AI와의 설계 판단을 My-Skill-Graph에 기록하여 재사용하는 방법
요약
AI와의 대화 로그에서 발생하는 설계 판단 정보를 개인 지식 베이스인 My-Skill-Graph에 효율적으로 기록하고 재사용하는 방법을 제안합니다. 단순한 대화 저장 대신 '왜 그런 선택을 했는가'에 집중하여 판단을 압축하고, 이를 기술적 전략(strategies)으로 확장하여 지식의 가치를 높이는 워크플로우를 다룹니다.
핵심 포인트
- 대화 로그 전체를 저장하는 대신 재사용 가능한 '판단(decisions)' 단위로 정보를 압축하여 기록해야 함
- 기록 시 명사형 제목 대신 '왜 선택했는가'를 포함한 명제문 형태의 제목을 사용하여 맥락을 보존함
- 설계 판단을 기록할 때 채택한 기술뿐만 아니라 그 결정의 이유와 대안(alternatives)을 함께 남겨야 함
- 기술적 판단을 코드 문맥에 가두지 않고 외부로 확장 가능한 '전략(strategies)'으로 관리하여 커리어 및 콘텐츠 제작에 활용함
서론
Codex나 Claude Code를 사용하면 구현이나 기사 작성 속도가 올라갑니다. 짧은 작업이라면 대화 속에서만 완결되어도 큰 문제는 없습니다.
반면, 며칠 뒤에 같은 테마로 돌아오면 다른 문제가 발생합니다.
'지난번에 왜 그런 설계를 했는가?', '어떤 대안을 버렸는가?', '그 판단을 다음 기사나 포트폴리오 설명에 사용할 수 있는가?'와 같은 정보들이 대화 로그 속에 파묻혀 버립니다.
그래서 로컬의 Obsidian Vault에서 운용하고 있는 개인용 지식 베이스인 My-Skill-Graph에 AI와의 작업에서 발생한 설계 판단을 남기기로 했습니다.
이 기사에서는 Zenn 기사 관리 리포지토리인 harness17/zenn-articles에서의 운용을 예로 들어, 대화 로그를 그대로 저장하는 것이 아니라 나중에 재사용할 수 있는 판단 기록으로 압축하는 방법을 기술합니다.
대화 로그에서 판단만 찾아내는 것은 무거웠다
AI와의 대화 로그에는 상당히 많은 정보가 남습니다.
시도한 안, 버린 안, 커맨드(Command) 출력, 중간 과정의 문장, 리뷰에서 나온 지적 사항 등. 작업 과정을 되돌아보기에는 편리합니다. 하지만 나중에 사용하고 싶은 정보는 대화 전체가 아닙니다.
예를 들어, 기사 후보를 생각한 뒤에 다시 보고 싶은 정보는 다음과 같습니다.
- 무엇을 기사 후보로 삼았는가
- 왜 그 후보를 우선했는가
- 무엇과 중복되어 피했는가
- 다음에 어떤 관점으로 쓸 것인가
설계에서도 마찬가지입니다.
"Entity를 직접 View에 전달할 것인가, ViewModel을 분리할 것인가", "외부 API를 매번 호출할 것인가, RSS와 캐시를 조합할 것인가"와 같은 판단은 작업 시점에는 대화의 흐름 속에서 결정됩니다. 하지만 훗날 같은 종류의 판단을 다시 할 때, 대화 로그에서 이유를 다시 찾는 것은 시간이 걸렸습니다.
따라서 대화 로그를 저장하는 것 자체가 아니라, 판단을 재사용할 수 있는 단위로 추출하기로 했습니다.
decisions에는 '무엇을 선택했는가'가 아니라 '왜 선택했는가'를 둔다
My-Skill-Graph에서는 설계 판단을 decisions/에 남기고 있습니다.
여기서 의식하고 있는 점은 제목을 명사로 만들지 않는 것입니다.
예를 들어, ViewModel에 대하여라는 제목은 나중에 검색 결과에 나와도 내용을 알 수 없습니다. 대신 다음과 같이 명제문으로 만듭니다.
---
description: "화면 전용 입력 상태를 Entity에서 분리하여, Controller와 View의 책임을 읽기 쉽게 만드는 판단."
alternatives: "Entity를 직접 View로 전달 / 입력용 DTO를 별도로 생성"
...
이렇게 하면 본문을 열기 전에 판단의 방향을 알 수 있습니다.
중요한 것은 채택한 기술명만 남기지 않는 것입니다. ViewModel을 사용함만으로는 다음 판단에 활용하기 어렵습니다. 화면 편의성을 Entity에 섞지 않기 위해까지 포함해 두면, 다른 화면을 만들 때도 비교 축으로 사용할 수 있습니다.
AI에게 구현을 요청할 때도 이러한 입도의 판단이 남아 있으면 재사용하기 쉬워집니다.
"이 프로젝트에서는 입력 폼의 화면 편의성은 ViewModel에 맞춘다"라는 판단을 전제로 전달할 수 있기 때문입니다. 매번 대화 속에서 같은 설계 방침을 다시 설명할 필요가 없습니다.
strategies에는 기술 판단을 어떻게 활용할지를 둔다
설계 판단은 그대로 두면 코드의 문맥에 갇히게 됩니다.
하지만 개인 개발에서는 설계 판단이 기사, OSS, 직무 경력서, 면접에서의 설명 자료로 이어지는 경우가 있습니다. 그래서 기술 판단에서 외부로 끌어낼 수 있는 가치는 strategies/에 남기고 있습니다.
예를 들어, 이 기사 자체도 처음에는 "AI와의 작업 로그를 어떻게 남길 것인가"라는 이야기였습니다. 하지만 동일 시리즈에서 인접한 "AI 2대의 크로스 리뷰 (Cross-review) 운용" 기사와 중복되기 쉬운 관점이었습니다.
그래서 다음과 같이 다시 잡았습니다.
---
description: "AI와의 대화에 파묻힌 설계 판단을 재사용 가능한 형태로 만들면, 기사 테마와 포트폴리오 설명 양쪽 모두에 사용할 수 있다.
opportunity_type: product
...
이 메모에 남기고 있는 것은 기사 본문이 아닙니다.
"이 기사를 무엇을 위해 쓰는가", "어떤 인접 테마와 구분할 것인가"라는 판단입니다. 이를 남겨두면 다른 날에 다음 내용을 쓸 때도, AI에게 의뢰할 때도 관점이 흔들리지 않게 됩니다.
특히 Zenn 기사에서는 비슷한 테마가 늘어나기 쉽습니다.
이번에도 AI 간의 크로스 리뷰 운용과 설계 판단을 재사용하는 운용...
가까운 위치에 있습니다. 전자는 리뷰 품질 (Review Quality), 후자는 판단의 저장과 재사용입니다. 이 경계를 전략 메모 (Strategic Memo)로서 남김으로써, 기사들 사이의 역할을 나눌 수 있었습니다.
기록하는 조건을 정하지 않으면 지속할 수 없다
처음부터 전부를 기록하려고 하면 운용이 무거워집니다.
반면, 마음이 내킬 때만 기록하면 중요한 판단일수록 바쁜 타이밍에 놓치게 됩니다. 그래서 기록하는 조건을 좁혔습니다.
현재의 운용에서는 주로 다음과 같은 때만 남깁니다.
- 대안을 비교하여 설계 판단 (Design Decision)을 했다
- 새로운 라이브러리 (Library), 패턴 (Pattern), 연계 방법을 채택했다
- 기술 작업에서 기사, OSS, 구직에 사용할 수 있는 시사점이 나왔다
- 다음에 할 일이나 작업 스레드 (Thread)가 바뀌었다
반대로, 단순한 파일 읽기, 가벼운 문구 수정, 포맷 (Format)만 변경, git 조작만으로는 남기지 않습니다.
이러한 선긋기를 통해 My-Skill-Graph를 작업 일지로 너무 과하게 만들지 않도록 하고 있습니다. 남기고 싶은 것은 모든 행동이 아니라, 나중에 설명하고 싶은 판단입니다.
Zenn 기사 리포지토리 (Repository)에서도 마찬가지입니다. 오타를 고친 것뿐이라면 남기지 않습니다. 기사의 관점을 「도구 소개」에서 「판단의 재사용」으로 바꿨다면 남깁니다. 후자는 다음 기사 구성에도, 공개 전 리뷰에도 사용할 판단이기 때문입니다.
기사 후보를 찾을 때 판단 메모가 효과적이었다
이 운용을 시작한 이후로, 기사 후보를 찾는 방식이 조금 변했습니다.
이전에는 기사를 쓰려고 할 때 「무엇을 쓸 수 있을까」를 그 자리에서 생각했습니다. 지금은 과거의 판단 기록에서 찾습니다.
보고 있는 것은 다음과 같은 메모입니다.
- 무언가에 막혔던 기록
- 대안을 비교한 기록
- 나중에 후회한 설계
- 다른 용도로도 쓸 수 있을 법한 운용 개선
이러한 방식으로 찾으면 체험 기사로 만들기 쉬운 후보를 발견할 수 있습니다.
예를 들어, YouTube Data API의 쿼터 (Quota) 대책은 「API를 사용했다」는 이야기가 아니라, 「매번 API를 호출하는 설계로는 일일 쿼터를 견딜 수 없었기에, RSS와 캐시 (Cache)를 조합했다」는 판단으로서 기사로 쓸 수 있습니다.
ASP.NET Core MVC의 ViewModel 분할도 「ViewModel 설명」이 아니라, 「화면 편의를 Entity에 섞지 않기 위해 나누었다」는 판단으로서 쓸 수 있습니다.
AI와의 작업 로그도 마찬가지입니다. 단순히 「Obsidian에 저장하고 있습니다」라고만 하면, 단독으로는 체험 기사로서의 고유성이 드러나기 어렵습니다. 이번처럼 「대화 로그에서 판단만을 추출하여, 다음 기사나 구현에 재사용한다」라고 설정하면 체험 기사로서 쓰기 쉬워집니다.
크로스 리뷰 기사와는 역할을 분리한다
가까운 테마로, Codex와 Claude Code를 크로스 리뷰 (Cross Review)하게 하는 운용이 있습니다.
그것은 작성자와 리뷰어를 분리함으로써 사실 오인, 기밀 유지 리스크 (Confidentiality Risk), AI 특유의 맺음말을 검출하는 이야기입니다. 중심은 리뷰 품질입니다.
이 기사의 중심은 리뷰가 아닙니다.
리뷰 전후에 발생한 판단을 대화 밖으로 꺼내어 재사용하는 것입니다.
예를 들어, 크로스 리뷰를 통해 「이 표현은 기밀 유지 리스크가 있다」는 것을 알았다고 가정해 봅시다. 그 자리에서 고치기만 한다면 리뷰 결과입니다. 하지만 「향후 업무 도메인 유래의 enum 명은 기사용 범용 명칭으로 대체한다」라고 남긴다면, 다음 기사에도 쓸 수 있는 판단이 됩니다.
이 차이를 의식하면 두 기사는 중복되지 않습니다.
- 크로스 리뷰 운용: 다른 AI로 무엇을 검출할 수 있었는가
- 설계 판단 메모 운용: 검출이나 구현으로부터 생겨난 판단을 어떻게 재사용할 것인가
이번 기사에서는 후자만을 다룹니다.
요약
AI와의 작업에서는 대화 로그를 남기는 것만으로는 나중에 사용하기 어렵다고 느꼈습니다.
그래서 My-Skill-Graph에 decisions/와 strategies/를 만들어, 설계 판단과 기사·포트폴리오로의 연결을 나누어 남기도록 했습니다.
효과를 본 점은 다음 3가지입니다.
- 제목을 명제문으로 만들어, 판단의 내용을 검색 결과만으로 알 수 있게 한다
- 기술적 판단과, 그것을 기사나 구직에 사용하는 전략을 분리한다
- 모든 것을 기록하지 않고, 나중에 설명하고 싶은 판단만을 남긴다
AI를 사용하여 작업을 빠르게 진행하는 것이 목적이라면 대화 로그만으로도 충분합니다. 며칠 후, 다른 작업이나 기사에 판단을 전달하고 싶다면 대화 밖으로 판단을 남기는 메커니즘이 필요했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기