에이전트형 코딩으로 코드는 이제 점토처럼 빚을 수 있음

TL;DR

• 에이전트형 코딩으로 코드 변경 비용이 급감하면서, 코드는 조각하기 어려운 돌에서 자유롭게 빚고 다시 만들 수 있는 점토로 바뀜.
• 코드의 형태를 빠르게 탐색하고 다듬는 장인 방식은 사람이 매 반복 단계에 참여해 판단을 적용함.
• 공장 방식은 명세, 생성기, 검증기를 파이프라인으로 구성하고, 사람의 개입을 최후의 수단으로 제한함.
• 두 방식 모두 사람의 판단이 필요하며, 차이는 판단을 반복 과정마다 적용할지 파이프라인 구축 단계에 주로 적용할지에 있음.
• 실제 개발 흐름에서는 장인 방식과 공장 방식을 결합해 문제에 맞는 접근을 선택하는 일이 중요함.

코드가 점토가 됨

• 코딩의 중세 시대, 즉 2025년 11월 이전에는 코드를 돌처럼 정교하게 깎아 완성했으며, 도구가 개선돼도 큰 변경에는 철거와 비계, 벽에 붙인 세심한 계획이 필요했음.
• 에이전트형 코딩은 코드 변경 비용을 크게 낮춰, 코드가 같은 기반 물질로 이루어져 있어도 완전히 다른 재료처럼 다룰 수 있게 함. 이제 코드는 점토임.

점토 다루기

• 코드가 점토라면 원하는 대략적인 형태로 코드를 덩어리째 만들고 실제로 어떻게 느껴지는지 살펴볼 수 있으며, 마음에 들지 않으면 일부를 다시 빚거나 전체를 뭉개고 처음부터 시작할 수 있음.
• 전체 구조가 적절해지면 조각가처럼 큰 덩어리에서 중간 크기 특징, 세부 사항 순으로 다듬음.
• 모델링은 만들고 있는 대상의 모든 층위에서 프랙털 방식으로 적용할 수 있음.
• 새 제품을 탐색하는 1인 개발자는 세부 사항을 다루기 전에 하루 만에 핵심 전체를 스케치해 무엇이 작동하는지 확인할 수 있음.
• 어려움을 겪는 제품 기능을 담당하는 팀은 며칠 동안 기능을 완전히 새로운 방향으로 바꿔 피벗할 가치가 있는지 살펴볼 수 있음.
• 실제 작동하는 모습을 지켜보는 것보다 나은 계획이나 목업은 없음.
• 변경이 거의 공짜가 됐더라도 올바른 변경인지 판단하는 일은 그렇지 않으므로 제품 및 엔지니어링 판단은 여전히 중요함.
• 코드 덩어리를 계속 쌓기만 해서는 제품이 제대로 작동하지 않음. 각 부분을 다듬고 서로 어떻게 맞물리는지 고민하지 않으면 프롬프트만으로 수습하기도 전에 전체가 엉성한 덩어리로 무너질 수 있음.
• 취향, 맥락, 가드레일, 아키텍처는 구조를 지지하는 뼈대와 가마 역할을 함.
• 이런 판단을 언제, 어느 정도 적용할지는 아직 알아가는 중이며, 사람의 개입 정도가 다른 여러 작업 흐름이 나타나는 중임. 그 스펙트럼의 양 끝에는 살펴볼 만한 두 접근인 장인과 공장이 있음.

장인의 방식

• 장인은 작업 과정에 계속 참여하고자 함. 빠른 피드백 루프는 변형 가능한 코드의 가장 큰 장점이자 많은 개발자가 이에 빠져드는 이유임.
• 커피를 사 오는 동안 기능을 떠올리고 휴대전화로 에이전트와 접근법을 계획하면, 책상으로 돌아왔을 때 검토할 준비가 된 결과물을 얻을 수 있음. 다듬기를 몇 차례 더하면 온전한 제품·엔지니어링·품질 보증(QA) 주기를 한 사람과 30분으로 압축할 수 있음.
• 스스로가 사용자라면 이 피드백 루프는 특히 만족스러움.
• 매일 더 자주 사용하는 마크다운 편집기를 개발하면서, 지출 목록이 담긴 파일을 보다가 항목을 자동으로 합산하면 좋겠다고 생각함.
• 코드를 조금 적용해 본 뒤 탄산음료를 반쯤 마실 때쯤에는 간단한 연산을 계산하고 결과를 여백에 표시하는 블록인 계산 블록(calc blocks)의 첫 버전이 앱에서 작동했고 이미 유용했음.
• 이는 실시간 소프트웨어 개발임.
• 장인의 방식이 반드시 바이브 코딩인 것은 아님. 이 방식은 작업 과정에 계속 참여하며 모든 반복 단계에 판단을 적용하는 것임.
• 사용자에게 보이는 표면만 판단하면 바이브 코딩이고, 코드의 형태를 판단하기까지 하면 모든 줄을 살펴보지 않더라도 엔지니어링임. 달라진 것은 피드백 루프가 더 빨라졌다는 점임.

공장의 방식

• 반대쪽 극단에는 작업 과정에서 자신을 빼려는 공장 방식이 있음.
• 공장은 코드 점토를 더 큰 구조에 깔끔하게 맞는 벽돌로 만드는 시스템을 구축하는 방식임.
• 명세, 생성기, 검증기(테스트, 평가, 가드레일, 검토 에이전트)로 구성된 파이프라인이 루프를 돌고, 최후의 수단으로만 사람에게 작업을 넘기는 구조임.
• 반복 가능한 패턴이 틀 역할을 하고 작업 결과를 검증할 명확한 기준이 있는, 구조가 잘 잡힌 코드베이스에서 가장 효과적임.
• 공장 방식은 CRUD 엔드포인트를 하나 더 추가하거나 사소한 버그 100개를 처리하는 작업에 적합함.
• 공장에서도 판단은 존재하지만, 판단이 상위 단계로 옮겨지거나 파이프라인에 내장됐을 뿐임.
• 판단을 얼마나 파이프라인에 내장하고 자동화할 수 있는지는 아직 결론이 나지 않았지만, 신뢰할 수 있는 결과를 내는 공장을 구축하는 일이 앞으로 엔지니어링의 큰 부분이 될 가능성이 있음.

장인인가, 공장인가?

• 두 방식 모두 사람의 판단이 작업을 이끌며, 차이는 판단을 적용하는 시점에 있음.
• 장인은 모든 반복 단계에서 판단을 적용하므로 아이디어를 탐색하고 적절한 느낌이 필요한 기능을 다듬는 데 유용함.
• 공장은 파이프라인을 구축할 때 판단을 적용하고, 반복 과정에서는 가능한 한 사람의 개입을 줄임.
• 어느 쪽도 판단을 생략할 수 없음.
• 산업적인 어감 때문에 공장은 대기업 코드베이스에만 어울리고, 장인은 태국 해변에서 앱을 만지는 인디 해커에게만 어울린다고 생각할 수 있지만 두 방식은 함께 쓰일 수 있으며 실제 작업 흐름 다수는 둘을 섞은 형태일 것임.
• 규모가 크고 자리를 잡은 제품에도 새로운 문제를 해결하거나 적절한 느낌이 필요한 기능을 추가하는 장인 정신이 필요함.
• 1인 개발자도 지루하고 반복적인 일을 처리하고 과거에는 한 사람이 생각할 수 없던 규모를 이루기 위해 공장을 운영하고자 할 수 있음.
• 핵심은 해결하려는 문제에 알맞은 접근을 선택하는 일이며, 이는 소프트웨어 엔지니어링이 늘 해 온 일이기도 함.
• 이제 새로운 재료를 손에 쥐고 있음. 코드는 점토이며, 그 점토로 무엇을 만들지가 남은 질문임.