Tech

Zettelkasten과 서비스 문서화 그리고 가슴 설레는 OKR – Hwahae network graph

2022. 04. 08

안녕하세요. 화해팀 프론트엔드 플랫폼 리더 박제훈 입니다. Zettelkasten과 서비스 문서화 – Hwahae network graph

2021년 4분기 프론트엔드 플랫폼에서 재미있는 도전을 했던 경험을 공유드리고자 합니다.

시작

서비스를 하는 조직은 규모가 커지고 확장되면서 다양한 제품을 만들어가게 됩니다. 시간이 지나면서 서비스에 대한 기획서도 작성하게 되고 개발과 관련된 다양한 문서들도 생깁니다. 기획서를 위한 디자인 툴과 개발을 위한 hand-off 소프트웨어도 트렌드에 따라 다양하게 사용하는데 화해 개발팀은 google drive ppt, whimsical, zeplin, miro, figma 등 많은 도구들을 거쳐왔고 현재도 이동하고 있습니다. 또한 개발 관련 문서 역시 confluence와 notion 등을 사용하고 있습니다.

어떤 프로젝트가 진행된 후 히스토리는 당시 참여했던 개발자나 기획자의 기억에 의존하는 경우가 종종 생깁니다. 이후 개발 히스토리를 파악하려 할 때 문서라도 있으면 다행이지만 그렇지 않은 경우도 있습니다. 중앙집권식으로 관리되지 않고 프로젝트 참여자에 의해 각각 만들어진 문서들은 해당 참여자가 퇴사하면 문맥을 파악하기 어려워집니다.

화해팀 개발 툴

특정 기능을 찾아라

작년 상반기 플랫폼 규모가 커져가는 시점에 신규 입사자 분들에게 플랫폼 온보딩을 위해 프론트엔드 플랫폼에서 관리하는 서비스를 플랫폼 타운이라는 이름으로 정리했습니다. 개발에 필요한 문서들을 한 곳에 모아 이를 기반으로 온보딩을 진행했습니다.

화해팀 플랫폼 타운 표

이후 설명을 위해 흐름이나 연결 관계 등을 표현할 방법을 고민했었는데 일정상 더 발전시키지 못한 채 정리만 하고 마무리했습니다.

그러다 마침 화해팀(버드뷰) 내의 정보보호 관리 체계 구축 중 개인정보가 포함된 기능들을 찾는 과정에서 다양한 경험을 하게 되었습니다. 백오피스를 포함한 수많은 서비스 중에서 개인정보 데이터를 사용하고 있는 구간을 찾기란 결코 쉽지 않은 일이었습니다. 활발하게 유지·운영되고 있는 서비스는 문제가 없었지만 담당자가 없는 레거시 시스템에 대해서는 히스토리나 현재 상태에 대한 파악이 불가능해서 관련된 모든 자료를 처음부터 찾아가야 했습니다. 결국 많은 탐색비용을 지불할 수밖에 없었습니다.

정보보호 관리 체계가 어느 정도 구축된 후 우리는 파편화된 서비스들의 요건을 쉽게 파악할 수 없는 환경에 대한 문제를 인식하게 되었습니다. 이후에도 전체 프론트엔드 플랫폼에서 운영하고 있는 서비스의 현황 파악이 필요했기 때문에 서비스의 전체적인 흐름을 알 수 있고, 주요 기능에 대해서 쉽게 인지가 가능한 도구가 필요하다고 결론을 내리게 되었습니다.

때마침 개발팀 차원에서도 2021년 4분기 OKR로 전체 프론트엔드 서비스에 대한 문서화 및 도식화를 제안받았습니다. 작년에 이어 2022년에도 역시 프론트엔드 플랫폼 확장이 예정이 되어 있었기에 프론트엔드가 거쳐가야 할 중요한 사안이라는 공감대가 형성되었고, 과제를 진행하기로 결정했습니다.

이후 프론트엔드 서비스 도식화에서 화해팀 전체 서비스 도식화로 프로젝트 범위가 확장됩니다.

문제 해결을 위한 접근

처음 제안받은 아이디어는 아래 그림과 같았습니다.

화해 서비스 도식화 초안

이 아이디어를 보고 화해팀에서 사용 중인 Miro를 활용하여 서비스의 스크린 혹은 기능을 기반으로 한 플로우 차트 형태로 도식화하는 것을 먼저 고민해보았습니다. UI 플로우 흐름상 그림과 같은 1:n의 단방향 연결이 아니라 n:n의 양방향성 연결이 생길 것으로 보였습니다. 또 전체 서비스를 도식화하면 Miro와 같은 툴을 쓸 때 관리 및 흐름을 파악하기 쉽지 않을 거라는 생각도 들었습니다.

도식화와는 별도로 문서화도 생각해봐야 했습니다. 최근 많이 이용하는 서비스들(Notion, confluence, obsidian, Roam research 등등)을 활용하여 많은 수의 문서를 관리하는 방법을 리서치했는데 그 과정에서 zettelkasten을 알게 됐습니다. 이 방법은 매우 인상적이었고, 저의 생각에도 변화가 생겼습니다.

Zettelkasten

Zettelkasten은 정보가 적힌 메모와 메모의 정보가 담긴 메타데이터로 구성되어 있습니다. 메모는 메타데이터의 hash값과 같은 태그를 통해서 서로를 참조할 수 있으며 같은 테마에 속하는 메모는 분류하여 한 칸에 모아둡니다. 그리고 메모 칸은 메모지를 떠올릴 수 있는 철자를 표기합니다.

zettelkasten에 대한 설명을 찾아보면서 도식화가 가능한 wiki라는 생각이 들었습니다. 이후 이 zettelkasten 개념을 서비스 문서화에 대입해보니 많은 부분이 풀리는 것을 느꼈습니다.

zettelkasten

이미지 출처: https://en.wikipedia.org/wiki/Zettelkasten

Zettelkasten은 second brain이라고도 불리는데요. 처음 Zettelkasten을 고안했던 사회학 이론가인 독일의 니콜라스 루만 교수님은 작은 아이디어나 기반 지식들을 네트워크로 연결시켜 보관하고, 새로운 아이디어나 기록 검색은 키워드 별로 연결시켜 연구들을 지속적으로 발전시켜 나갔습니다. 그 결과로 70건의 저서와 400건의 논문을 작성하기도 했습니다. 최근엔 ‘knowledge base’라는 키워드로 개인 혹은 집단의 지식 정리를 obsidian이나 org-roam과 같은 zettelkasten 기반의 문서 도구로 정리하는 방법들도 떠오르는 추세입니다.

화해 앱을 중심으로 생각들이 뻗어나가면서 각 서비스의 페이지와 기능 단위로 연결성을 갖고 구조를 이해하는 방식이 우리가 기획서를 나열하고 이해하는 과정과 유사하다고 생각했습니다. 다시 말해 머릿속에 있는 그림을 현실의 그래프로 도식화하는 것이죠.

Zettelkasten을 서비스 문서화에 대입해 본다면 메모는 서비스의 주요 정보들로 구성하고, 같은 분류에 속하는 메모는 프로젝트로 묶을 수 있습니다. 그래서 하나의 메모는 하나의 스크린 혹은 기능을 담고 페이지별로 흐름이나 연결관계를 설정해주는 것으로 서비스에 대한 문서화 및 도식화가 가능하리라 예상했습니다. 그렇다면 이 부분이 시각적으로도 보여야 하는데 Roam research, obsidian과 같은 문서 도구가 이미 훌륭하게 구현하고 있었습니다.

obsidian

이미지 출처: https://obsidian.md/

이미 만들어진 서비스를 활용하여 문서화를 진행할지에 대해서도 검토해봤는데 문서 도구를 활용하는 것도 좋지만 필요한 기능들을 직접 구현해서 확장해보는 것도 괜찮겠다는 생각이 들었었습니다. 오픈소스를 찾다 보니 vscode의 extension으로 구현된 foam을 알게 되었고, 가능성은 확신으로 점점 변해갔습니다. foam을 활용해 프로토타이핑을 해보면 아래와 같은 형태로 결과물을 예상할 수 있었습니다. 처음 제안받은 방법 중 단방향 그래프 연결이 양방향으로 변경된 것 외에는 접근 방법이 거의 유사했습니다.

foam을 활용한 프로토타이핑_화해

방향성을 결정한 후 우리에게 주어진 시간은 약 2달 정도뿐이어서 위 기능 구현은 다른 의미론 굉장한 도전이었었습니다.

구현을 위한 접근

처음에는 구현 시간이 부족해 보이기도 했고, 개발팀에서 다른 상용 문서화 도구로 먼저 문서화를 하고 가능하다면 이후에 구현하는 것을 제안받기도 했습니다. 4분기가 끝나기까지 시간이 얼마 남지 않았지만, 구현 가능성을 확인한 이상 상용 툴로 제한적인 아이디어를 확장하는 것보다 직접 구현하면서 근본 원인을 해결해나가는 것이 훨씬 더 도전적이고 가슴 두근거리는 과제라는 생각이 들었습니다. 빠르게 필요 기능들을 수집하고 구체화해야 했습니다. 그래야 개발팀 차원에서의 구체적인 논의가 가능하고, 함께 진행할 플랫폼 구성원들에게도 이 과제의 가능성을 보여주고 설득할 수 있으니까요.

과제를 진행하면서 다시 한번 화해팀의 OKR 문화에 대해서 생각해봤습니다. 화해팀은 OKR 중에서도 도전적인 과제를 별도로 구분하고 있고 모든 과제가 설레야 한다는 것을 알고 있습니다. 우리가 해결하고자 하는 문제가 작은 것일지라도 도전적이고 설레는 과제를 진행하고 싶었습니다. 단순 문서화에서 그치는 것이 아니라 주도적으로 문제의 근본 원인을 찾고, 해결하고 싶었습니다.

그리고 우리는 2021년 마지막까지 정말 즐겁게 과제를 진행했습니다. 정말 힘들었지만요.

Jamstack

foam이나 obsidian 같은 문서 도구를 보고 zettelkasten은 많은 메모(페이지)들로 구성되어 있으며 각각의 데이터는 자주 변하는 것이 아니므로 정적 페이지로 관리할 수 있을 것이라고 생각했습니다. 각각의 페이지는 cms에서 데이터를 관리하고 WYSIWYG 혹은 해당 내용을 작성할 수 있는 form으로 구성된 편집 화면으로 관리할 수 있습니다. 블로그처럼 페이지를 draft로 관리할 수도 있고, 발행하면 페이지가 배포되어 서비스는 변경된 화면을 반영하면 됩니다. 이에 블로그 등과 같은 정적 페이지를 효율적으로 관리할 수 있는 Jamstack으로 서비스를 구성하면 괜찮겠다는 판단을 했습니다.

Jamstack에 대해서는 해당 사이트에서도 잘 설명이 되어있지만 요약하자면 아래와 같습니다.

JAM

JavaScript: 동적 기능은 자바스크립트에서 처리하며, 사용해야 하는 framework나 library에 제한이 없다.
APIs: 서버 측 작업은 재사용 가능한 API로 추상화되고 Javascript로 HTTPS를 통해 엑세스 한다. third party 서비스 혹은 커스텀 기능일 수 있다.
Markup: 웹 사이트는 정적 HTML 파일로 제공된다. 정적 사이트 생성기를 사용해 Markdown과 같은 소스 파일로부터 생성될 수 있다.

Why Jamstack

Better Performance
- 배포 시간에 페이지를 생성한다.
- CDN을 통해 사전에 빌드된 마크업 및 asset들을 제공한다.
- ttfb(time to first byte)를 최소화하는데 CDN을 통해 제공되는 사전 빌드된 파일을 능가하는 것은 없다. (When it comes to minimizing the time to first byte, nothing beats pre-built files served over a CDN.)
Higher Security
- api는 microservice로 추상화되어 공격을 줄여주고 안정성이 높다.
Cheaper, Easier Scaling
- 정적 파일을 호스팅 하는 것은 저렴하거나 무료이다.
- 확장은 파일을 더 많은 위치(places)에서 제공하는 문제이며 CDN이 이러한 문제에 완벽하게 대응한다.
Better developer experience
- (위의 이유들로) 프론트엔드에 집중할 수 있다.

그리고 Jamstack을 기반으로 구현체에 대한 리서치를 시작했습니다.

구현에 필요한 기술 리서치

작년에 읽었던 기술문서 중 인상적이었던 LINE에서 하루 만에 정적 웹 페이지 개발해서 배포하는 방법을 방법적으로 많이 참고했고 아래와 같이 기술 스택들을 정해갔습니다.

headless cms: strapi

많은 headless cms을 리스트업하고 비교해 놓은 사이트를 참고해 리서치했습니다. community 버전이 전부 open source로 되어있고, strapi에서 자체 제공하는 cloud를 쓰거나 기술 지원 등을 제외하면 우리는 셀프 호스팅을 할 거라 과금 유도가 거의 없고 DB 선택(SQLite, MongoDB, MySQL, Postgres)이 자유로우며 GraphQL, RESTful API 모두 지원, webhook 지원, 인증 및 권한 제어 등이 유연하고 구현에 필요한 기능은 거의 있는 것 같아 보였던 strapi를 선택했습니다.

자체 제공하는 에디터 환경도 완성도가 높아 보여 직접 구현하려던 form은 strapi에서 제공하는 것을 사용하면 되겠다고 생각했습니다. 또한 문서화가 굉장히 잘되어있었고, 오픈소스라서 막힐 때는 코드를 확인하면 될 거라 생각했습니다. 그리고 next.js로 구현한 blog 가이드를 보면서 빠르게 프로토타이핑해볼 수 있었습니다.

다만 SSO, 커스텀 권한 관리가 유료 기능인데, 초기 구현에서는 기능을 최소화하고 사용자는 strapi에서 관리하면 충분할 거라 생각했습니다. 시스템이 고도화된다면 필요한 기능만 모아서 headless cms를 직접 구현하는 방향으로 발전 가능할 거라는 생각도 했지만 지금도 충분히 필요한 기능들은 다 제공되고 있습니다.

SSG (static site generator): next.js

12 버전이 릴리즈 되면서 swc 활용으로 빌드 타임이 비약적으로 상승하였습니다. gatsby도 최근 릴리즈 된 4.0에서 DSG를 적용하여 속도가 비약적으로 상승했다고 하는데, 사실 next.js가 더 익숙하기도 하고 비교 분석할 시간이 없어 next.js를 바로 활용하기로 했습니다. 실제 구현에는 ISR(Incremental Static Regenration)을 활용하면 유지보수 관점에서도 좋을 거라 판단했습니다.

graph library: G6

이 구간에서는 리서치에 시간을 많이 썼습니다. 막연히 svg로 그래프(네트워크) 형태로 그릴 수 있는 것이 있을 것 같았고 d3가 후보군으로 먼저 떠올랐습니다. foam에서 좌표가 겹치지 않게 그래프 형태를 어떻게 만들까 궁금해서 구현 방법을 확인해봤는데 ‘d3.force’ 함수가 눈에 띄었고 내부 코드는 d3-force module의 forceLayout을 활용하여 구현이 되어있습니다.

이미지 참고: https://github.com/d3/d3-force

이후 next.js에서 d3를 활용해야 해서 어떻게 함께 사용할지를 고민해보았습니다. 예전에 개인적으로 d3를 써보았을 때는 class 컴포넌트 시절의 react 환경이 었었고 functional component에서는 hook과 궁합이 안 맞는 느낌을 받아서 어떻게 구현할지 고민하던 중 한 아티클을 보고 정리를 다시 하였습니다.

요약하자면 react도 렌더링을 virtual dom으로 별도로 관리하는데 d3도 dom을 직접 조작하니 어느 한쪽에 렌더링 사이클을 몰아주던지, 렌더링 사이클을 잘 믹스하던지, 아니면 d3의 수학 관련 모듈만 사용하는 방법들로 구현 방법이 소개되어 있습니다. (문서의 react-faux-dom은 생략했습니다) 마지막 방법으로 구현하는 것이 제일 나아보였고 그 접근 방법으로 구현이 된 nivo, vx, recharts 등의 라이브러리들이 눈에 띄었습니다.

그때 이쯤에서 ‘꼭 d3 혹은 svg로 네트워크 그래프를 구현해야 할까’라는 근본적인 의문점이 다시 생겼습니다. 우리가 웹에서 그래프를 그린다면 선택지는 svg, canvas, webgl로 구현할 수 있고 선택의 폭이 훨씬 넓어집니다. 그래서 넓어진 머릿속을 정리하기 위해 개념부터 다시 정리했습니다.

svg와 canvas를 비교 정리한 좋은 글에서도 설명이 잘 되어있는데 결국 메모(노드) 개수가 많아지면 canvas가 유리해지는 구조일 거라는 생각이 들었습니다. 그리고 webgl로 구현이 되어있다면 더더욱 퍼포먼스가 좋을 거라 생각했습니다. 그래서 다양한 network visualization 라이브러리들을 다시 한번 정리해보았습니다.

svg
- d3 force
canvas
- Vis.js
- g6
webgl

위에서 검토했던 것 중에서는 sigma.js가 퍼포먼스도 좋고 필요한 기능도 다 있어서 가장 눈에 띄었습니다. 하지만 아쉽게도 문서화는 샘플로 제공해주고 있고 react용 라이브러리는 real world 예제 같아 필요한 기능들을 구현하려면 계속 코드를 열어봐야겠다는 생각이 들었습니다. 문서화가 너무 안되어있어서 실제로 팀원이 sigma.js로 프로토타이핑을 해보면서 이후 구현에 대한 걱정을 많이 하셨고, 저도 직접 만들어보면서 현재 주어진 시간 안에 과제를 마무리하기에는 올바른 선택이 아닌 것 같아 빠르게 포기했습니다.

react-force-graph

여담이지만 react-force-graph도 굉장히 매력적이었고, 최종 후보 중 하나였습니다.

프론트엔드 서비스 전체를 도식화한다면 처음엔 몇백개 수준이겠지만, 버드뷰 전체 서비스라면 관리 방법에 따라서는 몇천 개 수준으로 확장될 겁니다. 다만 지금부터 엄청나게 많은 메모 수를 고민할 필요는 없기 때문에 어느 정도의 퍼포먼스가 보장된다는 전제 하에 필요조건을 다시 정리했습니다.

문서화가 잘 되어있어야 한다.
커스텀이 용이해야 한다.
예제가 많아야 한다.(시간문제)
네트워크 그래프 구현 방식이 다양해야 한다.

결과적으로는 Ant design을 만들었던 그룹의 g6가 제일 문서화가 잘 되어 있었고, network visualization 구현 예제가 굉장히 풍부하며 이번 과제에서 필요한 기능들은 모두 제공하고 있었습니다. 그래프 구현 방식들도 굉장히 많이 제공하고 있어서 이후 그래프의 표현 방법에 대한 확장도 충분히 가능해 보였습니다. webgl로도 구현 예정이라는 issue도 본 것 같은데 아직 대응 예정은 없는 것 같습니다. 예제 중에 5000개의 노드로 퍼포먼스 테스트한 예제가 있는데 여기까지 확인하고 퍼포먼스도 큰 문제가 없을 거라 판단했습니다.

그래서 최종적으로 g6를 택하였습니다. 실제로 필요한 기능에 대한 구현은 굉장히 빠른 시간에 완료했습니다.

아래는 이번에 구현하면서 적용한 그래프 레이아웃 알고리즘인 ForceAtlas2인데 Gephi라는 graph visualization 소프트웨어에서 개발한 알고리즘이고 자세한 내용은 PLOS라는 과학 저널 아티클을 참고해보시면 좋을 것 같습니다.

ForceAtlas2

다만 G6는 문서화가 중국어 버전과 영어 버전이 차이가 좀 있고 최신화는 중국어 버전뿐이라 구글 번역기와 함께 문서를 이해해 나갔습니다. 단순히 그래프 API 문서화뿐만 아니라 메인 컨셉이나 그래프에 대한 설명도 잘 되어 있어서 공부도 많이 되었습니다.

퍼포먼스에 대한 부분도 5천 개 노드 예제가 있는데 지금 만드는 서비스가 많이 커지기 전까지 충분히 활용할 수 있을 것 같아 보였고 지금 필요한 기능을 만드는 데는 충분했습니다. g6의 오픈소스를 분석하면서 흥미로웠던 부분도 있었습니다. webgl을 사용하지 않는데도 ‘enabledGPU’라는 옵션이 있어서 어떻게 구현했는지 궁금했었는데 내부적으로 offscreen canvas를 활용하고 있었습니다. 이후에 canvas 활용이나 그래프 엔진을 직접 구현할 일이 생긴다면 공부가 많이 될 것 같았습니다.

기획 시작

zettelkasten 기반의 서비스를 기반으로 필요한 기술들은 구현 가능한 것으로 리서치를 완료했고 이제 구체적인 기획이 필요했습니다. 이 OKR은 프론트엔드 플랫폼 주도적 과제여서 기획도 플랫폼에서 전부 진행하였습니다. 기획에 익숙하진 않았지만, 먼저 Miro로 빠르게 구현 플로우를 그려보았습니다.

이 서비스 이름은 임시로 Hwahae Network Graph(이하 HNG)로 부르기로 했습니다.

Hwahae Network Graph 기획

각 문서들은 노드에 대응되며 개별 html 문서로서 대응하도록 설계했고, iframe에 html로 올라갈 수 있게 기획을 잡았습니다. 그리고 framer로 prototype을 만들기 위해 빠르게 기획도 정리해나갔습니다. 각 페이지에는 서비스 페이지나 기능 단위로 메모(페이지)를 구상하고 메모에 유관된 디자인 툴 정보나 handoff 툴 정보, 혹은 유관 부서 등을 기입할 수 있도록 열어놨고 정제가 안된 분류 항목은 tag로 자유도를 열어놓고 점진적으로 분류하려고 계획하였습니다.

그리고 중간중간 기술 스택들을 정해가면서 실제 구현과 가깝게 수정하고 framer로 prototype을 만들었습니다.

그리고 기능 확정을 다시 정리하였습니다.

사전 요건 사항

프론트엔드 서비스에 대한 현황 파악을 할 수 있는 문서화 도구가 필요하다.
- 추후에는 버드뷰 제품 그룹 전체를 도식화할 수 있다.
버저닝이 돼야 한다.
제품 그룹에서 수정 가능해야 한다.
화면 위주의 서비스 구성도가 필요하다.
(optional) 기술 스택, API, 배포 환경 등의 개발 정보도 포함한다.

4분기 OKR (MVP)

*MVP : 최소 기능 제품, Minimum Viable Product

용어 정리
- MVP: 12월 31일에 반드시 구현해야 하는 기능
- L1: MVP로 고려하였지만 일정상 힘들어 보여서 우선순위 낮추고 가능하면 진행
- L2: MVP는 아니지만 요건이 필요하면 12월 이후로 제안
- L3: 필요는 해 보이는데 대체 방법이 있거나 L2보다 우선순위 낮음
로그인
- 로그인은 개발 기간 문제로 이번에 진행하지 않는다.
- L2
  - strapi login을 사용한다.
  - 계정 생성은 strapi 슈퍼 계정으로 생성. 가능하면 기능 추가한다.
  - 디자인은 화해 운영 어드민의 디자인을 그대로 가져다 쓴다.
  - 기능(이메일 혹은 비번 변경 화면)을 통한 비밀번호 변경
- L3
  - 추후 hwahae 로그인을 쓸 수 있으면 쓴다.
  - 패스워드 찾기
문서 작성 파트
- MVP
  - headless CMS를 활용하여 문서를 작성할 수 있다. (w/strapi)
  - 버전은 cms에서 로그 테이블로 관리하며 문서에서 버전을 확인할 수 있다.
    - 추후 버전에 따른 변화를 어떻게 보여줄지는 MVP가 아닌 다른 기능으로서 관리 예정
문서 확인 파트
- 그래프 기반의 메모 상자(zettelkasten) 서비스를 만든다. (w/next.js)
- 그래프를 통해 문서의 연결 흐름을 확인할 수 있다.
- 그래프를 눌러서 상세 내용을 확인할 수 있다.
- MVP
  - 그래프 노드 구현 (g6)
  - 줌 인/아웃
  - 드래그
  - 노드 클릭
  - 데이터를 통해 그래프를 생성
  - 그래프를 어떻게 그릴지에 대한 인터페이스 구상
  - 문서 화면 노출
프론트엔드 센터에서 관리하는 제품(or 기존에 완성된 도식화하기 좋은 제품) 기준으로 1개의 제품을 찾아 그 제품을 기준으로 샘플을 만든다.
TF 및 밴드에 전달하고 관리할 수 있는 템플릿을 작성하고 가이드를 제공한다.

MVP 구현을 완료하고 시간이 된다면 혹은 시간이 더 주어진다면 추가할 기능

command palette(+ instanceSearch.js)를 활용한 문서 검색
- 리서치가 좀 더 필요함 (algolia/react-instantsearch)
history versioning 표시 및 변경 기록 표시 방법
graph 필터
ui 다듬기

이것을 기반으로 프론트엔드 플랫폼 개발자 두 분과 함께 연말까지 즐겁게 구현했습니다.

완성

약 1.5달 동안 매진한 결과 L3 몇 가지를 제외하면 기획대로 12월 말에 구현을 완료했습니다. 아래는 결과입니다. headless cms는 strapi라 제외했습니다.

개발 버전으로 수정한 영상입니다

실제 구현을 어떤 식으로 했는지를 풀어내는 것은 좀 다른 이야기일 것 같아서 건너뛰었지만 엄청난 도전이었습니다. 11월, 12월을 3명이 거의 매일 새벽까지 함께 보냈으니까요. ‘몸은 지쳐있지만 뇌는 즐겁다’라는 소감으로 12월 마지막 주에 드디어 구현을 마무리했습니다.

아쉬운 점은 처음 구조는 Jamstack으로 구상했지만 급하게 구현으로 목표를 변경하는 바람에 Jamstack으로 환경을 구상할 여유가 없어서 기존의 익숙한 배포 방식을 사용했다는 점입니다. 그래서 올해 안으로 다시 처음 구상한 환경대로 적용해나가려 합니다. 언제든 옮겨갈 수 있도록 구조적으로 구성은 해놓았고 이후 SSG를 활용한 정적 배포를 해야 하는 새로운 서비스를 만난다면 이번에 진행한 프로젝트를 기반으로 더 발전시킬 수 있을 것이라는 자신감도 얻었습니다.

프론트엔드 플랫폼의 서비스 문서화를 올해 3월부터 진행하고 있는데 문서 템플릿이나 메모(노드)의 효율적으로 관리하는 방법을 정리하는 게 앞으로 남은 숙제입니다. 사실 작성 방법이 열려있고 노드를 바라보는 관점도 서로 달라 플랫폼에서 기준을 작성해나가면서 집단 지성으로 풀어나가길 기대하고 있습니다.

마무리

사실 이 접근 방법이 궁극적으로 문제를 풀었는지는 아직 검증되지 않았습니다. 우리는 문제를 해결할 방법과 그 시작점을 제안한 것이고 이 과정조차도 POC(Proof of concepts) 과정이라고 생각합니다. 작년부터 시작해 궁극적인 문제를 풀기 위해 도전하고 아직 검증하지 못한 오류를 수정하면서 버드뷰의 서비스 흐름과 특징을 한 곳에서 파악할 수 있도록 근본 원인을 지속적으로 개선하고 해결해나가려고 합니다. 문제를 잘 해결해 그 과정도 블로그에서 다시 한번 공유할 수 있으면 좋겠습니다.

수학의 유명한 난제 중 하나였던 페르마의 마지막 정리를 해결했던 앤드류 와일즈도 우연히 지도교수가 추천했던 타원 곡선이 문제 해결에 결정적인 기여를 했다고 말했죠. 이처럼 때때로 상관없어 보이는 두 가지가 의외의 해결점이 되는 일이 있습니다. 실제로 무언가 막혔을 때 조금만 시야를 돌려보면 우리가 갖고 있는 근본적인 문제들을 해결할 방법들이 의외의 곳에 많이 있고, 이번 프론트엔드 플랫폼에서 시도했던 방법 역시 그런 시도 중 하나였다고 생각합니다.

이번 과제는 끊임없이 도전하려는 마음과 화해팀의 거시적 문제를 해결하는 데 기여하고 싶은 마음으로 시작했습니다. 도전은 무척이나 즐거운 일입니다. 앞으로도 화해팀에서 해결하고자 하는 문제를 주도적으로 정의하고 해결해나가는 문화가 더욱 활성화되기를 바라며 글을 마무리합니다.

감사합니다.

Reference

✅ 프론트엔드 플랫폼 인터뷰 <htmI> | 프론트엔드 플랫폼 , “성장도 공유도 멈추지 않는다” 편도 읽어보는 건 어때요?

✅ 프론트엔드 플랫폼의 또 다른 콘텐츠 React Query와 함께하는 API 에러 처리 설계하기 편도 확인해보세요!

박제훈 | Front-end Developer

화해팀에서 Front-end 리딩을 맡고 있습니다.

목록으로