목차11
수정
아이디어가 생기면 빨리 만들어보고 싶어진다.
AI는 그 생각을 구체적으로 풀어준다. 기능을 제안하고, 화면을 나누고, 구현 순서까지 정리한다. 그러다 보면 아직 확인하지 않은 생각에도 확신이 붙는다.
나도 그런 방향으로 가곤 했다.
그래서 만들기 전에 내 생각을 점검할 질문을 따로 두기 시작했다. 아래 열 개는 그때 사용할 수 있는 프롬프트다.
모두 한 번에 사용할 필요는 없다. 내가 무엇을 모르고 있는지에 따라 골라 쓰면 된다. {} 안에는 자신의 내용을 넣는다. 자료를 찾을 도구가 없는 AI에게는 원문을 직접 제공해야 하며, 존재하지 않는 출처를 만들어서 빈칸을 채우게 해서는 안 된다.
번호는 아래 본문의 절 번호다. 모두 쓸 필요 없이 필요한 질문만 고른다.
- 어디서 시작할지 모르겠다
- 1 분야 파악 · 2 먼저 해본 사람의 조건 · 8 재사용할 구현
- 만들 이유가 충분한지 모르겠다
- 3 잘되지 않을 이유 · 6 사용자가 바꾸고 싶은 일
- 참고했는데 겉모습만 닮았다
- 4 작업 기준으로 분해 · 5 얕게 따라 한 부분 찾기
- 믿고 공개해도 되는지 모르겠다
- 7 지금 말해도 되는 주장 · 9 이해하지 못한 부분
- 조사 다음 행동이 안 정해진다
- 10 다음에 확인할 가정과 최소 작업 정하기
1. 내가 들어가려는 분야부터 파악하기
어떤 문제를 풀고 있는지도 모르는데 개선안부터 받지 않으려는 질문이다.
내가 만들고 싶은 것은 {아이디어}다.
누구의 어떤 일을 바꾸려는지는 {대상과 문제}다.
바로 기능을 제안하지 말고, 먼저 이 문제와 연결된 분야를 정리해줘.
이미 쓰는 제품, 관련 오픈소스, 공식 자료, 실패하거나 중단된 접근을 구분해라.
각 항목에는 원문 출처와 확인 시점을 붙이고,
내가 왜 봐야 하는지와 아직 모르는 것을 적어라.
찾지 못한 자료는 없다고 단정하지 말고 미확인으로 남겨라.
마지막에 내가 가장 먼저 알아야 할 질문 세 개를 골라라.자료를 많이 모으는 것이 목적은 아니다. 내가 모르는 범위가 어디까지인지 먼저 보려는 것이다.
2. 먼저 해본 사람이 어떤 조건에서 선택했는지 보기
비슷한 제품이 있다는 사실보다, 왜 그런 방식으로 만들었는지 알고 싶을 때 쓴다.
{문제}를 먼저 다룬 사례를 찾아줘.
가능하면 제작자의 설명, 실제 제품, 공식 문서, 저장소의 논의를 확인해라.
각 사례를 다음 순서로 정리해라.
어떤 사용자의 문제를 풀었는가?
어떤 제약과 자원을 가지고 있었는가?
실제로 확인되는 선택은 무엇인가?
제작자가 직접 설명한 이유와 네가 추정한 이유는 무엇인가?
내 조건인 {나의 조건}과 무엇이 다른가?
유명하다는 이유만으로 좋은 기준으로 선정하지 마라.다른 사람의 성공 조건을 빼놓고 결과만 가져오지 않기 위한 질문이다.
3. 잘되지 않을 이유를 먼저 보기
아이디어를 키우는 설명만 계속 나올 때 사용한다.
{아이디어}가 잘되지 않을 가능성을 검토해줘.
확인된 실패 사례와 아직 검증하지 않은 위험 가설을 구분해라.
각 위험에 대해 원인, 초기에 볼 수 있는 신호,
내 상황에서 확인할 방법, 실패했을 때 바꿀 것을 적어라.
억지로 반대하지 말고, 근거가 약한 반론은 약하다고 표시해라.
마지막에 계속할 이유와 중단할 이유를 각각 가장 강한 것부터 정리해라.반론을 받았다는 이유로 아이디어를 버릴 필요는 없다. 무엇을 먼저 확인해야 하는지 정하는 데 쓴다.
4. 결과물을 작업 기준으로 분해하기
참고자료를 넣었는데 겉모습만 비슷하게 나올 때 필요한 질문이다.
내가 만들 결과물은 {결과물}이다.
참고할 원본은 {원본 링크 또는 첨부 자료}다.
원본에서 핵심 대상, 정보의 관계, 입력과 출력,
사용자가 움직이는 순서, 오류 처리, 중요한 제약을 분해해라.
관찰할 수 없는 내부 동작을 사실처럼 채우지 마라.
내 작업으로 옮길 때에는 다음을 작성해라.
반드시 들어갈 요소와 관계.
해야 하는 행동과 하지 말아야 하는 행동.
결과물에 포함될 내용과 형식.
좋은 결과 예시와 수정이 필요한 결과 예시.
그 차이를 확인할 방법.분석이 다음 작업의 지침으로 이어져야 한다. 어려운 용어를 붙이는 것만으로 끝내지 않는다.
5. 얕게 따라 한 부분 찾기
기준을 가져온 것인지, 그냥 비슷하게 꾸민 것인지 돌아보는 질문이다.
내 결과물 {초안}과 참고한 원본 {자료}를 비교해줘.
다음을 구분해라.
겉모습만 따라 한 부분.
원본의 맥락과 달라서 맞지 않는 부분.
내가 이유를 설명하지 못한 채 가져온 부분.
이번 문제에는 필요 없는 부분.
원문·고유한 이미지·브랜드 요소 등 사용 권한을 확인해야 할 부분.
각 항목에 유지, 수정, 제거, 확인 중 하나의 조치를 붙여라.
차이가 있다는 이유만으로 원본 쪽이 낫다고 판단하지 마라.비슷하지 않다는 말은 충분한 비판이 아니다. 왜 바꿔야 하는지가 있어야 한다.
6. 사용자가 정말 바꾸고 싶은 일인지 확인하기
기능은 그럴듯하지만 왜 사용할지 설명하기 어려울 때 쓴다.
{아이디어}의 기능 목록보다 실제 사용과 구매의 조건을 봐줘.
누가 사용하고 누가 비용을 내는가?
지금은 어떤 방법으로 일을 해결하는가?
바꾸려면 누가 어떤 수고를 해야 하는가?
기존 방식을 계속 쓰는 이유는 무엇인가?
내 제품 때문에 새로 생기는 운영 부담은 무엇인가?
확인한 사실과 추정을 나누고,
현재 사용자에게 물어볼 구체적인 질문을 작성해라.
시장 규모나 지불 의사를 자료 없이 숫자로 만들지 마라.내가 불편해 보인다고 느낀 것과, 사용자가 돈과 시간을 들여 바꾸고 싶은 것은 다를 수 있다.
7. 지금 말해도 되는 주장인지 확인하기
소개 글이 실제 제품보다 앞서가지 않게 하려는 질문이다.
내가 공개하려는 문장은 {소개 문장}이다.
확인 가능한 자료는 {코드, 실행 결과, 사용자 기록 등}이다.
문장 속 주장을 분리해서 각 주장에 필요한 근거를 적어라.
현재 자료로 말할 수 있는 범위와 아직 말할 수 없는 범위를 나눠라.
구현, 연결, 실제 사용, 결과 확인을 같은 상태로 취급하지 마라.
근거가 부족한 문장은 의미를 과장하지 않는 표현으로 바꿔라.
개인적으로 느낀 효과를 일반적인 성능 보장으로 바꾸지 마라.좋은 소개는 자신감을 모두 빼는 글이 아니다. 실제로 한 일을 정확하게 보여주는 글이다.
8. 처음부터 만들 필요가 있는지 보기
개발을 시작하기 전에 이미 쓸 수 있는 것을 확인한다.
{요구사항}을 해결할 때 재사용할 수 있는 구현을 찾아줘.
각 후보의 공식 자료와 저장소를 확인하고,
맞는 기능, 맞지 않는 제약, 유지 상태, 통합 비용을 정리해라.
라이선스는 실제 파일을 기준으로 확인하고,
해석이 불확실한 사용 조건은 별도 검토가 필요하다고 표시해라.
그대로 사용, 일부 확장, 직접 구현 중 무엇이 적절한지 설명해라.
기능이 존재한다는 것과 내 환경에서 확인했다는 것을 구분해라.
필요 없는 의존성을 추가하지 않는 선택도 비교해라.직접 만들었다는 사실보다, 내가 계속 운영할 수 있는지가 중요하다.
9. 이해하지 못한 채 넘기는 부분 찾기
모든 구현을 직접 외우려는 질문은 아니다. 판단에 필요한 빈칸을 찾기 위한 것이다.
{계획 또는 결과물}에서 중요한데 아직 설명하거나 확인하기 어려운 부분을 찾아줘.
각 부분에 대해 다음을 적어라.
내가 결정해야 하는 내용인가, 기술 작업으로 위임할 수 있는가?
모르면 어떤 문제가 생기는가?
어떤 원문, 설명, 테스트 또는 실제 사용으로 확인할 수 있는가?
확인 전에는 어떤 행동이나 주장을 보류해야 하는가?
모든 코드의 정독을 자동으로 사람의 숙제로 만들지 마라.
에이전트가 수행할 확인과 사람이 책임질 선택을 나눠라.모르는 것이 드러나면 다음 일이 구체적이 된다. 모르는 상태를 숨기면 다음 사람은 그것이 해결됐다고 생각할 수 있다.
10. 다음에 무엇을 할지 결정하기
조사만 계속 늘어날 때 다음 행동을 좁히는 질문이다.
지금까지 확인한 {아이디어와 자료}를 기준으로
작게 실행, 수정 후 실행, 보류 중 하나를 제안해줘.
최종 사업 판단이나 외부 실행의 승인은 내게 남겨라.
제안에는 다음을 포함해라.
가장 중요한 근거와 아직 남은 불확실성.
다음에 확인할 가정 하나.
그 가정을 확인할 최소 작업.
좋아졌다고 판단할 기준과 실패한 경우의 다음 선택.
추가로 들어가는 시간·비용·외부 영향.
이번에 정한 내용과 남은 질문을 구분해서 기록해라.
보류할 이유가 충분하면 억지로 기능을 늘려 계속시키지 마라.분석이 길어졌다는 이유로 좋은 결정을 했다고 생각하고 싶지는 않다. 다음에 무엇을 확인할지 더 분명해졌다면 그 분석은 쓸모가 있다.
마치며
질문 열 개를 모두 썼다고 준비가 끝나는 것은 아니다.
중요한 것은 답에 무엇이 들어 있는지다. 출처가 있는지, 내 상황을 고려했는지, 실제로 해볼 수 있는 행동으로 이어지는지 봐야 한다.
내가 이 질문들을 남긴 이유도 AI에게 더 그럴듯한 기획서를 받기 위해서가 아니다.
아직 모르는 것을 모르는 상태로 보고 싶었다. 그리고 만들기 시작할 때는 적어도 무엇을 확인하려는지 알고 싶었다.