[5월 TIL #8] 목표를 적는 것도 기술이다

오늘 새로운 실험 방향을 잡았다. 문라이트가 어떤 인터페이스여야 하는가를 AI로 빠르게 탐색해보는 실험이다.
 
실험 개요

1. 왜 — 문라이트는 사람의 이해를 대체하는 도구가 아니라 증강하는 도구여야 한다. Engelbart의 H-LAM/T 개념처럼.
2. 무엇을 — 다이나믹 인터페이스 방향 탐색. 고정 → 커스텀 → 다이나믹 인터페이스로 문라이트가 어떻게 보일 수 있는지 여러 버전 생성.
3. 어떻게 — Claude /goal + Codex /goal로 매일 30분~1시간, 5일간 약 10개 버전 생성. 다음 주에 팀이 UX 관점으로 논의.
4. 마인드셋 — 완벽히 이해하고 시작하려 하지 말 것. 우연을 통한 발견이 목표.

근데 /goal에 목적 적는 게 왜 이렇게 어렵지?
/goal은 Claude Code와 Codex에 최근 생긴 기능으로, 완료 조건을 적어두면 AI가 그 조건이 충족될 때까지 여러 턴에 걸쳐 자율적으로 작업을 이어간다. “계속해줘”를 반복하지 않아도 된다는 점에서 긴 작업에 유용하다.
 
막상 써보니 엉뚱한 결과가 나왔다. 목표를 언어화하는 게 생각보다 훨씬 어려웠다. 왜 그런지 생각해봤다.
 

---

1. 욕구는 있는데 언어가 없다

사람이 뭔가를 원할 때 욕구는 두 층위가 있다.

• “이런 느낌이었으면 좋겠다”는 감각적인 층위
• “이런 조건이 충족되면 된다”는 언어적인 층위

보통 전자는 있는데 후자가 없다. 더 정확히는, 감각은 어렴풋이 있는데 그 감각을 목표나 조건으로 바꿔 적는 언어가 부족하다.
그러면 이런 일이 생긴다.

• 내가 원하는 것을 충분히 담아 전달하지 못한다
• AI는 비어 있는 부분을 자기 방식으로 채운다
• 결과물은 그럴듯하지만, 점점 내 손을 떠난다

결국 문제는 AI가 못 알아듣는 게 아니라, 내가 원하는 것을 AI가 다룰 수 있는 형태로 아직 충분히 번역하지 못했다는 데 있었다.
 

2. 원인을 찾아보니

원인은 크게 두 가지였다.
 
첫째, 목표를 세우는 내재화된 방법이 없었다.
SMART, OKR, 역산법 같은 것들이 있다는 건 알고 있었지만, 이걸 일상이나 프롬프팅에 적용해본 적은 거의 없었다. 그러다 보니 /goal을 적을 때도 내가 원하는 상태를 어떤 구조로 정리해야 하는지 막막했다.
 
→ 그래서 목표를 적을 때 방법론을 의식적으로 빌려 써보기로 했다. 처음부터 자연스럽게 잘 쓰려고 하기보다, SMART든 역산법이든 일단 틀에 맞춰 적어보는 연습이 필요하다. 방법론이 내재화돼야 목표를 적는 게 자연스러워진다.
 
둘째, 테스크에 대한 경험이 부족했다.
다이나믹 인터페이스를 많이 만들어보거나 봐야 “좋은 게 뭔지”에 대한 감각이 생긴다. 감각이 없으면 욕구도 선명해질 수 없고, 욕구가 선명하지 않으면 언어도 나오지 않는다.
 
→ 그래서 “이건 아닌데”의 반복을 너무 싫어하지 않기로 했다. 그게 현타처럼 느껴지지만, 사실 내 기준이 조금씩 좁혀지고 있다는 신호다. 동시에 무작정 많이 만들어보기만 하는 게 아니라, 좋은 인터페이스 사례를 리서치하면서 간접 경험도 쌓아야겠다. 막막하다는 느낌이 들면 “나는 못하겠다”가 아니라, 아직 충분히 보지 못했고 비교할 기준이 부족하다는 신호로 받아들이기로 했다. 더 보고, 더 만들어보고, 더 비교하면서 감각을 키워가야겠다.

---

마무리

목표를 적는 것도 기술이다.
좋은 목표는 처음부터 머릿속에 완성된 문장으로 떠오르지 않는다. 많이 보고, 만들어보고, 실패하고, 방법론을 적용해보는 과정에서 점점 선명해진다. 이번 실험에서 중요한 건 완벽한 /goal을 한 번에 쓰는 게 아니라, 내가 원하는 것을 AI가 다룰 수 있는 형태로 번역하는 연습을 시작했다는 점이다.. 굿..!!