전에 다니던 스타트업인 닥프렌즈에서 맡았던 가장 큰 프로젝트, 닥톡 서비스 리뉴얼에 대해 정리해보려 합니다. 이 포스트가 다른 분들에게 얼마나 큰 도움이 될지 나에게 있어서 큰 디딤돌이 될지 그저 스쳐지나가는 작은 추억 쌓기를 위한 회고록이 될지는 모르겠으나 프로젝트 하나하나 회고를 하고 다음 프로젝트땐 같은 실수를 두번 반복하지 않게 회고록을 적어 봅니다.

사내 대규모 닥톡 리뉴얼의 시작

이전에 토이프로젝트 규모의 사내 프로젝트를 진행하고 나서 회사 내부의 이런 저런 행사들을 진행하고 나서야 해당 프로젝트를 진행하게 되었습니다. 백엔드의 리뉴얼은 물론이거니와 디자인도 기본 틀을 모두 수정하는 방향을 잡고 프론트도 물론 ios와 안드로이드도 디자인에 맞춰서 새로운 앱으로 리뉴얼 되는 과정에 들어가게 되었습니다.

그동안 사용이 불편했던 UI/UX들을 모두 뒤엎는 것은 물론 보기 싫은 부분들과 쓸모없는 부분들, 그리고 새로 추가되는 기능까지 정반합하는 기획단계를 거쳐 개발 작업에 들어가게 되었습니다.

물론 당장 완벽하게 프로젝트가 진행은 안되더라도 누가봐도 너무 올드한 디자인 이었고 사용하는 인원수도 규모가 작지 않았기 때문에 그들을 위한 최소한의 업그레이드를 하지 않을 수는 없었습니다.

서비스 개요

기존 닥톡 전문가 서비스 개요

닥톡 전문가 서비스는 다음과 같은 기능을 제공하는 의료 상담·병원 운영 지원 서비스였습니다.

• 네이버 지식인을 통한 의사 상담 및 병원 노출
• 병원 출입 수 기반의 간단한 운영 지표 확인
• 정기 문자 발송 서비스
• 병원 내부 채팅 기능
• 병원 정보 관리 서비스

리뉴얼 과정에서 중점적으로 가져갔던 부분은 전반적인 디자인 컨셉을 재정비하고 신규 기능도 여러 개를 추가했습니다.

내가 맡은 역할

제가 해당 프로젝트에서 맡은 역할은 아래와도 같습니다.

• Vue 기반 프론트엔드 개발 및 리드
• 신규 API 연동 및 기존 API 리뉴얼
• 컴포넌트 구조 설계
• 도메인 단위 UI/기능 구현
• 팀 내 풀스택 2명과 함께 총 3명이 프론트를 담당했고, 일정 관리와 조율 역할도 함께 맡았습니다.
• 추후 vue3 재 리뉴얼

위 내용들을 제가 맡게 되었고 초반에 사내 프론트엔드개발자는 저 밖에 없었어서 제가 프론트엔드리드급 역할을 맡아서 진행했어야했습니다.

기술 스택선택과 한계

이부분은 저와 그때 팀장이 결정을 후회했던 부분입니다...ㅎㅎ이 부분 때문에 추후 다시 vue3.0 으로 리뉴얼 작업을 한번 더 진행하게 되었습니다.

• Vue 2.0: Nuxt2 기본 탑재 버전. 당시 Vue 3가 안정적이지 않다는 이유로 Vue 2를 선택, 추후에 Vue 3으로 재 진행
• Nuxt 2.0: SEO 때문이라 설명했지만 결과적으로 서비스는 SEO 영향이 많지 않아 Vue 3 버전대를 주축으로 들고감
• TypeScript: 생산성, 버그 감소, 비동기 통신 안정성을 위해 도입.
• SCSS: 유지보수성과 작업 효율을 위해 선택.
• Git & GitHub: 버전 관리 및 협업용.
• aws s3, cloud front : vue3로 다시 마이그레이션 할때 프론트엔드 자체 서버 구현을 위한 추가 스택

결국 Vuex가 당시 TS 적용에 최적화되지 않아 Vuex 주요기술요소들인 state·mutations·actions·getters등 모두 수작업으로 타입 정의해야 했습니다. 하지만 수작업으로 타입정의를 하는 부분도 Nuxt2의 생태계가 TS와 완벽히 호환되지 않는 상황이엇어서 개발 과정에서 타입충돌 에러들이 많이 발생했고 추후에 vue3 정식 출시와 함께 재 리뉴얼을 진행하게 되었습니다.

리뉴얼 과정

기획 및 디자인 단계

• 기존 서비스의 불편한 UX와 산만한 UI를 전면 재정비.
• 불필요한 기능은 제거하고 신규 기능을 정의하는 정반합식 기획 과정 수행
• PC·모바일을 하나의 URL에서 처리하려 했으나 구조적 문제가 많아 적응형 웹으로 결정.
  - 채팅 화면 단순화 요구
  • 병원 운영 페이지는 기능이 많아 PC 구조 필요
  • Jenkins 서버 이슈, 도메인 관리 복잡성 등

도메인별 진행의 순서

모바일과 웹의 서버 api도 약간의 차이가 있었고 모바일·웹의 API 차이와 두 번 배포해야 하는 구조를 고려해, 로그인 → 건강상담 → 고객관리(문자서비스) → 채팅 → 설정 → 홈 순으로 작업을 쪼개 진행했습니다.
의 순서로 진행했습니다. 생각보다 쉬운 순서로 진행했고 중간중간 시간이 남는 사람들이 중간에 투입되서 도움을 주는 형식으로 진행했습니다.

개발 구조 설계

• 컴포넌트 디렉토리 구성의 일부입니다, 당시엔 디렉토리 아키텍쳐 관련해서 지식이 부족했고 컴포넌트 내부에서 도메인을 분리하여 구조를 잡아가려고 했습니다. 아래는 그때 당시 디렉토리를 비슷하게 구연해놓은 예시의 일부입니다.
  
• 신규 API, 기존 API, 리뉴얼 API가 섞여 있었기 떄문에 기능별 책임을 명확히 나누려고 했습니다. 아래는 제가 그때 당시 api를 비슷하게 구연해놓은 예시의 일부입니다.

/**
 * 답변
 * @returns
 */
export function patchAnswersSeq(
  seq: number,
  params: URLSearchParams,
): AxiosPromise<{}> {
  return instance.patch(`/answers/${0}`, params);
}

위와 같이 api 함수에서 그 목적성을 명확하게 드러내는 네이밍을 했으며 apis 디렉토리 파일 제목도 최대한 백엔드의 api 요청 url과 동일하게 가져가려고 했습니다.

컴포넌트의 전체 패턴은 Feature-first 패턴을 가져갔어요.
Feature-first패턴을 가져간 이유는 아래와 같았습니다

• 기능 단위로 UI·상태·로직이 모여 있어서 코드 찾기가 빨라졌고, 이슈가 나면 해당 기능 폴더만 보면 됐습니다.
• 나중에 기능을 확장하거나 수정할 때도 영향 범위가 폴더 단위로 명확해서 리스크가 줄었고 리팩토링 속도가 빨랐습니다.
• 나를 포함해 2~3명이 치고 빠지는 구조였기 때문에, 각자 기능 폴더를 잡고 작업하는 협업 패턴과도 잘 맞았습니다.

라이브러리의 선택

프로젝트 전체 팀장이 추천해준 마크업 내부의 모든 텍스트에 자주 쓰이는 텍스트를 위한 텍스트 변수화, 건강상담 도메인과, 고객관리쪽 총 세가지의 라이브러리를 넣어야 했습니다. 대용량 트래픽이 생기는 구조도 아니었고 해당 라이브러리를 직접 구현하기엔 MVP를 달성할 시간이 부족하다고 생각되어 세가지의 라이브러리를 채택하게 되었습니다.

첫번째는 그래프를 그릴 vue3-apexcharts이었고
두번째는 건강상담에 사용자들이 text를 입력할 Tiptap라이브러리 였습니다.
그리고 마지막 세번째는 다국어를 위해 사용한게 아닌 text의 변수화를 위해 사용한 i18n이 있습니다.

vue3-apexcharts는 vue와의 호환성과 커스터마이징의 편의성을 위해 해당 라이브러리를 선택했고
Tiptap는 위와 마찬가지로 vue와의 호환성 그리고 vue3가 나오자마자 바로 업데이트해주는 속도 그리고 생태계를 체크하여 해당 라이브러리를 선택하게되었습니다.
마지막으로 i18n은 생태계가 워낙 넓기도 하고 만약에 추후 다국어로 변환하게 된다면 쉽게 변환시킬수 있는 이유를 갖고있어 해당 라이브러리를 사용해보게 되었습니다.

위 세개의 라이브러리는 사용이 어렵지 않았고 프로젝트 내부에서도 엄청난 난이도를 요구하는 UI/UX를 만드는 것이 아니엇기 떄문에 디자이너와의 협업도 잘 되었고 어려운 이슈사항 없이 무난하게 구현했다고 생각합니다.

이슈사항

초기 이슈

기존 프로젝트와 거의 동일한 스펙으로 작업하면서 문제가 시작되었습니다.

1. Nuxt2 + TypeScript 호환 문제
   Vuex에서는 TS가 기본적으로 잘 적용되지 않아
   state,mutations, actions에 직접 타입을 정의해 구조를 수작업으로 잡아야 했습니다.

2. API 개편 증가
   신규 API, 기존 API 유지, 리뉴얼 API가 뒤섞여 API 양이 크게 늘어났습니다.
   프론트는 풀스택 2명 + 나, 총 3명이 분담하여 진행했다. 후에 추가로 들어오는 프론트엔드 개발자와 추가 작업도 진행하게 됐습니다.

3. 채팅(socket.io) 기능
   가장 난이도가 높고 저에게 아직 코드 파악할 시간이 좀 부족했기 때문에 기존 버전 경험이 있는 풀스택 개발자가 기능개발을 전담해주셨습니다.

사용 환경 관련 이슈

1. 병원은 대부분 Windows 환경

병의원의 의사들은 보통 병원에서 환자들을 관리하는 Windows프로그램을 쓰는데 그 Windows 프로그램에서 돌아가는 지 따로 확인이 필요했습니다. 맥에서는 확인이 불가해 윈도우 컴퓨터에서 따로 확인을 진행해야 했습니다.

2. 반응형 대신 적응형 선택

URL 하나에서 PC/모바일을 구분하는 방식은

• 채팅 화면 단순화 요구
• 고객관리 페이지 기능 차이
• 도메인 관리 복잡성
• Jenkins 서버 중단 리스크
• Windows프로그램과의 호환
  이런 이유들로 적합하지 않았다고 생각했고
  결국 URL을 분리한 적응형 웹으로 결정하게 됐습니다.

초반에는 URL 하나로 디바이스를 나눠서 진행하려 했고 vue 라이브러리로 디바이스를 구분해 폴더안에서 따로 나눠서 진행하려고 했으나 URL 의 문제가 있었습니다.

해당 URL문제를 디렉토리 안에서 해결하려 했으나, 도메인이 집중도가 떨어지는 점, Jenkins의 서버다운이 되는 부분들, 등을 고려하여 반응형이 아닌 적응형 웹으로 제작을 진행하게됐습니다.

개인 이슈

처음으로 맡게되는 대형 프로젝트이기도 하고 vue를 해본적이 얼마 안된 저는 vue의 문법이나 전체 프로젝트 일정을 어떻게 구성해서 가야하는지 이슈가 생기면 어떻게 대응해야 하는지 하나도 모른 상태에서 프로젝트를 진행하게 되었습니다.

전반적인 프론트 일정과 작업 구성을 제가 리드하고 팀장님에게 컨펌을 맞느 식으로 진행했으며, 화면을 제작하고 모든 화면 제작이 끝나면 api를 붙히는 식으로 작업을 진행하게 되었습니다. 1년 차가 끌고 가기엔 벅찼지만, 어쨌든 맡은 이상 해야 한다는 생각이 강했습니다.

신입이기 때문에 이슈가 생겻을 때 대응하는 시간이 오래걸렸습니다, 당시에 아직 AI가 개발에 적극적인 도입이 되기 전이기 때문에 항상 밤을 새가면서 블로그를 뒤져가며 이슈를 해결하곤 했습니다.

이러한 개인이슈들을 해결하고자 컴포넌트를 도메인별로 나누고 날짜 기반 일정표를 먼저 만드는 전략으로 대응해 최소한의 일정을 잡고 가기 위한 계획을 세웠습니다.

리뉴얼 결과

00년도에 만들어졌던 디자인에 비해 UI/UX는 상당히 깔끔하고 자연스러운 흐름으로 만들어진 결과물 이었습니다.

전체적인 기능 구조 재정비는 휼륭하게 개선되었고 필요없는 옛날 도메인 기능들은 모조리 제거되고 신규 기능들이 다수 추가되었습니다.(vue3-apexcharts를 이용한 기능들 등)

내부 이해관계자들의 사용성이 크게 향상되었고 프론트 코드베이스 일부 정리도 성공적으로 정리되어 유지보수가 깔끔하게 이루어졌습니다.

성능최적화도 개선되어 jQuery 기반 레거시 웹을 Vue 3 + TypeScript + Vite로 마이그레이션하여 페이지 로딩 속도를 최대 4.0s → 2.0s로 단축(Lighthouse 측정 기준)하였습니다.

허나 Vue2·Nuxt2 기술 스택의 한계로 인해 이후 Vue3 리뉴얼을 재시작하게 된 부분은 다시한번 시간을 많이 잡아먹는 일이었습니다.

회고

잘했다고 느낀점

• 지금 다시 되돌아보면 당연히 고칠점이 많고 절대 그런 행동은 하지 말아야지 라고 생각했던 부분들도 있지만 1년차 리드 비슷하게 프론트 전체를 끌고 갔고 완성까지 해냈다는 점이 굉장히 뿌듯하게 느껴졋다고 생각합니다.

• 도메인 기반 구조화를 잘 했다고 생각합니다. 컴포넌트 하위의 디렉토리를 도메인 기반으로 잘 정리해 Feature를 기반으로 구조화 했다는 점에서 협업할때 시간도 덜 들이고 최소한의 움직임으로 작업을 진행할수 있고 시간이 단축됐다는 점에서 굉장히 만족감을 느꼈습니다.

• 많고 복잡한 API와 socket.io의 메서드들을 구조를 재 정립하여 협업으로 잘 분담했다고 느꼈습니다. 해당 작업을 하면서 socket.io의 동작원리와 작동방식도 배울수 있었고 보통의 채팅 플랫폼이 웹서비스에서 어떻게 동작하는 지 코드의 구조를 어떻게 구성하면 될지를 확실히 체험할수 있었습니다.

• Vue 프로젝트에 나름 다양한 라이브러리들을 적용해본것 같습니다. 라이브러리를 찾을때 항상 먼저 찾아보고 이걸 왜 썻지 이유를 찾곤 했는데 이번 프로젝트에서는 현재 프로젝트에 맞는 스펙과 환경을 고려하여 선택해본것이 도움이 된것 같습니다.

• 적응형으로 구현할 것이냐, 반응형으로 구현 할 것이냐를 선택할 합리적인 결정을 위해 현재의 다양한 환경과 시간을 고려해본 것 같습니다, 사실은 선택권이 없는 부분이었던것 같기도 하지만 최대한 반응형으로 해볼수 있지 않을까? 만약 내부 엔진만 JS로 파악할수 있다면 그 환경에 맞춰서 코드를 한번만 쓸수 있지 않을까?라는 고민을 최대한 많이 검색해보고 찾아본것 같습니다.

• 처음으로 진행한 TS 프로젝트였기 때문에 구조적으로 많이 고민해본것 같습니다. 아래와 같이 api에서 받아온 타입들은 따로 관리하고 그 외 나머지 것들에 대한 타입들은 프론트쪽에서 interface로 미리 정의해 필요할때마다 꺼내쓰고 최대한 변하지 않는다는 조건하에 해당 타입을 미리 설정해 다른 사람이 유지보수를 위해 타입을 확인해도 빠르게 어떤 값을 받아올수 있는지 미리 볼수 있게 정의 한 덕에 추가 컨텐츠를 집어넣어도 해당 시간을 최소한으로 단축시킬수 있었다고 생각이 듭니다.
  

아쉬운 점

• 아무래도 초반 vue3 베타버전이라도 바로 적용했어야 하지 않았을까 생각이 듭니다, TS를 적용하다가 vuex에서 너무 많은 시간을 잡아먹어 다른 기능구현에 초점을 두지 못했기 때문입니다.

• 아키텍처라는 개념 자체가 저에게 없었습니다, 디렉토리 구성을 좀더 도메인에 초점을 맞춰서 구성했으면 좋았을 것 같습니다.

• 처음 맡았던 나름 리드급 일정이라 일정을 제대로 소화하지 못했던 것 같습니다. 후반부에 다른 분들이 많은 도움을 주었지만 그래도 일정을 빠르게 소화하지 못해서 아쉬움이 많이 남네요, 다음번엔 기능의 단위를 최소화 하고 해당 feature에 대한 구현 일정또한 구체화 및 최소화 시켜 탄탄한 일정을 잡도록 시도해 봐야겠습니다.

• vue를 사용한지 3개월도 채 안되서 러닝커브가 아직 좀 남아있던 것 같습니다,물론 React보다 vue가 러닝커브는 상대적으로 짧지만 아직 완벽하게 vue를 다를수 있다고 생각하지 않은 시점에서 해당 프로젝트를 시작했기 때문입니다. 해당 프로젝트를 통하여 vue를 다루는 수준을 많이 끌어올렸지만 당시 프로젝트를 진행하면서는 vue의 router 개념과 중앙관리 시스템인 vuex, pinia를 배우는데도 많은 시간을 잡아먹었던 것 같네요

• 생각보다 QA에서 많은 시간을 잡아 먹었던 것 같습니다, CSS를 못하는 것도 아닌데 생각보다 화면과 달랏던 부분이 있어 그런 부분에서 시간을 많이 잡아 먹었던 것 같습니다.

다음 프로젝트에 적용할 원칙

• 앞으로 기술 스택을 선택할때는 프로젝트의 환경을 중심으로 해당 프로젝트의 범용성, 확장성을 고려하여 단기 안정성보다 장기 확장성 중심으로 선택하려고 합니다.

• 올해에 많은 디렉토리 아키텍쳐를 구성하는 법을 스터디 했기 떄문에 앞으로 파일 구성을 할때엔 도메인 기준 컴포넌트 구조 설계 유지하도록 노력할것 같습니다.

• 프론트엔드 프로젝트에서의 나름의 리드 경험을 가지고 있으니 다른 프로젝트를 진행한다면 초기 기획·데이터 구조 정의를 더 단단하게 구성해보도록 노력할것 같습니다, Notion을 사용해서 좀 더 파편화되고 세분화된 일정을 가져가도록 다른 프로젝트에 적용해보겠습니다.

• 테스트와 일정관리 방식 표준화시킬 것 같습니다. 해당 프로젝트의 MVP일정에 밀려 테스트코드를 적용시켜보지 못했고 해당 프로젝트의 경험을 살려 일정관리 방식을 다른 팀우너들과 함께 공유하고 Daily scrum을 통해 오늘의 목표치를 확실히 세워보도록 하겠습니다.

• Storybook를 적용하여 화면단의 QA를 최소화 해보고 싶습니다. 모든 화면을 직접 다 만들엇고 세부적으로 조정했기 떄문에 Storybook나 Chromatic을 사용하여 디자이너와 함께 검수하는 Live 세션을 갖는 방법을 고려중입니다.