소설보다 압도적으로 만화파인 사람, 시바이누 하나코입니다. 텍스트로만 된 계획서, 솔직히 힘들지 않나요?

"결국 무엇이 바뀌는가?"를 한눈에 알 수 있게 하고 싶어서, Claude에게 계획을 낼 때마다 도표를 그리게 해보았습니다. 잘 되지 않았던 부분까지 포함하여, 시도한 것·작성한 규칙·결과를 그대로 나열합니다.

시도한 것: "계획을 세울 때마다 도표도 그려줘"라고 요청. 작성 방식에 대한 세부적인 판단은 Claude에게 맡겼다.

작성한 내용 (MEMORY.md)

구현 계획·작업 계획을 제시할 때는 문장뿐만 아니라 반드시 Mermaid 도표도 작성한다
- 절차가 적고 단순한 계획은 채팅창 내에 그대로 삽입한다
- 파일 수가 많거나 의존 관계가 복잡한 계획은 Artifact로서 별도로 공유한다
...

결과: 도표가 나오지 않았다. 원인은 "메모리 요약" 자체는 읽고 있었지만, 상세 파일을 열어서 확인하는 공정을 생략했기 때문. 정보가 없었던 것이 아니라, 확인하지 않았던 것이다.

시도한 것: 다른 작업(마스코트 앱을 아이콘 클릭만으로 실행할 수 있도록 하는 계획)을 의뢰.

나온 도표

결과: 정확하지만 알기 어렵다. .app 내부 구성이라는 구현 상세 부분이라, 알고 싶었던 "애초에 무엇이 바뀌는가"가 전달되지 않는다.

작성한 내용 (MEMORY.md에 추가)

계획 제시 시의 Mermaid 도표는 내부의 구현 상세(파일 구성·기술적인 내부 구조 등)가 아니라,
"전체적으로 무엇이 바뀌는가"를 한눈에 파악할 수 있는 도표(예: 현상 → 변경 후의 비교, 대략적인 흐름)를
가장 먼저 배치한다. 구현 상세 도표가 필요한 경우에는 전체상 도표와 별도로 상세 섹션에 보충 자료로 덧붙인다

나온 도표

결과: 원하던 도표. "현상"과 "변경 후"를 나란히 두는 것만으로, 무엇이 바뀌는지 한눈에 알 수 있게 되었다.

시도한 것: "본질은 도표를 붙이는 것이 아니라, 5초 만에 변화를 알 수 있게 하는 것"임을 깨닫고, CLAUDE.md에 규칙을 추가.

작성한 내용 (CLAUDE.md)

## 계획 제시 시의 도표 작성법
- 첫 번째 도표에서는 파일명보다 "사용자 입장에서의 변화"를 작성한다
- 기술명(프레임워크명 등)은 써도 좋지만, 반드시 "무엇을 담당하는지"도 함께 적는다
...

결과: 도표의 역할 분담을 4종류로 정리. "전체상", "이용 기술·담당 영역", "책임 분담", "관계·흐름"으로 나누어, 그대로 사용할 수 있는 계획 템플릿으로 만들었다.

시도한 것: 테스트 소재(매일 19:00에 새가 화면 가장자리에서 나타나 "슬슬 돌아가!!" "쿠에에에에!!!"라고 재촉하는 앱)로 계획서를 작성하게 했다.

발생한 일: 채팅 본문에 Mermaid를 삽입했을 때 도표로 렌더링되지 않는 환경이었다. 코드 블록이 그대로 텍스트로 표시되었다.

작성한 내용 (MEMORY.md 수정)

채팅 본문에 삽입했을 때 렌더링되지 않는 환경이 있으므로,
간단한 경우라도 도표는 Artifact로 발행한다

결과: 완성된 전체상 도표

책임 도표·구현 방침 비교표도 함께 제시되어, "어떤 일이 일어나는 앱인가"를 먼저 이해한 뒤 구현안을 비교할 수 있는 구성이 되었다.

• 첫 번째 도표는 구현 절차가 아니라 "변화의 요약"으로 한다
• 규칙은 한 번 만들고 끝내는 것이 아니라, 나온 도표를 보고 수정한다
• "간단하면 채팅창 내 삽입으로 OK"는 환경에 따라 다르다. 실제로 렌더링되는지 확인한다

글자로 읽으면 머리에 잘 들어오지 않는 분들은 꼭 한번 시도해 보세요.