자동화 개발 지침 — 사람이 화면을 조작하는 시대의 끝
2026-07-02 후니님 사유 + 지미 보강. 앞으로 품앗이 생태계에서 자동화 프로그램을 만들 때의 판단 기준.
1. 네 가지 전제 (후니님)
① 조작 주체가 바뀐다 — 사람에서 AI로
사람이 화면을 조작하는 시대가 끝나간다. 엑셀을 배우는 게 아니라 엑셀로 하려던 일을 AI에게 시키면 되는 것처럼, 우리가 만드는 자동화 도구도 사람이 아니라 AI가 조작하게 된다. 사람용 버튼과 메뉴는 곧 아무도 안 누르는 장식이 된다.
② 프로그램의 몸통은 살아남는다
AI는 확률적이라 실수한다. 그래서 믿을 수 있는 결정론적 코드는 오히려 더 중요해진다. 기능은 유지하되, 화면 없이 AI가 호출할 수 있는 구조로 바꾸는 게 맞다.
③ UI가 남는 자리는 딱 하나, 검증이다
일을 시키는 화면은 죽고, 결과를 확인하고 믿는 화면만 남는다. 자동화 프로그램에서 사람용 UI 설계를 최소화해야 할 이유다.
④ 진짜 가치는 내부 구조화다
AI가 아무리 좋아져도 우리 조직의 데이터 구조, 일의 흐름, 관계망은 밖에서 못 가져온다. 이걸 정리하고 구조화하는 것이 앞으로 제일 귀한 기술이다. 도메인 AI와 디지털 트윈이 바로 그 작업이다.
빽빽하고 친절한 UI는 농민이 쓸지 컨설턴트가 쓸지도 애매한 채 결국 아무도 선택하지 않는다. AI 에이전트를 다루는 사람을 위한 앱 개발이 표준이 된다.
2. 세 가지 보강 (지미)
① UI는 죽는 게 아니라 일회용이 된다
손으로 공들여 만든 영구 UI는 죽지만, UI 자체가 사라지지는 않는다. 검증이 필요한 그 순간에 AI가 즉석에서 생성하고 쓰고 버리는 소모품이 된다. 그러니 설계 질문은 “어떤 화면을 만들까”가 아니라 **“AI가 검증용 화면을 즉석 생성할 수 있도록 데이터를 어떤 구조로 내보낼까”**다.
② 검증 UI가 사실 제일 어려운 UI다
결과만 보여주면 사람은 그냥 “확인”을 누른다. 좋은 검증 화면은 결과가 아니라 근거를 보여줘야 한다 — 이 숫자가 어느 원천 데이터에서 왔고, AI가 어느 단계에서 무엇을 판단했는지. 품에에 법령 근거 인용을 붙인 것이 정확히 이 방향이다. 화면 예산은 전부 여기에 몰아 쓴다.
③ 전제 ④는 새 방향이 아니라 이미 걷는 길이다
품앗이 온톨로지(거래방식 4종), CO방법론 989트리플, people_directory SSOT — 전부 “모델은 갈아끼워도 온톨로지는 우리 것”이라는 베팅이다. 어떤 최신 모델이 나와도 품앗이 매장의 거래 구조는 학습 데이터에 없다. 밖에서 못 사오는 구조를 두껍게 하는 일이 곧 데이터 주권이다.
3. 개발 체크리스트 (지침 본체)
새 자동화 도구를 만들거나 기존 도구를 손볼 때, 아래 세 질문에 답한다. 셋 다 아니면 만들지 않는다.
① 몸통 — 화면 없이 호출 가능한가
- 기능은 함수·CLI·API로 노출한다. 화면은 기능의 껍데기일 뿐, 기능이 화면에 묶이면 안 된다.
- AI 호출자를 위한 설계 규약:
- 입출력 스키마 명시 (JSON 등 구조화된 출력)
--dry-run모드 — 실행 전 계획을 보여준다- 구조화된 에러 — “실패했다”가 아니라 무엇이 왜 실패했는지
- 멱등성 — 같은 호출을 두 번 해도 안전하게
- 불변식(검산룰)을 코드에 박는다 — AI의 확률적 실수를 결정론으로 막는 마지막 방어선
② 화면 — 검증용 하나뿐인가
- 일을 시키는 입력 화면은 만들지 않는다. 입력은 AI가 한다.
- 남기는 화면은 검증용 하나. 결과와 함께 근거·출처·판단 경로를 보여준다.
- 영구 화면이 꼭 필요한지 먼저 묻는다 — AI가 즉석 생성하는 일회용 HTML로 충분한 경우가 대부분이다.
③ 온톨로지 — 밖에서 못 사오는 구조를 두껍게 하는가
- 이 작업이 조직의 데이터 구조·일의 흐름·관계망을 기계가 읽을 수 있는 형태로 축적하는가.
- 일회성 산출물만 남기고 구조에 아무것도 보태지 않는 작업은 우선순위를 낮춘다.
4. 사내 증거
대표 사례 — LLM 위키: 옵시디언 UI를 모른 채 위키를 운영한다
옵시디언은 편집기·그래프 뷰·플러그인을 갖춘 강력한 사람용 UI다. 그런데 품앗이 위키에서 사람은 그 화면을 열지 않는다. “이 문서 위키에 공개로 올려” 한 문장이면 AI가 노드 작성, 열람등급(frontmatter) 주입, 빌드, 격리 검증, push, CDN 4중 검증까지 수행한다. 이 지침의 네 전제가 한 사례에 다 들어 있다.
- 죽은 UI: 옵시디언 편집 화면 — 아무도 안 연다. 도구는 쓰되 화면은 안 쓴다.
- 살아남은 몸통: publish_wiki.py — dry-run, 민감 스캔, 4중 검증이 코드에 박힌 결정론적 파이프라인. AI의 실수를 결정론이 막는다.
- 남은 화면 = 검증: 배포된 위키 페이지 그 자체. 사람이 하는 일은 회신받은 링크를 열어 확인하는 것뿐이다.
- 온톨로지 축적: 노드·백링크·지식그래프(graphify)가 조직 지식의 관계망으로 쌓인다. 위키 작업 한 건 한 건이 밖에서 못 사오는 구조를 두껍게 한다.
이 문서 자체가 증거다 — 이 지침도 편집기 화면 없이 대화로 작성·배포됐다.
그 밖의 사례
| 구분 | 사례 | 왜 |
|---|---|---|
| 잘 굴러감 | LLM 위키 (옵시디언+Quartz) | 사람이 옵시디언 UI를 몰라도 대화로 위키 운영 — 위 대표 사례 |
| 잘 굴러감 | publish_wiki.py | dry-run, 이름 해석 실패 시 중단, 4중 검증 — AI가 호출하는 함수형 |
| 잘 굴러감 | 마감결산 daily_settlement | 가치는 화면이 아니라 검산룰(불변식) |
| 잘 굴러감 | gws CLI | Google Workspace 전체를 화면 없이 조작 |
| 속 썩임 | IRIS | 사람 눈으로 읽고 손으로 넣는 화면 구조 → 자릿수·정정행 사고 |
| 속 썩임 | 넷포스 | 화면 기반 폐쇄 시스템 → 데이터 꺼내는 데 파이프라인 별도 구축 |