코드를 잘 짜는 게 개발이라 생각했던 주니어가, 헬멧을 쓴 날
개발자가 배달을 뛰게 된 사연
앱은 다 만들었는데, 배달원이 부족해서 결국 제가 직접 뛰었습니다.
첫 회사는 스타트업이었습니다. 주니어 백엔드 개발자로 전통시장 배달 플랫폼을 만들고 있었어요.
그때 저는 '코드를 잘 짜는 게 곧 좋은 개발자'라고 믿었습니다. 회의실에서 설계하고, 모니터 앞에서 코드를 짜고. 그게 제가 아는 개발의 전부였습니다.
그러다 런칭일이 왔습니다. 운이 좋게도 서비스가 열리자마자 주문이 엄청나게 들어왔어요. 그런데 정작, 배달할 수 있는 인력이 부족했습니다.
말도 안 되는 상황이었지만, 대표님의 지시는 단호했습니다.
"개발자라도 지금 당장 배달을 뛰어라."
솔직히 처음엔 좀 아쉬웠습니다. 주니어인 만큼 빨리 성장하고 싶었고, 더 큰 시스템, 더 멋진 기술을 다루고 싶었거든요. '전통시장 배달앱'이라는 도메인은 그 욕구를 채워주는 그림은 아니었습니다.
균열의 순간
그런데 이상하게도, 배달을 뛰면 뛸수록 머릿속이 복잡해졌습니다.
한 사장님 가게에서 알림 소리가 멈추질 않고 울리고 있었습니다. 새 주문이 들어오면 알림이 한 번 울리고 꺼지지 않는 버그였어요. 회의실에서는 한 번도 본 적 없던 문제였습니다. 시장에 나와 보니 화면도 잘 안 보이고, 끄는 법도 몰라 당황하시는 분들이 한둘이 아니었습니다.
그런데 진짜 충격은 그 다음이었어요. 이분들은 CS 채널에 문제를 올릴 수 있는 분들이 아니었습니다. 우리가 모르는 채로, 이 버그는 매일 사장님들을 괴롭히고 있던 거예요.
좋은 코드는 분명히 짰습니다. 그런데 좋은 제품은 안 만들어지고 있었습니다.
깨달은 것
그날 깨달았습니다. 자리에 앉아 기획의 요구사항만 듣고 코드를 짜는 것 — 그것만으로는 개발자가 아니구나.
더 나아가, 내가 만들고 있는 제품의 본질을 이해하고, 그 안의 문제를 끝까지 풀어내는 것. 그게 개발자의 본질이구나.
그때부터 개발하는 자세가 달라졌습니다. 무엇을 만들든 먼저 'Why'를 들여다보게 됐어요. 이 기능이 어떤 비즈니스 임팩트를 만드는지, 정작 쓰는 사람에게는 어떻게 가닿아야 하는지 — 코드 이전에 그걸 먼저 그려보게 됐습니다.
---
지금도 새로운 기능을 잡을 때마다, 저는 그 시장 골목을 떠올립니다. 알림이 멈추지 않던 가게, 끄는 법을 몰라 당황하시던 사장님의 얼굴.
그래서 저는 코드를 짜기 전에 항상 같은 질문을 먼저 합니다.
"이 코드 뒤에 누가 서 있는가."
이 한 줄이, 제가 시장 골목에서 배운 전부입니다.