에이전트가 오래 일할수록, 사람의 승인선이 제품이 된다

에이전트가 오래 일할수록, 사람의 승인선이 제품이 된다 이번 주의 공통점은 ‘더 강한 모델’보다 더 오래, 더 조직적으로 일하는 에이전트입니다.

OpenAI와 Cursor는 장시간 실행과 다중 에이전트 협업을 제품의 중심으로 끌어올렸고, GitHub도 코드 리뷰를 단순한 코멘트 생성에서 검증과 재검토가 이어지는 흐름으로 확장하고 있습니다.

에이전트가 한 번의 질문에 답하는 도구를 넘어 실제 업무를 계속 수행하기 시작하면 개발자가 설계해야 할 것도 달라집니다.

중요한 것은 프롬프트만이 아닙니다.

무엇을 할 수 있는가. 어디까지 스스로 진행할 수 있는가. 언제 사람에게 돌아와야 하는가. 실패하면 어디서 멈추는가.

그리고 이번 주 직접 Jev를 사용해보며 한 가지를 더 확인했습니다.

모든 자동화를 장기 실행 에이전트나 범용 LLM으로 만들 필요도 없습니다.

OpenAI Agents API 공개 베타

PROOF LEVEL 03 · 공식 확인

OpenAI는 9월 10일 Codex를 구동하는 관리형 에이전트 하네스를 개발자가 사용할 수 있도록 Agents API를 공개 베타로 발표했습니다.

긴 세션과 컨텍스트 관리, 도구 실행, 서브에이전트 조율, 파일과 코드를 다루는 실행 환경 등을 OpenAI가 관리합니다.

개발자에게 중요한 점 에이전트 실행기를 직접 조립해야 하는 비용은 줄어듭니다.

반대로 에이전트가 더 오래, 더 많은 일을 할 수 있게 될수록 어떤 행동을 허용하고 어디에서 사람에게 승인을 받을 것인지가 중요해집니다.

Lee's Take 에이전트 제품의 차이는 점점

“무엇을 자동화할 수 있는가?” 보다

“어디까지 자동화하고, 어디에서 사람이 책임지는가?”

에서 생길 것 같습니다.

L-Proof-AI 역시 자료 수집과 초안 생성까지는 AI가 진행하더라도 최종 발송은 사람이 승인해야 한다는 선을 제품 규칙으로 두는 편이 맞다고 봅니다.

이번 주 해볼 일 긴 작업 하나를 골라 자동 실행 구간 / 사람 승인 구간으로 나눠보기 외부 쓰기, 결제, 고객 발송처럼 되돌리기 어려운 행동은 별도 승인 단계로 분리하기 실패했을 때 재시도할지, 중단할지, 사람에게 돌려보낼지 미리 정하기 원문: https://openai.com/index/introducing-the-agents-api/

GitHub Copilot 코드 리뷰가 ‘댓글’에서 ‘검증 루프’로 이동

PROOF LEVEL 03 · 공식 확인

GitHub는 9월 11일 Copilot code review의 업데이트를 발표했습니다.

새로운 커밋이 기존 리뷰 의견을 해결했는지 다시 확인해 처리된 코멘트를 자동으로 정리하고, Copilot의 수정 제안을 적용할 때 변경 내용에 맞는 커밋 메시지를 생성합니다.

리뷰 과정에서 사용할 수 있는 셸 도구도 확대됐습니다. 빌드, 테스트, 스크립트 실행 등을 이용해 리뷰 결과를 검증할 수 있으며 Lite 리뷰에는 여러 에이전트의 분석을 합치는 방식도 적용됐습니다.

개발자에게 중요한 점 AI 리뷰의 병목이 단순히

“버그를 몇 개 찾아냈는가”

에서

“그 지적이 실제 수정으로 이어졌고, 수정됐다는 것을 다시 검증할 수 있는가”

로 이동하고 있습니다.

Lee's Take AI 리뷰의 성공 지표를 ‘코멘트 수’로 잡으면 오히려 소음이 늘어날 수 있습니다.

제가 보고 싶은 것은 이런 숫자입니다.

AI가 지적한 문제 중 실제 반영된 비율 같은 문제가 다시 발생한 비율 AI 수정 이후 사람이 다시 수정한 비율 수정 후 테스트에서 실제로 문제가 해결됐는지 AI가 리뷰어 역할까지 가져간다면 발견보다 검증 루프가 중요합니다.

이번 주 해볼 일 AI 리뷰 코멘트 가운데 실제 반영된 비율을 기록해보기 자동 수정 후 diff와 테스트 결과를 함께 확인할 수 있는 흐름 만들기 원문: https://github.blog/changelog/2026-09-11-auto-resolution-and-analysis-updates-in-copilot-code-review/

Cursor Projects: 에이전트의 단위가 ‘채팅’에서 ‘프로젝트’로

PROOF LEVEL 03 · 공식 확인

Cursor는 9월 10일 Projects를 발표했습니다.

Projects는 기능 개발이나 마이그레이션처럼 오래 걸리는 작업의 컨텍스트를 유지하고, 코디네이터 에이전트가 작업을 여러 서브에이전트에게 나눠 맡길 수 있게 합니다.

프로젝트는 클라우드 환경에서 계속 실행될 수 있으며, 일정이나 Slack, PR 같은 신호에 따라 반복 작업을 수행하는 구조도 제공합니다.

개발자에게 중요한 점 에이전트의 단위가

한 번의 채팅 → 계속 운영되는 프로젝트

로 변하고 있습니다.

그 순간부터 AI가 기억하는 정보와 현재 작업 상태도 일종의 애플리케이션 상태가 됩니다.

누가 무엇을 맡았는지, 어떤 결과를 신뢰할 수 있는지, 실패했을 때 다음 작업을 계속할 것인지 같은 것을 코드와 비슷한 수준으로 관리해야 합니다.

Lee's Take 장기 에이전트가 가치 있는 이유를 단순히

“기억을 오래 한다”

라고 생각하지 않습니다.

오히려 중요한 것은 사람이 며칠 뒤 다시 들어왔을 때

왜 지금 이런 상태가 되었는지 설명할 수 있는가

입니다.

긴 기억보다 추적 가능한 상태가 더 중요할 수 있습니다.

이번 주 해볼 일 반복 업무 하나를 골라 다음 네 가지를 문서화해보기.

입력 결과물 승인자 실패 시 동작 그리고 승인되지 않은 결과는 다음 단계로 넘어가지 않는 것을 기본값으로 두기.

원문: https://cursor.com/changelog

직접 써본 Jev: 모든 판단에 LLM이 필요한 것은 아니었다

PROOF LEVEL 03 · 공식 확인 + 직접 테스트

TypeSafe AI는 9월 15일 첫 번째 System One Model인 Jev를 공개했습니다.

일반적인 LLM처럼 자유로운 문장을 생성하는 대신, 프로그램이 미리 정의한 선택지에 대해 typed decision과 확률·confidence를 반환하는 모델입니다.

처음에는 저도 “이걸 굳이 LLM 대신 왜 사용하지?”라는 생각이 있었습니다.

직접 작은 프로젝트에 적용해보니 답은 꽤 명확했습니다.

Fit한 상황에서는 굉장히 강하다 제가 테스트한 HowMuchCaloriesLeft라는 칼로리 기록 프로젝트를 예로 들겠습니다.

사용자가 이렇게 말할 수 있습니다.

“아까 밥은 반 정도 남겼어.”

애플리케이션이 알아야 하는 것은 멋진 답변이 아닙니다.

먼저 이 입력이

새로운 음식 추가인지 기존 기록 수정인지 기록 삭제인지 단순 질문인지 판단해야 합니다.

그리고 기존 기록 수정이라면 어떤 기록을 수정해야 하는지, 확신이 낮다면 사용자에게 다시 물어볼지도 결정해야 합니다.

이런 분류·라우팅·점수화·분기에서는 Jev의 구조가 상당히 잘 맞았습니다.

결과가 자연어가 아니라 처음부터 프로그램이 사용할 수 있는 선택지와 확률로 돌아오기 때문입니다.

그런데 Fit하지 않은 곳까지 쓰면 오히려 불편하다 반대로 이런 작업은 일반 LLM이 훨씬 자연스러웠습니다.

음식 이름과 양을 자연어에서 해석하기 사용자의 애매한 표현을 이해하기 자유로운 대화 생성하기 후보를 새로 만들어내기 음식 정보를 바탕으로 칼로리를 추정하기 Jev는 범용 LLM의 작은 버전도, Codex나 Claude Code 같은 개발 에이전트도 아니었습니다.

정해진 선택지가 존재하고 프로그램이 그 판단을 바로 사용해야 하는 구간에서 잘 맞는 별도의 도구에 가까웠습니다.

Lee's Take 이번 테스트에서 가장 흥미로웠던 점은

AI가 더 강해졌다고 모든 문제를 하나의 강한 LLM에게 맡기는 것이 최선은 아니라는 것

이었습니다.

문장을 만들어야 하는 곳에는 LLM을 쓰고,

복잡한 일을 오래 수행해야 하는 곳에는 에이전트를 쓰고,

정해진 상태 안에서 빠르게 판단해야 하는 곳에는 Jev 같은 decision model을 쓸 수 있습니다.

결국 중요한 것은 어떤 모델이 가장 강한지가 아니라

“이 판단에는 어느 정도의 자유가 필요한가?”

인 것 같습니다.

자유도가 높아질수록 할 수 있는 일은 많아집니다.

동시에 검증해야 할 것도 늘어납니다.

이번 주 해볼 일 현재 LLM으로 처리하고 있는 작업 하나를 골라 질문해보기.

“여기서 정말 문장을 생성해야 하는가?”

결과가 결국 A/B/C, true/false, 점수, 라우팅처럼 몇 개의 선택지로 귀결된다면 범용 LLM 호출이 과한 구조일 수도 있습니다.

반대로 새로운 후보를 만들거나 맥락을 깊게 해석해야 한다면 억지로 판단 모델에 넣지 말고 LLM에게 맡기는 편이 낫습니다.

이번 호의 결론 이번 주 발표들을 보면 AI 개발은 점점 모델을 호출하는 것에서 AI가 실제 업무를 수행하도록 만드는 것으로 이동하고 있습니다.

그런데 자동화가 커질수록 사람이 사라지는 것은 아닙니다.

오히려 사람이 개입해야 할 지점을 더 명확하게 설계해야 합니다.

그리고 Jev를 직접 써보면서 여기에 하나를 더 추가하고 싶어졌습니다.

모든 AI에게 최대한 많은 자유를 줄 필요도 없습니다.

생성해야 할 때는 생성하게 하고, 판단해야 할 때는 판단하게 하고, 사람이 책임져야 할 순간에는 멈추게 하는 것.

결국 AI 제품의 설계는 점점

모델 선택보다 권한 설계에 가까워지고 있습니다.