丰容(풍용)은 원래 동물원에서 쓰던 말이에요. 사육하는 동물이 야생에서 하던 행동을 할 수 있도록 우리 안에 자극을 넣어주는 겁니다. 영어로는 environmental enrichment, 한국어로는 행동풍부화라고 해요.
예를 들면 먹이를 그냥 주지 않고 숨겨 둡니다. 바닥 재질을 바꾸기도 하고, 냄새를 뿌려두기도 해요.
중국에서는 이 말을 사람한테 쓰기 시작했어요. 「人类丰容(인류풍용)」입니다.
똑같은 하루를 보내던 사람이 스스로에게 자극을 넣는다는 뜻이에요.
여우상회라는 이름을 정했어요. AI 말투를 없애려고 써 둔 문서부터 AI 말투였다는 것도 알게 됐고요.
01배경 › 저장소하고 있는 일과 도구
요즘 AI를 붙들고 서비스를 여러 개 만들어 내놓고 있어요. 하나를 오래 다듬기보다는 떠오르는 걸 죄다
만들어 뿌려 보는 쪽입니다. 그중 뭐가 살아남는지 보고 싶어서요. 이 블로그에는 그 과정을 적습니다.
작업은 저장소 한 곳에서 해요. 코드 옆에는 위키를 두는데, 여기가 조금 특이합니다. 결정한 것과
그날 한 일을 전부 문서로 쌓아 둬요. 새 작업을 시작하면 AI가 그걸 먼저 읽습니다. 사람 기억력을
믿지 않겠다는 뜻이에요. 그날 한 일은 log.md 한 파일에 시간순으로 쌓이고요. 이 글도 거기서 나왔습니다.
작업 창은 두 개 띄워서 서로 다른 서비스를 굴려요. 이날은 한쪽에서 서비스를 만들고 다른 쪽에서는
블로그를 만졌습니다. 쌓인 건 스물두 건. 그중 판단이 갈렸던 자리만 골라 왔어요.
02서비스 › 여우상회출시 기준과 범위 확정
왜
만들 것은 정해뒀는데 언제 손을 놓을지가 없었어요. 하루에 결정 네 건과 커밋 열 개가 나와도
출시가 얼마나 가까워졌는지 셀 방법이 없었습니다.
해결
「하루 한 바퀴가 끊기지 않고 돈다」라는 한 줄을 문 여는 기준으로 삼았어요.
방법
완성의 정의를 표로 만들었어요. 그 표가 다 차는 날을 출시일로 못박았습니다. 범위를 40% 줄이자는
안도 함께 나왔지만 접었어요.
여우상회는 지금 만들고 있는 서비스예요. 매일 셋만 진열하고, 값은 「해본 것」으로 치릅니다. 하나를
골라 실제로 해낸 뒤 인증하면 물건이 생겨요. 그 물건으로 자기 방을 채웁니다.
제가 물었습니다. "1차 오픈 가능한 스펙 정의를 했으면 해. 어느정도까지 오픈을 할거냐.
디벨롭이 끝도없을거같아서."
엿새 전에 「무엇을 만드는가」는 적어뒀어요. 「언제 그만 만드는가」는 없었습니다. 요건 목록이 알아서
끝날 리는 없으니 끝선을 한 줄로 그었어요. 셋 중 하나 고르기, 실제로 하기, 인증하기, 물건 받기,
방에 놓기, 올리기. 이 흐름이 끊기지 않으면 문을 엽니다. 표가 다 차는 날이 출시일이에요. 그전에는
열지 않고, 그 뒤에는 더 다듬지 않기로 했습니다.
막상 세어 보니 그동안 적어둔 숫자도 틀렸어요. 퀘스트 문안이 42개라고 돼 있었는데 실제로는
39개였습니다. 어림으로 적으면 이렇게 어긋나네요. 앞으로는 표에 넣고 직접 센 숫자만 적기로 했어요.
테크트리, 40%의 추가 비용
테크트리는 어떤 걸 해내면 다음 단계가 열리는 구조예요. AI는 이걸 2차로 미루자고 제안했습니다.
미루면 문안 78개가 60개로 줄고, 그림도 78종에서 60종이 돼요. 남은 일이 40% 줄어든다는 계산까지 나왔습니다.
그래도 넣기로 했어요. 빼고 나면 첫 주에 다시 오게 만드는 장치가 「만료」 하나뿐입니다. 만료는 등을
떠미는 힘이고, 모으는 재미는 끌어당기는 힘이에요. 떠미는 힘만 남으면 결국 재촉하는 서비스가 됩니다.
애초에 피하기로 해둔 모습이었어요.
40%를 더 치르기로 한 이유도 결정 기록에 같이 적었습니다. 나중에 후회할 때는 그 기록이 필요하니까요.
03서비스 › 여우상회이름·컨셉·화풍 결정
왜
중심 단어인 「서식지」가 자꾸 걸렸어요. 처음에는 취향 문제인 줄 알았는데, 이미 정해둔 말투 규칙과
정면으로 어긋나 있었습니다.
해결
가게로 갔어요. 여우가 하는 상점이고, 값은 돈 대신 「해본 것」입니다.
방법
컨셉 후보 아홉을 걸러 하나를 골랐어요. 그 컨셉을 바탕으로 화풍을 정하고 주인 인상착의까지 끌어냈습니다.
그전까지 이 서비스의 중심 단어는 「서식지」였어요. 동물원에서 온 말입니다. 갇힌 동물이 야생에서
하던 행동을 하도록 우리에 자극을 넣어 주는 걸 행동풍부화라고 해요. 그 개념을 사람한테 가져오면서
이 서비스가 시작됐습니다.
제가 짚었습니다. "서식지라는 표현 특히 맘에 안들어."
취향 탓은 아니었어요. 이 서비스는 사육사의 목소리를 빼고 「일지」로 가겠다고 이미 정해뒀습니다.
그런데 중심에 둔 건 사육사의 말이었어요. 서식지에 풍부화, 개체까지. 우리 밖에서 들여다보는
사람의 어휘가 한가득이었습니다.
가게가 좋았던 건 예쁜 은유여서가 아닙니다. 미리 정해둔 규칙들이 그 말 하나로 쭉 풀렸어요.
셋 중 하나를 고르면 하나만 사는 셈입니다. 안 한 게 그날 사라지는 건 못 산 물건이고, 세트는
안쪽 선반이에요. 방을 더 얻으면 자리도 더 생깁니다. 「퀘스트를 하면 왜 물건이 생기나」도 여기서
처음 풀렸어요. 값을 치렀으니까 물건이 나오는 거죠.
AI가 「외상」이라는 말을 얹어놨길래 제가 짚었습니다. "외상일 필요 없잖아." 맞았어요. 코드도
이미 그렇게 돼 있지 않았습니다. 물건은 인증이 끝난 시점에 생겨요. 구현과 어긋나는 은유를
그 위에 덧칠하고 있었던 셈입니다.
시안이 시안 구실을 못 한 이유
받아 본 가게 그림들이 전부 같아 보였어요.
"구도만 다르고 다 톤앤매너가 똑같아. 전혀 여러 안으로서 기능을 못해."
원인은 발주 쪽에 있었습니다. 화풍을 기존 규격에 묶어 놓은 채 구도만 갈라서 시켰어요. 애초에
고를 만한 차이가 생길 수 없었던 거예요. 그래서 그리는 방식부터 갈라 다시 받았습니다. 픽셀과 수채,
평면 선화도 넣었고 게임 「커피톡」 같은 밤 분위기도 넣었어요.
픽셀에 밤으로 정했습니다. 하나를 고르는 순간 물건 78종의 화풍까지 같이 정해져요. 예쁘고 말고만
따질 자리는 아니었습니다.
캐릭터를 규칙에서 끌어내기
여우 주인도 다시 잡았어요. 그전 여우는 앞치마를 두르고 종을 든 채 웃고 있었습니다. 어느 잡화점
주인한테 붙여도 될 모습이었죠. 그래서 정해둔 규칙마다 몸에 붙는 물건을 하나씩 배당했습니다.
값이 「해본 것」이니까 저울을 줬어요. 못 산 것도 장부에 남으니 장부와 몽당연필이 필요했고요.
손님을 평가하지 않아서 시선은 내리깔았습니다. 자기 얘기를 안 하니 명찰은 없습니다. 차림새는
앞치마 대신 조끼와 팔토시로 갔어요. 팔토시는 소매가 더러워지지 않게 끼는 물건이라, 적는 게
본업이라는 표시가 됩니다.
표정은 늘리지 않기로 했습니다. 얼굴은 고정하고 꼬리만 바꿔요. 표정 78종이면 물량이지만 꼬리
서너 상태는 물량까지는 아니에요. 그래도 캐릭터가 얇아지지는 않습니다.
04블로그 › 매퉁이AI 말투 제거
왜
말투 가이드를 다 써뒀는데도 AI가 쓴 초안에서는 계속 AI 말투가 나왔어요.
해결
문서를 하나 더 쓰지 않았어요. 글을 고치는 순간 규칙을 읽히도록 검사를 걸었습니다.
방법
규칙이 안 읽히던 원인 셋을 찾았어요. 제 글 네 편을 말투 샘플로 넣고, 바깥의 AI 표식 목록으로
제 문서도 다시 셌습니다.
이 블로그 글을 제가 전부 쓰는 건 아니에요. AI가 작업 기록을 읽고 초안을 쓰면 제가 고칩니다.
그런데 초안마다 AI 말투가 그대로 남았어요. 소개글을 보고 말했습니다.
"말투가 AI말투잖아. 내가 저거 어떻게 고치라고 가이드도 다 해놨는데 왜 안되는거지? 원인을 찾아봐"
가이드는 있었어요. 다만 가이드끼리 서로를 가리키다가 빈 곳에서 끝났습니다. A 문서에는
"블로그는 B를 봐라"라고 적혀 있고 B는 "C에 있다"라고 했어요. C는 한 줄로 D를 가리켰는데,
정작 D에는 말투 이야기가 없었습니다. 문서 수는 충분했어요. 이어지는 고리 한 군데가 끊겨 있었죠.
두 번째 원인도 찾았습니다. 잘 작동하는 진단이 엿새 전에 이미 적혀 있었어요. 문서 이름이 다른
서비스 이름으로 돼 있어서, 블로그를 쓸 때 아무도 열지 않았을 뿐입니다.
여기에 문서를 더 얹지는 않았어요. 훅을 하나 걸었습니다. 특정 조건에서 자동으로 끼어드는
검사예요. 블로그 문구를 고치려는 순간 말투 규칙을 읽힙니다. 작업 창마다 한 번만 막고 두 번째부터는
통과하게 했어요. 규칙 본문은 훅에 베끼지 않고 문서에서 읽어 오도록 했습니다. 베껴 두면 둘이
따로 놀거든요. 다 걸어 놓고 소개글을 고치려다가, 제가 만든 검사에 제가 한 번 막혔습니다.
말투 샘플 4편 투입
"글몇개 줄게 말투 예시로 넣어줘. 내용적인 가이드가 아니라 문장을 구성하는 방식에 대한 샘플이야."
맞춤법과 오타는 손대지 않고 넣었어요. 고치는 순간 말투 자료가 달라지니까요.
여기서 판단이 한 번 뒤집혔습니다. 처음 뽑아 온 분석은 「부풀린다, 태클을 건다, 흐린다」였어요.
들여다보니 전부 무엇을 쓰는가에 관한 말이었습니다. 제목만 「문장 구성」일 뿐, 내용 지침이어서
반려했어요.
다시 뽑은 것 중 셋은 이랬습니다. 층이 다른 말을 한 문장에 섞고, 의고체와 한자어 사이에 구어와
신조어도 오갑니다. 문장은 접속사를 이어 붙여 늘이지 않아요. 명사 앞을 두껍게 만듭니다. 판단은
수식어에 넣되 서술어는 건조하게 둬요.
표식 목록으로 자가 측정
"웹에서 클로드 AI 말투 빼는 법 찾아봐"
국내 자료는 「짧은 문장과 긴 문장을 섞어라」 정도에서 멈췄어요. 그중 쓸 만했던 건
주제보다 문장 꼴에 초점을 둔 표식 목록이었습니다.
거기에는 「A가 아니라 B다」 같은 부정 대구와 삼단 나열이 있었어요. 자문자답, 되감기, 굵은 말로
시작하는 목록, 줄표 남용도 적혀 있었습니다.
그 목록을 들고 문서들을 다시 셌어요.
「A가 아니라 B」
굵게 시작하는 목록
AI가 쓴 말투 문서
3회
20개 중 15개
AI가 쓴 다른 말투 문서
6회
—
제 글 4편 전체
1회
2회
AI 말투를 없애겠다고 쓴 문서가 그 목록을 고스란히 따라가고 있었습니다.
판정 하나는 바뀌었어요. 자문자답과 부정 대구는 제 글에도 나옵니다. 문제는 빈도였습니다.
저는 네 편을 통틀어 한 번 썼고, AI는 문서 하나에서 세 번 썼어요.
소개글은 세 판을 버린 끝에 제가 썼습니다. 제 글에는 AI 판에 없던 게 있었어요. 물고기 알이
성체가 될 확률로 문을 연 다음 프로덕트 이야기로 넘어갑니다. AI는 전제를 먼저 말하고 뒤에 비유를 붙였어요.
05블로그 › 매퉁이글 삭제와 초안 체계 수립
왜
사이트에 올라가 있던 아홉 편은 제가 쓴 글이 아니었어요.
해결
전부 지웠습니다. AI는 초안까지만 쓰게 하고, 각도를 정하는 일은 제 몫으로 남겼어요.
방법
초안이 무엇인지 먼저 정의했어요. 그 정의는 문서에 두지 않고 명령으로 만들었습니다.
지웠어요. 이제 하나씩 손으로 잡기로 했습니다.
초안이 무엇인지도 정했어요. 제 작업 기록에서 제가 한 일을 사실 위주로 모아둔 것. 여기까지가
AI 몫입니다. 그 소재를 어떻게 쓸지는 제가 정해요. 무엇을 앞에 놓을지, 무엇을 뺄지, 어느 각도에서
볼지도 제가 고릅니다.
이 규칙은 문서에 두지 않고 명령으로 만들었습니다. 오늘 배운 게 그거였어요. 문서에만 적힌 규칙은
다음 작업 창에서 읽히지 않습니다.
06블로그 › 매퉁이검색 노출 대비
왜
사이트는 열려 있었지만 사이트맵도 공유 카드도 없었어요. 링크를 붙여도 아무것도 뜨지 않았습니다.
해결
본문은 한 글자도 건드리지 않았어요. 기계만 보는 자리에 필요한 걸 넣었습니다.
방법
사이트맵·피드·구조화 데이터를 붙이고 AI 크롤러를 열었어요. 방문 수는 사람을 식별하지
않고 셉니다.
AI 검색에 잘 걸리는 법이라고 돌아다니는 조언을 보면 절반쯤은 「글마다 요약 블록과 FAQ를 넣어라」예요.
그게 바로 이날 오전에 AI 말투라고 찍어낸 것들이었습니다. 같은 날 한쪽에서는 지우고 다른 쪽에서는
넣게 되는 셈이어서, 본문은 손대지 않기로 했어요.
넣은 건 사이트맵, 피드, 구조화 데이터, 정본 주소예요. 사람 눈에는 하나도 보이지 않습니다.
AI 크롤러는 열어 뒀어요. 이 블로그는 사람을 끌어모으는 깔때기보다는 만든 것들을 모아 두는 자리에
가깝습니다. 인용되는 것 자체가 이득이에요.
방문 수도 붙였습니다. 숫자를 세려면 어딘가에는 남아야 하잖아요. 딱 그것 하나만 서버에 뒀고
나머지는 파일 그대로 내보냅니다. 쿠키는 쓰지 않고 IP도 남기지 않아요. 사람을 식별하지 않으니
동의 배너도 필요 없습니다.
걸어 놓은 자동화가 한 번도 안 돌고 있었다
전날 「푸시하면 알아서 배포된다」를 걸어 놨어요. 확인해 보니 한 번도 초록불이 들어온 적이
없었습니다. 저장소에 열쇠를 넣지 않아서 매번 그 자리에서 죽고 있었어요. 그동안 배포는 전부
손으로 하고 있었습니다.
걸어 놓은 자동화는 한 번 돌려 보기 전까지 돈다고 치면 안 돼요.
07마무리 › 다음 작업내일 할 일
여우상회는 색 팔레트를 밤 기준으로 다시 쓰고, 그다음 물건을 그립니다.
블로그는 오늘 지운 자리에 글을 하나씩 채울 거예요.
가이드를 다 써놨는데도 소용이 없었어요. 원인을 찾고 샘플을 넣은 뒤, 바깥 목록으로 제 문서를 다시 재봤습니다.
시작
소개글을 보고 제가 말했어요.
"말투가 AI말투잖아. 내가 저거 어떻게 고치라고 가이드도 다 해놨는데 왜 안되는거지? 원인을 찾아봐"
가이드는 분명히 있었어요. 하나도 아니었고요.
원인 ①. 끊긴 고리
문서
말투에 대해 하는 말
뉴스 말투 가이드
"현황 리뷰용. 블로그는 이것과 다르다"
인간풍부화 말투
"블로그 말투는 페르소나에 있다"
블로그 페르소나
한 줄로 devlog.md 를 가리킨다
devlog.md
글의 형식만 있다. 말투 이야기가 없다
셋 다 다른 문서를 가리켰는데, 막상 끝까지 따라가니 규칙이 없었어요.
문서는 충분했지만 고리가 중간에서 끊겨 있었습니다.
원인 ②. 엉뚱한 문서에 갇힌 규칙
엿새 전에도 같은 지적을 받았고, 그때 써둔 진단이 있었어요.
AI 말투의 정체가 어휘보다 자세에 있다는 내용에 거부 사유 4개와 통과 시험 한 줄까지 붙어 있었습니다.
장치는 제대로 작동했어요. 그런데 문서 이름이 「인간풍부화 말투」였습니다. 서비스 하나에 딸린 문서처럼 보여서
블로그를 쓸 때는 아무도 열어보지 않았어요.
원인 ③. 문서를 안 여는 새 세션
제가 말했어요.
"계속 새로운 세션이 말투참고를 안하잖아. 뭔가 글을 쓸 때는 그걸 보게 만들어야할거아냐"
그래서 문서 하나를 더 쓰고 끝내지는 않았어요. 이미 그렇게 했다가 실패했으니까요.
블로그 문구를 고치려는 순간 규칙을 읽도록 훅을 걸었습니다. 세션당 한 번 막고, 두 번째부터는 통과해요.
규칙 본문은 훅에 복사하지 않았어요. 문서에서 읽어 보내게 했습니다. 둘을 따로 적어두면 문서와 훅이 제각각 움직이게 됩니다.
훅 시험은 29건에서 36건으로 늘렸어요. 막혀야 하는 입력과 통과해야 하는 입력을 모두 넣었습니다.
실제로 소개글을 고치다가 제가 만든 훅에 한 번 막혔어요.
말투 샘플 네 편
"글몇개 줄게 말투 예시로 넣어줘. 내용적인 가이드가 아니라 문장을 구성하는 방식에 대한 샘플이야."
난 · 자랑 · 태화관 · 후암이발소. 맞춤법과 오타도 손대지 않고 그대로 넣었어요.
고치는 순간 말투 자료로 쓸 수 없게 됩니다.
1차 분석은 틀렸어요. 「부풀린다 · 태클을 건다 · 흐린다」로 뽑아왔는데, 모두 무엇을 쓰는가에 관한 이야기였습니다.
「문장 구성」이라는 제목을 달았어도 실제 내용은 지침이었어요. 다시 시켰습니다.
"'무엇'이라는 원칙이 전부 내용적인 피드백이야. 단어사용과 그 수식관계를 더 중점적으로 봐야 해"
두 번째로 뽑아온 것 중 셋은 이랬어요.
층이 다른 말을 한 문장에 섞습니다. 의고체 · 한자 추상명사 · 비속어 · 신조어가 한 문단에 오갑니다
문장은 명사 앞이 두꺼워져서 길어집니다. 접속사로 이어붙여 늘리지는 않습니다
판단은 수식어에 넣고 서술어는 건조하게 둡니다. 농담은 관형절에 있고 본동사는 평범합니다
이 과정에서 잘못된 규칙도 하나 나왔어요. 「감탄·강조 부사를 안 쓴다」는 서비스 화면 규칙을
가져온 것이었는데, 제 샘플에는 「아주」가 네 번 나옵니다.
바깥 목록으로 자가 측정
"웹에서 클로드 AI 말투 빼는 법 찾아봐"
국내 자료는 「짧은 문장과 긴 문장을 섞어라」 정도에서 멈췄어요.
쓸 만했던 건 tropes.fyi 의 표식 목록이었습니다.
문장 꼴을 기준으로 정리한 목록이었어요. 부정 대구(「A가 아니라 B」), 삼단 나열, 자문자답,
쉼표 꼬리, 되감기, 굵게 시작하는 목록, 줄표 남용, 얼버무림이 들어 있습니다.
클로드 특유의 표식으로 지목된 건 얼버무림(「라고 볼 수 있다」)과 줄표였어요.
줄표는 1,000단어당 612개로 세어져 있습니다.
그 목록을 기준으로 제 문서를 다시 재봤어요.
「A가 아니라 B」
굵게 시작하는 목록
AI가 쓴 「블로그 말투」 문서
3회
20개 중 15개
AI가 쓴 「인간풍부화 말투」 문서
6회
—
내 글 4편 전체
1회
2회
AI 말투를 없애려고 만든 문서에 그 목록의 문장 꼴이 그대로 들어가 있었어요.
판정 하나는 바뀌었습니다. 자문자답과 부정 대구는 제 글에도 나와요.
제 글에도 있으니 금지 대상으로 묶기는 어려웠어요. 봐야 할 건 빈도였습니다. 저는 네 편에 한 번 썼는데 AI는 한 문서에 세 번 썼어요.
소개글의 결말
세 번 다시 썼고, 세 판 다 버렸어요. 제가 직접 썼습니다.
제가 쓴 글에는 AI 판에서 볼 수 없던 흐름이 있었어요. 어류 생존률로 문을 열고 프로덕트로 넘어옵니다.
「하나만 낳아 잘 기르는 게 미덕」과 「매몰비용」이 한 문단에 붙어 있고,
그다음에야 「생산이 가장 저렴해지고 있다」가 나와요. AI는 전제부터 말하고 비유를 뒤에 붙였습니다.
그 글은 말투 규칙에서 제외한다고 못박았어요. 페르소나 문서와 파일 주석 양쪽에 적었습니다.
하루 뒤의 결말
여기까지가 8월 29일입니다. 다음 날 결론이 하나 더 붙었어요.
규칙으로는 안 빠졌습니다. 표식 개수는 줄었는데 읽는 느낌이 안 바뀌더라고요.
그래서 같은 글을 두 판으로 만들어 나란히 올려봤어요. 클로드가 쓴 판과, 그 글을 챗지피티에 넘겨
말투만 다시 쓰게 한 판. 구조는 완전히 같았고 인용문도 글자 단위로 같았습니다.
챗지피티 판을 골랐어요. 갈린 자리는 어휘가 아니라 문장을 끊는 방식이었습니다.
챗지피티 판은 한 문장을 여러 개로 쪼개고, 「~쪽입니다」처럼 열어 둔 채 끝내는 자리가 많아요.
그래서 지금은 글을 이렇게 만듭니다. 클로드가 사실과 구조를 잡고, 말투만 챗지피티가 한 번 다시 씁니다.
말투를 고치라고 시키면 사실도 같이 고쳐지니까, 돌린 뒤에 구조와 인용문을 세어서 검사해요.
어긋나면 반영하지 않습니다. 이 글도 그 통과를 거쳤어요.
아직 안 풀린 것
훅은 블로그 문구를 고칠 때만 발화합니다. 위키 문서를 쓸 때는 걸리지 않아요.
그런데 AI 말투가 가장 심하게 나온 곳은 말투 규칙을 적은 위키 문서 자신이었습니다.
저장소 하나에 위키와 프로젝트 넷을 같이 담았어요. 무엇을 어디에 뒀는지 사실만 적습니다.
한 일
저장소 하나에 지식과 코드를 같이 담았습니다. 2026-08-18에 만들었고, 지금까지 커밋은 101개예요.
최상위 구조는 이렇게 잡았어요.
raw/ 원본 자료 — 사람이 넣고, 고치지 않는다
wiki/ 위키 — Claude 가 쓴다
projects/ 프로젝트별 폴더 — bait · blog · gunghap · quest
packages/ 공유 코드 7개 — auth · config · db · ui · habitat · MCP 서버 둘
infra/ DB 하나, 컨테이너 하나
design/ 원칙 · 도구 호출법 · 공유 껍데기
tools/ 훅 스크립트
index.md · log.md · todo.md · schema.md · CLAUDE.md
지식 구조
카파시가 2026년 4월에 올린 LLM Wiki 패턴을 그대로 따라갔어요. 검색을 핵심에 두지 않고 컴파일하는 방식입니다. 질문할 때마다 원본을 다시 뒤지는 수고를 줄이려고, 자료를 만나는 시점에 위키로 옮겨 적어둡니다. 답도 그 위키를 바탕으로 해요.
계층은 셋으로 나눴습니다.
계층
위치
소유자
규칙
원본
raw/
사람
불변. 지금 2건
생각
raw/thoughts/
사람
불변. 지금 0건
위키
wiki/
Claude
자유롭게 고친다. 지금 55쪽
위키 아래에는 ideasservicesdecisionssynthesisconceptsentitiessources, 이렇게 일곱 갈래가 있어요. 그중 decisions가 결정 기록(ADR)이고, 지금까지 33건 쌓였습니다. 구조·스택·데이터 모델을 정했다면 코드를 쓰기 전에 여기에 먼저 적어요.
부속 파일은 넷입니다.
index.md — 전체 카탈로그. 질문에 답하기 전에 가장 먼저 읽는 파일
log.md — 시간순 추가 전용. 지금 122건
todo.md — 할 일. [사람]이 붙은 것은 Claude가 못 하는 일입니다
schema.md — 페이지 종류와 프론트매터 규칙
커맨드
슬래시 커맨드는 11개예요. 이 가운데 셋은 위키 연산(/ingest/query/lint)에 쓰고, 나머지 여덟은 작업용으로 씁니다. /idea/explore/new-service/adr/devlog/review/debate/quest-set이 있어요.
아이디어가 생기면 /idea로 등록합니다. /explore로 여러 번 굴려본 뒤 /new-service로 만들어요.
자동으로 도는 것
규칙을 문서에만 적어두면 잘 지켜지지 않더라고요. 그래서 훅으로 걸었습니다.
세션이 시작될 때는 아래 셋이 돌아가요.
미처리 원본 자료 알림
머지 안 된 브랜치 알림
결정 전부 + 미해결 충돌 + 위키가 어긋난 곳 + 막힌 [사람] 일
파일을 고치거나 명령을 치기 전에는 네 가지를 막습니다.
워크트리 안에서 위키 고치기
이미 쓴 번호로 새 결정 기록 만들기 · log.md 통째로 덮어쓰기
git add -A 같은 범위 없는 스테이징과 경로 없는 커밋
블로그 문구를 고칠 때 말투 규칙을 다시 들려주기
한 번 갈아엎었다
처음에는 서비스를 apps/ 아래에 뒀어요. 그러다 2026-08-28에 projects/<프로젝트>/{app,design}으로 옮겼습니다. 기준은 소유하는 것은 도메인별로, 공유물은 기능별로예요.
프로젝트끼리는 서로 import하지 않습니다. 공유할 게 생기면 packages/로 올려요. 나중에 프로젝트 하나를 떼어낼 때는 git subtree split 한 줄이면 됩니다.
막힌 것
세션을 여러 개 동시에 돌리고 있습니다. 그런데 둘 다 master에서 돌면 훅이 아무것도 막지 못해요. 워크트리일 때만 걸리도록 해뒀기 때문입니다.
클로드로 그림을 만들 수 없어서, 이미 로그인해 둔 코덱스의 이미지 생성 기능만 빌려 쓰는 통로를 냈습니다.
문제
서비스에 들어갈 아이템 그림이 수십 종 필요했어요. 그런데 클로드 코드는 그림을 못 만듭니다.
글로 발주서를 쓴 다음 제가 다른 앱에 옮겨 붙이고, 나온 파일은 다시 폴더에 넣는 식으로 작업하고 있었어요.
챗지피티(코덱스)에는 이미지 생성이 내장돼 있고, 제 PC에는 이미 로그인도 돼 있었습니다.
이걸 클로드가 직접 부르게 하고 싶었어요.
읽기 전용 통로부터
첫 단계로는 기록부터 챙겼습니다. 코덱스에 남은 대화와 실행 권한을
클로드가 조회만 할 수 있도록 로컬 MCP를 하나 만들었어요. 읽기 전용입니다.
그때는 「그림은 사람을 거쳐 한 번에 발주한다」고 정해뒀어요. 읽기 전용 통로밖에 없었기 때문입니다.
그런데 제가 그걸 뒤집었습니다. 자동으로 돌아가게 해달라고 했어요.
좁은 통로 하나
방법은 셋이었어요.
방법
판정
A
이미지 생성 도구 하나만 노출하는 전용 MCP
채택
B
코덱스가 제공하는 MCP 서버를 그대로 연결
구현은 짧지만 에이전트 권한 전부가 열린다. 게다가 폐기 예정 경고가 뜬다
C
OpenAI 이미지 API를 직접 호출
API 키와 별도 과금이 붙는다. 이미 있는 로그인을 두고 새로 살 이유가 없다
A로 갔습니다. 키는 읽지도 전달하지도 않아요. 이미 로그인된 코덱스를 비대화식으로 띄운 뒤
내장 이미지 생성만 쓰게 했습니다. 결과 파일은 임시 폴더에 받아 PNG 서명과 크기를 확인하고 나서야
저장소 안으로 복사해요. 기존 파일도 덮어쓰지 않습니다.
첫날의 실패
붙이고 /mcp에도 떴는데, 그 세션에서는 불리지 않았습니다.
MCP 도구는 세션이 시작될 때 물려요. 이미 열려 있던 세션에서는 쓸 수 없고 새 세션부터 쓸 수 있었습니다.
그래서 그날은 다시 시작하는 값이 싸지도록 발주서와 참조 이미지를 파일로 남기고 마쳤어요.
이튿날, 도구가 안 보임
상태를 조회하니 available: false였어요. 로그인은 멀쩡했습니다.
알고 보니 코덱스 데스크톱 앱은 실행 파일을 어느 PATH에도 등록하지 않습니다. 사용자·시스템·프로세스
세 곳이 모두 비어 있었어요. MCP는 맨 이름으로 프로그램을 띄우고 있어서 PATH 외에는 찾을 길이 없었습니다.
그래서 네 단계로 찾게 고쳤어요. 환경변수 → PATH → %LOCALAPPDATA% 아래 해시 폴더 중 최신 → 맨 이름 순입니다.
해시 폴더 이름은 앱이 갱신될 때마다 바뀌어서 경로를 박아두지 않았어요.
상태를 조회하면 시도한 명령도 같이 돌려주도록 했습니다. 다음에 실패했을 때 경로 문제인지 로그인 문제인지 한 줄만 봐도 알 수 있게요.
기록에도 구멍이 하나 있었어요. 「PATH에 있어야 한다」는 내용이 결정 문서 어디에도 적혀 있지 않았습니다.
어제 되던 게 오늘은 왜 안 되는지, 기록만 봐서는 알 수 없었어요.
투명 배경
받은 그림마다 흰 테두리가 남았어요. 저는 도구의 한계인가 보다 하고 있었는데, 문득 이렇게 물었습니다.
"이미지젠 MCP 잘봐 투명배경 이미지를 만들던데 그거 안돼?"
맞는 지적이었어요. 코덱스가 만든 이미지 폴더를 훑어보니 전날 배치에 정말 부드러운 알파가
다섯 장 있었습니다. 반투명 픽셀이 수십만 개씩 들어 있었어요. 원래 되는 도구였던 겁니다.
그날 받은 그림들은 알파 채널이 아예 없었고, 있더라도 0 아니면 255뿐이었어요.
MCP가 보내던 주문에는 「투명 배경 필요」라는 말만 한 줄 들어가 있었습니다. 그러다 보니 흰 바탕에 그린 다음 배경을 지우는 쪽으로
새고 있었어요. 흰 테두리는 그 과정에서 남았습니다.
두 군데를 고쳤어요. 주문에 「직접 투명하게 내라 · 나중에 지우지 마라 · 알파를 이진화하지 마라」고 못박았습니다.
그리고 MCP가 받은 그림의 알파를 직접 세도록 했어요. 전날 배치로 검출기를 시험해 보니 다섯 장은 통과했고,
다섯 장은 실패했습니다. 정확히 갈렸어요.
내가 한 것
계정과 로그인은 제 것이고, 도구는 제 사용량을 씁니다
자동 경로를 요구한 사람도 저예요. 그래서 「사람을 거쳐 발주한다」는 결정을 뒤집었습니다
두 방식을 다 만들어 보게 시켰어요 — "A,B 둘 다 해봐. 결과물 보고 판단할게."
AI가 물건을 통째로 그리는 쪽과 코드가 형태를 세우고 AI는 무늬만 그리는 쪽이었습니다
둘을 나란히 놓고 골랐습니다 — "A가 훨씬 좋아." 각진 것은 둘이 비슷했지만 둥근 것에서 차이가 났어요.
한쪽 고양이는 고양이로 보였고, 다른 쪽은 회색 덩어리였습니다
투명 배경이 원래 되는 기능이라는 점도 제가 짚었어요
상업 이용 조건도 제가 확인했습니다. 8일 동안 아이템 그림 전체를 막고 있던 항목이었어요
시안이 제대로 갈리지 않았을 때도 짚었습니다 — "구도만 다르고 다 톤앤매너가 똑같아. 전혀 여러 안으로서 기능을 못해."
화풍은 그대로 두고 구도만 갈라놨으니 애초에 선택지로 쓸 수 없었어요
아직 안 풀린 것
그림이 늘자 다른 문제도 나왔습니다. 물고기 열여섯 종을 배경에 풀어봤더니
세 종은 이름이 틀렸고 수심은 대부분 지어낸 값이었어요.
「투명머리 물고기」는 표준명이 아니었습니다. 지어낸 설명이었고, 실제 이름은 통안어였어요.
숫자는 전부 자료에서 다시 잡았고 한 줄마다 출처를 달았습니다.
찾지 못한 것은 지어내지 않고 「미확인」으로 남겼어요.