자발적 B작업이란,
<함께 자라기, 애자일로 가는 길 - 김창준 저> 책에서 "더글러스 엥겔바트"의 작업 구분법을 가져와서 A작업 (원래 하기로 했던 일), B작업 (A작업을 개선하는 일), C작업 (B작업을 개선하는 일) 로 나누어 설명합니다. 이 부분을 읽었을 때, "나는 회사에서 A작업만 하고 있는 게 아닐까? 회사와 나의 성장을 위해서는 혼자라도 조금씩 B,C작업을 하려는 시도를 늘려가야하지 않을까?" 라고 생각이 들었습니다.
그치만 가이드라인을 주는 사수가 없는 환경에 있는 주니어인 저로서는 어떻게 개선해야하는지 얼마나 개선해야하는지 무엇을 개선해야하는지 너무나 막막했고 어떤 식으로 저 스스로 회사에서 고군분투하면서 A작업 이외에 A작업을 개선시키기 위한 노력을 했는지 기록해봐야겠다고 생각했습니다. 더 좋은 개선 방법이 있을 수 있고, 문제는 저희 회사 환경에 국한되기 때문에 그대로 적용해쓰기에는 무리가 있을 수도 있습니다. 그러나 많은 스타트업에서 주니어 분들이 혼자서 고군분투하면서 성장하고 계시고 그런 여러 성장의 모습을 보여드리면서 다른 분들께 좋은 자극이 되었으면 하는 바람으로 시리즈물을 기획하게 되었습니다.
이 에피소드를 들어가기전에 짧게 제 소개를 하자면 저는 작은 규모의 스타트업에서 일하고 있는 프론트엔드 1년차 개발자입니다.
이벤트 페이지를 만들어야합니다
작년 12월부터 저희 회사에서는 새로 런칭한 유료 제품을 홍보하기위해 월간 프로모션 페이지를 만들어야했습니다.
프로모션 페이지를 통해서 사용자의 유입과 결제를 유도하기는 하지만, 디자인이 나오는 대로 모두 프론트엔드가 구현하기엔 일시적으로 쓰고, 변경이 잦은 페이지라서 많은 리소스를 들여서 구현할 수는 없는 페이지였습니다. 그렇기 때문에 그래픽요소들은 모두 이미지로 렌더링하고, 사용자와 인터렉션이 필요한 부분 (슬라이드, 결제버튼 등) 만 따로 코드로 구현하는 방향으로 기획하였습니다.
시간이 지나고
12월... 1월...2월 이렇게 몇 달이 지나면서, 이벤트 페이지 운영의 비효율적인 문제점을 발견할 수 있었습니다. 새로운 이벤트페이지를 오픈 할 때마다, 아니 이벤트가 끝나거나 이벤트 중간에 이벤트 이미지가 변경될 때 마다 hotfix 로 배포를 해야하는 경우가 종종 있었습니다. 작은 변경에도 스프린트 도중에도 브랜치를 바꿔서 hotfix를 하는 절차가 너무나도 비효율적이라고 생각했습니다.
이벤트페이지를 만들어주는 노코드 툴도 많아지고 있는 추세기 때문에... 개발 리소스는 0으로 수렴하게 만들면 만들수록 좋을 것 같다는 생각을 하였습니다 .
비효율적이라는 생각도 많기했는데, 반복적인 작업에서 오는 현타(?)... 같은게 많이와서 이 부분을 꼭 자동화시켜야겠다 (혹은 반자동화라도...) 라는 목표를 세웠습니다.
애초에 백엔드에서 이미지를 내려주면 되지 않나?
맞습니다. 이 문제의 가장 좋은 해결책은 이벤트페이지 에디터를 만드는 겁니다. (네, 이제부터 피그마를 만들어 봅시다.) 하지만, 당장에 개발 리소스와 시간이 부족하여 좋은 해결책이 될 수 없었죠.
조금 오래전 이야기지만 이러한 많은 변경사항들, 요구사항들 때문에 배민의 만다오와 같은 에디터를 만들어낸게 아닌가 싶습니다.
자 그러면 어떻게 효율적으로 "자동화" 된 어드민을 만들 것인가? 라는 것이 저의 숙제였습니다.
참고로 이 과제는 회사에서 저 스스로의 사이드프로젝트로 진행하던거라 백엔드의 리소스를 따로 가져다 쓸 수도 없고, 저의 지식의 한계도 있기때문에 배민의 만다오와 같은 아주 fancy 하고 모든 경우의 수를 커버하는 이벤트 페이지 에디터를 만드는 것은 불가능 했습니다.
그렇기 때문에 저는 구조에서 0.5스텝만 편하게라도 하는 개선을 목표로 삼았습니다. - 완벽하게 프론트 배포 플로우를 없앨 수는 없겠지만 불필요한 프론트 배포는 없애는 구조 - 이 계획을 세우고도 바로 백엔드 작업에 들어가진 못했지만, 백엔드를 도입하기 이전에 몇 번의 컴포넌트 추상화 를 거치면서 변화 하는 것 과 변하지 않는 것의 기준을 명확히 세우려고 노력했습니다.
프론트쪽 코드에서 변화가 많은 background 나 image url등을 상수화하고 그에 따라서 렌더링 되게 추상화된 컴포넌트를 추구하여 만들어져있었기 때문에 스키마 구조를 짤 때 아주 편했습니다. 이 경험을 하면서 저는 맨땅에 설계부터 해야하는 것이 아니라 애초에 프론트에서 상수로 쓰고 있는 것들을 db로 관리하는 것이 목표가 되어 복잡하거나 초기 설계를 잘 못하는 일을 막을 수 있었다고 생각했습니다.
Q. 바로 프로덕트로 쓰는 건 안좋지 않나요? 보안이라던지 그런 것들 신경쓴건 없었나요?
저는 사이드 프로젝트로 supabase를 적극적으로 먼저 사용해 보았습니다. 사이드 프로젝트를 운영,배포해보면서 먼저 보안사항이나 요금제 같은 것 대해서 미리 고민해 보았기 때문에 회사에서 팀원을 설득할 때 수월 했던 것 같습니다. 보안에 대해서 조금 신경쓴 부분은 client 에서 바로 supabase api를 호출하지 않고 (key 노출 하지 않기 위해) Next api에서 호출한 부분이 있습니다. 물론, 저희 회사의 프론트 챕터의 규모가 매우 작고, 의사 결정 과정이 빡빡하지 않은 것도 사실이라서 다른 큰 회사나 동료들을 설득해야하는 과정이 많은 회사에서는 부정적으로 비추어 질 수 도 있다고 생각합니다.
Q. 금액은? 어떤 플랜을 쓰고 있나요?
supabase는 무료플랜으로도 무제한 API requests 와 500 MB 의 DB 공간, 1 GB file storage를 제공하기 때문에 제가 개발하는 스펙에서는 모자란 스펙이 아니라서 무료플랜을 사용하고 있습니다.
Q. 개선 후 후기가 어떤가요? 효과가 있었나요?
(아직 어드민은 후기는 없습니다 그치만) 도입하고 바로 몇 일지나지 않아서 db에 저장되어 있는 정보인 ogImage 를 교체해달라는 요구사항이 들어왔고, 저는 그 요구사항을 1분 만에 수정할 수 있었습니다. 앞으로 어드민을 제공한다면 이런 요구사항은 소통도 필요없는 업무가 될 것을 기대합니다.
1차 배포 이후 놓친 것
1차 배포에서는 Supabase의 DB 데이터들을 그대로 보여주는 것에만 초점을 맞추다 보니 개발 환경 DB와 실제 환경 DB를 분리하지 못한 채로 배포하였습니다. 이 문제는 바로 다음 달 배포 준비에서 나타났습니다. 새로운 이벤트 페이지를 QA해야 하는 상황이었지만, 실제 데이터를 수정할 수 없는 상황이었습니다. 그래서 저는 재빨리 Supabase 개발 프로젝트를 하나 더 만들고 실제와 같은 환경의 DB와 스토리지를 만들어 QA를 진행하였습니다.
마무리
제가 이렇게 글을 남기게 된 것은 supabase 라는 툴을 알게되고 현업에서 써볼 수 있었던 것은 사이드 프로젝트 때문이였습니다. 사이드 프로젝트에서는 저보다 먼저 supabase를 써보시고 적극권유 해주신 분의 도움으로 많이 배우게 되었고, 결과적으로 회사에서의 생산성 향상에 도움이 되는 경험으로 이어지게된 경험을 공유하고자 하였습니다.
또한, 개발자로써 문제를 해결한다는 것은 꼭 엄청나게 팬시하고 판타스틱한 문제 해결방안으로 문제점을 계속해서 인지하고 어떻게서든지 해결한다면 그 해결책으로 현재 팀의 상황이 나아진다는 것을 느꼈습니다. 물론, 0.5스텝에서 머무는게 아니라 더 나은 방향과 방법을 연구하고 더 나아가야한다는 점은 변치않습니다.
저에게 이번 B작업은 "무엇을 했냐" 보다는 "왜 그렇게" 했고 그것의 효과, 결과가 어땠냐가 더 중요한 프로젝트였습니다. 또한, "자발적으로" 문제를 인식하고 해결방법을 실행한 첫 프로젝트기도 하고요. 이번 프로젝트를 발판으로 작은 것에서부터 큰 것까지 많은 자발적 B작업을 시도해볼 계획입니다. 이러한 시도들은 저와 저의 팀원들을 더 나은 방향으로 이끌어갈 것이라 생각합니다.
