AI 코딩 도구를 쓰며 달라진 기획서 쓰는 법

 

요즘 기획서를 쓰다 보면 읽는 사람이 한 명 더 늘었다는 느낌이 듭니다.
개발자와 디자이너 말고, 코딩 도구 속에서 문서를 읽고 코드를 만들어주는 AI도 제 기획서의 독자가 된 거죠.

저는 개발자가 아니라서 직접 서비스를 만들 수는 없지만, 코딩 보조 도구를 가지고 작은 화면이나 동작을 만들어보는 일은 조금씩 해보고 있습니다.
그러다 보니 "내 기획서가 사람에게는 충분해 보여도 AI에게는 부족하구나" 하는 순간을 여러 번 만났어요.

이번 글은 그 경험을 바탕으로, 기획서를 쓰는 방식이 어떻게 달라지고 있는지 정리해본 기록입니다.
특정 도구의 세부 기능을 설명하는 글은 아니고, 문서를 쓰는 사람의 관점에서 정리했습니다.

 

사람 개발자는 기획서가 조금 모호해도 맥락을 읽어서 되묻거나 알아서 보완해줍니다.
"예약 취소는 가능한 시간까지만"이라고 적어도, 회의에서 "그 시간이 몇 시간 전이에요?" 하고 질문이 오가면서 채워지죠.

반면 AI에게 같은 문장을 주면 그럴듯한 값을 알아서 정해서 구현해버립니다.
예를 들어 제가 "취소 마감 시간은 정책에 따름"이라고만 적어두었더니, 임의로 24시간 전이라는 값을 넣은 코드가 나온 적이 있어요.
틀린 건 AI가 아니라 빈칸을 남긴 제 문서였습니다.

이 경험을 하고 나서 기획서를 "되묻기가 어려운 독자도 읽는 문서"라는 전제로 쓰게 되었습니다.
되묻지 못하는 독자에게는 질문의 답이 문서 안에 미리 들어 있어야 해요.

 

가장 크게 달라진 건 규칙을 판단 가능한 문장으로 쓰는 습관입니다.

예를 들어 예약 가능 시간을 설명하는 부분을 생각해보겠습니다.
예전에 쓰던 방식은 "영업시간 내에서 서비스 소요시간을 고려해 예약 가능"이었어요.
지금은 이렇게 풀어서 씁니다.

"예약 시작 시각은 영업 시작 시각 이상이어야 한다."
"예약 종료 시각은 영업 종료 시각 이하여야 한다. 종료 시각은 시작 시각에 서비스 소요시간과 정리 시간을 더해서 계산한다."
"이미 같은 직원의 다른 예약과 겹치는 구간이 있으면 선택할 수 없다."

문장이 길어지고 딱딱해지지만, 사람이 읽어도 오해가 줄고 AI가 읽어도 빈틈이 줄어요.
저는 "만약 ~라면 ~한다" 형태로 한 규칙에 한 조건만 담으려고 합니다.
조건이 여러 개일 때는 번호를 붙여서 나누는 편이 훨씬 안전했어요.

 

규칙만으로는 부족하고, 구체적인 예시가 꼭 같이 있어야 한다는 것도 배웠습니다.

가정 예시를 하나 들어보겠습니다.
어떤 가상의 미용실에서 커트가 40분, 영업 종료가 오후 7시, 정리 시간이 10분이라고 하겠습니다.
이때 마지막 예약 시작 가능 시각은 몇 시인지를 문서에 직접 적어둡니다.

"예: 영업 종료 19:00, 커트 40분, 정리 10분이라면 마지막 시작 시각은 18:10이다."

이렇게 계산된 예시가 있으면 AI가 만든 결과를 확인할 때 기준이 생깁니다.
코드가 18:30을 허용하고 있다면 곧바로 잘못을 알아챌 수 있죠.
사람이 검수할 때도 "예시와 맞는지"만 보면 되니까 속도가 빨라집니다.

예외 목록도 따로 만들어 둡니다.
임시 휴무일에 이미 잡힌 예약이 있을 때, 직원이 하루 중간에 자리를 비우는 경우, 서비스 시간이 중간에 바뀌는 경우처럼 헷갈릴 만한 상황을 표로까지 만들지는 않고 목록으로 적습니다.
각 항목 끝에 "이 경우 시스템은 무엇을 하는가"를 한 줄로 답해두는 게 핵심이에요.

 

또 달라진 점은 말이나 글로만 설명하지 않고 작은 프로토타입을 직접 만들어서 보여주는 일이 늘었다는 것입니다.

예를 들어 예약 화면의 시간 선택 영역을 설명할 때, 예전에는 화면 이미지에 말풍선을 달았습니다.
지금은 코딩 도구에 규칙을 알려주고 간단히 동작하는 화면을 만들어 본 다음, 그 화면을 가지고 개발자와 이야기합니다.

장점은 문서에서 드러나지 않던 빈틈이 바로 보인다는 점입니다.
"이 상황에서는 버튼이 어떻게 보여야 하죠?" 같은 질문을 제가 먼저 발견하게 돼요.
그 결과 회의에서 "그건 안 적혀 있어서요" 하는 말을 듣는 일이 줄었습니다.

다만 이 프로토타입은 어디까지나 대화를 돕는 도구입니다.
제가 만든 화면을 그대로 서비스 코드로 쓰자는 뜻이 아니고, 실제 구현은 개발자가 구조와 안정성을 따져서 결정해야 합니다.
이 경계를 흐리면 서로에게 부담이 되기 쉽다고 생각해요.

 

이렇게 쓰다 보니 조심할 점도 몇 가지 생겼습니다.

 

첫째, 문서가 길어진다고 좋은 문서가 되는 건 아닙니다.
규칙이 명확해야지, 양이 많아야 하는 게 아니에요.
같은 내용이 여러 군데 반복되면 나중에 수정할 때 서로 어긋나기 쉬워서, 한 규칙은 한 곳에만 적고 나머지는 거기를 가리키게 합니다.

둘째, AI가 만든 결과를 그대로 믿으면 안 됩니다.
그럴듯하게 동작하는 화면이어도 예외 상황에서는 틀릴 수 있으니, 제가 적어둔 예시를 직접 대입해서 확인합니다.

셋째, 민감한 정보는 문서에 넣지 않습니다.
실제 고객 정보나 운영 데이터를 도구에 붙여 넣는 일은 피하고, 가정한 데이터로 예시를 만들어요.

넷째, 문서의 최종 책임은 사람에게 있다는 점입니다.
AI가 읽기 좋게 만들어 주어도 정책의 옳고 그름은 운영하시는 분과 개발자와 함께 판단해야 합니다.

 

기획서가 AI에게도 읽힌다는 사실은 의외로 사람에게도 좋은 영향을 줬습니다.
모호함을 줄이는 습관이 결국 협업 전체의 질문 횟수를 줄여주었거든요.

남은 질문은 문서의 형태입니다.

지금은 줄글과 예시 중심으로 쓰고 있지만, 도구에 따라 더 잘 읽히는 형식이 따로 있을 수도 있어요.
앞으로는 문서를 쓰는 것과 동작하는 예제를 만드는 일의 경계가 더 옅어질 것 같은데, 그때 기획자의 역할이 어디까지 넓어지고 어디에서 멈춰야 하는지 계속 생각해보려고 합니다.