1 팀 규모와 역량
기술 선택에서 가장 먼저 평가해야 할 것은 팀의 규모와 기술적 역량이다. 소규모 팀(한 명일 수도 있다)에서 여러 역할을 겸하는가, 아니면 전문 역할로 분화된 대규모 팀인가? 소수가 수명주기의 여러 단계를 담당하는가, 아니면 각 니치를 전담하는가?
1.1 카고 컬트 엔지니어링
교재가 경고하는 가장 흔한 실수는 카고 컬트 엔지니어링(cargo-cult engineering)이다.
대형 기술 기업의 블로그에서 읽은 최첨단 기술을 맥락 없이 모방하는 행위. 팀 규모, 데이터 볼륨, 조직 성숙도가 전혀 다른 환경에서 동일한 기술을 도입하려는 것이 전형적 패턴이다. (Reis, 2022, Ch.4)
5명짜리 데이터 팀이 Netflix의 실시간 추천 아키텍처를 모방한다고 가정하자. Kafka, Flink, 커스텀 ML 파이프라인을 구축하는 데 6개월을 투자하지만, 정작 비즈니스가 필요한 것은 일일 배치 대시보드였다. 6개월 동안 비즈니스 가치는 제로(zero)이고, 팀은 인프라 유지에 매몰된다. 같은 기간에 관리형 서비스(BigQuery + dbt + Looker)로 대시보드를 2주 만에 구축했다면, 나머지 5.5개월은 비즈니스에 직접 가치를 더하는 분석에 쓸 수 있었다.
1.2 기술 복잡도와 팀 대역폭
단순한 기술부터 복잡한 기술까지의 연속선(continuum)에서, 팀의 규모가 복잡한 솔루션에 투입할 수 있는 대역폭을 대략적으로 결정한다.
| 팀 규모 | 권장 전략 | 이유 |
|---|---|---|
| 소규모 (1~3명) | 관리형 서비스, SaaS 최대 활용 | 한정된 대역폭을 비즈니스 가치에 집중 |
| 중규모 (4~10명) | 관리형 서비스 + 일부 커스텀 | 핵심 영역에서 차별화 가능 |
| 대규모 (10명+) | 커스텀 구축 가능, 단 정당화 필요 | 자원은 있지만 기회비용은 여전히 존재 |
1.3 기술 스킬 인벤토리
팀의 스킬을 인벤토리하라. 로우코드 도구를 선호하는가, 코드 우선 접근법을 선호하는가? Java, Python, Go 중 어떤 언어에 강한가? 로우코드부터 코드 중심까지의 모든 선호도에 맞는 기술이 존재한다.
교재의 조언: 팀이 이미 익숙한 기술과 워크플로를 고수하라. 빛나는 새 기술을 배우는 데 많은 시간을 투자하고도 프로덕션에서 사용하지 않는 경우를 교재는 여러 번 목격했다. 새 기술·언어·도구를 배우는 것은 상당한 시간 투자이므로, 이 투자를 현명하게 하라.
2 시장 속도
기술에서는 시장 속도가 승리한다(speed to market wins). 이것은 높은 품질 표준과 보안을 유지하면서 기능과 데이터를 더 빠르게 전달하는 올바른 기술을 선택하는 것을 의미한다. 또한 출시 → 학습 → 반복 → 개선의 빠른 피드백 루프 안에서 작업하는 것을 의미한다.
2.1 완벽은 좋음의 적이다
“완벽은 좋음의 적이다(Perfect is the enemy of good).” 기술 선택에 수개월~수년을 고민하며 아무 결정도 내리지 않는 팀은 해산의 위기에 처한다. 느린 결정과 산출물은 데이터 팀에게 사형 선고이다. (Reis, 2022, Ch.4)
교재는 너무 느리게 움직이고 고용된 가치를 전달하지 못해 해산된 데이터 팀을 여러 차례 목격했다고 밝힌다. 이것은 기술적 실패가 아니라 조직적 실패이다. 기술 선택의 완벽주의가 가치 전달의 부재로 이어지고, 그것이 팀의 존재 근거를 훼손한다.
2.2 가치를 일찍, 자주 전달하라
교재의 세 가지 행동 지침:
| 지침 | 의미 | 직관 |
|---|---|---|
| 작동하는 것을 사용하라 | 팀이 이미 아는 도구가 더 큰 레버리지를 준다 | 새 도구 학습 시간 = 가치 미전달 시간 |
| 차별화되지 않는 무거운 작업을 피하라 | 비즈니스 가치를 거의 더하지 않는 불필요한 복잡 작업 회피 | 자체 DB 커넥터 구축 vs 기성품 사용 |
| 빠르고 안정적이고 안전한 도구를 선택하라 | 속도, 신뢰성, 보안의 세 축 모두 충족 | 하나를 위해 다른 둘을 희생하지 마라 |
2.3 팀 규모와 속도의 상호작용
팀 규모와 시장 속도는 밀접하게 연결된다. 소규모 팀이 빠르게 움직이려면 관리형 서비스가 필수이고, 대규모 팀이라도 가치 전달 속도를 위해 “차별화되지 않는 무거운 작업(undifferentiated heavy lifting)”을 최소화해야 한다.
“차별화되지 않는 무거운 작업”이란 비즈니스 경쟁 우위에 기여하지 않지만 반드시 해야 하는 인프라·운영 작업이다. DB 커넥터를 직접 코딩하는 것, Hadoop 클러스터의 노드를 교체하는 것, 의존성 충돌을 디버깅하는 것이 여기에 해당한다. 이런 작업에 시간을 쓸수록 비즈니스에 직접 가치를 더하는 작업에 쓸 시간이 줄어든다.
3 핵심 요약
§4.1~4.2의 핵심을 세 문장으로 요약하면 다음과 같다.
첫째, 팀 규모가 기술 복잡도의 상한을 결정한다. 소규모 팀은 관리형 서비스를 최대한 활용하고, 비즈니스에 직접 가치를 더하는 문제에 대역폭을 집중해야 한다.
둘째, 시장 속도는 데이터 팀의 존속 조건이다. 기술 선택의 완벽주의가 가치 전달을 지연시키면, 팀의 존재 근거 자체가 사라진다.
셋째, 이 두 고려사항은 같은 방향을 가리킨다: 추상화를 수용하고, 이미 작동하는 것을 사용하고, 차별화되지 않는 무거운 작업을 피하라.
4 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.4 §4.1-4.2.