대상 독자: AI에게 코딩 도움을 받고 있는 사람 / 개인 개발·병행 개발로 정보가 너무 많아져 곤란을 겪고 있는 사람

독서 시간: 약 7분

• AI와 개발하면 코드도 메모도 기사 소재도 엄청난 속도로 늘어난다 - 모든 것을 한 곳(Notion만, Obsidian만, AI만)에 몰아넣으려고 하면 대개 파탄 난다

**「보관 장소를 역할로 나누는 것」**만으로 정보 미아를 상당히 줄일 수 있다

AI와 함께 개발하고 있으면 정보가 엄청난 속도로 늘어납니다.

코드를 작성한다. PR을 만든다. 장애가 발생한다. 관계자에게 설명한다. 기사를 쓴다. 다음 아이디어가 떠오른다──.

PR(Pull Request) = 「이 변경 사항을 프로젝트 본체에 반영해 주세요」라고 요청하는 단위. 코드의 변경을 모아서 확인·기록하는 메커니즘입니다.

정신을 차려보면 docs(문서용 폴더), Notion, 채팅, Git, 로컬 메모가 전부 뒤섞여 버립니다.

저 자신은 여러 개의 git worktree를 사용하여 몇 가지 개발을 병행하여 진행하고 있습니다.

git worktree(워크트리) = 하나의 Git 리포지토리에서 여러 작업 폴더를 동시에 분리해낼 수 있는 메커니즘. 작업(브랜치)마다 폴더를 나눌 수 있으므로 「충돌 없는 병렬 개발」이 가능합니다.

예를 들어, 다음과 같은 단위로 병행하고 있습니다(모두 개인 개발 카테고리의 예시입니다).

• 시험 대비 툴
• 수업용 플랫폼
• 연구·3D 실험장
• 투자·보조금 관련 자료 만들기

이 상태에서 AI에게 개발 도움을 받으면 편리한 한편 「어디에 무엇이 있는지」를 금방 알 수 없게 됩니다.

그래서 저는 정보의 보관 장소를 역할로 나누기로 했습니다.

제 안에서는 이렇게 나누는 것이 가장 이해하기 쉬웠습니다.

중요한 것은 다음 세 가지를 하지 않는 것이었습니다.

• 전부를 Notion에 넣으려고 하지 않는다
• 전부를 Obsidian으로 관리하려고 하지 않는다
• 전부를 AI에게 맡기려고 하지 않는다

각각에 역할을 부여하고, 잘하는 것만 하게 만든다. 이것이 효과적이었습니다.

Notion에는 개발의 지식 허브(Knowledge Hub)와 같은 데이터베이스(DB)를 하나 만듭니다.

여기에 넣는 것은 「나중에 인간이 보고 현재 상황을 파악하고 싶은 정보」입니다.

• 개발 상황
• 완료된 PR
• 장애 기록
• 의사 결정 (왜 그렇게 결정했는가)
• 다음 태스크
• worktree별 상태
• 관련 링크

DB에는 예를 들어 다음과 같은 항목을 갖게 합니다.

Notion이 적합한 것은 「목록으로 보고 싶은 정보」입니다.

「이것은 완료되었는가」 「어느 worktree의 이야기인가」 「장애인가, 단순한 개발 메모인가」 「관련 PR은 무엇인가」 ── 이런 대장(Ledger)적인 관리에 강합니다.

Obsidian에는 현재의 상태가 아니라, 배움이나 생각을 둡니다.

• 왜 그 설계로 했는가
• 장애로부터 무엇을 배웠는가
• 기사로 쓸 수 있을 법한 소재
• 의료 AI·교육 AI에 대한 생각
• 자신의 개발 스타일
• 나중에 다시 사용할 것 같은 지식

Notion이 「대장」이라면, Obsidian은 「자신의 머릿속 지도」입니다.

추천하는 방법은 docs를 전부 Obsidian에 집어넣는 것이 아니라, 중요한 것만 링크하는 것입니다. 처음부터 완벽하게 정리하려고 하면 우선 지속할 수 없습니다.

KnowledgeVault/
10_Projects/ … 프로젝트별 메모
Portfolio.md
...

MOC(Map of Content) = 「콘텐츠의 지도」. 관련 메모로의 링크를 한 페이지에 모아둔 "목차 페이지"를 말합니다.

처음부터 전부를 정리하려고 하지 말고, 우선 MOC_개발전체.md와 같은 지도 한 장을 만드는 것부터 시작하는 것을 추천합니다.

docs는 작업의 원본을 두는 곳입니다.

• 작업 로그
• 설계 메모
• 보고서
• 기사 초안
• 장애 기록
• 인수인계 자료

여기서 중요한 것은, docs를 너무 깔끔하게 만들려고 애쓰지 않는 것입니다.

개발 중에는 정보가 늘어납니다. 다소 거칠더라도, "원본으로서 남아 있다"는 사실 자체에 가치가 있습니다.

단, 나중에 찾을 수 있도록 파일명에 「날짜+내용」을 넣는 것만은 철저히 합니다.

2026-06-13_서버비가 비쌈_폴링(Polling) 쉽게 해설.md
2026-06-07_deploy 장애_복구 기록.md
2026-06-08_route-optimizer 설계 메모.md

이것만으로도 검색성이 상당히 높아집니다.

Git은 코드와 변경 이력을 지키는 장소입니다. 이곳은 AI가 마음대로 건드리지 못하게 하여, 변경 기록(이력)이 반드시 남는 상태를 유지합니다.

"언제·무엇을·왜 바꿨는가"를 나중에 추적할 수 있다는 것 자체가, 병행 개발에서는 커다란 안전장치가 됩니다.

AI에게 맡길 수 있는 일은 해마다 늘어나고 있습니다. 하지만, 인간만이 할 수 있는 일도 분명히 존재합니다.

저는 "어디까지 AI에게 맡길 것인가"를 3단계로 나누어 생각하고 있습니다.

• git status 취득 - worktree별 dirty / ahead / behind 목록화
• 새로운 docs 파일 검출
• API 키로 보이는 문자열 검출
• 빌드 스크립트에 위험한 처리가 포함되어 있지 않은지 체크
• 일간·주간 요약(Summary) 작성
• 완료된 PR 목록화

dirty / ahead / behind = Git의 상태를 나타내는 용어. dirty = 저장되지 않은 변경 사항이 있음, ahead = 로컬이 본체보다 앞서 있음, behind = 본체보다 뒤처져 있음이라는 의미입니다.

포인트는, 자동화해도 좋은 범위는 기본적으로 「보고·분류하고·경고하는 것」까지라는 선을 긋는 것입니다.

• docs를 읽고 요약하기
• Notion DB에 기록할 초안 만들기
• PR 내용으로부터 개발 메모 만들기
• 장애 기록 정리하기
• 기사 초안 만들기
• Obsidian용 태그 제안하기
• "이 부분은 인간의 확인이 필요함"이라고 플래그(Flag) 세우기

이곳은 AI가 잘하는 영역입니다. AI에게 밑작업을 시키고, 인간이 마지막에 확인한다. 이 형태가 가장 안전하고 빠릅니다.

• 무엇을 우선할지 결정하기
• 프로덕션에 공개할지 결정하기
• PR을 머지(Merge)할지 결정하기
• 관계자에게 어떻게 설명할지 결정하기
• 정보의 취급을 판단하기
• 기사로서 공개해도 될지 판단하기
• 실패로부터 다음 규칙 만들기

AI는 안을 낼 수 있습니다. 하지만, 책임 있는 판단은 인간이 해야 합니다. 특히 삭제·공개·전송·머지·DB 변경은 반드시 인간의 확인을 거치는 것이 안전합니다.

저라면 이런 흐름으로 진행합니다.

• 개발한다
• docs에 기록이 쌓인다
• AI가 docs와 Git을 읽는다
• Notion에 「현재 위치」를 정리한다
• Obsidian에 「배움」으로서 정리한다
• 인간이 판단하여 기사·PR·다음 태스크로 만든다

이 흐름으로 해두면, AI 개발로 인해 정보가 늘어나도 길을 잃기 어렵습니다.

AI와 함께 개발하면 작업 속도는 올라갑니다. 하지만, 정보도 그만큼 빠르게 늘어납니다.

그렇기에 정보의 위치를 역할별로 나누는 것이 효과를 발휘합니다.

AI에게 전부 맡기는 것이 아니라, AI에게 정리하게 하고 인간이 판단한다.

이 분담이 개인 개발에서도, 팀 개발에서도 앞으로 점점 더 중요해질 것이라고 생각합니다.

질문·오류 지적·"우리 쪽은 이렇게 하고 있다"라는 사례 공유는 언제든 환영합니다.

임상공학기사 × AI 엔지니어 / 11년간 병원의 의료기기 현장에 계속 머물러 왔습니다. 지금은 AI 엔지니어로도 활동하며, 낙농학원대학의 연구생으로서 논문 박사 취득을 목표로 하고 있습니다. 연구 테마의 주축은 유전자 의료의 미래입니다. 그 바탕 위에서, 의료 현장과 맞닿아 있는 병원의 IT·사이버 보안·의료 AI 도입에 대해서도 현장에서 일어나고 있는 과제와 1차 정보를 대조하며 계속 조사하고 있습니다.

질문·오류 지적·"우리 병원에서는 이렇게 하고 있다"라는 사례 공유는 언제든 환영합니다.

• X: @endoh_taichi
• Qiita: @TaichiEndoh