엔지니어링 전략은 로드맵이 아니라, 뭘 안 할지 정하는 필터임

전략은 멋진 문장이 아니라 선택의 기술임

• 글의 출발점은 단순함. 엔지니어링 전략은 비전 문구, 분기 로드맵, 긴 위시리스트가 아님

  • 저자는 전략을 “다 할 수 없을 때 진짜 중요한 걸 고르는 일”로 정의함
  • 좋은 아이디어가 많을수록 전략이 더 필요함. 전략은 팀이 어디에 힘을 주고, 어디를 미루고, 무엇을 무시할지 정하는 필터임
  • 전략이 없으면 코드도 많이 쓰고 회의도 많이 하는데, 정작 회사나 조직이 앞으로 나아가진 않음

• 좋은 전략의 뼈대는 Richard Rumelt의 Good Strategy/Bad Strategy에서 가져옴

  • 핵심 문제를 진단하고, 그 문제를 다룰 가이드 정책을 세우고, 서로 맞물리는 실행을 붙이는 구조임
  • 반대로 나쁜 전략은 멋진 단어와 큰 포부는 있는데, 다음 주에 뭘 해야 하는지 아무도 모르는 상태임
  • “우리는 더 데이터 기반 조직이 된다” 같은 말은 방향처럼 들리지만, 실제 병목을 찌르지 못하면 그냥 슬로건임

사용자 식별 문제로 보는 좋은 전략과 나쁜 전략

• 좋은 전략 예시는 여러 브랜드와 앱에 흩어진 사용자 식별 문제임

  • 사용자가 앱과 웹사이트를 오가는데 각 플랫폼이 사용자를 서로 다른 사람처럼 취급함
  • 공통 사용자 관점이 없으니 개인화도 안 되고, 전체 여정 분석도 안 되고, 리포팅도 흔들림
  • 진짜 진단은 “사용자를 시스템 전체에서 안정적으로 식별할 수 없다”는 것임

• 이 경우 가이드 정책은 “먼저 identity를 고친다”가 됨

  • 각 브랜드가 자기 방식으로 해결하게 두지 않고, 모든 플랫폼이 부를 수 있는 단일 사용자 ID 기준을 만듦
  • 이벤트도 그 ID 기준으로 표준화해서 사용자 여정을 연결함
  • 중복 ID는 병합하고, 통합 데이터를 개인화·마케팅·리포팅에 공급함

• 나쁜 전략은 같은 문제를 더 화려하게 망치는 방식임
  • “모든 브랜드가 더 데이터 기반으로 움직인다”는 목표를 세우고, 각 팀이 자기 분석 파이프라인을 만들게 함
  • 겉으로는 빠르게 움직이는 것처럼 보이지만, 사용자 ID가 연결되지 않아서 같은 사용자가 다섯 명처럼 보임
  • 결과적으로 대시보드는 많아지는데 숫자는 맞지 않고, 팀은 추적 시스템 유지보수에 시간을 태움

계획은 전략을 실제 작업으로 바꾸는 단계임

• 저자는 계획을 세 가지 정책으로 쪼갬. 결과 명확화, 리소스 배분, 의사결정 원칙임

  • “성능 개선”은 목표가 아님. “6개월 안에 API latency를 50% 줄여 파트너 이탈을 막는다”처럼 측정 가능해야 함
  • 결과가 테스트 가능하게 쓰여 있지 않으면 인력을 붙이지 않는다는 기준을 둠
  • 계획이 못하면 스프레드시트에 적힌 거짓 약속이 되고, 실제 프로덕션으로 이어지지 않음

• 20명 엔지니어 조직 예시는 꽤 구체적임

  • Identity 팀 6명은 core identity service를 맡고, 30ms 안에 고유 ID로 해석되는 요청 비율을 KPI로 둠
  • Data 팀 7명은 이벤트 수집, 검증, 백엔드 처리를 맡고, 오류 없이 캡처·검증·전달된 이벤트 비율을 봄
  • Platform 팀 7명은 인프라와 신뢰성, 성능을 맡고, 핵심 서비스 uptime과 전체 스택의 p95 latency를 책임짐

• 요청이 계속 들어오는 상황에서는 의사결정 원칙이 필요함

  • 영업 요청, 새 기능 제안, 멋져 보이는 기술 도입, 채용 요청은 끝없이 들어옴
  • 저자의 기준은 최상위 3개 우선순위에 묶이거나, 신뢰성을 올리거나, 장기 우위를 쌓는 일만 받는 것임
  • 나머지는 다음 사이클까지 기다림. 이 선이 없으면 모든 요청이 싸움거리가 됨

30개월짜리 실행 순서도 전략의 일부임

• identity 예시는 한 번에 끝낼 수 없으니 단계로 나눔

  • 0~6개월은 core identity service를 만들고 저장소와 latency 목표를 잡음. 분석 기능은 기다림
  • 6~12개월은 이벤트 캡처와 스키마 표준화, 안정적인 파이프를 만듦
  • 12~18개월은 처리 파이프라인과 접근 계층을 만들고, 진짜 data engineering 팀을 구성함
  • 18~24개월은 작은 ML 팀을 만들어 개인화 첫 모델과 feature pipeline을 제공함
  • 24~30개월은 글로벌 신뢰성, 개발자 경험, 플랫폼·데이터·ML 소유권 정리에 집중함

• 프로젝트 선택은 unblocker, risk reducer, value driver, nice-to-have 순으로 정렬함

  • 데이터베이스와 API처럼 없으면 아무것도 못 하는 일은 unblocker임
  • KPI, 모니터링, 검증처럼 나중의 고통을 줄이는 일은 risk reducer임
  • 대시보드나 파일럿 연동처럼 비즈니스 가치가 보이는 일은 value driver임
  • 그 외는 nice-to-have로 밀림

• 이 기준이 없으면 조직은 빠른 성과처럼 보이는 일에 끌려감

  • 예를 들어 어떤 팀이 새 identity service에 자기 스키마로 빨리 붙어서 임원용 대시보드를 만들고 싶어 할 수 있음
  • 하지만 공통 검증과 표준 스키마가 없으면 데이터는 조각나고, 대시보드는 그럴듯하지만 틀린 이야기를 함
  • 그래서 초반 프로젝트는 shared schema, validation, monitoring 같은 기반 작업이어야 함

실행 관리는 약속이 아니라 증거를 보는 일임

• 프로젝트 크기는 1~2개월 안에 만질 수 있는 결과를 내는 수준이어야 함

  • 한 팀이 end-to-end로 소유할 수 있어야 하고, 두 팀이 필요하면 너무 큰 프로젝트라 쪼개야 함
  • 시간 단위 추정에 집착하기보다 숨은 의존성을 드러낼 만큼만 자세하면 됨
  • 이렇게 쪼개면 미끄러져도 몇 주 단위로 미끄러지지, 몇 년짜리 실패가 되진 않음

• 중단 상황에 대한 정책도 명확함

  • 신뢰성이나 보안을 위협하면 즉시 우선순위를 올림
  • 최상위 전략과 맞으면 다시 정렬해서 앞당길 수 있음
  • 둘 다 아니면 다음 사이클까지 기다림
  • 현실적으로 임원 요청 때문에 한두 개를 밀어 넣어야 할 때도 있다는 점은 인정함. 다만 그걸 원칙 없는 흔들림으로 만들지 않는 게 중요함

• 실행 추적은 팀 단위 KPI, 체크포인트, 시각화, 조정으로 굴러감

  • 6개월짜리 단계를 1~2개월 산출물로 쪼개고, 각 체크포인트에서 실제 결과가 목표를 냈는지 확인함
  • 대시보드, 주간 요약, 초록·노랑·빨강 신호등 같은 단순한 시각화도 drift를 빨리 잡는 데 쓸 수 있음
  • 계획은 항상 틀어지므로 2~4주마다 확인하고 다시 정렬해야 함

• 마지막으로 전략은 리더 머릿속에 있으면 없는 거나 마찬가지임

  • 문서화되지 않은 전략은 존재하지 않는다고 봐야 함
  • 모든 매니저는 자기 팀 일이 전략과 어떻게 연결되는지 설명할 수 있어야 함
  • 인접 팀의 피드백이 다시 계획에 들어오지 않으면, 현장 마찰은 조용히 쌓이고 계획은 현실에서 멀어짐

---

기술 맥락

• 이 글의 핵심 선택은 “좋은 아이디어를 많이 모으는 것”이 아니라 “공통 identity부터 고치는 것”이에요. 왜냐면 사용자 식별이 깨진 상태에서는 대시보드, 개인화, 머신러닝이 전부 서로 다른 데이터를 보고 움직이게 되거든요.

• 20명 조직을 Identity, Data, Platform으로 나누는 것도 그냥 조직도 예시가 아니에요. 각 팀이 맡는 시스템 레이어가 다르고, KPI도 30ms ID 해석률, 이벤트 오류율, p95 latency처럼 책임과 직접 연결돼야 실행이 흐려지지 않아요.

• 프로젝트를 1~2개월 단위로 쪼개라는 조언은 추정을 잘하자는 얘기보다 리스크를 작게 만들자는 쪽에 가까워요. 큰 프로젝트가 1년 밀리면 조직 전체가 흔들리지만, 작은 프로젝트가 몇 주 밀리면 다시 정렬할 수 있거든요.

• unblocker와 risk reducer를 value driver보다 앞에 두는 기준도 현실적이에요. 임원 대시보드처럼 눈에 보이는 결과는 매력적이지만, 스키마와 검증이 없으면 그 숫자는 신뢰할 수 없고 결국 더 큰 비용으로 돌아와요.