30일 만에 전담 개발 팀을 구성하는 방법

소개

대부분의 아웃소싱 계약은 첫 해가 아니라 첫 달에 실패합니다. 엔지니어들의 역량은 충분하고 비용도 적정하지만, 팀은 몇 주 동안 업무에 필요한 접근 권한이나 배경 정보, 명확한 우선순위조차 없이 시간을 보냅니다. 실제 업무가 시작될 무렵이면, 고객사는 이미 이 모델에 대한 신뢰를 잃은 상태입니다.

고객사가 미리 준비한다면 전담 개발 팀은 30일 이내에 완전한 생산성을 달성할 수 있습니다. 공급업체가 채용과 고용을 담당하지만, 제품, 코드베이스, 비즈니스 목표를 설명할 수 있는 것은 오직 고객사뿐입니다. 온보딩은 공동 프로젝트이며, 지식 전달의 대부분은 고객사 측에서 담당합니다.

첫날 전: 준비해야 할 사항

시작일 일주일 전이 팀의 진행 속도를 결정합니다. 리포지토리 접근 권한을 3일이나 기다려야 하는 엔지니어들은 추진력을 잃게 되며, 이러한 지연은 전체 프로젝트의 분위기를 좌우합니다.

준비 작업에는 클라이언트 측에서 몇 시간 정도가 소요됩니다. 대부분은 행정적인 업무이며, 한 사람이 전체 목록을 전담할 수 있습니다.

• 접근 권한 및 계정. 코드 저장소, 작업 관리 도구, 클라우드 콘솔, 커뮤니케이션 채널에 대한 계정을 생성하십시오. 시작일 전에 각 로그인을 테스트하십시오.
• 기술 문서. 아키텍처 다이어그램, API 설명서, 설정 가이드를 한곳에 모아 두십시오. 변경된 부분을 누군가가 표시해 두었다면, 구버전 문서도 사용 가능합니다.
• 담당자. 업무일 기준 1일 이내에 질문에 답변해 줄 클라이언트 측 담당자 한 명을 지정하십시오. 이 담당자는 대개 기술 리더나 제품 소유자입니다.
• 초기 백로그. 난이도가 낮거나 중간 수준인 작업 10~15개를 준비하세요. 팀은 프로덕션에 위험을 주지 않으면서 코드베이스를 익힐 수 있는 작업이 필요합니다.

1주차: 접근 권한, 배경 이해, 첫 번째 과제

첫 주는 오리엔테이션에 중점을 둡니다. 팀은 제품의 기능, 사용자층, 코드 구조를 파악합니다.

이 주의 산출물은 의도적으로 소량으로 설정됩니다. 목표는 기능 출시가 아니라, 작업 환경 구축과 첫 번째 병합된 변경 사항입니다.

1~2일차: 환경 설정

첫날, 클라이언트는 킥오프 회의를 진행합니다. 제품 소유자는 비즈니스 모델, 주요 사용자 그룹, 그리고 현재 우선순위를 설명합니다. 기술 책임자는 아키텍처와 배포 과정을 상세히 안내합니다.

회의가 끝난 후, 엔지니어들은 로컬 환경을 설정하고 애플리케이션을 실행합니다. 대부분의 설정 문제는 이 단계에서 발생하므로, 클라이언트 담당자는 신속한 답변을 제공할 수 있도록 대기해야 합니다.

3~5일차: 첫 번째 소규모 작업

각 엔지니어는 초기 백로그에서 한두 가지 작업을 맡습니다. 이 단계에서는 버그 수정, 소규모 UI 변경, 테스트 커버리지 작업이 적합합니다. 실제 코드를 다루지만 위험 부담은 낮습니다.

모든 작업은 코드 검토, 테스트, 배포의 전체 주기를 거칩니다. 이를 통해 팀은 클라이언트의 업무 방식을 파악하고 프로세스상의 문제점을 조기에 발견할 수 있습니다.

2주차: 프로세스 및 소통 리듬

두 번째 주에는 팀이 개별 작업에서 팀 단위의 일상 업무로 전환합니다. 고객사와 공급업체는 업무 계획, 논의, 보고 방식에 대해 합의합니다.

분산된 팀은 한 장소에 모여 있는 팀보다 더 체계적인 구조가 필요합니다. 시간대와 문화적 차이로 인해 비공식적인 의사소통이 어려워지므로, 의사소통의 리듬을 명확히 정해야 합니다.

• 데일리 스탠드업. 두 시간대가 겹치는 시간에 짧은 화상 회의를 진행하십시오. 진행 상황과 장애 요인을 공유하는 데 15분이면 충분합니다.
• 스프린트 계획. 1~2주 단위의 스프린트로 작업을 계획하십시오. 클라이언트 측 제품 소유자가 우선순위를 정하고, 팀이 소요 공수를 추정합니다.
• 코드 리뷰 규칙. 누가 무엇을, 얼마나 빨리 검토할지 합의하세요. 리뷰가 하루 이상 지연되면 팀 전체의 작업 속도가 느려집니다.
• 서면 업데이트. 공유 채널에 매주 간략한 요약 보고를 요청하세요. 이를 통해 추가 회의 없이도 이해관계자들이 상황을 파악할 수 있습니다.
• 에스컬레이션 절차. 각 측에서 장애 요인을 해결할 담당자를 명확히 정의하세요. 벤더 담당자는 팀 관련 문제를, 클라이언트 담당자는 제품 관련 질문을 처리합니다.

3~4주 차: 주인의식과 성과 측정

마지막 2주 동안은 온보딩이 제대로 이루어졌는지 검증합니다. 팀은 실질적인 책임을 지게 되며, 양측은 명확한 기준에 따라 결과를 검토합니다.

이 단계에서는 프로세스에서 여전히 조정이 필요한 부분이 드러납니다. 사소한 문제는 90일 차보다 25일 차에 해결하는 것이 더 쉽습니다.

실제 기능 인계

3주차에는 제품 로드맵에 포함된 완성된 기능 하나를 팀에 배정합니다. 이 기능은 디자인 결정이 필요하고, 코드베이스의 여러 부분을 아우르며, 프로덕션 릴리스가 수반되어야 합니다.

개발이 시작되기 전에 클라이언트 측 기술 책임자가 기술적 접근 방식을 검토합니다. 그 후, 팀은 견적 산출부터 배포에 이르기까지 작업 전반을 주도합니다. 이 단계에서 지나치게 세밀하게 감독하는 것은 본래의 취지를 무색하게 만듭니다.

30일 차에 추적해야 할 지표

월말에 공급업체와 검토 회의를 진행합니다. 결과를 1주차에 설정한 기대치와 비교하고, 가능한 경우 수치를 활용하십시오.

• 전달 속도. 지난 두 번의 스프린트에 걸쳐 계획된 스토리 포인트와 완료된 스토리 포인트를 비교하세요. 높은 속도보다 안정적인 속도가 더 중요합니다.
• 코드 품질. 1차 또는 2차 검토에서 통과한 풀 리퀘스트의 비율을 확인하세요. 잦은 재작업은 맥락 파악에 미흡함을 시사합니다.
• 질문 빈도. 엔지니어들이 클라이언트에게 도움을 요청하는 빈도를 추적하세요. 이 수치는 매주 감소해야 합니다.
• 이해관계자의 피드백. 제품 소유자와 기술 책임자에게 간단한 평가를 요청하세요. 그들의 관점은 지표로는 파악되지 않는 문제점을 드러내는 경우가 많습니다.

흔히 저지르는 온보딩 실수

대부분의 온보딩 지연은 몇 가지 공통된 원인으로 발생합니다. 각 원인이 처음에는 사소해 보이기 때문에 기업들은 이러한 실수를 반복하게 됩니다.

• 접근 지연. 3일 차에야 계정이 제공되면 팀은 3일분의 시간을 낭비하게 됩니다. 보안 승인은 예상보다 오래 걸리는 경우가 많으므로, 일찍 절차를 시작하십시오.
• 제품 맥락 부재. 사용자를 이해하지 못하는 엔지니어는 기술적으로는 정확하지만 실제로는 쓸모없는 결정을 내립니다. 1시간의 제품 설명은 몇 주에 걸친 재작업 시간을 절약해 줍니다.
• 담당자가 너무 많음. 5명이 지시를 내리면 우선순위가 충돌합니다. 의사결정권자를 한 명으로 정하면 방향성이 명확해집니다.
• 팀을 외부인으로 취급하는 것. 별도의 소통 채널과 제한된 회의는 이중 구조를 만들어 냅니다. 클라이언트의 일상 업무에 자연스럽게 녹아드는 팀이 더 빠르게 적응합니다.

마무리

30일이면 전담 팀이 완전한 생산성을 발휘하기에 충분합니다. 결과는 공급업체에 달려 있기보다는, 클라이언트가 접근 권한, 배경 정보, 명확한 우선순위를 얼마나 잘 준비하느냐에 더 크게 좌우됩니다.

온보딩을 책임자, 마감일, 최종 검토가 있는 하나의 프로젝트로 취급하십시오. 체계적으로 구성된 첫 달은 장기적인 협력 관계에 필요한 신뢰를 쌓아줍니다.