화이트큐브에서의 10개월, 운영이 먼저인 개발에 적응하기

들어가며

2025년 10월에 화이트큐브에 합류해서 2026년 8월에 마무리했다. 10개월이 길다면 길고 짧다면 짧은데, 돌아보면 이전까지 내가 개발을 대하던 방식이 가장 많이 흔들린 기간이었다.

이 글은 특정 기술에 대한 글은 아니다. 그보다는 "기술적으로 잘 만드는 것"과 "팀에 실제로 도움이 되는 것"이 항상 같은 말은 아니라는 걸 배운 과정에 대한 기록에 가깝다.

낯설었던 것: 기술이 아니라 운영이 먼저 움직인다

합류하고 가장 먼저 부딪힌 건 속도였다. 그런데 단순히 빠르다는 것보다, 무엇이 개발의 출발점이 되는가가 내가 알던 것과 달랐다.

그전까지 익숙했던 흐름은 대체로 기술에서 출발했다. 풀어야 할 문제가 있고, 적절한 구조를 고민하고, 설계를 정리한 다음 구현에 들어가는 식이다. 논문을 읽고 구현하거나 사이드 프로젝트를 만들 때도 그랬다. 코드의 완성도가 곧 결과물의 완성도였다.

화이트큐브에서의 출발점은 운영이었다. 이번 주에 어떤 프로모션이 나가는지, 운영팀이 지금 무엇을 손으로 처리하고 있는지, 그래서 언제까지 무엇이 가능해야 하는지가 먼저 정해지고 개발은 거기에 맞춰 움직였다. 기술적으로 더 나은 선택지가 있다는 걸 알면서도 이번 주에 나가야 하기 때문에 다른 선택을 하는 일이 반복됐다.

처음에는 이게 꽤 불편했다. 지금 이렇게 짜면 나중에 문제가 될 텐데 싶은 순간마다 손이 멈췄다. 추상화를 덜 하고, 나중에 정리하자고 남겨두는 결정들이 쌓이는 게 스스로 타협처럼 느껴졌다.

관점이 바뀐 지점

시간이 지나면서 내가 기준을 하나만 들고 있었다는 걸 알게 됐다. 모든 코드를 오래 살아남을 코드처럼 짜고 있었던 것이다.

실제로는 코드마다 수명이 다르다. 몇 년을 버텨야 하는 영역이 있고, 이번 캠페인이 끝나면 같이 사라질 코드가 있다. 앞의 것에 들이는 공을 뒤의 것에 똑같이 들이면 꼼꼼한 게 아니라 그냥 낭비다. 반대로 뒤의 기준으로 앞을 짜면 사고가 난다. 중요한 건 완성도의 절대적인 수준이 아니라 요구의 수명과 코드의 수명을 맞추는 판단이었다.

이 기준이 생기고 나서는 속도가 훨씬 덜 불편해졌다. 빠르게 낸다는 게 대충 한다는 뜻이 아니라, 어디에 공을 들이고 어디를 의도적으로 비워둘지 매번 정하는 일이라는 게 분명해졌기 때문이다. 나중에 실제로 문제가 됐던 건 급하게 짠 코드가 아니라, 왜 그렇게 짰는지 아무도 모르는 코드였다.

패러데이: 짧은 주기로 계속 내보내기

처음 3~4개월은 패러데이라는 차량 장기 구독 서비스 팀에서 일했다. 앞에서 이야기한 "운영이 먼저"라는 감각을 가장 직접적으로 배운 시기였다.

프로모션 페이지와 화면 개선

프로모션 페이지를 여러 번 만들었다. 캠페인은 주기가 짧고 시작일이 정해져 있어서, 설계를 다듬을 시간보다 기한이 먼저 왔다. 처음에는 이런 페이지들이 금방 사라질 거라는 점이 아쉬웠는데, 앞에서 이야기한 기준이 생기고 나서는 오히려 여기가 힘을 빼도 되는 자리라는 게 분명해졌다.

전체적인 화면 개선 작업도 함께 했는데, 여기서 배운 게 따로 있었다. 바꾼 화면을 그냥 내보내는 게 아니라 A/B 테스트로 나눠서 붙이고 숫자로 판단했다는 점이다.

그전까지 나는 화면 개선을 "더 나아 보이게 만드는 일"이라고 생각했다. 그런데 나눠서 붙여보면 내가 확신했던 안이 항상 이기는 게 아니었다. 더 깔끔해 보이는 쪽이 지는 경우도 있었다. 내 판단이 가설일 뿐이고 검증은 따로 필요하다는 걸, 설명으로가 아니라 결과로 배웠다. 이 경험은 나중에 무엇을 만들지 정할 때 계속 영향을 줬다.

운영 어드민과 자동화

가장 기억에 남는 건 운영 어드민 작업이다. 기능을 하나 더 붙이는 것보다, 운영팀이 매번 손으로 반복하고 있는 일을 찾아서 없애는 쪽이 임팩트가 훨씬 컸다.

대표적으로 외부 서비스 연동을 붙여 사람이 중간에서 처리하던 단계를 걷어냈다.

모두싸인 연동: 계약서를 주고받고 상태를 확인하는 과정이 어드민 안에서 이어지도록 만들었다.
테슬라 Fleet API 연동: 구독이 시작되고 끝날 때마다 사람이 처리하던 차량 권한 위임과 해제를 자동화했다.

특히 권한 위임과 해제는 구독자가 늘어날수록 그대로 비례해서 늘어나는 일이었다. 한 건씩 보면 별것 아니지만 매번 사람이 붙어야 했고, 빠뜨리면 바로 문제가 되는 종류의 작업이다. 이런 건 기능을 하나 더 얹는 것보다 먼저 걷어내는 게 맞다고 생각했다.

이런 작업들의 공통점은 요구사항 문서에 적혀서 내려온 게 아니라, 옆에서 보다가 발견한 것들이었다는 점이다. 운영 중심으로 굴러가는 조직에서 엔지니어가 기여할 수 있는 가장 큰 부분이 여기 있다고 생각하게 됐다. 무엇을 만들지 정하는 단계부터 참여하는 것이다.

크롤링 인프라: 반대 성격의 일

패러데이 이후에는 사내 전반에서 쓰이는 핵심 크롤링 시스템의 인프라를 재구성하는 일을 맡았다. 내부 시스템이라 구체적으로 적기는 어렵지만, 성격이 앞의 일과 정반대였다는 점은 이야기할 수 있을 것 같다.

프로모션 페이지가 몇 주 뒤에 사라지는 코드였다면, 이쪽은 여러 팀이 이미 의존하고 있는 기반이었다. 잘못 건드리면 영향이 우리 팀에서 끝나지 않고, 한번 자리를 잡으면 오래 남는다. 즉 앞에서 세운 기준을 이번에는 반대 방향으로 적용해야 하는 일이었다. 여기서는 공을 들이는 게 과한 게 아니라 필요한 것이었다.

같은 조직 안에서 이렇게 성격이 다른 두 종류의 일을 연달아 해본 게 운이 좋았다고 생각한다. 빠르게 내는 일만 했다면 그게 전부인 줄 알았을 테고, 기반 작업만 했다면 왜 저렇게까지 급하게 내야 하는지 이해하지 못했을 것이다. 둘 다 해보고 나서야 상황에 따라 기준을 바꿔 잡는 게 실력이라는 생각이 들었다.

지표로 확인한 것

만든 것이 실제로 의미가 있었는지는 결국 숫자로 돌아왔다. 화면 개선은 A/B 테스트 결과로 바로 확인할 수 있었고, 어드민 자동화는 운영팀이 그 일에 쓰던 시간이 줄어드는 형태로 나타났다.

숫자를 보기 전까지는 내가 만든 게 도움이 되고 있다는 걸 사실 확신하지 못했다. 코드가 잘 돌아가는 것과 그게 팀에 의미가 있는 것은 다른 문제이고, 후자는 내 판단만으로는 알 수 없기 때문이다. 그래서 지표가 움직이는 걸 확인했을 때가 이 10개월 중 가장 뿌듯한 순간이었다. 기술적으로 어려운 걸 해내서가 아니라, 내가 옳다고 생각해서 만든 것이 실제로 맞았다는 확인을 받았기 때문이다.

남는 것

10개월 전의 나는 좋은 엔지니어를 코드를 잘 짜는 사람이라고 생각했던 것 같다. 지금은 조금 다르게 생각한다. 무엇을 만들어야 하는지 판단할 수 있고, 그 판단이 맞았는지 확인할 방법을 같이 만들어두는 사람에 더 가깝다.

물론 여전히 잘 짜는 건 중요하다. 다만 그게 목적이 아니라 수단이라는 감각이 생긴 게 이 기간의 가장 큰 소득이다. 빠른 조직에서 일해본 경험은 앞으로 어떤 환경에 가더라도 계속 쓰일 것 같다.

이제 쿠팡에서 머신러닝 엔지니어로 새로 시작한다. 도메인도 역할도 달라지지만, 무엇을 만들어야 하는지부터 묻는 습관은 그대로 가져가려고 한다.

함께 일한 분들께 감사드린다.