12장: 독서모임 리뷰 — 본.깨.적과 퍼실리테이션

들어가며

이 챕터는 2026년 2월 2일에 진행된 독서모임에서 내가 정리한 회고와 토론 답변이다. 앞선 11개 장이 책의 내용을 따라가며 정리한 요약 노트라면, 이 장은 같은 책을 읽고 동료들과 나눈 대화 끝에 내가 직접 메모해 둔 흔적에 가깝다. 본.깨.적과 퍼실리테이션 두 형식을 함께 정리했고, 책의 메시지를 현장에 어떻게 가져올지에 대한 거친 결론까지 담고 있다.

책 자체에 대한 평가는 뒤에서 다시 다루지만, 미리 한 줄로 정리하자면 트렌드를 따라잡고 있는 사람에게는 복기에 가깝고 입문자에게는 좋은 출발점이라는 정도였다. 그래서 회고도 새로운 발견보다는, 이미 알고 있던 원칙들을 어디에 어떻게 다시 꽂아 넣을지를 정리하는 방향으로 흘러갔다.

본.깨.적: 책에서 본 것, 깨달은 것, 적용할 것

바이브 코딩과 AI 보조 엔지니어링의 정의와 구분

책의 출발점인 두 개념을 다시 한 번 또렷하게 구분해 두고 싶었다. 바이브 코딩은 "개발자가 바이브에 몸을 맡긴 채 AI 지원을 받는" 즉흥적이고 실험적인 방식이며, 안드레 카파시가 처음 제시한 표현이다. 책의 분류를 빌리자면 부트스트래퍼의 영역에 가깝다. 반면 AI 보조 엔지니어링은 명확하고 체계적인 방식으로, 빠른 코드 작성보다 고품질의 코드를 만들어 가는 데 무게가 실린다. 이터레이터의 영역이다.

핵심은 어느 한쪽이 옳다는 식의 이분법이 아니라, 둘 사이의 트레이드오프를 이해하고 상황에 맞게 도구를 골라 쓰는 능력이다. 이 구분만은 헷갈리지 않도록 머릿속에 단단히 박아두기로 했다.

대화를 통한 코딩과 "영어"라는 새 언어

1.1.1절의 "가장 각광받고 있는 언어는 자바도 파이썬도 아닌 '영어'가 되었다"는 젠슨 황의 인용은 다시 봐도 강한 문장이다. AI가 개발 분야의 주도권에 깊이 들어와 있고, 어느 시점부터는 특정 프로그래밍 언어 문법보다 AI를 잘 다루는 능력이 더 중요해질 수 있다는 점을 다시 한 번 체감했다.

적용 측면에서는 AI 트렌드를 쫓는 일이 더 이상 선택이 아니라는 결론이다. 매월 새로운 도구나 기능을 최소 하나 이상은 직접 적용해 보는 것을 개인 규칙으로 두고 있다.

프롬프트의 부상: 지시에서 설명으로

1.2.1절에서 다룬 프롬프트의 위상 변화도 인상적이었다. 좋은 프롬프트를 쓰는 일이 더 이상 부수적인 기술이 아니라 그 자체로 "업무 능력"이 되었고, 새로운 프로그래밍 소양으로 자리 잡고 있다는 관찰이다.

이 관점은 채용 단계에서도 의미가 있다. 어떤 후보가 AI 도구를 어느 정도 깊이로 다루는지, 프롬프트를 통해 의도를 얼마나 잘 풀어내는지를 참고 요건으로 가져갈 만하다.

의도 중심 프로그래밍, 채팅 지향 프로그래밍

이 두 용어는 그동안 막연하게 알고 있던 흐름에 이름표를 붙여 준 셈이다. 의도(Intent)를 코드 대신 자연어로 기술하고, 채팅 인터페이스를 1차 작업 환경으로 삼는 방식을 명확히 가리키는 표현으로 익혀 두고자 한다. 채용 단계에서 후보의 작업 스타일을 가늠할 때도 이런 용어를 공통어로 쓸 수 있을 것 같다.

AI 기반 툴 생태계와 MCP

1.4절의 새로운 생태계 정리에서는 MCP(Model Context Protocol) 같은 도구가 가장 눈에 들어왔다. AI가 직접 데이터베이스에 연결되어 컨텍스트를 가져오는 흐름은, 단순히 코드를 빨리 짜는 수준을 넘어 응답 품질 자체를 끌어올릴 수 있는 지점이라고 봤다.

다음 사이드 작업에서는 개발 환경 안에서 MCP 도구를 통해 DB를 연결해 보고, AI의 응답이 실제 컨텍스트에 얼마나 잘 들러붙는지 체감해 볼 계획이다.

모래성 코드와 제자리 걸음 패턴

3.1.1절의 "모래성 코드(sandcastle code)"와 "제자리 걸음(two steps back)" 패턴은 회의실에서 한 번 더 짚고 싶은 대목이다. AI에 100% 의존하다가 실제 환경에서 무너지는 모습, 그리고 코드를 충분히 이해하지 못한 채 두더지 잡기만 반복하는 모습은 주변에서도 종종 관찰된다.

이 표현들은 추상적인 잔소리 대신 구체적인 그림을 제공해 준다. 다음에 팀원과 일대일 면담을 할 때 자연스럽게 인용해서, "지금 우리가 만들고 있는 게 모래성 코드는 아닌가"라는 질문을 함께 던져 볼 생각이다.

시니어 개발자의 자리

4.1절은 시니어 개발자가 어떻게 정의되는지를 다시 정리해 준다. 개발 프로세스의 중심에서 전문성을 잃지 말고 계속 연마해야 한다는 메시지, 그리고 시니어가 되기 위해서는 그 위치를 받쳐 주는 중급 개발자 층이 반드시 필요하다는 관찰이 핵심이다.

이 부분은 별도의 적용 행동을 적어 두지는 않았다. 다만 개인 차원의 방향성으로는 충분히 묵직한 문장이라 그대로 가져가기로 했다.

보안, 신뢰성, 유지보수성

8장은 주니어 시기일수록 시야에서 잘 사라지는 영역을 모아둔 챕터다. 보안, 신뢰성, 유지보수성은 모두 기능 구현이 끝난 다음에야 비로소 문제가 드러나는 특성을 갖는다. 이 책을 함께 읽은 구성원들과 이 영역에 대한 공감대가 어느 정도 형성되었기를 기대한다.

적용 측면에서는, 이제 이 영역을 신경 쓰지 않은 결과물에 대해서는 좀 더 강하게 피드백을 주는 쪽으로 기준을 옮길 생각이다.

퍼실리테이션: 다섯 관점의 회고

감상 공유 — 별점과 그 이유

별점은 5점 만점에 2점이다. 박한 점수처럼 보일 수 있지만, 책 자체가 나쁘다는 의미는 아니다. 초판 발행이 2025년 11월인 책을 2026년 초에 읽었음에도 트렌드에서 크게 뒤처진 느낌이 들지 않았다는 점은 오히려 다행스러웠다. 다만 내 연차에서 보면 새롭게 알게 된 부분은 많지 않았고, 이미 알고 있던 내용을 한 번 더 정돈해 주는 복기에 가깝게 읽혔다는 점에서 점수를 그렇게 매겼다.

내용 점검 — 인상 깊었던 장면

가장 오래 기억에 남는 부분은 "프로그래밍 언어의 미래" 섹션, 그중에서도 자연어 중심 개발에 대한 논의였다. 지금 우리가 쓰는 고수준 언어를 대체하는 또 다른 윗 단계의 추상 레이어가 등장할 것이라는 전망인데, 멀리 있는 이야기 같지 않다는 점에서 기록해 둘 만한 대목이었다. 자연어와 코드 사이의 경계가 점점 더 흐릿해지는 흐름이 이미 시작되어 있다고 느꼈다.

가치 판단 — 저자 주장에 대한 반론

저자가 강조하는 바이브 코딩의 핵심 원칙 중 "인간이 작성했든 AI가 생성했든 모든 코드는 반드시 리뷰를 거친다"는 항목은, 원칙적으로는 동의하지만 현실에서 그 기준을 잡는 일이 쉽지 않다고 봤다. 책 전체에서 코드 리뷰에 드는 시간 비용 자체를 정면으로 다루는 부분이 거의 없다는 점도 아쉬웠다.

리뷰는 분명 필요한 활동이지만, 모든 코드에 동일한 강도를 적용하는 것은 트레이드오프 관점에서 비현실적이다. 핵심 경로(critical path), 보안 민감 코드, 데이터 일관성을 다루는 영역에 리뷰 자원을 우선 배치하고, 나머지는 가벼운 점검으로 가는 식의 차등 운영이 더 합리적이라고 생각한다.

문제 제기 — 우리 업무·조직에 적합한가

내가 담당하는 제품에 그대로 가져다 쓸 만한 강한 처방은 많지 않았다. 다만 일반적인 회사 업무, 특히 소프트웨어 개발 조직 전반에는 적용해 볼 여지가 충분히 있다. 책 전체를 단번에 읽히기보다는 단계별로 권하고 싶었다.

주니어 ~ 중급 레벨 개발자에게는 4장(시니어 개발자), 5장(생성된 코드를 이해하기), 8장(보안·신뢰성·유지보수성)을 우선 권하고 싶다. 이 세 챕터는 AI 도구를 쓰면서도 엔지니어링의 기본기를 잃지 않도록 잡아 주는 역할에 가까워서, 팀 단위 학습 자료로도 부담이 적다.

현실 적용 — 업무에 어떻게 적용할까

핵심 메시지는 "AI가 70%를 채울 때, 나머지 30%를 정확히 채우는 사람이 되자"로 요약된다. 팀 구성원이 그런 30%를 책임질 수 있도록 만드는 것이 한 축이고, 책에서 강조한 원칙들을 평소에 서로 되짚으며 작은 합의를 쌓아 가는 것이 다른 한 축이다.

구체적인 행동으로는, AI가 작성한 코드 중 영향 범위가 큰 변경에 대해서는 짧게라도 리뷰 시간을 별도로 잡는 패턴을 만들어 보려 한다. 모든 코드가 아니라 영향이 큰 코드부터, 그리고 의식적인 시간 블록으로 잡아 두는 것이 핵심이다.

마치며

자유 기재 항목에서는 책 114페이지의 "바이브 코딩 핵심 원칙 12가지" 중 내가 잘 지키지 못하는 항목을 솔직하게 적어 두었다. 첫째, "인간이 작성했든 AI가 생성했든 모든 코드는 반드시 리뷰를 거친다"는 원칙은 주요 사항 일부를 제외하면 기능 체크 수준에서 끝내고 있다는 점을 인정하게 됐다. 둘째, "이해하지 못하는 코드는 머지하지 않는다"는 원칙도, 가끔은 AI가 만들어 준 결과물을 충분히 소화하지 못한 채 머지로 밀어 넣은 경우가 있었다.

원칙은 외우기보다 붙잡고 있어야 의미가 있다. 이 두 항목은 다음 분기 동안 의식적으로 점검 대상에 올려 두기로 한다.