How Forward Deployed Engineering is done at Cognition — Jia Wu

URL: https://www.youtube.com/watch?v=RVxym6mmIns 날짜: 2026-07-29 채널: AI Engineer (aiDotEngineer)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Cognition(Devin 개발사)의 Forward Deployed Engineering(FDE)은 ==제품이 풀 수 있는 문제와 고객이 실제로 겪는 문제의 교집합을 최대화하는 것==이 핵심이며, 단순히 토큰을 많이 태우는(token maxing) 방식에서 벗어나 측정 가능한 비즈니스 성과(엔지니어링 시간, 납기 단축, PR 처리량)로 가치를 증명하는 방향으로 진화했다.

• FDE는 제품(Product)의 원과 고객 문제(Problem)의 원, 두 원의 교집합인 "제품-시장 적합성(PMF)"을 넓히는 역할을 한다
• 코딩 자체는 이제 대부분 해결된 문제이며, 진짜 어려움은 테스트·리뷰·배포·유지보수에 있다
• Cognition은 6개월 만에 인력 채용은 뒤처졌음에도 에이전트를 통해 조직 전체 PR 품질과 양을 한 자릿수(약 10배) 끌어올렸다

발표자 지아 우(Jia Wu)는 Cognition의 Deployed Engineering Lead로, Windsurf 인수 이후 합류했다. 발표는 (1) FDE가 문제 공간을 깊이 이해하는 방법, (2) 고객 문제를 다시 제품 역량으로 매핑하는 방법, (3) FDE 채용·조직 철학, (4) 실제 고객사 사례와 수치로 구성된다.

---

1. Devin과 Cognition의 현재: "우리는 이제 진짜 좋다"

Devin은 2024년 출시 초기 조롱거리였다가 현재는 SF 전역에 광고가 붙을 만큼 성과를 인정받는 제품으로 성장했다.

1.1. 2024년 출시 당시의 반응

1. 초기 화제성과 실망

   1. 출시 당시 벤치마크: 2024년 Devin 최초 공개 당시 SWE-bench 13% 성능으로 "We're so back(우리 다시 돌아왔다)"이라는 반응이 있었음
   2. 엔지니어들의 공포: 엔지니어들은 반대로 "We're so cooked(우리 이제 망했다)"라고 반응함
   3. 일주일 뒤의 냉정한 평가: 실사용 일주일 후에는 "이거 별로 안 쓸모 있네"라는 반응이 지배적이었고, "정말 절박하고 아이디어가 없을 때만 쓸 것 같다"는 평가를 받음

2. 현재의 반전

   1. 자기 풍자를 마케팅으로 활용: Cognition은 이 조롱을 그대로 받아들여 SF 전역 광고 캠페인 소재로 활용함(유머 감각이 있다는 방증)
   2. 현재는 실제로 좋아짐: 발표자는 "이제는 진짜 좋다(We're actually good now)"고 명확히 밝힘

1.2. 제품 구성

1. 다양한 인터페이스로 제공

   1. CLI: Claude Code처럼 CLI 형태로도 노출됨
   2. IDE: Cursor, Windsurf처럼 IDE 형태로도 노출됨
   3. 발표자의 배경: 지아 우는 Windsurf 인수(acquisition) 이후 Cognition에 합류했다고 밝힘("great times"라고 회상)

2. 핵심 제품: Devin Cloud (에이전트)

   1. 회사가 가장 유명한 제품: Devin Cloud 또는 "Devin Cloud agent"가 Cognition의 대표 제품
   2. 발표 목적은 제품 세일즈가 아님: 발표자는 기능 나열이 아니라 "우리가 엔터프라이즈 전반에서 실제로 임팩트를 전달하는, 최고 수준의 소프트웨어 엔지니어링 조직 중 하나"라는 점을 강조하고 싶다고 말함

---

2. 핵심 성과 지표: 6개월 성장 그래프

2.1. 내부 생산성 지표

1. 채용은 부족했지만 산출물은 폭증

   1. 인력 부족 상황: 지난 6개월간 Cognition은 채용 속도 면에서 뒤처져 있었음("for better or worse, we might have been behind on hiring")
   2. 에이전트로 상쇄: 그럼에도 자체 에이전트를 사용해 조직 전체에서 품질 좋고 견고한(robust) PR을 한 자릿수(약 10배, order of magnitude) 더 많이 출하함
   3. 의미: 이는 자체 에이전트 배포를 통해 얻는 엔지니어링 레버리지가 계단식(step function)으로 증가했다는 의미

2. 외부 채택 곡선

   1. 파라볼릭 성장: 여러 기업이 Cognition의 에이전트를 채택·배포하고, 다양한 유스케이스와 시나리오에서 활용하는 방식이 포물선(parabolic) 형태로 증가하고 있음

---

3. Forward Deployed Engineering의 첫 번째 원칙: 문제 공간을 깊이 이해하라

FDE의 존재 이유는 "제품이 할 수 있는 것"과 "고객이 겪는 문제" 두 원의 교집합을 최대화하는 데 있다.

3.1. 벤 다이어그램으로 본 FDE의 존재 이유

1. 두 개의 원: 제품과 문제

   1. 제품(Product) 원: 비즈니스이자 소프트웨어 엔지니어링 조직으로서 회사가 만드는 것
   2. 문제(Problem) 원: 회사가 풀고자 하는 문제들의 집합
   3. 교집합 = PMF: 두 원이 겹치는 부분이 바로 제품-시장 적합성(product-market fit)이며, 이상적으로는 회사가 하는 일이 고객에게 가치를 주고, 고객의 문제를 회사 제품으로 풀 수 있어야 함

2. FDE 모션의 목적

   1. 교집합 극대화: Cognition에서 forward-deployed 모션은 회사가 일반적으로 만드는 제품과 엔터프라이즈 전반에서 겪는 문제 사이의 교집합을 최대화하는 것을 목표로 함

3.2. 소프트웨어 엔지니어링에서 진짜 어려운 부분

1. 코딩은 이미 대부분 해결됨

   1. 모델 성능: 지금의 모델들은 충분한 컨텍스트 엔지니어링만 있으면 원하는 코드 블록을 뽑아낼 수 있을 만큼 좋아짐
   2. 코딩은 문제의 20%에 불과: "코드를 더 빨리 쓰는 것"은 보통 전체 문제의 20%에 불과함

2. 진짜 문제: 테스트·리뷰·배포·유지보수

   1. 레거시 코드의 현실: 제로에서 새로 만들고 프롬프트만 하면 되는 이상적 상황은 실제로 존재하지 않으며, 기존 코드베이스를 다루고 기능을 빌드·유지보수해야 하는 현실이 있음
   2. 비즈니스 가치가 걸린 단계들: 기능을 만들고 나서의 리뷰, 배포, 유지보수의 모든 단계에 큰 비즈니스 가치가 걸려 있음
   3. 테스트·리뷰·배포가 진짜 문제: "이 코드를 어떻게 테스트할 것인가, 어떻게 리뷰·배포할 것인가, 엔터프라이즈 전반에서 어떻게 유지보수할 것인가"가 진짜 문제로 남음

3.3. Devin 역량을 고객 문제에 매핑하는 방식

1. 방향 없는 배포 = 토큰 낭비

   1. 무작정 배포의 위험: 소프트웨어 개발 생명주기가 극도로 복잡한 상황에서 구체적 방향 없이 에이전트를 배포하면 그냥 토큰을 낭비(token maxing)하는 것에 불과함
   2. 가시적 성과 없음: 방향 없는 배포는 지출만 태우고 실질적 성과를 만들지 못함

2. FDE의 하루 구조

   1. 콜과 실무의 균형: 지아 우의 하루는 보통 고객 콜 4~5시간과 실제 hands-on keyboard 작업 4~5시간으로 구성됨
   2. 콜의 역할: 이 콜들을 통해 비즈니스에 가장 높은 레버리지를 주는 전략적 이니셔티브가 무엇인지 깊이 파악함

3. 자동화를 통한 자기 자신의 업무 제거

   1. 목표는 스스로를 자동화로 대체하는 것: 전략적 우선순위를 파악한 후에는 에이전트가 모든 자동화를 스스로 실행하도록 세팅해서 FDE가 수동으로 트리거하지 않아도 특정 알림·이벤트에 반응하게 만듦
   2. 가장 어려운 질문: ROI 측정: FDE로서 가장 모호하고 아직 풀리지 않은 문제는 투자 대비 수익(ROI)을 어떻게 측정할 것인가이며, 이를 풀어내는 회사는 "5조 달러(5 trillion) 시가총액" 규모가 될 것이라고 언급함

4. 고객 생태계에 임베드

   1. 백로그와 잔여 작업 파악: FDE는 고객 생태계에 임베드되어 처리해야 할 백로그, 필요한 리미디에이션(remediation), 절대 출하되지 않는 지연된 코드, 아무도 작성하지 않는 테스트, 특정 알림의 자동 트리아지 등을 살펴봄
   2. 역량을 문제에 매핑: 이렇게 파악한 문제들에 Cognition의 제품 역량을 매핑함

3.4. 절반의 방정식: 제품에도 피드백을 줘야 한다

1. 고객 문제 해결만으로는 부족함

   1. 벤 다이어그램의 절반만 채움: 고객의 문제를 100% 해결하고 고객이 매우 만족하더라도, 이는 방정식의 절반에 불과함
   2. 제품도 함께 풀어야 함: 고객의 문제와 회사가 만드는 제품의 합집합(union)을 놓고 볼 때, 문제 해결만으로는 벤 다이어그램의 일부만 이동시킬 뿐임

2. 진짜 피드백 루프 = Forward Deployed Engineering

   1. 정의: 하고 있는 일과 고객이 필요로 하는 것 사이의 최대 교집합을 통합하는 진짜 피드백 루프를 만드는 것이 바로 Cognition에서의 forward deployed engineering임 (※ 발표 중 이 대목에서 발표자가 "Cockroach Labs"라고 언급했는데 문맥상 Cognition의 말실수/ASR 오인식으로 판단됨)

---

4. 두 번째 원칙: 고객 문제를 다시 제품 역량으로 매핑하라

4.1. 필드에서 얻는 최고 신뢰도의 평가 데이터

1. 현장이 곧 평가 셋

   1. 매일 현장에서 얻는 데이터: FDE는 매일 현장에서 고객이 겪는 문제와 하는 일들을 듣기 때문에, 회사가 가진 가장 높은 신뢰도(fidelity)의 평가 셋(evaluation set)이 필드에서 나옴
   2. 이 컨텍스트를 제품으로 전달: 이렇게 얻은 컨텍스트를 합리적인 방식으로 제품팀에 되돌려줘야 함

2. 판단해야 할 질문들

   1. 공통 문제인가 개별 문제인가: 엔터프라이즈 전체에 공통적으로 나타나는 문제인지, 특정 사용자에게만 고유한 문제인지 구분해야 함
   2. 워크어라운드가 기능이 되어야 하는가: 워크어라운드, 핵(hack), 버그가 정식 기능으로 승격되어야 하는지 판단해야 함
   3. 로드맵의 리스크를 낮추는 것이 목표: 궁극적 목표는 로드맵의 리스크를 낮추는 것이며, 엔지니어가 "이걸 만들면 특정 고객으로부터 Y%의 매출을 얻는다"를 정확히 알 수 있는 것이 이상적임

3. FDE = 변화의 전령이자 다리

   1. 제품과 문제 사이의 다리: FDE는 제품과 문제 사이를 잇는 다리이며, 피드백은 다음 배포가 이전 배포보다 나아지게 만드는 루프의 절반을 차지함

4.2. FDE 채용 철학: T자형 인재와 스파이크형 인재

1. 역할 정의 자체가 유동적

   1. 모호한 정체성: FDE라는 역할은 세일즈 엔지니어인지, 솔루션 아키텍트인지 정의가 매우 유연함
   2. 넓은 스킬셋 요구: 사람 스킬, 비즈니스 스킬, 프로세스, 고객 대응 스킬, 기술력까지 폭넓게 갖춰야 함(필드에 배치되려면 해당 기술 스택도 알아야 함)

2. 깊은 스파이크(전문성)를 가진 인재도 채용

   1. 프로덕트 매니지먼트 배경: 제품이 서로 어떻게 맞물리는지에 대한 좋은 감각을 가진 PM 출신을 채용함. 소프트웨어 엔지니어링 비용이 0에 수렴할수록 제품을 어떻게 설계할지 아는 것이 더 중요해지기 때문
   2. 창업가·소프트웨어 엔지니어 출신: 비즈니스 감각이 다소 부족해도 기술 도메인에서 매우 스파이크(뾰족)한 인재도 채용함. 비즈니스 감각은 나중에 배울 수 있지만, 현장에서 실시간으로 기술 전문성을 익히기는 매우 어렵기 때문

3. 좋은 FDE 대비 훌륭한 FDE

   1. 좋은 FDE: 제품을 로드맵에 매핑하고 고객 문제를 해결하는 등 모든 일을 다 함
   2. 훌륭한 FDE의 차별점: "왜"에 대한 집요한 호기심(relentless curiosity for why)을 가짐 — "우리가 왜 이 문제를 풀고 있는가, 이게 비즈니스 전체에 중요한가, 이걸 로드맵에 어떻게 전달하면 모두에게 도움이 되는가"를 항상 자문함

4.3. 조직이 따르는 두 가지 신조

1. 신조 1: "왜"에 대한 집요한 호기심

   1. 끊임없는 자문: Cognition은 항상 "이 문제가 비즈니스에 중요한가, 로드맵에 어떻게 되돌려 전달해야 다른 모두에게 문제가 개선되는가"를 자문함

2. 신조 2: 고객에 집요하게 밀착

   1. 고객이 곧 생명줄: 고객은 회사의 생명줄(lifeblood)이며, 고객을 성공시키는 것만이 비즈니스로서 생존하고 엔터프라이즈 파트너십의 당연한 선택지가 되는 유일한 길임

---

5. FDE 방법론의 진화: 토큰 맥싱에서 측정 가능한 성과로

5.1. 과거 접근: 토큰 맥싱 시대

1. 예산 걱정 없던 시절

   1. KPI = 토큰 사용량 극대화: 1~2년 전 FDE들의 목표/KPI는 단순히 토큰 사용량을 극대화하는 것이었음
   2. 모든 것이 보조금 지원된 시기: 예산 걱정 없이 원하는 만큼 뭐든 실행할 수 있는 완벽한 시기였다고 회고함

2. 문제의 중심이 딜리버리로 이동

   1. 엔터프라이즈의 실질 가치 요구: 함께 일하는 대규모 규제 산업 기업들은 "이 솔루션에서 진짜 가치를 얻고 있는가, 아니면 그냥 이유 없이 토큰만 태우고 있는가"를 매우 중요하게 여기기 시작함

5.2. 핵심 차별점: 조직 전체를 10배 빠르게

1. 엔지니어 개인 10배 vs 조직 전체 10배
   1. 엔지니어 10배는 이미 가치 있음: 엔지니어를 10배 빠르게 만드는 것은 여전히 유의미한 가치
   2. 진짜 목표는 조직 전체 10배: 그러나 기술직이든 비기술직이든 회사 전체 모든 구성원을 10배 빠르게 만들 수 있는가가 진짜 파트너십 가치를 여는 지점
   3. 단일 지점 툴의 한계: CLI나 IDE 하나만 제공하는 단일 지점(single point) 툴들은 이 조직 전체 가속을 만들어내지 못해 실패함

5.3. 성과 측정: "세션" 단위 지표

1. 세션(session) 개념
   1. 정의: Cognition에서 에이전트를 실행해 특정 트레이스/트래젝토리를 만들면 이를 "세션"이라고 부름
   2. 엔지니어링 시간으로 환산: 세션 데이터를 통해 실제로 생성된 엔지니어링 시간과, 사용자가 실행한 세션 중 실제로 생산적인 시간이 얼마나 되는지 도출 가능함

---

6. 증명된 성과: 익명 사례 연구 3건

6.1. 3개월 임베드 사례

1. 150%+ 헤드카운트 효과
   1. 3개월 상주: 특정 고객사에 3개월간 직접 임베드됨
   2. 150% 플러스 헤드카운트급 산출: 그 3개월 동안 기능적으로 150% 이상의 추가 인력(headcount)에 해당하는 산출을 전달함 — 진행 중이던 프로젝트나 마이그레이션에 150명의 추가 동료가 함께 일한 것과 같은 효과라고 비유함

6.2. 딜리버리 타임라인 82% 단축

1. 애자일 지표 비교
   1. 에자일 개발 방법론 기준: 애자일 개발 방법론(티켓, 스프린트 등)을 기준으로 Devin 도입 전후의 모든 지표를 비교함
   2. 82% 단축: 딜리버리 전반에서 타임라인을 약 82% 압축할 수 있었음
   3. 엔터프라이즈 전반의 패턴: 고객 환경에 완전히 활성화(fully activated)되면 엔지니어링 캐파의 대규모 확장뿐 아니라 시장 출시까지의 시간(time to value)도 줄어듦

6.3. 원시 PR 수량 거의 2배

1. 단일 지점 툴 대비
   1. PR 볼륨 비교: 단순 숫자를 한 차원 더 파고들면, 단일 지점 툴만 쓰던 시절과 비교해 Devin 같은 에이전트 하니스를 도입한 뒤 엔지니어들이 처리하는 원시 PR 수가 거의 2배(almost double)로 증가함

6.4. 공개 고객 사례: Nubank (라틴아메리카)

1. ETL 마이그레이션
   1. 기존 인력 규모: 원래 50명의 엔지니어가 이 마이그레이션에 배정되어 있었음
   2. Devin 단독으로 자율 수행: Devin이 자율적으로 작업해 전체 타임라인의 약 1/3 만에 마이그레이션을 완료함

6.5. 공개 고객 사례: 라틴아메리카 대형 은행

1. 세금 식별 시스템 마이그레이션
   1. 레거시 시스템: COBOL, JCL 같이 요즘 아무도 배우지 않는(재미없고 흥미롭지 않다는 이유로) 레거시 언어/기술이 얽힌 시스템이었음
   2. 절반의 노력으로 완료: 원래 필요했던 노력의 절반만으로 마이그레이션을 완료함
   3. 가장 복잡한 코드베이스에서도 작동: 세계에서 가장 복잡한 일부 코드베이스에서도 실질적 결과를 내며 작동함을 증명함

6.6. 공개 고객 사례: Built (카드 회사)

1. PR 승인율과 산출량
   1. 한 자릿수(약 10배) 증가: PR 승인율(acceptance rate) 관점에서 병합되는 PR이 한 자릿수(약 10배) 더 많아짐
   2. 주당 엔지니어 10명 이상 분량: 매주 10명 이상 엔지니어에 해당하는 산출량을 생성함
   3. 기존 엔지니어도 우수함을 전제: 발표자는 "Built의 엔지니어들은 원래도 매우 뛰어나다(cracked)"고 강조하며, 그런 뛰어난 엔지니어를 10배로 곱하는 효과를 상상해보라고 말함

---

7. 조직 철학: 어디든 가고, 무엇이든 한다

7.1. 회사 핵심 가치의 외부 적용

1. 내부뿐 아니라 외부 고객에게도 동일하게 적용

   1. 승리하는 팀에 있는 재미: "이기는 팀에 있는 건 정말 재밌다(It's really fun being on the winning team)"
   2. 챔피언 만들기: 조직에 Devin을 도입한 사람은 조직 내에서 비교 불가능한 결과를 보여줄 수 있고, 그 사람 자체가 회사의 챔피언이 됨

2. 끝까지 간다는 자세

   1. 브라질 10개월 파견 사례: 고객을 성공시키기 위해 한 FDE를 브라질에 10개월간 파견해 고객 바로 옆에 거주하도록 한 사례가 있음(청중 웃음 유발)
   2. 미션에 헌신: "우리는 이 미션에 헌신한다(We're down for the mission)"

7.2. 에고 없는 정정(correctness) 문화

1. 문제를 제품으로 피드백
   1. 고쳐야 할 관행은 바로 지적: 고쳐야 할 엔지니어링 관행이 있으면 이를 플래그하고 제품팀에 다시 전달하며, 여기에 에고가 개입되지 않음
   2. 같은 배를 탄 팀: 결국 모두가 같은 배를 탔고, 같은 미션을 수행하며, 그저 계속 출하(shipping)할 뿐이라는 태도

7.3. "모두가 고투마켓(Go-to-Market)이다"

1. FDE 정체성의 모호함을 인정

   1. 모호한 소속: "나는 세일즈 소속인가? 포스트세일즈 소속인가? FDE로서 실제로 뭘 하는가?"라는 질문은 늘 모호하게 남아있음
   2. 결론: 모두가 GTM: 그럼에도 모든 구성원이 고투마켓(go-to-market)이라는 점은 명확한데, 목표가 "어떤 대가를 치르더라도 고객을 성공시키는 것(make the customer successful at all costs)"이기 때문임

2. 마무리 메시지

   1. 매초가 중요하다: "우리는 매초가 중요하기 때문에 일을 한다(we just do things because every second counts)"
   2. 채용 초대: 세상에서 가장 어려운 문제들의 교집합에 있고 싶고, 소프트웨어 전면 disruption의 일부가 되고 싶고, 이 문제들의 반대편에 서고 싶다면 Cognition의 forward deployed engineering팀과 이야기하자고 초대하며 발표를 마침

---

주요 발언 모음

"SweepBench 13%. We're so We're so back." / "We're so cooked." (2024년 Devin 출시 당시 반응) "I would only use this if I was desperate and out of ideas." (출시 일주일 후 초기 반응) "These models are so good now that... with enough context engineering, you can get the code blocks that you really care about. But the problem isn't like writing code faster, that's usually only 20% of the problem." "The company that will solve this will be, you know, $5 trillion market cap." (ROI 측정 문제의 난이도를 강조하며) "You can make engineers like 10x faster. That's fine. That's still valuable. But can you make an organization 10x faster, including every single person that might be technical or non-technical across the company?" "It's really fun being on the winning team." "We've deployed somebody in Brazil for like 10 months... to live next to one of the customers to just make them successful." "Everybody essentially is go-to-market... the target is to make the customer successful at all costs. And at the end of the day, we just do things because every second counts."

핵심 데이터 & 수치

• SWE-bench 13%: 2024년 Devin 최초 출시 당시 벤치마크 성능, 초기 화제와 이후 실망의 근거가 됨
• 약 10배(order of magnitude) PR 증가: 지난 6개월간 채용은 뒤처졌음에도 자체 에이전트로 조직 전체 PR 산출량을 약 10배 늘림
• 150%+ 헤드카운트: 특정 고객사에 3개월 임베드해 150% 이상 추가 인력에 해당하는 산출을 전달
• 82% 딜리버리 타임라인 단축: Devin 도입 전후 애자일 딜리버리 지표 비교 결과
• 거의 2배(almost double) 원시 PR 수: 단일 지점 툴 대비 에이전트 하니스 도입 후 PR 처리량 증가율
• Nubank ETL 마이그레이션: 원래 50명 엔지니어 배정 프로젝트를 Devin 단독으로 전체 타임라인의 1/3 만에 완료
• 라틴아메리카 은행 세금 시스템 마이그레이션: 절반의 노력(half the effort)으로 완료, COBOL/JCL 레거시 스택 포함
• Built 카드사: PR 승인율 약 10배 증가, 주당 10명 이상 엔지니어 분량 산출
• 브라질 10개월 파견: FDE 1명을 고객 바로 옆에 10개월간 상주시킨 사례

결론 및 시사점

1. 코딩은 더 이상 병목이 아니다: AI 코딩 모델의 성능이 충분히 좋아진 지금, 소프트웨어 엔지니어링의 진짜 병목은 코드 작성이 아니라 테스트·리뷰·배포·유지보수에 있으며, 이 영역에 에이전트를 어떻게 통합할지가 핵심 과제다.
2. 에이전트 배포는 방향 없는 토큰 소모에서 측정 가능한 ROI로 이동해야 한다: "얼마나 많은 토큰을 썼는가"가 아니라 "엔지니어링 시간을 얼마나 창출했는가, 딜리버리 타임라인을 얼마나 단축했는가, PR 처리량이 얼마나 늘었는가"로 성과를 증명해야 살아남는다.
3. Forward Deployed Engineering은 세일즈와 제품 사이의 양방향 피드백 루프다: 고객 문제를 해결하는 것으로 끝나는 게 아니라, 그 경험을 다시 제품 로드맵에 반영해야 진짜 가치가 생긴다.
4. 채용은 T자형과 스파이크형을 함께 뽑아야 한다: 폭넓은 비즈니스·고객 스킬을 가진 인재와, 비즈니스 감각은 부족해도 기술적으로 매우 뾰족한 인재(창업가·엔지니어 출신)를 함께 채용하는 전략이 유효하다 — 기술 전문성은 현장에서 가르치기 어렵기 때문이다.
5. 단일 지점 툴(CLI/IDE 단독)의 한계: 개별 엔지니어를 빠르게 만드는 것을 넘어, 비기술직을 포함한 조직 전체를 가속하지 못하면 진짜 파트너십 가치를 만들 수 없다.