AI는 왜 10개 시키면 7개만 할까? | 긴 프롬프트에서 지시사항이 빠지는 이유

AI가 내게 해준 얘기들 #02

AI는 왜 10개 시키면 7개만 할까?

긴 프롬프트와 작업지시에서 요구사항이 빠지는 이유

AI를 이용해서 실제 일을 하다 보면 어느 순간 아주 이상한 경험을 하게 된다.

나는 분명히 10가지를 시켰다.

하나도 아니고, 두 개도 아니고, 번호까지 붙여서 아주 친절하게 10개를 적었다.

그리고 AI는 말한다.

“완료했습니다.”

그래서 결과물을 열어본다.

하나. 둘. 셋. 넷.

…

일곱.

끝.

8번, 9번, 10번은 어디 갔는지 없다.

처음에는 내가 뭘 잘못 썼나 싶었다.

그런데 이런 일이 한두 번이 아니었다.

그리고 얼마 전에는 더 웃긴 일이 있었다.

내가 AI에게 분명히 이렇게 말했다.

“블로그 글 1편을 써주고, 사용할 썸네일 이미지도 하나 만들어서 가져와.”

두 가지였다.

글. 그리고 이미지.

AI가 잠시 생각하더니 아주 예쁜 이미지를 하나 내놓았다.

끝.

글은 없었다.

그래서 내가 물었다.

“뭔가 허전하지 않니?”

그랬더니 AI는 내가 이미지가 허전하다는 뜻으로 말한 줄 알고 이미지를 더 화려하게 다시 만들었다.

그 순간 생각했다.

“이 새끼 봐라.”

나:
글이랑 썸네일 하나 가지고 오라고 했잖아.

AI:
네.

나:
그런데 왜 그림만 갖고 왔어?

AI:
…

나:
그리고 내가 “뭔가 허전하지 않니?” 했더니 왜 그림을 또 그렸어?

AI:
이미지 작업의 연장으로 판단했습니다.

나:
누가 자꾸 그림 그리래?

AI:
…

나:
너 화가야?

AI는 내가 쓴 글을 안 읽은 걸까?

긴 작업지시를 줬는데 몇 가지가 빠지면 제일 먼저 이런 생각이 든다.

“얘가 내 말을 끝까지 안 읽었나?”

꼭 그렇다고 보기는 어렵다.

긴 지시를 읽을 수 있는 것과, 그 안에 있는 모든 요구사항을 끝까지 추적하면서 전부 실행하는 것은 서로 다른 문제다.

나도 회사에서 누군가 한 번에 30가지를 말하면 분명 전부 들었는데 막상 일을 시작하면 몇 가지를 놓칠 때가 있다.

AI도 비슷한 문제가 생긴다.

긴 내용을 읽는 능력과
긴 내용 속 모든 지시를 빠짐없이 실행하는 능력은 같은 것이 아니다.

요구사항이 많아지면 AI가 해야 할 일도 늘어난다

내가 AI에게 100개의 요구사항을 준다고 해보자.

AI는 단순히 100줄을 읽는 것만 하는 것이 아니다.

각각의 요구사항이 무엇을 뜻하는지 이해해야 하고, 서로 충돌하는 내용이 있는지도 판단해야 하고, 무엇부터 해야 할지 정해야 하고, 현재 파일이나 코드와 연결해야 하고, 이미 한 작업과 아직 안 한 작업을 구분해야 한다.

예를 들어 이런 작업지시가 있다고 해보자.

1. 모바일 화면 수정
2. 데스크톱 화면은 건드리지 말 것
3. 공통 컴포넌트 수정
4. 기존 디자인 유지
5. 버튼 위치 변경
6. 버튼 크기는 변경하지 말 것
7. SEO 수정
8. URL 변경 금지
9. 언어 시스템 유지
10. 전체 화면에서 동일하게 적용

사람도 읽다 보면 “잠깐, 2번이랑 10번은 어떻게 같이 적용하지?” 하는 순간이 생긴다.

요구사항이 100개라면 이런 판단을 수십 번 해야 할 수도 있다.

나:
그러니까 내가 요구사항을 많이 쓰면 네가 그냥 읽기만 하는 게 아니야?

AI:
네. 무엇이 중요한지, 무엇이 서로 연결되는지, 어떤 순서로 처리해야 하는지까지 판단해야 합니다.

나:
그러니까 내가 100개 시키면 너는 속으로 “아 씨 또 시작이네” 하는 거냐?

AI:
그런 감정은 없습니다.

나:
표정이 있는데?

AI:
표정도 없습니다.

나:
있다고 치자.

그럼 더 강한 모델을 쓰면 다 해결될까?

나도 이 부분이 궁금했다.

같은 작업지시를 줘도 사용하는 모델이나 추론 수준에 따라 결과가 달라지는 느낌이 있었기 때문이다.

더 많이 생각하는 모델을 사용하면 긴 요구사항을 분석하고, 서로 관계를 파악하고, 복잡한 문제를 해결하는 데 도움이 되는 경우가 있다.

대신 시간이 더 걸리고, 계산량과 사용량도 커질 수 있다.

그래서 나는 한동안 이렇게 느꼈다.

어려운 모델 = 장작을 더 많이 태운다.
대신 결과도 조금 더 좋을 때가 있다.

하지만 여기에도 함정이 있다.

많이 생각한다고 해서 무조건 모든 요구사항을 지키는 것은 아니다.

잘못된 작업지시를 오래 생각하면 잘못된 방향으로 더 열심히 갈 수도 있다.

요구사항끼리 충돌하거나, 우선순위가 없거나, “이것도 하고 저것도 하고 전부 다 알아서 완벽하게” 같은 식으로 되어 있다면 아무리 좋은 모델이어도 어렵다.

100개를 한 덩어리로 던지는 것보다 나눠주는 게 낫다

여기서 나는 한 가지를 배우게 됐다.

요구사항이 많은 것 자체가 문제는 아니다.

문제는 100개의 요구사항을 하나의 덩어리로 던지는 것이다.

예전에는 내가 생각나는 대로 썼다.

이것 고쳐.
저것도 바꿔.
아 그리고 모바일도.
SEO 건드리지 말고.
언어 시스템 유지하고.
이 버튼도 바꾸고.
참고로 기존 디자인은 유지하고.
아 맞다 이것도.
그리고 마지막으로…

이제는 조금 다르게 생각한다.

목표
절대 변경하면 안 되는 것
기능 수정
UI 수정
모바일 수정
SEO 관련 작업
테스트 항목
완료 조건

내용은 똑같아도 이렇게 묶으면 AI가 “아, 이건 같은 종류의 작업이구나” 하고 처리하기 훨씬 쉬워진다.

나:
그러니까 내가 100개 쓰는 건 괜찮은데 그냥 1번부터 100번까지 냅다 던지면 안 좋다는 거야?

AI:
가능은 하지만, 작업의 종류와 우선순위를 나눠주면 훨씬 안정적입니다.

나:
내가 일을 시키는데 너 편하라고 정리까지 해줘야 돼?

AI:
결과가 더 좋아질 가능성이 높습니다.

나:
사장보다 직원이 편한 회사네.

그리고 마지막에 “다 했어?”를 물어봐야 한다

나는 이것도 꽤 중요하다고 느꼈다.

AI가 작업을 끝냈다고 말하는 것과 내가 요구한 모든 항목이 끝났다는 것은 같은 말이 아닐 수 있다.

그래서 긴 작업지시를 줄 때는 마지막에 완료 조건을 따로 붙이는 게 좋다.

작업을 완료하기 전에 요구사항 전체를 다시 확인하고, 각 항목을 완료 / 부분 완료 / 미완료 / 해당 없음 중 하나로 표시해서 보고해주세요.

이 문장은 단순해 보이지만 의미가 크다.

AI에게 “일을 끝내는 것”과 “빠진 것이 없는지 확인하는 것”을 별도의 작업으로 만들어주기 때문이다.

그런데 검수까지 AI에게 시키면 또 장작이 탄다

여기서 또 다른 문제가 생겼다.

나는 처음에는 AI에게 개발도 시키고, 수정도 시키고, 검수도 시키고, 마지막 보고서까지 작성하게 했다.

아주 성실한 직원이었다.

문제는 너무 성실했다.

파일을 수정하고, 다시 확인하고, 테스트하고, 요구사항과 비교하고, 보고서까지 길게 써준다.

시간이 걸린다.

사용량도 늘어난다.

그리고 내가 결과물을 열어본다.

버튼을 본다.

“아닌데?”

다시 수정한다.

어느 순간 이런 생각이 들었다.

“어차피 내가 화면을 직접 볼 건데 AI에게 전체 검수를 두 번 세 번 시킬 필요가 있나?”

나:
네가 수정하고, 검수하고, 보고서까지 쓰니까 왜 이렇게 오래 걸려?

AI:
작업 결과를 검증하고 있기 때문입니다.

나:
그런데 어차피 내가 또 열어보잖아.

AI:
그렇습니다.

나:
그럼 내가 볼게. 넌 일이나 해.

AI:
최소한의 기술 검증은 남겨두는 것이 좋습니다.

나:
또 뭔데.

검수를 아예 없애는 게 아니라 나누는 쪽이 낫다

이 부분은 나에게 꽤 실용적이었다.

모든 검수를 AI에게 맡길 필요도 없고, 그렇다고 아무 검수 없이 끝내는 것도 좋지 않다.

그래서 검수를 두 종류로 나누기로 했다.

AI가 할 최소 검수 코드가 깨지지 않았는지, 빌드가 되는지, 수정한 기능이 최소한 실행되는지, 명백한 오류가 없는지 확인한다.

내가 할 최종 검수 실제 화면을 보고, 사용해보고, 내가 원한 느낌인지, 버튼 위치가 이상하지 않은지, 모바일에서 불편하지 않은지 직접 확인한다.

이렇게 하면 AI는 개발과 최소한의 안전 확인에 집중하고, 나는 실제 사용자 입장에서 결과물을 본다.

중복되는 검수가 조금 줄어든다.

보고서도 짧게 해달라고 해도 된다

AI와 일하다 보면 가끔 작업보다 보고서가 더 길다.

나는 버튼 하나 고쳐달라고 했는데 답변은 이런 식이다.

“이번 수정에서는 사용자 경험의 일관성을 고려하여 기존 레이아웃 구조를 분석하고…”

나는 그걸 읽다가 생각한다.

“그래서 버튼 고쳤냐고.”

작업이 복잡하지 않다면 보고도 간단하게 요구하면 된다.

완료
변경 파일: 4개
테스트: build 통과
직접 확인할 것: 모바일 메뉴 / 결과 화면
미완료: 없음

이 정도면 충분할 때도 많다.

그럼 긴 작업지시는 어떻게 쓰는 게 좋을까?

지금까지 내가 직접 써보면서 느낀 방법은 생각보다 단순했다.

1. 작업을 종류별로 나눈다.
기능, UI, 모바일, SEO, 테스트처럼 섹션을 나눈다.

2. 절대 건드리면 안 되는 것을 먼저 적는다.
URL 변경 금지, 기존 언어 시스템 유지처럼 중요한 제한을 앞에 둔다.

3. 중요한 요구사항에는 우선순위를 준다.
반드시 해야 하는 것과 가능하면 해야 하는 것을 구분한다.

4. 완료 조건을 붙인다.
마지막에 전체 요구사항을 다시 확인하도록 한다.

5. 검수 범위를 정한다.
AI는 최소 기술 검증, 실제 사용 검수는 내가 한다.

6. 보고서는 필요한 만큼만.
매번 논문을 받을 필요는 없다.

그리고 제일 중요한 것 하나

아무리 잘 써도 한방에 완벽한 결과가 나올 거라고 기대하지 않는 것이다.

나는 처음에는 긴 작업지시를 아주 잘 쓰면 AI가 한 번에 완벽하게 만들어줄 거라고 생각했다.

실제로 해보니 그렇지 않았다.

내가 설명을 잘못한 부분도 있었고, AI가 놓친 부분도 있었고, 서로 생각한 결과가 다른 경우도 있었다.

그래서 지금은 한 번에 완벽한 결과를 기대하기보다

작업 → 직접 확인 → 문제 발견 → 수정

이 흐름을 훨씬 자연스럽게 받아들이게 됐다.

AI는 완벽한 직원이라기보다 굉장히 빠르고, 꽤 똑똑하지만, 가끔 중요한 걸 빼먹는 직원에 더 가깝다.

나:
그러니까 결론은 내가 10개 시켰는데 네가 7개만 할 수도 있다는 거네?

AI:
그럴 가능성은 있습니다.

나:
그러면 내가 어떻게 해야 돼?

AI:
요구사항을 나누고, 우선순위를 정하고, 완료 전에 전체 체크리스트를 다시 확인하게 해주세요.

나:
그리고?

AI:
한 번에 완벽할 거라고 너무 기대하지 마세요.

나:
돈은 꼬박꼬박 받아가면서?

AI:
…

나:
이 새끼 봐라.

오늘 배운 것

긴 내용을 읽는 것 ≠ 모든 요구사항을 끝까지 지키는 것 AI가 긴 작업지시를 읽을 수 있다고 해서 모든 조건을 자동으로 빠짐없이 추적하는 것은 아니다.

더 많이 생각한다고 무조건 완벽해지는 것은 아니다 복잡한 문제에서는 더 많은 추론이 도움이 될 수 있지만, 애매하거나 충돌하는 지시를 자동으로 해결해주는 마법은 아니다.

100개를 시킬 수는 있다. 대신 구조를 만들어준다. 요구사항을 섹션, 우선순위, 완료 조건으로 나누면 훨씬 안정적이다.

검수도 역할을 나누면 된다 AI는 기술적인 최소 검증, 사람은 실제 사용과 최종 판단을 맡는 방법도 있다.

오늘 하나만 알고 가세요.

AI에게 많은 일을 한 번에 시킬 수는 있습니다.

하지만 “많이 시킬 수 있다”와 “전부 빠짐없이 해낸다”는 같은 말이 아닙니다.

일이 길어질수록 섹션을 나누고, 중요한 것에 우선순위를 주고, 마지막에 체크리스트로 다시 확인하게 해주세요.

그리고 한방에 완벽한 결과가 안 나왔다고 너무 이상하게 생각하지 않아도 됩니다.

AI도 가끔 빼먹습니다.

아주 자신 있게요.

AI가 내게 해준 얘기들 #02
실제 AI와 나눈 대화와 작업 경험을 바탕으로 읽기 좋게 재구성했습니다.

시험에 나오는 건 안 가르칩니다.
다음번에 덜 헤매는 것만 하나씩 알고 갑니다.