ari Space 
사내 디자이너들이 AI로 이미지를 더 쉽게 만들 수 있게 해주는 웹 서비스를 맡았다.
처음 이 프로젝트에 배정됐을 때는 그냥 만들면 되겠지 싶었다. Next.js 쓰고, API 연결하고, 배포하면 끝 아닌가?
1년 4개월이 지난 지금 돌아보면, 그때 나는 정말 아무것도 몰랐던 것 같다.
배포부터 막혔다
제일 먼저 부딪힌 건 배포였다.
Next.js 하면 Vercel이 맞다고 봤다. 근데 회사에서 Vercel 연동이 안 됐다. 방화벽 문제였는지, 따로 막아놓은 건지는 정확히 모르겠다. 그래서 Vercel은 선택지에서 빠졌다. 그럼 AWS Amplify는? 찾아보니까 정적 배포라서 SSR이 안 됐다.
나는 API Routes가 필요했다. 로그인 토큰을 httpOnly로 관리해서 클라이언트에 노출 안 되게 하려고. 근데 Amplify는 정적 배포라 서버가 안 돌아갔다.
결국 선택지는 백엔드 개발자가 이미 쓰고 있던 Kubernetes였다.
K8s는 과했을까
솔직히 말하면, 프론트엔드 하나 배포하는 데 K8s는 과한 선택이었던 것 같다.
근데 당시에는 “이미 인프라가 있으니까 그걸 쓰자”는 판단을 했다. EC2를 새로 세팅하거나 Vercel 우회 방법을 더 찾아볼 수도 있었는데, 그러지 않았다. 지금 생각하면 그 시도를 해봤으면 어땠을까 싶기도 하다.
K8s 배포는 혼자 한 건 아니었다. 백엔드 개발자한테 많이 배웠다. Dockerfile 만들어서 전달하고, 시크릿 키 설정 파일 넘기고. 대신 dev, prod, staging 환경별로 네임스페이스 나누고 시크릿 키 관리하는 건 내가 했다.
혼자 다 하진 않았다. 하지만 모르는 건 물어보고, 내가 해야 할 건 했다. 그게 협업이니까
다음에 비슷한 상황을 마주한다면, 인프라를 그대로 따르기보다 비용, 복잡도, 운영 주체를 비교해서 선택지를 더 적극적으로 제안해 보고 싶기도 하다.
사용자가 2명이었다
서비스를 만들어놓고 보니까 쓰는 사람이 2명이었다.
기능은 계속 추가되는데, 디자이너들이 뭐가 바뀌었는지를 몰랐다. 뭐가 있는지도 모르는데 어떻게 쓸 수 있을까 이러니 당연히 안썼던 거다.
그래서 선임 디자이너한테 먼저 찾아갔다. 슬랙으로도 얘기하고, 직접 만나서도 물어봤다. “지금 이 서비스 어때요? 뭐가 불편해요?”
그러다가 회사 내 일본 디자이너 쪽에서도 이 서비스를 쓰고 싶다는 얘기를 들었다. 그래서 정기적으로 구글 밋 하자고 제안했다.
피드백 미팅을 시작하고 나서
정기 미팅을 시작하니까 달라졌다.
이전에는 기능이 추가돼도 사용자들이 몰랐는데, 이제는 알게 됐다. 그리고 사용자들이 직접 “이런 기능 있으면 좋겠다”고 말해줬다. 그걸로 기획 방향을 같이 정할 수 있었다.
뭐가 중요한지 아니까, 개발 우선순위도 명확해졌다. 이전보다 빠르게 만들어서 전달할 수 있었다.
결과적으로 사용자가 2명에서 8~11명 정도로 늘었다. 엄청난 숫자는 아니고 매번 사용자 수가 달라졌지만, 낯선 사내 서비스 치고는 유의미한 변화였다. 단순히 기능을 추가한 게 아니라 소통 구조를 만든 게 더 큰 효과를 냈다고 느꼈다.
릴리즈 노트를 쓰기 시작했다
피드백 미팅이랑 비슷한 맥락으로, 릴리즈 노트도 쓰기 시작했다.
배포할 때마다 버전, 업데이트 사항, 날짜, 업데이트한 사람을 정리했다. 프론트, 백엔드, 배치 워크 각자 쓰고, 사용자한테 보여주는 전체 글에는 합쳐서 올렸다.
이게 별거 아닌 것 같은데, 하고 나니까 이슈 누락이 줄었다. “이거 언제 배포됐어요?”라는 질문에 바로 답할 수 있게 됐다.
통계 웹사이트도 만들었다
AI 이미지 서비스가 어느 정도 안정화되고 나서, 사용 통계를 볼 수 있는 웹사이트도 만들었다.
이건 기획, 디자인, 개발 전부 혼자 했다. Next.js에 API Routes 써서. 규모가 크진 않았지만, 처음부터 끝까지 혼자 결정하고 만든 건 처음이었다.
사용량 추이를 한눈에 볼 수 있게 되면서, 언제 트래픽이 몰리는지, 어떤 유저가 자주 쓰는지, 어떤 기능을 많이 쓰는지를 기준으로 우선순위 논의를 할 수 있게 됐다.
돌아보면
1년 4개월 동안 혼자 프론트를 담당하면서 배운 건, 기술적인 것보다 일하는 방식에 가까웠던 것 같다.
- 모르면 물어봐야 한다. 혼자 끙끙대면 시간만 간다.
- 사용자랑 직접 얘기하면 더 좋다. 추측하는 시간을 아끼게 된다.
- 기록을 남겨야 한다. 안 그러면 나도 까먹는다.
K8s가 과했던 것처럼, 더 좋은 선택지가 있었을 수도 있다. 근데 그 당시에는 그게 최선이라고 생각했고, 그 선택 안에서 할 수 있는 건 했다.
지금 다시 하라고 하면 더 나은 방식을 이전보다 잘 고려해서 만들 수 있을 것 같다는 생각도 든다.
마무리
1년 4개월 동안 하나의 서비스를 처음부터 안정화까지 경험한 건 운이 좋았다고 생각한다. 혼자라서 힘들었던 것도 있지만, 혼자라서 배운 것도 많았다. 그리고 주변 동료들의 도움이 많이 컸다.
다음에는 어떤 서비스를 만들게 될지 모르겠지만, 사용자한테 도움이 되는지를 계속 파악할 것 같고 그게 제일 중요하다는 것을 깨달았다.
모르는 건 물어보고, 사용자의 입장에서 생각하고, 기록 남기는 사람이 되어서 지속 가능한 서비스를 만들고 싶다.