시작

가이드라인은 왜 필요한가

사람들이 쓰는 테크 제품에 내 손으로 직접 문구를 써넣고 가이드를 작성해 제공하는 건 신나면서도 긴장되는 일이다. 적어도 내가 아는 한, 디지털이건 아날로그건 세상의 찬사 속에 시대를 풍미하는 제품이나 서비스가 텍스트가 허술한 경우는 없다. 짱짱하고 세련되게, 띄어쓰기 하나 부호 하나 허투루 쓰지 않은 집요한 말끔함이 전반에 흐른다.

이런 수준을 구현하려면, 또는 지향한다면, 스킬이나 감각만으로는 부족하다. 특히 테크 제품은 기능 뒤의 기술을 설명하고 그 효용 가치를 전달해야 하기 때문에 더더욱 라이터의 기술(technique)적 정교함을 필요로 한다. 그리고 그 정교함은 한 사람의 로컬 드라이브, 즉 머릿속에만 있어선 안 된다. 개인에게 귀속되는 스킬이 아닌 팀에 귀속되는 규칙으로 약속되고 공유돼야 한다.

가이드라인은 어떻게 생겼나

라이팅 가이드라인은 테크 프로덕트를 둘러싼 각종 텍스트를 어떤 지향과 규칙에 따라 작성할 것인지를 문서화해 놓은 것이다. 제품 UX 문구, 헬프센터의 사용자 가이드와 개발자 가이드, 플레이북과 트러블슈팅, 블로그같은 마케팅 콘텐츠 등이 그 대상이다.

가이드라인을 공개해 놓은 글로벌 빅테크 기업들을 기준으로 보면, 보통 Design System 안에 Content Guidelines 같은 이름으로 들어가 있다. UX 라이팅의 매개인 UI 컴포넌트의 경우 디자인 스펙을 코드와 함께 명시하고, UX 맥락에 따른 컴포넌트의 용법과 문구 작성 지침을 함께 정의해둔다. 보이스앤톤, 문체, 문장부호, 표기, 서식 등 일반 규칙은 Foundation > Content 같은 메뉴에 둔다.

“Content”라고 하면 다양한 형태의 콘텐츠를 포괄하기 때문에 우리는 일단 UX 문구와 사용자 가이드로 범위를 제한하고 “Product Writing” Guidelines라는 좁은 이름을 택했다. “Style” Guide라고 부르는 경우도 있는데 형식적 측면에 국한된 것처럼 들려서 좋은 명칭은 아니라고 생각한다. 라이팅은 의도와 전략의 매개이지 형식이나 미감만의 그릇은 아니기 때문이다.

출발

레퍼런스

리서치는 이전 회사에서 처음 가이드라인 수립을 추진할 때 많이 했었다. 당시 Google, Apple, Slack, Mailchimp, Intuit 등 테크 기업부터 영국 정부와 미국 정부에 이르기까지 20개 정도 되는 레퍼런스를 검토했다. 그중 가장 유용하게 참고했던 건 Microsoft, Atlassian, Shopify 였다. 이 세 곳의 가이드라인은 아마 거의 모든 페이지를 열어봤을 것 같다. 이렇게 빠짐 없고 상세한 가이드라인이 공개돼 있다는 건 큰 행운이다. 대기업이니까 투입할 인력도 있고 그만큼 완성도도 높겠지만, 공개는 또 다른 차원의 문제라 고마움과 함께 리스펙트를 느끼는 대목이다.

물론 이들은 영어를 기준으로 수립됐기 때문에 국내 레퍼런스도 찾아봤다. 하지만 상세한 정도나 전반적 완성도가 아쉽기도 했고, 주요했던 금융 서비스와 내가 종사하는 B2B SaaS 간 성격 차이도 컸다. 결과적으로, UX 라이팅 뿐만 아니라 사용자 가이드를 포함한 프로덕트 콘텐츠를 포괄적으로 다루는 해외 가이드라인을 주로 참고했다. 나머지는 우리의 실무 지식과 경험으로 채워나갔다.

초점과 목표

팀 관점

팀 초기에 수립해 둔 가이드라인도 이미 존재했고, 세세하게 명문화되지 않은 규칙들도 그간 상당 부분 내재화되어 있었다. 작업에 착수할 당시 팀원 한 명은 3년차 재직 중이라 다양한 태스크와 케이스를 많이 다뤄봤고, 다른 한 명은 영문 전담이라 일관된 규칙을 나름대로 수립하며 유지하고 있었다. 팀 리드로 합류한 나는 팀에서 작성하는 거의 모든 콘텐츠를 밀도 높게 리뷰하면서 기준을 구체화하고 합을 맞췄다.

가이드라인 수립은 일차적으로 우리가 이미 적용하고 있던 내재화된 규칙을 명문화하는 목적이 컸다. ‘이미 잘 하고 있는데 손도 많이 가는 일을 굳이 벌려야 하나’ 하는 의문이 없었던 건 아니다. 그러나 장기적으로 AI를 활용해 업무 효율을 높이고 우리가 정말 하고 싶은 '꿈의 프로젝트'들을 하려면 반드시 필요한 일이라고 확신했다.

라이팅은 업무의 정교성이나 실질 책임 범위에 비해 적은 인력으로 운영될 때가 많다. 사실은 must-have인 많은 일들이 이런저런 실무에 치여서 nice-to-have로 밀려나고, 근본적인 임팩트는 요원해지는 게 현실이다. 자잘하게 부서지는 자투리 시간을 모아야 덩어리 시간을 확보할 수 있다. 어떤 정보든 문서화되면 활용도가 급격히 높아진다.

회색지대도 문제였다. ‘마침표를 어디서 찍고 어디서 안 찍을지’처럼 사소하지만 그때마다 고민돼서 논의로 이어졌던 것들도 규칙으로 못 박고 싶었다.

회사 관점

팀 내부의 효율화보다 더 중요하게 생각한 건 사내 인식의 변화였다. 윤문, 리뷰, 특히 '스타일'에 관해 대화를 나누다 보면 비슷한 오해가 반복된다는 인상을 받곤 했다. '그게 뭔지는 잘 모르겠지만 라이터들이 중요하게 여기는 심미적 기준이나 취향'처럼 여겨지는 것 같았다.

이용약관 다르고 온보딩 프롬프트 다르듯이, UX 문구나 가이드도 목적과 성격에 맞는 스타일로 작성되어야 의도한 정보와 가치가 사용자에게 효과적으로 전달된다. 그런데 정확히 어떤 방식으로 그게 가능해지는 건지가 눈에 안 보이니까 막연하고 추상적인 영역, 다르게 말해서 영향과 기여가 명확하지 않은 영역으로 치부되는 듯했다.

라이팅은 사용자 경험의 문제다. 제품 가치와 회사 신뢰도의 문제다. 라이팅이 제품에 어떤 영향을 미치고, 그 영향은 구체적으로 어떤 설계를 통해 작용하는지를 지침으로 가시화하고 싶었다. 또한, 그 영향은 세세한 규칙으로 정의된 톤과 용어, 작성 방법을 통해 다양한 채널에서 일관되게 구현될 수 있다는 걸 문서로 보여주고 싶었다. 그 문서가 마침내 존재하게 되면 PM의 기획서, PD의 디자인 문서뿐만 아니라 CS의 안내 문서와 CM의 블로그처럼 제품의 언어를 다루는 모든 터치포인트에서 공통의 기준을 공유할 수 있게 될 터였다.

과정

아이디어 수렴

팀이 함께 기존 가이드라인을 검토하며 1) 필요한데 빠져 있거나, 2) 실제 적용해보니 수정이 필요하거나, 3) 기준이 모호해서 구체화가 필요하거나, 4) 그간 리뷰 과정에서 반복 등장했던 내용을 생각나는 대로 기록했다. 당시 팀 구성이 절반은 3년차, 절반은 6개월차여서 축적된 경험과 신선한 안목이 모두 작용할 수 있었다.

라이터라면 공감할 것들을 몇 개만 예를 들어보자면,

• UI 레이블은 [ ] / ' ' / 볼드 중 뭘로 표기할 거냐
• 약어 표기와 영문 병기는 대체 어떻게 하는 게 맞냐
• 해주세요 / 해 주세요 띄어쓰기 둘 다 되는데 뭘로 할 거냐
• (사용자가 정보를) 등록/입력/추가 중 뭐가 맞냐
• (넣은 정보와 설정을) 저장/완료/적용 중 뭐가 맞냐
• 플레이스홀더 텍스트 매번 써야 되냐 (아..)
• 에러메시지 좀 통일하자
• 문장으로 쓸 거냐 명사구로 쓸 거냐
• 스낵바 메시지엔 마침표 찍을 거냐 말 거냐 (아아...)

논의와 결정

그렇게 모은 사안들에 대해 서로 자유롭게 의견을 남긴 다음, 2주에 걸쳐서 1차 논의를 나눴다. 실무 중에 경험한 사례를 들어가며 각자 나름대로 세운 기준을 공유하고 잠재적 문제를 살폈다. 어떤 것들은 빠르게 결론이 났지만, 뭐가 더 좋은 선택인지 계속 고민되는 것들도 있었다. 정보가 부족해서 판단하기 어려운 건 담당을 나눠서 추가 리서치를 하기로 하고 2차 논의로 넘겼다.

어느 정도 논의가 마무리되자 가이드라인의 구조를 짜기 시작했다. 실제 작성을 시작하면 더 정교하게 논의하고 다듬을 수 있을 터였다. 기존 가이드라인에서 살릴 것, 레퍼런스에서 가져올 것, 논의 과정에서 새로 필요성이 대두된 것 등을 모두 포함해서 뼈대를 세웠다.

작성

기존 가이드라인에서 보완하면 되는 공통 원칙과 맞춤법, 표기, 서식 등 형식 관련 항목을 먼저 썼다. 상대적으로 부담이 적어서 시작으로 삼기 좋았다. UI 컴포넌트 섹션은 이전 회사에서 작성해 본 경험이 있기 때문에 빠르게 할 수 있으리라 생각했다. 그때는.

그러다가 팀에 변동이 생겼다. 회사에도 변화가 많던 시기라 평소의 2배 가까이 일이 늘면서 관성을 잃고 말았다. UX 라이팅에 국한되는 UI 컴포넌트 섹션 없이 어떻게든 반기가 넘어가는 시점에 일단락을 짓고 싶었으나 그마저도 하지 못했다. 이렇게 물르기 시작하면 마음이 더 느슨해질 것 같아서 종국에는 원래대로 UI 컴포넌트까지 모두 마무리지어서 완성도 높게 내야겠다고 결심했다.

중간 리뷰

완성도 70% 정도 됐을 때 중간 리뷰를 열었다. 확실히 좋은 예시, 나쁜 예시까지 추가해서 작성한 지침을 놓고 논의를 다시 여니 더 구체적이었다. 프로젝트가 여러 달에 걸쳐 진행되는 동안 팀이 모두 가이드라인을 염두에 두고 일한 덕에 그간 모인 생각으로 더 뾰족하게 다듬을 수 있었다. 반대로 어떤 것들은 1, 2차 논의 때 꽤나 엄격한 기준으로 의견이 오갔는데, 현실을 반영하는 방향으로 완화되기도 했다.

계속 작성

여름에는 내고 싶었는데 어느덧 가을이 됐다. UI 컴포넌트 섹션에 주력했다. 재택하는 목요일에 집중하려고 수요일까지 다른 업무들을 싸악 해치우기도 했지만, 무리한 여름이 지나고 번아웃과 함께 가을을 맞고 보니 마음만큼 진도가 나가지 않았다. 예시 찾는 게 제일 품이 많이 들었던 것 같다. 빠른 이해를 위해서는 예시가 꼭 필요한데 딱 맞는 예시 찾기가 쉽지 않았다. 좋은 레퍼런스는 많았지만 우리 맥락에 맞게 각색하느라 한 땀 한 땀 지난한 과정이 이어졌다.

끝이 보이는 것 같기도

연내에 꼭, 꼬옥, 마무리하고 싶었지만 연말은 연말의 사정이 있는 법. 한국인에겐 설이 진짜 새해의 시작 아니겠냐는 동료들과 나 자신의 정신승리로 조급함을 좀 내려놓고 다시 한 꼭지씩 차근차근 채워나가는 데 집중했다.

용법이 엄격하게 정의되어 있지 않은 컴포넌트들이 일부 있었는데, 툴팁, 팝오버, 노티피케이션, 콜아웃, 얼러트 배너 같은 ‘알림과 피드백’ 컴포넌트들이 특히 그랬다. (전문가용 B2B SaaS는 알릴 게 많다ㅠㅠ) 용법과 구성에 따라 문구 작성 전략도 달라지는 문제가 있어서 차후에 PD팀과 세부 논의를 나누기로 하고 기본 규칙만 실었다. 다행히 마지막 15~20% 작업할 때는 완성도 높게 정제된 지침들이 그간 꽤 쌓여서 AI 도구로 전보다 훨씬 빠르게 완성해 나갈 수 있었다.

드디어 배포

음력 2025년의 마지막 근무일, 아직 남아있는 일들이 가슴을 조여왔지만 박상영 선수처럼 ‘할 수 있어, 할 수 있어’를 되뇌이며 집중. 오후 4시에 드디어 작성을 마쳤다. 하지만 문서를 새 페이지에 옮기고, 히스토리를 위해 릴리즈 노트 비슷한 것도 쓰고, 일부 섹션을 PDF로 변환해서 Gem도 하나 만들고 테스트까지 해본 다음, 슬랙 채널 공지로 공식 배포하는 데까지 4시간이 더 걸렸다. 9시에 배포하고 퇴근하니 1년 넘게 작업한 가이드라인을 정말로 다 끝냈다는 게 안 믿기고 뿌듯해서 잠을 다 설침.

결과

형태

회사가 노션을 써서 가이드라인도 노션 문서로 만들었다. 작업 버전은 긴 페이지 하나로 오른쪽 목차를 이용해 점프해 다니며 작성하곤 했는데, 그렇게 방대한 내용을 긴 스크롤로 보게 하는 건 너무 가독성이 떨어질 터였다. 그래서 배포 버전은 제미나이의 조언에 따라 항목별로 페이지를 만들고 대표 페이지에 링크로 심어서, 대표 페이지를 목차처럼 구성했다.

이 문서와 함께 Gem을 만들어 배포했다. 원래 목표한 것처럼 제품 언어를 다루는 누구나 활용할 수 있도록 UI 컴포넌트와 메시징 전략을 제외한 가이드라인으로 윤문 봇을 만들었다. 배포하기 전에 가볍게 테스트해 봤을 땐 나쁘지 않았는데, 피드백을 받아서 실제로 쓰기에 충분히 유용하도록 개선하려고 한다.

구성

이미 잘 적용하고 있는 규칙들을 명문화하는 데 그치지 않고, 제품 언어의 완성도를 끌어올리기 위해 더 나아가야 할 부분까지 담았다. 가이드라인이 있다고 바로 말끔하게 써내진 못하겠지만, 아무리 훌륭한 베스트 프랙티스라도 손에 잡히는 형태로 존재해야 실무에 적용할 수 있다.

특히 공들인 것들

목적

라이팅이 어떻게 제품과 회사에 기여하는지, 이 가이드라인이 어떻게 그런 역할에 맞닿아 있는지를 밝히고 싶었다. 우리 자신도 일깨울 겸, 입 옆에 두 손을 모아 외치는 마음으로 작성한 첫 머리.

• 사용자 여정의 모든 터치포인트에서 사용자 중심의 언어로 소통하며 사용자 경험을 개선합니다.
• 제품의 복잡한 기능을 이해하기 쉽게 해설하여 사용자에게 제품의 가치를 효과적으로 전달합니다.
• 효과적 정보 설계로 전환율 개선, 이탈율 감소, 고객 지원 비용 절감 등 비즈니스 목표에 기여합니다.
• 풍부한 정보, 일관된 보이스, 전략적 메시징으로 제품 신뢰도와 브랜드라는 무형자산을 축적합니다.
• 데이터와 피드백을 바탕으로 제품 상태와 사용자 수요에 맞게 콘텐츠를 지속적으로 최적화합니다.

원칙

라이팅의 방식이 어떻게 사용자 경험 개선과 제품 가치 전달로 연결되는지를 담았다. 총 11개 중에 아래 4개는 특별히 포함한 내용이다. 기술이나 기능을 설명하려 드는 건 공급자 관점이고, 사용자에게는 지금 눈 앞의 문제를 해결하는 데 도움이 되는지가 가장 중요하다는 기본을 상기하고자 했다. 또 지나치게 단순화된 ‘간결함’이나 ‘친근함’의 함정에 대해서도 귀띔해 두고 싶었다.

• 실용적 관점에서 사용자의 목표 달성에 도움이 되는 정보를 선별해 내용을 구성합니다.
• 이미지 등 시각 자료는 보조 수단으로 활용하고, 텍스트만으로 완전한 정보가 전달되게 작성합니다.
• 가능한 한 짧고 간결하게 표현하되 사용자가 내용을 이해하는 데 필요한 정보는 충분히 제공합니다.
• 팩트는 팩트, 지시는 지시로 표현합니다. 부드러운 톤을 구사하려고 의미나 의도를 변형하지 마세요.

문장 원칙

이러한 방향성은 기본적인 문장 규칙으로 구체화됐다. 별 것 아닌 것 같지만 모호하게 뒀다가는 크고 작은 오해와 혼란을 불러일으킬 수 있는 것들이다. (실제로는 여러 개로 나뉘어 쓰인 규칙을 여기서는 편의상 항목별로 이어 붙였다.)

• (어미) 사용자가 취해야 할 행동은 ‘~ㅂ니다’를 사용하지 말고 ‘~하세요’를 써서 명확하게 지시한다. 제품이 지원하지만 사용자가 반드시 하지 않아도 되는 내용에 대해서만 ‘~ㄹ 수 있습니다’를 사용한다.
• (능동과 피동) 능동은 사용자가 서술된 행동의 주체가 누구인지 알아야 할 때 사용한다. 피동은 서술된 행동의 주체가 중요하지 않거나, 오히려 불필요한 정보일 때 사용한다. 주로 시스템 동작 등 주어가 명확하지 않거나 행동보다는 결과가 중요할 때 사용한다.
• (긍정과 부정) 안 되는 상태를 부정문으로 설명하기보다 사용자가 취해야 할 행동을 긍정문으로 제시한다. 금지나 제한, 주의나 경고를 강조하기 위해 예외적으로 이중 부정을 사용할 수 있다.
• (필수와 권장) 따르지 않았을 때 오류나 문제가 생길 경우 ‘반드시’, ‘해야 합니다’, ‘하지 않아야 합니다’ 등으로 확실하게 표현한다. 오류나 문제가 생기진 않지만 잠재적 혼란을 줄이고 최적의 결과를 얻는 데 필요한 경우에는 ‘권장’한다.

권장 표현과 유사 표현

혼란하게 뒤섞이고 있던 표현들을 모두 정리해서 사용 시점 및 조건까지 명시했다. 복잡한 UX나 개념 설명에서 고민하며 판단해야 했던 것들인데 이번에 정리해서 팀이 모두 속 시원해했다. 작업 버전에선 중간쯤에 끼어 있었는데 배포 버전에선 효용을 생각해서 앞쪽에 배치했다.

UI 컴포넌트

팀이 UX 라이팅을 맡은 지 그리 오래 되지 않아서 아직 전문화되지 못하고 회색지대에 걸쳐 있는 부분이 많았다. 16종 컴포넌트의 역할과 작동 방식에서 시작해 실제 예시와 함께 구체적인 작성 지침을 썼다. 우리 디자인 시스템에 맞춰 하나하나 조사하고 사례 찾으며 정제하느라 쉽진 않았지만, 이미 연구와 실제를 통해 고도화된 해외 레퍼런스 덕을 가장 많이 본 부분이다.

회고

1년이 걸릴 줄 왜 몰랐을까

후딱 할 수 있을 줄 알았다. 이전 회사에서 업무가 붕 떴을 때 한두 달 바짝 리서치부터 UI 컴포넌트 섹션 작성까지 해봤던 터라 두 번째는 더 빨리 할 수 있을 줄 알았는데. 덩치가 훨씬 컸다. 로드맵이니 팀 운영이니 원래 하던 일 다 하면서, 변화무쌍 회사 파도 다 타가면서 병렬로 추진한 거라 일정한 동력과 속도를 유지하기 어려웠다. ‘너무 오래 걸리는 거 아니냐’는 피드백도 있었지만, 한 꼭지만 써보면 다들 이해하실 수 있으리라.

완벽주의는, 그래서 의미가 있었을까

아아, 나이 먹고 나아진 줄 알았는데. AI에 먹여서 초안 작성 봇이나 윤문 봇으로 활용할 생각을 처음부터 갖고 있었기 때문에 가이드라인의 완성도가 떨어지면 AI 답변을 실제로는 쓰기 어려울 게 예상됐다. AI 설정 지침이 자세하다고 해서 답변 품질이 반드시 좋아지는 건 아니더라는 얘기를 팀 동료가 해줬는데도, 나 자신과 타협이 잘 안 됐다. 우리 팀이 어떤 일을 어떻게 하는지를 가시화할 수 있는 드문 기회이기도 했다. 앞단에 고생하면 뒤로 갈수록 편해진다는 믿음이 있는 만큼, 사계절을 꼬박 거쳐서 일단락한 가이드라인으로 다음 단계는 훨씬 빠르고 쉬워지리라 믿는다.

코끼리 다리 만지듯

작성의 규칙들을 언어로 구체화하는 작업은 단순히 미래의 시스템을 만드는 일만은 아니었다. 과거의 경험을 재평가하는 계기이기도 했다. 명문화되어 있진 않았지만 우리가 이런 걸 축적된 감각으로 잘해오고 있었구나. 어떤 게 더 나은 방향인지 비슷하게 고민하며 공유하고 있었구나. 반대로 너무 감으로만 일해왔다고 느껴지는 부분도 있었다. 이걸 이렇게 뜯어봤으면 매번 그렇게 고뇌하며 썼다 지웠다 하지 않아도 됐을 텐데. 감각은 언어로 정의되며 또렷해졌고, 그렇게 찾은 언어는 다시 감각을 벼리는 기준이 됐다.

나눠서 할 수 있었을까

중간에 몇 번 고민했다. 나눠서 할 순 없을까. 초기 논의와 결정 단계에서는 다같이 참여해도 작성하는 과정은 한 사람이 맥락을 잡고 끌고 가야 일관성을 확보할 수 있는 일이었다. 고민도 많이 필요하고 일종의 시스템을 만드는 일인데다 3명 뿐인 팀이라 내가 주로 작업하고 리뷰로 논의하는 방식을 택했다. 방법이 없진 않았을 텐데 그 방법을 구상하고 실행하는 것 또한 일이었고, 동료들에게 부담을 나누기가 어렵게 느껴지는 상황이기도 했다. 다같이 참여하며 경험을 공유하는 것과 다같이 참여하느라 다같이 바쁜 것. 아직도 잘 모르겠다.

AI는 하여간 잘 ‘먹여야’ 한다

잘 정제된 케이스가 쌓이자 AI에 샘플과 레퍼런스를 주고 빠르게 써낼 수 있었다. 일하는 방식이 빠르게 변모하고 있는 상황에서 AI가 잘 읽을 수 있는 원천 자료를 갖추는 일이 중요해졌다. 레퍼런스를 검토할 때 가장 아쉽고 의아했던 부분 중 하나가 모호한 설명이었다. 지침이 구체적으로 표현되어 있어야 여러 사람이 이해할 수 있겠다는 접근은 아래 ‘다음 단계’로도 이어진다.

다음 단계

AI-Native 기반 2.1 업데이트

2.0을 배포해서 행복했지만 이미 2.1 계획이 다 있었다. 프로덕트 콘텐츠를 소비하는 방식뿐만 아니라 제품 사용 방식 자체가 AI를 통하는 방향으로 나아가고 있다 보니 애초에 AI가 잘 쪼개고 추출할 수 있게 작성하는 게 중요해졌다. 3월 초 지식 공유 세션에서 발표할 목적으로 AI-Native Knowledge Engineering 방법론을 파는 중인데, 여기서 도출할 작성 지침을 추가로 반영하고 AI 에이전트를 구성하려고 한다.

제품 용어집 업데이트

원래는 용어집을 같이 배포하고 싶어서 중간에 병렬로 작업하기도 했지만 마무리짓지 못했다. 제품 용어집 없이 가이드라인만으로는 AI 활용에 한계가 있다. 내부 용도까지 고려해서 넓은 범위로 마스터 버전을 만들고, 그 중 일부를 사용자 제공용으로 공개하려고 한다. 이것 역시 AI 에이전트의 중요한 학습 자료가 될 것이다.

UI 컴포넌트 작성 지침 고도화

2.0에서 매듭짓지 못한 부분이다. PD팀의 디자인 시스템 고도화와 타이밍이 맞아서 UI 컴포넌트의 용법과 구성에 관해 통합 지침을 논의할 수 있게 됐다. 통합 지침이 나오면 UX 라이팅 및 i18n 플러그인 구현까지 이어질 수 있을 거라 기대된다.

꿈의 프로젝트

제품 내 AI 챗봇의 답변 품질 제고 차원에서 핵심 콘텐츠 80편을 개선하는 게 우리 팀 상반기 목표다. 80편을 3명이서, 기존 업무와 병렬로, AI가 읽기 좋게 수정하고 리뷰해서 배포하려면 6개월은 걸릴 거다. 가이드라인은 바로 이런 “꿈의 프로젝트”에 투입할 시간을 확보하기 위한 초석이었는데 드디어 퍼즐을 맞춰볼 시간이다.