AI가 만든 결과를 내가 이해하고 있다고 말하려면, 기획자의 확인 기준

 

AI로 목업을 만들고, 스팩브릿지를 만들고, 예약 시스템의 정책 문서를 쓰는 것이 요즘 제 일과의 대부분이에요.
결과물이 나오는 속도는 예전과 비교가 되지 않습니다.
그런데 결과물이 쌓일수록 같은 질문이 따라와요.
"이걸 내가 정말 이해하고 있나."

화면이 그럴듯하게 나오면 이해한 것 같은 기분이 듭니다.
정책 문서가 매끄럽게 정리되면 빠진 게 없다고 느끼기도 쉬워요.
하지만 기분과 이해는 다르다는 걸, 설명 없는 목업 때문에 개발자와 소통이 막혔던 경험에서 한 번 배웠습니다.
화면만 보면 다 정해진 것 같은데, 정작 정책은 제 머릿속에만 있었거든요.

그러던 차에 GeekNews에서 제목부터 이 고민과 닮은 글을 봤습니다.
오늘은 그 토론을 짧게 훑고, 코드를 읽지 못하는 기획자가 무엇을 근거로 "이해했다"고 말할 수 있을지 제 일에 비추어 정리해 보려고 해요.

 

10월 20일 GeekNews에 Hacker News의 Ask 글이 소개됐습니다.
AI가 작성한 코드를 이해하지 못한 채 배포하는 문제에 다들 어떻게 대처하느냐는 질문이었어요.
질문자는 빠르게 배포하다 보니 코드를 한 줄씩 검토하기 어렵고, 결국 유지보수까지 AI에 기대게 될까 걱정했습니다.
답변에는 설계서를 승인한 뒤에만 코드를 바꾸는 방식, 구현과 검사를 서로 다른 에이전트가 맡는 방식, 위험도에 따라 사람이 볼 구간을 나누는 방식이 나왔어요.
댓글은 일곱 개였는데, 설계에 참여했다면 충분하다는 쪽과 운영 배포 전에는 코드를 읽어야 한다는 쪽으로 갈렸습니다.
저는 앞쪽을 만들기 전의 이해, 뒤쪽을 문제가 터진 뒤의 이해로 읽었어요.

 

저는 코드를 완벽히 읽지 못합니다.
줄 단위 검토는 처음부터 선택지가 아니에요.
그래서 "내가 확인할 수 있는 것"을 따로 정해야 한다고 생각했고, 지금은 세 가지를 떠올리고 있습니다.

첫째는 정책 문서예요.
무엇이 맞는 동작인지를 문장으로 적어 둔 문서입니다.
AI가 코드를 쏟아내기 전에 이 문서를 사람이 먼저 승인해야 한다고 봐요.
토론에서 설계서를 승인한 뒤에만 코드를 바꾼다는 답변이 눈에 들어온 것도 그래서입니다.

둘째는 예외 목록입니다.
정상 흐름은 AI도 사람도 비슷하게 그려요.
차이가 나는 곳은 늘 예외입니다.
예약 시스템으로 가정해 보면, 결제 도중 창을 닫았을 때나 확정된 예약을 취소할 때 환불이 어디까지인지 같은 질문이 그렇습니다.
이런 상황을 목록으로 적어 두면 AI의 결과물이 각 항목을 어떻게 처리했는지 하나씩 물어볼 수 있어요.

셋째는 완료 기준, 즉 테스트 시나리오입니다.
"이 상황에서 이렇게 되면 완료"를 문장으로 적어 두는 거예요.
코드를 못 읽어도 시나리오대로 동작하는지는 확인할 수 있습니다.

다만 반대편 댓글처럼 테스트 자체가 틀릴 수 있으니, 시나리오는 정상보다 예외를 더 많이 적으려고 합니다.

 

모든 곳을 똑같이 꼼꼼히 확인할 수는 없어요.
그래서 기획서에 "여기는 사람이 반드시 확인한다"는 구간을 미리 적어 두는 방식을 생각하고 있습니다.
테넌트 구조의 예약 시스템을 기획해 온 경험을 바탕으로 가정해 보면, 이런 표가 될 것 같아요.

• 결제: 금액 계산, 승인과 실패 처리는 사람이 끝까지 확인합니다.
• 취소: 환불 범위와 수수료 규칙은 사람이 확인합니다.
• 권한: 테넌트끼리 데이터가 섞이지 않는지, 누가 무엇을 볼 수 있는지는 사람이 확인합니다.
• 화면 문구: AI에 맡기고 톤만 훑어봅니다.
• 화면 배치: AI에 맡기되 정책이 적힌 내용과 어긋나지 않는지만 봅니다.

기준은 단순합니다.
되돌리기 어렵거나, 돈과 권한이 움직이거나, 한 번 틀리면 다른 사용자에게까지 번지는 곳은 사람이 봅니다.
되돌리기 쉽고 영향이 작은 곳은 AI에 맡깁니다.
이 구분을 문서에 적어 두면 AI에게 일을 맡길 때도, 개발자와 이야기할 때도 "이건 어디까지 확인된 건가"를 말하기가 쉬워져요.

 

설명 없는 목업의 문제는 화면만 있고 그 아래의 정책, 데이터, API가 보이지 않는다는 점이었어요.
개발자는 화면을 보고 각자 해석했고, 저는 해석이 달랐다는 걸 나중에야 알았습니다.
스팩브릿지는 그 틈을 줄이려고 2026년 2월에 시작한 프로젝트예요.
화면 위에 정책, 데이터, API 스펙을 연결해서 같은 화면을 보며 같은 설명을 읽게 하자는 협업 도구입니다.
탭 처리가 아직 어려워서 Figma를 병행하고 있고, 개발은 계속 진행 중이에요.
곧 GitHub에 공개할 예정입니다.

이번 토론을 읽고 나니 이 연결이 사람과 사람 사이에서만이 아니라 AI와 사람 사이에서도 같은 역할을 할 수 있겠다는 생각이 들었어요.
설명 없는 화면을 AI에 주면 그럴듯하지만 의도와 다른 결과가 나올 수 있으니까요.
화면에 정책이 붙어 있으면 "이 화면이 맞는지"를 문서를 뒤적이지 않고 화면 위에서 확인할 수 있습니다.
위험도 구간도 화면 단위로 표시할 수 있다면 어디를 사람이 봐야 하는지 한눈에 보일 것 같아요.
아직은 제 바람에 가까운 생각이라, 실제로 만들며 확인해 보려고 합니다.

 

앞으로 AI가 만든 결과를 받을 때마다 아래 다섯 가지를 확인하기로 했어요.

1. 정책 문서를 구현 전에 제가 먼저 읽고 승인했는가.
2. 예외 목록이 정상 흐름만큼, 가능하면 더 많이 적혀 있는가.
3. 완료 기준이 시나리오 문장으로 적혀 있는가.
4. 결제, 취소, 권한처럼 사람이 반드시 볼 구간이 기획서에 표시되어 있는가.
5. AI가 만든 결과를 제 말로 다시 설명할 수 있는가.

마지막 항목이 가장 중요하다고 생각해요.
제 말로 설명하지 못한다면 아직 이해한 게 아니라는 뜻이니까요.

 

풀리지 않은 질문도 남아 있습니다.

정책 문서와 테스트 시나리오를 잘 써 두면 이해를 얼마나 대신할 수 있을까요.
운영 배포 전에 코드를 읽어야 한다는 의견에, 기획자는 어떤 방식으로 기여할 수 있을까요.
위험도 구간을 제가 잘못 나누면, 그 잘못을 알아차릴 사람은 누구일까요.

답은 아직 모르겠습니다.
다만 코드를 읽지 못한다는 사실이 확인을 포기해도 된다는 뜻은 아니라는 점은 분명해졌어요.
제가 읽을 수 있는 문서에서 먼저 기준을 세우는 일부터 해 보려고 합니다.