형주님의 초대로 인프콘 2022에 다녀왔다. 추첨제라서 못 갈 줄 알았는데 감사하게도 초대권을 주셔서 무사히 다녀올 수 있었다. 간만에 다녀온 컨퍼런스이니 간단하게라도 후기글을 써볼까 한다.

들었던 세션 내용을 정리하기보다는 철처하게 개인적인 관점에서 배운 점과 소회를 적어보려고 하니 세션 내용이 궁금하신 분들은 다른 글을 참고하는 걸 추천한다. 이후에 인프런에서 강의 영상과 발표 자료를 공개할 예정이라고 하니 기다렸다가 그걸 보시는 것도 좋을 것 같다.

인프콘은 코로나가 시작되고 처음으로 규모 있게 열린 오프라인 컨퍼런스였다. 게다가 인프런을 운영하는 인프랩에서 하는 행사였으니 많은 개발자분들의 관심을 받았던 거 같다. 실제로 신청자가 엄청 많아서 추첨 경쟁률이 높았다고 한다.

내가 인프콘에 가고 싶었던 이유는 기술적 경험을 나누는 세션들이 꽤 있었기 때문이었다. 코로나 전에는 여러 컨퍼런스의 연사가 엇비슷하고, 세션 주제도 경험 기반보다는 공식 문서만 봐도 알 수 있는 특정 기술에 대한 기본적인 내용을 정리해서 공유하는 게 많다고 느꼈다. 그래서 언제부턴가 개발 행사를 잘 다니지 않았었다. 그러나 이번 인프콘은 그때 이후로 시간이 많이 지나기도 했고, 인프랩에서 세션 주제를 많이 신경 쓴 덕인지 연사 라인업도 새로운 분들이 많았다. 또 경험 기반의 흥미로운 주제들도 많아서 기대되었다.

세션별 후기

사이드 프로젝트 만세! - 기술만큼 중요했던 제품과 팀 성장기 - 방진호 | Chromium 오픈소스 개발자

사이드 프로젝트를 하는 중이라 참고할 내용이 있을까 기대하기도 했고, 오픈소스를 운영하신 것이라 프로젝트에 대한 이야기도 재밌을 거 같아서 참석했다. 그러나 예상보다 팀장의 관점에서의 팀 매니징에 대한 이야기가 더 많았고, 프로젝트에 대한 이야기는 기술적인 부분보다 앱 프로젝트 특성과 연관된 이야기가 많아서 개인적으로는 조금 아쉬웠다.

세션에서 이야기하는 웬만한 내용들은 같이 사이드 프로젝트를 하고 계신 분들이 잘 챙겨주고 계셨다. 그래도 더 잘 챙겨볼 수 있는 것은 커뮤니케이션 동기화를 더 잘하기 위해 작업 내용을 슬랙에 더 자주 공유해보는 것이었다. 우리는 동기부여나 적극성 부분에 대해서는 다들 알아서 잘하는 부분이고 문제가 발생했을 때 잘 해결할 만한 사람들이라 걱정이 없었지만, 평소에 작업할 때 비동기로 커뮤니케이션하는 게 그리 원활하지 않아서 작업 진행 상황을 공유 받지 못한다고 느꼈던 적이 종종 있었기 때문이다.

기술적으로는 작업 의존성을 줄이기 위해 아키텍처를 변경하고, 속도를 높이기 위해서 인터페이스 디자인을 빡빡하게 리뷰하고 안쪽 부분은 비교적 느슨하게 리뷰한다는 점도 기억할만한 포인트였다. 이는 일할 때도 마찬가지라고 생각했기 때문이다.

세션에서 흥미로웠던 이야기 중의 하나는 회고 횟수를 줄여서 죄책감을 덜 느낄 수 있게 해준다는 것이었다. 우리야 서로 죄책감을 느껴가면서라도 빡세게 하자는 기조라서 이럴 필요는 없지만 다른 스터디 등을 운영할 때는 죄책감을 잘 다루는 것을 챙겨봐야겠다고 생각했다.

나도 내 코드의 문제를 찾고 싶다고요?! - 테스트 할 때 기억할 7가지 - 한주승 | CONTEC

기본적인 내용이었으나 정말 구체적인 테스트 방법과 테스트의 중요성에 대해 상기해주는 세션이었다. 요지는 유저 입장에서 테스트를 하고, 반드시 테스트를 하라는 이야기였다. 어떻게 테스트를 해야 하고, 왜 그렇게 해야 하는지를 정말 잘게 자세히 설명해주셨다. 개인적으로는 발표자분이 문제 상황을 추상화하고 고민하고 해결하는 과정을 디테일하게 정리하는 과정이 흥미로웠다.

이렇게 테스트 방법을 자세하게 정리하게 된 이유는 함께 일하는 신입 개발자 때문이었다고 한다. 상대에게 무언가를 가르칠 때에는 상대가 어떻게 사고하고 행동하는지 그 과정을 자세히 이해해야 효율적으로 티칭할 수 있다는 생각으로 접근하다 보니 정말 기본적인 테스트 방법을 모른다는 것을 알게 되셨다고 한다. 좋은 사수라는 느낌이 뿜뿜했다.

이 분은 PM 역할도 겸하시기에 유저 시나리오 베이스의 테스트 케이스 작성을 해야 하는 역할이지만, 다른 개발자들이 이걸 챙기는 게 효율적인가 하는 의문이 들기는 했다. 우리 회사는 PO가 유저 스토리 기반으로 작업 내용을 정의하고 있고, 제품 인수 전에 인수 테스트를 통해 이러한 테스트를 진행하고 있기 때문이다. 이 과정이 더 자연스럽게 느껴진다.

대부분의 개발자들이 풀스택으로 일하기보다는 프론트엔드나 백엔드로 나뉘어서 일하기 때문에 유저 스토리 기반으로 테스트 케이스를 작성하면 다른 사이드 작업도 같이 끝난 후에나 테스트를 할 수 있다. 개발자 개인이 잘 개발했는지를 더 빠르게 피드백을 받기 위해서는 더 작은 단위로 테스트를 쪼개는 연습을 하고, 유저 입장의 테스트는 팀 차원에서 진행하는 게 더 효율적이며 안정적인 프로덕트 개발을 가능하게 해주지 않을까 하는 생각이 든다.

이 발표 초반에 사람들이 빵 터지는 순간들이 있었는데 대놓고 드립을 치는 것보다 엄청나게 공감되는 상황을 설명할 때 많이들 웃으셨다. 다음에 발표할 때 참고해야지..

코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes - 서지연 | 컨택스츠아이오

짧은 세션이었지만 개인적으로 실무에 가장 도움이 될 것 같은 세션이었다. 우리 회사는 이미 일부분 Stacked Changes 방식의 코드 리뷰를 하고 있었다. 이러한 방식에 이름이 있고, 이를 도와주는 도구(graphite)가 있다는 걸 처음 알아서 너무나 흥미로웠다.

이 도구를 사용하면 브랜치를 반복적으로 이동하며 PR을 만들어주는 번거로움을 줄일 수 있다고 한다. 가장 좋았던 점은 PR을 작게 쪼개게 되면 한 PR이 원자성을 가지면서도 큰 작업의 일부분이 되는데 어떤 맥락에서 이 PR이 위치하는지를 github의 PR description에서 볼 수 있게 해주는 점이었다. PR 리뷰를 할 때 이 PR 전에 어떤 작업을 했고, 이후에 어떤 작업을 하게 될지를 알기가 굉장히 번거롭거나 어려웠는데 이 문제를 해결해줄 수 있을 거 같다.

실전! 멀티 모듈 프로젝트 구조와 설계 - 김대성 | 네이버

제일 기대했던 세션 중의 하나였다. 멀티 모듈 프로젝트를 개발하면서 발생하는 문제를 해결해나가며 변화하는 프로젝트 구조를 공유해주셨다. 특히 가장 공감이 많이 가는 부분은 코드 재사용을 위해 common이나 core 등의 모듈이 비대해지면서 생기는 부작용이었다.

코드 중복이 늘어나는 것과 의존성이 늘어남으로 생기는 비용을 비교하면 의존성이 늘어나는 게 압도적으로 비싸다. 이를 해결하기 위해 모듈 간의 경계를 잘 치는 것에 대한 이야기를 해주셨다.

보는 내내 이해하기 어려운 부분이 있었다. 모듈을 Bounded Context로 나누어서 크게 Infra/Data/Boot/Cloud 그룹으로 관리하는 부분이었다. 이렇게 되면 사실 또 도메인 모델에 대한 모듈을 제외하고는 대부분의 모듈이 공통 모듈이 되는 게 아닌가 하는 의문이 들었다.

일반적으로 DDD에서 BC에 대한 이야기를 할 때는 기능적인 분리를 위한 경계보다는 도메인 분리를 위한 경계로 하나의 팀만이 다루는 부분을 나누는 것을 이야기한다고 생각했다. 그래서 DDD에서 말하는 BC의 목적과 세션에서 말하는 BC의 목적이 살짝 다르지 않나 하는 생각이 들었다. 이 팀이 기능팀이라 DDD에서 말하는 부분이 필요 없어서 그런건가 싶기도 했다. 아니면 내가 이해를 잘 못했거나.. 좀 더 자세한 내용을 들어보고 싶었다.

(레거시 시스템) 개편의 기술 - 배달 플랫폼에서 겪은 N번의 개편 경험기 - 권용근 | 우아한형제들

역시 우형인가.. 하는 세션이었다. 5년 동안 여러 상황의 레거시 시스템을 개편하는 과정을 공유해주셨다. 레거시 시스템을 성공적으로 개편한 경험 자체가 값지다고 생각하는데 그러한 경험이 다양하게 많은 부분이 부러웠다. 이 발표자분의 이야기도 더 자세히 들어보고 싶다는 생각을 보는 내내 했다.

크게 경종을 울리는 부분은 레거시 시스템 개편에서 변경 범위를 같은 책임과 역할을 가지는 레이어로 정의하여 해결해나가는 관점과 안정적으로 개편하기 위해 테스트 케이스에 정말 많은 시간을 투자했던 점이었다. 테스트 케이스 정의만 한 달 동안 했던 적도 있다고 하셨다.

상상만 해도 어렵고 지루한 과정이 가득할 것 같은데 이를 잘 이겨내고 성공적으로 개편하신 점에 대해 마음 깊이 리스펙하게 되었다. 코드 변경과 관련된 모든 기능에 e2e 테스트를 붙이고 개편 내내 nGrinder로 부하를 줘가며 테스트했다는 점도 인상 깊었다.

이 세션에서도 도메인 지식을 높이기 위해 이벤트 스토밍이 추천되었다. 정말 이벤트 스토밍뿐인가 ㅠㅠ 개인적으로 이벤트 스토밍이 어느 정도 효과기 있다고 느끼기는 했지만 그 경험이 대체로 너무 지난했고 어느 해상도로 해야할지를 정의하는 게 쉽지 않았기에 시간 대비 효용을 못 느껴왔다. 성공적인 이벤트 스토밍을 경험해보고 싶다.

세션 외

• 굿즈를 정말 하나도 못 받았다. 줄서기 귀찮아서 나중에 받아야지했는데 행사 중간이 되기도 전에 대부분 품절되었다. 호엥. 사실 굿즈 자체가 탐나기 보다는 각 회사에서 무슨 굿즈를 주는지가 너무 궁금했는데.. 세상 아쉬워했는데 다음날 트위터에 굿즈 사진 올려주시는 분들이 많아서 호기심이 충족되었다! 해피엔딩.
• 사실 인프콘 행사 준비가 시작될 때 나 또한 연사 제안을 받았으나 거절했었다. (형주님 미안해..! 😂) 이력서와 같은 소프트 스킬에 이야기를 나누기 보다는 좀 더 개발 경험과 역량을 쌓는 것에 집중하고 싶었기 때문이다. 이런 이유로 요즘은 거의 모든 외부 활동을 거절하고 있다. 그런데 막상 거절해놓고 타임라인에 인프콘 얘기가 뜰 때마다 재밌어 보여서 아쉬운 마음이 들었다. 그러다가 최근 몇 주 동안 원래의 목적 대로 개발을 열심히 하게 되니 어느 순간부터 이런 뽀모를 덜 느꼈다. 인프콘 당일에는 아쉬운 마음이 거의 들지 않았고, 오히려 발표하지 않은 덕에 가벼운 마음으로 세션 듣는 일에 집중할 수 있어서 좋았다. 어떤 결정을 내리든 내 마음이 충만한 게 중요한거구나 싶었다. 앞으로도 계속 내 마음이 더 충만할 수 있는 선택을 하고자 한다. 이후에 기술적인 경험을 더 쌓은 후에 기술 관련된 주제로 컨퍼런스에 뿌듯하게 서고 싶다.
• 연사분들이 대부분 트친인 게 신기했다. 세션 들으면서 의문이 생겼던 부분을 기회될 때 슬쩍 물어봐야겠다.
• 간만에 개발 행사를 가니 오랜만에 만나게 되는 개발자분들이 꽤 있었다. 무척 반가웠다!
• 인프콘 전체적으로 오퍼레이션이 깔끔하다고 느꼈다. 엄청 고생하며 준비했을 인프랩 멋져.. 이런 멋진 행사를 준비해준 인프랩 사람들에게 감사하다.
• 이번 컨퍼런스 세션을 들으면서 개발자로써 나의 관점이 많이 성장했음을 느꼈다. 예전이었으면 감조차 잡지 못했을 여러 패러다임의 이야기들을 꽤나 현업에서 마주한 경험을 기반으로 이해할 수 있었다. 각 세션들 자체도 재밌었지만 이런 나의 변화도 재밌었던 시간이었다.
• 무엇보다 이번 인프콘에서 기억에 남는 것은 나에게 감사 인사를 해준 분들이었다. 나와의 멘토링이나 블로그, 강의 등을 보고 원하는 회사에 가셨다거나 서류 합격률을 확 높여서 성공적인 이직을 하셨다고 전해주셨다. 그러면서 거듭 감사하다고, 언젠가 꼭 인사드리고 싶었는데 이렇게 만나게 되어 인사했다는 말씀들을 해주셨다. 감사하다는 말을 전해주셔서 내가 더 감사하고 감동적이었다. 사람 많은 곳에서 지나가는 나를 붙잡고 그런 얘기 꺼내는 게 쉽지는 않을 것 같은데.. 나의 활동이 누군가에게 도움이 되었다는 사실이 뿌듯하고, 도움되는 사람이 될 수 있어서 감사했다.