Agentic Engineering

원문: Agentic Engineering by Addy Osmani 를 번역한 글입니다.

1년 전 Andrej Karpathy가 "바이브 코딩(vibe coding)"이라는 용어를 만들었다. 프롬프트를 입력하고, AI가 내놓는 걸 그대로 받고, diff는 읽지 않고, 에러 메시지만 다시 붙여넣으며 반복하는 방식이다. 순수한 AI 자동 조종으로 빠른 프로토타입이나 MVP를 만드는 현상에 딱 맞는 이름이었다.

문제는 "바이브 코딩"이 만능 용어가 되어버렸다는 것이다. 이제 사람들은 주말 해킹부터, 사람의 감독 하에 AI 에이전트가 구현을 담당하는 체계적인 엔지니어링 워크플로까지 모든 것을 설명할 때 이 용어를 사용한다. 이 둘은 전혀 다른 활동인데, 같은 용어로 부르다 보니 혼란이 생기고 실제 피해도 발생하고 있다.

---

바이브 코딩이 실제로 의미하는 것

바이브 코딩은 분위기에 맡기고 코드를 검토하지 않는 방식이라고 할 수 있다. 이것이 핵심 특징이다. 프롬프트를 입력하고, 수락하고, 실행하고, 작동하는지 확인한다. 작동하지 않으면 에러를 다시 붙여넣고 재시도한다. 계속 프롬프트를 입력한다. 인간은 엔지니어가 아니라 프롬프트 DJ다.

이런 경우에 유용하다:

• 그린필드 MVP, 프로토타입, 해커톤 데모: 일요일까지 작동하는 무언가가 필요한 경우. 코드 품질은 중요하지 않다.
• 개인 스크립트와 일회성 도구: 본인만 사용하는 경우. 망가지면 다시 생성하면 된다.
• 학습과 탐색: 초보자가 AI의 출력을 보며 예시를 통해 배우면서, 그렇지 않으면 만들 수 없었던 것들을 만들 수 있다.
• 창의적 브레인스토밍: 의도적으로 과다 생성하여 AI가 어떤 접근법을 제안하는지 확인한 뒤, 버리고 제대로 구축하는 방식이다.

바이브 코딩이 수백만 명에게 그렇지 않았다면 불가능했을 맞춤형 소프트웨어를 만들 수 있는 능력을 제공한다면, 그것은 진정한 성과다. 이 기법은 도구 상자에서 정당한 자리가 있다.

하지만 실패 유형은 이 시점에서 충분히 문서화되어 있다. 패턴은 항상 같다. 데모에서는 훌륭하게 작동하다가, 현실이 닥친다. 수정하거나, 확장하거나, 보안을 적용하려 하면, 아무도 코드가 실제로 무엇을 하는지 이해하지 못한다는 것을 발견한다. 한 엔지니어가 말했듯이, "이건 엔지니어링이 아니라 그냥 바라는 것일 뿐"이다.

---

전문가를 위한 더 나은 버전의 용어가 필요하다

핵심은 이것이다. 많은 경험 있는 엔지니어들이 이제 AI로부터 2배, 5배, 때로는 그 이상의 엄청난 생산성 향상을 얻고 있으며, 동시에 코드 품질도 유지하고 있다. 하지만 그들이 일하는 방식은 바이브 코딩과 전혀 다르다. 프롬프트 전에 명세(spec)를 작성한다. 모든 diff를 검토한다. 테스트 스위트를 실행한다. AI를 빠르지만 신뢰할 수 없는 주니어 개발자처럼 대하며 끊임없는 감독이 필요하다고 본다. 개인적으로 "AI 보조 엔지니어링(AI-assisted engineering)"이라는 표현을 선호해왔고, 이것이 인간이 루프 안에 머무르는 스펙트럼의 끝을 설명한다고 생각한다.

Simon Willison(원문 저자가 좋아하는 분)은 이를 위해 "바이브 엔지니어링(vibe engineering)"을 제안했다. "바이브"를 되찾으면서 "엔지니어링"을 추가하여 규율을 나타내는 것이다. 하지만 커뮤니티가 몇 달간 이를 논의하는 것을 지켜본 후, "바이브"라는 단어는 너무 많은 짐을 지고 있다는 생각이 들었다. 이 단어는 가벼움을 연상시킨다. CTO에게 결제 시스템을 "바이브 엔지니어링"하고 있다고 말하면, 그의 얼굴에서 우려를 읽을 수 있다.

Andrej Karpathy가 이번 주에 "에이전틱 엔지니어링(agentic engineering)"을 제안했는데, 이게 괜찮은 것 같다.

이것이 효과적인 이유는 아마 이럴 것이다:

실제로 일어나는 일을 설명한다. AI 에이전트를 조율한다. 코드를 실행하고, 테스트하고, 개선하는 코딩 어시스턴트 말이다. 여기서 아키텍트, 리뷰어, 의사결정자 역할을 한다. 코드의 몇 %만 직접 작성할 수도 있다. 나머지는 지시에 따라 에이전트가 작업한다. 그것이 에이전틱이다. 그리고 전 과정에 걸쳐 엔지니어링 규율을 적용한다. 그것이 엔지니어링이다.

전문적으로 명확하다. "에이전틱 엔지니어링"은 그것이 의미하는 바 그대로 들린다. 자율 에이전트가 관여하는 진지한 엔지니어링 규율이다. VP of Engineering에게 부끄러움 없이 말할 수 있다. 직무 기술서에 넣을 수 있다. 팀 실천 방안으로 구축할 수 있다.

깔끔한 경계선을 긋는다. 바이브 코딩 = 무모함. 에이전틱 엔지니어링 = AI가 구현을 담당하고, 인간이 아키텍처, 품질, 정확성을 책임진다. 용어 자체가 구분을 강제한다.

---

에이전틱 엔지니어링은 실제로 어떤 모습일까

워크플로는 복잡하지 않지만, 바이브 코딩이 명시적으로 포기하는 규율을 요구한다:

계획으로 시작한다. 무엇이든 프롬프트하기 전에, 설계 문서나 명세를 작성한다 (때로는 AI의 도움을 받아서). 작업을 잘 정의된 태스크로 분할한다. 아키텍처를 결정한다. 바이브 코더들은 이 부분을 건너뛴다. 그래서 프로젝트가 꼬이는 것이다.

지시한 다음 검토한다. 계획에서 명확히 범위가 정해진 태스크를 AI 에이전트에게 준다. AI가 코드를 생성한다. 인간 동료의 PR에 적용할 때와 동일한 엄격함으로 그 코드를 검토한다. 모듈이 무엇을 하는지 설명할 수 없다면, 포함시키지 않는다.

끊임없이 테스트한다. 에이전틱 엔지니어링과 바이브 코딩의 가장 큰 차이점은 테스트다. 견고한 테스트 스위트가 있으면, AI 에이전트가 테스트를 통과할 때까지 루프에서 반복할 수 있어 결과에 대한 높은 확신을 준다. 테스트가 없으면, AI는 깨진 코드에 대해 쾌활하게 "완료"를 선언한다. 테스트는 신뢰할 수 없는 에이전트를 신뢰할 수 있는 시스템으로 변환하는 수단이다.

코드베이스를 소유한다. 문서를 유지한다. 버전 관리와 CI를 사용한다. 프로덕션을 모니터링한다. AI가 작업을 가속화하지만, 시스템에 대한 책임은 본인에게 있다.

이를 잘 수행하는 팀들은 종종 더 빠른 개발을 보고하며, 이러한 성과는 탄탄한 프로세스를 강화한 데서 비롯되지, 프로세스를 포기한 데서 비롯되지 않는다. AI가 보일러플레이트와 단순 반복 작업을 처리한다. 인간은 아키텍처, 정확성, 엣지 케이스, 장기적 유지보수성에 집중한다.

아이러니한 것은, AI 보조 개발이 실제로 전통적인 코딩보다 좋은 엔지니어링 관행에 더 큰 보상을 준다는 것이다. 명세가 좋을수록 AI의 출력도 좋아진다. 테스트가 포괄적일수록 더 자신 있게 위임할 수 있다. 아키텍처가 깔끔할수록 AI가 이상한 추상화를 환각할 가능성이 줄어든다. 한 분석이 지적했듯이, "AI가 문제를 일으킨 것이 아니다. 설계 사고를 건너뛴 것이 문제였다."

---

우리가 논의해온 역량 격차

현장에서의 불편한 진실이 하나 있다. 에이전틱 엔지니어링은 시니어 엔지니어에게 불균형적으로 큰 혜택을 주는 것 같다. 깊은 기본기를 갖추고 있다면(시스템 설계, 보안 패턴, 성능 트레이드오프를 이해한다면), AI를 엄청난 역량 증폭기로 활용할 수 있다. 좋은 코드가 어떤 것인지 알기 때문에, AI 출력을 효율적으로 검토하고 수정할 수 있다.

하지만 주니어면서 기본기를 쌓기 전에 AI에 의존하면, 위험한 역량 위축의 위험이 있다. 코드를 이해하지 못한 채 생산할 수 있다. 특정 패턴이 왜 존재하는지 배우지 않고 기능을 출시할 수 있다. 여러 엔지니어링 리더들이 이를 떠오르는 위기로 지적했다. 프롬프트는 할 수 있지만 디버깅은 못하고, 생성은 할 수 있지만 자신이 생성한 것에 대해 추론하지 못하는 개발자 세대 말이다.

이것은 AI 보조 개발에 반대하는 논거가 아니다. 이것이 무엇을 요구하는지에 대해 솔직해져야 한다는 논거다. 에이전틱 엔지니어링은 전통적인 엔지니어링보다 쉽지 않다. 다른 종류의 어려움이다. 타이핑 시간을 검토 시간으로, 구현 노력을 조율 역량으로, 코드 작성을 코드 읽기와 평가로 교환하는 것이다. 기본기가 덜 중요해지는 것이 아니라 더 중요해진다.

---

앞으로의 방향

방향은 명확하다. AI 에이전트는 점점 더 유능해지고 있으며, 에이전틱 엔지니어링 워크플로는 점점 더 많은 전문 개발자들의 기본 방식이 되고 있다. 이것은 가속화될 것이다.

우리에게 필요한 것:

• 솔직한 용어: 인간의 감독 하에 체계적으로 에이전트가 보조하는 개발을 의미할 때는 에이전틱 엔지니어링이라고 부르자. 재미있고, 무모하고, 프로토타이핑 전용 버전을 의미할 때는 바이브 코딩이라고 부르자. 하나의 용어를 양쪽 모두에 사용하지 말자.
• 더 나은 평가 프레임워크: AI 보조 워크플로가 실제로 단지 더 빠른 소프트웨어가 아니라 신뢰할 수 있는 소프트웨어를 생산하고 있는지 체계적으로 측정할 방법이 필요하다.
• 기본기에 대한 투자: AI가 더 많은 구현을 처리할수록, 아키텍처적 사고, 보안 인식, 시스템 설계에 대한 프리미엄은 낮아지는 것이 아니라 높아진다. 교육 프로그램은 이에 적응해야 한다.

AI 코딩의 부상은 소프트웨어 엔지니어링의 기예를 대체하는 것이 아니다. 그 기준을 높이는 것이다. 성공할 개발자는 가장 빠르게 프롬프트하는 사람이 아니다. 무엇을 왜 만들고 있는지에 대해 가장 명확하게 사고한 다음, AI 에이전트를 포함한 가용한 모든 도구를 활용하여 잘 만드는 사람이다.

바이브 코딩은 모든 관례를 버렸을 때 무엇이 가능한지 보여주었다.

이제 엔지니어링을 다시 가져올 때다. 그것을 있는 그대로 부르자.

---

원문 저자인 Addy Osmani는 O'Reilly에서 Beyond Vibe Coding을 출간했다.