Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Agentic coding의 발전으로 코드가 '점토'처럼 유연해지면서, 개발 과정에서 모델링과 빠른 반복이 가능해졌습니다. 이는 아이디어를 빠르게 프로토타입화하고 다양한 방향을 탐색하는 것을 의미합니다. 하지만 단순히 코드를 쌓는 것만으로는 부족하며, 아키텍처와 맥락에 대한 인간의 판단력이 여전히 중요함을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN OpenAI Codex의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Alberto Denia ∙ 2026년 9월 25일
코딩의 중세 시대(즉, 2025년 11월 이전)에 우리는 코더-석공들이 하루를 보내며 정교하게 코드-돌을 완성된 조각으로 새기는 데 시간을 보냈습니다. 돌은 용서가 없어서 수정하는 것이 어려웠고, 시간이 지남에 따라 더 나은 도구들이 상황을 개선했음에도 불구하고 마찬가지였습니다. 작은 수정은 괜찮았지만(여기에서 끌질 몇 번, 저기에서 패치 작업), 더 큰 수정은 철거, 비계 설치, 그리고 벽에 고정된 신중한 계획을 의미했습니다.
에이전트 기반 코딩(Agentic coding)이 이를 뒤집었습니다. 코드는 유연해졌습니다(malleable). 중세 코드와 동일한 근본적인 물질로 만들어져 있음에도 불구하고, 변경을 가하는 비용이 무너졌습니다. 이것은 코드가 완전히 다른 재료처럼 행동하게 만듭니다. 코드는 이제 점토입니다.
코드가 점토가 되면, 모델링을 시작할 수 있습니다. 원하는 대략적인 모양으로 큰 덩어리의 코드-점토를 던져 넣고 느낌을 확인해 보세요. 마음에 들지 않나요? 부분은 쉽게 재형성하거나 심지어 전체를 납작하게 만들어 처음부터 다시 시작할 수 있습니다. 전체 구조가 적절하다고 느껴질 때, 조각가가 하듯이 다듬습니다: 일반적인 덩어리에서 중간 크기의 특징으로, 그리고 세부 사항까지요.
모델링은 프랙탈(fractally) 방식으로 적용될 수 있으며, 구축하는 것의 어떤 계층에서도 가능합니다. 새로운 제품을 탐색하는 개인 개발자는 세부 사항에 들어가기 전에 작동하는 것을 보기 위해 하루 만에 전체 핵심 부분을 스케치할 수 있고, 어려움을 겪는 제품 기능 담당 팀은 피벗(pivot)이 가치가 있는지 알아보기 위해 완전히 새로운 방향으로 몇 일 동안 시간을 보낼 수 있습니다. 계획이나 목업(mockups)으로는 실제 작동하는 것을 보는 것만 못합니다.
당신의 제품 및 엔지니어링 판단력은 여전히 중요합니다. 변화를 주는 것은 이제 거의 무료일 수 있지만, 그것이 올바른 변화인지는 알 수 없습니다. 만약 제대로 느껴지고 잘 유지되는 무언가를 만들고 싶다면, 그저 덩어리들을 계속 쌓아 올릴 수는 없습니다. 조각들을 다듬고 그것들이 어떻게 맞물리는지 생각해야 합니다. 그렇지 않으면 전체가 당신이 프롬프트로 빠져나올 수 있는 속도보다 더 빨리 지저분한 진흙탕으로 무너질 것입니다. 감각, 맥락, 가드레일(guardrails), 아키텍처… 이것들이 바로 당신의 골조와 가마입니다.
이러한 판단력을 언제, 그리고 어느 정도 적용해야 하는지는 우리가 아직 알아내고 있는 부분입니다. 인간 개입 수준의 스펙트럼을 따라 여러 워크플로우가 나타나고 있습니다. 이 스펙트럼의 양 끝단에는 살펴볼 만한 두 가지 접근 방식, 즉 장인(artisans)과 공장(factories)이 있습니다.
장인은 참여하기를 원합니다. 빠른 피드백 루프는 유연한 코드의 가장 좋은 점이며, 우리 중 많은 사람이 여기에 중독된 이유입니다. 커피 한 잔을 마시는 시간 동안, 당신은 하나의 기능을 생각하고, 휴대폰의 에이전트(agent)와 함께 접근 방식을 계획할 수 있으며, 책상으로 돌아왔을 때 검토를 받을 준비가 된 상태로 만들 수 있습니다. 몇 번의 다듬기 반복 작업을 추가하면, 한 사람과 30분 만에 전체 제품/엔지니어링/QA 주기를 압축한 것입니다.
당신 자신이 사용자일 때, 이 루프는 터무니없이 만족스럽습니다. 예를 들어, 저는 매일 점점 더 많이 사용하는 Markdown 에디터를 작업하고 있습니다. 며칠 전 제가 지출 목록이 있는 파일을 보고 생각했습니다. “만약 여기에 모든 금액을 자동으로 합산할 수 있다면 좋을 텐데… 잠깐, 코드를 좀 넣어볼까!” 탄산음료 반 병을 마신 후에, 저는 앱에서 작동하는 calc blocks(단순 연산을 평가하고 그 결과를 여백에 보여주는 블록)의 첫 버전을 만들었고 이미 유용했습니다. 실시간 소프트웨어 개발입니다.
이것은 그저 '바이브 코딩(vibe coding)' 아닌가요? 반드시 그렇지는 않습니다. 장인의 방식은 루프 안에 머무르며 모든 반복 과정에 자신의 판단을 적용하는 것입니다. 사용자에게 보이는 표면만 판단한다면 그것이 바이브 코딩입니다. 코드 자체(적어도 그 형태, 심지어 모든 라인이 아니더라도)까지 판단한다면 그것이 엔지니어링입니다. 단지 루프가 더 빨라졌을 뿐입니다.
반대 극단에서는 자신을 루프 밖으로 제거하고 싶어 합니다. 이것이 바로 공장의 방식입니다.
공장은 코드 점토(code-clay)를 더 큰 구조에 깔끔하게 들어맞는 벽돌로 만드는 시스템 구축에 관한 것입니다. 사양(specs), 생성기(generators), 검증기(verifiers) (테스트, 평가(evals), 가드레일(guardrails), 리뷰 에이전트(reviewing agents))로 이루어진 파이프라인을 생각해보세요. 이 루프는 최후의 수단으로 인간에게만 에스컬레이션됩니다. 공장은 몰드 역할을 하는 반복 가능한 패턴과, 작업 결과를 검증할 명확한 기준이 있는 잘 구조화된 코드베이스에서 가장 잘 작동합니다. 공장은 11번째 CRUD 엔드포인트를 추가하거나 백 개의 사소한 버그를 처리하는 것 같은 일에 놀랍습니다.
공장에서도 판단은 여전히 존재합니다. 단지 상류(upstream)로 이동했거나 파이프라인 내에 내재화되었을 뿐입니다. 얼마나 많은 부분이 내재화되고 자동화될 수 있을지는 아직 미지수이지만, 저는 신뢰할 수 있는 결과를 산출하도록 공장을 설정하는 것이 엔지니어링의 핵심이 될 부분이라고 생각합니다.
두 경우 모두 인간의 판단이 여전히 작업을 이끌고 있습니다. 차이는 언제 적용하느냐에 달려 있습니다. 장인은 모든 반복 과정에서 판단을 적용하며, 이는 아이디어를 탐색하고 '느낌'이 좋아야 하는 기능을 다듬는 데 좋습니다. 공장은 파이프라인을 구축할 때, 그리고 루프 중에는 가능한 한 적게 판단을 적용합니다. 어느 쪽도 이를 건너뛸 수 없습니다.
산업적인 함의를 고려하면 공장(factories)은 대규모 기업 코드베이스에만 속할 것이고, 장인들(artisans)은 태국의 해변에서 앱을 만지작거리는 인디 해커들에게나 어울릴 것이라고 생각하기 쉽습니다. 하지만 이 둘은 상호 보완적일 수 있으며, 많은 실제 워크플로우는 이 두 가지가 혼합된 모습을 띨 것입니다. 크고 확립된 제품들은 새로운 문제를 해결하거나 '제대로 느껴져야' 하는 기능을 추가하는 데 장인 정신(artisanship)이 필요합니다. 심지어 솔로 개발자들조차도 지루하고 반복적인 부분을 처리하고, 이전에는 한 사람이 상상할 수 없었던 규모를 달성하기 위해 공장 같은 것을 운영하고 싶어 할 것입니다. 핵심은 해결하려는 문제에 맞는 올바른 접근 방식을 선택하는 것입니다. 그리고 이것이 바로 소프트웨어 엔지니어링(software engineering)이 항상 다루어 온 것이었습니다.
그래서 우리는 손에 새로운 재료를 갖게 되었습니다. 코드가 이제 점토와 같습니다. 우리는 이 점토로 무엇을 만들까요?