AI 코딩의 선(禪) - 에이전트 코딩 시대의 원칙들

Python의 Zen of Python에서 영감을 받은 글. 저자는 1년간 매일 코딩 에이전트를 사용하면서 정리한 에이전트 코딩 원칙들을 공유함.

코드의 경제학이 바뀌었음

• "소프트웨어 개발은 죽었다" - 코드를 직접 짤 필요가 없어짐. 개발자의 역할은 문제 프레이밍, 컨텍스트 설계, 제약 조건 정의, 결과 판단으로 이동함
• "코드는 싸다" - 코드의 한계비용이 거의 0에 수렴하면서, 병목이 구현이 아니라 제품 결정, 요구사항 정리, 보안 리뷰, 사용자 테스트, 릴리스 프로세스로 이동함
• "리팩토링은 쉽다" - 마음 바꾸는 비용이 역사상 가장 낮음. 실제로 3개월 동안 CMS를 4번이나 다른 아키텍처로 처음부터 다시 만들었다고 함
• "기술 부채 상환도 쉽다" - 라이브러리 업데이트, API 마이그레이션 같은 건 프롬프트 한 줄이면 됨. 낡은 의존성을 방치할 변명이 사라짐

피드백 루프와 품질

• "모든 버그는 얕다" - 리누스의 법칙에서 말하는 "충분한 눈"이 이제 AI로 풍부해짐. 함수 단위의 코드베이스 이해가 더 이상 필수가 아님
• "타이트한 피드백 루프를 만들어라" - 테스트가 첫 번째, CI가 두 번째, 서버 로그가 세 번째 피드백 루프. "피드백 없는 속도는 혼돈일 뿐"이라는 말이 핵심
• "빠른 쓰레기는 여전히 쓰레기" - 실행이 쉬워질수록 규율이 더 중요해짐. 속도와 코드 줄 수는 원래도 진척의 끔찍한 지표였음

에이전트의 확장된 역할

• "어떤 스택이든 너의 스택" - 본인이 아는 기술에 국한될 필요 없음. 에이전트가 대부분의 주요 스택에서 유능하게 작동함
• "에이전트는 코딩만을 위한 게 아님" - 비즈니스 분석, UX, 인프라, 운영까지 가능. 저자는 미루던 WordPress 블로그 4개를 15분 만에 마이그레이션했음
• "컨텍스트 병목은 당신 머릿속에 있음" - 여러 에이전트를 병렬로 돌릴 때 진짜 병목은 인간의 조율 능력. 토큰이 아니라 인지가 제약 조건임

비즈니스와 전략적 시사점

• "Buy vs Build → 이제는 Build가 더 많음" - 코드가 싸지면서 직접 만드는 쪽이 유리해짐. 스크린샷 API를 사는 대신 Playwright를 AWS Lambda에 배포한 사례를 소개함
• "소프트웨어는 부채, 제품은 자산" - 만들기 쉬워진 만큼 기능 추가 유혹이 커지지만, 사용되는 것만 만들고 안 쓰이는 건 죽여야 함
• "해자(moat)는 더 비싸졌다" - 기능 격차는 빠르게 좁혀짐. 해자는 유통, 데이터, 브랜드, 네트워크 효과 쪽으로 이동함

에이전트 시대를 위한 설계

• "에이전트를 위해 만들어라" - AX(Agent Experience)가 새로운 UX임. 서비스를 에이전트가 접근할 수 있도록 구조화된 컨텍스트와 머신 리더블한 인터페이스를 제공해야 함
• "실패 모드를 예측하라" - 에이전트는 실수하고, 보안 취약점을 만들고, .env 파일을 커밋하려고 시도함. 가드레일을 세우고, 권한을 제한하고, 환경을 격리해야 함

결국 이 글의 메시지는 명확함: 코딩 에이전트 시대에 개발자는 "코드를 짜는 사람"이 아니라 "시스템이 무너지지 않게 감독하는 엔지니어"로 진화해야 한다는 것.