<div id="readability-page-1" class="page"><div>4월초에 회사 블로그에 “매일 배포하는 팀이 되는 여정” 이라는 주제로 2편의 글을 작성했다. 틈틈히 회사에서 경험한 엔지니어링 관련 내용들을 블로그에 정리했었는데, 이 내용들을 보기 좋게 다듬었더니 글을 완성시키기까지 하루? 이틀? 정도 밖에 걸리지 않아서 가성비가 너무너무 좋았다. 엄청 특별한 내용이 있지 않은데 많은 분들이 관심을 가져준 이유는 단순한 예시/설명 형태가 아닌 시행착오가 담긴 경험담이 대부분이라 그런게 아닐까? 나도 어떤 특정 키워드로 검색후 글을 읽다보면 단순 설명만 있는 글에는 흥미가 많이 떨어진다. 경험에는 시간이 담겨져 있기 때문에 같은 이야기를 하더라도 경험이 더해진 이야기에는 더 많은 것들이 함축되어 있다고 생각한다. 더 많은 분들과 팀에서 이런 경험을 많이 공유해주면 좋겠다.

<ul>
 <li><a href="https://medium.com/daangn/%EB%A7%A4%EC%9D%BC-%EB%B0%B0%ED%8F%AC%ED%95%98%EB%8A%94-%ED%8C%80%EC%9D%B4-%EB%90%98%EB%8A%94-%EC%97%AC%EC%A0%95-1-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5-%EA%B0%9C%EC%84%A0%ED%95%98%EA%B8%B0-1a1df85b2cff">매일 배포하는 팀이 되는 여정(1) — 브랜치 전략 개선하기</a></li>
 <li><a href="https://medium.com/daangn/%EB%A7%A4%EC%9D%BC-%EB%B0%B0%ED%8F%AC%ED%95%98%EB%8A%94-%ED%8C%80%EC%9D%B4-%EB%90%98%EB%8A%94-%EC%97%AC%EC%A0%95-2-feature-toggle-%ED%99%9C%EC%9A%A9%ED%95%98%EA%B8%B0-b52c4a1810cd">매일 배포하는 팀이 되는 여정(2) — Feature Toggle 활용하기</a></li>
</ul>

<img src="https://sungjk.github.io/images/2023/04/29/daangn-medium.png" alt="daangn-medium" title="daangn-medium">

보안적으로나 대외적인 문제 등 때문에 회사 블로그에는 배포와 관련된 모든 이야기들을 담을 수 없었다. 물론 개인 블로그에도 마찬가지로. 굳이/불필요한 이런 절차가 왜 있는지, 이건 왜 이렇게 했는지 등 모든 것에는 다 이유가 있는데 글로 담아낼 수 없는 부분들이 많았다. 그리고 코드도 함께 공유하며 어떻게 사용하고 있는지 더 자세하게 공유하고 싶었는데도 말이다.

마침 사내에서 JVM 챕터 테크톡이 있을 예정이었는데, 이 자리에서 블로그 글에 담지 못했던 이야기들을 모두 공유해보면 좋겠다는 생각이 들었다.

<img src="https://sungjk.github.io/images/2023/04/29/jvm-tech-talk.png" alt="jvm-tech-talk" title="jvm-tech-talk">

일단 “저 해볼게요~” 하고 던졌는데 막상 발표하는 날이 다가올 수로 발표 준비를 하나도 하지 않아서 압박 아닌 압박으로 다가왔다. 자료 만들어야 되는데.. 어떤 내용 추가하지.. 순서는 어떻게 하면 좋을까.. 고민만 한 달 넘게 하다가 정작 발표 하루 전에 반나절을 투자해서 만들었다. 테크톡의 취지는 각 팀 또는 개인이 고민했거나 새롭게 알게 된 기술적인 내용을 가볍게 공유하는 것인데, 시간이 지나고 보니 혼자 너무 무겁게 생각했던거 같다.

<img src="https://sungjk.github.io/images/2023/04/29/keynote.png" alt="keynote" title="keynote">

발표는 팀 블로그 글에 작성한 2편의 이야기를 바탕으로 크게 “금융 서비스의 배포”, “배포 환경 개선하기”, “Feature Toggle 활용하기” 라는 주제로 나누어서 진행했다. 배포 프로세스는 왜 이러한 지, 우리 팀은 처음에 어떠했고 지금은 어떠한 지 등 글에 담아낼 수 없는 내용을 모두에게 알려줄 수 있어서 한 편으로는 속이 시원하기도 했다. 그리고 피쳐 플래그를 어떻게 구성했고 실제로 어떻게 사용하고 있는지 더 자세히 알고 싶다는 얘기도 있어서 코드 레벨에서의 실제 유스케이스도 함께 살펴보았다.

불과 1년전만 해도 단일 브랜치를 관리하는게 마냥 궁금했었는데 지금은 그게 나에게도 당연한 환경이 되었다. 그리고 안정적이고 효율적인 배포와 서비스 운영을 위해 당장 도전해보고 싶은 과제들에 대해서도 공유하고 아직도 갈 길이 많이 남았다는 것에 대해 구성원들의 공감대도 필요하다고 생각했다.

발표는 일론머스크의 엔지니어링 원칙에 대한 영상을 공유하면서 마무리했다(감동 모먼트로 공유하려고 했는데 마우스 클릭이 잘못되면서 내용이 미리 공개되어서 속상했다).

<iframe width="100%" height="400" src="https://www.youtube.com/embed/t705r8ICkRw?start=1015" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen=""></iframe>

영상을 쭉 보다 보면 일론이 모델3를 양산하면서 이 규칙을 5 -&gt; 4 -&gt; 3 -&gt; 2 -&gt; 1 역순으로 여러번 반복하면서 실패를 경험한 사례도 얘기해준다. 실제로는 1부터 5까지 순차적으로 해야하는데 말이다. 실제로 존재하지 않는 것에 대해 고민하고 있거나 해결하려 하거나, 이걸 자동화하려고 매달리지 말고. 진짜 필요한게 무엇인지, 없어도 되는건 아닌지, 요구사항(전제)부터 다시 잘 따져보는게 중요하다는 이야기다. Simplify. 복잡함은 통제해야 할 변수를 만들어내고, 변수가 많아지면 여기서 파생되는 문제들도 많아진다.

<img src="https://sungjk.github.io/images/2023/04/29/musk_engineering_philosophy.png" alt="musk_engineering_philosophy" title="musk_engineering_philosophy">

“네카라쿠배에서는 이렇게 한대요.” 그래서 어쩌라는거지? 그렇게 하는 이유와 전제도 함께 알려주면 좋겠다. 다른 회사나 팀에서 이렇게 하니까 우리도 그렇제 하자는건, 극닥전으로 말해서 ‘비효율적이고 불필요한 작업을 우리도 똑같이 해도 상관없다.’로 해석할 수도 있다. 전제가 잘못된건 아닌지, 이게 정말 필요한 건지, 스스로에게 먼저 ‘왜’ 를 던져보자.

<img src="https://sungjk.github.io/images/2023/04/29/inefficient.png" alt="inefficient" title="inefficient">
</div></div>

coyled.com

Jeremy Kim

4월초에 회사 블로그에 “매일 배포하는 팀이 되는 여정” 이라는 주제로 2편의 글을 작성했다. 틈틈히 회사에서 경험한 엔지니어링 관련 내용들을 블로그에 정리했었는데, 이 내용들을 보기 좋게 다듬었더니 글을 완성시키기까지 하루? 이틀? 정도 밖에 걸리지 않아서 가성비가 너무너무 좋았다. 엄청 특별한 내용이 있지 않은데 많은 분들이 관심을 가져준 이유는 단순한 예시/설명 형태가 아닌 시행착오가 담긴 경험담이 대부분이라 그런게 아닐까? 나도 어떤 특정 키워드로 검색후 글을 읽다보면 단순 설명만 있는 글에는 흥미가 많이 떨어진다. 경험에는 시간이 담겨져 있기 때문에 같은 이야기를 하더라도 경험이 더해진 이야기에는 더 많은 것들이 함축되어 있다고 생각한다. 더 많은 분들과 팀에서 이런 경험을 많이 공유해주면 좋겠다.
매일 배포하는 팀이 되는 여정(1) — 브랜치 전략 개선하기
매일 배포하는 팀이 되는 여정(2) — Feature Toggle 활용하기
보안적으로나 대외적인 문제 등 때문에 회사 블로그에는 배포와 관련된 모든 이야기들을 담을 수 없었다. 물론 개인 블로그에도 마찬가지로. 굳이/불필요한 이런 절차가 왜 있는지, 이건 왜 이렇게 했는지 등 모든 것에는 다 이유가 있는데 글로 담아낼 수 없는 부분들이 많았다. 그리고 코드도 함께 공유하며 어떻게 사용하고 있는지 더 자세하게 공유하고 싶었는데도 말이다.
마침 사내에서 JVM 챕터 테크톡이 있을 예정이었는데, 이 자리에서 블로그 글에 담지 못했던 이야기들을 모두 공유해보면 좋겠다는 생각이 들었다.
일단 “저 해볼게요~” 하고 던졌는데 막상 발표하는 날이 다가올 수로 발표 준비를 하나도 하지 않아서 압박 아닌 압박으로 다가왔다. 자료 만들어야 되는데.. 어떤 내용 추가하지.. 순서는 어떻게 하면 좋을까.. 고민만 한 달 넘게 하다가 정작 발표 하루 전에 반나절을 투자해서 만들었다. 테크톡의 취지는 각 팀 또는 개인이 고민했거나 새롭게 알게 된 기술적인 내용을 가볍게 공유하는 것인데, 시간이 지나고 보니 혼자 너무 무겁게 생각했던거 같다.
발표는 팀 블로그 글에 작성한 2편의 이야기를 바탕으로 크게 “금융 서비스의 배포”, “배포 환경 개선하기”, “Feature Toggle 활용하기” 라는 주제로 나누어서 진행했다. 배포 프로세스는 왜 이러한 지, 우리 팀은 처음에 어떠했고 지금은 어떠한 지 등 글에 담아낼 수 없는 내용을 모두에게 알려줄 수 있어서 한 편으로는 속이 시원하기도 했다. 그리고 피쳐 플래그를 어떻게 구성했고 실제로 어떻게 사용하고 있는지 더 자세히 알고 싶다는 얘기도 있어서 코드 레벨에서의 실제 유스케이스도 함께 살펴보았다.
불과 1년전만 해도 단일 브랜치를 관리하는게 마냥 궁금했었는데 지금은 그게 나에게도 당연한 환경이 되었다. 그리고 안정적이고 효율적인 배포와 서비스 운영을 위해 당장 도전해보고 싶은 과제들에 대해서도 공유하고 아직도 갈 길이 많이 남았다는 것에 대해 구성원들의 공감대도 필요하다고 생각했다.
발표는 일론머스크의 엔지니어링 원칙에 대한 영상을 공유하면서 마무리했다(감동 모먼트로 공유하려고 했는데 마우스 클릭이 잘못되면서 내용이 미리 공개되어서 속상했다).
영상을 쭉 보다 보면 일론이 모델3를 양산하면서 이 규칙을 5 -> 4 -> 3 -> 2 -> 1 역순으로 여러번 반복하면서 실패를 경험한 사례도 얘기해준다. 실제로는 1부터 5까지 순차적으로 해야하는데 말이다. 실제로 존재하지 않는 것에 대해 고민하고 있거나 해결하려 하거나, 이걸 자동화하려고 매달리지 말고. 진짜 필요한게 무엇인지, 없어도 되는건 아닌지, 요구사항(전제)부터 다시 잘 따져보는게 중요하다는 이야기다. Simplify. 복잡함은 통제해야 할 변수를 만들어내고, 변수가 많아지면 여기서 파생되는 문제들도 많아진다.
“네카라쿠배에서는 이렇게 한대요.” 그래서 어쩌라는거지? 그렇게 하는 이유와 전제도 함께 알려주면 좋겠다. 다른 회사나 팀에서 이렇게 하니까 우리도 그렇제 하자는건, 극닥전으로 말해서 ‘비효율적이고 불필요한 작업을 우리도 똑같이 해도 상관없다.’로 해석할 수도 있다. 전제가 잘못된건 아닌지, 이게 정말 필요한 건지, 스스로에게 먼저 ‘왜’ 를 던져보자.

사내 JVM 챕터 테크톡 후기

댓글