Furigana - 이제 한자 때문에 멈추지 마세요

• 일본어를 배워본 경험이 있는 분이라면 공감하시겠지만 일본어 읽기 학습의 가장 큰 장벽은 한자입니다. Furigana는 문맥에 맞는 적절한 후리가나를 자동으로 달아주는 것을 시작으로 해서, 궁극적으로는 일본어를 읽을 때 느끼는 심리적 부담감을 콘텐츠에 대한 흥미와 기대감으로 바꾸고 일본 드라마나 애니를 챙겨보는 것처럼 자연스럽게 일본어 텍스트를 즐길 수 있는 학습 경험을 제공하는 것이 목표입니다.
• 이미 존재하는 후리가나 생성 프로그램이 있고 저도 필요에 의해서 사용해 보았지만, 사전적인 정의에만 기반하다 보니 문맥에 맞지 않는 독음을 표시하는 경우가 많았습니다. LLM의 도움을 받으면 이런 문제를 쉽게 해결할 수 있겠다고 생각했습니다.

• LLM을 써서 쉽게 할 수 있을 거라고 예상했지만 다양한 문맥 별로 자연스러운 후리가나를 생성하는 것은 생각보다 단순하지 않았습니다. 반복적인 실험을 통해 모델이 집중할 수 있는 최적의 요구사항과 문맥 단위를 검증하고 시스템의 전후 처리 과정을 통해 성능을 개선하는 등 신경써야 할 부분이 많았습니다. 모델 업데이트가 빠르게 이루어지고 있는 만큼 앞으로도 계속될 이 과정을 효율적으로 운영하는 방법을 탐구해 나가고 있습니다.
• 사용자에게 긍정적인 읽기 경험을 지속적으로 제공하기 위해서 가장 중요하게 생각하는 부분은 양질의 콘텐츠 확보입니다. 이 목표에 공감하는 일본 현지 크리에이터들과 오리지널 콘텐츠 라이브러리를 구축하기 위해 협업을 진행하고 있습니다. 교육을 위한 학습 자료가 아닌 크리에이터의 시선을 담은 독창적인 텍스트를 제공하고, 사용자 또한 참여자로서 자신만의 텍스트를 올릴 수 있는 커뮤니티형 콘텐츠 플랫폼을 지향하고 있습니다.

• 한자 때문에 멈추는 일 없이 일본어를 읽고 싶다

AI Filmmaking

• AI로 어느 정도까지 퀄리티 있는 스토리텔링 영상을 만들 수 있을지 실험 중입니다. AI는 제작 단계의 도구로서의 역할만 담당하고, 결과물에서는 AI가 돋보이지 않는 채로 사람들에게 재미와 감동, 그리고 메시지를 전달할 수 있는 작가주의적 filmmaking을 지향합니다.

• 자체 시나리오 창작 및 AI 프리비즈 워크플로우 구축에 매진 중이며 빠른 시일 내에 단편 영화와 드라마의 형태로 선보이기 위해 준비하고 있습니다.

AI Meeting Cheat-sheet 기획 및 개발

• Yess의 타겟 고객은 서비스 비즈니스를 제공하는 에이전시, 스튜디오 등입니다. 이들이 프로젝트 성사 과정에서 겪는 실제 문제에 깊게 파고들어 피처를 기획 및 개발했습니다.

• 일정 기간 동안 개발자와 기획자의 구분 없이 모든 팀원이 기획을 진행했습니다. 그 과정에서 고객들이 세일즈의 가장 앞 단계인 미팅 준비에 가장 많은 시간을 할애하고 그만큼 어려움을 느낄 것이라는 가설을 세웠고, 인터뷰를 통해 실제 문제임을 확인했습니다. 이 문제를 해결하기 위해 Meeting Cheat-sheet이라는 주제로 Lo-fi 와이어프레임을 직접 그리면서 기획하였습니다.
• AI로부터 실시간으로 받는 데이터를 심리스한 스트리밍 UI/UX로 제공하기 위해 기술적으로 여러 방법을 시도했습니다. 내부적으로 사용중인 텍스트 에디터와 웹소켓 라이브러리에 의존성이 있다 보니 복잡도를 제거한 환경에서 테스트해보는 것이 도움이 되었습니다. 팀원들과 해커톤에 참가해 Vercel AI SDK를 활용해 보거나 rxjs로 자체적인 스트리밍 모듈을 구현해 보기도 했습니다. 그러나 실제 제품에 적용하면 여전히 복잡도가 높아지고 일관적인 동작이 보장되지 않았습니다. 이를 해결하기 위해 응답에 스트리밍 관련 커서 위치 데이터가 포함되는 Server Driven 방식을 제안하였고 팀 내 논의를 거쳐 서버와 클라이언트 사이의 웹소켓 라이브러리 레벨에서 해당 작업을 수행하는 절충안을 선택 후 개선하였습니다.

• Meeting Cheat-sheet을 기점으로 고객의 세일즈 과정을 돕는 기능들인 프로젝트의 맥락 분석, 미팅 요약, 제안서 생성 등의 주요 피처들이 기획되었습니다. 이 피처들이 모여 Yess 1.0의 AI Sales Copilot이 완성되었고 Yess와 같은 도메인에서 이미 규모가 큰 서비스들이 있음에도 불구하고 AI-native로서는 첫 플레이어로 선보이는 기반이 되었습니다.
• 기획 단계에서 고객이 실제 상황에 필요로 하는 UX는 무엇일지를 가장 많이 고민했고, 네이밍에 대한 아이디어도 이런 접근을 통해 도출하였습니다.

• AI를 다룰 때 UX 목표를 정의하는 것이 중요하다는 것을 배웠습니다. AI 스트리밍을 구현하는 방법은 다양하지만 난이도와 복잡도를 기준으로 선택하기보다도 목표를 기준으로 선택하는 것이 시간을 더 절약하는 방법입니다. AI 자체도 수단에 불과하기 때문에 목표를 세분화하여 꼭 필요하고 도움이 되는 영역에서 적절하게 사용하는 것이 중요합니다.

• AI Sales Copilot 개발 기록 - (1) 기획하는 개발자
• AI Sales Copilot 개발 기록 - (2) Streaming Queue
• AI Sales Copilot 개발 기록 - (3) Delta-Driven UI

디자인 시스템 구축 및 개선

• 디자인 시스템은 웹앱 전체적으로 일관성 있고 쉬운 UI/UX를 제공함으로써 사용자를 적은 비용으로 학습하도록 돕는 도구이기 때문에 꼭 필요하다는 데 팀원 모두가 공감했습니다.
• 디자인 시스템은 퀄리티와 스피드를 모두 챙길 수 있게 해 주는 도구입니다. 매주 새로운 기능을 구현하더라도 디자인 시스템이 지원하는 영역은 큰 고민을 하지 않아도 기본적인 퀄리티를 보장할 것이고, 그걸 가져다 쓰기만 함으로써 별도의 설계나 작업에 대한 리소스가 필요 없어지기 때문입니다.

• Material 디자인 시스템을 참고하여 디자인 토큰을 정의하였습니다. 주요 컴포넌트의 경우 코어 로직에 해당하는 부분은 Headless UI 라이브러리인 Radix Primitives를 활용하고, 스타일을 커스텀하여 구현하였습니다.
• 컴포넌트를 적용하는 순서에 대해 고민하였는데, 먼저 웹앱의 모든 버튼을 새로 구현된 컴포넌트로 교체하는 작업을 진행해 보았습니다. 이렇게 하고 보니 디자인의 일관성은 보장이 되지만 작업 시간이 너무 오래 걸리는 단점이 있었습니다. 다음 작업에서는 특정 컴포넌트를 교체하는 방향 대신에 사용자가 웹앱 진입 후 처음으로 보는 1 depth 페이지들을 대상으로 디자인 시스템을 적용하였습니다.
• 유지보수 과정에서 합성 컴포넌트 패턴을 응용하여 재사용성과 편의성을 개선하였습니다.

• 디자인 시스템을 도입한 후로 시안을 스타일로 구현하는 과정에 효율이 증가하였습니다. 이전에 비해 불필요한 스타일 관련 커뮤니케이션이 확연히 줄었고, 새로운 기능들을 구현하더라도 파편화의 정도를 제어할 수 있게 되었습니다.
• 우선 순위를 고려하여 중요한 부분부터 적용하는 전략을 통해 비교적 단기간 내에 많은 개선을 이루었습니다.

• 직군을 막론하고 팀 전체가 디자인 시스템을 바라보는 관점과 개념에 대해서 싱크를 맞추어 나가는 과정이 의미 있었습니다. 특히 디자인 의도와 코드 사이의 갭이 없도록 서로 동일하게 이해하고 있는지 계속해서 확인하는 것이 중요하다는 것을 느꼈습니다.
• 디자인 시스템은 최초 구현보다 지속적으로 개선하고 유지 보수하는 것이 더 중요합니다. 그렇기 때문에 불필요한 커뮤니케이션은 최소화하더라도, 성숙한 시스템으로 발전하기 위해서 팀원들의 적극적인 리뷰와 꾸준한 개선 작업이 필요합니다.

• 합성 컴포넌트 패턴을 응용하여 디자인 시스템 개선하기

새로운 에디터 라이브러리 점진적 도입

• Yess 웹앱에서 문서 편집은 가장 중요한 기능인 만큼 에디터 라이브러리에 대한 의존도가 높습니다. 기존에 도입된 quill 라이브러리는 유지보수가 더디고, 커스터마이즈에 유연하지 않은 점 때문에 과거에 만든 포크 버전 위로 여러 기능이 덧붙여져 있었습니다. 이로 인해 정상적인 버전 관리의 혜택을 받기 어려운 형태였습니다. 게다가 포크 버전의 코드가 type strict하지 않은 점은 기능을 빠르고 안정적으로 개발하는 데 허들이 되고 있었습니다. 앞으로는 생성형 AI를 도입하여 더욱 인터랙티브한 요구사항에 대응해야 하는 상황을 고려했을 때 새로운 에디터 라이브러리 도입이 필요하다고 판단했습니다.

• ProseMirror 기반의 tiptap 라이브러리를 검증 대상으로 선정하고 몇 회차에 걸쳐 POC를 진행했습니다. 어려운 문제를 대하는 부담을 덜 수 있도록 스프린트 범위 바깥에서 페어 프로그래밍 형태로 진행했습니다.
• POC 후 실제 스프린트에서 Workflow Automation 기능의 이메일 내용 편집기를 구현하기 위해 tiptap을 부분 도입했습니다. 예상하지 못한 문제들이 발생했을 때 ProseMirror의 데이터 구조를 잘 알지 못해서 헤매기도 했지만 팀원들의 도움으로 함께 트러블 슈팅을 하면서 새로운 라이브러리의 러닝 커브를 넘을 수 있었습니다.

• 간단한 기능부터 부분적으로 도입하고 나니 핵심 기능에 대한 POC는 비교적 부담이 덜해졌습니다. 처음부터 동시 수정 및 AI streaming을 새 에디터로 구현하고자 했으면 훨씬 큰 블랙박스를 감당하기 어려워 선택하지 못했을 것입니다.
• 기획적으로 편집 가능한 영역에 대해 요구사항이 주어졌을 때 빠르게 시도할 수 있게 되었습니다. 기존의 quill 기반 모듈만 있을 때와는 달리 안정적인 타입 시스템과 긍정적인 개발자 경험의 도움을 받을 수 있는 tiptap이라는 선택지가 추가되었기 때문에 점진적으로 확대 적용하고 있습니다.

• 러닝 커브가 가파르더라도 팀의 도움으로 함께 넘으면 더 수월하고 빠르다는 것을 배웠습니다. 도움에만 의지하지 않고 스스로 노력하는 것도 중요하지만, 정말 도움이 필요할 때는 요청하는 것 역시 중요합니다. 또한 도움을 요청할 때는 문제 상황에 대해 지금까지 파악한 내용과 앞으로 어떤 부분을 해결해야 하는지를 명확하게 정리해서 전달해야 합니다.

• 새로운 에디터 라이브러리 도입 과정

Widget SDK 성능 개선

• Yess는 사용자가 자신의 웹사이트에 코드 스니펫을 심어서 고객 문의 창구로 사용할 수 있는 자바스크립트 위젯 SDK를 제공합니다. 이 위젯 내에서 고객 문의를 입력받는 Inquiry Form의 첫 로드까지 시간이 5초 정도로 긴 현상이 있었습니다. 로딩이 거의 필요하지 않은 blazingly fast한 경험을 제공하기 위해 성능 개선을 진행하였습니다.

• 위젯이 처음 구현될 당시 Inquiry Form은 별도의 단독 서비스로 제공되고 있는 기능이었기 때문에, 공개된 Inquiry Form의 URL을 iframe에 띄우는 형식으로 구현되었습니다. 다만 위젯 SDK 역시 iframe으로 동작하고 있기 때문에 이는 iframe 중첩 현상으로 인한 추가적인 네트워크 요청으로 이어졌습니다. 네트워크 요청의 응답 속도를 개선하는 것도 고려할 수 있는 방안이지만 조금 더 근본적인 방향성을 고민한 결과 모노레포 전환을 실행하기로 했습니다. Yess에는 이처럼 별도 서비스로도 동작할 수 있는 기능이 여러 개 있고 서로 연관성을 가질 가능성도 높은 Vertical SaaS 제품이기 때문에, 그 특수성을 고려하여 웹앱과 위젯이 멀티 레포로 분리되어 있던 구조를 모노레포로 통합하였습니다.

• 여러 개의 앱이 서로를 빌드 타임에 참조할 수 있는 환경이 구성되어 위젯 내 Inquiry Form의 로딩 시간이 제거되었습니다. 또한 모노레포 구조가 정착되면서 공통 코드를 관리하기 용이해졌고, 공통 코드를 기반으로 새로운 앱을 구성하고 배포 환경을 마련하는 것이 간편해졌습니다.

• 작지 않은 규모의 레거시 코드베이스에 대해 근본적인 구조 변경을 가하는 작업이었기 때문에 노가다와 예상치 못한 빌드 에러를 해결하는 과정의 연속이었습니다. 하지만 blazingly fast한 경험 제공이라는 목표가 뚜렷했기 때문에 필요한 과정으로 인지하고 팀이 함께 노력할 수 있었습니다. 개발 전략을 설득하고 실행하는 데 있어서도 working backwards 방법론이 유효하다는 것을 배웠습니다.

• 고객 경험으로부터 구현 방법 도출하기

입점 파트너 서비스 에러 핸들링 개선

• 파트너 서비스는 초기 구현 이후 제대로 유지보수되지 않아 히스토리를 알기 어렵고 높은 복잡도와 유연하지 않은 코드로 인해 새로운 기능을 구현하고자 할 때 어려움이 많았습니다. 앞으로의 파트너 프로젝트 병목을 최소화하기 위해, 가장 필요하다고 생각되는 에러 핸들링을 개선하였습니다.

• 기존 서비스 기능에 영향이 가지 않도록 하면서 방대한 양의 변경 사항을 가하는 작업이었기 때문에 다양한 유즈케이스에 대한 검증과 방어 전략을 고려하며 진행하였습니다.
• 파트너 실무를 담당하는 팀원 두 명을 모집하여 담당 역할을 나누어 진행하되, 주기적으로 함께 논의하고 적극적으로 코드 리뷰를 진행하였습니다.

• 기존에는 파트너 서비스에서 API 통신 또는 자바스크립트 에러 발생시 이를 방어할 수 있는 체계가 없었습니다. 이를 개선한 결과 예상 가능한 Exception의 규격화 및 예상치 못한 에러 발생시의 UI 방어 처리가 가능해졌고, 운영 환경에서의 에러를 트래킹할 수 있는 툴을 적용하여 고객과 개발자 경험을 모두 개선하였습니다.

• 어떤 서비스에서든 에러 핸들링이 필요하다는 점을 고려했을 때, 공통화할 수 있는 부분과 비즈니스 로직과 관련된 부분을 분리하여 고도화하는 경험을 할 수 있었습니다.
• 문제를 느낀 부분에 대해 적극적으로 해결하고, 함께 목표를 달성할 수 있는 동료를 모집하여 주도적으로 프로젝트를 관리하는 경험을 할 수 있었습니다.

• 레거시 코드에서 에러 핸들링 시작하기

숙박교통 도메인 담당

• 가이드 투어가 주력인 마이리얼트립 서비스의 다각화를 위해 숙박교통 도메인 담당으로 다양한 프로젝트를 진행하였습니다.
• 도메인 코드베이스의 안정화를 위해 기술 부채 청산에도 집중하였습니다.

• 커머스의 주요 사이클인 상품 탐색과 예약 중에서 상품 탐색 부분을 담당하여 주도적으로 개발하였습니다. 렌터카 내재화, 대국민 숙박대전 이벤트 페이지 제작, 국내 숙소 전면 리팩토링, 입점숙소 파트너 개선 등을 담당했습니다.
• 레거시를 일컫는 2.0 코드베이스에서 개선된 3.0 버전으로 모든 숙박교통 프로덕트를 구현 및 전환하였습니다. 3.0에서는 타입스크립트를 기반으로 안정성을 고려하였고 서버와 클라이언트 상태를 분리하여 복잡도를 낮추는 등 새롭게 논의된 팀 컨벤션을 적용하며 개선된 코드 베이스를 도메인에 정착시켰습니다.

• 렌터카 서비스가 출시된 이후 빠르게 성과를 경신하며 일거래액 1억을 달성하였고, 서비스 지표를 개선하기 위해 모니터링한 결과 모달을 닫는 과정에서 페이지 이동이 일어나 결제 전환율에 영향을 주고 있음을 발견하여 모달 스택을 히스토리에 저장하는 기능을 구현하여 결제 전환율이 3% 상승하였습니다.
• 노후화된 대국민 숙박대전 이벤트 페이지, 국내숙소 프로덕트를 전면 리팩토링하여 유지보수성과 확장성을 개선하였습니다. 특히 사용자 불편을 야기하던 URL 쿼리 유실 문제를 해결하여 고객 경험과 사업운영 경험을 개선하였습니다.

• 빠르게 비즈니스 임팩트를 내는 과정에서 코드 퀄리티를 희생하지 않기 위한 제품 개발 프로세스를 고민하는 계기가 되었습니다. 기능을 단순히 구현만 하기보다는 유지보수성과 확장성을 고려하고 개발자 테스트를 중요시해야 한다는 점을 배웠습니다.
• 같은 도메인에 속한 팀원과 협업하면서 업무 및 일정을 관리하는 역할을 맡았을 때, 나의 개발에 할애할 수 있는 시간이 부족해지는 경험을 통해 매니징 역할의 어려움을 느꼈습니다. 효율적인 업무 분담을 위해서는 목표를 세분화하고 우선순위를 명확히 하는 것이 중요하다는 점을 배웠습니다.

• 로직 분리의 기준에 대하여

이미지 관리 생산성 도구 개발

• 팝업 이미지, 아이콘 등 서비스 개발에 필요한 각종 에셋들을 업로드하는 과정이 프론트엔드 개발자에 의해 수동으로 이루어지고 있어 간단한 에셋 변경시에도 기획/디자인으로부터 티켓을 전달받아 처리하는 불편한 과정이 반복되었습니다. 이 과정이 간단하게 이루어질 수 있도록 생산성 도구를 개발하였습니다.

• 필요한 경우 누구라도 직접 피그마 시안상에서 에셋 URL을 얻을 수 있도록 플러그인 형태로 구현하였습니다.
• 피그마 플러그인 외에도 웹사이트 형태로 보다 확장성 있고 종합적인 기능을 제공하는 이미지 관리 툴을 개발하였습니다.

• 개발자가 수동으로 진행하던 과정이 필요 없어지고, 요청자가 티켓을 전달하거나 트래킹할 필요가 없습니다.
• 프로그램으로 업로드에 필요한 정보를 관리하다 보니 수동으로 할 때보다 에셋을 일관적이고 효율적으로 관리할 수 있습니다.

• 수동으로 이루어지는 반복 작업이 불편하게 느껴질 때, 자동화할 수 있는 방법을 찾고 능동적으로 구현하는 경험을 할 수 있었습니다.
• 피그마 API를 연동하면서 확장 프로그램의 유용함과 그러한 확장성을 마련해준 플랫폼의 중요성을 깨달았습니다. 피그마 캔버스 데이터를 postMessage 통해 전달받는 과정에서, 서로 다른 자바스크립트 프로그램 간의 안정적인 통신에 대해 고민해보는 계기가 되었습니다.

이메일 콘텐츠 에디터 개발

• 이메일 마케팅 SaaS 서비스인 배리는 고객에게 개인화된 이메일 경험을 제공함으로써 마케팅 효과를 높이는 서비스입니다. 이메일 경험에서 또한 중요한 것은 좋은 콘텐츠를 제작하는 것인데, 디자이너와 개발자 리소스가 없는 업체의 경우 콘텐츠 제작에 어려움을 겪습니다. 따라서 디자이너와 개발자가 없이도 퀄리티 있는 콘텐츠를 제작할 수 있도록 이메일 에디터를 개발하였습니다.

• 블록 단위로 콘텐츠의 내용 및 디자인을 CRUD하고 undo, redo, 미리보기 등 에디터의 기본적인 기능을 지원하였습니다. 블록의 자료 구조를 통일하여 jsx 또는 이메일 마크업 등 기능별로 매칭되는 뷰타입을 동적으로 렌더링하였습니다.
• 상태관리 라이브러리로 redux를 사용하였고 비동기 통신이 필요한 경우 redux-observable을 사용하여 스트림 방식으로 처리하였습니다. 데이터 반영은 메인 프로덕트 API에 위임하고 프론트엔드 스탠드 얼론 앱으로 기능할 수 있도록 구현하였습니다.

• 기존의 이메일 에디터를 참고하고 개선할 점들을 도출하여 직관적인 UI를 구현한 결과 사용자에게 사용성 관련 긍정적인 피드백을 받았습니다.
• 서비스 내에 에디터를 탑재하여 중도 이탈 없이 이메일 마케팅 전 과정을 지원할 수 있게 되었습니다.

• 글로벌 상태로 한 곳에서 모든 데이터를 관리하다 보니 복잡도가 높아지고 성능이 저하되는 이슈가 발생하여 글로벌 상태 관리에 대한 경각심을 얻을 수 있었습니다.
• 처음 골랐던 WYSIWYG 라이브러리의 심각한 결함으로 인해 새로운 라이브러리로 교체하는 경험을 하면서, 개발시 라이브러리를 도입할 때 어떤 장단점이 있는지 충분히 파악하고 검증한 후 도입하는 것이 좋다는 것을 배웠습니다.
• 이메일 마크업의 제한적인 특징을 파악하고 최신 기술을 사용할 수 없는 환경에서 반응형을 구현하는 경험을 하였습니다.

• Redux와 React Context API 함께 사용하기
• WYSIWYG 에디터 선택하기
• 프로젝트 폴더 구조의 변화, 바꾼 이유, 그리고 느낀 점

메인 프로덕트 개발

• 이메일 마케팅 서비스를 빠르게 런칭하기 위해 여러가지 필요한 단계와 기능들이 있었고, 그 중에서 발송 관리, 수신자 관리, 계정 관리 등의 페이지 개발에 참여하였습니다.

• 개발 효율성을 높이기 위해 디자인 시스템을 구축하였습니다. Styled System 기반으로 컴포넌트를 구조화하고 storybook을 활용해 테스트 및 문서화도 진행하였습니다.
• 소규모 신사업 개발팀으로 개발자도 기획 단계에 함께 참여하며 적극적으로 의견을 내고, 빠르게 제품을 개발 및 개선하는 과정을 반복했습니다.

• 에디터와 메인 프로덕트 개발을 1년 안에 완료하여 서비스를 런칭했고, 실제 사용자들로부터 효과적으로 이메일 마케팅을 수행하게 되었다는 피드백을 받을 수 있었습니다.
• 개인 차원에서는 개발자로 처음 실무를 맡게 된 서비스였기 때문에 백지 상태에서 비약적인 성장을 이룬 계기가 되었습니다.

• 디자인 시스템 최초 구현 후 지속적으로 리팩토링하며 보다 재사용 가능한 코드로 개선했습니다. 시스템이 알 필요 없이 인터페이스로 위임할 것과 시스템 내부에서 지원해야 할 것을 구분하였습니다.
• 일반적인 웹 서비스에서 필요로 하는 UI 컴포넌트 스펙은 어떤 것들이 있는지 배웠습니다.