AI 코딩 에이전트는 어떻게 만들어질까? 핵심 구성 요소 완전 해부

요즘 Cursor, GitHub Copilot, Claude Code 같은 AI 코딩 도구를 써보신 분 많으시죠? 코드를 짜달라고 하면 알아서 파일을 읽고, 수정하고, 심지어 터미널 명령어까지 실행하는 모습을 보면 "이거 어떻게 만든 거지?" 하는 궁금증이 생기게 되는데요. Sebastian Raschka가 이 "코딩 에이전트"라는 것이 실제로 어떤 부품들로 구성되어 있는지를 체계적으로 정리한 글을 공개했어요.

코딩 에이전트, 챗봇과 뭐가 다른 건데?

먼저 기본적인 차이부터 짚고 넘어갈게요. 우리가 ChatGPT한테 "이 코드 고쳐줘"라고 물어보면, 텍스트로 답변을 줄 뿐이에요. 복사해서 붙여넣기하는 건 우리 몫이죠. 반면 코딩 에이전트는 직접 파일 시스템에 접근해서 코드를 읽고, 수정하고, 실행 결과까지 확인해요. 이게 뭐냐면, 단순히 "답을 아는 AI"가 아니라 "실제로 일을 하는 AI"라는 뜻이에요. 마치 시니어 개발자한테 "이 버그 좀 잡아주세요"라고 하면, 그 사람이 직접 IDE를 열고 코드를 보고 수정하는 것처럼요.

핵심 구성 요소 하나씩 뜯어보기

1. LLM 백본 — 두뇌 역할

에이전트의 중심에는 당연히 대형 언어 모델(LLM)이 있어요. 이 모델이 "어떤 파일을 읽어야 하지?", "다음에 뭘 해야 하지?"를 판단하는 두뇌 역할을 하거든요. 여기서 중요한 건 단순히 모델이 똑똑한 것만으로는 부족하다는 점이에요. 에이전트용 LLM은 도구를 호출하는 능력(tool use 또는 function calling)이 잘 훈련되어 있어야 해요. "이 함수를 이런 파라미터로 호출해야겠다"는 판단을 JSON 같은 구조화된 형태로 정확하게 출력할 수 있어야 하거든요.

2. 도구(Tools) — 손과 발

두뇌만 있으면 아무것도 못 하겠죠? 에이전트에게는 실제로 세상과 상호작용할 수 있는 도구들이 필요해요. 대표적으로 이런 것들이 있어요:

파일을 읽고 쓰는 도구, 터미널 명령어를 실행하는 도구, 코드를 검색하는 도구(grep, find 같은), 그리고 웹 브라우저나 API를 호출하는 도구 등이에요. 이 도구들이 잘 설계되어 있을수록 에이전트가 더 정확하게 일할 수 있는데요, 예를 들어 파일 수정 도구가 "전체 파일을 덮어쓰기"만 지원한다면 작은 수정 하나에도 전체 파일을 다시 써야 하니까 비효율적이겠죠. 그래서 대부분의 에이전트는 특정 줄만 수정할 수 있는 정밀한 편집 도구를 제공해요.

3. 에이전트 루프 — 생각하고, 행동하고, 관찰하는 사이클

이게 에이전트의 핵심 동작 원리인데요, "생각(Think) → 행동(Act) → 관찰(Observe)"을 반복하는 루프예요. 이게 뭐냐면, LLM이 먼저 현재 상황을 보고 "다음에 뭘 해야 할지" 생각하고, 도구를 호출해서 행동하고, 그 결과를 관찰한 다음, 다시 생각하는 사이클을 돌리는 거예요. 버그를 고친다고 하면: "에러 메시지를 보니 auth.py 파일에 문제가 있을 것 같아 → auth.py를 읽어볼게 → 아, 42번째 줄에 타입 에러가 있네 → 이렇게 수정하면 되겠다 → 수정 → 테스트 돌려보자 → 통과!" 이런 식이에요.

4. 컨텍스트 관리 — 기억력의 한계 다루기

LLM에는 한 번에 처리할 수 있는 텍스트 양의 한계(컨텍스트 윈도우)가 있어요. 대규모 코드베이스의 파일을 전부 읽어서 넣을 수는 없으니까, 어떤 정보를 넣고 어떤 정보를 뺄지를 잘 관리해야 해요. 좋은 코딩 에이전트는 필요한 파일만 골라 읽고, 너무 긴 파일은 관련 부분만 발췌하고, 이전 대화가 길어지면 요약해서 압축하는 등의 전략을 써요. 이 부분이 실제로 에이전트 성능에 엄청난 영향을 미치거든요.

5. 안전장치(Guardrails) — 실수 방지

에이전트가 자유롭게 코드를 수정하고 명령어를 실행할 수 있다면, 실수로 중요한 파일을 삭제하거나 위험한 명령어를 실행할 수도 있겠죠? 그래서 권한 관리와 안전장치가 중요해요. 어떤 도구는 자동 실행을 허용하고, 어떤 도구는 사용자 승인을 받도록 하는 식의 설계가 필요해요.

기존 자동화 도구와는 어떻게 다를까?

"그러면 그냥 셸 스크립트나 CI/CD 파이프라인이랑 뭐가 다른 거야?"라고 물을 수 있는데요, 핵심 차이는 유연성이에요. 스크립트는 미리 정해진 순서대로만 실행하지만, 에이전트는 중간 결과를 보고 다음 행동을 스스로 결정해요. 테스트가 실패하면 에러 메시지를 읽고 다른 접근을 시도할 수 있는 거죠. 이건 기존의 rule-based 자동화로는 불가능했던 부분이에요.

현재 이 분야에서는 Anthropic의 Claude Code, OpenAI의 Codex, 그리고 Cursor나 Windsurf 같은 IDE 통합 에이전트들이 경쟁하고 있는데요. 각각 에이전트 루프의 구현 방식이나 도구 설계에서 미묘한 차이가 있어요. 예를 들어 어떤 에이전트는 계획을 먼저 세우고 실행하는 "plan-then-execute" 방식을 쓰고, 어떤 에이전트는 한 단계씩 진행하면서 계획을 수정하는 "adaptive" 방식을 써요.

한국 개발자에게 주는 시사점

이 글이 가치 있는 이유는, 코딩 에이전트를 단순히 "쓰는" 것에서 "이해하는" 단계로 넘어가게 해주기 때문이에요. 내부 구조를 알면 에이전트를 더 잘 활용할 수 있거든요. 예를 들어 컨텍스트 관리의 원리를 알면, 왜 큰 파일보다 작은 모듈로 코드를 나누는 게 에이전트 활용에 유리한지 이해할 수 있어요. 또한 직접 사내용 코딩 에이전트를 만들어보고 싶다면, 이 글이 아키텍처 설계의 좋은 출발점이 될 수 있어요. MCP(Model Context Protocol) 같은 표준이 나오면서 도구를 만들어 붙이기도 훨씬 쉬워졌고요.