혼자서 Web 개발 회사를 경영하고 있습니다. PM으로서 여러 프로젝트를 병행하면서, 직접 설계와 구현도 합니다.

AI를 코딩에 사용하는 사람은 많겠지만, 저는 최근 AI에게 '나의 분신'을 만들게 하는 것에서 가장 높은 시간 대비 효율을 느끼고 있습니다. 이 기사에서는 그 메커니즘 — 저는 이를 '제2의 뇌 (second brain)'라고 부릅니다 — 을 만드는 방법을, 실제로 사용 중인 파일 구성과 프롬프트(Prompt)와 함께 소개합니다.

AI는 우수하지만, 매번 기억 상실

AI 어시스턴트(저는 Claude Code를 사용하고 있습니다)는 코드를 쓸 줄 알고 문장도 잘 씁니다. 하지만 새로운 세션(Session)을 열 때마다, 저에 대해 아무것도 모르는 상태에서 시작합니다.

• "우리 회사는 검증을 생략하지 않는 방침이다"라고 매번 말함
• "고객용 문장은 답변을 회피하지 않는 방식으로 써달라"고 매번 수정함
• "그건 전에도 거절했던 안이야"라고 매번 거절함

즉, **AI의 능력이 아니라, AI에게 전달하는 '나의 정보'가 병목(Bottleneck)**인 것입니다. 이를 깨달은 후부터 판단 기준, 업무 방식, 문체 등을 전부 파일로 작성하여 AI가 읽게 만들었습니다.

메커니즘: 판단 기준을 Markdown 리포지토리로 만들기

거창한 도구는 사용하지 않습니다. 그저 Markdown 파일을 git 리포지토리(Repository)에 넣을 뿐입니다. 저의 구성은 다음과 같습니다.

second-brain/
├── README.md # 이 리포지토리의 읽는 법
├── identity/ # 인물 그 자체
...

포인트는 3개 층으로 나누는 것입니다.

• identity — 장기간 변하지 않는 '나의 성질'. 판단의 원칙, 취향, 강점과 약점
• playbooks — 상황별 '이럴 때는 이렇게 한다'. 리뷰 관점, 문장의 틀
• projects — 변화가 빠른 프로젝트 정보. 여기만 빈번하게 업데이트

AI에게는 서두에 identity/core.md를 반드시 읽게 하고, 나머지는 태스크(Task)에 따라 필요한 파일만 열게 합니다. 전부 읽게 하면 컨텍스트(Context) 낭비이므로, README에 "어떤 태스크일 때 어떤 파일을 읽어야 하는가"에 대한 절차를 적어두는 것이 요령입니다.

core.md는 '인물 소개'가 아니라 '설정 파일'로서 작성한다

처음에는 core.md를 자기소개처럼 작성했더니 AI의 움직임이 별로 변하지 않았습니다. 효과가 있었던 것은, AI를 위한 지시 사항으로 다시 작성한 것입니다.

Before (인물 설명):

저는 신중한 성격이며 품질을 중시합니다.

After (행동 지시):

수습 가능한 일은 속도 우선. 수습 불가능한 일은 품질 우선.

당신(AI)의 구현 방법:

• 제안 시에는 "이것이 수습 가능한가"를 덧붙일 것
• 가역적인 태스크는 확인을 기다리지 않고 진행해도 좋다. 불가역적인 단계 직전에는 반드시 멈출 것
• 검증 및 테스트 생략은 절대로 제안하지 말 것

이 형식으로 바꾼 뒤부터 AI 제안의 질이 눈에 띄게 달라졌습니다. "이렇게 움직여 주길 바란다"를 그대로 동작 사양으로 작성합니다. 인물의 묘사가 아니라, 부트로더(Bootloader, 부팅 시 읽히는 설정)라고 생각하고 작성하는 것이 가장 잘 전달됩니다.

만드는 법: AI에게 나를 인터뷰하게 하기

"자신의 판단 기준을 작성하라"고 해도 스스로는 의외로 잘 쓰지 못합니다. 저는 AI에게 인터뷰어를 맡겼습니다. 실제로 사용한 프롬프트의 골자입니다.

당신은 나의 "제2의 뇌"를 만들기 위한 인터뷰어입니다.
목적: 나의 판단 기준, 업무 방식을 끌어내어 AI가 재현할 수 있는 형태로 문서화하는 것.
규칙:
...

이를 몇 번 반복하면 스스로도 언어화하지 못했던 행동 원리가 나옵니다. 저의 경우 "판단의 축은 결국 전부 수습 가능한가 아닌가였다"라는 발견을 했고, 이것이 core.md의 중심이 되었습니다.

운용: 쓰고 끝내지 않는 메커니즘

만들고 만족해서 방치하면 의미가 없으므로, 운용 규칙을 딱 3가지만 정해두었습니다.

• 세션 종료 시 "수확"하기 — 그날 AI와 주고받은 내용 중 새로운 판단, 정정, 좋았던 문구가 있다면 해당 파일에 대한 추가 제안을 AI에게 시킨다. 채택 여부는 자신이 결정한다.
• identity와 playbooks는 AI가 마음대로 고치게 하지 않기 — 추가 제안을 제시하는 것까지가 AI의 일이다. 반영은 인간의 승인제를 따른다. 이 부분을 자동화하면 어느샌가 "AI가 만든 나"가 되어버린다.
• 신선도를 frontmatter에 적기 — 각 파일에 updated: 날짜를 넣어, 오래된 파일은 "오래되었을 가능성이 있음"이라고 AI 측에 명시하게 한다.

그리고 실무상 중요한 점은, 고객명이나 안건의 기밀은 _confidential/ 디렉토리에 분리하여 AI가 읽는 범위를 제어하는 것입니다. 분신 만들기(identity building)와 정보 관리는 세트입니다.

효과: 무엇이 바뀌었는가

운영을 시작한 지 얼마 되지 않았지만, 이미 체감 효과가 큰 것은 다음 세 가지입니다.

• 지시가 짧아졌다 — "그 방식대로 리뷰해줘"라고만 해도, 자신의 리뷰 관점이 반영된 리뷰가 돌아온다.
• 아웃풋의 재작업(rework)이 줄었다 — 고객용 문서 초안이 처음부터 "내가 쓸 법한 문장"으로 나온다.
• 자신의 사고 습관이 보였다 — 문서화 과정 그 자체가 가장 훌륭한 자기 분석이 되었다.

반대로, 아직 구현하지 못한 것은 "문체 스타일의 완전한 재현"입니다. 판단 기준보다 문체 쪽에 암묵지(tacit knowledge)가 더 많이 포함되어 있어, 실제 사례를 모아 검증 중입니다. 이 부분은 이어지는 기사에서 다루겠습니다.

당장 오늘 시작한다면

• 리포지토리(repository)를 만들고 identity/core.md 파일을 딱 하나만 둔다.
• AI에게 위의 인터뷰 프롬프트를 전달하여 30분 동안 대화한다.
• 도출된 추가 제안들을 직접 편집하여 확정한다.

첫 번째 파일이 만들어진 시점에서 이미 AI의 움직임은 변하기 시작합니다. 완벽한 구성을 목표로 하기보다, 단 하나의 원칙이라도 "부트로더(bootloader) 형식"으로 작성해 보세요.

Discussion