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 도입
- 빠르게 성장하는 조직에서 제품 개발 속도를 높이기 위해 필요하다고 판단했다.
- 그러나 서비스마다 전혀 다른 디자인 컨셉과 예외 사항들로 인해 공통 컴포넌트의 코드가 점점 복잡해졌다. 결국 커스텀 스타일이 필요해지는 경우가 많았고, 공통 컴포넌트의 의미가 흐려지는 결과를 낳았다.
이처럼 많은 고민이 앞으로 일어날지 모르는 문제를 대비하는 데 치중했고, 실제로는 불필요한 고민이 되는 경우도 많았다.
하고 싶은 개발말고 업무를 위한 개발하자
그래서 나는 내가 하고 싶은 개발이 아니라, 빠른 서비스 출시를 위해 업무를 효율적으로 처리하는 개발에 초점을 맞춰 고민하기로 생각을 바꿨다
빠른 제품 출시를 위한 기술 스택 다시 정하기
- TailwindCSS + Shadcn 도입
- UI를 빠르게 구성하고 수정하기 위해 TailwindCSS를 기본으로 하되, Shadcn의 미리 정의된 컴포넌트를 활용해 생산성을 높였다.
- 이를 통해 디자인 변경과 같은 요구사항에도 빠르게 대응할 수 있었다.
- OpenAPI Generator인 Nesia 도입
- API 명세를 기반으로 자동화된 타입 생성과 클라이언트 코드 생성을 통해 API 작업 시간을 대폭 단축했다.
- 매번 수작업으로 API 타입을 정의하거나 변경 사항을 반영하던 비효율을 없애는 데 효과적이었다.
이와같은 기술스택을 변경하면서 HeadlessUI, OpenAPI Generator에 대한 이해와 Nesia를 구성하기 위한 Turborepo를 경험해보고 오히려 배우는 것들이 많았다.
마무리
1년이라는 시간 동안 제대로 된 서비스를 출시하지 못한 점은 아쉬움으로 남지만, 나름대로 여러 라이브러리와 기반 지식들을 학습하고 실제 프로젝트에 적용하면서 많은 것을 배웠다고 생각한다. 내가 했던 고민과 결과물들이 100% 정답이라고는 할 수 없겠지만, 어떻게 보면 프론트엔드 개발자라면 한 번쯤 겪어볼 법한 오버 엔지니어링과 트레이드오프 같은 주제들을 깊이 고민할 수 있었던 점은 큰 의미가 있었다.
2025년에는 꼭 제대로 된 서비스를 하나 출시해보고 싶다.
