“누가 만들었나”가 중요하지 않은 세상…에이전트 코딩의 끝없는 연쇄

필자는 아스트로(Astro)라는 매우 훌륭하고 비교적 새로운 웹 프레임워크를 사용한다. 아스트로 팀의 핵심 통찰은 대다수 웹사이트가 정적 콘텐츠로 구성된다는 점이었고, 덕분에 사이트에 콘텐츠를 추가하는 과정이 크게 간소화됐다. 개인 웹사이트에 블로그 게시물을 올리려면 프론트매터(front matter)가 포함된 마크다운(Markdown) 파일을 만들고 배포하기만 하면 게시물이 자동으로 나타난다. 더 동적인 기능이 필요할 때는 타입스크립트나 리액트(React), 또는 거의 모든 프레임워크를 손쉽게 활용할 수 있다. 정말 훌륭한 도구다.

요즘 필자는 코드를 거의 직접 작성하지 않는다. 클로드 코드(Claude Code)가 대다수(또는 전부의?) 작업을 처리한다. 아스트로는 오픈소스 프로젝트인 데다 문서화가 탁월하게 잘 되어 있어, 클로드 코드는 아스트로의 작동 방식을 완전히 파악하고 있다. 사이트 관리와 개선 요청도 전혀 어려움 없이 처리한다.

필자는 문득 이런 의문이 들었다. 아스트로 자체는 어떻게 개발되고 있을까? 아스트로 팀도 에이전트 코딩을 활용해 개발하고 있을까? 아스트로에는 비트(Vite)와 노드(Node) 같은 대형 프로젝트를 포함해 수많은 의존성이 존재한다. 물론 비트와 노드 역시 각자의 의존성을 가지고 있다. 그 의존성들은 여전히 사람이 직접 개발하고 있을까, 아니면 그 개발 팀들도 AI 에이전트를 활용하고 있을까?

호기심을 이기지 못한 필자는 클로드 코드에 더 깊이 파고들어 달라고 요청했다. 알고 보니 아스트로 저장소에는 AGENTS.md 파일이 존재했으며, 일부 커밋의 메시지 트레일러에는 클로드 코드와 깃허브 코파일럿이 공동 작성자로 표기되어 있었다. 또한, .agents/skills 디렉터리에는 개발, 병합, 분류 등을 다루는 스킬 파일들도 있었다. 필자가 직접 살펴본 결과, 누군가가 에이전트 지원 체계를 탄탄하게 구축해 놓았다.

흥미가 더욱 커진 채 추가로 조사하니 꽤 흥미로운 사실이 드러났다. 약 1년 전부터 코딩 에이전트를 활용해 아스트로 사이트를 구축하는 방법에 관한 문서가 등장하기 시작한 것이다. 비슷한 시기에 문서 팀은 개발자의 코딩 에이전트가 아스트로 문서에 더 깊고 쉽게 접근할 수 있도록 하는 MCP 서버도 공개했다.

아스트로 코드베이스에는 ‘에이전트 준비 완료’ 상태를 보여주는 작은 변화들도 눈에 띈다. 예를 들어, 명령줄 개발 서버는 에이전트가 실행을 시작했는지 감지할 수 있으며, 애플리케이션 자체도 에이전트가 구동 중인지 파악할 수 있다. 작은 변화들이지만, 코딩 에이전트를 사용하는 아스트로 개발자들을 수용하는 방향으로 나아가는 걸음들이다.

이 흥미로운 탐험은 어떤 의미를 지닐까?

핵심은 코드가 범용 상품이 될 것이라는 점이다. 아스트로 개발자로서 필자는 거의 항상 AI 에이전트를 활용하고 있다. 아스트로 개발 팀도 점점 더 AI 에이전트를 활용하고 있다. 아스트로의 의존성을 개발하는 팀들도 AI 에이전트를 사용하고 있다. 심지어 클로드 코드와 에이전트 자체를 만드는 사람들도 자사 도구를 직접 활용하는 ‘도그푸딩(dogfooding)’ 방식으로 차세대 프런티어 모델을 개발하고 있다. 머지않아 이 모든 것이 ‘거북이 위에 또 거북이’처럼 끝없이 이어지는 구조가 될 것이다.

오늘날 아무도 “그 전기는 누가 생산했어?” 혹은 “그 셔츠 천은 누가 짰어?”라고 묻지 않는다. 마찬가지로, 머지않아 “그 앱 코드는 누가 짰어?”라고 묻는 사람도 없어질 것이다. 그런 질문 자체가 의미를 잃게 되기 때문이다. 컴파일러가 생성한 어셈블리 코드를 들여다보지 않듯, 에이전트가 작성한 ‘일반’ 코드도 더 이상 들여다보지 않게 될 것이다. 사실 이미 어셈블리 코드를 직접 작성하는 사람이 있는지조차 불분명하다. 머지않아 타입스크립트, 파이썬, C++에 대해서도 같은 말을 하게 될 것이다.
dl-itworldkorea@foundryco.com ...