제품을 하나씩 만드는 게 아니라 같은 뼈대를 도메인마다 세웁니다. 아래 15가지는 그동안 실제로 쓴 것들이고, 각각 문서로 남아 있습니다. 순서는 Data → Knowledge Graph → Studio → Agent → Company — 바닥은 AI가 아니라 데이터입니다. 구조가 엉성하면 AI를 얹어도 무너지니까요.
정본 15건 중 1건은 원문이 공개돼 있어 직접 확인하실 수 있습니다. 나머지는 비공개 저장소에 있습니다 — 확인할 수 없는 출처는 출처가 아니라는 것을 압니다. 보안 검토를 거쳐 공개 가능한 것부터 순차로 엽니다.
데이터 파편화를 막고 단일 온톨로지(Single Entity)를 진실의 원천으로 세운다. 로우 데이터를 즉시 '원석(Ontology Object)'으로 가공하고, 모든 에이전트가 그 하나만 바라보게 해 완벽히 동일한 컨텍스트를 공유한다. One Source Multi Use.
구성원(인간과 AI 에이전트 모두)이 '데이터 정합성'이나 '파편화로 인한 에러 복구' 같은 가짜 노동에서 벗어나 본질적 문제 해결에 집중하게 하는 것.
아키텍처 — A(중앙 상태 머신) + B(이벤트 드리븐) 하이브리드. C(관계형 지식 그래프)는 2차 고도화.
내부 설계 문서
데이터는 많다고 쓸 수 있는 게 아니다. 핵심은 서로 무관해 보이는 데이터에서 연결고리(정합성의 키)를 찾는 것이다. 그 키가 없으면 수집은 됐는데 잘못 묶이고 잘못 연결되고 조용히 틀린다.
‘매칭을 더 정교화’가 아니라 ‘버려진 신뢰키를 복원’하는 것. 실제 사례 — 한 카드혜택 API 가 결제 응답의 자유문자열을 정형 카탈로그에 매핑하지 못해 조용히 실패하고 있었는데, 신뢰 가능한 정형 식별코드가 이미 있었으나 안 쓰이고 있었다. 그 키를 복원해 정합성 55.8% → 97.2%.
순서 — 결정키 → 정규화 → 레코드 링킹 → (꼬리)AI. 전면 AI/모델이 아니다.
사례 — 함의·동음 — ‘카페’를 수집하면 애견카페·스터디카페가 섞인다. 키워드는 같아도 업종의 실체가 다르고, 분리하지 않으면 ‘카페 N개’라는 숫자 자체가 거짓이 된다. 지역명 오인 — 상호에 지역명이 들어간 프랜차이즈가 그 지역의 개별 맛집으로 오인 수집된다. 이름 한 줄에 브랜드·지역·업종이 엉켜 있고, 그걸 푸는 것이 정형화다.
내부 설계 문서
‘전수를 수집했는가’를 한 축으로 판정하지 않는다. 내부일관성·엔드포인트 수렴·외부 오라클 대조 세 축을 동시에 세우고, 하나라도 어긋나면 미완으로 본다.
시스템이 자기 불완전성을 스스로 드러내게 하는 것. 실제로 서울만 수집했을 때 ‘under(갭 61%)’를 스스로 신고했고, 전국 완주로 within 으로 바뀌었다. 관측이 오라클보다 많은 것도 숨기지 않고 표면화한다.
내부 설계 문서
Data → Knowledge Graph → Studio → Agent → Company. AI가 아니라 데이터가 기반이다.
사람 한 명이 AI 에이전트 팀과 함께 100명 규모 조직의 생산성을 낼 수 있게 만드는 운영체제.
내부 설계 문서
역할을 ‘모자(Hat)’로 나누고 이벤트로 연결한다 — issue.assigned → build.task → build.done → review.passed → confession.clean → COMMIT. 각 에이전트는 자기 이벤트만 듣고 자기 이벤트만 발행한다.
6원칙 — ① Fresh Context Is Reliability(매 반복 컨텍스트 초기화) ② Backpressure Over Prescription(상세 지시 대신 품질 게이트로 제어) ③ The Plan Is Disposable ④ Disk Is State, Git Is Memory(파일이 핸드오프 메커니즘) ⑤ Steer With Signals, Not Scripts ⑥ Let Ralph Ralph — 루프 위에서 조정하고 루프 안에 개입하지 않는다.
순서 — ⑥이 미션 그 자체다 — ‘개발자가 개입하면 병목’을 AI 에이전트를 대상으로 쓴 것.
내부 설계 문서
리뷰를 통과한 뒤에도 한 번 더 의심하는 감사 에이전트. ‘이 코드가 하는 가정이 무엇인가, 문서화됐나, 엣지케이스에서 깨지나’를 묻는다.
신뢰도를 감점 방식으로 계산한다 — 에러 처리 누락 −10%, 미문서화 가정 −5%, 통합 리스크 −15%, 보안 우려 −20%. 결과는 APPROVE / FIX / ESCALATE 셋 중 하나이고, 80% 미만이면 통과시키지 않는다. 자기 확신을 숫자로 낮추는 장치.
내부 설계 문서
가설을 숫자로 쓰고, 성공 기준을 착수 전에 고정하고, 실행을 날짜별 표로 남긴다. 판정은 PASS/FAIL 이분법이 아니라 INCONCLUSIVE 를 따로 두고 원인까지 기록한다.
실패와 불확실을 지우지 않는 것. 실제 기록에 ‘PASS 20 / FAIL 1 / INC 12’ 와 함께 INC 원인(‘시드 부족 4<20’, ‘staging 채팅 비활성’)이 그대로 남아 있다. 그리고 에이전트 운영의 토큰 비용을 실측해 구조까지 분해한다 — $6.57/사이클 중 97%가 캐시 읽기이고 전용 세션 분리 시 $0.7 예상.
순서 — 가설(숫자) → 성공기준 사전고정 → 실행기록(표) → 3분류 판정 → 배운 것 누적 → 승급
내부 설계 문서
발견은 출시 후 마케팅이 아니라 태어날 때의 속성이다. 축1 표면발견성 · 축2 콘텐츠자동발행 · 축3 오픈API/MCP · 축4 레지스트리.
앱=생산 · 링크드그램=발견 OS. 가치를 한 곳에 가두지 않는다.
내부 설계 문서
‘검증된 해법’이 아니라 ‘날카로운 진단 + 정직한 검증 설계’를 판다. 검증되지 않은 모델에 상대 예산을 먼저 태우라고 하지 않는다.
‘맡겨달라’가 아니라 ‘측정부터 맡겨달라, 위험은 내가 진다’. 1단계는 자비 또는 최소 비용으로 소수 실측 파일럿을 먼저 돌리고, 그 숫자가 재현되면 그때 주체·예산·이관을 논의한다.
순서 — 진단(강함) → 검증 설계(정직) → 작은 실측(리스크 선부담) → 자생 모델(P&L) → 이관(exit)
내부 설계 문서
단일군 전후 비교로는 인과를 말할 수 없다. 대조군 매칭 + 차이의차이(DiD), 투입 전 사전측정, 사전등록된 1차 종결점 1개, 90일 내 관측 가능한 선행지표.
결과를 ‘검증됐다’가 아니라 ‘신호 탐색’으로 표현하고 표본 한계를 인정하는 것. 종결점을 여러 개 두고 나중에 고르는 체리피킹을 구조로 막는다.
내부 설계 문서
SEO·워케이션 같은 것은 진입장벽 0이다 — 입장권이지 우위가 아니다. 진짜 방어선은 셋 — 누적 정합 데이터셋의 복리, 선점 락인, 그리고 이전 가능한 SOP·큐레이터 직군.
moat 이 ‘풍경’이나 ‘개인’이면 정책이 아니다. 방어선은 데이터 복리이고, 운영은 사람 이름 없이 이전 가능해야 한다 — 미션이 경쟁 우위의 정의가 되는 지점.
내부 설계 문서
지역 전문가의 무형 자산을 유형의 디지털 시스템으로 전환해 가치를 증폭시키고 공유한다. 이론적 뿌리는 마이클 거버의 E-Myth '기술자의 함정' — 사업주가 자기 기술 업무에 매몰돼 사업 '자체에 대해' 일할 시간을 못 갖는 현상이며, 해결책은 사업을 시스템 종속적으로 만드는 것이다.
창업자 개인의 역량 이상으로 사업이 성장하게 한다.
순서 — ['선순환 설계자 발굴', '전문성 패키징', '이너서클 테스트베드', '커뮤니티 확산']
사례 — ['오노미치 U2 (일본) — 니치 타겟팅과 장소성', '로컬스티치 (한국) — 공간보다 커뮤니티 우선', '더웨이브컴퍼니 (한국) — 로컬 크리에이터 액셀러레이터']
공개 원문 ↗ 2025-08-09
실적은 닫힌 도메인의 데이터 정형화에서 강력하다 → '발견'(데이터) 실행은 보증한다. 그러나 '사람이 왜 머무는가'(관계·정주)는 데이터 엔지니어링 실적이 보증하지 못한다.
자격을 인과 보증으로 전용하지 않는 것. 트랙레코드는 '이 사람은 데이터를 진짜 다룬다'까지고, 그 다음은 증명이 아니라 검증이다 — 보증하지 못하는 영역은 파일럿으로 검정한다.
내부 설계 문서
불일치를 발견해도 ‘어느 쪽이 가짜’라고 하지 않는다. 두 수치가 다르면 정의·관측단위가 다른 두 추정치일 뿐이고, 정확한 진단은 ‘판정할 기준 데이터가 없다’이다.
상대를 깎지 않고 함께 풀 출발점을 만드는 것. 지적의 근거를 상대의 자기 진단에서 가져오고, 자기가 쓰는 데이터의 한계에도 같은 잣대를 적용하며(자기선택 표본이면 그렇다고 밝힌다), 포부와 실적을 구분해 아직 실적이 아닌 것은 ‘착수할 PoC’라고 쓴다.
순서 — 무대 인용 전 원문 재확인 → 상대의 자기 진단 인용 → 같은 잣대 자기 적용 → 포부/실적 구분
내부 설계 문서
무엇을 자동화할 수 있는가보다 무엇을 자동화하지 않을 것인가를 먼저 적는다. 허용: 주제 분석·의도 분류·질문 추출·초안 생성·답변 추천. 금지: 다계정 조작, 사람인 척 여론 형성, 대량 도배, 허위 후기.
기술이 가능한 것과 해도 되는 것을 구분하는 것. 마지막 항목이 규율의 핵심이다 — 사람이 최종 검수 후 게시. 초안까지가 자동화이고 발행은 사람이 한다.
순서 — 허용 범위 → 금지 범위 → 사람 검수 지점 순으로 적는다
내부 설계 문서
위 문서들은 요청하시면 열어드립니다. 그리고 작게 먼저 돌려서 숫자를 봅니다 — 그 숫자가 나오면 그때 규모를 정합니다.
이 지도는 실제로 배포된 페이지에서 생성됩니다. 손으로 든 목록이 아닙니다.