
제가 rhwp collaborator로 3개월간 기여하며 직접 경험한 AI 협업 방법론을 정리한 글입니다. 바이브 코딩에서는 잘 동작하던 AI가 기존 프로젝트나 회사 코드베이스에 적용되면 어려움을 겪는 이유를, 단순한 모델 성능보다 ‘축적된 프로젝트 맥락의 부재’라는 관점에서 살펴봅니…
1. 왜 AI 코딩 세션은 매번 처음부터인가
바이브 코딩 환경에서 Claude Code나 Cursor 같은 AI 어시스턴트는 매 세션마다 새로운 컨텍스트를 받습니다. 이전 세션에서 어떤 결정을 내렸고, 왜 그 라이브러리를 선택했는지, 어떤 함정을 피했는지를 모릅니다. 데모 앱을 5분 만에 만들 수 있어도 회사 코드베이스에 적용하면 즉시 무너지는 이유가 여기에 있습니다.
이 문제를 "모델 성능 부족"으로 돌리면 해결이 안 됩니다. 실제로는 모델이 충분한 정보를 받았음에도 "축적된 프로젝트 맥락의 부재"라는 구조적 한계에 부딪히는 것입니다. rhwp(Hyper-Web-Wiki 기반 협업 도구)는 이 빈자리를 채우기 위해 설계됐습니다.
2. rhwp가 제안하는 프로젝트 기억 구조

rhwp의 핵심은 Hyper-Web-Wiki 포맷입니다. 단순한 마크다운 문서가 아니라 노드 간 양방향 링크로 연결된 위키 그래프입니다. rhwp collaborator는 3개월간 이 포맷으로 AI 협업을 하면서 다음 세 가지 핵심 원칙을 발견했습니다.
첫째, 결정의 이유를 노드로 남겨야 합니다. "왜 이 라이브러리를 선택했나"가 곧 다음 세션의 첫 번째 프롬프트가 됩니다. 둘째, 실패 사례도 명시적으로 기록합니다. 같은 실수를 반복하지 않으려면 "X 시도 → Y 실패 → Z 대안" 패턴이 wiki에 박혀 있어야 합니다. 셋째, 컨벤션은 자동화 가능한 형태로 표현합니다. "명명 규칙" 같은 추상적 문장보다 구체적 lint rule이나 snippet이 효과적입니다.
3. 실전 적용 — rhwp collaborator 3개월 사례로 본 4가지 패턴
패턴 1: 결정 로그 노드 (Decision Log)
큰 결정이 내려질 때마다 별도 노드를 만들고 이유·대안·트레이드오프를 기록합니다. 다음 세션에서 "왜 React Query를 선택했나"라는 질문이 들어오면 wiki에서 해당 노드를 찾아 컨텍스트로 주입합니다.
패턴 2: 실패 카탈로그 (Failure Catalog)
"이 접근은 시도하지 말 것" 명시. 5번 시도한 끝에 안 된 패턴을 정리해 두면 AI가 같은 함정을 파지 않습니다. 단순한 코멘트가 아니라 자체 노드로 분리해 링크를 겁니다.
패턴 3: 컨벤션 스니펫 (Convention Snippet)
린트 규칙을 그대로 코드 스니펫으로 박아둡니다. "함수 길이 50줄 이하" 같은 추상 규칙보다 실제 .eslintrc 블록을 wiki에 넣고, AI가 패턴을 그대로 따라하게 만듭니다.
패턴 4: 의도 그래프 (Intent Graph)
각 모듈의 "왜 존재하는가"를 노드화. 신규 세션에서 새 모듈 추가 요청이 들어오면 의도 그래프와 비교해 중복·충돌을 즉시 감지합니다.
4. 코드 스니펫 — rhwp 노드 템플릿 예시
# Node: decision-2026-07-react-query
Context
대시보드 페이지 데이터 페칭 표준화 필요
Options Considered
- SWR: 가벼움, 캐시 단순
- TanStack Query: 복잡하지만 강력, 서버 상태 최적화
Decision
TanStack Query 선택
Reasoning
- 서버 상태가 페이지당 5종류 이상
- 무효화(refetch) 정책이 명시적
- mutation 후 자동 invalidate 패턴 필요
Tradeoffs
- 번들 사이즈 12KB 증가
- 학습 곡선 존재
Date
2026-07-22
5. 실용 팁 — 오늘부터 적용하기
rhwp를 처음부터 다 구축할 필요는 없습니다. 다음 순서로 시작하세요.
- 첫 주: "결정 로그" 노드만 만들기. 이번 주 큰 결정 3개만 기록.
- 둘째 주: "실패 카탈로그" 시작. 같은 실수 1번이라도 했으면 노드 추가.
- 셋째 주: 컨벤션 스니펫 wiki에 박기.
- 넷째 주: 의도 그래프 — 모듈 5개만이라도 노드로 분리.
한 달이면 50~80개 노드가 쌓이고, 그때부터 AI 세션 품질이 비약적으로 올라갑니다. 모델을 바꾸는 것보다 효과가 큽니다.
6. 전망 — 프로젝트 기억은 곧 AI 컨텍스트 창이다
rhwp 사례는 AI 협업의 미래 방향을 보여줍니다. 모델 자체가 좋아져도 프로젝트 맥락이 없으면 진짜 도움이 안 됩니다. 앞으로 등장할 모든 AI 코딩 도구는 결국 "프로젝트 기억"이라는 그래프를 어떻게 관리하느냐로 차별화될 것입니다. 지금 wiki를 구축하는 개발자가 6개월 후 가장 큰 수확을 거둡니다.
요약
- AI 코딩의 진짜 병목은 모델 성능이 아니라 축적된 프로젝트 맥락의 부재
- rhwp(Hyper-Web-Wiki)는 4가지 패턴으로 이 문제를 해결 — 결정 로그, 실패 카탈로그, 컨벤션 스니펫, 의도 그래프
- 3개월 협업으로 검증된 실전 방법론 — 한 달간 점진 도입 권장
- 모델보다 프로젝트 기억이 향후 AI 협업의 핵심 차별화 요소
📰 원본 출처 · https://news.hada.io/topic?id=31684 (#N=31684)
이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.
'AI 뉴스' 카테고리의 다른 글
| 판사, Claude 훈련용 불법 복제 도서 관련 Anthropic의 2.3조원 합의 승인 — AI 학습 데이터 저작권 판례의 의미 (0) | 2026.07.23 |
|---|---|
| AI 시대에 번영할 사람들 — volition이 지능을 대체하는 시대, 개발자가 살아남는 법 (0) | 2026.07.22 |
| Kimi K3와 Fable 5의 작업별 라우팅 — 두 모델의 조합이 단일 최고 모델을 넘어서는 순간 (0) | 2026.07.22 |
| AI 시대의 데이터 관리 — 개발자가 놓치기 쉬운 7가지 실전 원칙 (0) | 2026.07.22 |
| 안목은 위임할 수 없다 — AI 시대, 위원회식 디자인의 종말 (0) | 2026.07.22 |