[DDM Vol.2] 실용주의 프로그래밍, 데이터라이즈 BE가 선택한 길

 DDM(Datarize Dev Meetup) 두 번째 세션에서는 BE(Back-End) 챕터 리드 이인표님이 발표했습니다.

주제는 다소 가볍지만 스타트업이라면 반드시 맞닥뜨릴 수밖에 없는 질문, “실용주의 프로그래밍이란 무엇인가?”였습니다. 이 발표는 데이터라이즈가 시리즈 A부터 B까지 성장하는 과정에서 어떤 선택을 했고, 어떻게 개발 문화를 다져왔는지를 돌아보는 시간이었습니다.

왜 실용주의인가?

스타트업의 개발 환경은 언제나 빠듯합니다.
개발자가 ‘사치스럽게’ 시간을 들여 완벽한 구조를 설계하기보다는, 그때그때 가장 실용적인 선택을 해야 하는 상황이 반복됩니다.
데이터라이즈가 주목한 실용주의의 핵심 키워드는 두 가지였습니다.

• 커뮤니케이션
• 가역성(언제든 바꿀 수 있는 코드)

문제를 정확히 보는 법

많은 장애와 일정 지연은 ‘요구사항을 정확히 이해하지 못한 것’에서 비롯됩니다. 데이터라이즈는 이를 해결하기 위해 다양한 도구를 적극적으로 활용했습니다.

• 이벤트 스토밍(Event Storming): 사용자 행동과 도메인 이벤트를 포스트잇으로 붙여 모델링. 숨어 있던 갈등 요소나 정책을 빠르게 발견할 수 있음.
• ATDD(인수 테스트 주도 개발): 프로젝트 시작 전에 모든 구성원이 모여 수용 조건을 테스트 케이스로 정의. 스프레드시트 같은 익숙한 도구로 TC를 관리하여 배포 불안을 줄임.

이 과정을 통해 발굴된 유저 스토리는 Jira 스토리와 스프린트 계획에 그대로 반영되었습니다.

팀 커뮤니케이션을 가볍게

커뮤니케이션 비용을 줄이는 것도 실용주의의 핵심입니다.

• 엔지니어링 일지: Tech Spec과 ADR(Architecture Decision Record)을 남겨, 특정인의 기억에 의존하지 않고 맥락을 관리. 코드 리뷰 비용도 줄고, 책임이 개인이 아닌 팀에 분산됨.

• 유니캐스트 지향: 그룹 멘션 대신 한 사람을 명확히 지정해 리뷰와 논의를 요청. 원격·비동기 환경에서 지연을 최소화함.

• 컨벤션 관리자: 인원이 늘면서 발생하는 사일로를 방지하기 위해 각 프로젝트에서 한 명씩 선발. 컨벤션과 아키텍처 표준을 관리하고 팀 간 일관성을 유지.

설계를 단단하게

‘방어적 프로그래밍’ 대신 계약에 의한 설계(Design by Contract, DBC)를 도입했습니다.

• 메서드가 호출되기 전 반드시 만족해야 할 선행 조건을 정의
• 조건이 충족되지 않으면 가능한 빨리 코드 실행을 중단

예를 들어, 메시지 발송 시스템에서는 새벽 배치가 정상 완료되지 않으면 아예 발송 프로세스를 시작하지 않도록 계약을 설정했습니다. 덕분에 장애가 발생했을 때 복구 비용을 크게 줄일 수 있었습니다.

TDA의 정의

또한 TDA(Tell, Don’t Ask) 원칙을 적용해 객체 간 결합도를 낮추고, 책임을 명확히 분리했습니다. 다만 캡슐화가 과도하면 디버깅이 어려워지므로, 호출 깊이를 제한하는 등 현실적인 보완책도 함께 마련했습니다.

가역성 유지하기

실용주의 프로그래밍의 마지막 키워드는 가역성입니다. 언제든 코드를 바꿀 수 있으려면 테스트가 필수입니다.

• 데이터라이즈 백엔드팀은 서비스별 90% 이상의 테스트 커버리지를 유지

• 고전파(상태 기반 검증)와 런던파(행위 기반 검증)를 혼용해 효율 극대화
• 무거운 테스트 환경은 런던파로 개선, 트랜잭션 검증은 고전파로 유지

이 덕분에 신규 입사자도 입사 후 2~3주 내 첫 코드 기여를 경험할 수 있었습니다. 테스트 환경이 팀 전체의 진입 장벽을 낮춘 셈입니다.

에필로그: 성장하는 카오스 속에서

발표의 마지막은 인상적인 한 문장으로 마무리되었습니다.

“카오스가 있는 곳에 성장이 있습니다.”

실용주의는 완벽한 시스템을 꿈꾸는 것이 아닙니다. 실패를 전제로 하고, 문제를 빠르게 식별하고, 다시 고칠 수 있는 구조를 만드는 것. 스타트업처럼 성장 속도가 빠른 환경에서야말로 실용주의는 빛을 발합니다.

데이터라이즈 BE 챕터는 앞으로도 실용적인 결정들을 통해 비즈니스 성장을 뒷받침하며, 더 단단하고 유연한 시스템을 만들어갈 예정입니다.