2년 넘게 개발하고 운영한 프로젝트에 대해 개인적인 생각과 느낀 점을 정리한 글입니다.
처음부터 지금까지 개발해온 프로젝트인 만큼 한 번쯤(?) 회고를 해보고 싶었습니다.
프로젝트 시작 배경
2년 전에 SaaS기반 서비스의 "붐"이 일어났었고, 회사에서 무언가 새로운(?) 제품을 만들면 좋겠다고 의견이 나왔습니다. 하지만 SaaS 기반의 서비스인지 Cloud기반의 서비스인지 명확하게 정해줄 수 있는 사람이 없었습니다.
어찌되었든 간에 만들고자 하는 서비스는 레거시 제품을 업그레이드하는 방향이었고, 혼란 속에서도 Saas 기반이든 Cloud 기반이든 on-premise 기반이든 상관없이 더 좋은 제품을 만드는 방법에 대해 고민하게 되었습니다.
처음부터 만드는 마음가짐
기존 제품(옛 것, 레거시 제품)을 살리면서 새로운 것으로 다가간다는 온고지신의 자세로 레거시의 노하우를 살리고, 불필요한 것은 덜어내면서 새로운 기술을 도입하게 되었습니다. 서비스가 오래되고 성장했다는 점은 장점이 될 수도 있고 단점이 될 수도 있습니다.
레거시 제품을 개발하고 사용해보면서 어떤 방식이 불편했고 어떤 식으로 개선하면 좋을지 다른 개발자들, QA담당자들과 엔지니어분들의 의견을 수렴해보았습니다.
리뉴얼 방향
리뉴얼의 필요성
왜 새로운 제품을 만드는 지 타당한 근거가 필요했습니다. 기존 제품의 문제점을 파악하고 어떤 방향으로 만들어야 할 지 대략적인 방향성이 필요했습니다. 아래의 두 가지 포인트를 강조하였습니다.
서비스의 지속적인 성장과 사용자 편의성 증대
레거시 서비스는 10년 넘게 유지보수되었던 제품이었습니다. 지속적인 고객의 요구사항으로 인해 많은 기능이 존재하였으며 제품의 사이드이펙트와 호환성 등을 고려하다보니 제한적인 구조적 문제와 스파게티 설계 방식이 존재하였습니다. 개발자도 알기 어려운 숨겨진 기능도 많았으며 왜 만들었는지 모르는 기능도 많았습니다. 그래서 제품의 구조와 기능별 요구사항을 재정의해야겠다는 필요성을 느꼈습니다.
레거시보다 높은 성능과 개발 및 유지보수 효율성 증대
반복적인 수동 입력 UI로 인해 사용자 편의성을 저해하고 휴먼에러가 발생할 가능성이 높았습니다. 또한 고객사별 제품의 버전 관리가 힘들었으며, 유사한 서비스에 동일한 기능을 추가할 때 반복적인 개발 비용이 산정되었습니다. 그래서 관리의 용의성과 다양한 확장 가능성을 고려하였습니다.
목표
- 기존 서비스의 한계점을 극복하고 사용자 편의성을 고려한 유저 인터페이스 적용
- 새롭게 만드는 프로젝트를 시작으로 서비스의 방향성과 컨셉, 개발 과정을 체계적으로 재정의
- 모던 프론트엔드 프레임워크(Vue 3)를 적용
위 3가지 목표를 달성하기 위해 요구사항을 철저히 분석하고 관점 지향적인 설계를 통해 개선해야겠다고 생각했습니다.
기대 효과
레거시 서비스의 기능과 요구사항을 분석하고 스펙을 정리하면서 지속 성장 가능한 제품이 되기를 원했습니다. 사용자 편의성과 고객 비즈니스 효율성을 올려 제품의 신뢰도를 향상시키고 싶었습니다. 회사 내부적으로 첫 번째 Vue 3 기반의 서비스를 만듬으로써 앞으로 만드는 신제품 개발에 도움이 될 수 있는 초석이 되고 싶었고, 컴포넌트 단위 개발로 공통화, 재사용성, 개발 품질의 향상에 기여하고 싶었습니다.
기획
어떻게 기획하였을까?
과거에는 회사에 기획팀이 존재하지 않았습니다. 만들어야 하는 제품을 가장 잘 알고 있는 직군은 다름 아닌 개발자였습니다. 초반 기획은 balsamiq cloud를 사용하여 빠르고 간편하게 와이어 프레임을 만들었으며 이를 기반으로 다른 팀들과 커뮤니케이션하고 스펙을 전달하였습니다.
기획 의도
레거시 서비스의 오래되고 복잡한 로직을 타파하고자 쉽고 단순하고 자연스럽게 사용자가 이해할 수 있도록 구성하였습니다. 관점 지향적인 컨셉을 통해 종단 관점사와 횡단 관점사의 교차로 자연스러운 그룹화를 구성할 수 있도록 하였으며, 특히 사용자들이 Admin 페이지에서 복잡한 설정을 하는데 혼란을 줄이기 위해 노력했습니다. 또한, Top-Down 전략을 통해 사용자에게 필요한 기능과 정보를 컴팩트하고 효과적으로 제공하기 위해 화면을 구성하였습니다. 기존 제품의 복잡한 동선을 줄여 최소한의 움직임으로 결과를 도출하기 위해 동일한 방향으로 프로세스가 진행될 수 있도록 하였습니다.
전문적으로 기획을 구성하지는 않았지만 단순하고 일관성있게 구성할 수 있도록 노력하였습니다. 최대한 많은 케이스를 고려하여 사이드이펙트를 줄이기 위해 고민하였으며, 정말 커다란 문제가 있지 않는 한 기존에 세워두었던 원칙을 지키기 위해 노력하였습니다.
하지만 좀 더 전문적이고 정확한 기획이 필요하다고 판단하였으며 개발자의 몫을 줄이기 위해 그리고 장기적으로 서비스의 기초 기획/스펙을 만들기 위해서 등 여러 이점들과 함께 꾸준하게 기획팀의 신설을 요청드린 결과 신설 조직이 탄생하게 되었습니다.
메뉴 구성
불필요한 메뉴의 depth를 줄이기 위해 최대한 flat하게 구성하였으며, 사용자가 메뉴명을 보고 어떠한 기능을 하는 메뉴인지 알 수 있도록 메뉴명도 가독성있게 변경하였습니다.
일관되지 않고 불분명한 분류를 비즈니스 기능에 따라 구성하고 중복되는 메뉴를 통합하고 혼재되어있는 기능을 분리하였습니다.
화면 구성
화면은 상단 헤더, 좌측 네비 영역, 중앙의 컨텐츠 영역으로 분리하여 간단한 레이아웃으로 구성하였습니다. 최대한 일관된 디자인 패턴을 지키기 위해 노력하였으며, 지정된 높이/너비 등을 타입(S/M/L) 화시켰습니다.
UX
레거시 서비스와 비교하여 기본적인 유저 플로우를 강화하고 어떠한 역할과 기능을 하는지 손쉽게 알 수 있도록 가이드를 제공하였습니다. 예를 들어 Question(❓) 아이콘을 만들어 마우스 호버 시에 세부 설명을 팁으로 제공한다거나, 에러가 발생하였을 때 특정 상황에 따라 서버 상태 및 상세 설명을 Warning(⚠) 아이콘과 함께 텍스트로 보여주었습니다.
로딩마스크와 No Record 등의 UI를 통해 마우스 이벤트 동작 이후에 API가 실제로 pending 중인건지 아니면 데이터가 없는 것인지에 대해 구분하기 위해 노력하였습니다.
그리고 데이터가 변경/삭제 되는 경우에 무조건 메시지 창을 띄우는 단계를 추가함으로써 사용자의 의도치 않은 실수로 인해 오동작하지 않게 하였습니다.
기획팀이 신설된 이후
대략 1년 반 전부터 기획팀이 생기게 되었으며 여러가지 프로세스와 역할이 변경되었습니다.
- 기존 서비스 분석을 통해 새롭게 만드는 서비스의 방향과 스펙을 정리해주셨습니다. 개발자가 놓칠 수 있는 세세한 부분까지 신경써주셔서 개발에 집중할 수 있는 환경을 만들어주셨습니다.
figma를 통해 유저 플로우에서부터 와이어프레임, 요구사항, 스펙이 정리되었습니다.- 디자인팀 뿐만 아니라 영업팀, 엔지니어팀 분들의 요구사항을 교통정리해주셔서
결과적으로는 같은 의견/내용이지만 화면이 상이했던 부분을 하나로 통일해주시기 위해 노력해주셨습니다.
그 결과 FE 개발자들은 기획서를 기반으로 개발할 수 있게 되었고 개발자들끼리 소통하는 시간이 늘게되어 업무의 효율성과 집중도가 올라가게 되었습니다. 개인적으로는 기획팀이 좀 더 성장해져서 회사 전반적인 서비스에 영향을 주게 되면 좋겠다고 생각합니다.
개발
프로젝트 프레임워크 선택
회사에서는 이미 Vue 2로 만들어진 여러 프로젝트가 존재하였으며, 아직 모던 프론트엔드 프레임워크에 익숙하지 않는 팀원들도 있었습니다. 또한, 2020년 5월에 Vue 3 로드맵 일정이 발표되면서 높은 성능, Composition API 방식, Typescript 공식 지원, script setup 방식 등에 매력을 느껴 개인적으로도 마음이 이끌렸습니다.
기존에 FE 개발자들과 같이 만든 오픈소스 UI 컴포넌트 라이브러리도 Vue 3 beta버전으로 만든 상황이었기 때문에 리뉴얼 프로젝트 개발할 때 오픈소스 UI 컴포넌트를 프로젝트에 패키지로 추가하여 실제로 사용하면서 같이 완성도를 높이고 싶었습니다.
프로젝트 초창기 환경은 다음과 같습니다.
Vue 3(Composition API), Vuex 4, Vue-Router, TypeScript 3.9.x, SASS, Webpack 4, Babel, Axios(REST API) 등
프로젝트 초기 세팅
작성한 블로그 글 중 Vue.js 3 정리하기 (Vue-CLI 4, Vue 3, Composition API, TypeScript, Vuex 4)에 자세히 적혀있습니다.
코드 리뷰
초창기에는 Vue에 익숙하지 못했던 개발자들이 많았습니다. 그래서 유지보수성이 높고 가독성이 좋은 코드를 만들기 위해서 꾸준히 코드리뷰를 진행하였습니다. 현재 프로젝트에 투입되더라도 금방 적응할 수 있도록 러닝커브가 낮은 코드를 작성하도록 기준을 정했습니다. 또한 정해진 인원 이상이 upvote해야 코드를 머지할 수 있는 등의 규칙을 정하였습니다.
Git Flow 도입과 브랜치 전략
혼자서 개발하시는 분들은 브랜치 전략을 도입하면 배보다 배꼽이 더 커져서 개발할 때 오히려 독인 경우도 존재할 것 같습니다. 과거의 경험에 빗대어보면 단일 브랜치로 개발하는 서비스도 많았고, 왜 형상관리를 해야하는지에 대해 이해를 못하시는 분들도 많았습니다.
새롭게 만들고자 하는 서비스는 도커를 통해 구축하기 쉬운 서버 환경이 있었기 때문에 다양한 환경을 구축할 수 있었습니다.
- 릴리즈 버전을 확실히 관리하기 위해
- CI를 통한 자동배포를 인해 BE 개발자들과 더 좋은 커뮤니케이션을 위해
- 필요에 따라 다른 환경에서 개발/테스트하기에 쉬운 환경 구축을 위해
- 각 유관부서에 버전별 서버가 필요한 경우 즉각적인 피드백을 위해
우린 Git-flow를 사용하고 있어요 블로그 글을 기반으로 아래와 같은 브랜치 전략을 세웠습니다.
develop브랜치 : gitlab의 issue에 의해 자동 생성된 feature 브랜치가 머지되는 FE 개발용 브랜치입니다. 이는 쿠버네티스 환경과 연동되어있어 자동으로 개발용 도메인으로 배포됩니다.release브랜치 : release 버전 별로 브랜치를 따로 두었으며, 이 브랜치에 머지되는 경우는 release candidate로 구분하였습니다. release 브랜치에 tag를 만들어 major/minor/patch version을 만들어 관리하였습니다.feature브랜치 : gitlab의 issue에서 자동생성되는 브랜치를 모두 feature 브랜치로 고려하였습니다. hotfix, improvement와 같이 이슈의 타입 별로 관리하기에는 관리적 리소스가 낭비된다고 판단하여 모두 feature로 통합하여 관리하였습니다. feature 브랜치에서 develop 브랜치로 Merge Request할 때는 리뷰가 완료된 이후에는Squash&Merge로 머지하도록 규칙을 만들었습니다. develop 브랜치의 관리 용이성을 위해 로컬 환경에서의 여러 번의 커밋을 하나의 커밋으로 합치도록 하였습니다.
develop 브랜치, 버전별 release 브랜치마다 서버를 구성하였기 때문에 QA나 타 부서에서 서비스를 사용하고 테스트하기에 용이하였습니다.
도입된 규칙과 기술
lint
JavaScript의 최신 문법을 사용하여 개발하고 구성원들과 코드의 규칙을 만들려고 하였습니다. 하지만 땅바닥부터 구성하는 것보다 airbnb 규칙을 기반으로 Eslint를 구성하되 예외를 필요에 따라 하나씩 추가하는 것이 효율적이라고 판단하였습니다.
프로젝트의 스타일은 SASS로 BEM 규칙 기반으로 디자인을 구성하였습니다. 프로젝트에는 stylelint-config-standard 기반에서 scss/order 규칙을 추가한 컨벤션을 적용하였습니다.
Vue 코드 컨벤션은 Vue Style Guide의 등급 중에서 Essential, Strongly Recommended, Recommended 규칙까지 따르는 것으로 구성하였으며, 필요에 따라 추가적인 규칙을 허용하여 사용하고 있습니다.
typescript
레거시 서비스들은 변수타입에 따른 버그와 휴먼에러에 상당히 많은 부분 리소스를 낭비하고 있습니다. Vue 2와 비교하여 TypeScript로 만들어진 Vue 3는 당연히 TypeScript를 공식 지원하고 있으며, TypeScript를 도입하기에 좋은 기회라고 생각했습니다. 아직 팀원분들이 TypeScript에 대해 익숙치 않았지만 JavaScript의 슈퍼셋 언어이므로 프로젝트를 개발하면서 배울 수 있다고 판단하여 TypeScript를 점진적으로 도입하였습니다.
팀원분들과 같이 TypeScript를 배워가면서 프로젝트에 점진적으로 도입하다보니 아래와 같은 단점이 존재하였습니다.
- 초기 코드에는 컨벤션 룰이 없었기 때문에 TypeScript가 적용되어있지 않은 경우도 있고 TypeScript를 필요이상으로 남발한 경우도 존재합니다.
- 정해진 기한 내 개발되어야 하는 경우
any가 사용되었습니다. - Vue 3 Composition API 문법 중 일부가 TypeScript를 지원하지 않는 부분이 존재했습니다.
현재의 코드의 퀄리티의 차이가 존재하기 때문에 리펙토링이 필요합니다.
의존성 라이브러리 업데이트
프로젝트 초기 구성은 webpack 4 기반의 vue-cli를 사용하여 만들었습니다. 서비스가 정식적으로 2번 릴리즈되고 난 뒤에는 앞으로 프로젝트의 규모가 더 커질 것이라고 판단했습니다. 그동안 신경쓰지 않았던 번들러를 업데이트하여 최신 기술을 쓰고 싶다는 약간의 개인적인 욕심도 포함되어있고 개발 환경의 빌드 속도나 빌드 크기 이점과 이전 버전보다 더 편리한 관리적인 포인트를 가져가고 싶었습니다. webpack 4에서 5로의 변경하면서 몇 가지 의존성 라이브러리들과 플러그인들의 업데이트를 같이 진행하였습니다. 여담으로 axios의 경우 특정 버전에 보안이슈로 인해 업데이트를 같이 진행하였습니다.
- webpack 4 > 5
- eslint 7 > 8
- stylelint 13 > 14
- vue 3 당시 최신버전
- axios 당시 최신버전
- eslint-plugin-vue 7 > 8
- eslint-config-typescript 7 > 10
- node-sass(deprecated) > sass
- d3 3 > 4
- 그 외 @types/ 패키지 설치
이 작업을 진행 한 이후에 Front-end 환경 세팅 정리라는 블로그 글을 작성했습니다. vue-cli를 사용하지 않고 맨바닥에서부터 FE 프로젝트를 구성하려면 어떤 패키지들이 필요한 지 공부할 수 있었습니다. webpack 4에서 사용했던 loader들이 5가 되면서 asset modules로 변경되는 등 연관된 의존성에 대해서도 알 수 있었습니다.
Vite 도입
webpack 5로 변경된 이후에 프로젝트의 크기가 커지면서 로컬 노드 서버를 시작하는데 적게는 2분에는 많게는 5분 넘게 걸렸습니다. 개발 빌드 시간을 단축시켜 생산성을 높이기 위해 개발 빌드의 번들러를 vite로 변경하였습니다. 이 과정은 vue-cli 프로젝트를 vite 3으로 마이그레이션해보기 블로그 글에 자세히 적혀있습니다.
API 서비스 레이어 리펙토링
프로젝트 API 코드의 기술 부채 해결과 API가 대규모로 변경하게 되면서 서비스 레이어를 리펙토링해야하는 상황이 생겼습니다.
OpenAPI Generator를 사용하여 Swagger UI의 OAS json 파일로 API 코드 파일, TypeScript 모델 파일을 자동생성하여 리펙토링하는 경험도 하였습니다. 이 과정은 OpenAPI Generator로 자동생성된 API, Model 파일을 적용하고 리펙토링한 후기 블로그 글에 자세히 적혀있습니다.
그 외 Axios를 통해 retry, timeout, AbortController를 통한 cancellation, interceptor처리 등의 역할을 처리하였습니다.
다국어 및 Timezone 처리
국내 사용자뿐만 아니라 해외 사용자도 판매하기 위해 국제화 부분을 고려하였습니다. vue-i18n을 통한 다국어 처리와 Timezone 처리를 진행하였습니다. UTC 처리를 위해 moment.js도 고려해보았지만 서비스 지원 중단과 번들 경량화 이슈가 존재하여 day.js를 활용하였습니다.
데이터베이스와 서버가 여러 타임존을 수집/처리하는 것보다 UTC+0으로 통일하여 관리하는 방향이 깔끔하다고 판단하였으며, 화면에서는 유저계정 정보에 있는 타임존(지역)에 따라 offset처리하는 스펙으로 정하게 되었습니다.
에러 처리 및 메시지
컴포넌트의 에러처리는 컴포넌트 성격에 맞게 인풋박스 하단에 invalid 메시지를 표현한다거나 프레임 우측상단에 워닝 아이콘을 보여주는 식으로 처리하였습니다.
API의 응답 데이터에 대한 에러는 JAVA의 커스텀 Exception명을 그래도 받아 처리하는 방식을 사용했습니다.
우선 서버에서 예외처리를 커스텀 익셉션을 만들어 처리한다고 들었습니다. 그래서 이 Exception명을 vue-i18n의 KEY로 만들고 보여줄 메시지를 다국어 처리된 VALUE값으로 보여주는 방식을 선택했습니다. 그 이유로는
- 서비스의 주 사용자는 DB 엔지니어입니다. B2B 서비스 특성 상 에러의 발생원인이 화면, 서버가 아닌 디비나 에이전트일 수도 있기 때문에 문제가 발생한 부분을 빨리 발견하기 위해서
- 에러 메시지 자체를 보는 화면이 있기 때문에
- JAVA의 Exception명과 FE의 API 에러 메시지의 규칙을 만들기 위해서
- JAVA의 Exception명과 다국어를 한 번에 처리하기 위해서
등의 이유로 위와 같은 방식으로 에러 처리와 메시지 처리를 진행하였습니다.
성숙해진 오픈소스 UI 라이브러리
사내에서 진행하는 Vue 3 기반 오픈소스 UI 라이브러리를 프로젝트에 추가하여 개발하게 되었습니다. 라이브러리 사용자가 되어 프로젝트에 직접 넣어 같이 개발해본 결과, 새로운 기능도 추가하게 되었으며 누락된 부분을 보완할 수 있었습니다.
컴포넌트 구조와 관리
무작정 view에서부터 절차적인 방향으로 개발하는 것보다 작은 컴포넌트를 만들고 이를 조합하는 방향으로 개발하였습니다.
Atomic Design 패턴 도입과 변형
프로젝트 초반에 컴포넌트를 어떻게 하면 잘 구현할 수 있을까 고민하다가 그 당시에 유행하던 Atomic Design을 선정하게 되었습니다. Effective Atomic Design 블로그 글을 보고 Atomic Design 패턴과 Vue 3의 Composition API 방식을 버무려서 컴포넌트를 구현하게 된다면 관리적 측면에서도 재사용성에도 많은 도움이 될 것 같다고 판단하였습니다.
Atomic Design 방법론은 컴포넌트 단위를 역할과 책임에 따라 atoms, molecules, organisms, templates, pages이라는 기준을 세워서 개발하는 방식입니다. 처음에 가장 까다로웠던 점은 컴포넌트 구성 단위에 대한 기준이었습니다. 다른 아토믹 디자인 관련 글을 읽어봐도 개념은 얼추 알겠는데 직접적으로 와닿지 않았습니다. 처음부터 너무 빡빡한 규칙이 정해진다면 개발의 생산성 저하와 피로감이 생길 것 같아 기준에 대한 고민을 많이 하였습니다.
atoms와 molecules를 하나로 합치기로 하였습니다. 가장 작은 atoms와 atoms를 합성한 molecules를 나눴을 때 관리하기가 힘들 것 같았으며, 작은 단위의 컴포넌트를 개발자가 모두 알아야 하는 부분이 러닝커브가 있을 것 같다고 판단하였습니다.
organisms 단위는 도메인과 연관된 기능이 있는 컴포넌트로 정하였습니다. 컴포넌트의 크기나 뎁스와 상관없이 기능적인 역할과 책임을 다한다면 모두 organisms에 포함시켰습니다.
Container-Presentatonal 디자인 패턴 도입
만들고 있는 프로젝트는 특정 분야의 관제 모니터링 서비스이며, B2B에 특화된 디자인/기능을 가지고 있으며, 아래와 같은 몇 가지 특징이 존재합니다.
한 화면에서
많은 정보를 보여주고 분석할 수 있어야 합니다.
전문가, 엔지니어분들이 원하는복잡하고 다양한 기능이 구현되어야 합니다.
레거시 서비스가 갖고있는기존 기능이 충족되어야 합니다.
레거시 서비스보다 더사용하기 편해야합니다.
이 부분을 어떻게 하면 효율적으로 개발하고 유지보수할 수 있을지 고민했습니다. 레거시 서비스와 이를 기반으로 새롭게 만드는 프로젝트는 공통적으로 Stateful한 경향이 있는 Container 컴포넌트가 엄청 많이 반복된다는 사실을 발견했습니다. 또한, 레거시 서비스의 기존 기능을 충족시키기 위해서는 이 기능들을 하나의 Container 컴포넌트를 만들고 발전시키는 방향으로 가야겠다고 생각했습니다.
사용자가 검색한 조건에 대한 API 데이터를 가져와 보여주는 하나의 동작을 하는 Container 컴포넌트는 Vuex나 Pinia와 같은 상태관리 라이브러리에 접근하여 반응형이 이루어지도록 구현하였습니다.
이렇게 만들어진 Container 컴포넌트는
- 사용자가 선택한 탭 패널 안에 존재하거나
- 사용자가 검색한 결과 화면에 존재하거나
- 모달창에서 나타나거나
- 다른 메뉴에서 연계를 한다거나
상관없이 아무 화면이나 컴포넌트에 붙이더라도 항상 동일한 역할과 책임을 지도록 구현하였습니다.
그 결과 한 번 제대로 만들어진 컴포넌트가 필요에 따라 재사용할 수 있었고, 수정사항이 나오거나 테스트를 할 때도 작은 비용으로 구현할 수 있어 효율성이 증가하였습니다. 물론 아무것도 없는 상태에서 작은 단위로 컴포넌트를 구현하여 합치는 초기 과정은 시간이 오래 걸렸습니다.
결론적으로는 Vue 컴포넌트의 양방향 바인딩
v-model에 파라미터를 넣고, 블랙박스처럼 내부 동작은 외부에서 볼 수 없지만 데이터가 나타나는 이상적인 형태의 컴포넌트가 개발되었습니다.
회고
나를 회고
과거 컨테이너 박스 안에서 추위에 벌벌 떨면서 파견 개발하던 때와 달리 좋은 사람들과 좋은 환경에서 새로운 프로젝트를 이끌고 프론트엔드 리드 역할로써 여러가지 경험과 방법을 시도할 수 있었던 좋은 기회가 되었습니다. 2년 넘는 기간동안 리더의 역할과 책임감을 가지면서 조직원들과 공동의 목표를 달성하기 위해서 많은 노력을 하였습니다. 처음에는 첫 번째 여행을 떠나는 뉴비 모험가 파티마냥 많이 서툴렀지만 호흡을 점차 맞춰나가면서 눈치만 주고받아도 각자 역할을 하는 베테랑이 되었습니다.
되돌아보면 초기 1년 동안은 모든 업무와 역할을 하면서 동료들을 도와주고 모든 상황들을 컨트롤하기 위해 노력하였는데 이 방식은 오래가지 못하였습니다. 리더가 항상 바쁘게 움직이고 여유롭지 못하게 보였기 때문에 조직이 경직될 수 밖에 없었고 나라는 사람은 항상 무언가에 쫓기는 듯한 모습으로 비춰졌습니다.
2022년 말에 유튜브 EO 이오 채널에 올라온 이런 얘기를 하면 화내는 사람도 있죠 [한기용] 3부 최종화 영상을 보면서 나를 되돌아보는 점검의 시간을 가질 수 있었습니다. 업무의 경중에 따라 우선순위를 정하는 부분이 많이 부족하다고 깨달았으며, 모든 것을 완벽하게 할 수 있다는 자만심을 반성하게 되었습니다. 현재는 함께하는 동료들과 역할을 나누고 함께 믿는 방식으로 일을 진행하고 있습니다. 과거보다 확실히 더 여유로워졌고 양질의 아이디어와 과정, 성과가 나올 수 있었습니다.
처음에는 리더의 역할이 부담스럽고 무거웠지만, 리더로써 일하는 경우만 경험할 수 밖에 없는 부분도 있다고 생각합니다. 높은 자리에서는 더 멀리 볼 수 있게 되어 시야가 더 넓어졌고 성숙한 개발자로써 알차고 뜻깊은 경험을 할 수 있어 좋았습니다.
프로젝트를 회고
열정적으로 무언가를 진행하고 더 이상적인 방향으로 나아가려고 했지만 어떠한 이유로 인해 중단되는 경우가 종종 있었습니다. 모두가 완벽하게 일을 하고 좋은 방향대로 진행하고 싶지만 할 수 없는 조직간의 현실적 어려움과 각자의 사정이 있다는 것도 알게 되었습니다. 커뮤니케이션의 중요성을 느끼게 되었고 더 좋은 시너지를 내기 위한 타이밍과 노하우를 몸소 체득하게 되었습니다.
워터폴 방식의 개발방법에서 2주 단위의 스프린트 방식으로 변경함에 따라 실무담당자들이 테스크에 집중할 수 있게 되어 업무 효율성이 증가하게 되었습니다. 하지만 기획에서 릴리즈까지의 애자일 방식을 진행하다가 갑작스러운 세일즈로 인해 일정이 어그러지는 경우가 존재하였는데, 이런 경우에는 어떤 방식으로 진행해야할 지 애매했습니다. 또다른 아쉬운 점은 스프린트 단위의 스토리 포인트를 통해 개발 리소스를 추정하는 부분이 미흡했습니다.
프로젝트의 초기 기획과 요구사항, 개발, 릴리즈, 세일즈까지 경험해볼 수 있었고 현실적인 어려움속에서 제한적인 시간/자원을 가지고 어떻게 효율적으로 성과를 낼 수 있는지에 대해 배울 수 있었던 프로젝트가 되었습니다.
이제 이 프로젝트는 곧 4번의 릴리즈를 앞두고 있습니다. 좋은 사람들과 열심히 만든만큼 좋은 결과가 나왔으면 좋겠습니다.
