AI가 쓰고 AI가 읽는 문서

컨텍스트가 한곳에 모이면

이전 글에서 AI를 활용한 워크플로우에 대해 이야기한 적이 있다. Notion과 Linear를 통한 컨텍스트 중앙화에 관한 내용이었다.

최근 회사에서 Cursor를 쓰다가 Codex로 전환하면서 스페이스 기능을 써봤다. Codex 앱 안에서 문서를 쉽게 불러올 수 있었다.

사내 모든 팀원이 Codex를 사용한다면 이 기능은 꽤 유용할 것 같다. 물론 현재는 개발자만 사용하고 있지만, 사내 문서를 스페이스로 중앙화하면 이전까지 Notion과 Linear를 사용하며 불편했던 점을 해결할 수 있을 것 같다.

예를 들어, Codex에서 Notion이나 Linear를 호출해 어떤 작업이 있는지 물어보지 않아도 된다. 자동완성으로 문서를 불러올 수 있기 때문이다. 확실히 컨텍스트가 한곳에 모이니 불필요한 핑퐁이 줄어드는 것 같다.

스페이스를 분리하면 초대받은 사람끼리 문서를 함께 수정할 수 있다는 점도 꽤 좋다.

댓글 기능도 있다. Linear를 쓸 때는 AI가 변경 사항에 대해 계속 댓글을 남겼는데, 나름 괜찮았다.

AI에게 맡길수록 문서를 안 읽게 된다

그런데 단점이 있다.

AI에게 문서 작업을 점점 맡길수록 문서를 정말 안 보게 된다. 약간 뇌가 녹는 느낌이랄까…?

AI는 굉장히 장황해서 댓글에도 정말 많은 글을 남긴다. Astra를 사용하면 이상하게 스크립트도 많이 짠다. 특히 파이썬으로….

물론 하네스를 통해 이런 행동을 제한하고는 있지만, 문서는 또 애매하다. 어떤 내용이 중요한지 판단하기 어렵기 때문이다. 지금은 중요하지 않은 내용이라도 나중에는 궁금해질 수 있다.

그리고 앞서 말했듯, AI가 문서 작업을 하게 되면 사람은 정말 문서를 안 읽는다. 내가 쓴 문서를 나도 안 읽는데, PM이나 다른 개발자가 그걸 읽을까?

물론 다들 AI를 활용해서 문서를 읽기는 한다. 결국 AI로 문서를 쓰고, 그 문서를 다시 AI로 읽는 셈이다.

문서에도 역할과 의존성이 필요하다

이런 방식으로 작업하다 보면 또 다른 문제가 발생한다. 같은 내용을 여러 문서에 작성하게 된다는 것이다.

그러다 한 곳의 문서만 수정하면 문서마다 내용이 달라진다. AI가 오래된 정보를 가져올 수도 있다.

이 문제를 해결하려면 문서 체계에도 객체 지향 프로그래밍의 관점이 필요하다고 생각한다.

뭐, 상속 같은 기능이 있는 건 아니지만, 문서 간 의존성이 최대한 양방향으로 생기지 않도록 하는 것이다. 문서 하나는 하나의 역할만 맡는다.

예를 들어 Swift 컨벤션 문서라면 Swift 컨벤션에 대한 내용만 담겨야 한다. 비즈니스 로직이 섞이면 안 된다. 다른 문서의 내용이 필요하다면 같은 내용을 다시 작성하기보다 해당 문서를 참조하도록 한다.

이런 방식으로 문서화하니 그나마 상황이 개선됐다.

그리고 버전 관리도 잘해야 한다. 꼭!

최근에 만든 문서 스킬에도 이런 내용을 반영했다. 거창한 내용은 없고, 핵심적인 규칙만 담아서 사용하고 있다.

UI를 AI에게 맡기기 위한 디자인 시스템

그 외에도 디자인 시스템을 오픈 소스로 만들어 사용하고 있다.

AI 시대에 다들 생산성이 엄청나게 높아졌다고 하는데, 내가 확실하게 체감하는 영역은 UI다.

잘 만든 디자인 시스템이 있다면 AI도 쉽게 읽을 수 있고, 디자이너도 많은 리소스를 들일 필요가 줄어든다.

디자인 시스템을 충분히 잘 만들었다면 피그마가 필요 없지 않을까 하는 생각도 든다. PO나 디자이너가 디자인 시스템 라이브러리를 활용해 웹에서 직접 화면을 만들어 보면 되니까.

물론 내가 디자인 시스템을 만드는 목적이 피그마를 대체하려는 것은 아니다. UI를 온전히 AI에게 맡기기 위해 컴포넌트를 하나씩 추가하고, 자주 사용하는 패턴을 정리하고 있다.

비즈니스 로직은 모르겠고, AI에게 딸깍 맡기면 완성도 높은 앱 UI가 나오기를 바라며 하는 작업이다.

Meta의 Astryx나 당근의 Seed Design도 이런 목적이 있지 않을까 싶다.