How Forward Deployed Engineering is done at Cognition — Jia Wu
📺 원본 영상: How Forward Deployed Engineering is done at Cognition — Jia Wu
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-29
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연은 Cognition의 Deployed Engineering Lead인 Jia Wu가 Devin을 엔터프라이즈 환경에 배포하는 방식과, 그 과정에서 Forward Deployed Engineering(FDE)이 어떤 역할을 하는지를 설명한 발표이다. 핵심 메시지는 단순히 AI 코딩 에이전트를 고객에게 제공하는 것이 아니라, 고객의 실제 소프트웨어 개발 생명주기 안으로 들어가 문제를 정의하고, 그 문제를 다시 제품 로드맵으로 되돌리는 반복 구조를 만드는 데 있다.
강연자는 Devin의 가치가 “코드를 더 빨리 쓰는 도구”에 머물지 않는다고 본다. 이미 코드 생성 자체는 상당 부분 해결된 문제에 가까워졌으며, 진짜 병목은 테스트, 리뷰, 배포, 유지보수, 레거시 코드 대응, 조직 단위의 실행력에 남아 있기 때문이다. 따라서 Cognition의 FDE는 고객의 업무 맥락과 제품의 가능성을 맞물리게 하여, AI 엔지니어링이 실험이 아니라 실질적인 조직 성과로 이어지도록 만드는 기능으로 제시된다.
2024년의 Devin과 현재의 문제의식
Jia Wu는 발표 초반에 2024년 처음 공개된 Devin을 언급하며, 당시 반응이 기대와 회의가 섞여 있었다고 설명한다. SWE-bench에서 13%라는 성과가 주목받았지만, 실제 사용자 입장에서는 “막막할 때 마지막으로 써볼 도구”에 가깝게 느껴졌다는 것이다. 이는 AI 코딩 에이전트가 기술적으로 인상적이더라도, 실제 개발 조직의 복잡한 업무 흐름 안에서 곧바로 유용해지지는 않는다는 점을 보여준다.
이후 Cognition은 Devin의 제품 표면을 확장해 왔다. 강연자는 CLI, IDE 형태의 인터페이스, 그리고 Devin Cloud agent를 언급하며, Devin이 단일한 코드 생성 도구라기보다 다양한 사용 환경에서 동작하는 엔지니어링 에이전트 플랫폼으로 자리 잡고 있다고 설명한다. STT상 “flawed code”로 인식된 부분은 문맥상 Claude Code를 가리키는 것으로 보는 것이 자연스럽다.
중요한 전환점은 Cognition이 Devin을 단순 판매 대상이 아니라 내부 엔지니어링 레버리지의 기반으로도 사용한다는 점이다. 강연자에 따르면 Cognition 내부에서는 최근 6개월 동안 Devin을 활용해 조직 전체에서 훨씬 더 많은 양질의 PR을 만들 수 있었고, 이는 에이전트를 실제 업무에 배포했을 때 엔지니어링 생산성이 계단식으로 증가할 수 있음을 보여주는 사례로 제시된다.
02:13 - Cognition 내부에서 Devin을 활용해 PR 생산성이 증가한 수치를 설명하는 구간
Forward Deployed Engineering은 제품과 문제의 겹침을 키우는 일이다
강연의 중심 개념은 제품과 고객 문제 사이의 겹침이다. Jia Wu는 화면의 두 원을 예로 들며, 하나는 제품의 영역이고 다른 하나는 고객이 해결하려는 문제의 영역이라고 설명한다. 두 영역이 겹치는 지점이 Product-Market Fit이며, Cognition의 Forward Deployed Engineering은 이 겹침을 최대화하는 역할을 한다.
03:14 - 제품 영역과 고객 문제 영역의 교집합, 즉 Product-Market Fit을 벤 다이어그램으로 설명하는 구간
이 관점에서 FDE는 단순한 솔루션 엔지니어 또는 세일즈 엔지니어가 아니다. 고객이 실제로 어떤 업무를 처리하지 못하고 있는지, 어떤 개발 과제가 지연되고 있는지, 어떤 테스트가 방치되고 있는지, 어떤 알림과 장애 대응이 반복되는지를 현장에서 파악해야 한다. 그런 다음 Devin의 기능을 그 문제 공간에 맞게 배치함으로써, 제품이 고객의 실질적인 병목을 해결하도록 만든다.
강연자가 강조하는 첫 번째 원칙은 FDE가 문제 공간을 깊이 이해해야 한다는 점이다. 소프트웨어 조직은 기능 개발뿐 아니라 유지보수, 리뷰, 배포, 레거시 코드 관리, 테스트 작성 같은 복합적인 활동으로 돌아간다. 따라서 AI 에이전트를 “아무 데나 투입”하면 토큰만 소비하고 명확한 성과를 내지 못한다. Jia Wu는 이를 “token maxing”으로 표현하며, 무작정 사용량을 늘리는 방식은 엔터프라이즈 고객에게 지속 가능한 가치가 되지 못한다고 지적한다.
코딩은 20%의 문제이고, 나머지는 조직적 실행이다
강연에서 가장 중요한 기술적 판단 중 하나는 “코딩 자체는 대부분 해결된 문제”라는 주장이다. 이는 코드 작성이 완전히 끝났다는 뜻이 아니라, 충분한 컨텍스트와 Context Engineering이 제공되면 모델이 필요한 코드 블록을 만들어내는 능력은 이미 상당히 높아졌다는 의미에 가깝다. 그럼에도 기업의 소프트웨어 개발 속도가 자동으로 빨라지지 않는 이유는, 코드 생성 이후의 과정이 훨씬 더 복잡하기 때문이다.
실제 엔터프라이즈 환경에서는 새 기능을 작성하는 것보다 작성된 코드를 테스트하고, 리뷰하고, 배포하고, 장기적으로 유지보수하는 일이 더 큰 병목이 된다. 특히 대규모 조직에서는 레거시 코드, 규제 요구사항, 내부 도구, 배포 정책, 팀 간 소유권, 오래된 테스트 인프라가 얽혀 있기 때문에, 단순한 IDE 보조 도구만으로는 조직 전체의 속도를 10배 높이기 어렵다. Jia Wu는 개인 엔지니어를 빠르게 만드는 것과 조직 전체를 빠르게 만드는 것은 다른 문제라고 설명한다.
04:47 - 소프트웨어 개발 생명주기에서 코드 작성보다 테스트, 리뷰, 배포, 유지보수가 더 큰 병목임을 설명하는 구간
이 지점에서 Devin의 배포 방식은 단순한 사용 교육을 넘어선다. Cognition의 FDE는 고객과 긴 시간 대화하며 어떤 전략 과제가 가장 높은 레버리지를 가지는지 파악하고, 그 과제를 자동화 가능한 형태로 바꾼다. 강연자는 자신의 하루가 고객 미팅 몇 시간과 실제 hands-on keyboard 작업 몇 시간으로 나뉜다고 말하는데, 이는 FDE가 현장 이해와 직접 구현을 동시에 수행하는 역할임을 보여준다.
고객 문제를 제품 로드맵으로 되돌리는 피드백 루프
FDE의 두 번째 역할은 고객 문제를 제품 기능과 로드맵으로 되돌리는 것이다. 고객 문제를 100% 해결하는 것만으로는 충분하지 않으며, 그 과정에서 발견한 반복적인 패턴을 제품의 일반화 가능한 역량으로 전환해야 한다. 그렇지 않으면 각 고객마다 임시 대응만 늘어나고, 제품 자체의 학습 속도는 느려진다.
강연자는 현장에서 얻는 평가가 가장 높은 해상도의 피드백이라고 본다. 고객이 어떤 워크플로에서 막히는지, 어떤 우회 방법을 쓰는지, 어떤 버그가 반복되는지, 특정 문제가 한 고객에게만 특수한지 아니면 엔터프라이즈 전반에 공통적인지를 FDE가 직접 관찰하기 때문이다. 이런 정보는 제품팀이 로드맵의 위험을 줄이는 데 중요하다. 어떤 기능이 실제 매출과 고객 성공에 연결되는지 더 명확히 판단할 수 있기 때문이다.
따라서 Cognition의 FDE는 제품과 문제 사이의 다리 역할을 한다. 한쪽 방향으로는 Devin의 현재 기능을 고객의 문제에 맞추고, 반대 방향으로는 고객 현장에서 얻은 신호를 제품 개선의 근거로 만든다. 이 왕복 구조가 있기 때문에 다음 배포는 이전 배포보다 더 정교해지고, 제품은 실제 엔터프라이즈 환경에서 검증된 방향으로 진화한다.
07:42 - 현장 피드백을 제품 로드맵으로 되돌리고 엔터프라이즈 문제를 일반화하는 방식을 설명하는 구간
Cognition이 찾는 FDE 인재상
Jia Wu는 Forward Deployed Engineering이 매우 유연하게 정의되는 역할이라고 설명한다. 어떤 조직에서는 세일즈 엔지니어, 어떤 조직에서는 솔루션 아키텍트, 또 다른 조직에서는 고객 엔지니어에 가까울 수 있다. 그러나 Cognition이 보는 핵심은 넓은 역량과 깊은 스파이크를 동시에 가진 T-shaped 인재에 있다.
FDE는 고객 커뮤니케이션, 비즈니스 감각, 프로세스 이해, 기술 이해를 넓게 갖추어야 한다. 동시에 특정 영역에서는 매우 깊은 전문성을 보여야 한다. Cognition은 제품 감각이 강한 Product Manager 출신, 창업자 출신, 소프트웨어 엔지니어 출신을 모두 고려하지만, 공통적으로 중요한 것은 고객 문제를 제품 구조와 연결하고, 기술적으로도 방 안에서 전문가로 기능할 수 있는 능력이다.
강연자는 소프트웨어 엔지니어링의 비용이 0에 가까워질수록 제품 설계 능력이 더 중요해진다고 말한다. 코드를 프롬프트로 생성할 수 있는 시대에는 “무엇을 만들 것인가”와 “왜 이것이 고객과 비즈니스에 중요한가”를 판단하는 능력이 더 큰 차별점이 된다. 그래서 Cognition의 좋은 FDE는 고객 문제를 해결하는 실행자이면서, 동시에 그 문제가 왜 중요한지 끝까지 파고드는 제품적 사고의 소유자다.
Token Maxing에서 Intelligent Orchestration으로
강연 후반부에서 Jia Wu는 AI 에이전트 도입의 초기 시대를 “token maxing”으로 묘사한다. 1~2년 전에는 사용량을 늘리는 것이 주요 KPI처럼 여겨졌고, 예산 부담도 지금보다 덜했기 때문에 많은 조직이 토큰 소비 자체를 성과처럼 취급할 수 있었다. 그러나 대규모 규제 산업과 엔터프라이즈 고객에게 중요한 것은 사용량이 아니라 실제 가치다.
이제 질문은 “얼마나 많이 실행했는가”가 아니라 “얼마나 의미 있는 결과를 냈는가”로 이동한다. Cognition은 이를 Intelligent Orchestration, 즉 측정 가능한 결과를 지향하는 지능형 오케스트레이션으로 설명한다. 에이전트가 자동으로 특정 알림에 반응하고, 반복 업무를 처리하며, 개발 생명주기 안에서 필요한 세션을 수행하더라도, 그것이 실제 생산적인 엔지니어링 시간과 연결되지 않으면 고객에게 설득력이 없다.
이 차이는 단일 지점 도구와 조직 수준 에이전트 배포의 차이로 이어진다. CLI나 IDE가 개인의 속도를 높일 수는 있지만, 조직 전체의 과제 흐름, 비기술 직군과의 협업, 배포와 운영까지 포함한 가치 전달을 바꾸기는 어렵다. Cognition이 주장하는 Devin의 강점은 바로 이 조직 단위의 변화에 있다.
사례로 본 Devin의 엔터프라이즈 성과
Jia Wu는 Cognition이 고객 환경에 깊이 들어가 성과를 낸 몇 가지 사례를 제시한다. 첫 번째로, 특정 고객에 3개월 동안 임베드되어 약 150명 이상의 엔지니어링 인력에 해당하는 생산성을 제공했다고 설명한다. 여기서 중요한 것은 단순히 많은 세션을 실행했다는 사실이 아니라, 그 세션이 실제 생산적인 엔지니어링 시간으로 환산될 수 있어야 한다는 점이다.
12:19 - 3개월 고객 임베딩 사례에서 150명 이상의 엔지니어링 인력에 해당하는 생산성을 제공했다고 설명하는 구간
두 번째로, 강연자는 Devin 도입 전후의 개발 지표를 비교했을 때 프로젝트 전달 타임라인이 약 82% 줄어든 사례를 언급한다. Agile 개발 방식에서 티켓과 스프린트, 구현 과제가 순차적으로 쌓이는 구조를 생각하면, 이 정도의 압축은 단순한 코드 작성 속도 향상만으로 설명하기 어렵다. 테스트, 리뷰, 반복 작업, 마이그레이션 같은 병목이 함께 줄어들 때 비로소 Time to Value가 크게 단축된다.
12:59 - Devin 도입 전후 프로젝트 전달 타임라인이 약 82% 감소한 사례를 설명하는 구간
세 번째로, PR 산출량 측면에서도 단일 도구를 사용할 때보다 거의 두 배에 가까운 PR을 제공할 수 있었다고 설명한다. 다만 이 수치는 익명화된 사례 기반의 강연자 설명이며, 화면에 표시된 세부 그래프나 측정 방식은 STT에 포함되어 있지 않다. 따라서 정확한 기준과 산식은 원본 영상의 해당 화면을 함께 확인할 필요가 있다.
공개 사례: Nubank, 대형 은행, Bilt Cards
강연자는 익명 사례 외에도 공개적으로 언급 가능한 고객 사례를 소개한다. 첫 번째는 Nubank로, STT상 “Newbank”로 인식되었지만 문맥상 라틴아메리카의 디지털 은행 Nubank를 의미하는 것으로 교정하는 것이 자연스럽다. Jia Wu에 따르면 Nubank의 ETL migration에는 원래 50명의 엔지니어가 투입되어 있었고, Cognition은 Devin을 통해 이를 약 3분의 1 수준의 타임라인 안에서 자율적으로 전달할 수 있었다고 설명한다.
또 다른 사례는 라틴아메리카의 대형 은행에서 진행한 Tax Identification System migration이다. 이 프로젝트는 COBOL, JCL 같은 레거시 언어와 오래된 시스템을 포함한 복잡한 환경이었으며, 강연자는 이러한 영역이 현대 개발자들이 선호하거나 쉽게 익히는 기술 스택이 아니라고 지적한다. 그럼에도 Devin은 복잡한 코드베이스에서 필요한 마이그레이션을 수행하며 요구되는 노력을 절반 수준으로 낮추는 데 기여했다고 설명한다.
14:31 - Nubank ETL migration과 라틴아메리카 은행의 레거시 시스템 마이그레이션 사례를 설명하는 구간
마지막으로 Bilt Cards 사례에서는 PR acceptance rate와 주간 엔지니어링 산출량이 강조된다. Jia Wu는 Devin이 매주 10명 이상의 엔지니어에 해당하는 산출을 만들어낼 수 있었다고 설명하며, 우수한 엔지니어가 많은 조직에서 그 생산성을 10배로 확장하는 효과를 상상해 보라고 말한다. 이 사례들은 Cognition이 주장하는 FDE의 핵심, 즉 제품을 고객 현장에 깊게 배포하고 실제 결과로 증명하는 방식을 보여준다.
Cognition식 FDE의 문화적 조건
강연의 마지막 부분은 방법론보다 문화에 가깝다. Jia Wu는 Cognition이 고객에게 임베드되는 데 그치지 않고, 고객 성공을 위해 필요하다면 매우 강한 밀착도를 선택한다고 설명한다. 실제로 어떤 고객을 성공시키기 위해 브라질에 사람을 두 달 동안 파견해 고객 옆에서 생활하게 한 사례도 언급한다.
이런 방식은 FDE가 단순한 사후 지원 조직이 아니라 Go-to-Market의 핵심이라는 관점과 연결된다. 강연자는 FDE가 세일즈인지, 포스트세일즈인지, 정확히 무엇인지 모호하게 보일 수 있다고 말하지만, 결국 모든 사람이 고객 성공을 향해 움직인다는 점에서 시장 진입과 확장의 일부라고 본다. 고객이 Devin을 조직 안에 배포하고 압도적인 결과를 보여줄 수 있다면, 그 고객은 내부 챔피언이 되고 Cognition은 엔터프라이즈 파트너로 선택될 가능성이 높아진다.
또한 강연자는 ego 없이 제품으로 피드백을 되돌리는 태도를 강조한다. 현장에서 발견한 문제, 고쳐야 할 엔지니어링 관행, 제품이 더 잘해야 할 지점을 숨기지 않고 올려야 다음 배포가 더 나아진다. 이 문화가 있을 때 FDE는 고객 문제 해결자이자 제품 학습 시스템의 일부가 된다.
마무리 / 핵심 정리
이 강연의 핵심은 AI 에이전트 시대의 엔지니어링 생산성이 단순히 모델 성능이나 코드 생성 속도로 결정되지 않는다는 점이다. Devin이 실제 엔터프라이즈 환경에서 가치를 만들기 위해서는 고객의 업무 흐름, 레거시 시스템, 테스트와 리뷰, 배포 병목, 조직적 우선순위까지 이해해야 하며, Cognition의 Forward Deployed Engineering은 바로 그 접점을 담당한다.
Jia Wu가 제시한 FDE는 제품을 고객에게 전달하는 말단 기능이 아니라, 제품과 시장 사이의 학습 루프를 만드는 핵심 조직이다. 고객 현장에서 문제를 깊이 이해하고, Devin의 기능을 그 문제에 맞게 배치하며, 다시 그 경험을 제품 로드맵으로 되돌리는 구조가 Cognition의 배포 방식이다. 따라서 이 발표는 Devin 자체에 대한 제품 소개라기보다, AI 엔지니어링 도구가 어떻게 조직 수준의 성과로 번역되는지에 대한 운영 모델의 설명에 가깝다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | How Forward Deployed Engineering is done at Cognition — Jia Wu |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-29 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.