Vibe coding 및 Agentic engineering이 더 빠르게 융합되고 있다

Vibe coding 및 Agentic engineering이 더 빠르게 융합되고 있다

2026 년 5 월 6 일

최근 Simon Willison 의 High Leverage podcast 에 출연하여 Heavybit 의 Joseph Ruscio 와 AI 코딩 도구에 대해 이야기했습니다. Ep. #9, The AI Coding Paradigm Shift with Simon Willison 입니다. 여기에는 제가 Vibe coding 과 Agentic engineering 이 제 작업에서 시작되어 융합되고 있다는 놀라운 깨달음을 포함하여 몇 가지 주요 포인트를 정리합니다.

팟캐스트의 가장 큰 장점 중 하나는 생각할 때 말로 표현하는 것을 강요하고, 이전에 언어로 표현하지 못했던 아이디어를 드러내는 경우가 있다는 것입니다.

Vibe coding 과 Agentic engineering 이 시작되어 겹치고 있다

Vibe coding 이 처음 언급된 지 몇 주 후 저는 Not all AI-assisted programming is vibe coding (but vibe coding rocks) 을 발표하여, "Vibe coding" 은 책임 있는 AI 코드 작성과 매우 다른 존재라고 확실히 주장했습니다. 이후 저는 이를 Agentic engineering 으로 부르기 시작했습니다.

Joseph 이 두 가지의 구분을 언급했을 때, 제가 생각했던 것보다 훨씬 더 뚜렷한 차이가 있다는 것을 깨달았습니다:

그런데도, 흥미롭게도 이미 그 둘이 제게는 흐려지고 있습니다. 이는 매우 걱정스러운 일입니다.

제가 Vibe coding 을 생각할 때는 코드를 전혀 보지 않는 것이었습니다. 심지어 프로그래밍을 할 줄 모를 수도 있습니다. 비프로그래머가 일을 요청하고 일을 얻고, 일이 작동하면 훌륭하며, 작동하지 않으면 작동하지 않는다고 말하고 손가락을 감싸는 것입니다.

하지만 어느 순간에도 코드 품질이나 추가적인 제약 조건에 대해 진지하게 고려하지 않습니다. 제 Vibe coding 의 견해는 그것이 사용될 수 있는 경우와 사용할 수 없는 경우를 이해할 때 훌륭하다는 것입니다.

개인용 도구로, 버그가 발생하면 오직 당신만 고통을 겪습니다. 진행하세요!

다른 사람을 위한 소프트웨어를 개발하는 경우, Vibe coding 은 매우 무책임합니다. 그것은 다른 사람의 정보이기 때문입니다. 당신의 바보 같은 버그 때문에 다른 사람들이 상합니다. 더 높은 수준이 필요합니다.

이는 Agentic engineering 과 대조됩니다. 당신은 전문 소프트웨어 엔지니어입니다. 보안과 유지보수 및 운영 및 성능 등을 이해합니다. 그리고 이러한 도구를 최대한의 능력으로 사용합니다. 저는 이러한 도구들의 지원으로 인해 수용할 수 있는 도전의 범위가 크게 증가했습니다.

하지만我还是 25 년간의 소프트웨어 엔지니어 경험에 의존하고 있습니다.

목표는 고품질의 프로덕션 시스템을 구축하는 것입니다. 더 낮은 품질의 것을 더 빠르게 만든다면, 그것은 나쁘다고 생각합니다. 저는 더 높은 품질의 것을 더 빠르게 만들고 싶습니다. 제가 만드는 모든 것이 이전보다 모든 면에서 더 좋기를 바랍니다.

그 문제는 코딩 에이전트가 더 신뢰할 수 있게 되면서, 제 프로덕션 레벨의 것들조차도 그들이 작성하는 코드 줄을 더 이상 검토하지 않는다는 것입니다.

제가 클로드 코드 (Claude Code) 에 JSON API 엔드포인트를 구축하여 SQL 쿼리를 실행하고 결과를 JSON 으로 출력하라고 요청하면, 그것은 바로 그것을 올바르게 수행할 것입니다. 그것은 그것을 망칠 것입니다. 자동화된 테스트를 추가하고 문서화를 추가하라고 하면, 그것은 좋은 것을 할 것입니다.

하지만 저는 그 코드를 검토하지 않습니다. 그리고 이제 저는 죄책감을 느낍니다: 제가 코드를 검토하지 않았다면, 이를 프로덕션에 사용하는 것은 정말로 제게 책임 있는 일입니까?

저에게 가장 도움이 되는 것은 과거 대형 조직에서 엔지니어링 매니저로 일했을 때의 경험을 되돌아보는 것입니다. 다른 팀이 제 팀이 의존하는 소프트웨어를 개발하고 있습니다.

다른 팀이 어떤 것을 넘겨주고 "hey, 이거 이미지 리사이즈 서비스야, 이미지를 리사이즈하려면 이렇게 사용하세요"라고 말하면... 저는 그들이 작성한 모든 코드 줄을 읽지 않을 거예요.

저들은 그들의 문서를 보고, 그 문서를 사용해 몇 개의 이미지를 리사이즈하고, 그런 다음 제 기능을 출시하기 시작할 것입니다. 그리고 만약 이미지 리사이즈 기능이 버그가 있거나 성능이 좋지 않아 문제가 발생한다면, 그때는 Git 저장소를 파고들어 상황을 파악할 수 있습니다. 하지만 대개 저는 그것을 반검 (semi-black box) 으로 취급하며 필요할 때까지 보지 않습니다.

저는 이제 에이전트도 같은 방식으로 취급하기 시작했습니다. 여전히 불편한데, 인간은 자신이 한 일에 책임을 져야 하기 때문입니다. 팀은 평판을 쌓을 수 있습니다. "저 팀에 신뢰합니다. 과거 좋은 소프트웨어를 개발했으니, 그들이 쓰레기 같은 것을 만들지는 않을 거예요. 그건 그들의 전문적 평판에 영향을 미치니까요."라고 할 수 있습니다.

Claude Code 는 전문적인 평판이 없습니다! 자신이 한 일에 책임을 져야 합니다. 하지만 그럼에도 불구하고 스스로 증명해 왔습니다—시간과 시간마다 저는 단순한 것들을 만들어내고, 제가 좋아하는 방식으로 올바르게 수행합니다.

여기에는 편차의 정상화 (normalization of deviance) 요소가 있습니다. 모델이 저의 세밀한 감시를 하지 않고도 올바른 코드를 작성했으면, 미래에 잘못된 시기에 신뢰할 위험이 있고 그 결과 피해를 입게 될 수 있습니다.

소프트웨어 평가의 새로운 과제

과거에는 GitHub 저장소 100 개의 커밋과 좋은 README 및 자동화된 테스트 등이 있다면, 해당 프로젝트에 많은 관심과 주의가 기울였음을 비교적 확신할 수 있었습니다.

이제 저는 반 시간 만에 100 개의 커밋을 가진 Git 저장소를 생성하고, 아름다운 README 와 코드 줄의 모든 줄에 대한 포괄적인 테스트를 만들 수 있습니다! 그것은 많은 관심과 주의가 기울어진 프로젝트와 동일하게 보입니다. 아마도 그들과 동등할지도 모릅니다. 저는 알지 못합니다. 그것을 보았을 때 알 수 없습니다. 심지어 제

프로젝트조차도, 저는 알지 못합니다. 그래서 저는 테스트 및 문서의 질보다 더 가치 있는 것이 무엇인지 깨달았습니다. 제가 누군가가 그 것을 사용했기를 원한다는 것입니다. 2 주 동안 매일 사용한 "vibe coded" (감성 코딩) 것이라면, 그것은 당신이 단지吐出하고 거의 연습하지 않은 것보다 저에게 더 가치가 있습니다.

병목 현상이 이동했습니다

하루에 200 줄의 코드를 작성하는 것을 2,000 줄로 늘릴 수 있다면, 무엇이 깨질까요? 전체 소프트웨어 개발 라이프사이클은 하루에 몇백 줄의 코드를 작성하는 데 걸린다는 개념으로 설계되었습니다. 이제 그것은 아닙니다.

그것은 다운스트림뿐만 아니라 업스트림도 마찬가지입니다. 저는 Anthropic 의 디자인 리더인 Jenny Wen 의 훌륭한 연설을 보았습니다. 그녀는 우리가 이러한 모든 디자인 프로세스가 당신이 디자인을 얻어야 한다는 개념에 기반하고 있다고 말했습니다.

맞습니다—if engineers에게 넘겨주고 그들이 잘못된 것을 세 달 동안 만들어낸다면, 그것은 재앙적입니다.

이러한 설계 과정은 매우 광범위하게 설정되어 있습니다. 왜냐하면 그 설계는 비용이 많이 드는 작업으로 이어지기 때문입니다. 하지만 만약 세 달 만에 만들어지지 않는다면, 설계 과정은 훨씬 더 위험할 수 있습니다. 왜냐하면 잘못되면 비용이 크게 줄어든 것이기 때문입니다.

왜 저는 여전히 내 경력에 대해 두려워하지 않습니다

저와 에이전트와의 대화들을 볼 때, 이것이 대부분의 인간들에게는 'moon language'라고 매우 명확합니다.

컴퓨터가 자신의 코드를 작성할 수 있게 되면서 소프트웨어 엔지니어로서의 제 경력이 끝날까 봐 두려운 이유는 여러 가지가 있습니다. 이 것들은 기존 경험을 증폭시키는 도구이기 때문입니다. 당신이 무엇을 하는지 알면, 이 도구들을 사용하여 훨씬 더 빠르게 움직일 수 있습니다. [...]

저는 이러한 도구를 사용하며 일할 때마다 우리가 하는 일이 얼마나 어려운지 계속 깨닫습니다. 소프트웨어를 만드는 것은 매우 어렵습니다. 그리고 세계의 모든 AI 도구를 주어도 우리는 여전히 정말로 어렵게 달성해야 합니다. [...]
Matthew Yglesias, 정치 코멘테이터인 그는 어제 트위터에 "5 개월이 지났고, 저는 더 이상 vibecode 하고 싶지 않다고 생각합니다. 저는 professionally managed software companies 가 AI coding assistance 를 사용하여 제가 돈을 위해 판매하는 소프트웨어 제품들을 더 많거나 더 좋거나 저렴하게 만들기를 원합니다"라고 Tweet 했습니다. 그리고 그것은 제 생각에 맞습니다. 저는 충분한 양의 YouTube 비디오를 시청하면 배관 공부를 할 수 있습니다. 저는 배관공을 고용할 것입니다.

SaaS 제공업체에 대한 위협에 대해:

저는 이제 제가 앞서 말한 것처럼, 당신의 사소한 프로젝트만 몇 주 동안 사용했다면 그것을 사용하고 싶다고 생각했습니다. 그 기업 버전은 최소 두 개의 다른 대기업이 해당 CRM 을 6 개월 동안 성공적으로 사용했으면 저는 CRM 을 원하지 않는다는 것입니다. [...] 당신은 위험을 감수하기 전에 작동하는 것을 증명된 솔루션을 원합니다.