[바이브 엔지니어링] 길벗 챌린지 3주차 후기: AI에게 한 번에 다 시키면 왜 더 어려워질까

길벗 도서 챌린지 『바이브 엔지니어링』 3주차에는 7장 컨텍스트 전달의 기술부터 9장 컴퓨터 공학 기초가 필요한 순간까지 읽었습니다.
이번 범위는 AI에게 어떻게 지시할 것인가에서 시작해, 결국 내가 무엇을 알고 판단해야 하는가로 이어졌습니다.

태블릿으로 읽은 『바이브 엔지니어링』

정성을 들인다는 말의 뜻

AI에게 지시할 때는 정성을 들일수록 결과가 잘 나오는 것 같습니다. 여기서 말하는 정성은 기도가 아닙니다. 프로젝트 환경과 제한, 조건을 세세하게 생각해 프롬프트를 자세히 쓰는 일입니다. 단순히 "이런 기능을 만들어줘"라고 말하는 것보다 AI가 어디에서 어떤 기준으로 판단해야 하는지 알려주는 쪽에 가깝습니다.

책에서는 일반적인 프롬프트의 컨텍스트가 이해를 돕는 배경 설명이라면, AI와 개발할 때의 컨텍스트는 판단을 제한하는 조건 세트에 가깝다고 설명합니다. 프로젝트 전체 구조를 먼저 알려주고, 지금 작업할 위치와 요구사항, 지켜야 할 제약, 원하는 출력 기대치까지 차례로 범위를 좁혀갑니다. 정보를 많이 늘어놓는 것이 아니라 AI가 어느 기준부터 판단해야 하는지 순서를 설계하는 것입니다.

그렇다고 항상 많은 컨텍스트를 넣으면 되는 것은 아닙니다. 판단 순서가 고정되지 않는 작업도 있고, 도메인과 복잡도에 따라 필요한 깊이가 달라집니다. 컨텍스트가 아주 크거나 그 안의 정보가 틀렸다면 오히려 판단을 흐릴 수도 있습니다. 결국 자세하게 쓰는 것만큼 어떤 정보를 어떤 순서로 줄지 생각해야 합니다.

페르소나도 "너는 무슨 전문가야"라고 이름만 붙이는 것과는 달랐습니다. 지금 어떤 시선으로 판단할지 지정하는 도구이며, 구현·검증·운영 중 어떤 관점에서 무엇을 볼지 더 구체적으로 주는 것이 검증의 틀이 됩니다.

컨텍스트 전달의 기술을 다루는 7장

구현하는 사람과 의심하는 사람을 따로 두기

서로 다른 페르소나를 사용하면 혼자서도 페어 프로그래밍 효과를 얻을 수 있습니다. 먼저 구현 관점에서 만들고, 검증 관점에서 문제를 찾은 뒤, 발견한 내용을 선별해 다시 수정합니다. 필요하다면 검증과 수정을 반복합니다. 한 번에 구현과 의심을 모두 깊게 하려고 하기보다 관점을 나눠 맡기는 방식입니다.

이 과정을 모든 작업에 똑같이 적용할 필요는 없습니다. 복잡도와 중요도, 내가 얼마나 익숙한지를 보고 Full, Light, Skip 수준을 고릅니다. 관점을 분리하되 상황과 중요도에 맞게 검증 단계를 조절하는 것이 효율적이라는 생각이 들었습니다.

한 번에 다 해 달라는 유혹

8장을 읽으면서는 "와, 개발자로 일하기가 정말 쉽지 않겠구나"라는 생각이 먼저 들었습니다. 책 속 사례를 보면 이렇게까지 생각하고 요청했는데도 문제가 생깁니다. 처음 읽을 때는 복잡해 보였지만, 단계별로 놓고 보면 해야 할 일은 오히려 명확했습니다. 예시를 보며 직접 따라 해보면 몸에 익듯 체득될 수도 있겠다는 생각이 들었습니다.

방법은 컨텍스트를 단계적으로 전달하고, 요청을 작업 단위로 나누는 것입니다. 요구사항을 공유한 뒤 AI가 이해한 내용을 확인하고, HLD로 전체 구조와 범위를 맞춥니다. 그다음 LLD와 작업 분해를 거쳐 모듈별로 구현하고 검증·수정합니다. 어떻게 나눠야 할지 모르겠다면 분해하는 일부터 AI에게 물어볼 수도 있습니다.

모듈화와 단계적 지시를 다루는 8장

하지만 실제로는 "처음부터 끝까지 너가 알아서 다 해줘!"라고 말하고 싶은 유혹이 큽니다. 그렇게 시켜도 완벽할 리 없고, 그 과정에서 토큰은 계속 쓰이는데 결과물을 확인하기는 더 어려워집니다. 책에서 작업을 쪼개는 5분과 한 번에 시킨 뒤 디버깅에 걸릴 수 있는 5시간을 대비한 대목을 보며 전에 작업했던 과정들이 떠올랐습니다. 한 번에 시킨 작업은 점점 크기만 커지고, 문제가 생기면 어디서부터 바로잡아야 할지 막막했습니다. 이것이 초보 바이브코더가 처음 만나는 큰 장벽 중 하나가 아닐까 싶습니다.

인간의 판단을 묻는 3부 「생존의 조건」

돌아가는 코드와 "왜"를 설명하는 코드

9장은 프롬프트를 잘 쓰는 방법에서 컴퓨터 공학 기초로 방향을 돌립니다. 문서가 많아졌을 때 검색이 왜 느려지는지, 대화가 길어질수록 응답이 왜 늦어지는지, 여러 사람이 동시에 사용하면 왜 타임아웃이 생기는지 알려면 문제를 분류할 기준이 필요합니다. AI가 코드를 만들어주더라도 그 코드가 왜 느린지 판단할 기준까지 대신 생기지는 않습니다.

컴퓨터 공학 기초가 필요한 순간을 다루는 9장

AI가 만든 코드를 검증하고 제안을 이해하려면 시간·공간 복잡도, 메모리, 동시성, 네트워크, 데이터베이스 같은 기초가 필요합니다. 시스템 수준에서 생기는 문제를 발견하고 "왜 이렇게 만들었는가?"라는 질문에 답하기 위해서입니다. 다행히 지금은 모르는 내용을 바로 묻고 예시와 함께 배울 수 있는 AI라는 튜터도 있습니다. 컴퓨터 공학 기초를 더 효과적으로 공부할 수 있는 환경인 것은 맞는 것 같습니다.

읽으면서 주니어 때는 일단 돌아가는 코드를 만드는 데 집중해도, 시니어가 되면 "왜?"라는 질문에 답할 수 있어야 한다고 생각했습니다. 다른 부서나 QA에서 왜 이렇게 동작하는지 물었을 때 이유를 설명할 수 있어야 책임자가 될 수 있을 것 같습니다. 나는 어느 정도 대답할 수 있을까 생각해보면, 솔직히 아직 주니어도 안 된다고 생각합니다.

3주차를 마치며

아직도 한 번에 다 해달라고 말하고 싶은 마음은 큽니다. 하지만 프로젝트의 크기만 커지고 어디서부터 고쳐야 할지 몰랐던 경험을 떠올리면, 먼저 나누는 5분을 아끼는 것이 정말 빠른 방법인지는 의문입니다.

AI가 만든 코드가 돌아가는지만 보는 데서 멈추지 않고, 왜 이렇게 만들었는지 어느 정도 설명할 수 있을까. 그 질문 앞에서는 아직 자신 있게 대답하기 어렵습니다.