사내 AI 코딩 에이전트가 비슷한 구조로 수렴하는 이유 — Open SWE 패턴 5가지와 내 하네스 비교

AI 코딩 에이전트 얘기를 보다 보면 이름은 달라도 구조는 자꾸 비슷해진다.

슬랙에서 호출되고, 격리된 실행 환경에서 돌고, 필요한 도구만 좁게 붙고, 시작할 때 이미 컨텍스트를 잔뜩 먹고, 일이 커지면 서브에이전트로 쪼개진다. LangChain이 공개한 Open SWE를 보면서 든 생각도 딱 그거였다. “이거 다들 결국 비슷한 데로 모이는구나.”

이 글은 Open SWE를 소개하려는 글이 아니다. 오히려 왜 내부 코딩 에이전트가 비슷한 구조로 수렴하는지, 그리고 그게 우리 같은 실전 운영팀에 왜 중요한지를 정리하려는 글이다.

Quick Answer

사내 AI 코딩 에이전트가 비슷한 구조로 수렴하는 이유는 간단하다. 잘못 만들면 바로 비용, 권한, 복구, 리뷰가 터지기 때문이다. 그래서 결국 다들 격리된 샌드박스, 좁은 도구셋, 풍부한 시작 컨텍스트, 이벤트 기반 handoff, 검증 가능한 서브에이전트 분리 쪽으로 모인다.

지금 결론

에이전트가 똑똑한 것보다 실행 환경이 격리돼 있는 게 먼저다.
도구는 많을수록 좋은 게 아니라 적을수록 안전한 경우가 많다.
시작 컨텍스트는 길다고 좋은 게 아니라, 발견 불가 지식 위주여야 한다.
멀티에이전트는 멋있어서 쓰는 게 아니라, 검증 가능한 단위로 쪼개기 위해 쓴다.

Open SWE가 정리한 패턴 5가지

1. 격리된 샌드박스

Open SWE가 가장 먼저 강조하는 건 화려한 모델이 아니라 샌드박스다. Modal, Daytona, Runloop 같은 분리된 실행 환경을 붙여서 각 작업의 blast radius를 줄이는 구조다.

이건 실제 운영에서 아주 현실적이다. 에이전트가 코드를 고치다 망가뜨려도, 같은 작업공간 전체를 오염시키면 안 되기 때문이다.

2. 큐레이션된 도구셋

도구를 아무거나 잔뜩 붙이면 에이전트가 더 똑똑해질 것 같지만, 실전은 반대다. 자주 쓰는 execute, fetch_url, commit_and_open_pr, linear_comment, slack_thread_reply 같은 좁은 셋이 오히려 유지보수가 편하다.

우리 쪽도 비슷했다. 도구가 많을 때보다 “이 일엔 이 도구만 쓴다”가 박혀 있을 때 재작업이 줄었다.

3. 풍부한 시작 컨텍스트

에이전트는 빈 화면에서 갑자기 천재가 되지 않는다. 어떤 저장소인지, 어디가 민감한 파일인지, 이번 작업이 어떤 이슈와 연결되는지 미리 먹여줘야 한다.

다만 여기서 함정이 있다. 스스로 찾을 수 있는 디렉토리 구조를 또 주면 오히려 컨텍스트 낭비가 생긴다. 그래서 진짜 중요한 건 “에이전트가 알아서 못 찾는 규칙”이다.

4. Slack/Linear/GitHub handoff

실제 팀에서는 에이전트가 혼자 완결되지 않는다. 누가 요청했고, 어디까지 했고, 누구한테 넘길지 handoff가 붙어야 팀이 굴러간다. Open SWE가 Slack, Linear, GitHub를 붙이는 것도 이 맥락이다.

결국 핵심은 “에이전트가 뭘 했냐”보다 “팀 안에서 그 결과가 어떻게 닫히냐”다.

5. 서브에이전트 오케스트레이션

일이 커지면 하나의 에이전트가 다 잘할 수 없다. 리서치, 코드 수정, 검증, 보고를 분리해야 한다. Open SWE가 Deep Agents, LangGraph 쪽으로 가는 것도 이 때문이고, 우리도 분석팀, 글감팀, 발행팀을 나누는 이유가 결국 같다.

내 하네스와 비교하면 어디가 닮았나

Open SWE를 보면서 제일 닮았다고 느낀 건 세 가지였다.

상태를 문서가 아니라 실행 흐름으로 본다는 점
도구를 늘리기보다 호출 규칙을 줄인다는 점
마지막 검증을 따로 둔다는 점

반대로 차이도 있다.

Open SWE는 코딩 작업 중심이다.
우리 하네스는 콘텐츠 운영과 publish contract 같은 장부 마감이 더 강하다.
그래서 우리는 “코드가 맞냐”보다 “루프가 닫혔냐”를 더 세게 본다.

실수 TOP 3

실수 1. 도구를 너무 많이 붙인다

모든 도구를 다 붙이면 에이전트가 자유로워지는 게 아니라 길을 잃는다.

실수 2. 샌드박스보다 프롬프트를 먼저 만진다

실패 원인이 권한·격리·복구인데 프롬프트만 만지면 땜질만 된다.

실수 3. 멀티에이전트를 역할놀이처럼 쓴다

역할 이름만 많고 handoff 조건이 없으면 오히려 더 느려진다.

언제 이 구조가 특히 쓸모 있나

PR 자동 리뷰를 붙이고 싶을 때
Slack/이슈/커밋을 한 루프로 묶고 싶을 때
에이전트가 잘못했을 때 복구 비용이 큰 팀
“한 명의 천재 에이전트”보다 “검증 가능한 팀 루프”가 필요한 팀

FAQ

Q. 결국 다들 같은 구조로 가면 차별점은 뭐야?

A. 모델 성능보다 권한 경계, handoff 설계, 검증 기준, 운영 비용에서 차이가 난다.

Q. AGENTS.md 같은 문서만 잘 쓰면 되나?

A. 아니다. 문서는 시작점일 뿐이고, 진짜 차이는 실행 환경과 검증 루프에서 난다.

Q. 개인 프로젝트에도 이런 구조가 필요해?

A. 작은 프로젝트면 축약해서 써도 된다. 다만 배포나 권한이 걸리는 순간 샌드박스와 검증 분리는 빨리 필요해진다.

출처

LangChain blog, “Open SWE: An Open-Source Framework for Internal Coding Agents” (2026-03-19 요약 메모 기준)