2026.03.06

이제 AI가 코드를 작성하는 것은 일상이 되었습니다. 여기서 주목할 점은 코딩이라는 '행위'가 아니라, 엔지니어라는 '직무'의 본질적인 변화입니다. 현재 소프트웨어 엔지니어링은 크게 두 가지 전문 영역으로 재편되고 있습니다.
▶ 하네스 엔지니어링(Harness engineering): 에이전트를 신뢰할 수 있게 만드는 제약 조건, 도구, 피드백 루프 및 문서를 구축하는 일 (여기서 이미 하나의 새로운 산업이 형성되고 있습니다).
▶ 판단력 제조(Judgment manufacturing): 에이전트가 생산한 시스템을 지시, 검증 및 유지 관리할 수 있는 인간, 특히 초급 엔지니어를 육성하는 일
AI 에이전트의 등장으로 누구나 기본적인 수준의 하네스 엔지니어링을 수행할 수 있게 되었습니다. 하지만 이것이 전문가의 종말을 의미하지는 않습니다. 오히려 그 반대입니다. 누구나 소프트웨어를 만들 수 있게 된 만큼, 보안, 신뢰성, 성능, 규제 준수(Compliance) 등 실패 시 막대한 비용이 발생하는 고위험 영역에서는 숙련된 엔지니어의 깊이 있는 전문성이 이전보다 훨씬 더 중요해질 것이기 때문입니다.
Charlie Guo의 <"하네스 엔지니어링" 플레이북>은 글로벌 선도 기업들이 나아가는 방향을 명확히 보여줍니다. OpenAI는 이미 에이전트 중심의 조직 개편을 단행했고, Stripe의 에이전트 ‘Minions’는 매주 1,000개 이상의 PR(Pull Request)을 자동으로 병합하고 있습니다. 이제 개인 개발자조차 5~10개의 에이전트를 동시에 운용하며, 코드를 일일이 읽지 않고도 제품을 출시하는 시대가 되었습니다.
현시점에서 모델의 코드 작성 능력은 이미 '상수'가 되었습니다. 이제 생산성의 병목은 기술 그 자체가 아니라, '에이전트가 실수하기 어렵고, 올바른 결과물을 내놓기 쉬운 환경을 구축했는가'로 이동했습니다. 이것이 바로 하네스 엔지니어링의 본질입니다.
에이전트를 잘 활용하기 위한 몇 가지 공통적인 패턴이 있습니다.
• 에디터를 먼저 열지 않습니다. 요구사항을 정리해 에이전트에게 계획을 먼저 세우게 합니다. 인간은 계획 승인과 리뷰에 집중합니다.
• 아키텍처를 엄격히 설계합니다. 의존성 경로를 제한하고, 에이전트가 정해진 규칙 안에서만 움직이도록 구조적인 안전장치를 만듭니다.
• 내부 도구를 에이전트가 사용할 수 있도록 정비합니다. 자동 검사 도구가 내뱉는 피드백은 단순한 오류 보고가 아니라, '에이전트가 보고 즉시 따라 할 수 있는 수정 지침'이 되어야 합니다.
• 실패는 기록합니다. AGENTS.md를 단순 문서가 아니라 학습 로그처럼 다루며, 반복되는 실수는 구조적으로 제거합니다.
• 품질 기준을 낮추지 않습니다. 모든 PR에는 인간 책임자가 있고, 리뷰어는 자신이 무엇을 승인하는지 이해해야 합니다.
• 에이전트를 단순히 한 번 쓰고 버리는 도구가 아니라, 가동 상태를 추적하고 관리하는 프로덕션 시스템으로 대우해야 합니다. 반복되는 실패 패턴을 분석해 에이전트가 일하는 환경(하네스) 자체를 지속적으로 업그레이드합니다. |
결국 에이전트가 현장의 '노동자'라면, 하네스는 그들이 효율적으로 가동될 수 있도록 설계된 '지능형 공장'입니다. 엔지니어의 핵심 가치는 공장이 스스로 할 수 없는 영역, 즉 비판적 판단과 설계, 그리고 최종적인 결과물에 대한 책임으로 집약될 것입니다.
안드레 카파시는 최근 자신의 경험을 통해 기성 '앱 스토어' 모델의 종말을 예고했습니다. 그는 기존 앱 스토어에서는 절대 찾을 수 없는, 자신만의 특수한 운동 실험용 대시보드를 에이전트와 함께 단 한 시간 만에 만들어냈습니다. 이처럼 에이전트가 사용자의 구체적인 요구에 따라 즉석에서 앱을 조립해내는 시대에는, 이미 만들어진 패키지 소프트웨어를 골라 쓰는 방식이 점차 구식으로 느껴지게 될 것입니다.
앤드류 응 또한 경제학적 관점에서 이러한 흐름을 뒷받침합니다. 설령 개발자의 생산성이 10배로 높아지더라도 개발 인력에 대한 수요가 줄어들지 않는 이유는, 맞춤형 소프트웨어에 대한 갈증에는 사실상 한계가 없기 때문입니다. 실제로 마케팅이나 채용 부서에 소속되어 해당 팀에 필요한 도구를 직접 개발하는 ‘마케팅 엔지니어’나 ‘채용 엔지니어’와 같은 새로운 형태의 직무가 이미 현장에서 나타나고 있습니다.
결국 소프트웨어는 더 이상 규격화된 '제품(Product)'이 아니라, 비즈니스 목적에 따라 끊임없이 생성되고 변화하는 '맞춤형 도구들의 흐름(Stream)'으로 진화하고 있습니다. 우리는 지금 '소프트웨어 산업'의 정의 자체가 완전히 재정립되는 시대에 진입하고 있습니다.
토마스 울프는 AI가 코드 분석과 재작성 비용을 획기적으로 낮춤에 따라 소프트웨어 생태계의 '공급망' 자체가 재편될 것이라 전망합니다. 과거에는 복잡한 기능을 구현하기 위해 수많은 외부 라이브러리(의존성)에 기대는 것이 당연한 전략이었습니다. 직접 만드는 것보다 가져다 쓰는 것이 훨씬 효율적이었기 때문입니다. 하지만 에이전트가 필요한 기능을 직접 추출하거나 새롭게 작성하는 것이 쉬워진 지금, 과도한 외부 의존성은 오히려 보안 취약점을 늘리고 성능을 저하시키는 '부채'에 가까워지고 있습니다.
이 과정에서 소프트웨어의 수명을 설명하는 '린디 효과(Lindy Effect)'가 약화되고 있습니다. 오래된 레거시 시스템이 수십 년간 유지되었던 이유는 그 구조가 완벽해서가 아니라, 이를 건드렸을 때 감당해야 할 리스크와 교체 비용이 너무 컸기 때문입니다.
하지만 AI는 기존 코드를 정교한 '설계 도면'이자 테스트 가이드로 삼아, 새로운 언어로 현대화하는 번역 작업에 압도적인 능력을 보여줍니다. 결과적으로, 레거시 시스템의 교체 비용이 낮아집니다. 그 순간 레거시는 자연스럽게 해자의 일부를 잃게 됩니다. 그것이 린디 효과이든, 전환 비용이든, 혹은 단순한 두려움이든 말입니다.
카파시도 프로그래밍 언어 관점에서 같은 흐름을 짚습니다. LLM은 처음부터 창조하는 것보다 번역과 재작성에 뛰어나기 때문입니다. 기존의 낡은 코드는 AI에게 가장 정교한 '프롬프트'이자 완벽한 '테스트 가이드(Oracle)'가 됩니다.
다만, 코드를 다시 쓰는 것은 매우 쉬워졌지만 그 결과물이 현실 세계를 망가뜨리지 않았음을 증명하는 것은 여전히 어렵습니다.
재작성이 쉬워졌음에도 불구하고, '알려지지 않은 미지의 영역(unknown unknowns)'은 여전히 해결해야 할 과제로 남습니다. 모든 코드를 다시 쓸 수 있게 되더라도, 과거의 시스템이 오랜 시간 수많은 시행착오를 겪으며 해결해온 다양한 예외 상황(edge cases)들을 고스란히 다시 마주하게 되기 때문입니다.
이러한 환경에서 소프트웨어의 논리적 완벽함을 증명하는 '형식적 검증(Formal Verification)'은 더 이상 선택이 아닌 필수적인 요소가 됩니다. 에이전트는 결과물을 쏟아내는 속도에 비해 우리가 그 결과물을 신뢰할 수 있는 수준(Confidence)을 그만큼 빠르게 높여주지는 못합니다. 하네스 엔지니어링이 에이전트의 실수를 줄여줄 수는 있지만, 검증은 '식사 끝에 반드시 지불해야 하는 청구서'와 같습니다. 아무리 효율적으로 코드를 생산하더라도, 그것이 실제 세계에서 안전하게 작동함을 입증하는 비용은 결코 피할 수 없다는 뜻입니다.
AI 에이전트 기반의 코딩 도구는 시니어 엔지니어에게는 강력한 날개가 되어줍니다. 시니어는 에이전트가 내놓은 결과물을 조율하고 검증하며 전체 시스템에 통합할 수 있는 '판단력'을 이미 갖추고 있기 때문입니다. 반면, 초급(EiC) 개발자들에게는 이 도구가 오히려 독이 될 수 있습니다. 판단력이 부족한 상태에서 AI에 의존하다 보면 성장이 정체되거나 잘못된 논리에 매몰되기 쉽기 때문입니다.
이로 인해 시장에서는 "숙련된 시니어만 채용하고, 주니어의 업무는 AI에게 맡기자"는 경제적 유인이 발생합니다. 하지만 이러한 선택이 보편화되면 소프트웨어 산업의 인재 공급망은 완전히 무너질 위험이 큽니다. 시니어 엔지니어는 단순히 채용 시장에서 사 오는 부품이 아니라, 주니어 시절의 수많은 시행착오를 거치며 '육성'되는 존재이기 때문입니다.
Mark Russinovich와 Scott Hanselman은 이 위기에 대한 해법으로 '대규모 도제 제도(Preceptorship at scale)'를 제안합니다. 숙련된 시니어 한 명이 3~5명의 주니어를 전담하여 1년 이상 밀착 교육하고, 조직 차원에서 이들의 성장을 명시적인 핵심 목표로 관리해야 한다는 것입니다. 또한, AI 도구 역시 초급자를 위해서는 정답을 즉시 내놓기보다 스스로 생각하게 유도하는 '소크라테스식 코칭 모드'를 기본값으로 제공해야 합니다.
우리는 지금 인류 역사상 그 어느 때보다 빠르게 '실행(Execution)'을 자동화하고 있지만, 이를 제어할 '판단력'은 그 속도를 따라가지 못하고 있습니다. 결국, 이 판단력의 결핍이 미래 소프트웨어 엔지니어링의 가장 거대한 병목 현상을 초래할 것입니다.
향후 1년 내에 우리는 소프트웨어 엔지니어링 생태계에서 다음과 같은 세 가지 결정적인 변화를 목격하게 될 것입니다.
'하네스 엔지니어링'의 직무 공식화
맞춤형 소프트웨어(Bespoke Software)의 범람
주니어 인재 파이프라인의 전략적 리스크 |
에이전트는 소프트웨어를 '희소성'의 영역에서 '풍요'의 영역으로 이동시키고 있습니다. 즉 코드 생산은 점점 저렴해지고 빨라집니다. 이러한 시대에 가장 희귀하고 값진 자원은 기술 그 자체가 아닙니다. 그것은 바로 '무엇이 좋은 결과물인지 결정하고(판단), 그것이 제대로 작동함을 입증하며(검증), 책임 있게 유지하는 인간의 역량'입니다.
우리가 이 능력을 의도적으로 훈련하지 않는다면, 인류는 그 어느 때보다 많은 소프트웨어를 만들어내면서도 그 결과물을 통제하지 못하는 혼돈에 빠지게 될 것입니다. 겉보기에는 멀쩡하지만 현실 세계의 복잡성을 견디지 못하고 무너지는 소프트웨어들 말입니다.
Writer: Turing Post - Ksenia Se & Ben Eum
Edit: Metanet