AI 코딩 요구서 쪼개는 법, 설명보다 먼저 할 일

3줄 요약

• AI 코딩 도구는 복잡한 요구사항을 한 번에 받으면 끝까지 정확히 기억하지 못하므로, 가장 작은 뼈대부터 쪼개 넘기는 쪽이 안전합니다.
• 한 단계의 구현이 끝날 때마다 요구서와 결과물을 대조해 완료된 것과 안 된 것을 별도 파일로 남기면 다음 단계에서 빠진 기능을 놓치지 않습니다.
• 그 요구서 파일만 남아 있으면 지금 만든 결과물을 버리고 다른 도구로 옮겨도 비슷한 수준까지 다시 만들 수 있습니다.

롱폼 촬영본을 자산으로 쌓아온 마케팅 실무자나 크리에이터 중에는 AI 코딩 도구로 랜딩페이지나 신청서, 간단한 업무 도구를 직접 만들어보는 경우가 늘고 있습니다. 이때 자주 걸리는 지점은 코드 자체가 아니라 요구사항을 넘기는 방식입니다. 자세히, 빠짐없이 한 번에 적어 넘길수록 안전하다고 여기기 쉽지만, 실제로는 분명히 적어 둔 기능이 빠지거나 고쳐 달라고 한 부분과 다른 곳이 바뀌는 일이 반복됩니다.

이 문제는 설명을 더 길게, 더 정성껏 쓴다고 풀리지 않습니다. ENLIT은 촬영본에서 쓸 구간을 고를 때도 기준을 통째로 던지는 대신 작은 단위로 쪼개 확인하는 쪽이 결과를 안정적으로 만든다고 봅니다. AI 코딩에서도 같은 원리가 적용됩니다. 필요한 것은 더 긴 문장이 아니라 요구사항을 나누는 순서입니다.

AI 코딩 도구가 요구사항을 자꾸 놓치는 이유는 무엇인가요?

AI 코딩 도구가 복잡한 요구사항을 자꾸 놓치는 이유는 문서 하나로 통째로 받은 내용을 끝까지 정확히 기억하지 못하기 때문입니다. 작업이 길어질수록 앞서 적어 둔 조건을 놓치거나 다른 기능과 뒤섞어 버리는 일이 늘어납니다. Anthropic은 복잡한 작업을 한 번에 요청하는 대신 일련의 단계로 나눠 처리하고 중간 단계마다 점검하는 프롬프트 체이닝 방식을 권장합니다(Anthropic Engineering, "Building Effective Agents"). 요구서를 처음부터 작게 쪼개 넘기는 쪽이 안전한 이유도 같은 원리에서 나옵니다.

쪼개야 하는 이유는 두 가지입니다. 하나는 AI가 한 번에 복잡한 작업을 처리하는 데 약하다는 것이고, 다른 하나는 너무 큰 결과물을 한 번에 받으면 만든 사람이 그것을 직접 확인할 방법이 없다는 것입니다. 결과물을 직접 테스트할 수 있는 크기로 나누는 것이 쪼개는 기준입니다.

요구서를 길게 쓰는 것보다, 처음부터 작은 단위로 나눠 넘기는 쪽이 결과를 훨씬 안정적으로 만듭니다. 콘텐츠 기획서를 한 번에 몰아 적는 대신 장면 단위로 끊어 확인받는 것도 같은 이유에서 작동합니다.

요구서는 몇 단계로 나눠야 하나요?

흔히 적용되는 기준은 세 단계입니다. 가장 작은 뼈대인 1단계를 먼저 구현해 돌려 보고, 통과하면 2단계와 3단계를 이어 붙이는 순서입니다. 1단계만 통과하면 나머지는 그 위에 쌓는 작업이라 범위가 좁아집니다.

다만 숫자 3이 절대적인 기준은 아니죠. 복잡도가 낮은 작업이라면 한 단계로 끝내도 되고, 복잡도가 높다면 더 쪼개도 됩니다. 중요한 건 그 결과물을 직접 테스트할 수 있는 크기인지입니다.

쪼갤 때 확인할 것은 이렇게 정리할 수 있습니다.

• 이 단계만 떼어 내도 돌려서 확인할 수 있는지
• 다음 단계가 이번 단계 위에 자연스럽게 얹히는지
• 복잡도가 낮다면 억지로 세 단계를 만들지 않아도 되는지

뼈대가 통과하지 않은 상태에서 다음 단계를 얹으면, 어디서 문제가 생겼는지 가늠하기 어려워집니다. 그래서 1단계 통과를 다음 단계로 넘어가는 조건으로 두는 것이 안전합니다.

작업을 어디까지 AI에게 맡기고 어디서 사람이 확인할지 미리 나누는 방식은 작업을 세 칸으로 나누는 법과 같은 원리입니다. 숏폼을 시리즈로 나눠 먼저 한 편을 완성해 반응을 본 뒤 다음 편을 잇는 것도 같은 구조입니다.

단계를 나눈 뒤 AI에게 꼭 시켜야 할 일은 무엇인가요?

단계를 나눈 뒤에는 한 단계의 구현이 끝날 때마다 처음 준 요구서와 실제로 구현된 내용을 비교해 완료된 것과 완료되지 않은 것을 별도 파일로 정리해 달라고 시켜야 합니다. 요구서와 할 일 목록을 서로 다른 파일 두 개로 남기면 빠진 기능을 놓치지 않습니다.

구체적으로는 처음 준 요구서와 지금까지 구현된 내용을 비교해 완료된 것과 완료되지 않은 것을 TODOS.md 같은 파일로 저장해 달라고 요청하고, 요구서 자체도 별도 md 파일로 남겨 달라고 요청하면 됩니다. 이 요청 한 줄이 기억을 AI의 대화창이 아니라 파일 밖으로 꺼내 두는 장치입니다.

할 일 관리를 맡기는 대상은 AI지만, 그렇게 관리하라고 지시하는 건 결국 사람의 몫입니다. 작업이 복잡할수록 이 과정을 거치는 편이 안전하고, 간단한 프로토타입 단계에서는 생략해도 무리가 없습니다. 이 파일을 만들지 않으면, 몇 번째 수정 요청부터 어떤 기능이 사라졌는지 되짚기 어려워집니다.

콘텐츠 기획서도 같은 방식으로 다룰 수 있습니다. 완료된 장면과 남은 장면을 별도 목록으로 남겨 두면 담당자가 바뀌어도 기준이 흔들리지 않습니다.

자동 수정이 안 되는 오류는 어떻게 대응하나요?

자동 수정이 안 되는 오류는 발생 화면을 캡처해 AI에게 함께 넘기는 방식으로 대응합니다. 자동 수정 기능이 오류를 알아서 고쳐 주기도 하지만 모든 오류를 해결해 주지는 않습니다. 오류 메시지가 화면에 뜨면 AI가 그 문구를 근거로 더 정확히 고치지만, 아무 메시지도 뜨지 않는 증상은 AI가 고쳐야 할 일이라는 사실 자체를 모르고 지나가는 경우도 있습니다.

오류 문구를 그대로 옮기는 대신 화면을 캡처해 넘기는 방법은 오류를 세 줄로 정리해 보내는 방법과 같은 자리에서 쓰입니다. 캡처는 오류가 난 화면과 함께 바로 전 단계에서 어떤 동작을 했는지도 담아야 AI가 원인을 좁힐 수 있습니다. 설명만 길게 쓰는 것보다 효과적입니다.

고치다가 막히면, 지금까지 만든 결과물 자체를 버려도 괜찮습니다. 요구서 파일만 남아 있으면 다른 도구에서도 비슷한 수준으로 다시 만들 수 있기 때문입니다. 결과물에 들인 시간이 아까워서 억지로 고치는 것보다, 요구서를 들고 처음부터 다시 시작하는 쪽이 더 빠를 때가 있습니다.

결과물이 아니라 요구서를 자산으로 남기면, 지금 만든 걸 버려도 처음부터 다시 쓰지 않아도 됩니다.

도구는 어떤 순서로 옮겨 가야 하나요?

도구는 저렴하거나 무료로 시작할 수 있는 프로토타이핑 환경에서 먼저 시행착오를 겪고, 그 결과로 다듬어진 요구서를 들고 실제로 쓸 결과물을 만드는 도구로 옮기는 순서가 비용을 아낍니다. 복잡한 기능을 붙여 서비스로 운영할 단계가 되면 더 본격적인 도구나 개발자와의 협업으로 넘어갑니다.

도구별 무료 제공 범위나 메시지 제한은 시기에 따라 자주 바뀝니다. '무료'라는 말 자체를 약속으로 받아들이기보다, 저렴한 환경에서 먼저 틀리고 비싼 환경으로 옮긴다는 순서만 가져가는 편이 안전합니다.

데이터베이스를 붙이는 기준도 간단합니다. 접속한 사람마다 다른 내용을 보여줘야 하거나 데이터가 계속 쌓이고 누적돼야 할 때 필요합니다. 랜딩페이지처럼 일방적으로 전달만 하는 화면이라면 아직 필요하지 않을 수 있습니다.

다만 이 순서와 별개로, 목적만 말하고 구현 방법은 비워 두는 편이 나을 때도 있습니다. 이건 결과를 평가할 기준이 이미 있는 사람에게 유리한 방식이고, 평가 기준이 없는 상태에서 비워 두면 빠진 것을 알아채지 못하죠. 그래서 요구서와 대조하는 틀을 먼저 갖춘 다음에 써야 하는 조언입니다.

도구를 열 때마다 뭘 시킬지 막막하다면 고정해두는 세 가지 요청처럼 반복되는 요청부터 문서로 고정해 두는 방법도 함께 쓸 수 있습니다.

한눈에 비교

오늘 바로 적용한다면

• 다음 AI 코딩 작업은 가장 작은 뼈대인 1단계부터 쪼개 요청합니다
• 1단계가 통과하면 2단계, 3단계로 범위를 넓혀 요청합니다
• 단계가 끝나면 요구서와 결과물을 비교해 완료·미완료를 TODOS 파일로 남깁니다
• 자동 수정이 안 되는 오류는 발생 화면을 캡처해 함께 넘깁니다
• 저렴한 프로토타이핑 환경에서 요구서를 다듬은 뒤 실제 제작 도구로 옮깁니다

자주 묻는 질문

요구서를 몇 단계로 나누는 게 적당한가요?

복잡도가 낮거나 보통 수준인 작업이라면 세 단계로 충분합니다. 가장 작은 뼈대를 1단계로 먼저 통과시키고, 2단계와 3단계를 그 위에 얹는 방식이 일반적입니다. 다만 복잡도가 낮으면 한 단계로 끝내도 되고 복잡도가 높으면 더 쪼개도 되며, 기준은 그 결과물을 직접 테스트할 수 있는 크기인지입니다.

완료 여부를 왜 별도 파일로 남겨야 하나요?

AI와의 대화만으로는 무엇이 끝났고 무엇이 남았는지가 금방 흐려지기 때문입니다. 처음 준 요구서와 실제 구현 내용을 비교해 완료된 것과 안 된 것을 TODOS 같은 파일로 저장해 두면, 다음 단계로 넘어갈 때 빠진 기능을 바로 확인할 수 있습니다. 요구서도 별도 파일로 함께 남겨 두면 그 기준 자체가 흔들리지 않습니다.

만든 결과물이 잘 안 되면 어떻게 하나요?

결과물 자체는 버려도 괜찮습니다. 요구서 파일만 남아 있으면 다른 도구로 옮겨서도 비슷한 수준까지 다시 만들 수 있기 때문입니다. 들인 시간이 아까워 억지로 고치는 것보다, 요구서를 들고 처음부터 다시 시작하는 쪽이 더 빠를 때가 있습니다.