Vibe coding과 agentic engineering이 가까워지고 있다 글 소개
-
vibe coding과 agentic engineering은 원래 코드 검토와 책임성 기준으로 구분됐지만, 코딩 에이전트의 신뢰도가 높아지면서 실제 프로덕션 작업에서 경계가 흐려지고 있음
-
vibe coding은 코드를 거의 보지 않고 원하는 결과가 나오면 받아들이는 방식이라 개인 도구에는 유용할 수 있지만, 다른 사람의 정보와 사용 경험이 걸린 소프트웨어에는 무책임한 방식으로 보임
-
Claude Code 같은 에이전트가 JSON API 엔드포인트, SQL 쿼리, 테스트, 문서화를 반복적으로 잘 처리하면서 생성된 모든 코드 줄을 검토하지 않는 일이 생기고, 이는 사람 팀과 달리 평판이나 책임이 없는 대상에 대한 신뢰라는 위험을 만듦
-
이제는 커밋 100개, 좋은 README, 전체 테스트가 있는 저장소도 30분 만에 만들 수 있어 겉모습만으로 품질을 판단하기 어려워졌고, 실제 기준은 누군가 그 소프트웨어를 꾸준히 사용했는지가 됨
-
AI 도구는 소프트웨어 엔지니어의 경험을 대체하기보다 증폭하며, 코드 생산 속도가 하루 200줄에서 2,000줄로 늘면 병목은 설계, 검증, 운영, 실제 사용으로 이동함
Vibe coding과 agentic engineering의 경계
- Heavybit High Leverage 팟캐스트 Ep. #9에서 AI 코딩 도구를 다루며, vibe coding과 agentic engineering이 실제 작업에서 서로 더 가까워지고 있다고 보게 됨
- 이전에는 Not all AI-assisted programming is vibe coding (but vibe coding rocks)에서 vibe coding과 책임 있는 AI 보조 프로그래밍을 분명히 구분했으며, 후자를 이후 agentic engineering이라고 부르기 시작함
- vibe coding은 코드를 거의 보지 않고, 프로그래밍을 모를 수도 있는 사용자가 원하는 결과물을 요청한 뒤 동작하면 받아들이고, 안 되면 다시 요청하는 방식으로 구분됨
- 개인 도구처럼 버그가 자기 자신에게만 피해를 주는 경우에는 vibe coding이 유용할 수 있지만, 다른 사람의 정보와 사용 경험이 걸린 소프트웨어를 만들 때는 무책임한 방식으로 보임
- agentic engineering은 전문 소프트웨어 엔지니어가 보안, 유지보수성, 운영, 성능 같은 제약을 이해한 상태에서 AI 도구를 자기 역량의 최대치로 활용하는 방식임
- 목표는 더 낮은 품질의 결과물을 더 빠르게 만드는 것이 아니라, 더 높은 품질의 프로덕션 시스템을 더 빠르게 만드는 데 있음
- 문제는 코딩 에이전트가 더 신뢰 가능해지면서, 프로덕션 수준 작업에서도 생성된 모든 코드 줄을 더 이상 검토하지 않게 됐다는 데 있음
코드 검토를 생략하게 만드는 신뢰
- Claude Code에 JSON API 엔드포인트를 만들고, SQL 쿼리를 실행해 결과를 JSON으로 출력하도록 요청하면 제대로 처리할 것이라는 확신이 생김
- 자동화 테스트와 문서화를 추가하게 해도 결과물이 괜찮을 것이라고 기대하게 되며, 그 과정에서 실제 코드를 검토하지 않는 경우가 생김
- 코드를 검토하지 않았다면 프로덕션에 사용하는 것이 책임 있는 일인지에 대한 죄책감이 남음
- 큰 조직에서 엔지니어링 매니저로 일할 때 다른 팀의 소프트웨어를 사용하는 방식과 비슷하게 볼 수 있음
- 다른 팀이 이미지 리사이즈 서비스를 제공하면, 보통 그 팀이 작성한 모든 코드 줄을 읽지 않음
- 문서를 보고 이미지를 리사이즈해 본 뒤 자기 기능을 출시함
- 버그나 성능 문제가 보일 때에야 Git 저장소를 들여다볼 수 있음
- 대부분의 경우 해당 서비스를 반쯤 블랙박스처럼 다룸
- 에이전트도 점점 같은 방식으로 다루게 되지만, 사람 팀과 달리 Claude Code에는 전문적 평판이나 책임(accountability)이 없음
- 사람 팀은 과거에 좋은 소프트웨어를 만들며 평판을 쌓을 수 있고, 형편없는 결과물이 자신의 전문적 평판에 영향을 준다는 압박을 받음
- Claude Code는 그런 평판을 가질 수 없지만, 반복적으로 단순한 작업을 선호하는 스타일에 맞게 올바르게 처리하면서 신뢰를 쌓고 있음
- 여기에는 일탈의 정상화 요소가 있음
- 모델이 가까이 감시하지 않아도 올바른 코드를 작성할 때마다 신뢰가 커짐
- 나중에 잘못된 순간에 과신해 피해를 볼 위험도 함께 커짐
소프트웨어 평가가 더 어려워짐
- 예전에는 GitHub 저장소에 커밋 100개, 좋은 README, 자동화 테스트가 있으면 프로젝트에 상당한 정성과 주의가 들어갔다고 판단하기 쉬웠음
- 이제는 커밋 100개, 아름다운 README, 모든 코드 줄을 포괄하는 테스트가 있는 Git 저장소를 30분 만에 만들 수 있음
- 이런 저장소는 오랜 정성과 주의가 들어간 프로젝트와 겉보기에는 동일하게 보일 수 있음
- 실제로 그만큼 좋을 수도 있지만, 겉으로 봐서는 알기 어렵고 자기 프로젝트에 대해서도 같은 문제가 생김
- 테스트와 문서의 품질보다 더 중요하게 보는 기준은 누군가가 그 소프트웨어를 실제로 사용했는지임
- vibe coded 결과물이라도 만든 사람이 지난 2주 동안 매일 사용했다면, 거의 실행해 보지 않고 뱉어낸 결과물보다 훨씬 더 가치 있다고 봄
병목은 코드 작성에서 다른 단계로 이동함
- 하루에 코드 200줄을 만들던 상황에서 2,000줄을 만들 수 있게 되면, 소프트웨어 개발 생애주기의 다른 부분이 깨지기 시작함
- 기존 소프트웨어 개발 생애주기는 하루에 코드 몇백 줄을 만드는 속도를 전제로 설계돼 있었음
- 병목 변화는 하류 단계뿐 아니라 상류 단계에도 영향을 줌
- Jenny Wen의 발표에서는 기존 디자인 프로세스가 “디자인을 제대로 맞춰야 한다”는 전제를 갖고 있다고 봄
- 엔지니어에게 넘긴 뒤 잘못된 것을 3개월 동안 만들면 재앙이 되기 때문임
- 디자인이 값비싼 작업으로 이어지기 때문에 광범위한 디자인 프로세스를 둠
- 하지만 빌드에 3개월이 걸리지 않는다면, 잘못됐을 때 비용이 크게 낮아졌기 때문에 디자인 프로세스가 훨씬 더 위험을 감수할 수 있음
그래도 소프트웨어 엔지니어 커리어가 끝났다고 보지 않는 이유
- 에이전트와의 대화는 대다수 사람에게 알아듣기 어려운 “moon language”처럼 보임
- 컴퓨터가 스스로 코드를 쓸 수 있게 됐다고 해서 소프트웨어 엔지니어 커리어가 끝났다고 보지 않는 이유 중 하나는, 이런 도구가 기존 경험을 증폭하기 때문임
- 무엇을 하고 있는지 아는 사람은 AI 도구와 함께 훨씬 더 빠르게 움직일 수 있음
- AI 도구를 사용할수록 소프트웨어 제작 자체가 매우 어렵다는 사실이 반복적으로 확인됨
- 모든 AI 도구가 주어져도 달성하려는 일은 여전히 어렵다고 봄
- Matthew Yglesias는 트윗에서 "5개월이 지나고 보니 vibecode를 하고 싶지 않다. 전문적으로 관리되는 소프트웨어 회사들이 AI 코딩 보조를 사용해 더 많고, 더 좋고, 더 저렴한 소프트웨어 제품을 만들어 나에게 돈을 받고 팔았으면 한다" 고 썼고, 여기에 동의함
- 배관 관련 YouTube 영상을 충분히 보면 직접 집 배관을 고칠 수도 있지만, 배관공을 고용하는 편을 선호한다는 비유로 정리됨
SaaS와 사내 제작의 위험
- 기업이 SaaS를 쓰지 않고 자체 솔루션을 만들 수 있게 되는 위협에 대해서도, 실제 사용으로 검증된 소프트웨어를 선호한다는 기준이 그대로 적용됨
- 개인 프로젝트에서는 적어도 몇 주 동안 만든 사람이 직접 사용한 도구를 선호함
- 엔터프라이즈 버전으로 바꾸면, 적어도 두 개의 다른 대기업이 6개월 동안 성공적으로 사용한 CRM이 아니라면 도입하고 싶지 않다는 기준이 됨
- 위험을 감수하기 전에 실제로 작동한다고 입증된 솔루션을 원함
Hacker News 의견들
- 바이브 코딩과 LLM이 규율 없는 엔지니어링 조직이나 엔지니어를 만든 게 아니라, 기존 문제를 드러내고 가속했을 뿐임. 많은 엔지니어가 코드 작성 기준과 실천이 느슨하거나 아예 없고, 많은 팀도 코드를 운영 환경에 배포하는 기준이 약함. 이건 새로운 현상이 아니라, 소프트웨어 개발 생명주기에서 기준을 지켜본 적 없는 개인과 팀이 훨씬 더 많은 코드를 만들고 아이디어를 구체화하기 쉬워졌다는 뜻
- 나쁜 엔지니어는 계속 나쁘고, 좋은 엔지니어는 계속 좋음. 코드를 빨리 쓴다고 좋은 엔지니어가 된 동료는 본 적이 없음. 내가 아는 최고의 엔지니어들은 경험과 신중한 판단을 바탕으로 팀에 중요한 통찰을 공유해 시스템 방향을 좋게 이끈 사람들이었음. "Claude, 시스템 하나 만들어줘. 근데 잘 만들어줘. 고마워!"
- 많은 사람이 "문제가 되면 그때 고치자" 는 사고방식으로 성장해 왔음. 예전에는 코드베이스가 기능 개발에 저항하기 시작하면 당장의 병목을 고치고, 다음 저항 지점까지 미루는 식이었음. 기능을 만들면서 어느 정도 리팩터링하는 방식이었는데, 최전선 모델들이 "문제가 되는 순간" 을 뒤로 밀어버림. 주어진 코드 더미를 어느 정도까지는 처리해 주기 때문에, LLM이 회귀를 더 만들거나 요구사항을 더 놓치는 식으로 드러나지만 사람에게 일이 더 어려워진 느낌은 덜함. 그러다 어느 순간 너무 많이 깨져서 고쳐야 하는데, 전체 코드베이스가 내가 내리지 않은 결정들의 프랙털식 층이 되어 있어 풀어내기 어려움. 직접 코드를 편집하지 않으니 "이걸 이런 방식으로 추가하면 긴장이 크다" 는 몸으로 느끼는 반응이 사라져 리팩터링 돌파구를 잡기도 힘들어짐
- 테스트나 불변조건이 거의 없는 바이브 코딩 앱이 스파게티 코드가 되는 건 당연함. 코드는 언제든 리팩터링할 수 있고, 에이전트에게 작고 모듈화된 조각과 파일을 쓰게 강제할 수 있음. 에이전트가 썼든 사람이 썼든 좋은 엔지니어링은 좋은 엔지니어링임. 아직은 사람이 최소한 아키텍처를 이해하고 주도해야 하며, 에이전트는 정찰과 제안에서 아주 잘 도와줄 수 있음
- 몇 주 사이의 발전을 놓친 게 아니라면, AI가 더 믿을 만해졌다기보다 오류가 더 미묘해진 것으로 보임. 코드가 컴파일되지 않으면 찾기 쉽고, 컴파일되지만 동작하지 않아도 어느 정도 찾기 쉬움. 하지만 컴파일되고 동작하는데 일부 경계 조건에서 잘못되거나, 보안 취약점이 있거나, 기술 부채와 의심스러운 아키텍처 결정을 끌고 오면 찾기 훨씬 어려우며 리뷰 부담은 전혀 줄지 않음. 오히려 그럴듯한 코드는 명백히 나쁜 코드보다 리뷰할 때 정신적으로 더 부담됨
- LLM에게 테스트 주도 개발을 시킬 수는 있음. 여러 테스트를 먼저 작성하게 하고 코드가 거기에 맞는지 확인하며, 에이전트가 코드를 올바르게 조직하도록 시키면 됨
- LLM의 좋은 용도가 있다는 건 알고 있음. 하지만 지금은 위에서 내려오는 열기가 너무 커서 어디든 광범위하게 적용하라는 분위기고, 거기에 반대하면 너무 낙담스럽고 커리어에도 제약이 생겨 정신이 닳아감. 명백한 문제를 지적하면 그만큼 많은 우회책이 나오고, 그 우회책에는 곧 또 다른 문제가 드러나며 끝없이 새 해결책을 낳음. 어느 순간 이 모든 일이 기계 자체를 위한 작업처럼 느껴짐. 많은 회사에서 진짜 목표가 흐려지고 남은 것은 LLM 자체뿐인 것 같음
- "위험을 감수하기 전에 이미 작동이 검증된 해결책을 원한다" 는 말은 여전히 맞고, 경계가 발견되는 지점도 거기일 것임
- "하루 200줄에서 2,000줄을 만들 수 있게 되면 무엇이 깨지는가" 라는 문장에서, 엔지니어링 산출의 척도로 코드 줄 수를 쓰는 건 부끄러운 일임
- 여기서 코드 줄 수가 유용한 건 산출량 지표라서가 아니라 이해 가능성의 지표라서임. 200줄을 리뷰하는 것과 2,000줄을 리뷰하는 건 완전히 다른 작업량임
- 바이브 코딩을 실험하면서 코드를 직접 보지 않았더니 리팩터링 후에도 약 1만 줄이 나왔음. 같은 프로그램을 내 머리로 다시 만들고 ChatGPT는 검색과 자동완성처럼만 썼더니 1,500줄로 같은 결과가 나옴
- 글의 핵심은 코드 작성 산출 속도가 사람이 리뷰할 수 있는 속도를 넘어섰다는 것임. 소프트웨어 리뷰의 입력값으로 코드 줄 수를 쓰는 건 말이 됨. 말 그대로 각 줄을 읽어야 하기 때문임
- 코드 줄 수는 엔지니어링 산출의 지표로는 충분히 괜찮음. 다만 개발자 생산성의 단독 척도로는 형편없고, 그렇게 쓰려 할 때 문제가 생김
- 내 기준에서 차이는 파이프라인의 품질과 엄격함임. 바이브 코딩은 한 번 또는 몇 번 시도하고, 결과를 간단히 확인한 뒤 깨질 때까지 쓰는 방식임. 가벼운 개념증명이나 위험이 낮은 개인, 가족, 소규모 팀 앱에 적합함. 에이전트식 엔지니어링은 기능적 정확성, 성능, 인프라, 복원력/가용성, 확장성, 유지보수성 같은 더 넓은 관심사를 신경 씀. 작업 흐름을 관리하는 다단계 파이프라인이 있고, 프로젝트 접수, 선정, 명세, 에픽 분해, 스토리 분해, 코딩, 문서화, 배포 같은 단계가 있을 수 있음
- 슬라이더가 바이브 코딩과 에이전트식 엔지니어링 사이만 있다면, 사람이 더 깊이 개입하는 넓은 엔지니어링 영역을 놓치고 있음. Opus, GPT-5.5, 더 작은 모델들을 매일 쓰지만 전체 작업을 맡기지는 않음. 명세를 정의하고 다듬는 데 꽤 공을 들여도, 인간 PR 리뷰라면 통과시키지 않을 멍청한 일을 여전히 많이 함
- 바이브 코딩에는 각 단계의 품질 관문이 없고, 에이전트식 엔지니어링에는 있음. 개발팀은 설계, 테스트, 리뷰라는 올바른 프로세스 없이 만들려 할 때 곤란해짐. 에이전트 코딩 이전에도 그랬지만 지금은 특히 더 그렇고, 이 프로세스에서 에이전트를 활용하는 법을 이해한 팀이 가장 성공할 것임
- 코딩 에이전트가 첫 시도에서 해법에 아주 가까이 가지만, 마지막 10%나 5% 를 맞추는 데 엄청난 작업이 필요하다는 걸 느끼지 않았나. 문제 접근 방식을 바꾸면 에이전트가 그 간극을 메울 수 있음. 10년 전에는 10~15분마다 코딩을 멈추고 리팩터링, 테스트, 분석을 하며 완벽한지 확인했음. 버그가 이후 코드 전체를 오염시키기 때문임. 코딩 에이전트는 그렇게 하지도 못하고, 버그나 잘못된 아키텍처를 그대로 안고 계속 감. 본능적으로는 에이전트를 중간중간 멈추게 하고 싶지만 여러 이유로 불가능함. 대신 비용이 매우 싸니 에이전트가 처음 실수한 지점을 찾아 프롬프트를 고치고, 코드를 수정하는 대신 전부 지운 뒤 처음부터 다시 돌려야 함
- 수동으로 코드를 짤 때도 자주 그랬음. "동작하는 무언가" 는 꽤 빨리 만들 수 있지만, 다른 선택지를 평가하고 다듬고 테스트해서 확신을 쌓는 데 오래 걸림
- 인생 전반의 문제는 마지막 5~10%가 항상 가장 어렵다는 것임. 많은 경우 그 마지막 부분까지 기계화하려 투자하는 건 경제적으로 맞지 않음. LLM 제공자들은 처음부터 잘못된 접근을 택했다고 봄. 노동을 대체하는 데 집중할 게 아니라 노동을 보완하는 데 초점을 뒀어야 했고, 비싼 교훈을 얻은 듯함
- 나는 일단 동작하게 만든 뒤 리팩터링으로 빠져나오는 편이고, 코딩 에이전트로도 가능하지만 시간이 걸림. 처음부터 다시 시작하는 게 나았을 수도 있지만, 시작할 때는 원하는 아키텍처가 어떤 모습인지 몰랐음
- 코드베이스에 이미 많은 코드가 커밋된 뒤에는 그렇게 깔끔하게 되지 않음. LLM이 기존 아키텍처에 기능을 맞추는 데 애먹는다고 해서, 동작 중인 전체 코드베이스를 날리고 다시 시작할 수는 없음
- 똑똑하고 겸손하며 계속 배우는 사람이 쓴 훌륭한 글임. 마음에 든 문장은 "컴퓨터가 자기 코드를 쓸 수 있게 됐다고 해서 소프트웨어 엔지니어 커리어가 끝났다고 두렵지 않은 이유는 많다. 부분적으로는 이런 것들이 기존 경험의 증폭기이기 때문이다. 뭘 하는지 안다면 훨씬 더 빨리 달릴 수 있다" 는 대목임. 또 "이 도구들을 쓰며 우리가 하는 일이 얼마나 어려운지 계속 상기된다. 소프트웨어를 만드는 일은 맹렬하게 어렵다. 세상의 모든 AI 도구를 줘도 우리가 여기서 이루려는 일은 여전히 정말 어렵다" 는 부분도 좋았음
원문
출처 / GeekNews
[GN] 함께 보면 좋은 글β
알려드립니다
이 글은 국내외 IT 소식들을 공유하는 GeekNews의 운영자이신 xguru님께 허락을 받아 GeekNews에 게제된 AI 관련된 소식을 공유한 것입니다.
출처의 GeekNews 링크를 방문하시면 이 글과 관련한 추가적인 의견들을 보시거나 공유하실 수 있습니다! 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식을 정리하고 공유하는데 힘이 됩니다~ 
