길벗 도서 챌린지 『바이브 엔지니어링』 4주차에는 9장 후반부터 11장까지 읽었습니다.
이번 범위를 끝으로 책도 모두 읽었습니다. 컴퓨터 공학 기초, 테스트 코드, 도메인 지식이라는 세 가지 주제는 결국 하나의 질문으로 이어졌습니다. AI가 만든 결과를 보고 맞고 틀림을 판단하려면 나는 무엇을 알고 있어야 할까?
4주차까지 읽고 완독한 『바이브 엔지니어링』
"몰라, 해줘"로 계속 갈 수는 없다
9장 후반은 컴퓨터 공학 기초를 AI와 함께 배우고, 실제 문제가 생겼을 때 무엇부터 의심해야 하는지 다룹니다. 성능이 떨어지면 시간 복잡도, 시간이 지날수록 느려지면 메모리, 동시 요청에서 문제가 생기면 동시성, API 응답이 느리면 네트워크, 데이터가 많아지며 느려지면 데이터베이스를 살펴보는 식입니다. 문제를 해결하기 전에 먼저 어느 영역의 문제인지 분류할 기준이 필요하다는 내용입니다.
컴퓨터 공학 기초와 판단 기준을 다루는 9장
이 부분을 읽으며 컴퓨터 공학의 중요성을 더 느꼈습니다. 결국 내가 대략적으로라도 알고 있어야 AI와 대화할 수 있기 때문입니다. 언제까지고 아무것도 모르는 것처럼 "몰라, 해줘"라고만 할 수는 없습니다. AI가 답을 만들어도 질문할 단어와 결과를 의심할 기준까지 저절로 생기지는 않습니다.
모르는 개념을 그때그때 얕게라도 짚고, AI와 함께 학습하며 조금씩 아는 범위를 늘려가야 더 안정적이고 정확하게 코딩할 수 있을 것 같습니다.
체크리스트와 개발자의 감각
10장은 테스트 코드를 AI에게 주는 실행 가능한 명세로 설명합니다. "이렇게 동작해야 해"를 테스트로 먼저 정의하면 AI도 그 기준을 만족하는 코드를 만들 수 있습니다. 정상 케이스뿐 아니라 잘못된 입력과 데이터 없음 같은 예외 케이스, 빈 값·최솟값·최댓값 같은 경계 케이스도 함께 확인해야 합니다.
좋은 테스트에는 독립성, 반복 가능성, 빠른 실행 속도, 명확한 실패 메시지가 필요합니다. 하지만 AI는 정상 케이스에 치우치고 도메인 맥락을 놓치거나, 자신이 만든 구현을 따라 테스트를 작성할 수 있습니다. AI가 만든 테스트도 그대로 믿으면 안 됩니다. 기댓값이 정말 맞는지 다시 계산하고, 일부러 버그를 넣었을 때 실패하는지도 봐야 합니다.
테스트 코드 작성과 검토 체크리스트를 다루는 10장
처음에는 책의 체크리스트를 모두 메모해 두고, 하나씩 보며 확인하면 되지 않을까 생각했습니다. 물론 아무것도 확인하지 않는 것보다 훨씬 낫습니다. 그런데 내 생각에 그것은 50점 정도입니다.
개발자의 역량은 항목을 그대로 따라가는 데서 한 단계 더 나아가는 것 같습니다. 테스트 코드나 구현을 보다가 위화감을 느끼고, "여기서 이런 걸 더 하면 좋겠는데?", "뭘 더 해야 할 것 같은데?"라는 생각을 꺼낼 수 있어야 합니다. 그 느낌을 계기로 자료를 찾아보고, 빠진 검증을 더해보는 감각도 개발자의 역량이라고 생각합니다.
내가 떠올린 비유로는 책을 옆에 펼쳐 놓고 항목을 하나씩 확인하는 단계가 자료에 의지해 꼼꼼히 진행하는 대학원생과 비슷하다면, 프로는 코드를 유심히 보다가 필요한 것을 생각해내는 사람에 가깝습니다. 아니, 이러면 개발자의 능력이 더 중요해지는 것이 아닌가 싶습니다. 이런 측면에서 신입 개발자보다 능력 있는 시니어 개발자 채용 쪽으로 쏠리는 것이 당연한 것 같습니다.
AI가 모르는 회사 안의 규칙
11장은 도메인 지식을 업계 지식과 조직 맥락으로 나눕니다. 업계 전반에서 통용되는 지식은 AI도 알고 책이나 강의로 배울 수 있습니다. 반면 과거 의사결정의 이유, 부서 간 협의 사항, 회사만의 예외 케이스, 담당자만 아는 노하우와 비공식 소통 방식은 그 조직에서 일한 사람만 알 수 있습니다. 기술적으로 완벽해 보이는 기능도 이 맥락을 놓치면 결과가 틀릴 수 있습니다.
업계 지식과 조직 맥락을 다루는 11장
AI가 도메인 지식을 대신 쌓아줄 수는 없지만, 사람이 알고 있는 맥락을 전달하거나 정리하는 데 AI를 활용할 수 있습니다.
책에서는 주니어에게 질문하고 기록하라고 하고, 시니어에게는 문서화하고 전수하라고 합니다. 나는 이것이 조직 안에서 주니어와 시니어가 나눠 가진 암묵적인 책임이라고 생각합니다. 이 두 가지가 되지 않는 조직에는 발전이 없다고 느꼈습니다. 앞서 있었던 조직에서도 이런 경우 발전 가능성이 현저하게 떨어졌습니다. 구성원의 역량이 어떻든 이런 책임에만 충실하다면 어떻게든 나아갈 수 있지 않을까 생각합니다.
4주차와 완독을 마치며
책의 마지막 내용을 묶어보면 컴퓨터 공학 기초는 AI의 코드를 이해하고 문제의 가설을 세우는 "판단하는 눈"이고, 테스트 코드는 의심을 코드로 증명하는 "검증을 위한 방패"이며, 도메인 지식은 기술적으로 맞는 결과가 실제 업무에도 맞는지 재는 "맥락의 저울"입니다. AI가 코드를 만들더라도 시스템을 완성하는 판단은 사람에게 남습니다.
처음에는 내용이 다소 자세하고 어렵다고 생각했습니다. 하지만 읽을수록 내용이 더 잘 정리됐고, 개발자 사수에게 친절하게 배우는 듯한 느낌도 들었습니다. 정말 주니어로 들어가 하나씩 배우는 기분이었습니다.
『바이브 엔지니어링』은 바이브코딩 개발자에게 필수적인 지침서가 아닐까 생각합니다. 다시 한번 읽어보면 좋을 책으로 꼽아봅니다.
Comments
댓글
익명으로 바로 남길 수 있습니다. IP는 일부만 표시됩니다.
댓글을 불러오는 중입니다.