외주 프로젝트 관리 체계를 전용 레포로 정립한 과정

외주 검토 시스템을 위한 별도 레포를 만들고, 첫 프로젝트인 브랜드 홈페이지 컨셉을 이곳에 추가했다. 사실 이건 단순한 폴더 생성이 아니라 팀의 외주 프로젝트 관리 방식을 정립하는 작업이었다.

외주 프로젝트, 왜 별도 레포가 필요했나

회사가 어느 정도 규모가 되면 피할 수 없는 질문이 생긴다. "이 일은 내부에서 할 건가, 외주로 줄 건가?" 초기엔 모든 작업을 인하우스에서 처리했지만, 스펙이 명확하고 일정이 정해진 프로젝트들은 외부 파트너에게 검토받는 게 훨씬 효율적이다. 특히 브랜드 사이트처럼 일회성 성격이 강한 경우엔 더욱 그렇다.

다만 여기서 중요한 문제가 생긴다. 외주 문의가 들어올 때마다 어떻게 추적할 것인가? 메일로만 관리하다 보면 놓치는 게 생기고, 여러 파트너가 관여하면 커뮤니케이션이 꼬인다. 그래서 전용 레포를 만들기로 했다. 이곳이 외주 검토의 싱글 소스가 되는 거다.

파일 구조, 외주 프로세스를 담는 방식

초기 커밋에 포함된 파일들을 보면:

특히 흥미로운 건 문의.md, 분석.md, 지원서.md 같은 메타 문서들이다. 이들은 코드가 아니지만 프로젝트의 의사결정 흔적을 남긴다.

브랜드 홈페이지, 외주 판단의 사례

AX 아크릴 브랜드 홈페이지는 왜 외주 후보가 됐을까?

• 명확한 스펙: "브랜드 소개, 상품 갤러리, 연락처" 같은 기본 요소들이 뚜렷함
• 일회성: 한 번 만들면 유지보수는 최소화됨
• 인하우스 우선순위 제약: 팀은 핵심 서비스 개발에 집중해야 함
• 검증 리스크 낮음: 홈페이지는 코어 비즈니스 로직이 적음

반면 이렇게 외주를 주더라도 놓치면 안 되는 게 있다:

초기 사양 정의 → 설계 검토 → 개발 진행
      ↓              ↓            ↓
   왜 이걸 하나?   틀렸으면    중간에 수정
   명확해야 함    빨리 잡아야 함   비용 폭탄

분석.md와 문의.md는 이 초기 단계를 잘 기록하는 역할을 한다. 나중에 "아 그때 왜 이 방식을 선택했지?" 하는 순간이 반드시 온다. 그때 그 파일들이 의사결정 문맥을 복원해 준다.

팀 리딩 관점의 회고

이런 식으로 체계화하는 게 왜 중요한지 한두 가지 배웠다.

첫째, 외주는 "책임 넘기기"가 아니다. 오히려 더 강도 높은 검토가 필요하다. 내 팀이 직접 짜는 코드는 버그가 생기면 내가 책임지고 수정한다. 하지만 외주자 결과물은? 그들은 이미 다른 프로젝트로 넘어갔을 수도 있다. 그래서 초기 사양이 얼마나 명확한가가 생사를 가른다. 분석과 문의를 정밀하게 문서화하는 건 그 때문이다.

둘째, 일관성 있는 프로세스는 스케일을 만든다. 외주 문의가 월 1-2건일 때는 대충 해도 관리된다. 하지만 5건, 10건이 되면? 매번 다른 방식으로 하면 팀에서 번아웃이 생긴다. 정해진 형식(분석 → 문의 정리 → 지원서 수집 → 검토)이 있으면 새로운 외주자도 빨리 온보드 된다.

셋째, git으로 관리하는 의미. 슬랙 메시지나 이메일로 처리하면 나중에 찾을 수 없다. 하지만 git 레포면? 커밋 히스토리가 있고, 누가 언제 어떤 의견을 제시했는지 추적 가능하다. 분쟁 발생 시에도 "여기 문서에 명시돼 있습니다"라고 할 수 있다.

맨 처음 생각할 땐 "그냥 폴더 하나 더 만드는 건데?"였지만, 실제로는 팀의 의사결정을 투명하게 만드는 작은 인프라 투자였다. 다음 외주 건이 들어올 때 이 체계가 얼마나 편한지 실감할 거 같다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.