공장 안에는 무엇이 들어 있나

다른 페이지는 이 공장이 어떻게 일하는지를 설명합니다. 이 페이지는 그 일이 실제로 남긴 것을 그대로 펼쳐 놓습니다. services/ 폴더에 들어 있는 서비스 전부, 서비스마다 쌓인 기록, 그 기록에 걸리는 검토, 그리고 이 셋이 어떻게 맞물려 한 바퀴를 도는지입니다.

서비스 48개 보기 맞물리는 방식 직접 써보기 — 카탈로그

먼저, 규모

아래 수치는 모두 저장소에서 직접 센 것입니다. 추정치나 목표치, 외부 벤치마크는 넣지 않았습니다. 무엇을 어디서 셌는지 함께 적어 두었으니 그대로 확인하실 수 있습니다.

실측 2026-10-07. 서비스 행은 정본 기준일 2026-09-29, 지식그래프는 2026-07-13 빌드.
항목수센 위치와 단서
서비스 행49services/services.json — 포트 단위로 센 행
돌고 있는 프로세스48같은 파일 — 24-process 한 개가 포트 둘을 함께 들어서 행이 하나 더 많습니다
분류10같은 파일 — 기술 스택이 아니라 쓰임새로 나눈 분류
바로 열리는 공개 주소41같은 파일 — 남은 7개는 서버·데이터·법인 관리용이라 공개 목록에서 뺐습니다
서비스가 남긴 문서·기록286services/ 아래 .md. 빌드 산출물, 남의 저장소를 받아 둔 것, 수업 교재, 파이프라인에 넣는 원문은 뺐습니다 — 우리가 쓴 것만 센 수입니다. 아래 기록 표가 이 안을 쪼갭니다
저장소 커밋296git — 2026-05-26 첫 커밋부터 2026-10-08까지. 커밋할 때마다 늘어나는 값이라 이 표를 만든 시점 기준입니다

서비스 구성 — 10개 분류

서비스는 번호순으로 늘어서 있는 게 아니라 10개 분류로 묶여 있습니다. 분류 기준은 무엇으로 만들었는지가 아니라 무엇에 쓰는지입니다. 이름을 누르면 그 서비스가 바로 열립니다. 점선으로 표시한 것은 서버·데이터·법인 관리용이라 공개 목록에서 뺀 것입니다.

위 목록은 services/services.json(정본, 실측 2026-09-29)을 그대로 옮긴 것입니다. 서비스 48개 — 정본의 행은 49개인데, 한 서비스가 포트 둘을 함께 듣는 경우가 있어 행이 하나 더 많습니다. 이름을 눌러 바로 열리는 것이 41개이고, 나머지 7개는 서버·데이터·법인 관리용이라 공개 목록에서 의도적으로 빼 두었습니다.

기록은 어디에 쌓이나

서비스를 하나 만들면 코드만 남지 않습니다. 네 종류의 정본 문서가 먼저 있고, 그 아래로 서비스별 기록이 쌓입니다. 어느 질문을 어디서 답하는지가 미리 정해져 있어서, 같은 사실이 두 곳에 따로 적히지 않습니다. 이게 기록이 양만 늘지 않고 쓸 수 있게 남는 이유입니다.

  • 운영 런북 — SERVICES.md

    어느 포트가 어느 서비스이고 어느 주소로 나가는지. 서비스를 찾을 때는 프로세스 목록을 뒤지지 않고 이 파일 하나를 읽습니다. 표는 실측으로 자동 재생성됩니다.

  • 카탈로그 정본 — services.json

    49행과 10개 분류의 단일 출처. 제어 도구가 실행 중에 이 파일을 읽고, 이 페이지의 목록도 빌드 때 여기서 생성됩니다. 다만 카탈로그 포털은 아직 자기 사본을 들고 있어서 그쪽은 따로 고쳐야 합니다 — 아직 안 끝난 정리입니다.

  • 데이터 행선지 — DATA_ROUTING.md

    어떤 데이터가 어느 허브로 가는지. 집계·조인할 것은 PostgreSQL 허브로, 사람에 관한 기록은 인물 그래프로 갑니다. 계약과 실제 구현이 다른 지점까지 문서에 적어 둡니다.

  • 도메인 문서 지도 — CONTEXT-MAP.md

    서비스별 용어·결정 문서가 어디 있는지. 전부 미리 만들어 두지 않고 손대는 서비스부터 등재하는 방식입니다.

서비스별로 실제로 쌓여 있는 기록 (실측 2026-10-07). 위 286 안을 쪼갠 것이고, 표시한 두 줄만 그 바깥입니다.
기록수어디에 · 무엇인지
인물 기록10034-graph 인물 그래프 — 인물 49명, 심층분석 31건, 스캔 20건. 한 사람이 문서 하나입니다 (빈 서식 파일 1개는 사람이 아니라 뺐습니다)
스킬 추출용 원문23844-book2skill — 저작권이 풀린 고전 원문입니다. 우리가 쓴 글이 아니라 파이프라인에 넣는 재료라 위 286에는 넣지 않았습니다
페르소나 실험 기록3646-persona-lab — 실행 원장과 계약 문서. 공개 범위를 문서로 분리해 둡니다
일일 기록32memory/ — 2026-09-06부터 2026-10-07까지 하루 한 파일. 서비스 폴더 밖이라 위 286에는 안 들어갑니다
지식그래프 노드3,549graphify-out/graph.json — 링크 6,029개. 코드·문서를 질의할 수 있게 만든 그래프

검토는 어떻게 걸리나

이 공장에는 규칙이 하나 있습니다. 만든 쪽이 자기 결과를 승인하지 않는다. 그래서 검토는 늘 나중의 별도 패스로 돌고, 말이 아니라 위에 쌓인 기록을 증거로 삼습니다. 아래는 그 검토가 남긴 것들입니다.

검토와 교정의 실측 (2026-10-07)
항목수무엇인지
실패분석 실행302026-07-05부터 2026-09-09까지. 사용자가 다시 지시한 지점을 앞선 실패로 보고 교정쌍을 찾아냅니다
누적 교정 규칙35실행마다 새 규칙만 덧붙입니다. 같은 실수가 다시 나오면 번호를 올려 재발로 기록합니다
감사 리포트72026-08-14 ~ 2026-09-11. 스킬·볼트 생태계·웹디자인·인물분석·실행절차를 대상으로 각각 읽는 문서와 보는 문서 한 쌍
팀 페르소나 문서30역할별 팀원의 판단 기준과 담당 범위. 한 사람이 문서 하나입니다
에이전트 정의30이 저장소의 .claude/agents/ — 페르소나 28명에게 각자의 실행 정의가 있고, 역할 전용 2개가 더 있습니다
작업 절차59되풀이되는 일을 절차로 굳혀 둔 것. 이 중 9개만 헤일메리 고유이고 나머지 50개는 공용 도구 모음을 가져다 연결한 것입니다

있는 그대로 적자면, 실패분석 루프는 2026-09-09 이후 멈춰 있습니다. 현재 정기 작업으로 걸려 있는 것은 기록 위생 점검 하나뿐이고, 재가동은 예정 항목입니다. 돌지 않는 것을 돈다고 적지 않는 것도 이 공장의 규칙 가운데 하나입니다.

이 셋은 이렇게 맞물립니다

서비스가 기록을 남기고, 기록이 검토의 증거가 되고, 검토가 규칙과 정본을 고치고, 고쳐진 규칙이 다음 요청의 판단 기준이 됩니다. 한 바퀴가 닫혀 있어서 같은 실수를 두 번 하기 어렵습니다.

  1. 01

    요청

    구석의 한 줄 요청. 창구가 즉답할지 팀에 넘길지 가릅니다.

  2. 02

    서비스

    10개 분류 안에서 만들어지고 운영됩니다.

    49행 · 48 프로세스
  3. 03

    기록

    정본 네 종과 서비스별 기록으로 남습니다.

    문서 286 · 인물 100
  4. 04

    검토

    만든 쪽이 아닌 별도 패스가 기록을 증거로 판정합니다.

    실패분석 30 · 감사 7
  5. 05

    규칙·정본

    교정이 규칙이 되고, 절차와 정본 문서에 반영됩니다.

    규칙 35 · 절차 59

되먹임 — 05에서 바뀐 규칙과 정본이 01의 판단 기준이 됩니다. 이 화살표가 없으면 위 숫자는 그냥 쌓인 파일일 뿐입니다.

같은 실수가 다시 나오면 새 규칙을 적는 대신 기존 규칙의 번호를 올려 재발로 표시합니다. 그래서 규칙 수는 작업량이 아니라 아직 안 고쳐진 약점의 수에 가깝습니다.

말이 아니라 배선 — 실제로 물려 있는 지점

위의 순환은 설명이고, 아래는 코드에 실제로 적혀 있는 연결입니다. 서비스 48개가 각자 떨어져 있는 게 아니라 몇 개의 공용 지점을 함께 쓴다는 뜻입니다.

  • 공용 AI 호출 경로

    12개 서비스가 같은 클라이언트 하나를 require('../../lib/ai-router-client')로 끌어다 씁니다. 모델을 바꿀 때 서비스 열두 곳을 고치지 않고 한 곳을 고칩니다.

  • 스킬 원장을 가운데 두고

    Skill Lab이 추출 결과를 data/skill-library.db에 쓰고, LookGood이 같은 파일을 읽어 목록과 이력을 보여줍니다. 두 서비스가 파일 하나로 이어집니다.

  • 카탈로그 정본을 읽는 쪽

    제어 도구의 registry.js가 실행 중에 services.json을 읽어 대상 목록을 만들고, 이 페이지의 서비스 목록도 같은 파일에서 생성됩니다 — 손으로 쓰지 않습니다. 반대로 카탈로그 포털은 아직 목록을 자기 안에 적어 두고 있습니다. 정본 하나로 모으는 일이 아직 안 끝났다는 뜻이고, 그래서 서비스를 추가하면 지금은 두 군데를 고쳐야 합니다.

  • 데이터 허브는 둘, 기준은 하나

    집계하고 조인할 것은 PostgreSQL 허브로, 사람에 관한 기록은 인물 그래프로 갑니다. 어느 쪽인지는 서비스가 마음대로 정하지 않고 DATA_ROUTING.md가 정합니다.

  • 사이트가 런북을 되짚습니다

    지금 보고 있는 이 사이트의 다른 페이지들도 숫자를 적을 때 SERVICES.md를 근거로 인용합니다. 소개 문구와 운영 사실이 따로 떠돌지 않게 하려는 배선입니다.

  • 구조는 질의로, 운영은 런북으로

    코드가 어디서 어디로 이어지는지는 지식그래프에 질의합니다. 반대로 지금 무엇이 떠 있는지는 그래프가 아니라 런북에서 답합니다. 용도가 다른 질문을 같은 도구로 풀지 않습니다.

직접 확인해 보세요

이 페이지의 주장은 전부 열어볼 수 있는 것에서 나왔습니다. 카탈로그에서 서비스를 직접 써 보시고, 숫자가 의심되면 위 표의 '센 위치' 열을 그대로 따라가 보시면 됩니다.

서비스 카탈로그 열기 요청이 서비스가 되는 과정 연구와 실패 기록