code-review

우리는 코드처럼 문화도 리팩토링한다 (새 탭에서 열림)

배달의민족 커머스웹프론트개발팀은 조직 규모 확대에 따른 복잡도와 비효율을 해결하기 위해 문화를 코드처럼 리팩토링하며 '경계 없는 파트' 구조를 도입했습니다. 특정 도메인이나 서비스에 갇히지 않고 책임을 확장하는 R&E(Responsibility & Expandability) 원칙을 통해 기술적 통합과 조직의 유연성을 동시에 확보했습니다. 이러한 시도는 서비스 간 장벽을 허물고 구성원들이 커머스 전반을 조망하는 엔지니어로 성장하며, 비즈니스 요구에 기민하게 대응하는 결과로 이어졌습니다. ### 경계 없는 파트와 R&E 중심의 조직 구성 * **전통적 분할 방식의 탈피**: 프로젝트, 페이지, 서비스(B마트/배민스토어) 단위로 조직을 나눌 경우 발생하는 리소스 불균형과 도메인 파편화 문제를 해결하기 위해 고정된 경계를 제거했습니다. * **R&E(Responsibility & Expandability) 도입**: 단순히 주어진 역할만 수행하는 R&R을 넘어, 문제 해결을 위해 업무 영역을 스스로 확장하고 동료를 돕는 'Own It' 정신을 조직 구조에 이식했습니다. * **유연한 리소스 배분**: 약 20명의 프론트엔드 개발자를 3개 파트로 나누되, 특정 도메인에 종속시키지 않고 팀 상황에 따라 업무를 배분하여 병목 현상을 최소화했습니다. ### 기술적 통합을 통한 도메인 확장성 확보 * **통합 아키텍처 구축**: B마트와 배민스토어의 상품 카드 및 상세 화면 등 유사한 UI/UX를 공통 모듈로 추상화하고 API 구조를 맞춤으로써 코드 베이스의 일관성을 확보했습니다. * **엔지니어링 역량 강화**: 개발자들이 고객 서비스의 UX부터 어드민의 데이터 흐름까지 전방위적인 도메인을 학습하게 하여, 특정 기능 담당자가 아닌 커머스 전체를 이해하는 전문가로 성장하도록 유도했습니다. * **리스크 관리(Bus Factor 개선)**: 특정 인원이 부재하더라도 다른 팀원이 맥락을 즉시 이어받을 수 있는 구조를 만들어 프로젝트 중단 위험인 '버스 팩터'를 획기적으로 낮췄습니다. ### 지속적인 개선을 위한 소통과 기록의 리팩토링 * **의사결정 자산화(ADR)**: 단순한 기획 공유인 1Pager 방식에서 나아가, 기술적 결정의 배경과 맥락을 기록하는 ADR(Architecture Decision Record)을 도입해 팀의 지식을 체계적으로 관리합니다. * **루틴의 재설계와 자동화**: 반복적인 업무나 귀찮은 과정을 레거시로 남기지 않고, 자동화와 프로세스 개선을 통해 개발 효율성을 지속적으로 높입니다. * **심리적 안전감 기반의 협업**: '불판'과 같은 자유로운 논의 문화를 통해 실패를 과정으로 수용하고, 질문이 스터디로 이어지는 선순환 구조를 구축했습니다. 성장하는 조직에서 발생하는 비효율을 방치하지 않고, 코드 리팩토링과 같은 관점에서 구조와 문화를 끊임없이 개선하는 태도가 중요합니다. 특히 도메인 간 경계를 허무는 시도는 대규모 서비스 통합이라는 복잡한 비즈니스 과제를 해결하는 데 매우 강력한 전략이 될 수 있습니다.

코드 품질 개선 기법 25편: 요컨대... 무슨 말이죠? (새 탭에서 열림)

효과적인 코드 리뷰를 위해서는 리뷰 코멘트를 작성할 때 결론인 제안이나 요청 사항을 가장 먼저 제시하고, 그에 따른 근거와 이유는 뒤에 덧붙이는 구조를 취해야 합니다. 이러한 방식은 리뷰 요청자가 코멘트의 핵심을 즉각적으로 파악하게 하여 전체적인 리뷰 프로세스의 효율성을 높여줍니다. 명확한 구조로 작성된 코멘트는 불필요한 재독을 줄이고 제안된 의견의 타당성을 더 빠르게 검증할 수 있게 돕습니다. **불명확한 리뷰 코멘트의 예시와 문제점** * **가변 객체 사용의 위험성**: Kotlin의 `data class`에서 속성을 `var`로 선언하면 외부에서 객체의 상태를 직접 변경할 수 있어, 의도치 않은 시점에 데이터가 수정되는 버그를 유발할 수 있습니다. * **불필요한 인스턴스 공유**: 상태를 업데이트할 때 새로운 불변 인스턴스를 생성하는 대신 동일한 가변 객체를 공유하면 시스템의 견고함이 떨어집니다. * **정보 전달의 지연**: 제안 사항(모든 속성을 `val`로 변경하고 클래스를 분리할 것)이 코멘트의 마지막에 위치하면, 작성자는 긴 설명을 다 읽은 후에야 무엇을 고쳐야 하는지 알게 되어 인지적 부담이 커집니다. **제안 사항 우선 방식의 코멘트 구조화** * **핵심 제안 선행**: 코멘트의 첫머리에 "데이터 업데이트 빈도에 따라 클래스를 분리하고 속성을 `val`로 선언하세요"와 같이 구체적인 액션을 명시합니다. * **근거의 범주화**: 제안 뒤에 붙는 이유는 '객체의 불변성'과 '값의 라이프사이클'처럼 논리적인 항목으로 나누어 설명합니다. * **가독성 향상 기법**: 설명해야 할 항목이 몇 개인지 미리 밝히고(예: "다음 두 가지 측면에 기반합니다"), 각 항목에 제목을 붙여 구조화하면 전달력이 극대화됩니다. **데이터 모델링의 기술적 개선 방향** * **불변성 유지**: `data class`에서는 `var` 대신 `val`을 사용하여 `copy` 함수를 통한 예측 가능한 상태 업데이트를 지향해야 합니다. * **라이프사이클에 따른 분리**: 사용자 ID와 같이 거의 변하지 않는 속성과, 온라인 상태나 상태 메시지처럼 자주 변하는 속성을 별도의 클래스(예: `UserModel`과 `UserStatus`)로 분리하면 잘못된 업데이트를 방지하기 쉬워집니다. 리뷰 코멘트를 작성할 때는 '빠른 이해'를 목표로 결론부터 쓰는 것이 기본입니다. 다만, 상대방이 스스로 답을 찾아보게 하거나 깊은 고민을 유도하고 싶을 때는 의도적으로 중요한 부분을 뒤에 배치하는 전략을 취할 수도 있습니다. 상황에 맞는 적절한 설명 순서가 코드 품질과 팀의 개발 문화를 결정짓는 중요한 요소가 됩니다.

3년 차 앱 개발자가 일하는 순서를 공유합니다 (새 탭에서 열림)

효율적인 협업과 코드 리뷰를 위해 개발 프로세스를 세분화하고 작업 단위를 최소화하는 것이 핵심입니다. 기획 시뮬레이션부터 PoC(Proof of Concept), 그리고 리뷰어를 배려한 PR(Pull Request) 작성까지 이어지는 체계적인 워크플로우를 통해 작업의 예측 가능성을 높이고 팀 내 신뢰를 구축할 수 있습니다. 궁극적으로 작고 명확한 단위로 일하는 습관은 본인의 히스토리 관리와 팀의 전체 생산성 향상에 기여합니다. ### 기획 리뷰와 동작 시뮬레이션 * 기획서의 목적과 작동 방식을 명확히 이해하고, 실제 코드를 작성하듯 데이터 흐름과 화면 전환, 예외 상황(Edge Case)을 머릿속으로 시뮬레이션합니다. * 이 과정에서 사용자 경험을 위한 개선 아이디어나 의문점이 생기면 기획자와 즉시 소통하여 요구 사항을 확정합니다. * 복잡한 기능은 다이어그램이나 화살표를 활용해 전체적인 구조와 데이터 흐름을 시각화하여 큰 그림을 먼저 그립니다. ### 협업 효율을 높이는 작업 가시화 * 그려둔 작업 흐름을 바탕으로 Jira 에픽(Epic)과 하위 이슈들을 생성하여 전체 작업을 눈에 보이게 쪼갭니다. * 중요도가 높거나 여러 명이 관여하는 작업의 경우, 티켓을 확정하기 전 동료들에게 개발 방향 콘셉트를 공유하여 피드백을 받습니다. * 사전 공유 단계를 거치면 추후 리뷰 단계에서 발생할 수 있는 대규모 수정을 미연에 방지하고 불필요한 논쟁을 줄일 수 있습니다. ### PoC를 통한 규모 검토와 셀프 피드백 * 본격적인 개발 전 프로토타이핑(PoC)을 진행하며 예상치 못한 문제나 누락된 시나리오가 없는지 점검합니다. * PoC 단계의 코드 양을 확인하여(저자 기준 400줄), 변경 사항이 너무 많다면 주제별로 티켓을 분리하거나 하위 작업(Sub-task)으로 세분화합니다. * "내가 이 PR을 리뷰한다면 부담스럽지 않을까?"라는 질문을 스스로 던지며 리뷰어가 이해하기 쉬운 적정 규모로 작업을 조정합니다. ### 리뷰어 중심의 구현 및 PR 작성 * 의미 있는 단위로 커밋을 쪼개고, 인터페이스 정의 후 구현체를 작성하는 등 논리적인 순서로 코드를 쌓아 올립니다. * PR 작성 시에는 목적, 원인, 영향 범위, 테스트 방법 등을 상세히 기록하며, 필요시 동작 영상을 첨부하여 리뷰어의 이해를 돕습니다. * 작고 명확한 PR은 문제가 발생했을 때 원복(Revert)이 쉽고, 리뷰어에게 '읽기 편한 코드'라는 신뢰를 주는 효과가 있습니다. 이러한 워크플로우를 정착시키면 개발 기간 산정의 정확도를 높일 수 있습니다. 특히 Jira의 시간 기록 기능을 활용해 '최초 추정 시간'과 '실제 소요 시간'을 비교하고 기록하는 습관을 들이면, 본인의 개발 속도를 객관적으로 파악하고 더욱 정교한 일정 관리가 가능해집니다. 환경에 맞춰 이 프로세스를 유연하게 적용해 보시길 권장합니다.