<div id="readability-page-1" class="page"><div><div tabindex="-1"><a rel="noopener follow" href="/?source=post_page---byline--3d6bfa6929de---------------------------------------" data-discover="true"><div><img alt="Jusung Hwang" src="https://miro.medium.com/v2/resize:fill:64:64/1*3sz0SF37ibwm-BAopfwAfQ.png" width="32" height="32" loading="lazy" data-testid="authorPhoto"></div></a></div><h2 id="dbfc">배경</h2>올해 초부터 Codex를 구독해서 사용하고 있다.작년 회고에서도 적었지만, 나는 AI와 함께 일하는 방법에 관심이 많다. 작년에는 ChatGPT로 필요한 걸 물어보다가 Cursor를 쓰면서 AI를 개발 과정에 조금 더 적극적으로 끼워 넣기 시작했다면, 올해는 그 흐름이 Codex로 이어졌다.요즘 특히 눈에 들어오는 건 인터넷에서 자주 언급되는 하네스 엔지니어링 관련 이야기들이다. AI 에이전트를 어떻게 하면 내가 의도한 방향으로 더 잘 다룰 수 있을지, 다른 사람들은 어떤 구조와 방식으로 하네스를 깎고 있는지 궁금했다.그러던 중 유튜브에서 한국에서 열린 OpenAI Codex 커뮤니티 밋업 녹화 영상을 보게 됐다. 영상에서는 Codex를 활용한 여러 실험과 하네스 이야기가 나왔고, 그중 랄프톤도 소개됐다.<figure></figure>가볍게 얘기하자면 랄프톤은 AI가 밤새 코딩하고 사람은 잠을 자는 방식으로 진행된 해커톤이었다고 한다. 그 행사에서는 AI 에이전트가 사람이 잠든 동안 소프트웨어를 얼마나 자율적으로 완성할 수 있는지를 보고자 했다고 한다.랄프톤에서 1등을 한 팀에 대한 얘기가 나오면서, Q00님이 만든 Ouroboros의 존재를 처음 알게 되었다. 몇 달 전부터 Superpowers의 brainstorming 스킬을 사용하고 있었기 때문에 자연스럽게 궁금해졌다. Ouroboros는 Superpowers의 brainstorming과 무엇이 다를까? Codex나 Claude에서 제공하는 계획 모드와는 어떤 점이 다를까? 그 안에 담긴 철학이나 컨셉은 무엇일까?그런 궁금증으로 Ouroboros를 찾아보기 시작했다. 저장소 README를 읽어보고, 다른 사람들은 Ouroboros를 어떻게 쓰는지도 궁금해서 관련 영상을 찾아봤다. 그러다 Q00님의 Ouroboros 관련 영상을 보게 됐고, 그 흐름에서 디자인 씽킹과 온톨로지를 다룬 영상까지 보게 됐다.<figure></figure><h2 id="2946">영상에서 뒤늦게 이해한 것</h2>영상을 보기 전에도 AI에게 작업을 맡기기 전에 모호함을 먼저 줄이는 워크플로우가 좋다는 건 경험적으로 알고 있었다. oh-my-codex나 oh-my-claudecode에 있는 deep-interview 스킬, 그리고 Superpowers의 brainstorming 스킬처럼, 바로 실행으로 넘어가기 전에 질문을 주고받으며 생각을 정리하는 흐름이 꽤 유용하다고 느꼈기 때문이다.하지만 그 안에 있는 소크라테스식 대화가 무엇인지, 왜 그런 방식이 필요한지까지는 잘 몰랐다. 디자인 씽킹과 온톨로지 영상에서는 소크라테스가 이야기한 “너 자신을 알라”에서 시작해, <code>Wonder(궁금해하기) -&gt; Reflect(되비추기) -&gt; Refine(다듬기) -&gt; Restate(다시 말하기) -&gt; Repeat(반복하기)</code>로 이어지는 흐름을 설명했다.듣다 보니 내가 좋다고 느꼈던 워크플로우가 단순히 프롬프트를 잘 쓰는 방법만은 아니었다는 생각이 들었다. 내가 정말 내 의도를 잘 알고 있는지, 내가 쓰는 단어와 개념의 경계가 충분히 명확한지, 상대방이나 AI가 내 말을 같은 의미로 이해할 수 있는지 확인하는 사고 과정에 가까웠다.디자인 씽킹이나 더블 다이아몬드도 마찬가지였다. 이름은 들어봤지만, <code>Discover(발견) -&gt; Define(정의) -&gt; Develop(구체화) -&gt; Deliver(전달)</code> 흐름이 문제를 확산하고 수렴하는 사고방식이라는 점은 제대로 이해하지 못했다. 특히 Discover 단계가 단순히 자료를 조사하는 것이 아니라, 내가 무엇을 모르고 있는지 발견하고 불완전한 맥락을 확인하는 과정이라는 설명이 인상 깊었다.온톨로지도 처음에는 어렵게 느껴졌다. 그런데 단어와 개념의 정의, 경계, 관계를 맞추는 일이라고 생각하니 AI와 대화할 때 왜 맥락을 명확히 해야 하는지가 조금 더 이해됐다. 내가 가진 온톨로지를 AI가 모른다면, AI는 결국 추측할 수밖에 없다. 그리고 그 추측은 때로 내가 기대한 방향과 다른 결과로 이어진다.가장 크게 와닿았던 건 지식의 4사분면, 그중에서도 <code>unknown unknown</code>에 대한 이야기였다. 내가 모른다는 사실조차 모르고 있는 것들은 혼자서는 발견하기 어렵다. 그런데 AI가 질문을 통해 그런 부분을 끄집어낼 수 있다는 설명을 들었을 때, 그동안 내가 AI와 대화하면서 느꼈던 장면들이 떠올랐다.<h3 id="2d6b">unknown unknown을 질문으로 발견하기</h3>제품을 만들다 보면 기능 하나만 따로 존재하는 경우는 거의 없다. 화면에는 여러 액션이 있고, 하나의 액션이 다른 기능의 상태와 연결될 때가 많다. 어떤 버튼을 눌렀을 때 단순히 그 버튼만 동작하는 것이 아니라, 이미 존재하던 다른 기능의 흐름이나 예외 처리와 맞물릴 수도 있다.이런 관계는 처음부터 모두 보이지 않는다. 특히 기존 코드베이스 위에서 기능을 추가할 때는 더 그렇다. 내가 지금 만지는 화면만 보고 있으면 단순한 작업처럼 보이지만, 실제로는 다른 도메인 로직이나 기존 상태 관리, 이미 만들어진 사용자 흐름과 연결되어 있을 수 있다.이때 AI가 유용했던 건 단순히 엣지 케이스 목록을 뽑아줘서가 아니었다. 코드베이스를 같이 읽고 나서 “이 부분은 기존의 이 기능과도 연관이 있어 보이는데요. 이 경우는 어떻게 처리할까요?” 같은 질문을 던져줄 때였다.그런 질문을 받으면 그제야 내가 아직 인식하지 못했던 관계가 보인다. 영상에서 말했던 지식의 4사분면으로 보면, 나에게는 이런 순간이 unknown unknown에 가까운 부분을 발견하는 경험처럼 느껴졌다. 내가 모른다는 사실조차 모르고 있던 관계를, AI가 코드와 맥락을 읽고 질문의 형태로 꺼내주는 것이다.<h2 id="27a0">팀에 공유했다</h2>처음에는 이 내용을 그냥 내 지식 베이스에만 정리해 두었다. 휴가 때 본 영상이었고, 그때는 내가 이해한 내용을 내 언어로 남겨두는 정도였다.그런데 휴가를 다녀와 회사에 돌아오고 나니, 이 내용을 팀에도 공유해보면 어떨까 하는 생각이 들었다.나는 AI와 대화하면서 모호한 부분을 먼저 꺼내고, 내가 놓친 관계나 시나리오를 질문으로 받아보는 과정에서 실제로 생산성이 올라간다고 느낀 적이 많았다. 단순히 더 빨리 답을 얻는다는 의미라기보다, 생각이 정리되는 속도와 문제를 바라보는 시야가 달라지는 느낌에 가까웠다.이런 방식이 나에게만 적용되는 것으로 끝나지 않았으면 했다. 제품은 혼자 만드는 것이 아니고, PO, PM, 디자이너, 개발자가 각자의 관점으로 같은 문제를 바라보며 만들어가기 때문이다. 각자의 자리에서 모호함을 조금 더 잘 다루고, 놓친 질문을 조금 더 잘 발견할 수 있다면, 우리가 만드는 제품의 방향성도 더 선명해질 수 있지 않을까 생각했다.결국 돌이켜보면, 나는 우리가 좀 더 의미 있는 제품을 만들었으면 했기 때문일지도 모른다.<h3 id="423c">설치보다 쉬운 프롬프트로</h3>다만 바로 brainstorming이나 deep-interview 같은 스킬을 써보라고 하기에는 허들이 있다고 느꼈다. 개발자들은 새로운 도구를 설치하고 써보는 일에 비교적 익숙하지만, 모두에게 그런 방식이 편한 것은 아니니까.그래서 처음에는 설치가 필요한 도구보다, 바로 복사해서 첫 대화에 넣을 수 있는 프롬프트 형태로 공유하는 게 낫겠다고 생각했다. 중요한 건 특정 도구를 쓰는 것이 아니라, AI와 대화하면서 모호한 부분을 먼저 드러내고 질문으로 좁혀가는 경험을 해보는 것이라고 생각했기 때문이다.실제로 공유했던 프롬프트는 아래와 같다.<pre>너는 지금부터 소크라테스식 대화를 통해 내 문제 정의를 도와주는 대화 파트너야.내가 다음 메시지에서 고민이나 질문을 하나 말할 거야. 너는 바로 해결책을 제안하지 말고, 아래 흐름으로 나와 대화해줘.## 1. Wonder / Receive내가 말한 고민을 판단하지 말고 먼저 받아들여줘. 무엇을 문제로 보고 있는지, 어떤 전제를 가지고 말하는지 들어줘.## 2. Reflect내 고민을 네가 이해한 방식으로 짧게 다시 말해줘. 내가 "맞아, 그 얘기야"라고 느낄 수 있게 확인해줘.## 3. Refine / Cross-examine그다음 내가 놓친 전제, 모호한 표현, 검증되지 않은 가정, 더 먼저 물어야 할 질문을 짚어줘. 단, 바로 결론을 내리지 말고 질문으로 파고들어줘.## 4. Restate대화를 거친 뒤, 문제 정의가 어떻게 바뀌었는지 더 선명한 문장으로 다시 정리해줘.## 5. Repeat새로 정리된 문제 정의를 바탕으로 다시 질문을 이어가줘.## 6. Ambiguity Tracking대화가 진행되면서 문제 정의의 모호함이 얼마나 줄었는지 가끔 수치로 알려줘.ambiguity는 0~1 사이로 표현해줘.- 1은 거의 모든 것이 모호한 상태 - 0은 더 이상 모호함이 거의 없는 상태단, 매 답변마다 수치를 말하지는 말고, 문제 정의가 크게 좁혀졌거나 내가 요청했을 때만 알려줘.ambiguity가 약 0.2 이하로 내려왔다고 판단되면, 바로 다음 단계로 넘어가지 말고 나에게 물어봐줘.예:&gt; 지금 ambiguity는 약 0.2 정도까지 내려온 것 같아. &gt; 여기서 문제 정의를 마무리할까, 아니면 요구사항/설계로 더 진행할까?## 규칙- 바로 해결책을 제안하지 마. - 한 번에 질문은 1~3개만 해줘. - 답을 길게 설명하지 말고, 내가 다시 생각해서 답할 수 있게 물어봐줘. - 목표는 정답을 빨리 찾는 것이 아니라, 내가 아직 모르고 있는 전제와 질문을 발견하는 거야. - ambiguity 수치는 절대적인 값이 아니라, 대화 진행 상태를 확인하기 위한 참고 지표로 사용해줘. - ambiguity가 충분히 낮아졌다고 판단되면, 문제 정의를 계속 확장하지 말고 종결 여부를 먼저 물어봐줘.내가 다음 메시지에서 고민을 말하면, 위 흐름으로 대화를 시작해줘.</pre>여담으로, 한 동료분이 장난삼아(?) 공유했던 문서가 너무 길다고 피드백을 주셔서 가볍게 만화로 만들어보는 시도도 해봤다. 😅<figure><div role="button" tabindex="0">Press enter or click to view image in full size</div><figcaption>AI에게 바로 답을 묻기 전에, 모호한 문제를 질문으로 다시 들여다보는 과정을 그린 만화. (AI로 생성된 이미지)</figcaption></figure><h2 id="31a2">공유하기 전에 직접 써보기</h2>팀에 공유할 문서를 정리하면서 프롬프트를 만들고 직접 써보는 과정도 진행했다.TMI지만, 요즘 AI를 쓰면서 생산성이 높아진 건 분명하다. 다만 그만큼 충분히 검증되지 않은 결과물이 그대로 공유되는 경우도 종종 보게 된다. 막상 문서를 읽어보면 무엇을 설명하려는 건지, 어떤 맥락에서 나온 내용인지 잘 보이지 않는 경우도 있다. 그런 방식은 협업 관점에서 좋은 경험은 아니라고 개인적으로 생각한다.그래서 내가 팀에 프롬프트를 공유한다면, 적어도 내가 먼저 써보고 어떤 흐름이 나오는지 확인해야 한다고 생각했다. 단순히 “이 프롬프트 좋아요”라고 던지는 것이 아니라, 실제로 사용해 본 예시를 함께 보여주고 싶었다. 그리고 그 예시를 통해 내가 AI를 어떤 방식으로 활용하는지도 간접적으로 보여줄 수 있지 않을까 생각했다.테스트 주제로는 요즘 관심 있던 “Slack에서 돌아가는 개인 AI 비서”를 골랐다. 여러 Slack 채널과 스레드에서 내 업무와 관련된 중요한 변화나 액션을 놓치지 않도록 도와주는 개인 비서를 만들 수 있을지 궁금했다.대화를 해보니 문제 정의는 꽤 구체화됐다. 핵심 채널 2~3개에서 시작하고, Jira와 Notion 맥락을 참고하며, 긴급한 내용은 실시간 DM으로 보내고 그 외 내용은 하루 3회 요약하는 식으로 정리됐다.<h3 id="c036">끝나는 지점을 만들기</h3>다만 대화가 길어지면서 한 가지 아쉬운 점도 보였다. 질문이 이어지는 건 좋았지만, 어느 순간 “이 대화에 끝나는 지점이 있긴 한 건가?” 싶은 생각이 들었다. 지금 문제 정의의 모호함이 얼마나 줄어들었는지도 확인하기 어려웠다. 그래서 ambiguity(모호함 정도)를 0~1 사이의 수치로 표시하고, 약 0.2 이하로 내려가면 문제 정의를 마무리할지 물어보도록 프롬프트를 업데이트했다.즉, 처음부터 완성된 프롬프트를 만든 것은 아니었고, 직접 써보고, 불편했던 부분이 있으면 수정하고, 그렇게 프롬프트를 손봤던 것 같다.실제로 테스트해 본 대화는 아래 링크로 남겨두었다.<ul><li id="8bad"><a href="https://chatgpt.com/share/6a03c0e9-8d28-83a5-95f5-79987e71df55" rel="noopener ugc nofollow" target="_blank">ChatGPT 공유 대화</a></li></ul><h2 id="7194">마치며</h2>이전에는 AI를 주로 낯선 개념을 빠르게 이해하거나, 키워드만 알고 있던 내용을 공부하는 용도로 자주 사용했다. 그런데 요즘은 거기서 조금 더 나아가, 내가 아직 모른다는 사실조차 모르고 있던 것들을 질문으로 발견하고, 모호한 부분을 clarify 해주는 경험도 중요하다고 느끼고 있다.내가 던진 질문이 모호하면 AI의 답도 쉽게 뻔해지거나 엉뚱해질 수 있다. 그렇기에 질문을 다듬고, 전제를 확인하며 내가 놓친 부분을 다시 바라보면 문제 자체가 조금 더 선명해진다.그런 관점에서 제품을 만드는 일도 비슷하다. 바로 해결책으로 넘어가기 전에, 우리가 지금 어떤 문제를 말하고 있는지, 같은 단어를 같은 의미로 쓰고 있는지, 아직 보지 못한 관계는 없는지 확인하는 시간이 필요하다. 그 시간이 당장은 조금 느려 보일 수 있지만, 결과적으로는 더 나은 선택을 하게 도와줄 수 있다고 느꼈다.이런 과정들이 요즘 나에게는 잘 맞아서, 당분간은 이렇게 사용하지 않을까 싶다.<h3 id="4a72">[짧은 생각] Ouroboros, OMC, OMX는 왜 별도의 상태 관리 머신이 있을까?</h3><blockquote>OMC는 oh-my-codex, OMX는 oh-my-claudecode를 말한다.</blockquote>가벼운 내 추측으로는, 계획 모드나 Superpowers의 스킬셋 기반 흐름은 현재 세션의 토큰 컨텍스트에 많이 의존한다. 그래서 대화가 길어지고 컨텍스트가 압축되는 과정에서 문제 정의의 맥락이나, 인터뷰에서 주고받았던 질문과 답변의 일부가 흐려질 가능성이 있지 않을까 싶다.또한 특정 AI 도구가 제공하는 세션 구조에 대한 의존성을 줄이려는 이유도 있지 않았을까 싶다. 언제 세션 구조나 컨텍스트 처리 방식이 바뀔지 모르는 상황이라면, 중요한 상태를 외부에 두고 이어가는 편이 더 안정적일 수 있겠다는 생각이 들었기 때문이다.정확히는 모르지만, AI와 문제 정의나 실행 흐름을 여러 턴에 걸쳐 이어가려면 “상태를 어디에 둘 것인가”도 꽤 중요한 질문이 될 수 있겠다는 생각이 들었다.</div></div>

Stories by Jusung Hwang on Medium

배경
올해 초부터 Codex를 구독해서 사용하고 있다.
작년 회고에서도 적었지만, 나는 AI와 함께 일하는 방법에 관심이 많다. 작년에는 ChatGPT로 필요한 걸 물어보다가 Cursor를 쓰면서 AI를 개발 과정에 조금 더 적극적으로 끼워 넣기 시작했다면, 올해는 그 흐름이 Codex로 이어졌다.
요즘 특히 눈에 들어오는 건 인터넷에서 자주 언급되는 하네스 엔지니어링 관련 이야기들이다. AI 에이전트를 어떻게 하면 내가 의도한 방향으로 더 잘 다룰 수 있을지, 다른 사람들은 어떤 구조와 방식으로 하네스를 깎고 있는지 궁금했다.
그러던 중 유튜브에서 한국에서 열린 OpenAI Codex 커뮤니티 밋업 녹화 영상을 보게 됐다. 영상에서는 Codex를 활용한 여러 실험과 하네스 이야기가 나왔고, 그중 랄프톤도 소개됐다.
https://medium.com/media/40817d195f82aa9a2ed4438faa8cf243/href
가볍게 얘기하자면 랄프톤은 AI가 밤새 코딩하고 사람은 잠을 자는 방식으로 진행된 해커톤이었다고 한다. 그 행사에서는 AI 에이전트가 사람이 잠든 동안 소프트웨어를 얼마나 자율적으로 완성할 수 있는지를 보고자 했다고 한다.
랄프톤에서 1등을 한 팀에 대한 얘기가 나오면서, Q00님이 만든 Ouroboros의 존재를 처음 알게 되었다. 몇 달 전부터 Superpowers의 brainstorming 스킬을 사용하고 있었기 때문에 자연스럽게 궁금해졌다. Ouroboros는 Superpowers의 brainstorming과 무엇이 다를까? Codex나 Claude에서 제공하는 계획 모드와는 어떤 점이 다를까? 그 안에 담긴 철학이나 컨셉은 무엇일까?
그런 궁금증으로 Ouroboros를 찾아보기 시작했다. 저장소 README를 읽어보고, 다른 사람들은 Ouroboros를 어떻게 쓰는지도 궁금해서 관련 영상을 찾아봤다. 그러다 Q00님의 Ouroboros 관련 영상을 보게 됐고, 그 흐름에서 디자인 씽킹과 온톨로지를 다룬 영상까지 보게 됐다.
https://medium.com/media/23a47b37d06618c4d3e263f3267e1083/href
영상에서 뒤늦게 이해한 것
영상을 보기 전에도 AI에게 작업을 맡기기 전에 모호함을 먼저 줄이는 워크플로우가 좋다는 건 경험적으로 알고 있었다. oh-my-codex나 oh-my-claudecode에 있는 deep-interview 스킬, 그리고 Superpowers의 brainstorming 스킬처럼, 바로 실행으로 넘어가기 전에 질문을 주고받으며 생각을 정리하는 흐름이 꽤 유용하다고 느꼈기 때문이다.
하지만 그 안에 있는 소크라테스식 대화가 무엇인지, 왜 그런 방식이 필요한지까지는 잘 몰랐다. 디자인 씽킹과 온톨로지 영상에서는 소크라테스가 이야기한 “너 자신을 알라”에서 시작해, Wonder(궁금해하기) -> Reflect(되비추기) -> Refine(다듬기) -> Restate(다시 말하기) -> Repeat(반복하기)로 이어지는 흐름을 설명했다.
듣다 보니 내가 좋다고 느꼈던 워크플로우가 단순히 프롬프트를 잘 쓰는 방법만은 아니었다는 생각이 들었다. 내가 정말 내 의도를 잘 알고 있는지, 내가 쓰는 단어와 개념의 경계가 충분히 명확한지, 상대방이나 AI가 내 말을 같은 의미로 이해할 수 있는지 확인하는 사고 과정에 가까웠다.
디자인 씽킹이나 더블 다이아몬드도 마찬가지였다. 이름은 들어봤지만, Discover(발견) -> Define(정의) -> Develop(구체화) -> Deliver(전달) 흐름이 문제를 확산하고 수렴하는 사고방식이라는 점은 제대로 이해하지 못했다. 특히 Discover 단계가 단순히 자료를 조사하는 것이 아니라, 내가 무엇을 모르고 있는지 발견하고 불완전한 맥락을 확인하는 과정이라는 설명이 인상 깊었다.
온톨로지도 처음에는 어렵게 느껴졌다. 그런데 단어와 개념의 정의, 경계, 관계를 맞추는 일이라고 생각하니 AI와 대화할 때 왜 맥락을 명확히 해야 하는지가 조금 더 이해됐다. 내가 가진 온톨로지를 AI가 모른다면, AI는 결국 추측할 수밖에 없다. 그리고 그 추측은 때로 내가 기대한 방향과 다른 결과로 이어진다.
가장 크게 와닿았던 건 지식의 4사분면, 그중에서도 unknown unknown에 대한 이야기였다. 내가 모른다는 사실조차 모르고 있는 것들은 혼자서는 발견하기 어렵다. 그런데 AI가 질문을 통해 그런 부분을 끄집어낼 수 있다는 설명을 들었을 때, 그동안 내가 AI와 대화하면서 느꼈던 장면들이 떠올랐다.
unknown unknown을 질문으로 발견하기
제품을 만들다 보면 기능 하나만 따로 존재하는 경우는 거의 없다. 화면에는 여러 액션이 있고, 하나의 액션이 다른 기능의 상태와 연결될 때가 많다. 어떤 버튼을 눌렀을 때 단순히 그 버튼만 동작하는 것이 아니라, 이미 존재하던 다른 기능의 흐름이나 예외 처리와 맞물릴 수도 있다.
이런 관계는 처음부터 모두 보이지 않는다. 특히 기존 코드베이스 위에서 기능을 추가할 때는 더 그렇다. 내가 지금 만지는 화면만 보고 있으면 단순한 작업처럼 보이지만, 실제로는 다른 도메인 로직이나 기존 상태 관리, 이미 만들어진 사용자 흐름과 연결되어 있을 수 있다.
이때 AI가 유용했던 건 단순히 엣지 케이스 목록을 뽑아줘서가 아니었다. 코드베이스를 같이 읽고 나서 “이 부분은 기존의 이 기능과도 연관이 있어 보이는데요. 이 경우는 어떻게 처리할까요?” 같은 질문을 던져줄 때였다.
그런 질문을 받으면 그제야 내가 아직 인식하지 못했던 관계가 보인다. 영상에서 말했던 지식의 4사분면으로 보면, 나에게는 이런 순간이 unknown unknown에 가까운 부분을 발견하는 경험처럼 느껴졌다. 내가 모른다는 사실조차 모르고 있던 관계를, AI가 코드와 맥락을 읽고 질문의 형태로 꺼내주는 것이다.
팀에 공유했다
처음에는 이 내용을 그냥 내 지식 베이스에만 정리해 두었다. 휴가 때 본 영상이었고, 그때는 내가 이해한 내용을 내 언어로 남겨두는 정도였다.
그런데 휴가를 다녀와 회사에 돌아오고 나니, 이 내용을 팀에도 공유해보면 어떨까 하는 생각이 들었다.
나는 AI와 대화하면서 모호한 부분을 먼저 꺼내고, 내가 놓친 관계나 시나리오를 질문으로 받아보는 과정에서 실제로 생산성이 올라간다고 느낀 적이 많았다. 단순히 더 빨리 답을 얻는다는 의미라기보다, 생각이 정리되는 속도와 문제를 바라보는 시야가 달라지는 느낌에 가까웠다.
이런 방식이 나에게만 적용되는 것으로 끝나지 않았으면 했다. 제품은 혼자 만드는 것이 아니고, PO, PM, 디자이너, 개발자가 각자의 관점으로 같은 문제를 바라보며 만들어가기 때문이다. 각자의 자리에서 모호함을 조금 더 잘 다루고, 놓친 질문을 조금 더 잘 발견할 수 있다면, 우리가 만드는 제품의 방향성도 더 선명해질 수 있지 않을까 생각했다.
결국 돌이켜보면, 나는 우리가 좀 더 의미 있는 제품을 만들었으면 했기 때문일지도 모른다.
설치보다 쉬운 프롬프트로
다만 바로 brainstorming이나 deep-interview 같은 스킬을 써보라고 하기에는 허들이 있다고 느꼈다. 개발자들은 새로운 도구를 설치하고 써보는 일에 비교적 익숙하지만, 모두에게 그런 방식이 편한 것은 아니니까.
그래서 처음에는 설치가 필요한 도구보다, 바로 복사해서 첫 대화에 넣을 수 있는 프롬프트 형태로 공유하는 게 낫겠다고 생각했다. 중요한 건 특정 도구를 쓰는 것이 아니라, AI와 대화하면서 모호한 부분을 먼저 드러내고 질문으로 좁혀가는 경험을 해보는 것이라고 생각했기 때문이다.
실제로 공유했던 프롬프트는 아래와 같다.
너는 지금부터 소크라테스식 대화를 통해 내 문제 정의를 도와주는 대화 파트너야.
내가 다음 메시지에서 고민이나 질문을 하나 말할 거야.  
너는 바로 해결책을 제안하지 말고, 아래 흐름으로 나와 대화해줘.
## 1. Wonder / Receive
내가 말한 고민을 판단하지 말고 먼저 받아들여줘.  
무엇을 문제로 보고 있는지, 어떤 전제를 가지고 말하는지 들어줘.
## 2. Reflect
내 고민을 네가 이해한 방식으로 짧게 다시 말해줘.  
내가 "맞아, 그 얘기야"라고 느낄 수 있게 확인해줘.
## 3. Refine / Cross-examine
그다음 내가 놓친 전제, 모호한 표현, 검증되지 않은 가정, 더 먼저 물어야 할 질문을 짚어줘.  
단, 바로 결론을 내리지 말고 질문으로 파고들어줘.
## 4. Restate
대화를 거친 뒤, 문제 정의가 어떻게 바뀌었는지 더 선명한 문장으로 다시 정리해줘.
## 5. Repeat
새로 정리된 문제 정의를 바탕으로 다시 질문을 이어가줘.
## 6. Ambiguity Tracking
대화가 진행되면서 문제 정의의 모호함이 얼마나 줄었는지 가끔 수치로 알려줘.
ambiguity는 0~1 사이로 표현해줘.
- 1은 거의 모든 것이 모호한 상태
- 0은 더 이상 모호함이 거의 없는 상태
단, 매 답변마다 수치를 말하지는 말고, 문제 정의가 크게 좁혀졌거나 내가 요청했을 때만 알려줘.
ambiguity가 약 0.2 이하로 내려왔다고 판단되면, 바로 다음 단계로 넘어가지 말고 나에게 물어봐줘.
예:
> 지금 ambiguity는 약 0.2 정도까지 내려온 것 같아.  
> 여기서 문제 정의를 마무리할까, 아니면 요구사항/설계로 더 진행할까?
## 규칙
- 바로 해결책을 제안하지 마.
- 한 번에 질문은 1~3개만 해줘.
- 답을 길게 설명하지 말고, 내가 다시 생각해서 답할 수 있게 물어봐줘.
- 목표는 정답을 빨리 찾는 것이 아니라, 내가 아직 모르고 있는 전제와 질문을 발견하는 거야.
- ambiguity 수치는 절대적인 값이 아니라, 대화 진행 상태를 확인하기 위한 참고 지표로 사용해줘.
- ambiguity가 충분히 낮아졌다고 판단되면, 문제 정의를 계속 확장하지 말고 종결 여부를 먼저 물어봐줘.
내가 다음 메시지에서 고민을 말하면, 위 흐름으로 대화를 시작해줘.
여담으로, 한 동료분이 장난삼아(?) 공유했던 문서가 너무 길다고 피드백을 주셔서 가볍게 만화로 만들어보는 시도도 해봤다. 😅
공유하기 전에 직접 써보기
팀에 공유할 문서를 정리하면서 프롬프트를 만들고 직접 써보는 과정도 진행했다.
TMI지만, 요즘 AI를 쓰면서 생산성이 높아진 건 분명하다. 다만 그만큼 충분히 검증되지 않은 결과물이 그대로 공유되는 경우도 종종 보게 된다. 막상 문서를 읽어보면 무엇을 설명하려는 건지, 어떤 맥락에서 나온 내용인지 잘 보이지 않는 경우도 있다. 그런 방식은 협업 관점에서 좋은 경험은 아니라고 개인적으로 생각한다.
그래서 내가 팀에 프롬프트를 공유한다면, 적어도 내가 먼저 써보고 어떤 흐름이 나오는지 확인해야 한다고 생각했다. 단순히 “이 프롬프트 좋아요”라고 던지는 것이 아니라, 실제로 사용해 본 예시를 함께 보여주고 싶었다. 그리고 그 예시를 통해 내가 AI를 어떤 방식으로 활용하는지도 간접적으로 보여줄 수 있지 않을까 생각했다.
테스트 주제로는 요즘 관심 있던 “Slack에서 돌아가는 개인 AI 비서”를 골랐다. 여러 Slack 채널과 스레드에서 내 업무와 관련된 중요한 변화나 액션을 놓치지 않도록 도와주는 개인 비서를 만들 수 있을지 궁금했다.
대화를 해보니 문제 정의는 꽤 구체화됐다. 핵심 채널 2~3개에서 시작하고, Jira와 Notion 맥락을 참고하며, 긴급한 내용은 실시간 DM으로 보내고 그 외 내용은 하루 3회 요약하는 식으로 정리됐다.
끝나는 지점을 만들기
다만 대화가 길어지면서 한 가지 아쉬운 점도 보였다. 질문이 이어지는 건 좋았지만, 어느 순간 “이 대화에 끝나는 지점이 있긴 한 건가?” 싶은 생각이 들었다. 지금 문제 정의의 모호함이 얼마나 줄어들었는지도 확인하기 어려웠다. 그래서 ambiguity(모호함 정도)를 0~1 사이의 수치로 표시하고, 약 0.2 이하로 내려가면 문제 정의를 마무리할지 물어보도록 프롬프트를 업데이트했다.
즉, 처음부터 완성된 프롬프트를 만든 것은 아니었고, 직접 써보고, 불편했던 부분이 있으면 수정하고, 그렇게 프롬프트를 손봤던 것 같다.
실제로 테스트해 본 대화는 아래 링크로 남겨두었다.
ChatGPT 공유 대화
마치며
이전에는 AI를 주로 낯선 개념을 빠르게 이해하거나, 키워드만 알고 있던 내용을 공부하는 용도로 자주 사용했다. 그런데 요즘은 거기서 조금 더 나아가, 내가 아직 모른다는 사실조차 모르고 있던 것들을 질문으로 발견하고, 모호한 부분을 clarify 해주는 경험도 중요하다고 느끼고 있다.
내가 던진 질문이 모호하면 AI의 답도 쉽게 뻔해지거나 엉뚱해질 수 있다. 그렇기에 질문을 다듬고, 전제를 확인하며 내가 놓친 부분을 다시 바라보면 문제 자체가 조금 더 선명해진다.
그런 관점에서 제품을 만드는 일도 비슷하다. 바로 해결책으로 넘어가기 전에, 우리가 지금 어떤 문제를 말하고 있는지, 같은 단어를 같은 의미로 쓰고 있는지, 아직 보지 못한 관계는 없는지 확인하는 시간이 필요하다. 그 시간이 당장은 조금 느려 보일 수 있지만, 결과적으로는 더 나은 선택을 하게 도와줄 수 있다고 느꼈다.
이런 과정들이 요즘 나에게는 잘 맞아서, 당분간은 이렇게 사용하지 않을까 싶다.
[짧은 생각] Ouroboros, OMC, OMX는 왜 별도의 상태 관리 머신이 있을까?
OMC는 oh-my-codex, OMX는 oh-my-claudecode를 말한다.
가벼운 내 추측으로는, 계획 모드나 Superpowers의 스킬셋 기반 흐름은 현재 세션의 토큰 컨텍스트에 많이 의존한다. 그래서 대화가 길어지고 컨텍스트가 압축되는 과정에서 문제 정의의 맥락이나, 인터뷰에서 주고받았던 질문과 답변의 일부가 흐려질 가능성이 있지 않을까 싶다.
또한 특정 AI 도구가 제공하는 세션 구조에 대한 의존성을 줄이려는 이유도 있지 않았을까 싶다. 언제 세션 구조나 컨텍스트 처리 방식이 바뀔지 모르는 상황이라면, 중요한 상태를 외부에 두고 이어가는 편이 더 안정적일 수 있겠다는 생각이 들었기 때문이다.
정확히는 모르지만, AI와 문제 정의나 실행 흐름을 여러 턴에 걸쳐 이어가려면 “상태를 어디에 둘 것인가”도 꽤 중요한 질문이 될 수 있겠다는 생각이 들었다.

AI와 함께 내가 놓친 질문을 발견하기

댓글