충동적으로 만든 `.friend/`가 사실은 AI 시대의 `.git/`이었다.

먼저 말해두자면, 이것은 "자작 AI 인터페이스가 대단하다"라는 이야기가 아니다.

오히려 반대다.

처음에는 그저 작업 디렉터리(working directory) 안에 .friend/라는 숨김 디렉터리를 두었을 뿐이었다.

그런데 ChatGPT의 Web UI 변경으로 조금 불편함을 느끼다 보니, 그 무심코 했던 방식이 AI와의 협업 문맥(context)을 프로젝트에 접지(grounding)시키기 위한, 상당히 본질적인 설계가 아니었을까 하는 생각이 들기 시작했다.

요컨대, 이런 이야기다.

충동적으로 만든 .friend/가 사실은 AI 시대의 .git/이었다.

이야기의 시작은 단순한 잡담이었다.

"ChatGPT의 Web UI, 최근에 좀 변했지?"

이전에는 프로젝트가 트리(tree) 구조처럼 보였다.

시선을 이동하며 과거의 스레드(thread)를 찾을 수 있었다.

정확한 이름을 기억하지 못하더라도, 목록을 훑어보다 보면

"아, 이거였지."

하고 찾아낼 수 있었다.

그런데 새로운 UI에서는 먼저 프로젝트를 찾고, 클릭하고, 다시 스레드 목록으로 들어가야 한다.

프로젝트의 정렬 순서도 잘 모르겠다. 변경일도 직관과 맞지 않는다.

검색하면 나오는데, 목록에는 보이지 않는 것도 있다.

검색은 강력하다.

하지만 검색에는 전제가 있다.

찾고 싶은 것을 말로 떠올릴 수 있어야 한다는 것.

실제 작업에서는 그렇게 되지 않는다.

"그 이야기, 어디 있었더라?"
"분명 이 근처에서 논의했는데."
"이름은 잊어버렸지만, 보면 알 수 있어."

이것은 검색이 아니라 재인식(recognition)의 문제이다.

remember → search

가 아니라,

browse → recognize → recover

가 필요해진다.

그리고 이 작은 UI상의 불만으로부터 의외의 이야기가 시작되었다.

여기서 아주 조금만 friend interface에 대해 설명해 두겠다.

friend interface에 대해서는 Qiita의 다른 기사들, 태그 또는 키워드로는 MakingOfFriendInterface 근처에서 구현을 포함하여 다루고 있다.

관심 있는 분은 그쪽도 살펴보길 권하지만, 이 기사에서는 구현의 상세한 내용까지는 들어가지 않는다.

friend interface는 내가 개인용으로 만들고 있는, 약간 장난스러운 이름을 가진 대화형 생성 AI 인터페이스(interface)이다.

거칠게 말하자면, Emacs 상에서 동작하는 로컬 작업 디렉터리 밀착형 AI 파트너이다.

ChatGPT처럼 Web UI 상에서 프로젝트나 스레드를 선택하는 것이 아니라, 지금 열려 있는 작업 디렉터리를 기준으로 AI와의 대화 문맥을 복원한다.

예를 들어, 어떤 프로젝트에는 다음과 같은 .friend/ 디렉터리를 둔다.

project/
├─ src/
├─ docs/
...

여기에는 해당 프로젝트에 관한 AI와의 대화 로그, 요약, 지속적인 설계 메모, 상태 정보 등을 둔다.

한편, 사용자 전체에 공통되는 방침이나 지식은 홈 디렉터리 측의 ~/.friend/에 둔다.

~/.friend/
├─ foundation.md
└─ repository/
...

즉, friend interface에서는 AI와의 문맥을 크게 두 층으로 나누고 있다.

~/.friend/ = 사용자 횡단 방침·지식
project/.friend/ = 프로젝트 고유 대화 문맥

이 메커니즘은 처음부터 거창한 이론에 기반하여 만든 것이 아니다.

Emacs, Eclipse, Unix의 디렉터리 구조, Java의 패키지(package), .git/이나 .vscode/와 같은 프로젝트 로컬 메타 정보 디렉터리.

그러한 과거의 경험으로부터 "뭐, 여기에 두는 게 자연스럽지"라는 감각으로 시작한 것이었다.

그런데 ChatGPT의 Web UI 변경으로 조금 불편함을 느끼다 보니, 이 .friend/ 방식이 생각보다 강력한 설계였다는 것을 깨달았다.

참고로 friend interface 자체의 상세한 내용은 여기서 다루지 않는다.

이 기사에서는 friend의 구현 소개가 아니라, .friend/라는 방식이 가지고 있던 설계상의 의미에 주목한다.

friend에서는 프로젝트 관리의 1차 정보는 Web UI가 아니다.

앞 절에서 언급했듯이, 프로젝트는 파일 시스템 상의 디렉터리이며, AI 문맥은 그 직하의 .friend/에 놓인다.

workspace/
├─ morph-friend/
├─ ot/
...

각 프로젝트에는 각각 .friend/가 있다.

morph-friend/
├─ src/
├─ include/
...

friend에서 작업 문맥 (working context)은 다음과 같이 해결된다.

function resolve_friend_context(current_directory):
    dir = current_directory
    while dir is not filesystem_root:
        ...

즉, 현재의 작업 디렉토리 (working directory)에서 위쪽 방향으로 탐색하여, 가장 가까운 .friend/를 유효한 문맥으로 삼는다.

이것은 특별히 어려운 메커니즘이 아니다.

오히려 Unix 관점에서는 상당히 자연스럽다.

작업 장소가 문맥을 결정한다.

Web UI의 프로젝트 목록이 어떻게 변하더라도, friend에서는 우선 작업 디렉토리로 이동하면 된다.

cd ~/workspace/devel/morph-friend

이 시점에서, 적어도 "어떤 프로젝트인지"는 결정된다.

프로젝트 문맥은 UI 상의 목록이 아니라, 파일 시스템 (file system) 상의 위치와 결합되어 있기 때문이다.

여기서 관점을 바꿔보자.

파일 시스템은 단순한 저장 공간이 아니다.

그것은 계층적인 네임스페이스 (namespace)이다.

filesystem = namespace
directory = context boundary
path = name within context
...

이 관점을 채택하면 .friend/의 의미가 상당히 명확해진다.

project-root/
├─ source/
├─ docs/
...

이것은,

project-root = 프로젝트 문맥의 네임스페이스
.friend/ = 해당 문맥에 부수되는 AI 메타 정보

이다.

Web UI 상의 추상적인 "프로젝트"가 아니라, 실제 작업 대상이 존재하는 위치에 AI와의 협업 문맥을 둔다.

한 문장으로 말하자면 다음과 같다.

AI 문맥은 채팅 UI 안에 있는 것이 아니라, 작업 대상 옆에 둔다.

이 사고방식은 Java의 패키지 (package)와도 조금 닮아 있다.

src/
└─ com/
└─ example/
...

라는 디렉토리 구조가,

package com.example.app;
public class Main {
}

라는 네임스페이스에 대응하듯이, friend에서는,

/path/to/project/.friend/

가 해당 프로젝트의 AI 문맥을 가리킨다.

즉, friend는 AI 대화 문맥에 파일 시스템 상의 주소를 부여하고 있는 것이다.

여기서 그 캐치프레이즈가 등장한다.

충동적으로 만든 .friend/가 사실은 AI 시대의 .git/이었다.

물론 .friend/가 .git/의 대체제는 아니다.

.git/은 결과물의 차분 이력 (diff history)을 관리한다.

.friend/는 AI와의 협업 문맥을 유지한다.

.git = 결과물의 버전 관리
.friend = 협업 문맥의 관리

하지만 구조는 매우 유사하다.

project/
├─ source files
└─ .git/

.git/은 작업 대상 옆에, 그 작업 대상을 복원하고 추적하기 위한 메타 정보를 둔다.

반면,

project/
├─ source files
├─ docs
...

.friend/는 작업 대상 옆에, 그 작업 대상을 AI와 지속적으로 다루기 위한 메타 문맥을 둔다.

대응 관계를 표로 나타내면 다음과 같다.

관점	.git/	.friend/
위치	project root 직하	project root 직하
대상	결과물의 변경 이력	AI 협업 문맥
...	...	...

즉, 이렇게 말할 수 있다.

.git이 결과물의 이력을 프로젝트에 접지(grounding)시킨 것처럼,
.friend는 AI와의 협업 문맥을 프로젝트에 접지시킨다.

여기서 말하는 "AI 시대의 .git/"이란, .git/과 같은 차분 관리 기구를 만들었다는 뜻이 아니다.

.git/이 결과물의 이력을 프로젝트에 거주하게 한 것처럼, .friend/가 AI와의 협업 문맥을 프로젝트에 거주하게 한다는 의미이다.

여기서 이야기가 조금 복잡해진다.

사실 나는 Git파가 아니다.

지금까지 다양한 버전 관리 도구 (Version Control Tool)를 사용해 왔지만, 그리 좋은 기억이 없다.

그래서 명확한 이론적 이유라기보다는 기분의 문제로서, 전통적인 tar파이다.

하지만 이것은 .friend/ 전략과 모순되지 않는다.

오히려 잘 맞아떨어진다.

.friend/의 본질은 Git으로 차분 관리 (Diff Management)를 하는 것이 아니다.

프로젝트 문맥 (Project Context)을 프로젝트와 동일한 네임스페이스 (Namespace)에 두는 것이다.

따라서 저장 방법은 tar여도 상관없다.

tar czf morph-friend-20260521-before-m6.tar.gz morph-friend/

이렇게 하면 다음 내용이 통째로 저장된다.

source/
docs/
tests/
...

즉,

결과물의 상태
설계 문맥의 상태
AI와의 상담 상황
...

이 동일한 시점의 스냅샷 (Snapshot)으로서 고정된다.

.friend/에게 중요한 것은 정밀한 차분 이력이 아니다.

오히려 특정 시점의 문맥으로 돌아갈 수 있는 것이다.

.friend/의 차분을 보고 싶은 것이 아니다.
그 시점의 friend로 돌아갈 수 있으면 된다.

코드는 차분으로 설명할 수 있는 경우가 있다.

하지만 문맥은 종종 시점으로서 복원하고 싶다.

friend의 기본 원칙은 단순하다.

1 project root = 1 project context

프로젝트 루트 (Project Root)는 하나의 프로젝트 문맥의 뿌리이다.
그곳에 여러 개의 독립된 프로젝트를 밀어 넣으면 논리가 깨진다.

bad-root/
├─ .friend/
├─ compiler/
...

이 경우, .friend/가 어떤 문맥인지 알 수 없다.

올바른 구조는 다음과 같다.

workspace/
├─ compiler/
│ └─ .friend/
...

여러 프로젝트를 포함하는 상위 디렉토리는 프로젝트 루트가 아니다.
그것은 워크스페이스 루트 (Workspace Root)이다.

workspace root = 여러 프로젝트를 포함할 수 있는 작업 공간
project root = 1개의 프로젝트 문맥의 뿌리
friend root = .friend/를 가진 문맥의 뿌리

단, 중첩된 (Nested) friend root는 존재할 수 있다.

project/
├─ .friend/
├─ subproject1/
...

이것은 모순이 아니다.

project/ = 1 project context
project/subproject1/ = 1 project context
project/subproject2/ = 1 project context
...

중첩된 여러 개의 project root가 있을 뿐이다.

이때 유효 문맥 (Active Context)은 가장 가까운 .friend/로 한다.

function active_context(path):
return nearest_ancestor_containing(".friend/", from = path)

상위 문맥을 하위 문맥에 자동으로 혼입하지 않는다.
필요한 경우에만 명시적으로 참조한다.

default = current context only

이것은 문맥의 단일 책임 원칙 (Single Responsibility Principle)이다.

friend에는 또 하나의 중요한 분리가 있다.

~/.friend/
project/.friend/

project/.friend/는 해당 프로젝트 고유의 문맥이다.

project/.friend/
├─ ai-interaction.log
├─ ai-interaction.memory.md
...

반면, ~/.friend/는 사용자 전반에 걸친 문맥이다.

~/.friend/
├─ foundation.md
└─ repository/
...

이것은 다음과 같은 계층을 만든다.

global principle
↓
shared repository knowledge
...

한국어로 말하자면,

보편적인 방침
재사용 가능한 지식
프로젝트 고유의 판단
...

이다.

이 분리는 나중에 돌아보니 매우 컸다.

처음에는 그저 자연스러운 위치로서,

~/.friend/
project/.friend/

를 제안했을 뿐이었다.

하지만 결과적으로는, 사용자 전체의 지식과 프로젝트 고유의 문맥 (Context)을 분리하는 상당히 강력한 이층 구조가 되었다.

장대한 계획은 없었다.

하지만 과거의 Eclipse, Emacs, Unix, Java package, .git/, .vscode/ 등의 경험이 수면 아래에서 설계 감각으로서 작용하고 있었을지도 모른다.

여기서 소박한 의문이 생긴다.

만약 .friend/ 형식이 그토록 자연스럽다면, 왜 상용 AI 시스템에서는 전면적으로 채택되지 않고 있는가?

기술적인 이유도 있다.

하지만 큰 이유는 아마도 비즈니스 및 운영상의 이유일 것이다.

상용 AI 서비스에서 문맥은 서비스 가치의 핵심이다.

- 지속 이용의 이유
- 개인화 (Personalization)의 원천
- 검색·추천·자동화의 재료
...

사용자 관점에서 문맥은 자신의 자산이다.

user:
context is my working asset

반면, 벤더 (Vendor) 관점에서 문맥은 서비스 가치의 핵심이다.

vendor:
context is part of the product moat

이러한 긴장이 존재한다.

friend 형식은 문맥의 정본 (Source of truth)을 로컬 파일 시스템에 둔다.

cloud AI = 추론 서비스
.friend/ = 문맥 자산

이는 사용자 주권 및 로컬 퍼스트 (Local-first) 측면에서는 강력하다.

하지만 클라우드 서비스 주권과는 긴장 관계에 있다.

물론 클라우드를 부정하는 것은 아니다.

클라우드 AI를 추론 서비스로 사용하는 것과 프로젝트 문맥의 정본을 로컬에 두는 것은 양립 가능하다.

문제는 문맥을 누가 소유하며, 어디에 정본을 두느냐 하는 것이다.

여기까지 쓰면 friend 형식은 꽤 좋은 메커니즘처럼 보인다.

하지만 당연하게도 만인을 위한 것은 아니다.

가장 큰 이유는 아마도 보안이나 비즈니스 모델이 아니라, 그보다 더 앞단에 있는 문제일 것이다.

Unix적인 파일 시스템 문화에 익숙하지 않은 사람에게는 애초에 자연스럽게 보이지 않는다.

나에게는,

project/
├─ src/
├─ docs/
...

라는 구조가 상당히 자연스럽다.

.git/, .vscode/, .emacs.d/, ~/.config/, Java의 패키지 디렉토리, Eclipse의 workspace/project 구조.

이러한 것들에 익숙하다면, "프로젝트의 메타 정보를 숨김 디렉토리 (Hidden directory)에 둔다"는 발상은 거의 설명이 필요 없을 정도다.

하지만 그렇지 않은 사람에게는 다르다.

왜 점(.)으로 시작하는 디렉토리가 있는가
왜 보이지 않는 곳에 중요한 정보를 두는가
왜 ChatGPT 화면이 아니라 파일 안에 문맥이 있는가
...

라는 이야기가 된다.

즉, friend 형식은 로컬 퍼스트이며 투명성이 높은 설계인 동시에, Unix적·IDE적·개발자적인 전제 지식에 상당히 의존하고 있다.

이 점이 약점이다.

그렇다면 friend 형식이 더 넓은 사용자층에게 받아들여지려면 무엇이 필요할까?

이하는 상당히 독단적이고 편향된 견해이다.

먼저, 일반 사용자에게 .friend/를 직접 만지게 해서는 안 된다.

내부적으로는 파일 시스템에 접지(Grounding)되어 있어도 좋다.

하지만 UI 상에서는 다음과 같이 보이는 것이 좋다.

이 프로젝트의 AI 문맥
이 프로젝트의 작업 메모
이 프로젝트의 이력
...

.friend/는 구현 상세(Implementation detail)이며, 사용자에게는 "프로젝트에 부속된 AI 노트"로 보여야 한다.

개발자라면 project root라는 용어로 통하지만, 일반 사용자에게는 통하지 않는다.

따라서 friend가 만인을 위한 것이 되려면,

이 폴더가 작업 공간이군요
이 문서군을 하나의 프로젝트로 취급하겠습니다
이 노트군에 AI 문맥을 추가하겠습니다

라는 자동 판정과 확인 UI가 필요해진다.

.friend/가 파일로서 존재하는 것만으로는 부족하다.

사용자는 과거의 문맥을 찾고 싶어 한다.

그러기 위해서는,

최근의 작업
미완료된 논점
결정된 설계 판단
...

을 볼 수 있는 형태로 목록화할 수 있어야 한다.

즉, friend 형식이라 하더라도 최종적으로는 UI가 필요하다.

단, 그 UI는 문맥의 정본이 아니라, 로컬 문맥을 보기 쉽게 만드는 뷰 (View)여야 한다.

.friend/는 프로젝트의 기밀 경계 (Confidential boundary)를 계승한다.

이는 설계 원칙으로서 훌륭하다.

하지만 대중화하기 위해서는 사용자가 이를 이해하지 못하더라도 사고가 발생하기 어려운 구조여야 한다.

예를 들어,

이 프로젝트는 클라우드 동기화 중입니다
.friend/ 도 동기화 대상입니다
이 폴더는 공유되었습니다
...

와 같은 경고가 필요할 것이다.

나아가, 공개 또는 공유 전에는,

.friend/ に 会話ログ (대화 로그)가 포함되어 있습니다
private memory (개인 메모리)가 포함되어 있습니다
state file (상태 파일)이 포함되어 있습니다
...

와 같은 확인 절차가 있어도 좋을 것이다.

friend형의 본질은 Git이 아니다.

물론 tar도 아니다.

본질은,

AI 문맥 (Context)을 작업 대상의 바로 옆에 두는 것

이다.

따라서 저장 방법은 선택할 수 있는 것이 좋다.

스냅샷 저장
Git 연동
zip 출력
...

어느 것이든 상관없다.

사용자의 작업 문화에 맞출 수 있는 것이 중요하다.

대중화를 목표로 한다면, AI와의 이력을 단순한 채팅 로그 (Chat log)로 보여주지 않는 편이 좋다.

오히려,

결정 사항
미결 사항
다음 작업
...

와 같이 보여주어야 한다.

채팅은 흘러간다.

문맥은 남긴다.

이 사상을 UI로 표현할 수 있다면, friend형은 상당히 넓은 사용자층에게 도달할 수 있을지도 모른다.

현시점의 friend형은 솔직히 말해 전문가용이다.

파일 시스템을 네임스페이스 (Namespace)로 볼 수 있는 사람, 프로젝트 루트 (Project root)를 의식할 수 있는 사람, 숨김 디렉터리에 거부감이 없는 사람, 로컬 파일의 소유권과 책임을 어느 정도 감당할 수 있는 사람에게는 매우 강력하다.

반면, 모든 것을 Web UI 상에서 완결짓고 싶은 사람에게는 상당히 무겁다.

따라서 friend형을 대중화하기 위해서는, 내부 구조는 .friend/ 그대로 두더라도, 외부에는 상당히 친절한 UI와 안전장치가 필요하다.

내부 구조는 Unix 스타일로.
외부 경험은 비(非) Unix 사용자도 이해할 수 있도록.

이것이 아마도 friend형을 확산시키기 위한 조건일 것이다.

.friend/에는 밀도 높은 정보가 들어간다.

- AI와의 상담 이력
- 설계 판단
- 다음 작업
...

때문에 보안에 주의가 필요하다.

하지만 .friend/만이 특별히 위험한 것은 아니다.

프로젝트에는 애초에 기밀 정보가 포함될 수 있다.

project/
├─ src/
├─ docs/
...

소스 코드, 논문, 연구 노트, 데이터, 설계 문서.

이것들과 .friend/의 기밀도 사이에 정말로 큰 차이가 있는가?

많은 경우, 그 답은 불분명하다.

따라서 .friend/만을 별도로 취급하기보다, 프로젝트 루트 전체를 동일한 기밀 경계 (Confidential boundary)로 다루는 것이 자연스럽다.

.friend/ 는 해당 project root의 기밀 경계를 계승한다.

고기밀 프로젝트라면 .friend/뿐만 아니라 프로젝트 전체를 격리해야 한다.

- 네트워크 연결을 배제한다
- 클라우드 AI로 내용을 보내지 않는다
- 클라우드 동기화를 사용하지 않는다
...

반대로, 프로젝트 본체를 private cloud나 private backup에 두어도 된다면, .friend/만을 과도하게 특별 대우할 필요는 없다.

.friend/는 프로젝트 외부의 비밀 상자가 아니다.

프로젝트 문맥에 부수되는 메타 문맥 (Meta-context)이다.

friend형의 설계 원칙을 의사 코드 (Pseudo-specification)로 정리하면 다음과 같다.

type FriendContext = {
root: Directory
memory: MarkdownFile
...

보안 경계는 다음과 같이 다룬다.

function confidentiality_boundary(friend_context):
return project_boundary(friend_context.root.parent)
function may_share(friend_context, target):
...

즉,

.friend/ 의 공유 가능 여부는 원칙적으로 project root의 공유 가능 여부를 따른다.

중첩 문맥은 다음과 같이 다룬다.

function active_context(path):
return nearest_friend_context(path)
function parent_context(path):
...

단, 기본 설정으로는 부모 문맥을 혼합하지 않는다.

default = 현재 문맥만 사용

AI 채팅은 언뜻 보면 대화이다.

하지만 개발, 연구, 문서 작성에 사용하기 시작하면, 그것은 단순한 대화가 아니게 된다.

그곳에는,

- 무엇을 결정했는가
- 왜 그렇게 했는가
- 무엇을 시도했는가
...

이 포함된다.

그것은 작업 자산이다.

기존의 채팅 UI는 대화를 스레드 (thread) 단위로 관리한다.

하지만 장기 작업에 있어 본질적인 단위는 스레드가 아니다.

conversation thread = 이벤트 (event)
project context = 지속 가능한 작업 기억 (durable working memory)

채팅은 이벤트이다.

프로젝트 문맥 (project context)은 지속된다.

따라서 friend는 문맥을 스레드가 아니라 작업 디렉터리에 둔다.

대화는 흘러간다.
문맥은 작업 디렉터리에 남긴다.

처음부터 거창한 계획이 있었던 것은 아니다.

.friend/

와 ~/.friend/

는 Eclipse나 Emacs, Unix적인 실무 감각에서, 왠지 모르게 자연스러운 위치로서 나오게 되었다.

프로젝트 고유의 문맥은 프로젝트 바로 아래에.

사용자 횡단 문맥은 홈 디렉터리에.

단지, 그뿐이었다.

하지만 나중에 보면, 그것은 상당히 강력한 설계였다.

파일 시스템을 1차 네임스페이스 (primary namespace)로 삼는다.
AI 문맥을 작업 대상 옆에 둔다.
하나의 루트는 하나의 문맥을 나타낸다.
...

.friend/

는 처음부터 거창한 계획으로서 설계된 것이 아니었다.

단지, 작업 대상 옆에 AI 문맥을 두는 것이 자연스럽다고 생각했을 뿐이었다.

하지만 나중에 보면, 그것은 파일 시스템을 네임스페이스 (namespace)로 삼고, 프로젝트 루트를 문맥 경계로 하며, AI와의 협업 이력을 작업 장소에 접지 (grounding)시키는 설계였다.

.git/

이 결과물의 이력을 프로젝트에 거주하게 한 것처럼.

.friend/

는 AI와의 협업 문맥을 프로젝트에 거주하게 한다.

충동적으로 만든 .friend/

가 사실은 AI 시대의 .git/

이었다.

다만, 나는 tar파이다.