AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

AI 에이전트 코딩 이후, 개발 도구는 어떻게 진화하는가

에이전트 코딩이 생산성을 높일까요, 아니면 오히려 개발자를 방해할까요? 세 명의 개발자가 서로 다른 각도에서 이 질문에 답합니다.

사진 출처: Lummi.ai

Flask 창시자 Armin Ronacher, Haskell 전문가 Gabriel Gonzalez, 그리고 개발자 Federico Pereiro가 각각 에이전트 코딩의 미래에 대한 통찰을 발표했습니다. 흥미로운 점은 세 사람의 관점이 완전히 다르다는 것입니다. Ronacher는 “에이전트를 위한 새로운 프로그래밍 언어”를, Gonzalez는 “에이전트가 아닌 조용한 AI 도구”를, Pereiro는 “에이전트 자체가 고수준 언어”라고 주장합니다.

출처:

관점 1: 에이전트가 좋아하는 언어를 만들자

Ronacher는 역발상을 제시합니다. “기존 언어에 에이전트를 맞추지 말고, 에이전트에 맞는 새 언어를 만들면 어떨까?”

그가 발견한 에이전트의 약점은 명확합니다. 공백 기반 들여쓰기(Python)는 토큰 효율이 나쁘고, 타입 추론(TypeScript)은 LSP 없이는 혼란스럽고, 매크로(Rust)는 에이전트가 이해하기 어렵습니다. 반면 에이전트는 명시적 괄호, 명확한 타입 표기, grep으로 찾을 수 있는 코드를 선호합니다.

흥미로운 제안은 “자동 전파되는 효과 마커”입니다. 함수가 시간이나 데이터베이스를 사용한다면, 포맷팅 도구가 자동으로 needs { time, db } 같은 표시를 추가하는 것이죠. 에이전트는 이 정보로 정확한 테스트 목(mock)을 생성할 수 있습니다.

그의 핵심 논리는 이렇습니다: 코딩 비용이 극적으로 낮아지면서, 생태계의 폭보다 에이전트의 효율이 더 중요해졌다는 것입니다. 필요한 라이브러리가 없으면? 에이전트에게 다른 언어 구현을 보여주고 포팅하라고 하면 됩니다.

관점 2: 에이전트보다 조용한 도구가 낫다

Gonzalez는 정반대 입장입니다. 그는 채팅 기반 에이전트 코딩이 실제로는 생산성을 떨어뜨린다고 주장합니다. 자신의 인터뷰 경험에서 에이전트를 사용한 후보자들이 오히려 더 나쁜 결과를 냈다고 합니다.

문제는 “플로우 상태”의 파괴입니다. METR 연구를 보면, 에이전트를 사용할 때 유휴 시간이 두 배로 늘어났습니다. 개발자는 에이전트의 응답을 기다리거나, 반자동 모드로 실행하면서 중단 가능한 상태로 대기해야 합니다.

그가 제시하는 대안은 “Calm Technology(조용한 기술)”입니다. VSCode의 타입 힌트처럼, 필요할 때만 보이고 주의를 빼앗지 않는 도구 말이죠. 그는 세 가지 흥미로운 아이디어를 제시합니다:

의미 기반 프로젝트 탐색: 파일 트리를 “문자열 보간 회귀 테스트”, “명령줄 옵션 파서” 같은 의미 단위로 보여주는 것입니다. issue2078A.dhall보다 훨씬 이해하기 쉽습니다.

자동 커밋 리팩터링: 큰 변경사항을 AI가 자동으로 리뷰하기 쉬운 작은 커밋들로 쪼개는 기능입니다.

파일 렌즈: “Python처럼 편집하기” 모드를 켜면, Haskell 파일을 Python 문법으로 수정하고 AI가 다시 Haskell로 변환해줍니다.

핵심은 개발자가 여전히 코드와 직접 접촉하고, AI는 배경에서 조용히 돕는다는 것입니다.

관점 3: 에이전트 자체가 새로운 언어다

Pereiro는 가장 급진적인 주장을 합니다. LLM 에이전트가 Java나 Python 같은 “새로운 고수준 언어”라는 것입니다. C가 어셈블리를 대체했듯, 이제 에이전트가 모든 프로그래밍 언어를 대체한다는 논리죠.

그가 제시하는 미래 개발 환경은 네 가지 요소로 구성됩니다:

문서(Documentation): 시스템 사양을 담은 마크다운 페이지들. 이것이 “소스 코드”의 역할을 합니다.

구현(Implementation): 실제 코드베이스. 문서에서 재구성 가능해야 합니다.

대화(Dialogs): 여러 에이전트가 작업하며 생성하는 텍스트와 코드 스트림. 사람은 언제든 끼어들 수 있습니다.

작업(Tasks): 동적인 작업 목록. 문서와 코드 상태에서 재구성 가능합니다.

그의 비전에서 개발자는 더 이상 코드를 직접 작성하지 않습니다. 대신 에이전트들과 대화하고, 문서를 업데이트하고, 에이전트가 생성한 결과를 검토합니다. MCP(Model Context Protocol)가 이를 가능하게 할 핵심 기술이라고 그는 봅니다.

세 관점이 의미하는 것

세 사람의 주장은 모순되지만, 공통점이 있습니다. 모두 “현재의 채팅 기반 에이전트 코딩은 충분하지 않다”고 봅니다.

Ronacher는 도구(언어)를 바꾸자고 하고, Gonzalez는 인터페이스를 바꾸자고 하고, Pereiro는 작업 방식 자체를 바꾸자고 합니다. 어느 방향이 옳을까요? 아마 세 가지 모두가 부분적으로 실현될 것입니다.

한 가지 확실한 것은, 우리가 지금 목격하는 것이 단순한 “도구의 추가”가 아니라 “소프트웨어 개발 패러다임의 전환”이라는 점입니다. 그리고 그 전환이 어떤 모습일지는 아직 아무도 확실히 알지 못합니다.

참고자료:

Fediverse reactions

AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다