26년 4월 노트

#1

Ocean Vuong — “When I write, I feel larger than the limits of my body”

능동성이란 내게 내 마음이 있으니 누구의 영향을 받을지 내가 고르고, 무엇을 쓸지 내가 고르겠다는 것. 그래서 능동성은 급진적이다. 글을 쓸 때면 호기심을 따라야 한다. 내가 the라는 단어 — t-h-e — 를 써도, 그건 여전히 아시아계 미국인의 the다. 빠져나갈 수 없다. 빠져나갈 수 없다면, 정체성을 넘어 내 호기심을 돌봐야 한다. 정체성은 이미 거기 있으니까. 모든 것에 박혀 있다. SF를 쓰거나 화성에 대해 써도, 여전히 내게 고유한 아시아계 미국인의 경험이 짜여 들어간다. 우리가 누구인지, 어떻게 보이는지로부터 빠져나갈 수 없다 — 그러니 그것을 안고 가면서 호기심을 돌보아라. 그러지 않으면 자신을 체크박스, 카테고리, 테마로 추상화시킬 뿐이다. 우리는 종이에 새겨진 자아의 DNA와 화해하기 위해 글로 간다. 외모 때문에 모두가 어떤 방식으로 써야 한다면 그 큰 기회를 잃는다. 우리는 세상에서 늘 오인된다. 가장 자유롭고 창조적인 곳에서 그 오인을 향해 쓴다는 건 큰 수치다.

스타일은 정적인 현상이 아니다. 존재론적 진리도 아니다. 우리는 모드를 가지고 있다 — 말할 때처럼. 어머니에게 말할 때, 친구들에게 말할 때 다른 모드 — 모두 진짜다. 어머니에게 더 진짜인 것도, 연인이나 친구에게 더 진짜인 것도 아니다. 너는 너다. 진정성에 대한 질문은 의심스러운 탐구다. 그것은 우리 경험과 통사를 쉽게 고정 가능한 카테고리로 환원시킨다 — 카테고리화되면 관리가 쉬워진다. 카테고리화는 관리자의 모험이다. 그 안에서 우리는 자기 자신을 너무 많이 잃는다. 산만함은 정말 유용한 상태다 — 우리 세계에서 종종 병리화되지만. 언어와 스타일과 모드를 넘나드는 산만함, 카멜레온화 — 에두아르 글리상이 말한 레지스터와 스타일의 크레올화 — 는 자아의 확장이다. 내가 쓸 때, 나는 내 몸의 한계보다 훨씬 크다고 느낀다. 설명할 수는 없지만, 읽거나 써본 사람이라면 누구나 이를 경험했을 것이다. 훨씬 더 큰 신비에 접속하게 된다.

사진은 운이 있다 (적절한 시간·장소). 글쓰기에는 없다. 순수한 법칙이다. 단어 하나하나가 명료함과 확장을 향한 집단적 희망 속의 시민에 가깝다. 그래서 글쓰기는 시민적 프로젝트이며, 도달할 수 없는 열망의 작업이다. 자기 책을 다시 읽었을 때 후회가 있다는 것은 성장했다는 뜻이다.

규칙은 가드레일이다. GPS에 이미 있는 곳으로만 데려간다. 규칙을 따르는 것은 진짜 나아가는 것이 아니라 따라가는 것이다. 퀴어함은 다른 길을 요구한다 — 가드레일을 넘어, 숲을 헤매고, “전기 같은 황홀한 공포”와 함께 가장 자유로워진다. 거기서부터 삶을 만들어야 한다. 이성애 규범은 누구든 용기만 있으면 떠날 수 있다.

허세, 아이러니, 권력의 남성적 가면은 짧은 퍼포먼스다. 취약함이 24시간의 대부분을 채운다. “방패를 내려라… 자신의 취약함과 협력하는 것이 예술가로서 할 수 있는 가장 강한 일이다.” 돌봄, 연민, 개선의 욕구는 모두 취약함에서 나온다. 사회는 오락·스포츠·뉴스를 통해 취약함을 파괴하려 하지만, 아이러니하게도 취약함은 가장 강한 것이라 결코 파괴되지 않는다.

#2

레거시 레코드에 새 필드를 추가해야 했고, 기존 데이터는 해당 값이 null인 상태에서 언제 채울지(backfill)를 결정해야 했다. 트레이드오프를 고려했다. GET 조회 시 null을 감지해 즉시 생성하는 방식도 고려했지만, GET은 캐시 레이어와 자동 재시도의 대상이라 쓰기 동작의 실행이 보장되지 않는다. 대신 명시적인 POST 엔드포인트를 분리해 클라이언트가 직접 트리거하도록 했다. HTTP 시맨틱을 지키면 캐싱·재시도 같은 인프라 레이어의 기본 가정을 깨지 않고 그대로 활용할 수 있을 것 같다는 판단이었다.

#3

Lenny Rachitsky — Biggest Takeaways from Evan Spiegel

소프트웨어는 더 이상 진입장벽이 아니다. 소비자 제품의 병목은 제품 그 자체가 아니라 Product distribution에 있다. 지속 가능한 우위는 생태계(Snap을 예로 들면, 개발자가 만든 수백만 개의 AR 렌즈, 크리에이터 관계), 하드웨어, 디자인 주도 문화, 그리고 사용자가 명시적으로 요구하는 것을 거절할 수 있는 의지에서 나온다. 고객의 문제를 해결하는 것은 통념과 달랐고, 사용자가 요구한 기능은 근본적인 문제를 해결하지 않는다.

좋은 아이디어를 얻으려면 많은 아이디어가 필요하다. Snap의 디자인 팀은 매주 수백 개의 새 아이디어를 제시하고, 신입 디자이너는 첫날부터 발표한다. 심지어 Snap은 의도적으로 직원 200명까지 PM을 고용하지 않았다. 전통적 조직구조가 디자이너를 “PM 지시에 따라 시각물을 생산하는 사람”으로 격하시키는 것을 막기 위함이다. 아이디어가 쏟아져 나와야 하고, 그걸 막는 모든 구조적인 병목은 제거되어야 한다.

#4

ontology-lab이라는 개인 프로젝트를 시작했다. 상용 버전은 아니고, 오로지 내 삶에서 쓰려고 시작했다. 요약하자면 llm이 관리하기 쉽도록 개인과 조직의 암묵지를 구조화하기 위한 프레임워크. AI 시스템을 세 레이어로 보면 모델은 고르는 것, 하네스는 설계하는 것, 온톨로지는 시간이 지나도 조직마다 다르게 남는 것으로 구분할 수 있는데, ontology-lab은 그 온톨로지와 하네스를 쌓는 쪽에 해당한다.

각 온톨로지는 변화 속도에 따라 세 레이어로 나뉜다. foundation(불변, 존재이유와 판단 기준), domains(느림, 도메인 지식), think_do_write(가변, 의사결정 로그). 외부 입력은 inbox로 들어와 유형에 따라 domains 또는 think_do_write로 정제된다. 그 안에서 두 종류의 그래프가 만들어진다 — 사실·관계를 담는 Knowledge Graph(domains)와 판단 기준·의사결정 이력을 담는 Context Graph(foundation + think_do_write).

개별 온톨로지(ark, prix, neo)를 여러 개 만들다 보면 공통 교훈이 반복해서 나타난다. 각 로그에만 남기면 다음 온톨로지에서 같은 실수를 반복하므로, 별도의 methodology 레이어를 두었다. 일반화 가능한 교훈은 스테이징을 거쳐 methodology로 승격되고, 반대로 methodology가 갱신되면 개별 온톨로지가 새 원칙을 따르는지 점검해 내려보낸다. 지식은 어느 조직이든 어느 정도 있다. 컨텍스트는 대부분 흩어진 채로 있거나 사람 머릿속에만 존재한다. 결국 남는 건 컨텍스트 쪽이다.

나는 복잡한 것을 명료하게 만드는 일에 끌린다. 단순화 자체가 목적은 아니다. 보기 어려운 것을 다른 사람도 함께 추론할 수 있는 형태로 바꾸는 일이다. 어떤 조직이든 의사결정을 움직이는 대부분은 글로 남지 않는다. 판단의 근거, 적혀 있지 않은 규칙, 모든 선택 뒤에 깔린 맥락 — 이것들은 사람의 머릿속에 산다. 구조가 없으면 조직은 같은 실수를 반복하고, AI는 표면만 학습한 채 핵심을 놓친다. 내가 하는 일은 그 숨은 지식에 구조를 주는 것이다. 온톨로지 구축이 바로 그 작업이다 — 모두가 알지만 누구도 적어두지 않은 것을 명시화하는 일. 어려운 일이고, 그래서 의미가 있다. 팔란티어는 이를 “pain is our moat”이라 부른다. 하기 어려운 일은 복제하기 어렵고, 복제하기 어려운 일은 해자가 된다. 온톨로지와 에이전트 하네스 설계에 집중하는 이유다. 온톨로지는 데이터에 드러나지 않는 판단과 맥락을 담는다. AI가 패턴 매칭이 아니라 실제로 추론하려면 필요한 것들이다. 하네스는 에이전트가 그 맥락 위에서 안정적으로 행동하도록 만드는 층이다. 둘이 함께할 때 AI는 패턴을 흉내내는 일을 멈추고 조직처럼 사고하기 시작한다.

      ┌──────────────────────────────────────┐
      │  Model     Claude, GPT 등            │  선택의 영역
      │  Harness   skills, hooks, rules      │  컨텍스트 전달 설계
      │  Ontology  도메인 지식 · 판단 기준   │  조직의 맥락
      └──────────────────────────────────────┘

              00_the_methodology
                ▲            │
       교훈 승격│            │드리프트 점검
                │            ▼
       ┌────────┴────────────┴────────┐
       │      ark   prix   neo        │
       └──────────────────────────────┘

#5

Vercel | Agent Responsibly

CI 통과 = 안전이라는 공식이 더 이상 안 맞는다. 에이전트는 파이프라인을 “설득”하는 데 능해서, 테스트 통과하고 PR 설명도 그럴싸한데 막상 배포하면 전체 테이블 스캔 쿼리나 무한 성장 캐시가 섞여 있다. 예전엔 대충 짠 코드가 딱 티가 났는데, 요즘은 시니어가 쓴 것처럼 보인다. 부족한 건 코드 작성이 아니라 “이걸 배포해도 되는지 판단하는 능력”이고, 리뷰로 물량을 막는 건 지는 싸움이다. 결론은 인프라 자체를 엄격하게 만들어 “빨리 배포 = 기본적으로 안전”이 되게 하자는 것 — 카나리와 자동 롤백, 배포 후 상시 자기검증, 운영 지식을 문서가 아니라 실행 가능한 도구로. PR 올리기 전 세 가지 질문도 제안한다 — (1) 이게 뭘 하는지, 배포 후 어떻게 동작하는지 설명할 수 있나 (2) 프로덕션이나 고객에 어떤 부정적 영향이 있을 수 있나 (3) 이 PR이 장애를 낸다면 내가 온콜 받을 수 있나

#5-1

사실 엔지니어의 역량은 애초부터 코드 작성에 있지 않았다. 좋은 엔지니어와 그렇지 않은 엔지니어의 차이는 항상 판단에 있었다 — 무엇을 만들어야 하는지, 이걸 배포해도 되는지, 장애가 나면 어디를 봐야 하는지. 코드 작성은 그 판단을 실행하는 도구였고, 에이전트가 그 도구를 빠르게 만들어주면서 판단이 전면에 드러났을 뿐이다. 그런데 그 판단의 기준이 하네스(CI/테스트/리뷰) 안에 없다. 시스템의 운영 맥락, 장애 이력, 배포 기준이 온톨로지로 구조화되어 있어야 하네스가 참조할 수 있다. 없으면 에이전트는 표면적 기준에만 최적화된다.

이 인식을 바탕으로 회사 제품 개발 사이클에 prix 온톨로지 + Claude Code 스킬로 하네스를 연결했다. 흐름은 — 팀원이 에이전트로 PR을 올리면 ext(변경사항 이해 + 마이그레이션·권한 1차 검증) → spr(코드 스파링, 전체를 안 읽어도 문제점 파악) → 승인 → 스프린트 배포 직전 ext-main-diff(develop 누적 변경 최종 점검) → qa(체크리스트 생성, 팀원 각자 자기 작업 책임 확인) → 배포. 결과는 일주일 배포 코드량 2배, 리뷰 시간 절반, 그리고 치명적 문제와 핵심 비즈니스 로직에 집중하기가 오히려 쉬워졌다. 스킬이 prix 온톨로지의 domains와 tdw를 참조하기 때문에 스프린트가 반복될수록 판단의 정밀도가 올라간다.

┌─────────────────────────────────┐
│  Model     AI 모델 자체          │  코드를 생성하는 주체
├─────────────────────────────────┤
│  Harness   컨텍스트 전달 레이어  │  CI, 테스트, 리뷰 프로세스
├─────────────────────────────────┤
│  Ontology  판단 기준·운영 맥락   │  이 코드가 배포 가능한가
└─────────────────────────────────┘

#6

Caruso — Semantic, Kinetic, Dynamic Layers
Palantir — Dev vs Delta

#6-1

요즘 개발자 채용공고에 FDE(Forward Deployed Engineer)가 흔히 등장한다. 팔란티어에서 나온 직무 모델로, 고객사 현장에 직접 들어가서 요구사항이 아니라 요구사항 이전의 문제를 찾는 사람이다. SI에서 고객은 요구사항의 권위자다 — “이게 필요하다”고 말하면 만들어준다. FDE는 “그게 정말 당신이 필요한 건가”를 묻고 문제를 다시 정의한다. 오래 쌓인 업무 방식, 당연하게 여겨 더 이상 보이지 않는 마찰, 잘못된 원인 귀속은 요구사항 안에 들어오지 못한다. FDE가 가져오는 건 요구사항이 아니라 제품이 가정한 세계와 고객의 실제 세계 사이의 간극이다.

이 모델로 무엇을 할 것인가에 따라 갈린다. 성장 모션으로 쓰면 — 온보딩 가속, 도입 확대, 마찰 제거 — 유효하지만 비싼 CS에 가깝다. 현장에서 만들어낸 것이 사람 안에 쌓이고, 그 사람이 나가면 사라진다. 해자 모션으로 쓰려면 질문은 하나다 — 고객이 자신의 지식 구조를 만들 때, 그것이 우리 제품 어디에 담기는가. 팔란티어는 답을 갖고 있었다. 제품 자체가 그 공간이었다. Foundry의 Ontology Manager에서 고객은 자기 도메인 구조(Object Type, Property, Link Type, Action Type)를 직접 정의한다. Salesforce에서 Account가 뭔지 Salesforce가 결정했다면, Foundry에서는 Patient가 뭔지, Diagnosis와 어떤 관계인지를 고객이 결정한다. 구조는 Semantic(고객 정의) / Kinetic(개념 ↔ DB 연결) / Dynamic(권한·워크플로우)의 세 계층이고, FDE는 이 분업을 수행하기 위해 필요한 직무였다. 제품이 FDE를 만든 것이다.

이 구조 차이가 전환 비용의 성격을 바꾼다. Salesforce를 떠날 때 잃는 건 설정이다. 구조 자체는 다른 CRM에 그대로 다시 쓸 수 있다. Foundry는 다르다. 온톨로지를 JSON으로 export할 수 있다고 명시하면서도 같은 문서에 “내보낸 JSON 스키마에 장기적으로 의존하지 말 것”이 적혀 있다. 더 본질적으로는 JSON을 가져가도 그것이 실행되는 환경(Kinetic의 데이터 매핑, Dynamic의 권한·로직)은 가져갈 수 없다. 떠날 때 잃는 건 설정만이 아니라 그 설정이 기반한 도메인 모델 자체다. 구조의 주인이 누구냐가 해자의 성격을 결정한다.

지금 AI 회사들이 FDE를 채용하면서 이 조건을 갖추지 않는 경우가 많다. AI 솔루션 배포는 그 자체로 고객의 지식 구조를 만드는 작업이 아니다. 고객의 지식은 시스템 프롬프트 어딘가에, RAG DB 구석에, 파인튜닝 데이터 안에 흩어진다. 고객이 자기 구조를 볼 수 없고, 고칠 수 없고, 가져갈 수도 없다. FDE를 보내도 현장에서 발견한 것이 돌아올 곳이 없다. FDE는 채용 문제가 아니라 제품 설계 문제다. 그럴듯해 보이는 건 대개 결과다. 결과를 복사하면 원인 없는 결과를 만들려는 것이다.

#7

좋은 회사를 가려고 노력하기 보다는, 지금 있는 곳을 좋은 회사로 만드는 사람이 되어야 한다.
대개 문제는 사람보다는 구조의 문제인 경우가 많은 것 같다. 그리고 인식했다면 직접 고칠 줄도 알아야 한다.