AI에게 코딩을 시킬 때 진짜 어려운 건 코딩이 아니었어요

화면 위에 초록색 글씨가 떠 있습니다. 작업을 마쳤고 검사도 통과했다는 문장이에요. 안심하고 버튼을 누릅니다.

그런데 버튼이 안 움직여요.

다시 물으면 AI는 곧바로 답합니다.

"코드는 정상적으로 연결돼 있어요. 브라우저를 새로고침해 보세요."

새로고침을 해도 같습니다. 조금 전까지 '완료'였던 일이 이제 '환경 문제'가 됐어요. 저는 코드가 잘못됐는지, 제가 버튼을 잘못 누른 건지, 설명을 믿고 다른 곳을 봐야 하는지 판단할 수가 없습니다. 화면은 그럴듯하고 문장은 자신만만한데, 손에 잡히는 증거가 없거든요.

AI와 무언가를 만들면서 제가 가장 오래 붙잡힌 장면은 복잡한 코드를 읽을 때가 아니었어요. 완료라는 말을 완료로 받아도 되는지 정할 때였습니다. 코드는 AI가 빠르게 만듭니다. 하지만 무엇이 맞는 결과인지, 어느 실패까지 막아야 하는지, 어떤 증거를 보고 끝낼지는 결국 일을 맡긴 사람이 정해야 해요. 이 판단마저 AI에게 통째로 넘기면 같은 자리를 빙빙 돌게 됩니다.

'만들어졌다'와 '쓸 수 있다' 사이

작은 예약 화면을 만든다고 해볼게요. 달력에서 날짜를 고르고 이름을 적은 뒤 저장을 누르면 끝나는 화면입니다. AI가 보여준 화면만 보면 충분해 보여요. 날짜 칸도 있고 저장 버튼도 있으니까요.

그런데 손님이 이름을 비워둔 채 저장하면 어떻게 될까요. 같은 시간을 두 사람이 고르면요. 저장한 뒤 화면을 닫았다가 다시 열었을 때 예약이 남아 있지 않으면요. 휴대전화에서는 버튼이 키보드 뒤에 가려질 수도 있고요.

이 질문들은 코드를 어떻게 짜느냐보다 먼저 옵니다. 질문이 없으면 AI는 보이는 길 하나를 완성하고 '끝'이라고 말해요. 거짓말을 해서가 아니라 제가 끝의 모양을 좁게 줬기 때문입니다.

그래서 저는 기능 이름 대신 통과 장면과 실패 장면을 같이 적어요.

"빈 이름으로는 저장되지 않아야 해요. 저장이 안 된 이유가 화면에 보여야 해요. 이미 찬 시간은 다시 고를 수 없어야 해요. 저장 뒤 화면을 다시 열어도 같은 예약이 보여야 해요."

이렇게 쓰면 어려운 개발 용어를 몰라도 검수할 수 있습니다. 어떤 부품을 썼는지 설명하는 대신, 손님이 무엇을 했을 때 무엇을 보게 되는지만 확인하면 되니까요. 기획서가 진짜 실력이 되는 이유도 이 차이에서 시작해요.

유창한 설명은 증거가 아닙니다

AI는 실패 뒤에도 설명을 잘합니다. "상태 동기화 과정에서 일시적인 문제가 생겼습니다"라는 문장을 보면 원인을 찾은 것 같아요. 하지만 그게 실제 원인인지, 가능한 원인 가운데 하나인지는 구분해야 합니다.

저도 한동안 설명이 길수록 조사도 깊게 했다고 믿었어요. 나중에는 답 아래에 증거를 따로 요구했습니다.

• 어느 파일의 어느 부분을 바꿨는지
• 바꾸기 전에는 어떻게 실패했고, 바꾼 뒤에는 무엇이 달라졌는지
• 직접 확인하지 못한 것은 무엇인지
• 제가 같은 결과를 다시 보려면 어디를 눌러야 하는지

이 네 질문에 답하지 못하면 '고쳤다'가 아니라 '고쳤을 가능성이 있다'로 남깁니다. 표현 하나를 낮추는 일처럼 보이지만 다음 행동은 완전히 달라져요. 앞의 것은 출시를 준비하게 만들고, 뒤의 것은 검수를 계속하게 만들거든요.

혼자 만들 때 무엇을 검증해야 하는지를 체크리스트로 적어둔 이유도 같습니다. 검사는 통과 여부를 꾸미는 의식이 아니라, 제가 다시 볼 수 있는 증거를 만드는 일이에요.

완료 기준은 기능 목록이 아니라 경계선입니다

"로그인 기능을 만들어 주세요"라고 하면 로그인 화면은 나옵니다. 그런데 비밀번호가 틀렸을 때의 문장, 연결이 끊겼을 때의 처리, 로그인한 사람이 남의 정보를 볼 수 없는지까지는 '로그인 기능'이라는 말 안에 자동으로 들어 있지 않아요.

완료 기준은 해야 할 일을 길게 쓰는 목록이 아닙니다. 여기까지 되면 내보내고, 이 선을 못 넘으면 멈춘다는 경계선이에요.

그래서 제가 먼저 적는 건 화려한 기능이 아니라 멈출 조건입니다.

"저장한 내용이 사라지면 멈춰요. 다른 사람의 내용이 보이면 멈춰요. 작은 화면에서 핵심 버튼이 안 보이면 멈춰요. 제가 직접 재현하지 못한 성공은 성공으로 세지 않아요."

이 문장들은 코드를 몰라도 쓸 수 있어요. 아니, 제품을 쓰는 사람의 자리에서만 쓸 수 있습니다. 무엇이 불편한지, 무엇이 위험한지, 무엇을 약속했는지는 코드를 만든 쪽보다 일을 맡긴 쪽이 더 잘 알아야 하니까요.

여기서 자주 갈리는 이야기들

"AI가 코드를 쓰면 비개발자는 아이디어만 내면 된다." 아이디어만으로 화면의 첫 모습까지는 갑니다. 그 뒤에는 선택이 계속 나와요. 저장이 느릴 때 기다리게 할지 다시 누르게 할지, 실패한 내용은 보관할지, 어느 상황을 위험으로 볼지. 이건 개발 지식만의 문제가 아니라 누구를 위한 제품인지와 무엇을 약속했는지의 문제입니다. AI가 선택지를 설명해 줄 수는 있어도, 손해를 감수할 쪽을 대신 정해주지는 못해요. 그렇다고 비개발자가 모든 코드를 배워야 한다는 뜻은 아닙니다. 저는 코드를 전부 읽기보다 사용자가 하는 행동과 그 뒤에 보여야 할 결과를 분명히 쓰는 쪽을 택했어요. 비개발자가 앱을 만들며 먼저 부딪히는 함정도 이 관점으로 보면 정리가 쉬워집니다.

"검사가 통과했으면 사람이 다시 볼 필요 없다." 검사는 정해진 질문에만 답합니다. 그 질문을 아무도 넣지 않았다면 통과해도 모르는 일이 그대로 남아요. 날짜 저장만 검사하고 작은 화면에서 버튼이 보이는지는 검사하지 않았다면, 초록색 통과 문구는 작은 화면에 대해 아무 말도 하지 않은 셈입니다. 반대로 사람이 몇 번 눌러봤으니 자동 검사가 필요 없다는 뜻도 아니에요. 사람이 보는 장면과 기계가 반복 확인하는 장면은 서로 빈틈을 메웁니다. 중요한 건 '통과'라는 단어가 아니라 무엇을 검사했는지예요.

"프롬프트를 아주 자세히 한 번 쓰면 수정 왕복이 사라진다." 자세한 지시는 도움이 됩니다. 하지만 만들기 전에는 보이지 않던 선택이 화면을 본 뒤에 생겨요. 버튼 이름이 어색할 수도 있고, 실제 자료를 넣으니 목록이 너무 길 수도 있고요. 처음부터 모든 장면을 맞히려는 문서는 쉽게 두꺼워지고, 정작 중요한 경계는 흐려집니다. 저는 한 번에 완벽한 지시를 쓰기보다 작은 결과를 보고 다음 판단을 붙여요. 다만 매번 기준을 바꾸지는 않습니다. 누구를 위한지, 무엇이 위험한지, 끝났다는 증거가 무엇인지는 처음부터 고정해요. 기능을 접고도 제품이 나아졌던 경험은 더 많이 만드는 것과 더 정확히 만드는 것이 다르다는 이야기입니다.

"모른다고 답하는 AI는 일을 못하는 AI다." 확신이 필요한 순간에 모른다는 답은 답답합니다. 그래서 사람도 AI도 빈칸을 그럴듯한 설명으로 채우고 싶어져요. 하지만 확인하지 못한 일을 확인했다고 말하는 것보다, 확인할 수 없는 경계를 남기는 편이 다음 행동을 정하기 쉽습니다. 물론 모른다는 말만 하고 멈추면 부족해요. 어디까지 확인했고, 무엇이 막혔고, 제가 어떤 화면을 보면 다음 판단을 할 수 있는지까지 나와야 합니다. 불확실성을 숨기지 않는 것과 책임을 피하는 것은 다른 일이에요.

제가 마지막에 직접 보는 장면

작업이 끝났다는 보고를 받으면 저는 설명부터 읽지 않습니다. 손님이 처음 들어오는 자리로 돌아가요. 빈 화면에서 시작하고, 일부러 잘못 입력하고, 중간에 창을 닫고, 다시 들어옵니다. 성공 길만 밟으면 성공 화면만 보이니까요.

그다음 보고와 화면을 맞춥니다. "오류 문구를 보여준다"고 했는데 실제 문구가 없으면 보고가 틀린 거예요. "저장된다"고 했는데 새로 열었을 때 사라지면 구현이 틀린 거고요. 둘을 분리해야 다시 시킬 문장도 정확해집니다.

그러다 보니 제가 묻는 말이 단순해졌어요.

"당신이 한 일을 설명하지 말고, 제가 확인할 수 있는 결과를 보여주세요. 확인하지 못한 것은 따로 적어주세요."

AI에게 맡기지 않는 편이 나은 일은 AI를 덜 쓰자는 글이 아닙니다. 판단을 맡겼다는 사실조차 잊어버리는 순간을 막자는 글이에요. 직접 도구를 만들 때 주인이 해야 하는 일도 같은 경계에 있습니다.

AI에게 코딩을 시키는 일의 어려움은 명령어를 잘 쓰는 데 있지 않아요. 완료라는 말을 관찰 가능한 장면으로 바꾸는 일에 있습니다. 화면이 나왔을 때 끝났다고 믿는 대신, 실패시켜 보고도 약속이 남는지 확인하는 것. 저는 그걸 하고 나서야 '완료'라고 말합니다.

완료 보고를 받았을 때 대화를 한 번 더 줄여요

예전에는 오류가 나면 대화 전체를 복사해 다시 물었어요. AI는 앞의 설명을 이어 받아 또 긴 원인 목록을 줬고, 저는 어느 것부터 확인할지 몰랐습니다. 지금은 보고를 작은 표처럼 나눠달라고 해요. 바꾼 것, 직접 확인한 것, 확인하지 못한 것, 제가 해야 할 것만 남깁니다.

"저장 버튼의 동작을 바꿨어요. 빈 이름이 막히는 장면과 정상 저장은 직접 확인했어요. 창을 닫았다 다시 여는 장면은 확인하지 못했어요. 그 장면은 직접 눌러봐 주세요."

이런 보고라면 성공을 통째로 믿거나 통째로 의심하지 않아도 됩니다. 확인된 부분은 통과시키고 남은 장면만 봐요. 문제가 나오면 "전부 다시 해"가 아니라 "다시 열었을 때 사라진다"라고 좁혀 말할 수 있고요.

반대로 "모든 기능이 정상입니다"라는 보고만 왔다면 그건 완료가 아니라 질문이 남은 상태예요. 무엇을 직접 봤는지가 없으니까요. 내가 다시 만든다면 다르게 할 일도 기능 선택보다 이런 검수 왕복을 일찍 설계하는 데 가깝습니다.

마지막으로, 저는 고친 사람이 제시한 화면만 보지 않아요. 빈 상태에서 제가 다시 시작합니다. 준비된 자료와 로그인 상태는 문제를 가리거든요. 새로 온 손님의 자리에서 같은 결과가 나오는지 봐야 '제 컴퓨터에서는 됐다'는 완료를 벗어날 수 있어요.

자주 묻는 질문

코드를 모르는데 잘못된 결과를 어떻게 찾나요?

코드 대신 행동을 정해 보세요. 빈칸으로 저장하기, 같은 버튼을 다시 누르기, 창을 닫았다 열기, 작은 화면에서 보기처럼 손님이 할 법한 행동을 적어요. 기대한 결과와 실제 결과가 다르면 개발 용어를 몰라도 문제를 보여줄 수 있습니다.

AI가 완료했다고 하면 무엇부터 요청해야 하나요?

바뀐 위치, 직접 확인한 방법, 남은 미확인 항목을 요청해요. 설명 영상이나 화면도 도움이 되지만, 다른 사람이 같은 순서를 따라 했을 때 같은 결과가 나오는지가 더 중요합니다. 요청해도 답이 부실하면 같은 요청을 다른 표현으로 반복하기보다, 화면 하나만 좁혀 다시 확인해 달라고 범위를 줄이는 편이 답을 받기 쉬워요.

모든 기능에 긴 완료 기준을 써야 하나요?

아니에요. 잃으면 큰 것부터 씁니다. 정보가 사라지는 경우, 다른 사람에게 보이는 경우, 결제가 엉키는 경우, 핵심 행동을 끝내지 못하는 경우예요. 작은 문구 차이는 결과를 보며 조정해도 됩니다.

수정이 계속되면 기획이 실패한 건가요?

수정 자체는 실패가 아니에요. 실제 화면을 보고 더 나은 선택을 하는 과정일 수 있습니다. 다만 같은 문제를 기준 없이 되풀이한다면 비개발자가 만든 앱이 흔들리는 이유처럼 완료 기준부터 다시 잡아야 해요.