레포를 열어두고 한참을 그냥 봤다. 무인으로 밀어 올린 myWiki는 돌아가고 있었다. 그런데 손이 안 갔다. 어디부터 손대야 할지 머릿속이 하얘졌다. 전에 무인으로 다 만든 다음에야 고칠 산이 보였다고 썼던 그 산이, 그대로 앞에 있었다.
포기할까도 했다. 처음부터 다시 짓는 편이 빠르지 않을까 하는 생각이 스쳤다. 코드가 이미 크고, 중간에 요구도 바뀌어 있었고, 한 줄 고치려다 컨텍스트를 다시 까는 비용이 보였다. 그래도 2026년 7월 13일, Grok 세션을 열고 이렇게 적었다.
「너와 같이 지금까지 내가 무인수행한 이 myWiki를 고치려고해. 포기할까도 햇지만 너랑 같이하면 할수있을거 같아 시작해. 일단 요구사항부터~~~~」
다시 만들기보다 고쳐 보기로 한 날이었다. 첫 줄에 이미 방향이 있었다. 기능이 아니라 요구사항부터.
기능이 아니라 척추부터
이어서 바로 말했다. 요구사항부터 얘기하겠다고. second의 수집·정제·분류·요약 메커니즘을 그대로 가져가고 싶다고. 「다 세컨드 기준으로 해주고」.
내가 원한 건 스킬 파일을 복사하거나, 터미널에서 한 번에 굴리는 운영 묶음(Brew)을 앱 안에 박아 넣는 게 아니었다. second가 이미 굴리고 있는 계약, 원문을 모으고(수집) 잡음을 걸러 내고(정제) 칸에 얹고(분류) 정리해 남기는(요약) 그 루프를 제품 요구의 척추로 두자는 쪽이었다. 예전에 “스킬 이식은 말고 앱 기능으로 대응했다”고 넘어간 층이 있었는데, 그 아래 구조를 second 기준으로 다시 맞추자는 이야기였다. 배포나 새 화면보다 먼저, 지식 루프가 맞는지부터.
Grok이 second랑 myWiki를 나란히 놓고 어디가 비는지 표로 정리해 줬다. 원문 입력(raw)을 모으는 형태는 있는데, 잡음을 걸러 내는 정제(scrub)가 약하다. 분류 쪽 지도 규칙도 second만큼 선명하지 않다. 요약·정리 파이프라인은 있어도 문서끼리 연결하고, 어느 칸에 앉힐지 정하고, 전체를 다시 돌리는 깊이가 얕다. 찾아 볼 때도 위키에서 분류 지도를 보고 경로를 좁힌 뒤 원문까지 가는 단계가 아직 없다. 이름은 비슷한데 뼈대가 안 꽂혀 있다는 진단이었다. “정리는 되는데 위키처럼 안 느껴짐”이 여기서 온다는 말도 와닿았다.
나는 대부분 second 기준으로 가기로 했다. 분류 구조만은 이야기가 필요했다. 공간을 베이스로 동적으로 뻗어가게 할지. 공간이 고정 렌즈가 아니라 내가 관리하고 싶은 주제·칸이라면, 그 칸에서 안쪽 지도를 AI가 키우는 쪽이 자연스러워 보였다. second처럼 원문 층과 위키 층이 있고, 지도가 경로로 본문을 가리키는 그림이 제품에도 맞았다. 기본으로 생기는 공간도 숨기지 않고, 다른 공간과 같은 자리의 칸으로 두기로 했다.
설계가 맞춰지자 이렇게 적었다. 「휼륭 하다 그럼 자연스럽게 인덱스와 위키가 만들어지고 그걸 자연스럽게 활용하면 될거같애」. 전역으로 물어봐도 공간이라는 출발점이 있다는 감각이 마음에 들었다. 사람이 큰 칸만 잡고, 칸 안 세부는 정리 쪽이 맡는 그림. 지식 루프가 어때야 하는지는 그날 그 자리에서 정했다.
써 보니 바로 느껴진 것
요구를 말로만 두지 않고, 그날 이어서 체감 문제를 그대로 던졌다. 화면의 분류·태그 구성이 어색한 것도 말했고, 더 큰 건 소화 쪽이었다.
「소화가 너무 1:1인데 통합되어야할거같은데」
「소화할때 바로 편집하는게 아니고 종합해서 편집해야할거같은데 ? 인덱스도 활용해야할거같고 병합도 해야할거 같고 중복내용이 너무 많은거 같애」
원문 그대로다. 말이 거칠어도 요구는 구체적이었다. 원문 하나 들어오면 문서 하나를 바로 쓰거나 만들고, 분류 지도는 나중에 붙는 도구처럼 밀려 있고, 비슷한 글이 여러 장으로 쌓인다. 종합해서 합치고, 지도 보고 자리를 잡은 뒤에 쓰자는 쪽이었다. “품질 올려 줘” 같은 말이 아니라, 입구에서 바로 쪼개 쓰는 동작이 싫다고 찍은 셈이다.
내가 짚은 방향이 그거였다. 코드를 같이 열어 보니 원인이 맞았다. 입구에서 어떻게 처리할지 가르자마자 곧바로 본문을 쓰는 흐름이라, 처음부터 1:1로 갈라진다. 지도는 나중에 붙는 느낌이고, 병합도 손으로 나중에 돌리는 쪽에 가깝다. 내가 원한 처방은 짧았다. 분류 지도를 먼저 보고 어디에 두고 뭘 합칠지 정한 뒤, 그때 본문을 한 번 종합해서 고친다. 새 문서를 만드는 건 정말 새 가지일 때만. 같은 주제면 붙이고 합친다.
여기서 희망이 생겼다. 다른 이유가 아니었다. 요구를 구체적으로, 그리고 정확하게만 넘기면 바로 따라왔다. 1:1이 싫고 종합·분류·병합이 필요하다고 말했더니 파이프라인 단계까지 내려가 대조했다. “할 수 있겠다”는 감각은 그 즉각적인 반응에서 왔다. 산이 사라진 건 아니지만, 어디를 깎을지 첫 면이 잡힌 느낌이었다. 에이전트에게 산을 통째로 맡기는 게 아니라, 내가 깎을 면을 문장으로 주고 그 면만 같이 파내는 쪽에 가까웠다.
깎을 순서를 정한 뒤
기능을 더 붙이기 전에, 클린업 전 코드베이스 헬스 리뷰를 돌렸다. PR diff가 아니라 src/ 전수에 가깝게, 버그·보안·계층 드리프트·큐 좀비·핫패스를 이슈 목록으로 뽑는 작업이었다. 목적이 “뭐가 잘못됐는지 전부 고친다”가 아니라, 우선순위 로드맵을 먼저 얻는 쪽이었다. 구현을 더 쌓기 전에 깎을 순서를 손에 쥐자는 의식에 가깝다.
무인으로 쌓인 산 앞에서는 손이 안 가는 이유가 두 갈래였다. 제품이 무엇을 해야 하는지(요구)가 흐릿한 것과, 코드에서 어디가 위험한지(건강)가 안 보이는 것. 그날은 둘 다 손으로 짚기 시작한 날이었다. second 메커니즘을 요구 척추에 박고, 소화 1:1 문제를 말로 고정하고, 깎을 순서를 이슈 목록으로 받았다.
다시 짓지 않기로 한 것도 같은 맥락이었다. 이미 원문·위키 파일화까지 간 덩어리가 있었다. 버릴 게 아니라 계약을 다시 꽂고 입구 동작을 고치는 쪽이 맞았다. 희망은 “완벽한 계획이 생겼다”가 아니라, 구체 요구를 넘기면 에이전트가 같은 속도로 따라온다는 체험이었다.
여기서부터 다시
그래서 이 날은 재개 의식에 가깝다. 포기할까 말까 사이에서, Grok이랑 요구사항부터 다시 짚었다. 스킬을 이식한 게 아니라 수집·정제·분류·요약이라는 메커니즘을 제품 문장으로 옮겼고, 소화가 1:1로 쪼개지는 불편을 그대로 말했고, 조금 써 보니 요구만 구체하면 즉각즉각 처리됐다.
산은 아직 있다. 저장 구조를 어떻게 둘지, 비용이 어디서 새는지, 분류가 채팅에 어떻게 붙는지 같은 이야기는 아직 안 열었다. 그건 다음 편에서 깎으면 된다. 이 글에 남길 건 하나다. 무인으로 쌓인 산 앞에서 다시 짓기보다 고치기를 골랐고, 그 첫 수는 요구사항을 척추로 다시 세운 것이었다.