AI VIDEO BRIEFING

에이전틱 엔지니어링이란? 바이브 코딩의 한계와 AI 시대 소프트웨어 공학의 재발견

AI로 코드 산출량은 늘었는데 조직 성과는 그대로인 이유는 무엇일까. 젯브레인스 개발자 옹호자가 AI Dev 26 강연에서 제시한 '에이전틱 엔지니어링'의 정의와 평가·스펙·테스트 등 현장 실천 항목을 정리했다.

"바이브 코딩 말고 에이전틱 엔지니어링" — 젯브레인스 개발자 옹호자의 제안 영상 대표 이미지

핵심 메시지

  • AI 코딩 도구로 개인의 생산량은 늘었지만 조직 차원의 성과로는 잘 이어지지 않고 있으며, 강연자는 이를 '오래가지 못하는 성공'이라고 표현했다.
  • 코드 작성은 소프트웨어 공학을 이루는 여러 활동 중 하나일 뿐이어서, 코딩 속도만 끌어올려도 전체 생산성 향상은 부분에 그친다.
  • 에이전틱 엔지니어링은 결과물을 직접 만드는 대신 '만드는 것을 만드는' 체계를 설계하는 일로 엔지니어의 역할을 다시 정의한다.
  • 평가(eval), 스펙 주도 개발, 하네스, 도구 실행 샌드박스, 레드-그린 테스트, 관측성, 컨텍스트 엔지니어링이 구체적 실천 항목으로 제시됐다.
  • 강연자는 경영진에게 '인원 감축'이 아니라 '공학의 복원'이라는 프레임을 전달하는 것이 엔지니어의 몫이라고 주장했다.

쉽게 이해하기

젯브레인스의 개발자 옹호자 폴 에버릿은 AI Dev 26 샌프란시스코 강연에서, 지금 업계가 겪는 혼란을 '개인의 성과는 보이는데 조직의 성과는 보이지 않는 상태'로 요약했다. 그는 청중에게 최근 3개월 안에 에이전트로 코딩해 본 적이 있는지, 그 결과물을 실제 운영 환경에 배포했는지를 손들어 물었고, 배포까지 간 비율이 눈에 띄게 줄어드는 모습을 현장에서 확인시켰다. 올해 말 상황이 어떨지 안다고 손을 든 사람은 한 명도 없었는데, 그는 이 지점을 강연의 출발점으로 삼았다.

그가 꼽은 문제는 다섯 갈래다. 생산성 향상 폭이 기대만큼 크지 않다는 점, 결함률이 높아 품질 신뢰가 흔들린다는 점, 토큰 보조금에 기댄 가격 구조가 바뀌기 시작했다는 점, 개발자들이 생성 결과의 정확성을 크게 믿지 않는다는 점, 그리고 오픈소스 유지보수자와 사내 리뷰어에게 검토 부담이 몰린다는 점이다. 그는 특히 경영진과 엔지니어 사이의 인식 차이를 지적하며, 현장에서 반발이 터져 나오는 상황을 문제의 신호로 읽었다.

해법으로 그가 든 개념이 에이전틱 엔지니어링이다. 안드레이 카파시가 '바이브 코딩'이라는 말을 만든 뒤 스스로 정정하며 제시한 표현으로, 요지는 코드를 직접 짜는 사람에서 '코드를 만들어 내는 시스템을 짜는 사람'으로 역할을 옮기는 것이다. 강연자는 오픈AI 쪽에서 나온 '하네스 엔지니어링' 논의를 인용해, 문제가 생겼을 때 결과물을 손보는 대신 그 문제를 만든 시스템을 고치라고 정리했다. 사람을 없애는 것이 아니라 사람이 병목이 되지 않도록 보강하는 것이 목표라는 단서도 함께 달았다.

실천 항목은 꽤 구체적이다. 스펙은 사람이 작업 방향을 조종하고 이해관계자를 정렬시키는 수단이고, 평가는 '버튼을 눌러 봤더니 되더라'를 공학으로 바꾸는 첫 단계다. 새 모델이 나올 때마다 성능을 측정하는 일이 엔지니어의 일상 업무가 되며, 언제나 모델에 판정을 맡길 수는 없으므로 데이터 과학자의 역할도 다시 늘어난다고 봤다. 이 밖에 에이전트가 필요한 코드를 그때그때 생성해 샌드박스에서 실행하는 방식, 실패하는 테스트를 먼저 작성해 성공 기준을 명확히 하는 레드-그린 테스트, 병렬 서브 에이전트를 염두에 둔 코드베이스 재구성, 일반 시스템 관측성과 AI 관측성을 함께 보는 체계가 언급됐다.

마무리는 조직과 문화 이야기였다. 그는 리더에게 '뒤처져 쓸모없어지는 것에 대한 두려움'을 안고 일하는 구성원을 정직하게 마주하라고 주문했고, 엔지니어에게는 경영진이 실제로 귀 기울이는 상대가 여러분이라는 점을 상기시켰다. 자동화와 인력 대체가 아니라 혁신과 보강 쪽으로 논의를 옮기고, 공학이라는 규율 자체를 복원하자는 것이 그의 결론이다.

주요 인사이트

  • '개인 생산성은 올랐는데 조직 성과는 그대로'라는 진단은 AI 도구 도입을 검토하는 조직이 성과 지표를 어디에 둘지 다시 보게 만든다. 코드 산출량이 아니라 배포까지 이어진 비율을 세는 편이 현실에 가깝다.
  • 평가 체계를 먼저 갖추라는 조언은 실무적으로 가장 실행 가능한 대목이다. 모델이 자주 바뀌는 환경에서는 '어떤 모델이 좋은가'가 아니라 '우리 과제에서 어떤 모델이 좋은지 어떻게 측정할 것인가'가 반복되는 질문이 된다.
  • 실패하는 테스트를 먼저 쓰는 방식이 에이전트와 잘 맞는다는 지적은 흥미롭다. 성공 조건을 코드로 못 박아 두면 에이전트가 사용자를 만족시킬 방법을 헤매지 않고, 팀의 테스트 작성 습관까지 따라 하게 된다.
  • 병렬 서브 에이전트를 전제로 코드베이스의 모듈 경계를 다시 그린다는 발상은 기존 아키텍처 논의와 성격이 다르다. 사람이 읽기 좋은 구조와 에이전트가 다루기 좋은 구조가 갈릴 수 있다는 뜻이다.
  • 강연이 반복해서 강조한 것은 '용어를 바꾸면 프레임이 바뀐다'는 점이다. 바이브 코딩이라는 말이 경영진에게 값싼 자동화로 읽히는 동안에는 투자 논리도 인력 감축 쪽으로 흐를 수밖에 없다는 진단이다.

자주 묻는 질문

에이전틱 엔지니어링은 기존 소프트웨어 공학과 무엇이 다른가요?

강연자는 근본적으로 다른 것이 아니라 공학의 복원에 가깝다고 설명합니다. 다만 초점이 '결과물을 직접 만드는 일'에서 '결과물을 만들어 내는 시스템과 발판을 만드는 일'로 옮겨가며, 그 과정에서 사람이 병목이 되지 않도록 역량을 에이전트 쪽으로 옮기는 작업이 새로 추가된다고 봅니다.

AI 코딩 도구를 도입했는데도 성과가 안 보이는 이유로 무엇이 지목됐나요?

코드 작성이 애초에 병목이 아니었기 때문이라는 설명입니다. 소프트웨어 공학은 코딩 외에도 여러 활동으로 이뤄져 있어, 코딩 단계만 완전히 빨라져도 전체 개선 폭은 일부에 그친다는 것입니다. 여기에 결함률과 검토 부담, 신뢰 문제까지 겹친다고 지적했습니다.

당장 시작할 수 있는 실천 항목으로는 무엇이 제시됐나요?

가장 먼저 평가 체계를 갖추라고 권합니다. 생성된 코드가 적절한 비용과 시도 횟수 안에서 제대로 나왔는지 측정하는 일이 출발점이고, 이어 스펙 주도 개발, 실패 테스트를 먼저 쓰는 레드-그린 테스트, 도구 실행용 샌드박스, 관측성 체계 정비가 언급됐습니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식