서론

필자는 AI 에이전트에게 조금 복잡한 작업을 맡기는 일이 늘었습니다. 그때 자주 사용하는 방식이, 먼저 계획(Plan)을 세우게 한 뒤 착수하게 하는 방법입니다. 갑자기 손을 움직이게 하는 것보다, 단계를 먼저 내놓게 하는 것이 누락을 줄이고 결과를 안정시킵니다.

예를 들어 Anthropic의 Claude Code(커맨드 라인 등에서 코드를 다룰 수 있는 에이전트 환경)에는 plan 모드라는 기능이 있습니다. 파일을 변경하지 않고, 먼저 조사와 계획 수립만 하게 한 뒤, 사용자가 계획을 승인하면 실행으로 옮기는 모드입니다 (공식: https://code.claude.com/docs/en/plan-mode ). plan 모드뿐만 아니라, 생성형 AI 전반에서 "먼저 단계를 내놓아줘"라고 부탁한 뒤 실행하게 하는 진행 방식은 널리 사용되고 있습니다.

다만, 계획을 세워도 그 계획대로 실행이 진행된다는 보장은 없습니다. 아무리 정성스럽게 단계를 짜더라도, 실제로 해봐야 비로소 알 수 있는 것이 있기 때문입니다. 이는 많은 사람이 경험하고 있듯이, 계획은 반드시 현실과 어긋납니다. 중요한 것은, 어긋났을 때 대책을 추가하며 계속 나아갈 수 있는 메커니즘이 있느냐 하는 것입니다.

이 기사에서 제창하고 싶은 것은, 계획을 세우고 끝내는 것이 아니라, "이슈 트리(Issue Tree)"라는 사고방식으로 과제를 관리하면서, 실행 과정에서 새로운 대책을 계속해서 추가해 나가는 방식입니다. 어디까지나 사고방식의 제창이며, 구현의 세부 절차는 가볍게만 다루겠습니다.

【제창】 이슈 트리로 과제를 키워가며 해결하기

필자가 말하는 "이슈 트리"는 다음과 같은 사고방식입니다 (이는 공식 기능의 이름이 아니라, 필자가 현장에서 사용하기 위해 붙인 명칭입니다).

과제를 가지가 갈라지는 나무(Tree)로 보유한다. 단, 처음에 완벽한 나무를 만들려고 하지 않는다. 대책을 착수 전에 전부 열거하는 것은 불가능하므로, 나무는 "지금 파악된 범위" 내에서 그리기 시작하고, 진행하면서 깨달은 새로운 대책을 가지로서 추가해 나간다. 이것이 가장 중요한 포인트입니다. 나무는 고정된 계획이 아니라, 실행과 함께 성장해 가는 지도입니다.

그리고 각 가지에 현재 상태를 기록합니다. 필자는 다음 상태를 사용하고 있습니다.

✅ 검증 완료 (실측): 실제로 시도하고, 측정하여, 결과를 확인한 가지.

△ 전망 (미실측): "아마 이걸로 동작할 것이다/이게 유효할 것 같다"라고는 알고 있지만, 아직 실제로 측정하지는 않은 가지.

❓ 미검증: 아직 시도하지 않은 가지. 앞으로 착수할 후보.

❌ 불가능 (확정): 시도한 결과, 불가능하다고 확정된 가지. 단, 후술하는 바와 같이 여기에 분류하려면 무거운 증거가 필요합니다.

여기에 더해, "이 방향을 얼마나 시도했는가"라는 실마리의 기록도 남깁니다. "이 안은 몇 일에 시도했으나 빗나갔다"와 같은 메모입니다.

나아가, 이를 세션(Session)을 넘나들며 관리하게 합니다. AI와의 대화는 도중에 끊깁니다 (길어져서 요약되거나, 다음 날 재개되기도 합니다). 그때마다 나무가 사라지면, 다시 똑같은 곳을 더듬더듬 찾아야 합니다. 따라서 나무는 대화 외부에 남겨두어, 다음 세션에서도 다시 읽어들일 수 있도록 합니다.

도식화하겠습니다. 여기서는 특정 작업에 국한되지 않는 일반적인 형태로 보여줍니다. 목표(Goal)로부터 역산하여 가지를 나열하고 있는 것이 포인트입니다.

이 그림은 사고방식을 보여주기 위한 일반적인 예시입니다. 실제 가지를 나누는 방식이나 수는 다루는 과제에 따라 달라집니다. 나무의 형태 그 자체보다, 각 가지에 상태가 붙어 있고, 그것이 남아서 성장해 나가는 것이 핵심입니다.

여기까지가 골격이지만, 실제로 운용해 보니 나무를 "편리한 할 일 목록(To-do list)"으로 사용하는 것만으로는 부족했습니다. 나무를 신뢰할 수 있는 도구로 만들기 위해서는 몇 가지 규율이 필요합니다. 효과적이라고 느낀 순서대로 나열하겠습니다.

【최중요】 가지를 닫는 것(❌)에는, 나아가는 것보다 무거운 증거가 필요하다

4가지 상태는 대등하지 않습니다. ❌(불가능)으로 분류하는 것을 가장 엄격하게 다루어야 합니다.

이유는, 이 상태야말로 "탐색을 중단했을 뿐인데, '애초에 없다'라고 말을 바꾸는" 게으름의 도피처가 될 수 있기 때문입니다. "몇 번 시도했지만 안 됐다, 그러니 이 가지는 안 해도 된다"── 이것은 위험합니다. 몇 번의 실패는 불가능하다는 증명이 아니라, 단순한 탐색의 중단에 불과합니다. 아직 시도하지 않은 길이 남아있을지도 모르는데 "없다"라고 해버리면, 거기서 진짜 해답을 놓치게 됩니다.

따라서 필자는 가지를 ❌로 처리할 때는, 적대적 리뷰 (Adversarial Review)(일부러 반대 입장에서 "정말로 불가능한가, 놓친 길은 없는가"라고 엄격하게 파고드는 검증)를 거쳐, 이제는 정말로 이 가지는 불가능하다고 단언할 수 있는 지점까지 몰아붙이도록 하고 있습니다. 구체적으로는, 열 수 있는 가능성이 있는 길을 (가까운 2~3개가 아니라) 전부 나열했는지, 각각에 실제 측정 결과가 있는지, 시도하지 않은 길은 이유를 명확히 적었는지, 그리고 "없다"라고 단언하기 전에 코드 전체를 검색하여 해당 사항이 하나도 없음을 확인했는지── 이러한 점들을 채워 넣어 반론의 여지가 없어졌을 때 비로소 ❌로 만듭니다.

바꿔 말하면, 가지를 닫는 것(진행할 수 없다고 확정하는 것)은 가지를 진행시키는 것(움직였다고 확정하는 것)보다 더 신중해야 하며, 더 많은 증거를 요구한다는 뜻입니다. 부정을 확정하는 것이 긍정을 확정하는 것보다 더 무겁습니다. 이것이 이슈 트리 (Issue Tree)의 가장 중요한 성질이라고 생각합니다. 트리는 "할 일을 나열하는 도구"인 이상, 안이한 중단을 증거로 묶어두는 도구입니다.

이와 관련하여 한 가지 더. 툴이 내뱉는 "도달 불가능", "이 이상은 무리"와 같은 라벨도 그대로 믿지 않도록 하고 있습니다. 그것은 정적 분석 툴의 "의심"일 뿐, 확정된 사실이 아닙니다. 스스로 반증할 수 있는지 확인하기 전까지는 가지의 라벨로서 덥석 받아들이지 않겠다는 자세입니다.

✅는 "측정했다"일 뿐 ― "아마 될 것이다"를 섞지 않는다

다음에 효과적인 것은, ✅(실측)와 △(예상)를 명확히 구분하는 것입니다.

가짜 진척이 발생하는 가장 큰 원인은, "아마 될 것이다"를 "되었다"에 섞어버리는 것입니다. AI에게 부하 역할의 에이전트를 사용하게 하는 경우, 그 "했습니다"라는 보고도 독립적으로 다시 측정하기 전까지는 ✅로 만들지 않습니다. 예상은 예상대로 △에 두고, 실제로 측정하여 확인된 것만을 ✅로 올립니다.

이 선을 하나 긋는 것만으로 트리의 신뢰성이 크게 달라집니다. "트리상으로는 8할이 ✅인데, 실제로는 대부분이 예상이었다"라는 사고를 방지할 수 있기 때문입니다. 참고로, 이 "탐색적인 개선(예상)과 검증된 개선(실측)을 구별한다"는 발상은 나중에 다룰 학술 연구 (Arbor)에서도 핵심으로 다루어지고 있습니다.

트리는 "완료의 정의" ― 횟수로 멈추지 않는다

세 번째는, 트리를 "끝났는지 여부를 판정하는 용도"로 사용하는 것입니다.

"몇 번 시도했는데 진전이 없으니 종료"라는 방식으로는 멈추지 않습니다. 대신, 트리의 모든 잎(Leaf)이 ✅이거나 증거가 있는 ❌가 될 때까지, 그 과제는 끝나지 않았다고 규정합니다. ❓(미검증)인 잎이 하나라도 남아 있다면 아직 끝난 것이 아닙니다.

트리를 할 일의 보조 리스트가 아니라, 완료의 정의 그 자체로 사용하는 것입니다. 이렇게 하면 "어느 정도 손이 멈췄으니 완료로 하자"라는 식의 처리가 불가능해집니다.

결정한 가지를 뒤집지 않는다 ― 트리는 "안정기"이기도 하다

네 번째는, 한번 확정한 가지를 기분에 따라 다시 꺼내지 않는 것입니다.

✅ 또는 ❌로 만든 가지를 다시 논의 대상으로 되돌리는 것은, 그것을 뒤집을 구체적인 측정 결과를 한 줄로 쓸 수 있을 때만 합니다. 쓸 수 없다면 다시 꺼내지 않습니다.

의외일 수도 있지만, 확정된 가지를 기분에 따라 다시 여는 것은 같은 작업을 반복하는 것보다 해롭습니다. "끝났어야 할 일이 다시 미확정 상태로 돌아간다"고 하면 전체가 불안정해져서 언제까지나 수렴하지 않습니다. 트리는 앞으로 나아가기 위한 지도인 동시에, 결정한 것을 번복하지 않기 위한 안정기이기도 하다는 관점입니다.

골드 역산 방식이라, 표의 숫자가 움직이지 않는 주간에도 전진이 보인다

마지막으로, 트리를 골드(Goal)로부터 역산하여 만드는 효과입니다.

트리를 "원인이 어디인가"라는 진단의 분해로서 만들면, 상황에 따라 눈에 보이는 성과(표면적인 숫자)가 움직이지 않는 기간이 지속되어, 진행되고 있는지 멈춰 있는지 알 수 없게 됩니다. 그래서 골드와의 차이를 셀 수 있는 형태로 만들고, 거기서부터 가지를 나열합니다.

이렇게 하면, 표의 숫자가 움직이지 않는 주간에도 진척이 보입니다. ❓가 ✅가 되면 전진이고, ❓가 (증거가 있는) ❌가 되어도 "막다른 길이 하나 확정되었다 = 골드에 한 걸음 다가갔다"라고 셀 수 있기 때문입니다. 손이 멈춘 것이 아니라, 지도가 확실히 채워지고 있다는 것을 알 수 있습니다. 이는 실무에서 상당히 효과적입니다.

이 사고방식은 AI에게 시키기에 타당한가

"단순한 생각 아닐까"라고 생각하실 수도 있기에 근거를 제시합니다. 이슈 트리를 구성하는 요소들은 각각 연구나 공식 자료를 통해 효과가 입증되었습니다.

첫 번째: 나무(Tree)로 탐색하고 각 가지의 전망을 평가하는 것은 효과적이다. "Tree of Thoughts (사고의 나무)"라는 연구(arXiv:2305.10601, NeurIPS 2023)는 AI의 사고를 나무 형태로 유지하며, 각 가지에 "전망 있음·없어 보임·불가능"과 같은 평가를 붙여가며 탐색하게 하는 기법입니다. 논문에 따르면, "24 만들기"라는 숫자 퍼즐에서 단계별로 생각하게 하는 기존 방식의 정답률이 4%였던 것에 비해, 나무 형태로 탐색하게 하면 74%까지 올라갔다고 보고되었습니다. 가지에 상태를 부여하여 탐색한다는 이슈 트리(Issue Tree)의 골격은 여기서 그 유효성이 입증되었습니다.

두 번째: 상태를 대화 외부에 두는 것은 공식적으로도 권장된다. Anthropic의 공식 아티클 "Effective context engineering for AI agents"는 작업 정보를 대화 속에만 담아두지 말고, 노트나 스크래치패드(Scratchpad)로서 대화 외부에 써서 남겨둘 것을 권장합니다. 대화가 길어지면 정보가 묻히거나 손실될 수 있으므로, 외부에 꺼내 두자는 생각입니다. 이슈 트리를 외부 파일로 관리하는 것은 이와 같은 발상입니다.

세 번째: 유사한 생각은 학술 연구에도 이미 존재한다. 솔직히 말씀드리면, 이것은 필자만의 발상이 아닙니다. 2026년 6월에 공개된 "Arbor"라는 연구(arXiv:2606.11926)는 가설과 그 검증 결과를 나무 형태로 가지며, 세션을 넘나들며 계속 유지하는 에이전트를 제안합니다. "탐색적인 개선"과 "검증된 개선"을 구분하고(즉, 앞서 언급한 △와 ✅의 구분과 같습니다), 유망한 가지를 선택하고, 안 되는 가지는 접어버려 "같은 막다른 길을 반복해서 시도하는 것을 피한다"라고 기술하고 있습니다. 이슈 트리의 발상과 거의 동일합니다. 차이점은 Arbor가 영어 학술 연구이며, 머신러닝 (Machine Learning) 연구 자동화라는 특정 분야를 향하고 있다는 점입니다. 이 글은 그 생각을 "이슈 트리"라는 일상적인 프레임으로 가져와, 더 넓은 문제 해결에 가벼운 운용 방식으로 사용할 수 있게 하고자 하는 위치에 있습니다.

다만, 만능은 아닙니다

솔직하게 한계도 적겠습니다. "나무로 상태를 관리하게 하면 반드시 좋아진다"는 아닙니다.

어떤 연구(CP-Agent, arXiv:2508.07468)에서는 AI에게 할 일 목록을 관리하는 도구를 갖게 했더니, 일부 어려운 문제에서는 오히려 성공률이 떨어졌다는 결과가 보고되었습니다. 관리 자체가 부담이 되어 해답을 찾는 것을 방해할 수 있다는 뜻입니다.

여기서 말할 수 있는 것은, 이슈 트리는 가볍게 유지해야 한다는 것입니다. 너무 세세하게 관리하면 관리가 목적이 되어버립니다. 필자의 감각으로도 이 생각이 효과적인 것은 "어느 정도 손이 가는 과제"이며, 몇 단계 만에 끝나는 작업에는 오히려 방해가 됩니다. 사용처를 선택한다는 전제로 받아들여 주시기 바랍니다.

또 하나, 실무적인 팁을 드리자면, 난관이 있는 한 지점을 끊임없이 두드리지 마십시오. 하나의 가지에서 막히면 거기에 집착하지 말고, 독립된 다른 나무(다른 과제)를 병행해서 돌립니다. 같은 지점을 뱅뱅 도는 상태를 방지하는 구조적인 대책이 됩니다.

어떻게 관리하면 좋을까 (가볍게 언급하는 정도)

이 글은 사고방식의 제창이 주된 목적이므로, 구현은 "이런 것으로 관리하면 된다"는 정도로만 남겨두겠습니다.

거창한 메커니즘은 필요 없습니다. 대화 외부에 나무의 상태를 적은 파일을 하나 두는 것만으로도 시작할 수 있습니다. 과제마다 가지와 상태를 적어두고, AI에게 "작업할 때마다 이것을 읽고, 업데이트한 뒤에 진행해줘"라고 부탁하는 형태입니다. Claude Code를 사용하고 있다면, 이러한 지시를 CLAUDE.md

(프로젝트의 규칙을 적어두면 각 세션 시작 시 읽어들이는 파일. 공식: https://code.claude.com/docs/en/memory )에 적어두는 방법도 있습니다.

파일 업데이트는 기본적으로 AI 스스로 하게 합니다. 다만 한 가지 주의할 점이 있습니다. **"목록 전체를 새로 쓰게 하는(덮어쓰게 하는) 운용은 반드시 어긋난다"**는 것입니다. AI에게 매번 백지 상태에서 새로 쓰게 하면, 이전 기록을 놓치거나 실제 상황과 다른 상태로 바꿔버릴 수 있기 때문입니다. 사람이 직접 고치든 AI에게 고치게 하든, 덮어쓰기 방식인 한 같은 문제가 발생합니다.

따라서 AI에게는 추기 (append-only, 과거의 기록은 지우지 않고 아래에 계속 덧붙이는 방식)로 작성하게 하는 것을 추천합니다. "이 가지를 ✅로 표시했다・이 가지를 ❌로 확정했다"라는 사건을 한 줄씩 추가해 나가게 하고, 현재 상태가 어떤지에 대한 목록표는 그 추기 기록으로부터 별도로 자동 생성하게 만드는 것입니다. 이렇게 하면 확정된 기록이 나중에 다시 쓰이지 않으므로 상태가 어긋날 가능성이 낮아집니다.

요점은, 상태를 대화 속에만 두지 않는 것, 그리고 덮어쓰기로 관리하게 하지 않고 추기 기록을 정본(source of truth)으로 삼는 것입니다. 구조는 가벼우면 가벼울수록 좋으며, 우선 파일 한 장부터 시도해 보시는 것을 추천합니다.

마치며

계획은 실행해 보면 반드시 현실과 어긋납니다. 어긋나는 것 자체는 문제가 아닙니다. 어긋났을 때 대처 방안을 추가하며 계속 나아갈 수 있는 그릇이 없다는 것이 문제였습니다.

그래서 제창한 것이 이슈 트리 (Issue Tree)라는 사고방식입니다. 처음에 완벽한 나무를 만들려고 하지 말고, 지금 알 수 있는 범위 내에서 그린 뒤 진행 과정에서 새로운 가지를 추가하며 키워나가는 것입니다. 각 가지에는 "실측・예상・미검증・불가능 (확정)" 상태를 부여하고, 세션(session)을 넘나들며 남겨둡니다.

그 바탕에는 나무를 신뢰할 수 있는 도구로 만드는 규율이 있었습니다. 가지를 닫을 (❌) 때는 적대적 리뷰 (adversarial review)를 통해 절대 불가능하다고 단언할 수 있을 때까지 파고들 것. ✅에는 실측 데이터만을 넣고 예상치와 섞지 말 것. 나무를 완료의 정의로 사용하고, 횟수로 제한하지 말 것. 결정된 가지를 기분에 따라 번복하지 말 것. 그리고 골(goal)에서 역산하여, 표의 숫자가 움직이지 않는 주간이라도 전진이 보이도록 할 것.

나무로 탐색하는 것의 유효성도, 상태를 외부에 남기는 것의 타당성도 연구나 공식 자료를 통해 뒷받침되고 있습니다. 유사한 사고방식은 학술 연구에도 이미 존재합니다. 한편으로는 너무 과하게 관리하면 역효과가 나는 한계도 있습니다. 그렇기에 가볍게 유지하는 것입니다.

반복해서 말씀드리지만, 이것은 공식 기능이 아니라 한 실천가의 사고방식입니다. 계획을 세우는 것으로 끝내지 않고, 실행을 어떻게 마지막까지 추적할 것인가. 그 하나의 유형으로서, 본인에게 맞을 것 같은 부분만 시도해 보시기 바랍니다.

참고

• Claude Code plan 모드 (공식): https://code.claude.com/docs/en/plan-mode
• Claude Code 메모리 / CLAUDE.md (공식): https://code.claude.com/docs/en/memory
• Effective context engineering for AI agents (Anthropic 공식): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Tree of Thoughts (arXiv:2305.10601): https://arxiv.org/abs/2305.10601
• Arbor: Hypothesis-Tree Refinement (arXiv:2606.11926): https://arxiv.org/abs/2606.11926
• CP-Agent (태스크 관리가 역효과를 낼 수 있는 사례, arXiv:2508.07468): https://arxiv.org/abs/2508.07468

Discussion