코딩 에이전트 시대, 개발자는 코드를 쓰는 사람에서 실행을 감시하는 사람으로 밀려나는 중

ChatGPT에서 Devin까지, 16개월 만에 바뀐 판

• 2024년 3월 Cognition Labs가 Devin 시연 영상을 공개하면서 개발자 커뮤니티가 꽤 세게 흔들림

  • 사람이 한 일은 Upwork 구인 글을 처리해달라는 목표를 입력한 것뿐이었음
  • Devin은 브라우저, 터미널, 코드 에디터를 열고 라이브러리 검색, 저장소 생성, 코드 작성, 실행, 오류 수정, 결과 제출까지 혼자 이어감
  • 당시 개발자 타임라인에서 It's over라는 반응이 크게 퍼진 이유도 여기 있음. 자동완성이 아니라 실행 주체가 등장한 느낌이었거든

• Copilot과 Devin의 차이는 제안과 실행의 차이에 가까움

  • Copilot은 개발자가 코드를 쓰는 중간에 다음 줄을 제안하고, 수락 여부는 인간이 결정함
  • Devin은 어떤 라이브러리를 쓸지, 어떤 순서로 만들지, 오류를 어떻게 고칠지까지 AI가 결정함
  • 인간은 키보드 앞의 작성자라기보다, 목표를 던지고 결과를 지켜보는 관찰자에 가까워짐

• 이 변화가 1년 4개월 만에 벌어졌다는 게 진짜 무서운 포인트임

  • 2022년 11월 ChatGPT는 텍스트 답변을 잘하는 대화형 AI였음
  • 2023년 3월 GPT-4는 코드 작성, 오류 설명, 리팩토링에서 전문 개발자에 가까운 결과를 보여주기 시작함
  • 2023년 플러그인과 도구 사용이 열리면서 AI가 웹 검색, 계산기, 코드 실행기, 외부 API를 호출할 수 있게 됨
  • 2024년 3월 Devin은 긴 맥락, 도구 호출, 계획 루프를 묶어 하나의 프로젝트 수행자로 포장해낸 사례였음

도구와 에이전트의 경계

• 도구는 사람이 한 번 쓰고 결과를 받는 물건임

  • 계산기, 망치, 자동완성, Copilot의 한 줄 제안은 이쪽에 가까움
  • 중간 판단과 책임의 중심은 여전히 인간에게 있음

• 에이전트는 목표를 받고, 여러 단계를 스스로 실행하는 존재임

  • 계획을 세우고, 도구를 부르고, 결과를 관찰하고, 다음 행동을 고름
  • 인간은 최종 결과를 받거나, 운 좋으면 중간에 끼어들 뿐임

• 이 차이가 큰 이유는 개발자가 읽어야 하는 대상이 바뀌기 때문임

  • 예전에는 사람이 코드를 쓰고, 사람이 읽고, 사람이 실행했음
  • 에이전트 시대에는 AI가 명령을 실행하고, 인간은 나중에 로그나 diff를 읽는 구조가 됨
  • 이해가 실행보다 늦게 도착하면, 리뷰는 설계가 아니라 사후 수습이 됨

sequenceDiagram
    participant 개발자
    participant 에이전트
    participant 도구
    participant 코드베이스
    participant 실행환경
    개발자->>에이전트: 목표 전달
    에이전트->>코드베이스: 파일과 문맥 읽기
    에이전트->>도구: 검색, 셸, 편집 호출
    도구->>실행환경: 명령 실행
    실행환경-->>에이전트: 로그와 오류 반환
    에이전트->>코드베이스: 수정 반영
    에이전트-->>개발자: 결과와 diff 제시

LLM이 운영체제처럼 보이기 시작한 이유

• 카르파시는 2024년 강연에서 LLM이 운영체제와 닮아간다고 봤음

  • 컨텍스트 윈도우는 RAM처럼 현재 작업 정보를 담는 공간임
  • 파일 읽기, 웹 검색, 코드 실행, API 호출은 입출력 장치처럼 작동함
  • 모델 가중치는 쉽게 바뀌지 않는 핵심 층이고, 그 위에서 에이전트가 프로세스처럼 돌아감

• 이 비유가 찝찝한 이유는 1960년대 메인프레임 시절과 닮았기 때문임

  • 가장 강한 모델은 클라우드에 집중되어 있고, 사용자는 API로 접속해 토큰 단위로 지능을 빌려 씀
  • 개인용 컴퓨팅이 오기 전 얇은 터미널로 중앙 컴퓨터를 나눠 쓰던 풍경과 비슷함
  • 로컬에서 완전히 통제하는 LLM의 퍼스널 컴퓨팅은 아직 대중화됐다고 보기 어려움

• 운영체제가 너무 커지면 아무도 전체를 이해하지 못했던 것처럼, 에이전트도 행동 공간이 커질수록 추적이 어려워짐

  • 어떤 파일을 읽었는지, 왜 그 라이브러리를 골랐는지, 어떤 실패를 무시했는지까지 따라가야 진짜 이해임
  • 로그가 남는 것과 사람이 그 로그를 읽는 것은 완전히 다른 문제임

Cursor는 개발자를 구현자에서 리뷰어로 옮겼음

• Cursor는 완전 자율 에이전트는 아니지만, 단순 도구라고 하기엔 이미 많이 들어와 있음

  • Cmd+K는 선택한 코드 구간을 AI가 수정함
  • Cmd+L은 코드베이스 맥락을 읽은 AI와 에디터 안에서 대화하게 해줌
  • Composer나 Agent 모드는 여러 파일에 걸친 변경을 만들고, 개발자는 diff를 검토함

• 사용자들이 코드를 쓴다기보다 설계한다는 말을 하는 이유가 있음

  • 인간은 무엇을 만들지 자연어로 설명함
  • AI는 어떻게 구현할지를 코드로 풀어냄
  • 개발자는 최종 diff를 읽고 수락하거나 거부함

• 문제는 생각과 코드 사이의 마찰이 사라질 때, 이해의 과정도 같이 얇아질 수 있다는 점임

  • 예전에는 구현 과정에서 설계의 빈틈을 직접 마주쳤음
  • 이제는 AI가 빈틈을 임의로 메워서 동작하는 코드를 가져올 수 있음
  • 그럴듯한 diff를 읽는 능력이, 직접 짜는 능력만큼 중요해지는 흐름임

자율성의 딜레마는 생산성 문제가 아니라 안전 문제임

• 에이전트의 가치는 자율성에서 나오지만, 위험도 정확히 그 자율성에서 나옴

  • 사람이 일일이 지시하지 않아도 일이 진행되면 생산성은 올라감
  • 사람이 일일이 검토하지 않으면 실수도 실행된 뒤에야 발견됨
  • 자율성을 낮추면 안전하지만, 에이전트의 매력은 줄어듦

• 카르파시의 자율성 슬라이더 비유가 여기서 잘 맞음

  • 자동완성은 인간이 거의 모든 결정을 함
  • 함수 수정, 파일 수정, 저장소 전체 작업으로 갈수록 AI의 결정 비중이 커짐
  • 독립 프로젝트 완료 단계에서는 AI가 대부분을 결정하고 인간은 결과만 보는 쪽에 가까움

• 2024년 기준 코딩 에이전트는 아직 읽기에서 많이 무너졌음

  • SWE-bench 같은 실제 소프트웨어 엔지니어링 과제에서 당시 최고 모델 해결률은 약 40%대였음
  • 실패 상당수는 잘못된 파일 수정, 기존 코드 오해, 문서 제약 무시에서 나왔음
  • 코드는 쓸 수 있었지만 요구사항과 맥락을 읽는 능력은 불안정했다는 얘기임

오픈 가중치의 역설

• 2023년 LLaMA 가중치 유출과 이후 Llama 2 공개는 생성AI 생태계의 변곡점이었음

  • 2022년 생성AI 관련 GitHub 프로젝트는 1만 7천 개 수준이었음
  • 2023년에는 6만 5천 개로 늘었고, 증가율은 248%였음
  • Hugging Face 모델 저장소는 2023년 말 32만 개 이상, 월간 활성 사용자 600만 명을 넘었다고 설명됨

• 오픈소스 코드 공개와 오픈 가중치 공개는 같은 개방처럼 보여도 성격이 다름

  • 소스 코드는 사람이 읽고 고칠 수 있는 형태임
  • 모델 가중치는 수천억 개 부동소수점 숫자라서 접근은 가능해도 의미를 읽기는 어려움
  • 접근권이 생겼다고 이해 능력이 같이 생기는 건 아님

• 그래서 코드는 산출물이 아니라 원재료가 되고 있음

  • 모델, 에이전트, 파이프라인의 입력으로 코드가 계속 소비됨
  • 개발자는 정확히 어떻게 작동하는지 모르지만 작동한다는 상태를 더 자주 받아들이게 됨
  • 이건 생산성의 승리처럼 보이지만, 장기 유지보수 관점에서는 꽤 큰 부채가 될 수 있음

결국 질문은 하나로 모임

• 에이전트 시대의 핵심 질문은 AI가 코드를 쓸 수 있느냐가 아님

  • 이미 코드는 꽤 잘 씀
  • 문제는 어떤 판단으로 그렇게 썼는지 사람이 추적할 수 있느냐임

• 감사 기록은 기본 요구사항이지만, 로그가 있다고 끝이 아님

  • LangChain, LlamaIndex, AutoGen, CrewAI 같은 프레임워크는 대체로 실행 로그를 남김
  • 하지만 npm 의존성처럼, 기록은 있어도 실제로 읽히지 않으면 운영상 없는 것과 비슷함

• 권한 제한은 각 팀이 직접 선을 그어야 하는 가치 판단임

  • 모든 명령을 승인하게 하면 에이전트의 의미가 줄어듦
  • 전부 허용하면 한 번의 실수로 프로덕션 데이터나 고객 환경을 날릴 수 있음
  • 결국 팀마다 어떤 작업은 수트처럼 인간을 증폭하고, 어떤 작업은 절대 로봇처럼 혼자 두면 안 되는지 정해야 함

기술 맥락

• 이 글에서 가장 중요한 기술적 선택은 에이전트를 어디까지 자율적으로 둘 것인가예요. 자동완성 수준이면 개발자가 모든 결정을 붙잡고 있지만, 저장소 전체 수정이나 배포까지 맡기는 순간 AI가 실행의 주체가 되거든요.

• 그래서 권한 모델이 생산성 옵션이 아니라 아키텍처 문제가 돼요. 파일 읽기, 셸 실행, 네트워크 접근, 데이터베이스 변경 같은 권한을 하나로 묶어 허용하면 편하긴 한데, 사고가 났을 때 피해 범위도 같이 커져요.

• 감사 로그도 그냥 디버그 출력 정도로 보면 안 돼요. 에이전트가 어떤 파일을 읽고, 어떤 도구를 호출했고, 어떤 오류를 보고도 계속 진행했는지가 남아야 나중에 책임 소재와 재현 가능성을 따질 수 있어요.

• Cursor 같은 중간형 도구가 현실적인 이유는 인간이 루프 안에 남아 있기 때문이에요. AI가 코드를 많이 만들더라도 diff를 읽고 수락하는 절차가 있으면, 최소한 이해가 완전히 사라지지는 않거든요.

• 오픈 가중치 모델을 쓰는 팀도 같은 질문을 피할 수 없어요. 모델을 내려받아 돌릴 수 있다는 것과 그 모델의 학습 데이터, 편향, 실패 조건을 이해한다는 것은 다르기 때문에 운영 환경에서는 검증 체계를 따로 가져가야 해요.