2023년의 끝자락과 2024년
4년간의 컨설팅 커리어를 버리고 프론트엔드 개발자가 되기위해 독학도 해보고 부트 캠프도 해보았다. 그리고, 2023년 11월 프론트엔드 직무로 새로운 시작을 하게 되었다.
입사 후 1년이라는 시간동안 정말 많은 프로젝트를 부시고 다시 만들었다. (대충 10개쯤...?) 그러면서 이상과 현실의 다름을 깨달았고 개발자지만 코딩 보다는 업무를 잘 하려고 고민했던 한 해였던거 같다.
쉽지 않았던 첫 프로젝트
1. 개발 조직이 없었던 회사에서 개발 시작하기
입사 후 첫 프로젝트는 자사 홈페이지 리뉴얼이었다. 당연히 기존 환경과 코드를 확인하기 위해 정보를 요청했지만, 전달받은 것은 FTP 접속 정보였다. 여기서부터 "앵?" 이라는 생각이 들었지만, FTP로 접속해보니 백업 파일들이 뒤섞여 있고, 버전 관리가 전혀 되지 않은 상태여서 당황스러웠다.
back, back_2, new 라는 파일들을 보고 있자니 조금은 끔찍했다. 더 무서운건 어떤걸 사용하고 있는지 몰라서 함부로 못건드린다는 말 이었다.
그래서 내가 이 회사에서 가장 먼저 한 일은 개발도 인프라 환경 구성도 아닌, GitHub Organization 생성이었다. 2023년에 아직도 이런 곳도 있었다니...
2. 배포 후 발생한 예상치 못한 문제들
내가 팀장님께 전달 받았던 내용은 "기존 코드를 모두 버리고 메인페이지만 개발하면 되니 기술 스택을 정해서 해"였다. 기존 PHP 기반이었지만, 실제 개발 기간이 1~2주도 안되는 기간동안 개발부터 배포까지 하기엔 PHP에 대한 기본 지식도 없어 불가능해 보여 익숙한 React로 개발을 시작하게 되었다.
배포 후, 예상하지 못한 문제가 발생했다. 기존 홈페이지에서 제공되던 일부 기능이 누락되었다는 불만이 나왔고, 특히 관리자 페이지를 통해 공지사항을 등록하는 기능이 제대로 작동하지 않는다는 버그 리포팅까지 받게 되었다.
PHP로 구현된 페이지 까지는 이해하겠는데, 어드민이라니... 어드민이라는게 있었다는 것을 이때 처음 알았다. 기존 PHP 기반의 관리자 페이지가 단순히 프론트엔드만 있는 것이 아니라 데이터 관리까지 풀스택으로 개발이 되어있었던 것 이었다.
빠르게 대응하기 위해 PHP를 복구하고, Apache 서버 설정을 통해 React와 PHP를 URL 기반으로 분리했고, PHP에서 필요한 데이터를 JSON 형태로 제공하는 간단한 API를 구현하여 이 상황을 해결하였다.
CMS 관리자 페이지에 대한 요구 사항은 없었고 물리적으로 1~2주 안에 그 부분까지 개발한다는 것은 무리였지만, 홈페이지를 관리한다면 당연히 필요한 부분이었는데 생각 못했던 내 잘 못도 있었던거 같다.
(하지만 저도 처음인걸요~)
왜 이렇게 개발이 오래걸려요
처음에는 이 말을 듣고 의야했다. 내가 생명공학에 대한 베이스 지식이 없는 상태에서 기획이 구두로 이루어지고 디자인이 하루에도 몇 번씩 바뀌는 상황에서 배포해야 하는 당일까지 변경 요청사항이 발생해서 도저히 일정을 맞추기가 어려웠다
그런데, 화면에는 많은 과정과 이해 관계들로 늦어지는 부분들은 보이지 않았기에 결국에는 모든 것들이 나의 문제처럼 상황이 흘러가버렸다
문제점 찾아보기
나는 개발자니까 개발을 잘해야 한다는 생각이 가장 컸다. 그래서 새로운 프로젝트를 시작할 때마다 주로 개발적인 요소만을 생각했다.
예를 들어,
styled-components 대신 vanilla-extract로 바꿔야겠다.공통 컴포넌트를 잘 만들어서 storybook으로 관리해봐야겠다.
들과 같은 기술적 고민들로 시간을 보냈다. 이 고민들이 잘 못된 것은 아니지만, 지금 당장 필요한 고민인가라는 질문에는 그렇지 않은 경우가 많았다.
-
styled-components → vanilla-extract 변경 해봐야지
- 변경하려는 이유는 성능적 장점과 추후 SSR(서버사이드 렌더링)을 고려했을 때 vanilla-extract가 더 적합하다고 생각해서였다.
- 하지만 그동안 성능상의 문제가 발생한 적도 없었고, 현재 만들고 있는 서비스가 SSR이 필요한지 SSG(정적 사이트 생성)가 필요하진 조차 가늠되지 않는 상황이였기 때문에 불필요한 고민이였다.
-
공통 컴포넌트와 storybook 도입
- 빠르게 성장하는 조직에서 제품 개발 속도를 높이기 위해 필요하다고 판단했다.
- 그러나 3~4 가지의 서비스를 만드는 과정에서 디자인 컨셉 서로 너무 달랐고, 그에 따라 발생하는 예외 사항들로 인해 공통 컴포넌트의 코드가 점점 복잡해졌다.
- 결국 초반 많은 시간을 투자에 만든 컴포넌트들이 커스텀 스타일이 필요해지는 경우가 많았고, 공통 컴포넌트의 의미가 흐려지고 활용하기도 어려워지는 결과를 낳았다.
이처럼 개발만 바라보며 고민하고 개선하려했던 부분들이 오히려 불필요한 오버엔지니어링이 되어버렸다.
개발 중심이 아닌 서비스 중심으로 생각하자
그래서 나는 개발이 아니라, 빠른 서비스 출시를 위해 업무를 효율적으로 처리하는 개발에 초점을 맞춰 고민하기로 생각을 바꿨다
빠른 제품 출시를 위한 기술 스택 다시 정하기
- TailwindCSS + Shadcn 도입
- UI를 빠르게 구성하고 수정하기 위해 TailwindCSS를 기본으로 하되, Shadcn의 미리 정의된 컴포넌트를 활용해 생산성을 높였다.
- 이를 통해 디자인 변경과 같은 요구사항에도 빠르게 대응할 수 있었다.
- OpenAPI Generator인 Nesia 도입
- API 명세를 기반으로 자동화된 타입 생성과 클라이언트 코드 생성을 통해 API 작업 시간을 대폭 단축했다.
- 매번 수작업으로 API 타입을 정의하거나 변경 사항을 반영하던 비효율을 없애는 데 효과적이었다.
이와같은 기술스택을 변경하면서 HeadlessUI, OpenAPI Generator에 대한 이해와 Nesia를 구성하기 위한 Turborepo를 경험해보고 오히려 배우는 것들이 많았다.
마무리
1년이라는 시간 동안 제대로 된 서비스를 출시하지 못한 점은 아쉬움으로 남지만, 나름대로 여러 라이브러리와 기반 지식들을 학습하고 실제 프로젝트에 적용하면서 많은 것을 배웠다고 생각한다. 내가 했던 고민과 결과물들이 100% 정답이라고는 할 수 없겠지만, 어떻게 보면 프론트엔드 개발자라면 한 번쯤 겪어볼 법한 오버 엔지니어링과 트레이드오프 같은 주제들을 깊이 고민할 수 있었던 점은 큰 의미가 있었다.
2025년에는 꼭 제대로 된 서비스를 하나 출시해보고 싶다.
