early-stage 마인드셋을 없애면서 관료주의를 만들지 않는 방법

Source: Dev.to

컨텍스트

제가 Monest에 기술 책임자(Head of Technology)로 들어갔을 때, 기술팀은 12명이었다. 1년 후 우리는 35명이 되었다. 이 성장 때문에 모든 것이 바뀐다: 12명으로 잘 돌아가던 프로세스가 35명에서는 그냥 부서진다. 문제는 아무도 즉시 깨닫지 못한다는 점이다; 팀은 같은 방식으로 계속 일하고, 무언가가 터질 때까지 기다린다. 변화를 시도하면 모든 기술 리더가 들어본 문구가 나온다: “하지만 언제나 이렇게 해왔잖아”.

어려운 점은 바꿔야 할 부분을 찾는 것이 아니라, 회사를 몇 주가 걸리는 배포 머신 같은 관료주의 조직으로 만들지 않고 변화를 이끄는 것이다. 스타트업은 속도로 살아간다; 프로세스를 과도하게 만들면 회사를 여기까지 오게 만든 것을 죽일 수 있다.

도입한 프로세스 예시

아래는 우리가 도입한 네 가지 구체적인 변화이며, 처음에는 마찰을 일으켰다:

1. 필수 End‑to‑end (e2e) 테스트

   • 이전에는 자동화 테스트가 없었고, 팀은 수동으로 테스트하거나 전혀 테스트하지 않았다.
   • 12명일 때는 모두가 시스템 전체를 알고 있었다.
   • 35명이 되니 아무도 전체 모습을 파악하지 못하므로 e2e 테스트를 필수로 만들었다.

2. 실제 TypeScript 타입 적용

   • 우리의 “TypeScript”는 .ts 확장자를 가진 JavaScript였으며, 모든 곳에 any를 사용했다.
   • 모두가 각 함수가 무엇을 기대하는지 알 때는 통했다.
   • 엄격한 타입을 도입했고, 6개월 만에 4 041개의 TypeScript 오류를 제거했다(자세한 내용은 해당 글에 있음).

3. 관측성(observability) 규칙화

   • 모든 서비스에 New Relic을 도입했다.
   • 이전에는 프로덕션 문제 발생 시 “탐정”이 로컬에서 오류를 재현해야 했다.
   • 이제는 정확히 무슨 일이 일었는지, 어디서, 왜 일었는지를 데이터로 파악한다.

4. RFC (Request for Comments) 도입

   • 이전에는 누군가 아이디어를 떠올리면 복도에서 얘기하고 바로 코딩을 시작했다.
   • 이제 새로운 기능은 최소한 무엇을, 왜, 어떻게 할지에 대한 문서를 반드시 작성해야 한다.
   • 문서는 길 필요가 없지만, 반드시 존재해야 한다.

모든 경우에 초기 반응은 동일했다: “하지만 전에는 필요 없었잖아”. 답변을 “이제는 내가 명령했으니까 필요해”로 할 수는 없다. 그렇게 하면 불만이 생긴다.

결과

이러한 변화를 1년간 적용한 뒤 우리의 지표는 다음과 같다:

• 지원 티켓 50 % 감소
• 포스트‑모템 36 % 감소 (Q4 vs Q1), 팀 규모는 거의 3배가 되었고 주당 80+ 배포를 수행했음에도 불구하고

“귀찮음”이 구체적인 성과를 만들었다는 것을 보여주면 대화는 달라진다.

새로운 프로세스 결정 방법

무엇을 도입할지 아는 것만큼, 어디서 멈출지도 아는 것이 중요하다. 우리가 따르는 몇 가지 가이드라인:

• e2e 테스트: 필수이지만 100 % 커버리지는 아니다.
• RFC: 새로운 기능에만 필수, 버그 수정에는 적용하지 않는다.
• 타입: 정확히 적용하되 점진적으로 마이그레이션한다.

새로운 프로세스를 만들기 전에 항상 스스로에게 묻는다:

“이게 팀이 더 잘 전달하도록 도와줄까, 아니면 단순히 일을 더 늘릴까?”

답이 “단순히 일을 더 늘린다”면 도입하지 않는다.

결론

성장은 고통스럽다. 이전에 통하던 것이 더 이상 통하지 않으며, 문제라고 인식되지 않는 것을 바꾸려면 사람들을 설득해야 한다. 균형은 회사를 보호하면서도 속도를 잡아먹지 않는 프로세스를 만드는 데 있다. 마법 같은 공식은 없으며, 시도와 오류, 그리고 결과에 대한 지속적인 관찰이 필요하다.