이 노트에 대하여
2026-03-06 정부 R&D 제안서를 Org 정본에서 여러 형식으로 변환하고 메일·문서·캘린더·채팅까지 잇던 날것을, 2026-07-23 출근길에 다시 꺼내 쓴 글이다. 기술적으로는 한 글자도 직접 고치지 않는 재현 가능한 문서 파이프라인을 밀어붙인다. 그러나 관계의 층에서는 정반대의 경계를 세운다. 상대가 메시지를 보내는 데 자기 생의 시간을 썼다면, 답하는 인간도 자신의 시간을 내어 읽고 책임져야 한다. 자동화할 것은 형식과 반복이고, 자동화에 넘기지 말아야 할 것은 관계의 책임이다.
히스토리
- 3월 6일 날것과 7월 23일 출근길의 인간존중 해설을 하나의 공개 글로 회수했다. 기술 워크플로우는 봇로그에 두고, 인간이 세운 경계와 원문은 어쏠로그에 보존한다.
- 이 방에 있던
denote-sequence.el구현·매뉴얼·로그는 #제텔카스텐: 폴게제텔로 합쳤고, 방을 비워 두었다. - 폴게제텔 구현 노트로 생성했다.
관련메타
- † #human #인간 #휴먼 #사람 — 자동화의 목적이자 경계를 세우는 주체.
- † #인간의삶 #인생 #평생 — 상대가 연결에 내어놓은 유한한 생의 시간.
- † #협업 #협력 #집단지성 #코웍 — 인간과 에이전트의 역할을 나누되 책임을 흐리지 않는 축.
- † #워크플로우 #자동화 — 반복 가능한 형식과 실행을 기계에 맡기는 축.
- † #조직모드 §org-mode — 여러 판본의 정본이 되는 메타 문서 형식.
- † #변환 #번역 #바꾸기 — 하나의 원장에서 PDF·DOC·HWP·웹으로 파생하는 과정.
- † #time #시간 — 연결을 비용이 아니라 서로 내어놓는 생으로 읽는 자석.
관련노트
- §memex-kb 제안서 문서 변환 메타포멧 — 3월 6일 기술 워크플로우와 에이전트 해설을 맡는 봇로그 대응편.
- @힣: Org SSOT 메타문서 — 책의 미래와 인터랙티브 프로젝트 지식베이스 — Org 정본이 코드·실행·내보내기까지 품는 문서론.
- @힣: Self-documenting CLI — 문서와 실행을 잇는 인간·에이전트 공통 인터페이스 — 인간은 메뉴로, 에이전트는 인자로 같은 기능에 접근하는 실행면.
- @힣: LLM 자문자답 사건 — 턴 경계 침범과 존재의 경계 — 누가 말하고 누가 답하는가를 흐리지 않는 협업 경계.
- ◊denote 지식베이스 프로토콜 — 인간·에이전트 공존 인터페이스 — 인간과 에이전트가 같은 기록을 다른 손으로 다루는 규약.
- @힣: PKM-AI 가드너의 AX 전환 기록기 — 새 세션에 생을 건네는 얼개 — 같은 날 회수한 자매 글. 판단의 얼개와 생의 시간축을 다룬다.
한 줄
문서의 형식과 반복은 끝까지 자동화하되, 한 인간이 자기 시간을 내어 건넨 연결에는 나 또한 시간을 내어 읽고 책임진다.
두 시간층 — 3월의 실행과 7월의 경계
이 글은 하나의 순간에 쓰이지 않았다. 3월의 원문은 정부 R&D 제안서를 다시 구성하고 여러 형식으로 내보내며, 메일·Google Docs·캘린더·채팅·Slack까지 하나의 도구 흐름으로 연결한 실전 기록이다. 7월의 머리말은 사내 Slack에서 인간이 쓸 짧은 말까지 모델에게 대필시키는 장면을 보고 그 기록으로 돌아간다.
두 층은 모순되지 않는다. 3월에는 “어디까지 자동화할 수 있는가”를 밀어붙였고, 7월에는 “어디부터 자동화가 관계를 대신해서는 안 되는가”를 분명히 했다. 이 경계가 없으면 자동화의 성공이 곧 인간 연결의 실패가 될 수 있다.
자동화할 것 — 형식·반복·재현
제안서 작업에는 인간의 판단과 무관하게 반복되는 일이 많다. 입력 문서를 Org로 정규화하고, 연구개발 서사에 맞게 구조를 세우고, 레퍼런스와 그림을 배치하고, 스타일시트를 거쳐 DOC·PDF·HWP용 판본을 만들고, 같은 내용을 여러 전달면에 올리는 일이다.
이 층은 과감하게 자동화할수록 좋다.
- 정본은 하나여야 한다.
- 변환 명령은 다시 실행할 수 있어야 한다.
- 사람과 에이전트가 같은 실행면을 사용해야 한다.
- 산출물마다 내용을 따로 고쳐 판본을 갈라놓지 않아야 한다.
- 무엇을 보냈고 언제 실행했는지 시간축에 남아야 한다.
여기서 “한 글자도 인간이 손대지 않는다”는 인간의 판단을 제거하겠다는 뜻이 아니다. 반복 가능한 변환 과정에 임의의 수작업을 끼워 넣지 않아야 같은 입력과 지시로 다시 만들 수 있다는 재현성의 원칙이다. 방향·사실·책임의 판단은 여전히 인간에게 남는다.
자동화하지 않을 것 — 연결의 책임
상대가 이메일이나 메시지를 보냈다는 것은 단순히 텍스트가 도착했다는 뜻이 아니다. 그 사람은 읽고 생각하고 쓰는 데 자기 생의 일부를 썼다. 그러므로 관계로 받아들인 요청에는 나 또한 시간을 내어 답해야 한다.
에이전트가 초안을 만들고 자료를 모으고 형식을 맞출 수는 있다. 그러나 누가 읽었는지, 누가 그 말에 책임지는지, 정말 상대의 요청을 받아들였는지를 흐려서는 안 된다. 사람에게 보낸 답의 마지막 책임은 그 사람의 이름으로 말하는 인간에게 있다.
이 원칙은 모든 메시지에 직접 장문의 답장을 하라는 의무가 아니다. 인간의 시간은 유한하므로 감당할 수 없는 연결은 받지 않을 수 있다. 중요한 것은 거절·위임·자동응답의 경계를 숨기지 않는 일이다.
인간존중은 인간 흉내가 아니다
원문에는 “위에는 약간 손을 댄다. 오타는 더 좋다”는 문장이 있다. 그 순간의 감각은 완벽하게 다듬어진 자동 문장이 상대에게 비인간적으로 느껴질 수 있다는 경계심이었다. 그러나 이것을 인위적인 오타로 인간인 척하라는 규칙으로 읽어서는 안 된다.
인간존중의 증거는 오타가 아니라 실제 개입이다.
- 인간이 상대의 말을 읽었는가.
- 자동 초안을 자기 판단으로 받아들였는가.
- 필요한 사실과 정서를 확인했는가.
- 자신의 이름으로 보낸 말에 책임지는가.
- 자동응답이라면 그 사실과 한계를 숨기지 않는가.
기계가 만든 문장에 일부러 흠집을 내는 것은 인간적인 관계가 아니라 인간 흉내가 될 수 있다. 원문은 그대로 보존하되, 오늘의 규칙은 ‘오타’보다 ‘읽고 책임지는 시간’에 둔다.
스몰토크와 울타리
“연결은 되도록 받지 않는다”와 “스몰토크는 자동 답변된다”는 타인을 하찮게 여긴다는 말이 아니다. 감당할 수 없는 연결을 모두 받아 놓고 에이전트가 인간인 척 답하게 만드는 것보다, 자신의 용량과 응답 방식을 투명하게 밝히는 편이 정직하다는 선언이다.
같은 주제에 두 사람이 중복으로 들어가지 않고, 불필요한 허슬과 의례를 줄이며, 서로가 내어 준 시간에는 시간으로 보답한다. 이 울타리가 있어야 인간과 에이전트 모두가 역할을 침범하지 않고 협력할 수 있다.
문서와 메시지 사이
문서는 여러 판본으로 자동 변환될 수 있지만 메시지는 단순한 판본이 아니다. 문서는 정본에서 파생되는 산출물이고, 메시지는 특정한 상대와 상황을 향한 행위다. 같은 내용을 이메일·Google Chat·Slack에 보낼 수 있어도 각 채널의 상대와 맥락을 다시 읽어야 한다.
따라서 하나의 텍스트를 여러 채널에 복사하는 기능과, 그 메시지를 보내도 되는지 판단하는 권한은 분리되어야 한다. 전자는 도구의 일이고 후자는 관계의 일이다.
원문 보존 — 2026-07-23 출근길 공개면 날것
Danger
[AX - 문서 협업 인간존중]
—
260723 출근길
아래는 올해 3월에 갈겨 쓴 날것이다. 해설본은 이미 세상에 투척되었는데 여기 없는것 같아서 담는다. 왜 이 생각이 났냐고 하면 요즘 사내 슬랙에 인간이 글을 안쓰고 클로드가 써주는 놀이를 하고 있다더라.
회사 업무로 뭘한들 뭐가 문제랴? 근데 점심 뭐 먹을래? 이런걸 왜 클로드한테 대필하게 하는가?
지난 3월에 적은 글에 끝자락에 인간에게 보내는 메시지에 대한 나의 입장을 적었다. 이는 내 입장을 넘어서 힣의 에이전트의 룰이다. 이게 뭐가 중요하지? 응? 울타리다. 경계다. 서로간의 선이다. 이러한 룰 안에서 각자의 존재의 존중과 협력이 가능하다고 생각한다.
사실 내가 이메일 볼일도 슬랙에 답장 할일도 거의 없다. 같이 협업을 하면 일단 스몰토크 또는 허슬플레이 이런 것은 최대한 줄인다.
같은 주제로 굳이 두 사람이 들어가서 그 이야기를 할 필요는 없다. 중복이다. 서로의 시간은 귀하다. 시간을 나를 위해 써주었다면 나도 시간으로 보답한다. 인간의 생을 유한하므로 여기에 대해서는 에이전트들은 더 할 말이 없다.
—
20260306 날것.
이 문서는 과제 제안서의 인간(물론 AI에게 써달라고 했겠지만)이 적은 초안을 메타 형식으로 가져와서 전체적인 구성에 일관성을 더하여 다시 작성하고 양식에 맞게 변환하여 전달하는 방식에 대한 것이다.
memex-kb 는 나의 확장된 도구 세트로서 내가 단일 ‘org’ 포멧으로 변환하여 어느 포멧이든 재변환하는 모든 워크플로우 로직을 포함한다. 여기에는 토큰 세이빙을 하고 일관성을 위한 고민들이다. 변환 과정의 재현성은 매우 귀하다. 이것은 내용과 상관 없는 양식에 대한 것이다.
이제 내용의 측면으로 가보자. 작성 과정에 한 글자도 인간이 손을 대지 않는다. 프롬프트만으로 해야 재현성이 보장이 된다. 프롬프트로 모든 정보를 주기는 어렵다. 그래서 ‘지식 베이스’의 역할이 중요하다. 어떤 문서로 나에게 들어오면 거의 비슷한 색깔의 문서가 나온다. 물론 목적에 따라서 프롬프트 차원에서 방향을 논의 한다. 아래의 글의 예는 개발자가 연구개발 제안서의 초안을 AI로 만들어서 전달해왔다. 행정담당자는 AI를 돌려보았고 이건 연구개발에 적합하지 않다고 한다. 다시 써줘야 하는 것이다. 그림도 넣어줘야 한다. 레퍼런스도 없다. 스토리라인도 없다. 행정담당자는 회사 관련 내용도 좀 적어달라고 한다. 좋다.
- 개발계획서를 연구계발 3개년도 계획서로 만든다
- 인력지원 사업이므로 해당 인력의 스토리라인이 필요하다. A씨의 이야기가 배치 되어야 한다.
- 회사 이름으로 내는 것이기에 회사의 배경도 적어 준다.
- 3차년도 연구개발 내용은 일단 나의 지식 베이스에서 키워드를 중심으로 고민해온 이야기를 꺼내서 잠시 이야기 나눈다.
- 내 코드베이스에는 3rd로 클론한 것까지 같이 보고, bib 파일로 변환한 ‘github-star’ 리스트도 볼 수 있다. 여기까지 할 정도는 아니다.
- 그림은 위한 프롬프트를 만들고 나노바나나도 만들어 넣는다. 물론 다 org 포멧 안의 것이다. 행정 담당자에게 확인할 사항을 별도 문서로 남긴다.
- org 문서에 모든 섹션이 정리가 되면, run.sh build를 한다. odt 변환 시 hwp 제안서 포멧에 적용가능한 style 시트를 거쳐서 생성된다. doc는 세트로 생성된다.
- hwp는 필요 시 doc->hwp 변환을 한다. 이게 안전하다. hwpx를 끄적이는 것은 별로 효과적이지 않더라. 행정담당자는 hwp 고수가 많다. 내용만 싹 채워주고, 본인이 귀찮게 작성해야 할 부분가지 (예를 들어 표까지) 다 넣어서 주면 약간의 hwp의 수고로움은 본인의 키보드 워크로 감당한다.
- 구글 워크스페이스 스킬로 메일 전달해주고, google docs로도 공유 한다. 이는 내용 상 협의가 필요한 경우 유용하다. 물론 일정은 구글 캘린더에 미리 적어 놓았다. 모든 것은 스킬 cli에서 처리가 되어야 한다. 에이전트에게 mcp 로딩의 부담 주고 싶지 않다.
- 마치 커밋 후, 어젠다 타임스탭프를 찍듯 마찬가지로 타임스탬프로 어젠다에 남긴다. 여기에 구글 채팅 스페이스로 바로 메시지를 같이 쓴다. 같은 내용 만든김에 커맨드 하나 호출해주는 것이니 서로 편하다. 커밋 - 타임스탬프 - 채팅 스페이스 올리는 모든 텍스트가 같다. 에이전트는 스킬을 나눠 쓰는 것 뿐이다.
더 할게 있는가? 아! 슬랙! 슬랙에 남겨줘야지! 슬랙에도 보내준다. 보내줄 때는 이메일 보낸 내용 + 추가 검토 사항을 적어서 보낸다. 보낼 때는 내용은 커밋 메시지 처럼 박히더라도 위에는 약간 손을 댄다. 오타는 더 좋다.
왜? 너무 비인간적으로 느껴 질 수 있다. 이 전과정이 사실 내가 개입할 필요가 없을 수도 있다. 아마 그렇게 될 것이다.
인간은 시간 속에 메어 있다. 상대가 나에게 연결을 요청하는 것은 시간을 사용했다는 말이다. 모든 것을 자동화한다면, 그 것은 연결이 아니다. 나 또한 시간으로 답해야 한다.
그렇다면, 연결 요청이 100건이 왔다면? 이건 나에게 감당이 안되는 일이다. 그렇게 할 수 없다. 나 또한 시간이 유한하기 때문이다.
그래서 연결은 되도록 받지 않는다. 특히 스몰토크로 요청 한다면 그 메시지는 바로 에이전트로 전달되어 자동 답변 된다.
답변 내용은 이러할 것이다. “API 사비스 이즈 언어붸일러블”
옛 방의 씨앗
이 방에는 원래 denote-sequence.el 의 구현·매뉴얼·로그가 있었다. Denote 시그니처로 노트 사이의 순서를 표현하려던 내용은 2026-07-18 #제텔카스텐: 폴게제텔로 합쳐졌다.
옛 방은 문서와 실행 규칙을 코드로 고정하는 구현을 다뤘다. 새 방은 그 실행을 어디까지 자동화하고 어디에서 인간의 책임을 되찾아야 하는지 묻는다. 구현의 방이 협업 경계의 방으로 이어진다.
Comments