[바이브 엔지니어링] 길벗 챌린지 1주차 후기: 딸깍 개발자의 책임

책 소개

표지 이미지: 길벗 공식 도서 페이지

『바이브 엔지니어링』은 AI에게 코드를 생성해 달라고 요청하는 데서 멈추지 않고, 요구사항 정의부터 설계·검증·테스트·도메인 판단까지 전체 개발 과정을 AI와 함께 이끄는 방법을 다루는 책입니다.
AI가 코드를 만들더라도 무엇을 만들지 정의하고 결과가 올바른지 판단하는 책임은 개발자에게 있다는 관점에서 출발합니다.

[ 길벗 공식 도서 페이지에서 책 정보 보기 ]

[바이브 엔지니어링] 길벗 도서 챌린지 1주차

길벗 도서 챌린지 1주차에는 1장부터 4장 초반까지 읽었습니다.
생성형 AI가 기본 도구가 된 환경에서 무엇을 요구하고, 어떤 기준으로 검증하며, 문제가 생겼을 때 어디서부터 이해해야 하는지를 생각해볼 수 있었습니다.

e-book으로 구매한 『바이브 엔지니어링』

누구나 개발하는 시대. 대딸깍의 시대?

이제 AI가 없는 개발 환경은 상상하기 어렵습니다.
책의 "AI 없이 개발하겠다는 것은 생산성의 포기를 선언하는 것"이라는 말도 참 공감이 갔습니다.
"회사에서 엑셀을 쓰지말고 계산기 쓰세요" 라는 밈이 있었던 것처럼, 굳이 AI를 안써야 하나..? 라는 시대가 되었습니다.
이미 쓸 수 있는 생산성 도구를 일부러 외면할 이유는 없겠죠. 내가 공부를 하고 있는 것이 아니라면 수학적인 문제는 손으로만 풀고 있을 이유가 없습니다.

'대딸깍의 시대'라고 하는데요. 직접 AI로 무언가를 만들어볼수록 '이거 .. 딸깍 맞나 ..?' 라는 생각이 커져만 갔습니다.
겉으로는 "해줘", "더 해줘" 몇 마디로 완성되는 것처럼 보이지만, 좋은 결과를 얻으려면 생각보다 준비할 것이 너무 많았습니다.
내 손으로 수많은 도미노를 하나씩 세운 다음, 첫 도미노를 넘어뜨리며 "와 딸깍했다" 이런 느낌이라고 해야할까요.
그리곤 얼마안가 끊겨버린 도미노로 달려가 다시 똑바로 다시 세운후에 "다시 해보자"라고 하고 있는 것 같습니다.

책은 이를 위해 요구사항 정의, 아키텍처 설계, 맥락 주입, 검증 및 테스트, 리스크 감지라는 핵심 역량을 제시합니다.
AI가 코드를 작성하더라도 무엇을 만들지 정하고, 작업을 나누고, 프로젝트의 제약을 전달하고, 결과를 검증하는 책임은 사람에게 있습니다.
결국 정말 제대로 '딸깍'하려면 공부할 것이 정말 많구나라는 생각이 들었습니다.

단순히 작동한다는 말만으로 부족하다

2장에서는 "기능은 결과를 말하고, 비기능은 조건과 품질을 말한다"는 것이 기억에 남았습니다.
버튼을 누르면 응답이 오고 로그인도 된다면 기능 요구사항은 충족했을 수 있습니다.
그러나 응답에 너무 오래 걸리고, 사용자가 몰리면 서버가 멈추고, 입력값 검증이 없어 공격에 취약하다면 실제 서비스로는 쓸 수 없습니다.

성능, 확장성, 안정성, 보안, 유지보수성 같은 비기능 요구사항은 AI 개발 시대가 오면서 갑자기 생긴 문제들이 아닙니다.
어린 시절 게임만 할 때에도 정말 재미있는 게임이었지만 접속 품질, 서비스 운영같은 것들 때문에 무너지는 게임들을 수도 없이 봤습니다.
친구들과 함께 PC방에 갔는데 접속 대기만 3–4시간 켜놓고 다른 게임만 하다 허탈하게 돌아온 적도 있었죠.
서비스의 핵심 기능을 잘 만들었어도 접속할 수 없거나 동작이 느리다면 그 서비스는 살아남기 어렵습니다.

AI는 사용자의 요청에 충실합니다.
"이런 기능을 만들어줘"라고 하면 코드를 만들 수 있지만, 동시 요청 수와 목표 응답 시간, 장애 시 재시도 등등 이런 문제까지 저절로 해결해주지는 않습니다.
AI가 대충 만든다고 느꼈던 이유 중 일부는 내가 조건과 판단 기준을 충분히 설명하지 않았기 때문일 수 있습니다.
책의 내용을 조금만 구체적으로 들어가도, 그동안 생략했던 고려 사항이 정말 많았습니다.

생각까지 AI에게 떠넘기는 습관

우리는 AI에게 "알아서 해줘"라고 말할 수 있게 되면서 생각하는 일이 더 귀찮아졌습니다.
예전에는 계산기 하나를 만들더라도 실행 환경, 필요한 함수, 화면 구조처럼 다음 단계를 어느 정도 떠올릴 수밖에 없었습니다.
지금은 "계산기 만들어줘"라고 말하는 것만으로 일단은 작동되는 프로그램이 나옵니다.
중간에 너무 많은 것을 생략해버렸기 때문에, 내가 뭘 생각해야하는지, 뭘 빼먹은건지도 모르겠고, 곰곰히 생각해보기도 귀찮아져 버렸습니다.

모르는 작업에 대한 두려움도 더욱더 회피할 수 있게 되었습니다.
예전에는 인터넷에서 코드를 긁어오더라도 내 코드에 붙이려면 최소한 어디 넣어야 하는지 찾아봐야 했습니다.
지금은 내가 잘 모르더라도 통째로 AI에게 맡겨버릴 수 있습니다. 문제는 내가 떠넘기고 피한 영역은 계속 모르는 상태로 넘어간다는 점입니다.

이제는 코드를 AI가 만들지라도, 논리적으로 올바른 코드를 생각하고, 코드를 이해하는 일은 개발자의 성실함과 성의에 가깝습니다.
이 과정을 계속 건너뛸수록 코드는 점점 괴물처럼 기하급수적으로 불어나기 시작합니다.
문제가 생길 때마다 다시 AI에게 고쳐달라고 하지만, 이해하지 못한 코드는 또 다른 문제를 낳기 마련입니다.
코드 생성은 빨라졌지만 검토와 책임은 여전히 개발자의 몫으로 남아있었습니다.

빨간 에러 라인보다 무서운 조용한 버그

3장에서는 문법 오류 없이 성공한 것처럼 보이지만 실제 결과는 틀린 '조용한 버그'를 다룹니다.
실행 순서가 달라지거나, 상태 확인과 변경 사이에 다른 요청이 끼어들거나, 날짜·금액의 경계값을 잘못 처리해도 프로그램은 빨간 에러 라인을 보여주지 않을 수 있습니다.
로그에는 성공으로 남아도, 데이터가 누락되거나 중복되며 데이터가 쌓여버리는 문제가 더 무섭습니다.

이런 오류를 찾으려면 정상 케이스만 확인해서는 부족합니다.
빈 값과 최댓값 같은 에지 케이스, 여러 요청이 동시에 접근하는 상황, 외부 API 지연과 실패, 타임아웃과 재시도까지 고려해야 합니다.
특히 "이 코드가 정상 동작하려면 무엇을 당연하다고 가정하고 있는가?"라는 질문이 중요하게 느껴졌습니다.

개발 경험이 많지 않다면 기능이 실행될 환경과 깨질 수 있는 전제를 처음부터 모두 떠올리기 어렵습니다.
그래서 저는 구현할 때 단위를 작게 나누고, 그때그때 AI에게 실패할 조건과 컨디션, 조합을 의심해달라고 요청하는 방식이 나에게는 현실적인 것인지 생각도 들었습니다.
전체 서비스가 커진 뒤 한 번에 검토를 맡기는 것보다, 컴포넌트를 작성할 때마다 전제와 테스트를 함께 확인하는 습관을 들여야할 것 같았습니다.

오류를 고치기 전에 코드를 이해하기

4장 초반의 디버깅 이야기는 저에게 많이 와닿는 문제였습니다.
오류만 AI에게 던지고 "고쳐줘"라고 하면 당장은 수정된 것처럼 보여도, 제대로 고쳤는지, 다시 문제가 발생 안할지는 모릅니다.
원인을 이해하지 못한 채 AI로 고치기만 반복하면 코드는 복잡해지고 처음 문제가 무엇이었는지도 흐려집니다.

책은 "문제가 뭐야?"보다 "왜 이렇게 짰어?"라고 물으며 코드의 의도, 전제, 실행 흐름을 따라가는 코드 인스펙션을 먼저 제안합니다.
코드가 무엇을 하려는지 이해하고, 상태가 언제 바뀌는지, 그 사이에 다른 요청이 들어오면 어떻게 되는지 질문해야 의심할 지점을 좁힐 수 있습니다.

"문제가 뭐냐"보다 "왜 이렇게 짰냐"를 묻는 코드 인스펙션 내용

책 속에서 코드 작성과 디버깅을 모두 AI에게 맡기는 책의 '용이'라는 인물은 제 모습과도 많이 겹쳤습니다.
바이브 코딩 붐이 일어나기 시작했을 때 "나는 코드를 보지 않는다", "OK만 누르고 오류가 나면 다시 AI에게 맡긴다"는 말이 수없이 공유되곤 했습니다.
그러나 저장소에 연결된 AI의 사용 한도가 끝나거나 급한 장애가 생기면, 코드를 이해하지 못하고 작업한 바이브 코더는 머리가 정지되고 맙니다.
다시 에러를 찾아 검색할 수도 있지만, 빠른 도움에 익숙해진 뒤에는 예전 방식으로 돌아가는 역체감도 클 것입니다.
높은 확률로 사용량을 추가 결제하거나, 다른 AI로 문제를 해결해보려 하겠죠.
이건 꽤나 비즈니스 모델인 것 같기도 하네요.

1주차를 마치며

이번 주에 읽은 내용은 AI에게 적극적으로 맡기되, 인간은 방향과 기준과 책임을 더 분명하게 가져야 한다는 이야기였습니다.
AI가 미시적인 구현을 빠르게 처리할수록 개발자는 거시적인 구조와 품질, 실패 가능성을 생각해야 합니다.

1주차를 지나며 바이브 엔지니어링은 빠르게 만드는 능력에서 멈추지 않고,
요구사항을 조건으로 바꾸고, 코드의 전제를 의심하고, 테스트로 검증하며, 문제가 생겼을 때 흐름을 이해하는 단계입니다.

가장 필요한 변화는 무엇일까요? AI에게 답을 요구하기 전에 판단 기준을 먼저 생각하는 습관일 것입니다.
그리고 코드를 만든 AI에게 곧바로 "이 코드를 의심해 줘"라고 다시 묻는 것입니다.
딸깍은 누구나 할 수 있지만, 그 결과를 책임지는 일은 여전히 사람의 몫이라는 사실이 이번 1주차에서 가장 기억에 남았습니다.