Cognition은 Devin으로 어떻게 개발하나

핵심

* 엔지니어가 확인하기도 전에 Linear 라벨이나 크래시 로그가 에이전트 세션을 시작할 수 있습니다.

* 에이전트가 조사 내용을 이미 작성해 두었으므로 엔지니어는 풀 리퀘스트부터 확인을 시작합니다.

* 요금은 사용량에 따라 책정되며 엔터프라이즈 보증은 예상 엔지니어 작업 시간과 연동됩니다.

1. 겨냥하는 산업

Cognition은 클라우드에서 실행되는 코딩 에이전트인 Devin을 만듭니다. 엔지니어링 팀이 티켓, 버그 리포트, 풀 리퀘스트 리뷰를 넘기면 Devin은 스스로 풀 리퀘스트를 생성합니다. Devin이 다루는 작업은 버그 수정, 테스트 작성, 레거시 코드 마이그레이션, 문서 업데이트, 변경 사항 검토 같은 소프트웨어 엔지니어들의 일상 업무입니다. 고객사에는 대기업과 시스템 통합(SI) 업체들이 포함되어 있으며, 2026년 9월 Cognition은 연환산 매출 10억 달러를 넘어섰다고 발표했습니다.

이 회사는 애초에 이 에이전트를 만들기 위해 세워졌습니다. 2024년 3월 첫 게시물에서 스콧 우는 Cognition을 “추론에 집중하는 응용 AI 랩”으로, Devin을 “최초의 AI 소프트웨어 엔지니어”로 소개했습니다. Cognition은 회사 설립 시점을 2024년 1월로 보고 있으며, Wikipedia에는 2023년으로 나옵니다. 회사 엔지니어들은 “우리는 처음부터 Devin으로 Devin을 만들어 왔다”고 말합니다.

두 가지 사실은 분명히 짚고 넘어갈 필요가 있습니다. 첫째, Cognition은 에이전트로 회사를 운영하기 위해서가 아니라 에이전트를 판매하기 위해 설립되었습니다. Devin이 자체 엔지니어링에서 차지하는 비중은 점차 커졌습니다. 둘째, 에이전트 기반으로 돌아가는 조직은 엔지니어링 팀이지 회사 전체가 아닙니다. Cognition에 따르면, 2025년 7월 AI 코드 에디터 기업인 Windsurf를 인수하기 전 44명이었던 자사 팀 인원이 1년 뒤 350명으로 늘어났습니다. 이번 인수를 통해 Windsurf의 직원들이 합류했습니다. 인수 1주년 기념 글에 따르면 Cognition에는 영업·마케팅 조직이 필요했고 Windsurf에는 엔지니어링 역량이 필요했습니다. 현재 회사 인력의 상당수는 제품 판매와 고객 지원을 맡고 있습니다.

2. 운영 방식

Cognition은 2026년 2월에 올린 글 How Cognition Uses Devin to Build Devin에서 내부 업무 방식을 설명했습니다. 기본 원칙은 “Devin을 팀원처럼 대하라”입니다. 업무는 크게 네 가지로 나뉩니다.

업무 배정: 에이전트는 일이 시작되는 접점에 자리합니다. 엔지니어는 웹 앱, Slack, Linear, Jira, 커맨드라인 도구, API를 통해 Devin을 호출합니다. Slack 스레드나 티켓에서 Devin을 태그하고 파일을 첨부해 대화를 주고받습니다. 사람의 개입 없이 시작되는 작업도 있습니다. Sentry 같은 시스템이 크래시 로그, 버그 리포트, 배포 실패 내역을 감지해 Devin 세션을 직접 시작합니다. Linear 티켓에 Bug 라벨이 붙으면 `!triage-bug`라는 저장된 루틴이 실행됩니다. Devin은 관련 코드를 찾고 Git 히스토리와 Datadog 로그를 확인한 뒤, 유력한 원인과 영향받은 파일 목록, 수정 제안을 게시합니다. Cognition에서는 이러한 저장된 루틴을 Playbooks라고 부릅니다. 목표와 단계, 완료 조건, Devin이 해서는 안 되는 행동을 명시한 재사용 가능한 지침서입니다.

프로덕션 버그의 경우 Devin은 한 걸음 더 나아갑니다. 로그를 가져오고 데이터베이스의 읽기 전용 복제본을 조회해 문제를 일으킨 커밋을 찾아냅니다. 그런 다음 회귀 테스트를 포함한 수정 코드를 작성하고 풀 리퀘스트를 올립니다. Cognition의 표현을 빌리면 이렇습니다. “우리는 로그 대신 PR을 리뷰합니다.”

업무 검토: 에이전트가 먼저 검토하고 사람이 결정합니다. 모든 풀 리퀘스트는 Devin Review를 거칩니다. Devin Review는 변경량이 많은 diff를 위에서 아래로 읽기 편하게 재정렬하고 버그 가능성을 신뢰도별로 표시합니다. 해당 글에서는 이러한 표시가 최종 판정이 아니라 참고 정보라고 밝힙니다. 이어 Autofix 기능이 실행되어 지적된 버그와 CI 또는 lint 실패 항목을 통과할 때까지 Devin이 수정합니다. 2026년 2월의 한 게시물에 따르면, 이 루프는 “Devin에 대한 내부 토큰 지출을 대폭 늘렸다”고 하며, “인간의 업무는 판단이 필요한 결정으로 좁혀진다”고 합니다. 2025년 11월 Cognition의 Devin 성과 검토 글에서는 사람이 여전히 코드를 검토하고, Devin의 테스트 로직을 확인하며, 코드 오너에게 테스트 커버리지를 승인받는다고 설명합니다.

테스트도 같은 방식을 따릅니다. 2026년 5월 글에서 한 Cognition 엔지니어는 소스 코드 기반으로 Devin이 테스트 계획을 세우는 테스트 모드를 소개했습니다. 정해진 스크립트로 앱에 로그인해 흐름을 클릭해가며 점검한 뒤, 각 항목의 통과, 실패, 미테스트 상태를 표시한 스크린샷과 영상을 전달하는 방식입니다. 엔지니어들은 각자 개발 서버를 둔 Devin을 10대에서 20대까지 병렬로 실행했습니다. 비밀 값(시크릿)을 제공하거나 일회용 로그인 인증 코드를 입력할 때 사람이 개입합니다.

업무 감사: 배포된 작업물도 에이전트가 사후 점검합니다. Devin은 매일 아침 지난 24시간 동안 머지된 풀 리퀘스트를 훑어보며 하드코딩된 색상값, 어색한 여백, 공용 라이브러리를 써야 할 컴포넌트 사용 등 디자인 시스템 관련 문제를 점검합니다. 문제가 발견되면 Linear 티켓을 생성하고 수정 풀 리퀘스트를 올리기도 합니다. 별도 기능인 Session Insights는 종료된 Devin 세션을 검토해 다음번에 더 나은 프롬프트를 추천합니다. Cognition의 에이전트 가이드에는 또 다른 습관이 소개되어 있습니다. 팀에서 자주 발생하는 엔지니어의 실수 목록을 유지 관리하면서, 새 lint 규칙을 만드는 대신 에이전트가 새 풀 리퀘스트를 이 목록과 대조하도록 하는 방식입니다.

역할의 변화: 코드 작성에서 검토 중심으로. 2026년 2월 글은 이렇게 설명합니다. “에이전트로 배포하는 코드가 늘어나면서 병목은 코드 작성에서 코드 검토로 옮겨갔습니다.” 에이전트 가이드에서도 “현재 우리 팀 엔지니어들은 여러 시스템을 감독해야 합니다”라고 밝힙니다. 엔지니어링 외 부서 인원도 Git을 배우지 않고 Devin에게 코드 수정을 요청할 수 있으며, 데이터 분석가 버전인 DANA는 Slack에서 차트와 그 바탕이 되는 SQL을 곁들여 지표 관련 질문에 답합니다. 채용 방식도 달라졌습니다. 스콧 우는 2025년 8월 Cheeky Pint 팟캐스트에서 입사 지원자들에게 “8시간 안에 각자 자신만의 Devin을 만들어 보라”고 요구한다고 밝혔습니다.

Cognition은 시기별로 여러 수치를 공개해 왔는데, 각 수치가 측정한 대상은 서로 다릅니다.

* 2025년 5월: Lenny’s Newsletter의 스콧 우 인터뷰 쇼노트에 따르면, Cognition 엔지니어링 팀은 15명이었고 엔지니어 1명당 약 5대의 Devin과 협업했으며, 회사 전체 풀 리퀘스트의 25%를 Devin이 생성했습니다.

* 2025년 11월: Cognition 웹 앱 커밋의 약 3분의 1을 Devin이 푸시했습니다.

* 2026년 2월: Cognition은 한 주 동안 Devin이 작성한 풀 리퀘스트 659건을 머지했습니다. 2025년 최고 기록이었던 주간 154건에서 늘어난 수치입니다.

* 2026년 5월: “소속 엔지니어가 커밋한 코드의 89%는 Devin이 커밋한 것입니다.” 나머지는 자체 코드 에디터인 Devin Desktop의 로컬 에이전트가 처리했습니다.

* 2026년 7월: Sourcery가 요약한 인터뷰에서 스콧 우는 이 수치가 대략 95%에 이른다고 밝혔습니다.

회사는 Devin이 아직 부족한 점도 숨기지 않습니다. 명확한 검증 기준이 있고 범위가 잘 정의된 작업에서 가장 효과적이며, 규모가 큰 작업은 잘게 쪼개야 합니다. 모바일 기기에서의 테스트는 수행하지 못합니다. 디자인 측면에서도 한계가 있습니다. “Devin은 정상 작동하는 인터페이스를 만드는 데는 뛰어나지만, 이를 보기 좋게 꾸미는 것은 여전히 사람의 영역입니다.”

3. 격차

가장 큰 차이는 업무 흐름 속에서 사람이 위치하는 지점입니다.

일반적인 소프트웨어 개발 팀에서는 엔지니어가 티켓을 가져와 로그를 확인하고 코드를 작성한 뒤, 작업이 끝날 무렵 동료에게 검토를 부탁합니다. 반면 Cognition에서는 회사의 설명대로라면 때로는 사람이 들여다보기도 전에 에이전트가 티켓을 가져가고, 두 번째 에이전트가 결과물을 검토하고 수정합니다. 엔지니어는 이미 분석이 끝난 상태의 풀 리퀘스트 단계에 합류합니다. 따라서 엔지니어는 작업의 범위를 정의하고 변경 사항을 평가하며 배포 여부를 판단하는 데 집중합니다. Cognition 역시 이를 제품 측면에서 이렇게 표현했습니다. “이제 병목은 코드 작성이 아니라 코드 리뷰에 있습니다.”

두 번째 차이는 머지 이후에도 검증이 계속된다는 점입니다. 많은 팀이 스타일이나 디자인 시스템 규격 이탈을 잡기 위해 리뷰어 개인의 주의력에 기댑니다. Cognition은 전날 머지된 모든 코드를 매일 에이전트로 훑고 발견된 문제를 티켓으로 만듭니다. 리뷰가 바쁜 동료에게 아쉬운 소리 하며 부탁하는 일이 아니라, 에이전트가 늘 수행하는 상시 업무가 된 것입니다.

세 번째 차이는 반복 업무의 시작 방식입니다. 라벨 부착, 크래시 리포트, 배포 실패 등의 이벤트가 사전 작성된 Playbooks에 따라 에이전트 세션을 곧바로 시작합니다. 반복되는 작업은 매번 손으로 처리하는 대신 한 번 작성해 둔 지침서에 따라 자동으로 실행됩니다.

요금 체계도 같은 맥락을 따릅니다. Cognition은 사용자 좌석 수가 아니라 사용량에 따라 요금을 부과합니다. 셀프서브 요금제는 기본 할당량을 두고 초과분을 모델 비용에 기반한 달러로 청구하며, 엔터프라이즈 요금제는 Agent Compute Units 단위로 과금합니다. 2026년 6월부터는 기업 고객을 위한 보장 프로그램도 선보였습니다. 유의미한 Devin 세션마다 소요되었을 사람 엔지니어의 작업 시간을 에이전트가 추정하고, 연간 계약 종료 시점에 그 환산 가치가 고객이 지불한 금액에 미치지 못하면 “Cognition이 최대 1,000만 달러까지 사용량을 지원합니다.” 이 추정치는 실제 사용자가 라벨링한 고객 세션 258건을 대조해 검증한 Cognition 자체 방식입니다.

4. 파급

엔지니어링 조직이 코드 작성이 아닌 검토 중심으로 재편될 수 있습니다. 에이전트가 코드 대부분을 생산한다면, 변경 사항을 빠르고 정확하게 판단하는 능력이 희소한 역량이 됩니다. Cognition 역시 스스로 이 한계에 부딪혔다고 밝히며, 현재 모든 풀 리퀘스트에 Devin Review를 적용하고 있습니다. 코딩 에이전트를 도입하는 다른 팀도 사람이 꼼꼼히 읽기 힘들 만큼 많은 풀 리퀘스트가 쌓이는 비슷한 상황을 겪을 수 있습니다. TechCrunch가 보도한 스콧 우의 견해에 따르면 “무엇을 해야 할지는 항상 사람의 결정에 맡겨야 합니다.”

사용자 좌석 기반의 소프트웨어 요금제가 압