목적 조직 구조 안에서 개발팀이 일하는 법 | 인프콘2024

백엔드는 초기 API 스펙을 문서로 합의한 뒤 Swagger를 제공하고, 프론트엔드는 코드 생성과 MSW 모킹으로 실제 서버 구현을 기다리지 않고 개발한다. 2주 스프린트에서 디자인 지연이 UI와 QA 전체를 미는 문제는 디자이너가 여유 시간에 다음 스프린트 시안을 먼저 준비하는 구조로 완화했다. 요구사항이 바뀌는 불가피한 병목은 디자인 시스템과 Figma 연동을 고도화해 작업 속도 자체를 높이는 방식으로 줄였다.

구두로 결정한 내용을 전용 Slack 채널에 남겨 참석하지 못한 사람도 맥락과 변경 사항을 따라오고 별도 문서화 부담을 줄이게 한다. 기획 스프린트에는 개발자와 디자이너도 참여해 아직 정해지지 않은 동작과 정책을 함께 확정하며 제품 이해와 몰입도를 높인다. DRM처럼 기술 용어가 많은 과제는 회의 전에 배경 자료를 준비하고, 어려운 표현이 나온 순간 동료가 즉시 짚어 모두가 이해할 언어로 다시 설명한다.

여러 셀로 흩어진 개발자들은 주간 전체 모임에서 회사 목표와 장애 사례를 공유하고, 직군별 파트 모임에서는 느린 쿼리와 코드 기준을 더 깊게 논의한다. 역할의 선을 엄격히 긋기보다 개인 성과보다 팀의 성공을 먼저 돕고 사각지대의 일을 함께 메우는 태도가 협업을 강화한다. 전사 비전, 개발 조직과 파트의 정기적인 동기화에는 시간이 들지만 이후 반복 설득 비용을 줄여 전체 효율을 높인다.

전담 플랫폼 팀이 없어도 중복 코드를 발견하거나 새 기능이 필요한 사람이 제안·시제품을 만들고 동의를 얻어 공용 모듈에 기여하는 오픈소스형 운영을 택한다. 직접 구현의 커리어 욕구보다 일정 안에 회사 목표를 달성하는 효과가 크다면 검증된 오픈소스를 감싸 조직 환경에 맞추는 편을 선택한다. 전사 중요 과제에서 셀별 여력이 다르면 다른 셀이 일부 화면, 모니터링과 레거시 개선을 맡고 기존 기록과 직군 공유로 낯선 도메인의 학습 비용을 낮춘다.