코딩 에이전트가 코드를 다 쓰면, 병목은 어디로 가는가

요즘 고객 미팅에서 DevOps 얘기를 하다 보면 반드시 이 질문이 나온다. "그래서 Claude Code 나 Cursor 같은 것들이랑은 어떻게 되는 건가요?" 좋은 질문이고, 우리 입장에서는 반가운 질문이다. 코딩 에이전트가 잘될수록 우리가 만드는 것의 가치가 올라간다고 생각하기 때문이다. 이 글은 그 이유를 설명하는 글이다.

코드가 싸지면 무슨 일이 생기는가

Claude Code, Cursor 같은 도구들이 실제로 무너뜨리고 있는 것은 "코드를 작성하는 비용"이다. 우리 팀만 봐도 그렇다. 초기에는 PR 이 일주일에 세 개쯤 올라왔는데 지금은 수십 개씩 올라온다. 사람이 갑자기 열 배 부지런해진 게 아니다. 코드를 만드는 단계의 마찰이 사라진 것이다.

그런데 소프트웨어를 만드는 전체 흐름에서 코드 작성은 한 구간일 뿐이다. 병목 하나가 사라지면 흐름이 빨라지는 게 아니라, 다음 병목이 드러난다. 제약 이론이 말하는 그대로다. 코드 생산이 열 배가 되는 순간 조직은 세 가지 질문 앞에 선다.

• 이 에이전트는 무엇을 알고 코드를 썼는가 (컨텍스트의 문제)
• 이 코드는 어떤 경로로 시스템에 들어오는가 (실행의 문제)
• 이 변경을 누가 언제 허락했는가 (권한과 추적의 문제)

에디터 안에서 코드를 만드는 일은 에이전트가 한다. 그 코드가 이슈가 되고, 변경요청이 되고, 파이프라인을 통과해서, 승인을 받고, 배포 이력으로 남는 일. 여기가 이제 병목이고, 여기가 우리가 서 있는 자리다.

에이전트는 무엇을 알고 코드를 쓰는가

에이전트의 출력 품질은 모델 성능 곱하기 컨텍스트 품질이다. 앞의 항은 모델 회사들이 올려 준다. 뒤의 항이 조직의 몫이다.

수정하려는 소스만 보고 좋은 수정을 할 수는 없다. 연결된 소스를 봐야 하고, 그 코드가 왜 그렇게 생겼는지를 담은 이슈와 문서를 봐야 하고, 지난번 비슷한 변경이 어떤 장애를 냈는지를 봐야 한다. 사람 시니어 개발자가 머릿속에 들고 다니는 그 맥락이다.

도구가 파편화된 환경에서 에이전트에게 이 맥락을 주려면 이슈 트래커 API 토큰, 저장소 API 토큰, CI API 토큰, 위키 API 토큰을 발급하고, 각각의 응답 스키마를 이어 붙이는 접착 코드를 짜야 한다. 해 본 사람은 안다. 되긴 되는데, 토큰 관리부터 rate limit 까지 전부가 운영 부담이고, 그렇게 모은 데이터는 서로를 모르는 조각들이다. 이슈 #1234 와 커밋 abc123 이 관련 있다는 사실은 어느 API 응답에도 없다.

우리가 택한 구조는 다르다. 이슈, 문서, 코드, 빌드, 배포가 처음부터 고유 ID 기반의 하나의 그래프 위에 있다. 문서는 옵시디언처럼 서로 링크되고 그래프 뷰로 열린다. 에이전트는 이 그래프를 타고 이동한다. "이 이슈와 연결된 커밋 → 그 커밋이 건드린 모듈 → 그 모듈을 참조하는 다른 소스 → 그 소스에 얽힌 과거 장애 이슈." 평평한 테이블을 검색하는 게 아니라 관계를 따라가는 것이고, 이 관계는 누가 손으로 만들어 주는 게 아니라 일하는 과정에서 자동으로 생긴다.

미팅에서 이 부분을 설명하면 꼭 나오는 질문이 있다. "그 그래프는 누가 만들어요?" 아무도 안 만든다. 그게 요점이다.

코드는 어떤 경로로 시스템에 들어오는가

컨텍스트가 입력이라면 실행은 출력이다. 에이전트가 판단만 하고 실행을 못 하면 비서고, 실행까지 하면 동료다.

우리는 터미널에서 쓰는 CLI 를 제공한다. 사람을 위해 만들었지만, 지금 이 CLI 의 가장 부지런한 사용자는 Claude Code 다. 에이전트가 CLI 로 이슈를 만들고, 상태를 파악하고, 변경요청을 열고, 파이프라인 로그를 읽는다. 실제로 우리 내부에서는 이슈에서 에이전트가 소규모 변경요청을 직접 생성해서 수정 제안까지 붙이는 흐름을 쓰고 있고, 슬랙에서는 파이프라인이 깨졌을 때 에이전트가 에러 메시지를 중계하는 게 아니라 원인 분석과 진단을 달아 준다. 새벽에 온콜을 받아 본 사람이라면 "빌드 실패"라는 알림과 "이 커밋의 이 변경이 이 모듈과 충돌해서 실패했고, 이렇게 고치면 된다"는 알림의 차이를 안다.

에디터 안의 에이전트와 플랫폼 위의 에이전트는 대체 관계가 아니라 연장 관계다. Cursor 가 만든 코드도 결국 어딘가의 이슈에서 출발해서 어딘가의 파이프라인을 통과해야 한다. 그 통로가 에이전트에게 열려 있느냐, 사람이 중간에서 복사-붙여넣기로 나르느냐의 차이다.

그러면 사람은 무엇을 하는가

한 공공기관 미팅에서 데모를 보던 분이 이렇게 말했다. "이러면 사람은 거의 코드를 안 짜겠네요?" 맞다. 방향은 그쪽이다. 사람은 명세와 승인을 한다.

그런데 이 문장이 성립하려면 조건이 있다. 승인이 의미를 가지려면 승인 대상이 추적 가능해야 한다. 에이전트가 무엇을 근거로 무엇을 바꿨는지, 사람이 어느 지점에서 개입했는지, 그 개입까지 포함해서 전부 이력으로 남아야 한다. 에이전트의 행위가 추적되지 않는 조직에서 "AI 가 코드를 짠다"는 생산성 이야기가 아니라 감사 리스크 이야기가 된다.

그래서 권한 모델과 승인 게이트는 에이전트 시대에 장식이 아니라 전제 조건이다. 변경요청 승인이 파이프라인 게이트로 걸려 있으면, 에이전트가 하루에 CR 을 백 개 만들어도 프로덕션으로 가는 길목은 여전히 사람이 지킨다. 코드 생산량이 열 배가 될 때 필요한 것은 열 배 빠른 리뷰어가 아니라, 무엇이 리뷰를 통과해야 하는지가 시스템에 새겨진 구조다.

온프레미스라는 조건

이 그림에서 자주 빠지는 조건이 하나 있다. 한국 엔터프라이즈와 공공의 상당수는 폐쇄망이다. Claude 를 API 로 못 부른다.

그래서 우리는 LLM 레이어를 추상화해 뒀다. Claude, Gemini 같은 상용 모델도 붙지만, GPU 만 있으면 Qwen 계열 오픈소스 모델로 스위칭된다. 물론 오픈소스 모델의 기본기는 프론티어 모델보다 처진다. 그 간극을 하네스 엔지니어링으로 메우는 게 지금 우리가 연구 과제로 붙들고 있는 일이다. 모델 자체를 다시 학습시키는 게 아니라, 컨텍스트를 어떻게 썰어서 주고 도구를 어떻게 쥐여 주고 검증 루프를 어떻게 감는지로 실효 성능을 끌어올리는 것. 목표는 폐쇄망 안에서 온콜 대응과 장애 진단이 실용 수준으로 되는 것이다.

솔직하게 적어 두면, 지금 우리 에이전트는 작은 일을 한다. 소규모 변경요청, 진단, 요약. 대규모 신규 개발을 에이전트가 주도하는 그림은 아직 실험이고, GPU 도 늘 모자라다. 다만 방향에 대한 확신은 있다. 코드 작성이 싸지는 추세는 되돌아가지 않을 것이고, 그 세계에서 조직의 경쟁력은 에이전트가 아니라 에이전트가 딛고 설 바닥에서 갈릴 것이다. 컨텍스트 그래프, 실행 통로, 승인 구조 같은 것들 말이다.

에디터는 이미 좋아졌다. 이제 에이전트에게 회사를 줄 차례다.