AI가 문서를 만드는 시대가 왔는데, 그 문서에 피드백을 남기는 방식은 아직 2010년에 머물러 있습니다.

AI에게 기획서를 요청하면 몇 분 만에 완성도 높은 HTML 프로토타입이 나옵니다. 슬라이드도, 보고서도, 대시보드도 마찬가지입니다. 그런데 그 결과물을 동료에게 검토받으려는 순간, 우리는 갑자기 원시적인 노동을 시작합니다. 화면을 캡처하고, 그림판으로 빨간 동그라미를 치고, PDF로 내보내서 메신저에 첨부합니다. 만드는 데 3분, 피드백을 주고받는 데 30분이 걸립니다.

소통과 의사결정 내용은 수많은 업무 툴에 이렇게 분산되어 있습니다.

"기획자님, 피그마에 댓글 확인 부탁드립니다."
"슬랙에 댓글 남겨 놓았어요."
"노션에 댓글 남겨 놓았습니다."

여기에 최근에는 클로드, 챗GPT, 제미나이 같은 AI 툴들이 추가되었습니다. 대화 하나하나에 결정의 맥락이 담기지만, 그 맥락은 각 서비스 안에 갇힌 채 흩어집니다.

물론, 개발자들의 업무는 Git이나 코드 리뷰 도구를 통해 많은 것들이 개선되었습니다. 그렇다면 비개발 직군은요? 기획자도, 디자이너도, 마케터도 여전히 이 파편화 속에 남아 있습니다.

저는 이 파편화가 단순한 도구 부족의 문제가 아니라, 우리가 협업을 바라보는 방식 자체의 문제라고 생각하게 됐습니다. 이 글은 그 문제의식에서 출발해 swy.note에 도달하는 과정의 기록입니다.

1. 정보의 감옥: 왜 우리의 문서는 AI가 읽지 못하는가

1989년, 팀 버너스리는 CERN에서 「Information Management: A Proposal」이라는 제안서를 씁니다. 훗날 월드와이드웹이 되는 이 문서의 출발점은 거창한 기술 비전이 아니었습니다. 지극히 실무적인 문제였습니다.

"사람이 계속 바뀌는 조직에서 정보가 끊임없이 유실된다."

그가 내놓은 해법이 하이퍼텍스트 — 오늘날의 HTML입니다.

37년이 지난 지금, 우리는 같은 문제를 다시 마주하고 있습니다. 다만 이번에 정보를 유실시키는 주범은 사람의 이직이 아니라 문서 포맷 그 자체입니다.

.pdf, .pptx, .docx 같은 바이너리 포맷은 사람이 '보기'에는 좋지만, 기계가 '읽기'에는 폐쇄적입니다. 콘텐츠와 데이터가 뒤섞여 있고, 구조를 해석하려면 전용 프로그램이 필요하며, 파생 정보를 만들어내기 어렵습니다. AI가 문맥을 파악하고 정보를 재조합하는 시대에, 이 포맷들은 사실상 정보의 감옥입니다.

반면 HTML은 다릅니다. 웹의 표준 언어이자, 구조(시맨틱)와 콘텐츠가 분리된 개방형 포맷이며, 대부분의 AI가 별도 설명 없이도 잘 다루는 문서 형식입니다. 실제로 이미 벌어지고 있는 일이기도 합니다 — 여러분이 AI에게 "프로토타입 만들어줘"라고 했을 때, 눈에 보이는 결과물을 즉시 확인하고 싶다면 결국 HTML로 돌아오게 됩니다.

그래서 저의 첫 번째 가설은 이렇습니다.

AI 시대에 어쩌면, 문서의 표준은 .html이 더 나은 답이 아닐까?

2. 실시간 협업의 역설: 더 빨라졌는데 왜 더 느려졌는가

"실시간 협업 도구도, 소통 도구도 이렇게 많은데, 왜 다시 html이에요?"

이 글을 여기까지 읽으셨다면 한번쯤 드실 법한 질문입니다. 피그마, 슬랙, 노션, Google Docs... 실시간을 무기로 내세우는 툴은 이미 차고 넘칩니다. 저희도 이 도구들의 헤비 유저입니다. 그런데 도구를 깊게 쓸수록 이상한 현상을 발견했습니다. 실시간성이 오히려 지식 생산을 방해하는 순간들입니다. 저는 이것을 '실시간 협업의 역설'이라고 부릅니다.

첫째, 상태의 모호성. 실시간으로 수정되는 문서에는 '검토 중인 버전'과 '확정된 버전'의 구분이 없습니다. 검토자가 의견을 다는 도중에 문서가 바뀌는 '타겟 이동(Moving Target)' 현상은 소통의 정합성을 무너뜨립니다.

둘째, 컨텍스트의 파편화. 대부분의 도구에서 댓글은 문서의 물리적 위치에 결합되어 있습니다. 문장이 수정되는 순간 댓글은 엉뚱한 곳을 가리키고, 우리는 '댓글이 원래 가리키던 곳'을 다시 찾는 소모적인 작업을 반복합니다.

셋째, 가장 심각한 문제 — 기록의 상실. Figma 시안이나 실시간 문서에서 수십 개의 댓글을 주고받으며 의사결정을 내렸다고 합시다. 그 결과물을 보관하기 위해 PDF로 다운로드하는 순간, 댓글 히스토리와 의사결정의 맥락은 증발합니다.

이것은 저 혼자만의 체감이 아닙니다. Harvard Business Review에 실린 「Collaborative Overload」(Cross, Rebele & Grant, 2016)는 관리자와 직원이 협업 활동에 쓰는 시간이 지난 20년간 50% 이상 급증했고, 많은 기업에서 구성원이 시간의 약 80%를 회의와 요청 응대에 소비한다고 보고합니다.

그리고 2019년, Ink & Switch 연구소의 「Local-first Software」(Kleppmann 외)는 이 문제의 구조적 원인을 정확히 짚었습니다. Google Docs 같은 클라우드 앱은 실시간 협업을 가능하게 하는 대신, 데이터 저장을 서버에 중앙화함으로써 사용자의 소유권과 주체성을 빼앗는다는 것입니다.

3. 현상: AI 시대에 우리는 어떻게 일하고 있는가

기록과 실제 상황으로 돌아가볼게요. 요즘 저는 AI를 정말 많이 활용하고 있습니다. 기획자이자 디자이너이자 마케터로 일하다 보니, 이런 경험이 반복됩니다.

그런데 여기서 피드백을 주고받으려니 막막해졌습니다. 파일은 하나인데, 의견은 카톡으로, 슬랙으로, 통화로 흩어집니다. 결국 다시 스크린샷을 찍고, PDF로 바꾸고, 메신저에 붙여넣는 그 과정으로 돌아가게 됩니다.

4. 그래서, swy.note를 제안합니다 — 탄생 배경과 핵심 기능

그래서 저희는 발상을 뒤집었습니다. 실시간성을 포기하는 대신, 지식의 안정성을 선택하는 것입니다.

swy.note는 .html 파일 위에 바로 댓글을 다는 크롬 익스텐션입니다. 작동 방식은 단순하지만, 그 단순함 안에 위의 철학이 전부 들어 있습니다.

댓글이 파일 안에 삽니다. swy.note로 단 댓글은 댓글 데이터와 읽기 전용 뷰어까지 통째로 HTML 파일 내부에 내장됩니다. 파일 하나가 곧 문서이자, 댓글이자, 뷰어입니다.

받는 사람은 아무것도 설치할 필요가 없습니다. 파일을 여는 것만으로 모든 댓글과 답글 스레드를 볼 수 있습니다. 가입도, 로그인도 없습니다.

그리고 이 모든 것이 만드는 가장 강력한 순환이 있습니다 — AI 워크플로우입니다.

  1. AI가 .html을 만든다
  2. swy.note로 팀의 피드백을 파일에 단다
  3. 그 파일을 그대로 AI에게 다시 건넨다
  4. AI는 본문과 모든 댓글을 맥락째 읽고 다음 버전을 만든다

스크린샷도, 피드백 정리 문서도, "3페이지 두 번째 문단 말인데요"라는 설명도 필요 없습니다.

5. 기술적 제안: 무엇이 이걸 가능하게 하는가

swy.note의 철학을 실제로 지탱하는 건 네 가지 기술적 선택입니다.

1) 문서의 단위는 '버전'입니다. 문서는 수정될 때마다 새로운 버전이 됩니다. 검토자는 움직이지 않는 스냅샷 위에서 의견을 답니다. 개발자들이 Git으로 해온 것을 비개발 직군의 문서에 그대로 적용합니다.

2) 주석은 좌표가 아니라 요소에 붙습니다. 문장을 드래그하거나, 버튼·카드·이미지 같은 요소를 직접 클릭해 댓글을 답니다. W3C의 Web Annotation Data Model(2017년 권고)에 기반한 이 접근은, 어떤 화면 크기에서 열어도 댓글이 정확히 제 자리를 가리킵니다.

3) 의사결정은 문서와 함께 보존됩니다. 댓글 데이터가 별도 서버가 아니라 문서 안에 존재한다면, 툴이 사라져도, 인터넷이 끊긴 폐쇄망에서도, 10년 뒤에 파일을 열어도 — 그때의 논의와 결정은 문서와 함께 남아 있습니다.

4) 인터넷이 없어도, 데이터의 주체는 나입니다. 서버가 없습니다. 단 1바이트도 여러분의 기기를 떠나지 않습니다. Local-first 원칙 그대로, 데이터의 주인은 서비스가 아니라 여러분입니다.

6. 마치며: 속도가 아니라 방향

swy.note는 무료입니다. 앞으로도 그럴 것입니다. 저희가 이 도구로 증명하고 싶은 것은 비즈니스 모델이 아니라 하나의 방향이기 때문입니다.

기술이 부족해서 실시간 협업을 못 하는 것이 아닙니다. 소통의 본질을 지키기 위해 실시간 협업을 의도적으로 거부하는 것입니다. 우리는 AI-Native로 나아가고 있는 이 시대에, '소통과 기록의 본질'이라는 문제에서 이 작은 도구를 만들었습니다.

AI가 만든 HTML 파일이 있으신가요? 지금 바로 코멘트를 붙여보세요.

참고 문헌

  1. Tim Berners-Lee, Information Management: A Proposal, CERN, 1989. https://www.w3.org/History/1989/proposal.html
  2. Rob Cross, Reb Rebele & Adam Grant, "Collaborative Overload", Harvard Business Review, Jan–Feb 2016. https://hbr.org/2016/01/collaborative-overload
  3. Martin Kleppmann et al., "Local-first Software", Onward! 2019 (ACM SIGPLAN). https://www.inkandswitch.com/essay/local-first/
  4. W3C, Web Annotation Data Model, W3C Recommendation, 23 Feb 2017. https://www.w3.org/TR/annotation-model/