데빈이 자기 일을 증명하기 시작했다

이미지: METAL

요약

코그니션이 데빈에 GPT-6 Astra 를 붙여 코드를 짜는 단계와 증명하는 단계를 이었어요.
데빈은 아이폰 게임을 시뮬레이터에서 돌린 녹화본과 시험 보고서를 함께 돌려줘요.
보고서에는 시험되지 않은 영역이 따로 적혀, 자동화가 닿지 않은 자리가 남아요.

공개: 2026년 9월 11일 · 오픈AI 코그니션 사례
쓰는 곳: 클라우드 에이전트 데빈 · CLI · 데스크톱 제품
시험 산출물: 시뮬레이터 녹화본 + 통과 검사와 시험되지 않은 영역을 적은 보고서
예시: 아이폰 게임 오터 런
고객 응대: 버그 화면 캡처 투입 → 수정 후 결과 화면 캡처 회신
퍼플렉시티: 언어 모델 API·커넥터 응답을 흉내 내는 시험 프로그램으로 종단 간 검증
발표문 숫자: 두 사례 모두 속도·결함 감소 수치 없음

코드 검토를 해 본 사람이라면 아는 병목이 있어요. 짜는 속도보다 읽는 속도가 느리다는 거예요. 자율 소프트웨어 엔지니어 데빈을 만드는 코그니션이 지금 겪고 있는 문제가 정확히 그것이고, 이 회사가 내놓은 답은 코드를 덜 읽는 쪽이 아니라 코드가 스스로 증거를 내놓게 하는 쪽이에요.

오픈AI 는 9월 11일 코그니션 사례를 자사 사이트에 올렸어요. 코그니션은 큰 은행부터 테크 기업까지 전 세계 기업이 쓰는 자율 소프트웨어 엔지니어 데빈을 만든 회사예요. 발표문은 코그니션의 엔지니어링 팀이 더 많은 코드를 쓸수록 그 작업을 검토하는 일이 과제가 됐다고 적었어요. 회사가 GPT-6 Astra 에서 본 것은 더 똑똑한 작성자가 아니라 자기 결과를 시험하고 보여 주는 능력이에요.

월든 얀 코그니션 공동창업자는 이 지점을 한 문장으로 정리했어요. "Astra 가 개선한 큰 부분 중 하나는 자기 작업이 실제로 기대한 대로 작동한다는 것을 시험하고 증명하는 능력입니다" 라고 그는 말했어요. 작동한다고 주장하는 것과 작동한다는 것을 보여 주는 것 사이의 거리가 이 사례의 전부예요.

구체적인 장면이 하나 나와요. 발표문에 따르면 데빈은 Astra 를 써서 오터 런이라는 아이폰 게임을 시험하고, 시뮬레이터에서 게임이 돌아가는 녹화본을 돌려줘요. 녹화본과 함께 통과한 검사 항목과 시험되지 않은 채 남은 영역을 함께 적은 보고서가 붙어요. 녹화본은 소프트웨어가 실제로 어떻게 움직이는지를 보여 주고, 보고서는 시험이 어디까지 닿았는지를 적어 둬요.

여기서 회사가 인정한 한계를 그냥 지나치면 안 돼요. 보고서에 시험되지 않은 영역이라는 칸이 따로 있다는 건, 이 체제가 전부를 확인하지 못한다는 사실을 제품 안에 넣어 뒀다는 뜻이에요. 엔지니어는 그 칸을 보고 아직 손이 필요한 곳을 찾아요. 자동화가 검토를 없애는 게 아니라 검토가 향할 자리를 좁혀 주는 구조예요.

고객 응대 쪽에도 같은 방식이 들어갔어요. 얀에 따르면 고객이 버그 화면을 캡처해 보내면 팀이 그 이미지를 Astra 를 쓰는 데빈에게 넘기고, 데빈이 문제를 고친 뒤 결과를 보여 주는 화면 캡처를 돌려준다고 해요. 그는 이 방식 덕분에 고객에게 훨씬 빨리 답을 준다고 말했어요. 버그 보고가 이미지로 들어와서 이미지로 나가는 왕복이 만들어진 거예요.

적용 범위는 한 제품에 머물지 않아요. "우리는 핵심 클라우드 에이전트인 데빈뿐 아니라 CLI 와 데스크톱 제품까지 제품 전반을 개선하는 데 이것을 써 왔습니다" 라고 얀은 말했어요. 회사가 파는 물건을 회사가 만드는 도구로 쓰고 있다는 뜻이고, 이런 자기 적용은 도구의 약점이 가장 먼저 드러나는 자리이기도 해요.

같은 날 공개된 다른 사례 하나가 이 그림을 넓혀 줘요. 오픈AI 는 답변 엔진을 만드는 퍼플렉시티 사례도 함께 올렸어요. 조니 호 퍼플렉시티 공동창업자 겸 최고전략책임자는 "우리는 모델이 소통 내용을 작성하고, 실제 시스템을 수정하고, 운영 중인 소프트웨어를 감시하도록 할 수 있는데 이전 세대는 그러지 못했습니다" 라고 말했어요. 글을 쓰는 능력과 시스템을 건드리는 능력을 갈라 놓은 표현이에요.

퍼플렉시티가 든 예도 시험이에요. 호는 Astra 로 언어 모델 API 나 커넥터 같은 외부 서비스의 응답을 그럴듯하게 흉내 내는 시험용 프로그램을 만들어, 사람이 일일이 손으로 확인하지 않고도 종단 간 작업 흐름을 검증한다고 설명했어요. 그러고는 신뢰 수준을 이렇게 표현했어요. "우리는 실제로 전체 종단 간 시스템을 그것에 맡길 수 있고, 이전 세대 모델보다 훨씬 덜 들여다봅니다" 라고요.

이 두 사례가 같은 말을 하고 있다는 점이 중요해요. 에이전트가 더 좋아졌다는 신호가 벤치마크 점수가 아니라 사람이 확인하는 횟수로 나타나고 있어요. 얀은 앞으로를 이렇게 내다봤어요. "시간이 지나면 우리가 코드를 직접 들여다봐야 하는 양이 줄고 결국 더 많이 출시하게 될 것으로 기대합니다" 라고 그는 말했어요. 목표가 코드 품질이 아니라 검토 비용이라는 게 분명해요.

코그니션은 모델을 쓰기만 하는 회사가 아니에요. 메탈은 이 회사가 자체 코딩 모델 SWE-2 를 내놓고 성능과 비용의 경계선 위에 올렸다고 보도한 바 있어요. 자기 모델을 가진 회사가 제품 안에서는 다른 회사 모델을 시험 담당으로 쓰는 그림이고, 모델 선택이 회사 단위가 아니라 작업 단위로 갈라지고 있다는 신호예요.

메탈이 확인한 두 사례 페이지는 숫자를 거의 적지 않았어요. 속도가 몇 배 빨라졌다거나 결함이 몇 퍼센트 줄었다는 표현이 한 줄도 없어요. 대신 녹화본, 보고서, 화면 캡처처럼 사람이 눈으로 확인할 수 있는 산출물만 나열해요. 아직 벤치마크로 굳지 않은 단계의 변화를 회사들이 증거물 목록으로 대신 말하고 있는 셈이에요.

엔지니어링 쪽에서 보면 바뀐 것은 에이전트의 출력 형식이에요. 예전에는 코드 뭉치가 나왔고 사람이 그것을 읽어 판단했다면, 이제는 코드와 함께 그 코드가 돌아가는 장면과 무엇을 확인했고 무엇을 못 했는지 적은 문서가 같이 나와요. 검토자가 하는 일이 코드 해독에서 증거 심사로 옮겨 가요. 남는 질문은 그 증거를 누가 검사하느냐이고, 지금 그 자리에 앉아 있는 것도 같은 모델이에요.

자기가 짠 코드를 자기가 시험하는 구조에는 원래 구멍이 있어요. 시험을 통과하도록 코드를 맞추는 것과 코드가 맞도록 시험을 맞추는 것을 바깥에서는 구분하기 어려워요. 그래서 보고서의 시험되지 않은 영역 칸이 이 제품에서 가장 중요한 항목이에요. 자동화가 늘어날수록 값이 올라가는 것은 결과물이 아니라 결과물에 붙은 한계 표시고, 코그니션과 퍼플렉시티가 함께 내놓은 답은 사람을 검토에서 빼는 것이 아니라 사람이 볼 것을 줄이는 쪽이에요.