--- title: "엔지니어링 전략은 로드맵이 아니라, 뭘 안 할지 정하는 필터임" published: 2026-05-10T19:54:23.000Z canonical: https://jeff.news/article/2621 --- # 엔지니어링 전략은 로드맵이 아니라, 뭘 안 할지 정하는 필터임 이 글은 엔지니어링 전략과 계획을 구분하면서, 좋은 전략은 진짜 문제 진단, 방향성, 일관된 실행 묶음으로 구성된다고 설명함. 예시로 여러 브랜드에 흩어진 사용자 식별 문제를 들고, 30개월짜리 단계적 실행 계획과 팀 구성, KPI, 프로젝트 우선순위 기준까지 풀어냄. ## 전략은 멋진 문장이 아니라 선택의 기술임 - 글의 출발점은 단순함. 엔지니어링 전략은 비전 문구, 분기 로드맵, 긴 위시리스트가 아님 - 저자는 전략을 “다 할 수 없을 때 진짜 중요한 걸 고르는 일”로 정의함 - 좋은 아이디어가 많을수록 전략이 더 필요함. 전략은 팀이 어디에 힘을 주고, 어디를 미루고, 무엇을 무시할지 정하는 필터임 - 전략이 없으면 코드도 많이 쓰고 회의도 많이 하는데, 정작 회사나 조직이 앞으로 나아가진 않음 - 좋은 전략의 뼈대는 Richard Rumelt의 Good Strategy/Bad Strategy에서 가져옴 - 핵심 문제를 진단하고, 그 문제를 다룰 가이드 정책을 세우고, 서로 맞물리는 실행을 붙이는 구조임 - 반대로 나쁜 전략은 멋진 단어와 큰 포부는 있는데, 다음 주에 뭘 해야 하는지 아무도 모르는 상태임 - “우리는 더 데이터 기반 조직이 된다” 같은 말은 방향처럼 들리지만, 실제 병목을 찌르지 못하면 그냥 슬로건임 ## 사용자 식별 문제로 보는 좋은 전략과 나쁜 전략 - 좋은 전략 예시는 여러 브랜드와 앱에 흩어진 사용자 식별 문제임 - 사용자가 앱과 웹사이트를 오가는데 각 플랫폼이 사용자를 서로 다른 사람처럼 취급함 - 공통 사용자 관점이 없으니 개인화도 안 되고, 전체 여정 분석도 안 되고, 리포팅도 흔들림 - 진짜 진단은 “사용자를 시스템 전체에서 안정적으로 식별할 수 없다”는 것임 - 이 경우 가이드 정책은 “먼저 identity를 고친다”가 됨 - 각 브랜드가 자기 방식으로 해결하게 두지 않고, 모든 플랫폼이 부를 수 있는 단일 사용자 ID 기준을 만듦 - 이벤트도 그 ID 기준으로 표준화해서 사용자 여정을 연결함 - 중복 ID는 병합하고, 통합 데이터를 개인화·마케팅·리포팅에 공급함 > [!IMPORTANT] > 이 예시의 핵심은 대시보드나 머신러닝을 먼저 하지 않는다는 점임. 공유 identity가 없으면 그 위에 얹는 분석은 전부 서로 다른 숫자를 말하게 됨. - 나쁜 전략은 같은 문제를 더 화려하게 망치는 방식임 - “모든 브랜드가 더 데이터 기반으로 움직인다”는 목표를 세우고, 각 팀이 자기 분석 파이프라인을 만들게 함 - 겉으로는 빠르게 움직이는 것처럼 보이지만, 사용자 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보다 앞에 두는 기준도 현실적이에요. 임원 대시보드처럼 눈에 보이는 결과는 매력적이지만, 스키마와 검증이 없으면 그 숫자는 신뢰할 수 없고 결국 더 큰 비용으로 돌아와요. ## 핵심 포인트 - 좋은 전략은 비전 문구가 아니라 핵심 문제 진단, 가이드 정책, 일관된 실행으로 구성됨 - 사용자 식별 문제가 풀리지 않은 상태에서 대시보드나 머신러닝을 얹으면 데이터가 깨진 채로 확장됨 - 20명 엔지니어 조직 예시에서 Identity 6명, Data 7명, Platform 7명으로 책임과 KPI를 나눔 - 프로젝트는 1~2개월 안에 가시적 결과를 내야 하고, 한 팀이 끝까지 소유할 수 있어야 함 - 중단 요청은 신뢰성·보안 리스크 또는 최상위 전략과 연결될 때만 우선순위를 바꿈 ## 인사이트 기술 리더가 읽으면 찔리는 부분이 많은 글임. ‘좋은 아이디어가 많다’는 말은 사실 전략이 없다는 신호일 때가 많고, 이 글은 그 혼란을 KPI, 팀 배치, 프로젝트 크기, 중단 대응 규칙까지 내려서 정리함.