12개월 안에 엔지니어링 팀을 두 배로 늘리면 코드 품질은 어떻게 변할까?

Source: Dev.to

Overview

빠른 채용 뒤에 나타나는 품질 저하 패턴 — 그리고 이를 방지하는 실천 방법.

12개월 안에 엔지니어링 팀을 두 배로 늘리는 것은 대부분의 기준에서 성공이라고 할 수 있습니다. 이는 제품이 제대로 작동하고, 비즈니스가 성장하고 있으며, 조직이 그 성장에 필요한 엔지니어링 역량에 투자할 자원을 가지고 있다는 의미입니다.

하지만 이는 특정 종류의 품질 저하를 가장 확실히 예측하는 지표이기도 합니다 — 새로운 엔지니어가 능력이 부족해서가 아니라, 급격한 성장이 품질을 유지하고, 전달하고, 강제하는 메커니즘에 부담을 주기 때문입니다.

이러한 저하는 급격하지 않습니다. 눈에 띄게 나타나지 않으며, 몇 달에 걸쳐 서서히 쌓입니다. 전체 맥락을 충분히 이해하지 못한 채 내린 아키텍처 결정, 일관되지 않게 채택된 관례, 원래 팀에 암묵적으로 존재했지만 같은 분기에 합류한 20명의 새로운 엔지니어에게 명확히 전달되지 못한 실천들이 그 예입니다.

컨텍스트 전이 문제

원래 엔지니어링 팀은 문서, ADR, 설계 문서에 명시되지 않은 많은 컨텍스트를 암묵적으로 가지고 있다 — 같은 코드베이스에서 수개월 동안 함께 일하면서 형성된 공유 이해이다.

• 인증 서비스가 현재와 같이 구조화된 이유를 알고 있다.
• 시스템의 어느 부분이 취약한지와 그 이유를 알고 있다.
• 문서화되지 않았지만 일관되게 따르는 관행을 알고 있다.
• 발생한 실수, 그 이유, 그리고 그로부터 배운 점을 알고 있다.

새로운 엔지니어들은 이 컨텍스트를 가지고 있지 않다. 12개월 동안 팀 규모가 두 배가 되는 경우, 성장 기간의 약 6개월 시점에 암묵적 컨텍스트를 가진 엔지니어보다 그렇지 않은 엔지니어가 더 많아지는 전환점이 존재한다.

그 시점에서 암묵적 컨텍스트는 사실상 사라진다. 팀이 더 이상 그것을 공유하지 않기 때문에 팀의 의사결정을 지배하지 못한다. 컨텍스트가 없는 상태에서 내려진 결정은 다른 결과를 초래한다.

먼저 사라지는 것

빠른 성장 속에서 처음으로 악화되는 것들은 품질과 가장 명백히 연관된 것들이 아니다. 테스트는 여전히 통과하고, 배포는 여전히 성공한다. 제품은 계속 작동한다.

먼저 악화되는 것은 아키텍처 일관성이다 — 구성 요소 사이 경계에서, 여러 접근 방식이 합리적이고 선택이 코드 자체에 포착되지 않은 맥락에 따라 달라지는 회색 영역에서 내린 결정의 품질을 말한다.

• 공유된 컨텍스트를 가진 팀은 시스템이 어떻게 보여야 하는지, 어떤 트레이드‑오프가 적절한지에 대한 암묵적인 모델을 공유하기 때문에 일관된 선택을 한다.
• 공유된 컨텍스트가 없는 팀은 일관되지 않은 선택을 한다 — 반드시 잘못된 것은 아니지만, 아키텍처가 어느 한 엔지니어에게도 일관되게 이해되기 어려울 정도로 분산된다.

두 번째로 악화되는 것은 코드 리뷰 품질이다. 코드 리뷰는 리뷰어가 기술적 정확성뿐만 아니라 아키텍처 정렬성을 평가할 수 있는 컨텍스트를 가질 때 효과적이다. 전체 컨텍스트를 갖지 않은 리뷰어의 비중이 커짐에 따라 코드 리뷰는 순수한 기술적 정확성에만 초점이 맞춰지고, 아키텍처 일관성은 멀어진다.

성장으로 인한 문서 부채

성장하는 팀은 두 가지 방식으로 문서 부채를 생성합니다.

1. Obvious debt: 급속한 성장은 문서 작성 시간을 줄이고, 기존 문서는 코드베이스의 실제 상황보다 더 뒤처지게 됩니다.
2. Hidden debt: 원래 팀이 가지고 있었지만 문서화하지 않은 암묵적인 컨텍스트가 팀이 성장함에 따라 접근할 수 없게 됩니다. 이 지식은 지속 가능한 형태로 인코딩되지 않았습니다.

이 부채를 해결하려면 원래 팀이 이전에 암묵적으로 전달했던 내용을 명시적으로 표현해야 합니다 — 즉, 결정, 관례, 이유, 그리고 한때 당연히 여겼던 컨텍스트를 기록하는 것입니다. 이 작업은 어렵고 시간도 많이 소요되며, 배달 약속과 직접 경쟁합니다.

급속한 성장을 가장 성공적으로 헤쳐 나가는 팀은 이 문서 작업에 초기에 투자합니다 — 암묵적인 컨텍스트가 회복 불가능하게 희석되기 전에 — 그리고 이를 성장의 전제 조건으로 여기며 사후 수정이 아니라는 점을 강조합니다.

성장 속에서도 품질을 유지하는 실천법

• 코드 커버리지 메트릭은 아키텍처 일관성을 방지하지 못합니다.
• 린팅 규칙은 암묵적인 컨텍스트를 보존하지 못합니다.
• 필수 코드 리뷰는 컨텍스트가 부족한 리뷰어에게 아키텍처 판단을 전달하지 못합니다.

효과적인 실천은 암묵적인 컨텍스트를 명시적으로 만드는 것입니다:

• Architecture Decision Records (ADRs) — 중요한 아키텍처 결정이 내려진 이유, 고려된 대안, 그리고 선택을 좌우한 컨텍스트를 포착하는 간결하고 구조화된 문서입니다. 이는 전달 속도를 크게 늦추지 않는 높은 가치의 투자입니다.
• Engineering principles documents — 팀이 일관되게 내리는 트레이드오프와 따르는 규칙을 명시적으로 서술한 문서입니다. 이는 새로운 엔지니어가 자신의 결정을 조정할 수 있는 공유 기준점으로 작용합니다.
• Regular architecture reviews — 결정이 의도된 방향과 일치하는지에 대한 구조화된 대화로, 일관성 문제가 아키텍처 부채로 쌓이기 전에 드러낼 수 있는 장을 제공합니다.

일관성 및 조기 감지

이러한 실천은 결정이 팀의 아키텍처 방향과 일관되도록 보장하고, 차이를 조기에 감지할 수 있게 합니다.

이러한 실천들은 전용 품질‑엔지니어링 프로그램이나 큰 프로세스 투자를 필요로 하지 않습니다.
이는 팀의 가장 경험 많은 엔지니어가 현재 암묵적으로 알고 있는 것을 명시적으로 만들기 위해 시간을 투자해야 함을 의미합니다 — 그 지식이 사라지기 전에.

WiseAccelerate 엔지니어는 모든 참여에 전체 컨텍스트를 가지고 들어가며, 성장하는 팀이 성장 속에서도 품질을 유지하기 위해 필요한 문서화와 아키텍처 명확성에 기여합니다.

프롬프트

팀이 규모가 커져 그 부재가 고통스러워지기 전에 미리 도입했으면 좋았을 품질 실천은 무엇인가요?