코드 짜기 전에 '공부'부터 하는 AI 에이전트, 개발의 판을 바꾸다

AI 코딩 도구가 자동완성 수준에 머물던 시대는 끝나가고 있습니다. 최근 등장하는 AI 코딩 에이전트들은 코드를 생성하기 전에 프로젝트 문서를 먼저 읽고, API 레퍼런스를 훑고, 아키텍처를 파악합니다. 마치 신입 개발자가 첫 출근해서 위키부터 정독하는 것처럼요. 이 변화가 왜 중요한지 살펴보겠습니다.

기존 AI 코딩 도구의 한계: “일단 짜고 보자”

GitHub Copilot으로 대표되는 1세대 AI 코딩 도구는 기본적으로 자동완성이었습니다. 커서 위치의 맥락을 보고 다음에 올 코드를 예측하는 방식이죠. 빠르고 편리하지만, 근본적인 문제가 있었습니다.

프로젝트의 전체 구조를 모릅니다. 이 함수가 어떤 서비스에서 호출되는지, 이 라이브러리의 최신 API가 뭔지 파악하지 못합니다. 결과적으로 deprecated된 API를 추천하거나, 프로젝트 컨벤션과 동떨어진 코드를 생성하는 일이 빈번했습니다.

개발자들은 AI가 생성한 코드를 결국 한 줄 한 줄 검증해야 했고, “자동완성이 오히려 시간을 더 잡아먹는다"는 볼멘소리도 나왔습니다.

Research-Driven 에이전트: 먼저 읽고, 그다음에 짠다

새로운 패러다임의 AI 코딩 에이전트는 접근법이 다릅니다. 코드를 한 줄이라도 쓰기 전에 리서치 단계를 거칩니다.

구체적으로 이런 흐름입니다. 먼저 프로젝트의 README, 기여 가이드라인, 아키텍처 문서를 읽습니다. 그다음 관련 소스코드를 탐색하며 기존 패턴을 파악합니다. 외부 라이브러리를 사용해야 한다면 공식 문서와 최신 API 레퍼런스를 확인합니다. 이 모든 맥락을 갖춘 상태에서 비로소 코드를 작성합니다.

사람이 새 프로젝트에 투입됐을 때 하는 행동과 똑같습니다. 차이가 있다면, AI는 이 과정을 수 분 안에 해낸다는 것이죠.

SkyPilot 사례: 클라우드 인프라도 에이전트가 다룬다

UC 버클리에서 시작된 오픈소스 프로젝트 SkyPilot은 이런 에이전틱 접근법이 인프라 영역까지 확장되고 있음을 보여주는 좋은 사례입니다. SkyPilot은 원래 여러 클라우드 프로바이더(AWS, GCP, Azure 등)에 걸쳐 ML 워크로드를 최적 배치하는 프레임워크인데요.

최근 AI 에이전트와 결합되면서 흥미로운 시나리오가 가능해졌습니다. 에이전트가 SkyPilot의 문서를 먼저 학습하고, 사용자의 요구사항을 파악한 뒤, 최적의 클라우드 구성을 자동으로 작성하는 것입니다. GPU 가용성, 스팟 인스턴스 가격, 리전별 특성까지 고려해서요.

단순히 “YAML 설정 파일을 자동완성해주는” 수준이 아닙니다. 왜 이 구성이 최적인지를 문서 기반으로 판단하는 것이 핵심입니다.

에이전틱 개발이 바꾸는 것들

이 변화의 진짜 의미는 개발자의 역할 재정의에 있습니다.

첫째, 코드 리뷰의 성격이 바뀝니다. AI가 문서를 읽고 맥락을 이해한 상태에서 코드를 짜면, 리뷰어는 “이 API가 맞는지"를 확인하는 대신 “이 설계 방향이 맞는지"에 집중할 수 있습니다.

둘째, 문서의 가치가 올라갑니다. AI 에이전트가 문서를 기반으로 판단하기 때문에, 잘 정리된 문서가 곧 더 좋은 AI 코딩 결과로 이어집니다. “문서 안 써도 코드가 곧 문서"라던 개발 문화에 역설적인 반전이 생기는 셈이죠.

셋째, 온보딩 비용이 극적으로 줄어듭니다. 새 팀원이 프로젝트에 적응하는 데 걸리는 시간이 주 단위에서 시간 단위로 압축될 수 있습니다. AI 에이전트가 “이 프로젝트에서는 이런 패턴을 쓰고, 이 부분은 이런 이유로 이렇게 구성됐다"고 안내해주니까요.

아직 넘어야 할 산도 있다

물론 장밋빛 전망만 있는 건 아닙니다. 문서가 오래되었거나 부정확하면 에이전트도 잘못된 판단을 내립니다. 쓰레기가 들어가면 쓰레기가 나오는 원칙은 여전합니다. 또한 대규모 모노레포에서 관련 문서와 코드를 정확히 찾아내는 것도 아직 완벽하지 않습니다.

보안 측면의 우려도 있습니다. 에이전트가 외부 문서를 읽는 과정에서 악의적으로 조작된 콘텐츠에 노출될 가능성, 이른바 프롬프트 인젝션 문제는 여전히 활발하게 연구되고 있는 영역입니다.

코드를 짜기 전에 공부하는 AI 에이전트의 등장은 분명 올바른 방향입니다. 하지만 이것이 “개발자가 필요 없어지는 미래"를 뜻하진 않습니다. 오히려 좋은 문서를 쓰고, 좋은 설계 판단을 내리는 개발자의 가치가 더 높아지는 미래에 가깝습니다. 당신의 프로젝트 README, 마지막으로 업데이트한 게 언제인지 한번 돌아보시는 건 어떨까요?