우아한형제들에서 진행하는 콘퍼런스인 <우아콘 2022>에 대한 후기를 작성하고자 한다. 이번 컨퍼런스 역시 진행 중에는 실시간으로 확인은 하지 못 했고, 업로드되어있는 세션들을 들었다.
WOOWACON 2022
우아한테크콘서트, 함께해요
woowacon.com
사실 세션들이 뭐가 있는지만 확인해보려 했는데 너무 궁금한 것들이 많아서 들을 수 밖에 없었다. 현직 개발자들이 공감할만한 내용들과 주니어 개발자 또는 학생들에게 도움 될만한 내용들이 많았다. 주니어 개발자 입장에서 다른 큰 회사의 분위기와 프로젝트를 해결해 나가는 방법, 그리고 기업이 운영되는 모습을 간접적으로 느껴볼 수 있었다.
전체적으로 우아콘을 들어보니 우아한형제들이란 회사의 개발 환경은 그렇게 대단하게 잘 갖춰져 있지는 않았던 것 같다. 근데, 그걸 극복해낼 수 있는 구성원이 자유로울 수 있는 문화와 열정적인 구성원들이 있었기 때문에 계속 대단하게 갖춰나가고 있는 것 같다. 이미 국내에서 네카라쿠배당토에 당당히 한자리 차지하는 기업이지만 지금의 경험과 문화를 토대로 더 커질 것만 같은 회사라 생각됐다.
Day 1~3 세션이 나눠져있는데 그중 총 9개의 세션을 들었다. 내용이 정리된 것도 있고 소감만 적은 것도 있다. 세션을 들으면서 자유롭게 적은 것을 그대로 올리도록 하겠다.
참고로 각 세션들은 유튜브로도 볼 수 있는데, 우아콘 페이지에서 사람들이 코멘트를 남겨놓는 것들을 보는 것도 재밌었으니 유튜브로 봐도 코멘트는 보면 좋을 것 같다. 유튜브는 댓글을 막아놨다.
Day 1
기획서도, 시간도 없다! 나만의 카드를 선물하기 위한 여정!
요약
PM / 디자이너 / 개발자 2명으로 이루어진 그룹이다. 순서대로 설명을 한다.
PM
워킹그룹 '파티'에서 시작한 프로젝트다. 회사에서 사용하던 TF/스쿼드의 개념이긴 하나, 다른 프로세스를 적용해 일을 시작했다. 업무를 진행하는 방식이 정해져 있지 않고 퀘스트 달성을 위해 상황에 맞춰 의사 결정하는 것을 지향하는 유동적인 그룹이다.
그라운드 룰을 정하기 위해 애자일 방법론을 커스텀했다.
- 애자일 책 : Clean Agile / 애자일&스크럼 프로젝트 관리 / 함께 자라기: 에자일로 가는 길 / 카이젠 저니
사실상 이미 체계화되어 있고 많은 조직이 유기적으로 얽혀있는 경우 새로운 프로세스를 시도하기 어려워 방법론을 적용하기가 쉽지 않다. 애자일에서 강조하는 것들이 현실적으로는 어렵다. 절차가 많아 개인간의 상호작용이 어렵고, 문서화가 필수적이다 보니 작동하는 소프트웨어보다 우선시 되는 경우도 있다. 그러다 보니 초반에 정의되지 않은 스펙들을 적용하기 위한 변화에 대응하기 어려운 경우도 생긴다. 그래서 정말 작은 조직인 파티로 새로운 일하는 방식을 적용했다.
작은 워킹 그룹(파티)을 적용하기 위해 두가지를 정했다. 첫 번째는 업무 내용은 자주 공유를 했다. 작은 조직이고 조직원마다 맡은 역할이 전체 프로젝트에서 큰 부분을 차지하기 때문에 필요했다. 두 번째는 언제나 아이디어나 생각을 제안할 수 있고, 열린 마음으로 항상 생각해보기로 했다.
킥오프 후 아이디어 공유할 때 나온 내용들은 일정 대비 너무 많았다. 그래서 진행할 기능을 제한할 수밖에 없었는데 구성원의 역할에 따라 중요하게 생각하는 게 달랐기 때문에 오버 커뮤니케이션이 이뤄졌다. 2주 동안 정했지만, 생각의 공유 기간 동안에도 스펙이 정해지지 않았다고 멈추지 않고 각자 분야에 대해 검토를 했다. 그렇게 싱크를 진하게 맞추고 난 뒤 오히려 속도가 더 붙을 수 있었다.
디자이너
사용자가 꾸미기를 할 수 있는 공간을 주면서도 꾸미기를 할 수 있음을 직관적으로 알 수 있게 하는 것에 대한 고민에 빠졌다. 너무 채워넣자니 사용자가 직접 꾸미지 못할 것이고, 중간중간을 비워두면 뭔가 빠진 미완성적인 느낌을 받을 것이다. 그래서 나온 것이 gif로 활용 방안을 보여주는 방식이다.
사용자 허들을 낮추기 위해서는 한 화면에 하나의 기능씩 진행하게 했다. 한 번에 모두 다 하면 편할 수는 있어도 처음 허들이 너무 높아지기 때문이다.
개발자
2명의 개발자는 초반 기술 검토부터 QA 이슈 정리까지 최대한 짝 프로그래밍을 진행했다. 지금도 종종 사용할 정도로 페어 프로그래밍에 대한 좋은 경험이었다. 페어 프로그래밍 덕분에 어려운 이슈를 생각보다 훌륭하게 대처할 수 있었다.
하지만 페어 프로그래밍도 잘못되면 리소스가 두 배로 낭비되기 때문에 둘 만의 그라운드 룰도 정했다. 첫 번째로 한 화면을 같이 공유하면서 개발을 진행했다. 시뮬레이터나 동시에 동작 내용을 보는게 필요했기 때문이다. 두 번째로 코딩은 최대한 번갈아가면서 진행할 수 있도록 했다. 둘의 집중력을 위해서다.
작업 계획이나 작업한 내용에 대해서는 지속적으로 메모하고 공유했다. 페어 프로그래밍에서 코딩을 안 하는 입장에서는 리서치도 최대한 도와가면서 진행했다. 말로만 의견 전달이 어렵기 때문에 같이 코드를 작성하고, 다이어그램을 같이 만들면 설계를 하기도 쉬웠다. 커뮤니케이션에 추가적으로 투자할 필요가 없다 보니까 공유에 대한 장점이 많았다.
프로젝트를 진행하면서 스펙이 바뀌는건 문제가 되지 않는다고 생각한다. 다만, 파티원 모두가 바뀔 수 없는 스펙과 바뀔 수 있는 스펙에 대해 인지를 하고 있었기 때문에 오히려 의견 제시가 더 쉬웠다. 바뀔 수 있는 스펙들에 대해서는 서로 의견들을 충분히 교류하고 정할 수 있었다.
소감
애자일 기법을 경험해보고 싶었으나, 우리 회사도 여기서 제시한 문제와 동일한 문제를 겪고 있다. 이미 어느 정도 정형화된 프로세스가 있고, 대부분 폭포수와 같은 형태로 진행하고자 한다. 그러다 보니 원하는 프로세스대로 업무를 진행할 수가 없다. 이런 식으로 파티를 만들어 프로젝트 단위로 업무를 진행하는 게 회사 규모도 어느 정도 크니까 가능한 것 같으면서도 파티를 만들어 어떤 프로젝트를 진행할 수 있다는 게 부러웠다. 나도 회사에 애자일 방식을 통해 개발을 해볼 기회가 있을지 기대도 되며 걱정도 된다. 우선 TDD를 먼저 정착시키고 싶다.
이런 건 누가 할까? 배민 앱의 그레이존! 크고 작은 싱크홀 메꾸기
요약
그레이 존이란 일을 할 때 누구의 업무라고 하기도 애매한 업무 영역을 말한다.
여기서는 2가지를 주제로 말한다.
- 공통 로더 다시 만들기
- 공통 네비게이션 전격 개편
공통 로더는 배민앱에서 너무 오래되어 낡아 버린 것이 문제였다. 배민뿐만 아니라 B마트 등 음식 배달 주문과 거리가 먼 곳에서도 로딩 화면이 동일해 어색함이 있었다. 또, 배민과 거리가 먼 그냥 빙글빙글 돌아가는 로더도 있었다.
이 부분에 대한 수정을 담당자에게 맡기려고 했는데 담당자가 애매했다. 그래서 그레이존으로 정하고 발견한 개발자가 직접 담당했다.
모든 곳에서 공통적으로 쓰여도 괜찮으면서 사용자가 어색함을 느끼지 않을 로더가 필요했다. 그렇게 새롭게 탄생한게 두근두근 로더다. 주문을 앞두고 설레는 감정을 표현하기에 좋았다.
이런 그레이존을 처리하면서 싱크홀을 만나게 되었다. 로더를 크게 두 개로 만들었더니, 언제 이 로더가 돌아가고, 또 언제는 다른 로더가 돌아가야 할지 범위를 규정하는 게 필요해졌다. 처음에는 10 케이스로 2개의 로더를 결정할 기준을 정했다. 하지만, 타 부서와의 회의들을 통해 이는 터무니없음을 알게 되었고, 3페이지도 넘어갈 정도로 규칙들이 많아졌다. 최종적으로 로더가 표시될 수 있는 600 곳에 대해 각자 이유와 함께 어떤 로더를 써야 할지 정하는 작업을 해야 했다.
레거시가 쌓이고 쌓여 공통 내비게이션이 너무 낡아졌다. 앱 내비게이션을 간편화하고 최신화할 수 있어야 했다. 하지만, 이 일 역시 그레이존이었다. 이번에는 너무 큰 영향범위와 다양한 유관부서, 복잡한 레거시들이 문제였다.
여기서 방향 설계와 공감대 형성을 해야 업무를 진행할 수 있을 거라 판단해 리서치 부서와 함께 사용자 테스트를 통해 방향성을 검토했다. 검토가 끝났어도 너무 많은 유관부서로 인해 협업에 대한 문제였다. 어떤 과정을 거치던 사이사이 협업이 필요했다. 처음에는 3명에서 시작한 프로젝트가 어느새 120명이 넘어있었다.
최종적으로 프로젝트가 진행되면서 어떻게 기존 R&R에 맞게 일을 나눌 것인가가 중요했다. 그리고 그에 못지않게 어떻게 함께 잘 만들지가 중요한 일이었다.
소감
그레이존에 대해 누군가가 나서서 업무를 다뤄준다는 것 자체가 대단한 일인 것 같다. 알면서도 조용히 넘어가던 일을 누군가 들춰서 고치는 작업은 회사 운영에 있어서 매우 중요한 일이라 생각한다. 생각보다 어떤 작업을 할 때 누구의 업무인지 확인하는 일이 어려운데, 누군가에게 담당시키는 게 아니라 이렇게 모든 조직원들이 다 같이 협조해서 해내는 게 대단해 보인다.
우리 회사는 그레이존이 있다면 보고를 통해 위로 올라가며 대부분 위에서부터 업무에 대한 담당자 협의한다. 그리고 담당자에게 전달되는 형식이다. 애매한 영역이 없어지기 때문에 깔끔하긴 하다. 하지만, 아래에서부터 필요성을 느끼고 개선을 요청하고 스스로 바꿔나가는 건 배울 부분이라 생각한다.
합이 좋은 PM과 디자이너, 비결이 궁금하신가요?
요약
배민 사장님 앱에 대해 PM과 프로덕트 디자이너 간의 협업 이야기를 다룬다.
사장님들이 사용할 배민의 앱이 6개나 되었다. 서비스들이 모두 분리되어 있었고, 이를 통합하는 프로젝트였다. 주문 접수뿐만 아니라 가게 운영을 위해 필요한 기능들을 통합시켰다. 또한, 외부 브라우저가 아닌 인앱 브라우저(웹뷰)를 이용해 사용자 경험을 더 늘릴 수 있었다.
PM은 보통 프로젝트에 혼자다. 그래서 결정이 잘못된 경우에 대한 두려움이 있다. 이번에는 프로덕트 디자이너와 개발자들처럼 거의 페어처럼 일을 했다. PM과 프로덕트 디자이너가 겹치는 R&R을 갖는 영역에 대해 의견을 교류할 수 있었다.
프로젝트 중간에 투입되어도 배경과 근거를 알려주고 히스토리가 모두 공유받았다. 그래서 이후 협의가 원만할 수 있었다. PM의 기획서에 대해 디자이너가 꼼꼼히 확인해주는 덕분에 디자이너의 피그마와 정확히 일치시킬 수 있었다.
협업 노하우 3가지
- 혼자 고민하는 시간 줄이기
- 동료의 업무에 과부하가 걸렸을 때, 상황에 맞춰 유연하게 도와주기
- 쌓인 신뢰를 바탕으로 한 마음으로 일하기
소감
이렇게 디자이너 또는 PM과 협업을 한 적이 아직 없다. 하지만 세션을 통해 협업을 할 때의 바람직한 자세가 무엇일지 다시 생각해보게 되었다. 특히 협업 노하우 3가지 중 1번은 중요하다고 생각한다. 혼자 고민도 어느 정도는 필요하지만 혼자만 고민한다고 협업이 될 리가 없다.
기획자님들! 개발자가 아키텍처에 집착하는 이유, 쉽게 알려드립니다
요약
소프트웨어는 도메인 영역과 인프라스트럭처 영역으로 바꿀 수 있다. 핵심 요소는 도메인, 그 외의 영역은 인프라스트럭처 영역이다. 서비스에서는 UI, DB, API와 같은 것들이 인프라스트럭처다. 이때 도메인과 인프라스트럭처 사이 존재하는 선들을 의존성이라 한다.
계층형 아키텍처는 목적이 같은 코드들을 계층으로 그룹화한 아키텍처다. 프레젠테이션(UI), 도메인(업무 로직), 영속성(DB, API) 계층과 같이 나눌 수 있다. 여기서 계층을 직접적으로 참조하면 연쇄적인 참조 관계가 문제가 된다. 프레젠테이션 계층에서 도메인 계층으로의 요청이 직접적으로 영속성 계층으로의 요청인 것과 같아지기 때문이다. 그럴 경우 영속성 계층의 수정이 프레젠테이션 계층으로 직접적인 영향이 있다.
또 다른 문제는 프레젠테이션 계층과 영속성 계층의 수정으로 인해 중요한 도메인 계층에 영향이 많이 끼친다는 것이다. 빈번한 UI 수정을 감당하기 위해 도메인 영역은 계속해서 수정이 이뤄진다.
이를 해결하기 위해 어댑터라는 것을 사용한다. 도메인은 양쪽 계층과 어댑터만을 이용할 수 있도록 하는 것이고, 내부 동작과는 의존성을 끊는 것이다. 이는 인터페이스를 이용하는 것으로, 의존성 역전 기능을 사용하는 것이라 할 수 있다.
헥사고날 아키텍처는 클린 아키텍처를 구현하는 방법을 구체화한 것이다. 핵심 업무 규칙이 육각형 안에 있으며, 이는 외부의 변화로부터 보호하기 위함이다. 도메인 영역 경계에는 API가 있으며, 외부와는 핵심 업무규칙에 직접 접근이 어렵고 인터페이스를 통해서만 접근 가능하다.
아키텍처를 보다 보면 재밌다. 하지만 재미만으로 아키텍처를 도입하려 하지는 않는다. 개발자는 도메인에 외부 세부사항의 변경으로부터 분리하기 위해서, 그리고 개발비용이 감소할 수 있기 때문에 아키텍처 도입을 목표로 한다.
소감
사실 시스템 아키텍처는 너무 회사에 정착되어있어서 내가 개발할 정도만 손대 볼 수 있다. 그것도 공부하고 회사 다니면서 점차 늘고는 있지만 아직 부족함을 많이 느낀다. 클린 아키텍처에 대한 책도 몇 권 읽어봐야겠다는 필요성을 느끼긴 했는데 책이 있을지는 몰랐었다. 책을 읽어봐야겠다는 생각이 들었다. 필요성은 충분히 알고 어떤 게 더 나은 아키텍처 인지도 알지만 실제로 그렇게 개발하기란 쉽지 않은 것 같다. 개발 잘하고 싶다.
Day 2
요약
배달의 민족은 2015년 모놀리틱 구조로 만들어져 있었다. 2017년부터 주문수의 증가와 트래픽의 증가로 하나의 시스템과 하나의 데이터베이스로 버틸 수 없게 되었다. 이때 마이크로 서비스로의 전환을 시도했고 안정기를 찾을 수 있었다. 마이크로 서비스로 전환되면서 이벤트 기반의 아키텍처를 사용하게 되었다. 이제는 국내에서도 MSA 기반 아키텍처는 생소한 개념이 아니다.
하지만 하나의 마이크로 서비스에서 다루는 이벤트 기반 아키텍처는 아직 생소하다. 오늘은 배달의 민족에서 다루는 방식을 하나의 서비스를 예로 설명한다.
먼저, 이벤트를 정의해야 한다. 마이크로 서비스 아키텍처에서 "느슨한 결합"이라는 키워드 때문에 이벤트 기반 아키텍처가 항상 뒤따라온다. 물리적인 분리만으로 두 서비스가 분리되는 것은 아니다. 비동기 처리마저도 스레드 레벨의 의존도만 없앨 뿐, 특정 A 행위 다음에 다음 B 행위가 이어진다는 의존도를 낮출 수는 없다.
메시징 시스템을 이용하는 것도 항상 의존성을 낮춘다고 할 수 없다. A 행위를 수행한 서비스에서 큐에 B 행위 요청 메시지를 넣는다는 것은 물리적 의존관계만 없앨 뿐 논리적 의존관계는 여전히 존재한다는 것이다.
만약, A 행위를 처리하고 A 행위가 발생했다는 메시지 큐에 메시지를 입력하면 어떨까? 이때는 A 이후에 B가 수행되어야 한다는 의존관계가 없기 때문에 의존성을 드디어 없앴다고 할 수 있다. 이제 느슨한 결합이 된 것이다.
즉, 메시징 시스템을 사용하면 의존성을 낮출 수는 있지만, 메시지의 의미에 따라 완전히 느슨한 결합을 만들 수 있을지가 정해진다. 이를 통해 알 수 있듯이, 발행해야 할 이벤트는 달성하려는 목적이 아닌 도메인 이벤트 그 자체다.
내부 이벤트와 외부 이벤트에 대한 비교, 하나의 서비스에서 이벤트를 발행/구독하는 구조, 외부 이벤트 발행에 대한 일반화 등에 대해 설명해준다.
소감
C++로 모놀리틱 구조의 패키지 제품을 만들다 보니, 마이크로 서비스에 대해 잘 몰랐고 궁금했다. 회사에서 만드는 시스템은 이런 방식으로 구성되어 있지 않지만, 클라우드 시장을 더 빠르고 확실하게 잡기 위해서는 이 구조도 한 번 생각해볼 필요는 있을 것 같다. C++로도 충분히 만들 수 있을 것 같은데, 비슷한 개념이 필요할 때 도입해보도록 해봐야겠다. 물론 지금 회사 제품에는 필요 없을 가능성이 크고 다른 모듈들 간 같이 수정되어야 하기 때문에 어려울 수 있다.
세션 중간에 그림에 배치된 AWS 서비스들은 이해 못 했지만 대략적인 접근법에 대해 알 수 있었다. 최근 들어 최신 기술을 찾아보는 게 적어진 것 같아 자극을 많이 받았다. (이제는 MSA도 최신 기술은 아니지만)
API Gateway Pattern에는 API Gateway가 없다
요약
이 세션도 MSA에 대해 다룬다. 하지만 MSA에서 API Gateway Pattern에 대해서 다룬다. 흔히들 하는 API Gateway Framework에 대한 오해를 해소하기 위한 세션이다. 이 세션에서는 API Gateway Pattern을 사용할 수 있는 곳에서는 API Gateway Framework가 필요 없다는 것을 말한다.
API Gateway Pattern은 여러 마이크로 서비스로 나뉜 것을 하나로 묶어 클라이언트가 호출할 수 있게 해주는 것으로, 마이크로 서비스에서는 필수적인 요소다. 단순히 내부 API를 외부 API로 맵핑하는 것이 아닌, API Gateway가 인증을 해서 클라이언트가 호출 가능한 API만 보여줄 수도 있다. 이는 API Gateway Framework에서 간단한 설정 정보만으로도 구현이 가능하다. 하지만, 이건 API Gateway Pattern이 아니다.
실제로는 내부 API를 외부 API로 맵핑하는 것이 아니다. 클라이언트의 비즈니스 요청을 받은 뒤, 서버에서 내부 API를 조합한 후, 응답을 필요한 것만 추려서 반환하는 것이다. 이는 앞의 것과 달리 설정만으로 되는 것이 아니라 개발자가 코드로 작성해야 한다.
발표자 경험상 실제 MSA를 하면서 API Gateway Framework를 사용할 일이 많지는 않은 것 같다. 게다가 앞에 설명한 것처럼 잘못 오해하는 것 때문에 의사소통에서 오류가 발생하고 있다. 전자의 경우는 MS에서 Gateway Routing Pattern이라고 정의했다. 단순 요청/응답 라우팅에 관한 패턴이다.
다시 말하지만 API Gateway Pattern은 단순 라우팅이 아니라 코드를 통해 APi Gateway Pattern에서 정의한 역할을 수행할 수 있다.
소감
세션의 뒤의 내용들은 가장 앞에 설명하신 내용을 보충하는 식이다. 앞에 중요한 내용들이 다 나와있어 좋았다. 많이 듣고 지내온 내용이 아니기 때문에 어려웠지만 대강 느낌은 알았다. 앞의 MSA를 다룬 세션과 이 세션은 나중에 필요한 경우에 다시 찾아들어도 좋을 것 같은 세션이었다. API Gateway 뿐만 아니라 다른 곳에도 적용할 수 있는 개념이라 생각한다.
NAC(Network Access Control)는 필요악인가?
소감
정보보호실 팀원분이 나와서 우아한 형제들에서 NAC 설루션을 구축한 내용에 대해서 소개해준다.
오랜만에 NAC에 대해 들어서 반가웠다. 우리 회사에서도 여러 솔루션을 도입 검토하는 걸로 아는데, 현재 어디까지 적용됐는지는 모르겠다. 확실한 건 NAC은 없는 것 같다. 그러다 보니 이런 것들을 고민하고 있을지 궁금해졌다. 에이전트 방식, 에이전트리스 방식 어떤 것을 사용할지, 현재 서비스가 효율적으로 이루어지고 있는지 등이 궁금해졌다.
Day 3
개발자, 교육자가 되기로 결심하다?! : 가르칠 수 있는 용기를 갖기 위한 성장기
소감
우아한 테크 코스의 교육개발팀원분들이 진행하는 세션이다. 세션을 듣기 전에는 단순히 사내 교육팀 정도인 줄 알았다.
그 유명한 우아한 테크 코스라고 하니 어떤 사람들인가 궁금했다. 우아한 테크 코스의 코치들이 어떤 사람일지 궁금했다. 개발자의 포지션에서 계속 유지하는 것과 새로운 후배 양성에만 몰두하는 것은 완전히 다른 것이라고 알고 있기 때문에, 왜 교육자가 되는 것을 선택했는지 궁금해졌다.
마침 왜 교육자가 되기로 했는지에 대해서 물어봐서 신기했다. 한 분은 개발자로 슬럼프와 리뷰어의 위치에서 보람이 합쳐졌다고 했는데, 후배나 동료뿐만 아니라 선배와도 좋은 질문과 답변을 하면서 나도 느꼈던 부분이다. 슬럼프는 아니었지만, 리뷰어 혹은 리뷰이로써 나도 후배에게 도움을 주고 싶은 부분이 많았다. 내가 겪은 어려움들이 많았기 때문에 더욱 그랬었는데 나도 언젠가는 후배에게 도움을 많이 줄 수 있는 좋은 시니어가 되고 싶다. 한동안 현업만 하면서 그 감정을 못 느꼈던 것 같다.
생각보다 기술 스킬을 늘리지 못하고, 업무 시간에는 개발이 불가능하기 때문에 스스로 의지가 있어야 개발이 가능한 부분이 있다고 했다. 개발을 위한 욕구를 해소하기 위해서는 교육 도메인에 포함되어있는 서비스들을 직접 만들면서 해소하는 경우가 있다고 했다.
이런 부분을 자유롭게 할 수 있는 환경 자체가 중요한 것 같다. 하고 싶어도 못 하게 하는 직장이 아닌 것 같아 우아한 형제들이 정말 좋은 문화가 정착되어 있다는 것을 느꼈다.
우리 팀의 코드 리뷰 문화, 이렇게 조금씩 발전했어요
요약
배민 커머스 서비스의 웹 프런트 팀이 진행하는 세션이다. 웹프런트팀이지만 개발과 디자인뿐만 아니라 서버와 데브옵스 등 다양한 것을 고려하고 있다고 한다. 유연한 아키텍처에 대한 고민과 문서화와 코드 리뷰 등을 통해 고민을 하고 있다고 한다.
코드 리뷰가 필요한 이유는 너무 이론적인 설명 말고 실제로 하면서 중요했고 필요했던 이유들에 대해 정리했다. 크게 4가지로 정리할 수 있었는데, (1) 코드의 일관성 유지, (2) 로직 더블 체크, (3) 코드 중복 제거, (4) 함께 성장할 수 있는 기회였다.
(1) 신생팀이다 보니 코드의 일관성을 팀 내부에 정착시킬 필요가 있었다. 코드 일관성을 맞추게 되니 개선과 유지보수에 들어가는 리소스가 줄었다. 로직을 이름과 타입만으로도 어떤 기능을 하고 무엇을 의도하는지 쉽게 파악할 수 있었다.
(2) 빠듯한 일정과 잦은 요구사항 변경이 있다면 잦은 실수가 있을 수 있다. 이때는 더블 체크가 정말 효율적이었다. 오타뿐만 아니라 의도된 로직 인지도 더블체크할 수 있었다. 다 함께 책임감을 갖고 로직에서 발생 가능한 문제를 서로 논의도 할 수 있었다.
(3) 중복된 코드가 제거됨으로써 유연한 코드가 될 수 있다고 생각한다. 중복된 부분들은 통일하거나 추상화하는 방식으로 논의했다. 비슷한 컴포넌트들을 각자 만들어 쓰다 보니까 결국에는 컴포넌트를 분리해 공통적인 베이스 컴포넌트와 이를 기반으로 각 컴포넌트들을 새롭게 구성했다.
(4) 코딩 노하우나 영감을 얻는 것에 그치는 게 아니라, 이슈 처리를 하면서 얻은 배경지식들을 공유할 수 있었다. 추후 비슷한 문제가 발생했을 때 빠르게 해결할 수 있었다.
코드 리뷰는 풀 리퀘스트를 하게 되면, 랜덤으로 리뷰어 2명이 할당된다. 여러 프로젝트별로 작업자들이 다른데, 현재 진행하고 있는 프로젝트와 상관없이 랜덤으로 리뷰어가 된다. 프로젝트의 담당자들만 리뷰를 한다면 프로젝트에 대한 이해도는 다른 사람보다 높겠지만, 성격이 다른 프로젝트의 인원도 참여하면서 모든 프로젝트에 대해 알아갈 수 있도록 했다. 리뷰어 2명은 필수지만, 다른 사람도 언제나 리뷰어가 될 수 있다. 즉, 모두가 자발적으로 열심히 리뷰를 해준다.
리뷰어에 당첨되거나 리뷰어가 리뷰를 남겨주면 슬랙 알림을 보내주어 빠르게 피드백할 수 있는 시스템을 만들어놨다. 프런트엔드 매니저라는 것을 두어 필수 리뷰어 2명의 approved를 받으면 머지를 시켜주고, 순차적 merge 작업을 자동화시켜준다. 만약 실패 시에는 알림을 따로 보내준다.
또한 오전에 코어 코드 리뷰 시간을 정해 다른 업무로 바쁘다고 코드 리뷰가 밀리는 경우가 없도록 했다. 하루의 시작을 MR(Merge Request)로 할 수 있게끔 알림을 받기 때문에 따로 시간을 요청하지 않아도 코드리뷰가 가능해졌다.
그리고 딱딱한 코드 리뷰만 하는 게 아니라 부드럽게 풀 수 있도록 편한 리뷰들을 남길 수 있어, 자유로운 의견 교류가 쉬웠다.
리뷰 규칙들에 대해서도 소개를 해준다. (1) 'approve 해주세요' 대신 '리뷰 해주세요'라고 말하기 규칙이다. 농담으로라도 리뷰를 대충 하지 않기 위함이다. (2) MR 제목 규칙을 정했다. 각자 마음대로 하다 보니 커밋 로그에 대한 가독성이 떨어졌다. (3) 리뷰어를 배려한 MR 내용 작성하기도 정했다. 작업 내용에 대한 설명이 부족하면, 리뷰어는 코드만 보고 배경을 유추했어야 했다. 많은 양의 코드를 한 번에 리뷰 요청하는 것도 부담스러웠다. 작업의 병목을 해결하기 위해 MR 작성 템플릿을 작성했다. 이렇게 하면 리뷰어는 리뷰 내용을 빠르게 알 수 있고 리뷰이는 MR 크기를 확인할 수 있어 끊어갈 수 있었다. (4) 히스토리 남기기도 필요했다. 종종 오프라인 리뷰를 진행하는데 이때는 온라인 리뷰와 달리 히스토리가 남지 않는다. 추후에 내용을 보거나 온라인으로 보는 사람은 내용을 알기 어려웠다. 그래서 히스토리를 남기는 규칙을 남겼다.
리뷰를 하는 사람과 받는 사람이 생각하는 중요도가 다를 수 있다. 그렇기 때문에 리뷰를 해주는 사람이 직접적인 중요도를 표시해 리뷰받는 사람과 의사소통에서 오류가 발생하지 않도록 하는 것이 중요하다. 이를 해결하는 방법으로는 이모지를 이용해 간단히 정의했다.
핫픽스의 경우 리뷰 없이 바로 배포될 수도 있다. 그때는 사후 리뷰를 반드시 받도록 되어있어 안전성을 놓치지 않을 수 있었다.
마지막으로, 리뷰에 대한 회고 시간에 BEST 코드 리뷰를 공유하고 다른 파트에서도 주고받는 의견도 확인해볼 수 있다.
소감
배민의 코드리뷰 문화는 어떤지 볼 수 있어 좋았다. 사실 이런 부분들은 IT 대기업이 확실히 잘하고 있을 것이라고 생각했었는데, 내가 더 많은 코드를 보고 더 많은 작업들을 직접 해볼 수 있을 것 같아 중견/중소 회사를 찾았었다.
물론 내 선택이 틀린 것은 아니라고 생각하지만, IT 대기업은 확실히 시스템 자체가 최신의 것이라 더 효율적인 것 같다. 우리 회사도 문화만 도입하는 게 아니라 이제는 시스템도 빠르게 도입해주면 좋을 것 같다. 우선은 온라인으로도 투명하게 리뷰할 수 있도록 git과 gitlab이나 github 등에 연동해 구축해주면 좋을 것 같다....
그리고 회사에서 코드 리뷰를 처음 접했을 때(지금도 약간) 사소한 의견을 내기가 어려웠다. 중요한 내용만 말하게 되는데, 가벼운 분위기를 만들어준 것 자체가 주니어도 활발히 리뷰에 참여할 수 있는 환경을 만들어주는 것 같다.
'리뷰 > 컨퍼런스, 세미나 등 리뷰' 카테고리의 다른 글
| [컨퍼런스] INFCON 2023 (2023/08/15) (1) | 2023.10.03 |
|---|---|
| [컨퍼런스] if(kakao)dev2022 (2022/12/07~12/09) (0) | 2023.01.17 |
| [컨퍼런스] NDC(Nexon Developer Conference) (2022/06/08~06/11) (0) | 2022.08.09 |
| [컨퍼런스] Google I/O (2022/05/11) (0) | 2022.05.21 |
| [컨퍼런스] AWS Innovate AI/ML Edition (2022/02/24) (0) | 2022.02.27 |
