신규 웹 서비스 백엔드 설계 가이드 (권남)

Source

이 문서는 신규 웹 서비스 개발 시 고려해야 할 백엔드 아키텍처 및 개발 관행에 대한 경험 기반 가이드입니다. 주요 내용은 다음과 같습니다:

프로그래밍 언어 선택: 초기 개발 속도는 중요하지만, 장기적인 유지보수와 확장성을 위해 정적 타입 언어를 선호합니다. 개발자 풀이 좁은 언어는 채용 및 유지보수 리스크가 크므로 지양해야 합니다.
용어 통일: 팀 내외 소통 및 코드 일관성을 위해 프로젝트 초기에 한국어/영어 용어와 정의를 문서화하여 공유해야 합니다.
지식 공유 및 의존성 관리: 핵심 비즈니스 로직이 아닌 영역(예: 배포 시스템)에 특정 개인(영웅)에 대한 의존성을 두지 않아야 합니다. 또한 런타임 패치(Monkey Patch)는 금지하며, 오픈소스 수정은 공식적으로 반영해야 합니다.
모듈화 및 아키텍처: 스타트업 초기부터 마이크로서비스(MSA)를 도입하는 것은 비효율적이지만, 도메인별 모듈화(Product, Order 등)는 필수적입니다. 도메인 간 공통 비즈니스 로직을 담은 ‘공통 모듈’은 금지하며, Interface 기반 개발을 통해 약한 결합도와 높은 응집도를 유지해야 합니다.
계층 분리: 의존성 역전 원칙을 준수하여 하위 계층이 상위 계층(Web Layer 등)에 의존하지 않도록 해야 합니다.
MSA 전환 시점: 개발자 간 충돌 증가, 빌드/배포 시간 과다로 생산성이 떨어질 때 MSA 전환을 고려하며, 이때는 공통 라이브러리보다 공통 규약 정립을 우선시합니다.

정적 타입 언어 선호: 장기적인 리팩토링 및 버그 방지를 위해 동적 언어보다 정적 언어를 권장함.
용어 사전화: 프로젝트 시작 시 한국어/영어 용어 및 정의를 문서화하여 팀 전체에 공유해야 함.
단일 장애점(SPOF) 방지: 배포 시스템 등 핵심 인프라에 특정 개인의 지식에만 의존하는 구조 금지.
Monkey Patch 금지: 런타임 패치 금지 및 오픈소스 수정 시 공식 기여 권장.
도메인 모듈화: 초기부터 도메인별(Product, Order 등) 모듈 분리 권장. 도메인 로직을 포함한 ‘공통 비즈니스 모듈’ 생성 금지.
Interface 기반 설계: 구현체와 인터페이스 분리하여 결합도 낮추고 응집도 높임. 향후 MSA 전환 시 최소한의 변경으로 확장 가능.
계층 의존성 관리: 하위 계층이 상위 계층에 의존하지 않도록 함 (의존성 방향: Web -> Service -> Repository -> Domain).
MSA 도입 시기: 모노리식이 관리 불가능해질 때(충돌 증가, 빌드 지연 등) 전환. 공통 라이브러리보다 공통 규약(API Contract) 정립 우선.