레몬베이스 Frontend 설계 지침서

소속: 레몬베이스 Lemonbase

레몬베이스 Frontend 설계 지침서는 레몬베이스의 엔지니어가 프론트엔드 코드를 설계하고 작성하는 사고 과정을 풀어낸 문서입니다.
엔지니어가 실천할 수 있는 가이드이자 교육 자료로 활용되며, 이해를 돕기 위한 다양한 문제 해결 사례를 다루고 있습니다.

TF를 결성하고 이끌어 표면적인 현상이 아닌 문제의 본질을 밝혀내고, 팀 내 갈등을 유발하던 코드 논쟁에서 합의를 이끌어낼 기준점을 제시해, 팀의 역량을 강화하는 데 집중했습니다.

진행 과정

맥락:
- 회사의 전략 변경에 따라 제품 안정성과 팀 생산성 향상을 위한 기술 부채 청산을 과업으로 지시
- 챕터 구성원 투표를 통해 구체적인 과제와 우선순위를 결정
- 마침 목표 도메인에 Layered Architecture를 적용·검증하고 있었기에 해당 과제를 담당
해결해야 하는 문제:
- 개인·스쿼드별 코드 작성 패턴이 달라 코드 이해와 리뷰 비용 증가
- 좋은 코드에 대한 개인의 판단 기준이 일치하지 않아 의사결정에 긴 시간 소요

구성원들은 각자 다음 상황을 나쁘다고 인식함:
- 요구사항을 수용하지 못하는 기존 설계에 덧씌워진 코드로 복잡도 증가
- 역할을 알 수 없는 긴 코드로 작성된 구현체·파일
- UI를 그리는 데 적합하지 않은 데이터·타입 구조 설계
- 깊은 컴포넌트 트리와 Context API로 숨겨진 의존성
- 아무런 제약·판단 없이 다른 모듈을 가져와 사용하도록 구현체를 수정하는 행위
- 우발적 중복을 추상화하여 재사용하는 행위
다음 주제에 자신감이 낮은 구성원들이 많음 (답변마다 점수에 큰 편차를 보임):
- 확장성·재사용성을 확보한 컴포넌트 설계
- 비즈니스 로직 관리
팀 내에서 의견 충돌이 빈번한 키워드:
- 추상화, 응집·결합, 가독성
기타 분석 결과:
- 나쁜 코드가 일상적으로 생산·지속되는 상황으로 인해 과반수의 동료가 불편을 겪음
- 코딩 컨벤션은 업데이트가 늦고 코드베이스는 이미 다양한 패턴이 혼재되어 혼란스러움
- 일부 동료는 변화에 동의하지 않고 피드백을 개인의 선호로 받아들여 설득에 어려움을 겪음
- 업계에 알려진 문제 해결 사례를 팀의 코드베이스에 적용하는 데 어려움을 겪거나, 팀의 상황과 다르다고 단정하여 적용·검증 시도조차 못 함

현재 지속되는 의견 충돌은 해결 시도 없이 1년 이상 지속되었으므로 건강한 충돌이 아님
자신감 점수의 편차가 큰데도 갈등이 지속된다는 점은 오히려 높은 자신감을 가진 구성원들이 충돌을 일으킨다는 모순을 시사함
핵심 문제는 1명의 반대만으로도 합의에 이르지 못하고 개선을 시작할 수 없는 의사결정 구조 자체에 있음
그러나 동료가 납득하지 못한 규칙을 강제하기보다 저항 요인을 먼저 해소해야 하며, 강제성을 띄는 의사결정·실행 구조는 이를 보조하는 수단이어야 함
컴포넌트 설계와 비즈니스 로직 관리는 맥락에 따른 주관적인 판단이 필요한 영역으로, 코딩 컨벤션과 같은 규칙 모음만으로 완벽히 해소할 수 없음
코드 작성 패턴을 통일하는 것보다, 무의식적으로 반복되거나 좋은 코드로 오인되는 안티패턴을 차단하는 일이 시급함
동료들이 근거와 사례를 바탕으로 건강하게 의견을 나누고, 코드베이스 개선과 개발자로서의 성장을 지속할 수 있는 문화가 필요함