Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 AI 코딩 어시스턴트를 사용할 때, 결과물의 완성도는 사용자의 '요청 방식'에 달려있음을 강조합니다. 단순히 오류가 발생할 때마다 수정 요청을 추가하는 것보다, 구현하려는 기능이 실제 어떻게 사용될지 시나리오를 깊이 생각하고 구조화된 방식으로 AI에게 요구해야 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이 글은 '개발을 조금 쉽게 만든 팁을 게시합니다! by DoctorNet Advent Calendar 2026'의 기고문입니다.
AI 코딩 어시스턴트를 매일 사용하면서 깨달은 것이 하나 있습니다.
바로, 같은 AI를 사용하더라도,
'즉시 원하는 대로 작동하게 만드는 사람'과 '여러 번 수정해야 하는 사람'이 있다는 것입니다.
그리고 그 차이는 프로그래밍 경력이나 AI 성능 때문이 아니라, AI에게 '요청하는 방식'에 대한 생각의 차이에서 비롯되고 있었습니다.
이번 글에서는 'AI에게 부탁해도 결국 내가 직접 고쳐야 한다...'고 느끼는 분들을 위해, 그 '생각의 차이'를 구체적인 예시로 비교하며 알기 쉽게 정리해 보았습니다.
이 글을 통해 알 수 있는 것
먼저, 다음과 같은 작업을 상상해 보세요.
React + TypeScript로 만들어진 회원 목록 화면에 '검색창'을 추가하고 싶다| 재료 | 내용 |
|---|---|
| 기존 코드 | MemberList.tsx (목록 화면) useMembers.ts (데이터 가져오기) |
| 회원 데이터 항목 | 회원 번호 / 이름 / 읽는 법 / 전화번호 / 최종 방문일 |
| 팀 규칙 | 입력 필드 등의 부품은 components/ui의 사내 부품을 사용한다 |
:bulb: :bulb:
본 기사에서는 다음 두 사람이 같은 AI에게 같은 작업을 요청하는 과정을 비교하며, 그 생각의 차이를 정리해 보겠습니다.
생각의 차이를 정리한 글이므로, 위의 재료만 사용 가능하다는 전제로 부탁드립니다.
'애초에 요구사항을 제대로 정해야 한다', '검색은 서버 측에서 해야 한다' 등 의견은 일리가 있지만... 이야기가 너무 넓어지니 양해 바랍니다.
A님은 먼저 자신이라면 어떻게 구현할지를 머릿속으로 조합했습니다.
그리고 그 절차를 그대로 AI에게 전달합니다.
역시 A님답게, 순서에 망설임이 없습니다.
AI도 지시대로 즉시 코드를 작성해 주었습니다.
그런데 실제로 작동시켜 보니...
A님은 '설명이 부족했나'라며, 절차를 추가했습니다.
1. useState로 keyword를 정의한다
(중략)
5. 대소문자는 구분하지 않는다
...
이번에는 읽는 법으로도 검색할 수 있게 되었습니다.
하지만, 또 새로운 문제가 발생합니다.
또 문제 발생!
세심한 A님에게는 빠진 것이 없습니다.
문제가 발생할 때마다, 정성껏 절차를 추가해 나갔습니다.
1. useState로 keyword를 정의한다
(중략)
8. input 태그가 아니라 components/ui의 TextInput을 사용한다
...
네. 이제 완성입니다.
어떠신가요? 여러분의 요청 방식과 비교했을 때, 비슷한 점이 있었나요?
반면, 주니어 B님은 어땠냐 하면...
B님은 바로 AI에게 요청하지 않고, 이 검색창이 어떻게 사용될지를 신중하게 생각했습니다.
전화로 듣는 것은 '소리'이기 때문에, 고객의 이름은
히라가나나 가타카나로 입력할 것 같고, 이름을 밝히지 않으면
'전화번호 하위 4자리'로 검색하는 경우도 있을 거야. 전화를 하면서니까,
급하게 입력하겠지. 하이픈을 넣기도 하고 안 넣기도 하고, 제각각일 거야. 3,000명 정도면, 화면 내에서 필터링해도 무겁지 않을까?
와 같이, 사용하는 사람의 상황을 상상하며 이미지를 구체화해 나갑니다.
그리고 그 이미지 자체를 그대로 AI에게 전달했습니다.
B 씨의 지시에는 useState도, filter도 나오지 않습니다.
괜찮을까요… :sweat_smile: :sweat_smile:
그러자 AI는 코드를 작성하기 전에 다음과 같은 질문을 돌려주었습니다.
1. 성명에 한자가 포함되어 있는데, 검색 대상은 '성명'과 '요미가나(읽는 법)' 모두로 하는 것이 좋을까요?
2. 회원 수가 약 3,000명 정도라고 하니, 화면 측에서 필터링하는 방법을 고려하고 있습니다. 장래적으로 크게 늘어날 예정이 있습니까?
B 씨는 '둘 다 부탁드립니다', '당분간은 늘지 않습니다'라고 답했습니다.
그러자 AI가 방침을 제시해 줍니다.
B 씨는 그 방침을 읽고 '이대로 부탁드립니다'라고 전달했습니다.
그리고, 여기서야 비로소 AI가 코드를 작성하기 시작합니다.
네. 이걸로 완성입니다!! :tada: :tada:
게다가 B 씨가 생각하지 못했던 **'전각 숫자 정렬 방법'**까지도 AI가 방침 안에 넣어주었습니다.
두 사람의 결과를 비교해 봅시다. 어떻습니까?
| 베테랑 A 씨 | 신입 B 씨 | |
|---|---|
| 주고받은 횟수 | 7회 | 2회 |
| ... | 어떻게 할지(절차) |
왜/무엇을(목적과 완성형) |
흥미롭게도, 마지막 지시의 길이는 두 사람 모두 거의 같습니다.
그런데 결과는 크게 달랐습니다.
어째서 이렇게 차이가 났는지. 두 사람의 절차를 복습해 봅시다.
베테랑 A 씨는 자신의 머릿속에 있는 구현 절차를 그대로 AI에게 전달했습니다.
AI는 절차대로 움직이지만, 절차에 쓰여 있지 않은 것은 생각하지 않습니다.
그렇기 때문에, A 씨가 생각지 못한 문제는 작동시켜 보고 나서야 발견되었고, 그때마다 다시 수정해야 했습니다.
즉, A 씨의 입장에서 AI는
'시키는 대로 손을 움직이는 도구'였던 것입니다.
신입 B 씨는 먼저 '어떻게 사용될지 끝까지 생각'하고, 그것을 목적과 완성형으로 AI에게 전달했습니다.
그리고 바로 만들라고 시키지 않고, 질문과 방침을 먼저 내놓도록 했습니다.
그 결과, AI는 스스로 부족한 정보에 깨닫고 B 씨가 생각하지 못한 것까지도 방침 안에 넣어주었습니다.
즉, B 씨의 입장에서 AI는
'함께 생각해 주는 팀 동료'였던 것입니다.
이처럼 두 사람에게서는 AI를 부탁하는 '생각 방식'이나 '절차', 의식하는 '포인트'가 크게 다르다는 것을 알 수 있습니다.
차이점을 파악했으니, 여기부터는 **'AI에게 한 번에 작동하도록 요청하기 위한 5가지 마음가짐'**으로 복습해 보겠습니다.
A 씨가 저지르고 있었습니다.
오해하지 말아 주셨으면 좋겠지만, 절차를 쓰는 것이 나쁜 것은 아닙니다.
절차를 써버리면, AI는 그 절차 바깥을 생각하지 않게 됩니다.
그리고 절차의 '누락'은 작성한 본인이 가장 알아채기 어려운 것입니다.
절차를 쓰고 싶다는 생각이 들면, 잠시만 참으시고 '무엇을 위한 절차인지'를 먼저 써보세요.
B 씨의 지시에서 가장 효과적이었던 것은 '전화를 받으며 사용하는 상황'이라는 문구였습니다.
이 한 문구가 있다는 것만으로도 AI는 '급하게 입력하는', '귀로 들은 이름을 넣는' 등의 상황을 상상할 수 있게 됩니다.
코드에는 쓰여 있지 않은 '사용 장면'은, 사람이 전달해 줄 수밖에 없습니다.
|
|
|---|---|
| 히라가나와 가타카나를 구분하지 않음 | '야마다', 'ヤマダ' 둘 다 검색 가능 |
| 전화번호 하이픈을 무시함 | '1234', '090-1234' 둘 다 검색 가능 |
예시로 적는 것이 실수 없이 전달됩니다.
예시가 있으면, AI는 거기서부터 규칙을 생각해주고 테스트를 작성할 때의 재료가 됩니다.
이것이 가장 빠른 지름길입니다.
| 요청 방식 | 실수를 발견하는 타이밍 |
|---|---|
| 바로 만들게 시키기 | 작동시킨 후 |
| 방침을 먼저 내놓도록 하기 | 만들기 전 |
수정하는 데 걸리는 수고가 완전히 다릅니다.
A 씨의 때는, 어느새 정렬 기능이 고장 나 있었습니다.
'사내 비품 사용', '정렬은 변경하지 않음' 등, 변경하고 싶지 않은 것을 먼저 알려주면 불필요한 수정 없이 넘어갈 수 있습니다.
덤: 매번 전달할 것은 파일로 모아두기
'사내 비품 사용', '테스트도 함께 작성하기' 등, 매번 전달해야 할 내용은 AI 도구가 읽어 들일 수 있는 설정 파일에 모아두면 편리합니다.
예를 들어 Claude Code의 경우 프로젝트에 CLAUDE.md
두어 놓으면 매번 적지 않아도 읽어줍니다.
# 이 프로젝트의 규칙
- 입력란 등의 부품은 components/ui 내부 부품을 사용한다
- 기존 기능을 변경할 때는, 먼저 방침을 설명한다
이상으로 'AI가 한 번에 작동하도록 하는 5가지 수칙'이었습니다.
AI에게 요청하기 전에 체크리스트로 활용해 보세요.
1. 갑자기 절차를 적지는 않았는지 -
2. '누가・언제・왜 사용하는지'를 전달했는지 -
3. 완성된 이미지(결과물)를 '예시'로 전달했는지 -
4. 만들기 전에 '질문'과 '방침'을 먼저 요청받았는지 -
5. '지켜줬으면 하는 것'을 미리 전달했는지
바로 사용할 수 있도록 B님의 지시사항을 템플릿으로 만들어 두었습니다. 필요하다면 복사해서 사용해 보세요.
AI 요청 방법 템플릿
## 하고 싶은 일
(무엇을 만들고 싶은지・어떻게 고치고 싶은지)
## 사용할 사람과 상황
...
여기까지 읽어주셔서 감사합니다.
'AI에게 요청해도 결국 내가 직접 수정해야 한다', 'AI는 아직 쓸 수 없다'라고 느끼는 분들을 위해, 어떻게 설명하면 이해하기 쉬울지 고민하여 정리한 내용입니다.
AI에 요청하는 방법은 사실
새로운 팀원에게 업무를 부탁할 때와 같습니다.
단순히 절차만 전달하기보다는, '왜 해야 하는지', '어떻게 되어야 완성인지'를 알려주는 편이 상대방이 스스로 생각하고 움직여 줍니다.
조금이라도 여러분의 개발 과정이 '좀 더 수월해졌으면' 좋겠습니다.
본 기사에서는 '구체적인 예시를 통해 사고방식의 차이를 설명'했을 뿐이므로, 반드시 모든 상황에서 B님의 요청 방식이 좋거나, 최적의 해답이라고 말하는 것은 아닙니다.
작은 수정이라면 A님처럼 절차를 한마디로 전달하는 것이 더 빠를 때도 있습니다. (그래서 B님을 신입으로 설정했습니다.)
등장인물의 생각 방식, 절차, 주고받는 횟수나 시간 등 본 기사에 게재된 내용은 이해하기 쉽도록 만들어진 픽션입니다. AI의 답변은 사용하는 도구나 버전에 따라 다릅니다. 양해 부탁드립니다.