바이브 코딩과 LLM이 규율 없는 엔지니어링 조직이나 엔지니어를 만든 게 아니라, 기존 문제를 드러내고 가속했을 뿐임
많은 엔지니어가 코드 작성 기준과 실천이 느슨하거나 아예 없고, 많은 팀도 코드를 운영 환경에 배포하는 기준이 약함
이건 새로운 현상이 아니라, 소프트웨어 개발 생명주기에서 기준을 지켜본 적 없는 개인과 팀이 훨씬 더 많은 코드를 만들고 아이디어를 구체화하기 쉬워졌다는 뜻
나쁜 엔지니어는 계속 나쁘고, 좋은 엔지니어는 계속 좋음
코드를 빨리 쓴다고 좋은 엔지니어가 된 동료는 본 적이 없음
내가 아는 최고의 엔지니어들은 경험과 신중한 판단을 바탕으로 팀에 중요한 통찰을 공유해 시스템 방향을 좋게 이끈 사람들이었음
“Claude, 시스템 하나 만들어줘. 근데 잘 만들어줘. 고마워!”
많은 사람이 “문제가 되면 그때 고치자”는 사고방식으로 성장해 왔음
예전에는 코드베이스가 기능 개발에 저항하기 시작하면 당장의 병목을 고치고, 다음 저항 지점까지 미루는 식이었음
기능을 만들면서 어느 정도 리팩터링하는 방식이었는데, 최전선 모델들이 “문제가 되는 순간”을 뒤로 밀어버림
주어진 코드 더미를 어느 정도까지는 처리해 주기 때문에, LLM이 회귀를 더 만들거나 요구사항을 더 놓치는 식으로 드러나지만 사람에게 일이 더 어려워진 느낌은 덜함
그러다 어느 순간 너무 많이 깨져서 고쳐야 하는데, 전체 코드베이스가 내가 내리지 않은 결정들의 프랙털식 층이 되어 있어 풀어내기 어려움
직접 코드를 편집하지 않으니 “이걸 이런 방식으로 추가하면 긴장이 크다”는 몸으로 느끼는 반응이 사라져 리팩터링 돌파구를 잡기도 힘들어짐
테스트나 불변조건이 거의 없는 바이브 코딩 앱이 스파게티 코드가 되는 건 당연함
코드는 언제든 리팩터링할 수 있고, 에이전트에게 작고 모듈화된 조각과 파일을 쓰게 강제할 수 있음
에이전트가 썼든 사람이 썼든 좋은 엔지니어링은 좋은 엔지니어링임
아직은 사람이 최소한 아키텍처를 이해하고 주도해야 하며, 에이전트는 정찰과 제안에서 아주 잘 도와줄 수 있음
몇 주 사이의 발전을 놓친 게 아니라면, AI가 더 믿을 만해졌다기보다 오류가 더 미묘해진 것으로 보임
코드가 컴파일되지 않으면 찾기 쉽고, 컴파일되지만 동작하지 않아도 어느 정도 찾기 쉬움
하지만 컴파일되고 동작하는데 일부 경계 조건에서 잘못되거나, 보안 취약점이 있거나, 기술 부채와 의심스러운 아키텍처 결정을 끌고 오면 찾기 훨씬 어려우며 리뷰 부담은 전혀 줄지 않음
오히려 그럴듯한 코드는 명백히 나쁜 코드보다 리뷰할 때 정신적으로 더 부담됨
LLM에게 테스트 주도 개발을 시킬 수는 있음
여러 테스트를 먼저 작성하게 하고 코드가 거기에 맞는지 확인하며, 에이전트가 코드를 올바르게 조직하도록 시키면 됨
LLM의 좋은 용도가 있다는 건 알고 있음
하지만 지금은 위에서 내려오는 열기가 너무 커서 어디든 광범위하게 적용하라는 분위기고, 거기에 반대하면 너무 낙담스럽고 커리어에도 제약이 생겨 정신이 닳아감
명백한 문제를 지적하면 그만큼 많은 우회책이 나오고, 그 우회책에는 곧 또 다른 문제가 드러나며 끝없이 새 해결책을 낳음
어느 순간 이 모든 일이 기계 자체를 위한 작업처럼 느껴짐
많은 회사에서 진짜 목표가 흐려지고 남은 것은 LLM 자체뿐인 것 같음
회사의 미래를 걸고 그 비전을 구현하는 사람들은 결과를 피할 부드러운 출구를 보장받는 건지, 아니면 합리성이 통째로 버려지는 건지 모르겠음
건전한 엔지니어링 원칙으로 문제를 완화할 수는 있겠지만, 인지 부하·개발자 시간·돈·유한한 자원 관점에서 실제로 어떤 효율이 생기는지 의문임
“위험을 감수하기 전에 이미 작동이 검증된 해결책을 원한다”는 말은 여전히 맞고, 경계가 발견되는 지점도 거기일 것임
“하루 200줄에서 2,000줄을 만들 수 있게 되면 무엇이 깨지는가”라는 문장에서, 엔지니어링 산출의 척도로 코드 줄 수를 쓰는 건 부끄러운 일임
여기서 코드 줄 수가 유용한 건 산출량 지표라서가 아니라 이해 가능성의 지표라서임
200줄을 리뷰하는 것과 2,000줄을 리뷰하는 건 완전히 다른 작업량임
바이브 코딩을 실험하면서 코드를 직접 보지 않았더니 리팩터링 후에도 약 1만 줄이 나왔음
같은 프로그램을 내 머리로 다시 만들고 ChatGPT는 검색과 자동완성처럼만 썼더니 1,500줄로 같은 결과가 나옴
노력 차이도 솔직히 아주 크지는 않았지만, 손으로 짠 접근은 먼저 바이브 코딩한 버전 덕분에 만들고 싶은 것을 이미 생각해 둔 이점이 있었을 수 있음
글의 핵심은 코드 작성 산출 속도가 사람이 리뷰할 수 있는 속도를 넘어섰다는 것임
소프트웨어 리뷰의 입력값으로 코드 줄 수를 쓰는 건 말이 됨
말 그대로 각 줄을 읽어야 하기 때문임
코드 줄 수는 엔지니어링 산출의 지표로는 충분히 괜찮음
다만 개발자 생산성의 단독 척도로는 형편없고, 그렇게 쓰려 할 때 문제가 생김
그래도 여러 회사·팀·언어·애플리케이션 맥락에서 즉시 직관적으로 이해되고 비교 가능한 거의 유일한 지표라 유용함
같은 팀이 같은 제품에서 작업해도 1,000줄 변경은 금방 끝날 수 있고, 1줄 버그 수정은 며칠 디버깅이 필요할 수 있음
그래서 PR, 기능, 스토리 포인트를 맥락 밖에서 비교하기는 어렵고, 업계 표준 개발자 생산성 지표가 가능했다면 모두가 썼겠지만 본질적으로 어렵다 봄
이런 비교를 할 때는 맥락이 같다고 가정하면 도움이 됨
예를 들어 특정 회사의 특정 제품을 특정 기술 스택과 품질 프로세스로 만들던 팀이 어제는 N1줄, 오늘은 AI로 N2줄을 만들었다면 시간이 지나며 N1과 N2의 차이가 실제 영향을 근사함
엄밀한 AI 보조 개발 생산성 연구들도 대체로 같은 집단을 대상으로 AI 사용 전후 PR을 비교하는 A/B 테스트식 측정을 해 왔음
코드 줄 수는 엔지니어링 산출에 최악의 지표임. 다른 모든 지표를 제외하면
내 기준에서 차이는 파이프라인의 품질과 엄격함임
바이브 코딩은 한 번 또는 몇 번 시도하고, 결과를 간단히 확인한 뒤 깨질 때까지 쓰는 방식임
가벼운 개념증명이나 위험이 낮은 개인·가족·소규모 팀 앱에 적합함
에이전트식 엔지니어링은 기능적 정확성, 성능, 인프라, 복원력/가용성, 확장성, 유지보수성 같은 더 넓은 관심사를 신경 씀
작업 흐름을 관리하는 다단계 파이프라인이 있고, 프로젝트 접수·선정·명세·에픽 분해·스토리 분해·코딩·문서화·배포 같은 단계가 있을 수 있음
각 단계에는 테스트 통과나 성능 기준 같은 결정적 품질 관문과, 사업 가치·명세 완전성·코드 우아함·유비쿼터스 언어의 엄격함과 단순성 같은 적대적 리뷰가 섞임
이것도 슬라이더임
어떤 때는 기능 하나를 배포하려고 인터뷰하고 토큰을 태우며 세 차례 적대적 리뷰와 가치 추정, 상세 명세까지 하고 싶지 않아 그냥 티켓을 시스템에 던짐
슬라이더가 바이브 코딩과 에이전트식 엔지니어링 사이만 있다면, 사람이 더 깊이 개입하는 넓은 엔지니어링 영역을 놓치고 있음
Opus, GPT-5.5, 더 작은 모델들을 매일 쓰지만 전체 작업을 맡기지는 않음
명세를 정의하고 다듬는 데 꽤 공을 들여도, 인간 PR 리뷰라면 통과시키지 않을 멍청한 일을 여전히 많이 함
산출물을 믿거나 큰 에이전트 파이프라인을 만들어 거짓 안정감을 얻었다면 코드베이스에 그냥 흘러 들어가게 두기 쉬웠을 것임
10년 뒤에는 나아질 수 있겠지만, 지금의 바이브 코딩과 에이전트식 엔지니어링 파이프라인은 모두 LLM에 통째로 위임하는 같은 주제의 변주처럼 보임
오늘 아침에도 단일 파일에서 Opus on Max에게 변경을 맡길 수 있겠다 싶었지만, 거의 매 턴마다 실수하거나 놓치는 부분이 있어 고쳐야 했음
제안한 코드는 대체로 동작했겠지만 너무 복잡했고, 내가 이미 손으로 단순화해 둔 부분을 다시 퇴행시켰음
이런 일이 수천 개의 에이전트 커밋에 곱해지면 코드베이스는 빠르게 나빠짐
바이브 코딩에는 각 단계의 품질 관문이 없고, 에이전트식 엔지니어링에는 있음
개발팀은 설계·테스트·리뷰라는 올바른 프로세스 없이 만들려 할 때 곤란해짐
에이전트 코딩 이전에도 그랬지만 지금은 특히 더 그렇고, 이 프로세스에서 에이전트를 활용하는 법을 이해한 팀이 가장 성공할 것임
코딩 에이전트가 첫 시도에서 해법에 아주 가까이 가지만, 마지막 10%나 5% 를 맞추는 데 엄청난 작업이 필요하다는 걸 느끼지 않았나
문제 접근 방식을 바꾸면 에이전트가 그 간극을 메울 수 있음
10년 전에는 10~15분마다 코딩을 멈추고 리팩터링·테스트·분석을 하며 완벽한지 확인했음
버그가 이후 코드 전체를 오염시키기 때문임
코딩 에이전트는 그렇게 하지도 못하고, 버그나 잘못된 아키텍처를 그대로 안고 계속 감
본능적으로는 에이전트를 중간중간 멈추게 하고 싶지만 여러 이유로 불가능함
대신 비용이 매우 싸니 에이전트가 처음 실수한 지점을 찾아 프롬프트를 고치고, 코드를 수정하는 대신 전부 지운 뒤 처음부터 다시 돌려야 함
프롬프트가 완벽한 코드를 낼 때까지 이 반복을 계속하면 됨
인간이 할 일이 많다는 반론이 나오겠지만, 바로 그게 핵심임
인간은 여전히 필요하고, 이런 식으로 도구를 쓰면 코드 작성 속도는 10배 빨라짐
수동으로 코드를 짤 때도 자주 그랬음
“동작하는 무언가”는 꽤 빨리 만들 수 있지만, 다른 선택지를 평가하고 다듬고 테스트해서 확신을 쌓는 데 오래 걸림
요지는 맞지만 경계가 어디인지는 아무도 모름
앞으로 1년 정도는 모두가 그걸 찾아가는 시기가 될 것이고, 그래서 “GitHub를 재발명해야 한다”는 말도 많이 들리는 것임
인생 전반의 문제는 마지막 5~10%가 항상 가장 어렵다는 것임
많은 경우 그 마지막 부분까지 기계화하려 투자하는 건 경제적으로 맞지 않음
LLM 제공자들은 처음부터 잘못된 접근을 택했다고 봄
노동을 대체하는 데 집중할 게 아니라 노동을 보완하는 데 초점을 뒀어야 했고, 비싼 교훈을 얻은 듯함
나는 일단 동작하게 만든 뒤 리팩터링으로 빠져나오는 편이고, 코딩 에이전트로도 가능하지만 시간이 걸림
처음부터 다시 시작하는 게 나았을 수도 있지만, 시작할 때는 원하는 아키텍처가 어떤 모습인지 몰랐음
코드베이스에 이미 많은 코드가 커밋된 뒤에는 그렇게 깔끔하게 되지 않음
LLM이 기존 아키텍처에 기능을 맞추는 데 애먹는다고 해서, 동작 중인 전체 코드베이스를 날리고 다시 시작할 수는 없음
똑똑하고 겸손하며 계속 배우는 사람이 쓴 훌륭한 글임
마음에 든 문장은 “컴퓨터가 자기 코드를 쓸 수 있게 됐다고 해서 소프트웨어 엔지니어 커리어가 끝났다고 두렵지 않은 이유는 많다. 부분적으로는 이런 것들이 기존 경험의 증폭기이기 때문이다. 뭘 하는지 안다면 훨씬 더 빨리 달릴 수 있다”는 대목임
또 “이 도구들을 쓰며 우리가 하는 일이 얼마나 어려운지 계속 상기된다. 소프트웨어를 만드는 일은 맹렬하게 어렵다. 세상의 모든 AI 도구를 줘도 우리가 여기서 이루려는 일은 여전히 정말 어렵다”는 부분도 좋았음
업스트림 작업도 함께 바뀐다는 지적이 정확함
디자인 쪽 도구가 특히 빠르게 진화하고 있어서, 더 이상 Figma 쪽에 머무르는 번역 비용을 감수할 가치가 없어 보임
무서운 부분은 코드베이스에 AI 복잡성의 층이 쌓이고, 사람이 더는 코드를 이해하지 못해 최신 모델이 해독하고 변경하는 데 큰 비용이 들게 된다는 점임
머지않아 코드 재사용은 사라지고, 바퀴를 계속 다시 발명하느라 돈을 태우게 될 수 있음
이건 예전 Java나 IDE 의존이 강했던 Java/C# 같은 언어와 조금 비슷하지 않나
초기 Android 앱을 만들 때는 IDE를 반드시 써야 했고, 버튼 클릭 후 “Hello World” 알림을 띄우기 위해 말도 안 되는 양의 상용구 코드를 작성해야 해서 영혼이 빠지는 느낌이었음
따라 말해보자: 대부분의 소프트웨어는 수명 대부분을 유지보수 단계에서 보냄
따라서 소프트웨어가 버는 돈 대부분도 유지보수 단계에서 발생함
업계는 거의 100년이 지나도록 아직도 이걸 이해하지 못함
Alan Kay가 컴퓨터 혁명은 아직 일어나지 않았다고 한 말은 100% 맞음
현재의 모든 발전에도 도구들은 대체로 석기시대 수준임
내 큰 희망은 AI가 기존 패러다임을 회복 불가능할 정도로 완전히 깨뜨리는 지점까지 우리를 가속해, 마침내 새롭고 다르고 더 나은 무언가를 할 수 있게 되는 것임
그러니 지금은 AI로 소프트웨어 개발 생명주기에 제트팩을 달고 마음껏 해보자
빠르게 움직이고, 진짜로 깨뜨려보자
시의적절한 관찰이고 나에게도 맞게 느껴짐
비교적 단순한 일괄 다운로드 → 변환 → API 엔드포인트를 세워야 했고, 꽤 상세한 프롬프트를 썼지만 데이터 소스 같은 구현 세부사항은 많이 비워뒀음 Opus 4.7은 내가 했을 방식과 90% 정도 같게 만들었고, 편의 메서드와 단계별 검증은 훨씬 많이 넣었음
아주 좋았고, 더 어려운 문제를 생각할 여유를 줬음
내 경험도 비슷함
주로 Python 개발자지만, Rust나 Go처럼 익숙하되 같은 수준은 아닌 다른 백엔드 언어를 꾸준히 쓰고 있음
한 언어에 크게 치우친 약 13년 경험과 다른 언어에 대한 형식적 학습이 있으니 LLM을 지휘하기가 훨씬 쉬움
문법, 기본 구성요소, 패키지 관리자, 테스트 등을 배우는 부담은 예전 프로그래밍 방식에 비하면 크지 않음
얼마 전 Claude cowork/code로 리포팅 자동화를 하던 비개발자 동료를 도왔음
그 동료는 비즈니스 인텔리전스 쪽은 잘 이해했지만, RDP를 띄우고 공급업체 DB 위의 MS Access 추상화에 값을 채우는 pyautogui 래퍼를 바이브 코딩하기 위한 기본 표현에서 어려움을 겪고 있었음
직업으로서 개발자는 앞으로 5~10년은 괜찮을 것 같음
Hacker News 의견들
바이브 코딩과 LLM이 규율 없는 엔지니어링 조직이나 엔지니어를 만든 게 아니라, 기존 문제를 드러내고 가속했을 뿐임
많은 엔지니어가 코드 작성 기준과 실천이 느슨하거나 아예 없고, 많은 팀도 코드를 운영 환경에 배포하는 기준이 약함
이건 새로운 현상이 아니라, 소프트웨어 개발 생명주기에서 기준을 지켜본 적 없는 개인과 팀이 훨씬 더 많은 코드를 만들고 아이디어를 구체화하기 쉬워졌다는 뜻
코드를 빨리 쓴다고 좋은 엔지니어가 된 동료는 본 적이 없음
내가 아는 최고의 엔지니어들은 경험과 신중한 판단을 바탕으로 팀에 중요한 통찰을 공유해 시스템 방향을 좋게 이끈 사람들이었음
“Claude, 시스템 하나 만들어줘. 근데 잘 만들어줘. 고마워!”
예전에는 코드베이스가 기능 개발에 저항하기 시작하면 당장의 병목을 고치고, 다음 저항 지점까지 미루는 식이었음
기능을 만들면서 어느 정도 리팩터링하는 방식이었는데, 최전선 모델들이 “문제가 되는 순간”을 뒤로 밀어버림
주어진 코드 더미를 어느 정도까지는 처리해 주기 때문에, LLM이 회귀를 더 만들거나 요구사항을 더 놓치는 식으로 드러나지만 사람에게 일이 더 어려워진 느낌은 덜함
그러다 어느 순간 너무 많이 깨져서 고쳐야 하는데, 전체 코드베이스가 내가 내리지 않은 결정들의 프랙털식 층이 되어 있어 풀어내기 어려움
직접 코드를 편집하지 않으니 “이걸 이런 방식으로 추가하면 긴장이 크다”는 몸으로 느끼는 반응이 사라져 리팩터링 돌파구를 잡기도 힘들어짐
코드는 언제든 리팩터링할 수 있고, 에이전트에게 작고 모듈화된 조각과 파일을 쓰게 강제할 수 있음
에이전트가 썼든 사람이 썼든 좋은 엔지니어링은 좋은 엔지니어링임
아직은 사람이 최소한 아키텍처를 이해하고 주도해야 하며, 에이전트는 정찰과 제안에서 아주 잘 도와줄 수 있음
몇 주 사이의 발전을 놓친 게 아니라면, AI가 더 믿을 만해졌다기보다 오류가 더 미묘해진 것으로 보임
코드가 컴파일되지 않으면 찾기 쉽고, 컴파일되지만 동작하지 않아도 어느 정도 찾기 쉬움
하지만 컴파일되고 동작하는데 일부 경계 조건에서 잘못되거나, 보안 취약점이 있거나, 기술 부채와 의심스러운 아키텍처 결정을 끌고 오면 찾기 훨씬 어려우며 리뷰 부담은 전혀 줄지 않음
오히려 그럴듯한 코드는 명백히 나쁜 코드보다 리뷰할 때 정신적으로 더 부담됨
여러 테스트를 먼저 작성하게 하고 코드가 거기에 맞는지 확인하며, 에이전트가 코드를 올바르게 조직하도록 시키면 됨
하지만 지금은 위에서 내려오는 열기가 너무 커서 어디든 광범위하게 적용하라는 분위기고, 거기에 반대하면 너무 낙담스럽고 커리어에도 제약이 생겨 정신이 닳아감
명백한 문제를 지적하면 그만큼 많은 우회책이 나오고, 그 우회책에는 곧 또 다른 문제가 드러나며 끝없이 새 해결책을 낳음
어느 순간 이 모든 일이 기계 자체를 위한 작업처럼 느껴짐
많은 회사에서 진짜 목표가 흐려지고 남은 것은 LLM 자체뿐인 것 같음
회사의 미래를 걸고 그 비전을 구현하는 사람들은 결과를 피할 부드러운 출구를 보장받는 건지, 아니면 합리성이 통째로 버려지는 건지 모르겠음
건전한 엔지니어링 원칙으로 문제를 완화할 수는 있겠지만, 인지 부하·개발자 시간·돈·유한한 자원 관점에서 실제로 어떤 효율이 생기는지 의문임
“하루 200줄에서 2,000줄을 만들 수 있게 되면 무엇이 깨지는가”라는 문장에서, 엔지니어링 산출의 척도로 코드 줄 수를 쓰는 건 부끄러운 일임
200줄을 리뷰하는 것과 2,000줄을 리뷰하는 건 완전히 다른 작업량임
같은 프로그램을 내 머리로 다시 만들고 ChatGPT는 검색과 자동완성처럼만 썼더니 1,500줄로 같은 결과가 나옴
노력 차이도 솔직히 아주 크지는 않았지만, 손으로 짠 접근은 먼저 바이브 코딩한 버전 덕분에 만들고 싶은 것을 이미 생각해 둔 이점이 있었을 수 있음
소프트웨어 리뷰의 입력값으로 코드 줄 수를 쓰는 건 말이 됨
말 그대로 각 줄을 읽어야 하기 때문임
다만 개발자 생산성의 단독 척도로는 형편없고, 그렇게 쓰려 할 때 문제가 생김
그래도 여러 회사·팀·언어·애플리케이션 맥락에서 즉시 직관적으로 이해되고 비교 가능한 거의 유일한 지표라 유용함
같은 팀이 같은 제품에서 작업해도 1,000줄 변경은 금방 끝날 수 있고, 1줄 버그 수정은 며칠 디버깅이 필요할 수 있음
그래서 PR, 기능, 스토리 포인트를 맥락 밖에서 비교하기는 어렵고, 업계 표준 개발자 생산성 지표가 가능했다면 모두가 썼겠지만 본질적으로 어렵다 봄
이런 비교를 할 때는 맥락이 같다고 가정하면 도움이 됨
예를 들어 특정 회사의 특정 제품을 특정 기술 스택과 품질 프로세스로 만들던 팀이 어제는 N1줄, 오늘은 AI로 N2줄을 만들었다면 시간이 지나며 N1과 N2의 차이가 실제 영향을 근사함
엄밀한 AI 보조 개발 생산성 연구들도 대체로 같은 집단을 대상으로 AI 사용 전후 PR을 비교하는 A/B 테스트식 측정을 해 왔음
내 기준에서 차이는 파이프라인의 품질과 엄격함임
바이브 코딩은 한 번 또는 몇 번 시도하고, 결과를 간단히 확인한 뒤 깨질 때까지 쓰는 방식임
가벼운 개념증명이나 위험이 낮은 개인·가족·소규모 팀 앱에 적합함
에이전트식 엔지니어링은 기능적 정확성, 성능, 인프라, 복원력/가용성, 확장성, 유지보수성 같은 더 넓은 관심사를 신경 씀
작업 흐름을 관리하는 다단계 파이프라인이 있고, 프로젝트 접수·선정·명세·에픽 분해·스토리 분해·코딩·문서화·배포 같은 단계가 있을 수 있음
각 단계에는 테스트 통과나 성능 기준 같은 결정적 품질 관문과, 사업 가치·명세 완전성·코드 우아함·유비쿼터스 언어의 엄격함과 단순성 같은 적대적 리뷰가 섞임
이것도 슬라이더임
어떤 때는 기능 하나를 배포하려고 인터뷰하고 토큰을 태우며 세 차례 적대적 리뷰와 가치 추정, 상세 명세까지 하고 싶지 않아 그냥 티켓을 시스템에 던짐
Opus, GPT-5.5, 더 작은 모델들을 매일 쓰지만 전체 작업을 맡기지는 않음
명세를 정의하고 다듬는 데 꽤 공을 들여도, 인간 PR 리뷰라면 통과시키지 않을 멍청한 일을 여전히 많이 함
산출물을 믿거나 큰 에이전트 파이프라인을 만들어 거짓 안정감을 얻었다면 코드베이스에 그냥 흘러 들어가게 두기 쉬웠을 것임
10년 뒤에는 나아질 수 있겠지만, 지금의 바이브 코딩과 에이전트식 엔지니어링 파이프라인은 모두 LLM에 통째로 위임하는 같은 주제의 변주처럼 보임
오늘 아침에도 단일 파일에서 Opus on Max에게 변경을 맡길 수 있겠다 싶었지만, 거의 매 턴마다 실수하거나 놓치는 부분이 있어 고쳐야 했음
제안한 코드는 대체로 동작했겠지만 너무 복잡했고, 내가 이미 손으로 단순화해 둔 부분을 다시 퇴행시켰음
이런 일이 수천 개의 에이전트 커밋에 곱해지면 코드베이스는 빠르게 나빠짐
개발팀은 설계·테스트·리뷰라는 올바른 프로세스 없이 만들려 할 때 곤란해짐
에이전트 코딩 이전에도 그랬지만 지금은 특히 더 그렇고, 이 프로세스에서 에이전트를 활용하는 법을 이해한 팀이 가장 성공할 것임
코딩 에이전트가 첫 시도에서 해법에 아주 가까이 가지만, 마지막 10%나 5% 를 맞추는 데 엄청난 작업이 필요하다는 걸 느끼지 않았나
문제 접근 방식을 바꾸면 에이전트가 그 간극을 메울 수 있음
10년 전에는 10~15분마다 코딩을 멈추고 리팩터링·테스트·분석을 하며 완벽한지 확인했음
버그가 이후 코드 전체를 오염시키기 때문임
코딩 에이전트는 그렇게 하지도 못하고, 버그나 잘못된 아키텍처를 그대로 안고 계속 감
본능적으로는 에이전트를 중간중간 멈추게 하고 싶지만 여러 이유로 불가능함
대신 비용이 매우 싸니 에이전트가 처음 실수한 지점을 찾아 프롬프트를 고치고, 코드를 수정하는 대신 전부 지운 뒤 처음부터 다시 돌려야 함
프롬프트가 완벽한 코드를 낼 때까지 이 반복을 계속하면 됨
인간이 할 일이 많다는 반론이 나오겠지만, 바로 그게 핵심임
인간은 여전히 필요하고, 이런 식으로 도구를 쓰면 코드 작성 속도는 10배 빨라짐
“동작하는 무언가”는 꽤 빨리 만들 수 있지만, 다른 선택지를 평가하고 다듬고 테스트해서 확신을 쌓는 데 오래 걸림
요지는 맞지만 경계가 어디인지는 아무도 모름
앞으로 1년 정도는 모두가 그걸 찾아가는 시기가 될 것이고, 그래서 “GitHub를 재발명해야 한다”는 말도 많이 들리는 것임
많은 경우 그 마지막 부분까지 기계화하려 투자하는 건 경제적으로 맞지 않음
LLM 제공자들은 처음부터 잘못된 접근을 택했다고 봄
노동을 대체하는 데 집중할 게 아니라 노동을 보완하는 데 초점을 뒀어야 했고, 비싼 교훈을 얻은 듯함
처음부터 다시 시작하는 게 나았을 수도 있지만, 시작할 때는 원하는 아키텍처가 어떤 모습인지 몰랐음
LLM이 기존 아키텍처에 기능을 맞추는 데 애먹는다고 해서, 동작 중인 전체 코드베이스를 날리고 다시 시작할 수는 없음
똑똑하고 겸손하며 계속 배우는 사람이 쓴 훌륭한 글임
마음에 든 문장은 “컴퓨터가 자기 코드를 쓸 수 있게 됐다고 해서 소프트웨어 엔지니어 커리어가 끝났다고 두렵지 않은 이유는 많다. 부분적으로는 이런 것들이 기존 경험의 증폭기이기 때문이다. 뭘 하는지 안다면 훨씬 더 빨리 달릴 수 있다”는 대목임
또 “이 도구들을 쓰며 우리가 하는 일이 얼마나 어려운지 계속 상기된다. 소프트웨어를 만드는 일은 맹렬하게 어렵다. 세상의 모든 AI 도구를 줘도 우리가 여기서 이루려는 일은 여전히 정말 어렵다”는 부분도 좋았음
업스트림 작업도 함께 바뀐다는 지적이 정확함
디자인 쪽 도구가 특히 빠르게 진화하고 있어서, 더 이상 Figma 쪽에 머무르는 번역 비용을 감수할 가치가 없어 보임
무서운 부분은 코드베이스에 AI 복잡성의 층이 쌓이고, 사람이 더는 코드를 이해하지 못해 최신 모델이 해독하고 변경하는 데 큰 비용이 들게 된다는 점임
머지않아 코드 재사용은 사라지고, 바퀴를 계속 다시 발명하느라 돈을 태우게 될 수 있음
초기 Android 앱을 만들 때는 IDE를 반드시 써야 했고, 버튼 클릭 후 “Hello World” 알림을 띄우기 위해 말도 안 되는 양의 상용구 코드를 작성해야 해서 영혼이 빠지는 느낌이었음
따라 말해보자: 대부분의 소프트웨어는 수명 대부분을 유지보수 단계에서 보냄
따라서 소프트웨어가 버는 돈 대부분도 유지보수 단계에서 발생함
업계는 거의 100년이 지나도록 아직도 이걸 이해하지 못함
Alan Kay가 컴퓨터 혁명은 아직 일어나지 않았다고 한 말은 100% 맞음
현재의 모든 발전에도 도구들은 대체로 석기시대 수준임
내 큰 희망은 AI가 기존 패러다임을 회복 불가능할 정도로 완전히 깨뜨리는 지점까지 우리를 가속해, 마침내 새롭고 다르고 더 나은 무언가를 할 수 있게 되는 것임
그러니 지금은 AI로 소프트웨어 개발 생명주기에 제트팩을 달고 마음껏 해보자
빠르게 움직이고, 진짜로 깨뜨려보자
시의적절한 관찰이고 나에게도 맞게 느껴짐
비교적 단순한 일괄 다운로드 → 변환 → API 엔드포인트를 세워야 했고, 꽤 상세한 프롬프트를 썼지만 데이터 소스 같은 구현 세부사항은 많이 비워뒀음
Opus 4.7은 내가 했을 방식과 90% 정도 같게 만들었고, 편의 메서드와 단계별 검증은 훨씬 많이 넣었음
아주 좋았고, 더 어려운 문제를 생각할 여유를 줬음
주로 Python 개발자지만, Rust나 Go처럼 익숙하되 같은 수준은 아닌 다른 백엔드 언어를 꾸준히 쓰고 있음
한 언어에 크게 치우친 약 13년 경험과 다른 언어에 대한 형식적 학습이 있으니 LLM을 지휘하기가 훨씬 쉬움
문법, 기본 구성요소, 패키지 관리자, 테스트 등을 배우는 부담은 예전 프로그래밍 방식에 비하면 크지 않음
얼마 전 Claude cowork/code로 리포팅 자동화를 하던 비개발자 동료를 도왔음
그 동료는 비즈니스 인텔리전스 쪽은 잘 이해했지만, RDP를 띄우고 공급업체 DB 위의 MS Access 추상화에 값을 채우는 pyautogui 래퍼를 바이브 코딩하기 위한 기본 표현에서 어려움을 겪고 있었음
직업으로서 개발자는 앞으로 5~10년은 괜찮을 것 같음