나는 무엇으로 개발자임을 증명하려 했을까

요즘 나는 성장 정체기에 들어선 것 같다.

일을 덜 한 것은 아니다. 기능을 만들고, 오래된 코드를 정리하고, 오류를 추적하고, 사용자 행동을 측정할 환경도 만들었다. 할 수 있는 일만 보면 이전보다 분명히 많아졌다.

그런데 성장했다는 느낌은 잘 들지 않는다.

주변에서 잘 나가는 사람들이 더 좋은 회사로 옮기거나 높은 보상을 받는 모습을 보면, 내가 해온 일 전체가 뒤늦게 채점되는 기분이 들 때도 있다. 그 사람들이 잘된 것과 내 경력은 별개의 일인데도 그렇다.

그럴 때면 헷갈린다.

나는 정말 좋은 개발자가 되고 싶은 걸까.

아니면 어디서든 선택받고 살아남을 수 있는 사람이라는 증거가 필요한 걸까.

이 글은 왜 이렇게 많은 일을 하고도 성장하지 않았다고 느끼는지 알아보기 위해 쓰기 시작했다.

게임을 만드는 게 게임이 됐다

내가 처음 한 개발 비슷한 일은 모바일 마인크래프트에서 서버를 여는 작업이었다.

친구들과 같이 게임하고 싶어서 공유기 설정을 뒤졌다. 포트포워딩이 무엇인지도 제대로 이해하지 못했다. 인터넷에 나온 설명을 따라 설정했고, 잠시 뒤 친구들이 내가 연 서버에 들어왔다.

원리는 알지 못했지만 결과는 분명했다. 내가 보이지 않는 설정 하나를 바꾸자 다른 사람들이 내 게임 안으로 들어왔다.

포켓몬스터 시리즈를 할 때도 비슷한 경험을 했다.

특별한 포켓몬이 태어나는 일이 단순한 운이 아니라, 게임 안의 숨은 난수와 트레이너의 고유한 값으로 결정된다는 정보를 알게 됐다. 데이터를 확인할 수 있는 기기를 사고, Reddit에서 조건이 맞는 사람을 찾아 내가 가진 알을 대신 부화시켜 달라고 부탁했다.

게임이 데이터로 움직인다는 것을 그때 처음 느꼈다.

그전까지 게임은 이미 완성된 세계였다. 정해진 규칙 안에서 잘 플레이하면 됐다. 내부가 보이기 시작한 뒤에는 규칙을 알아내고 바꾼 다음, 다른 결과가 나오는 것을 확인하는 일이 더 재미있어졌다.

게임을 만드는 게 게임이 됐다.

게임 개발 교육을 듣고 Unity도 배웠다. 다만 여러 사람이 하나의 게임을 만드는 일은 생각보다 훨씬 어려웠다.

객체지향을 충분히 이해하지 못했고, 각자가 작성한 코드가 어디에서 어떻게 만나야 하는지도 정하지 못했다. 기획과 디자인, 개발이 서로 무슨 일을 하고 무엇을 필요로 하는지도 제대로 이해하지 못했다.

우리는 같은 게임을 만든다고 생각했지만 각자의 머릿속에는 조금씩 다른 게임이 있었다. 각자가 이해한 방식대로 작업한 뒤 결과물을 한데 모으고, 어긋난 부분을 다시 고치는 일을 반복했다.

일을 여러 명이 나눠서 한다고 저절로 하나의 제품이 되는 것은 아니었다.

전망은 AI를 가리켰고, 흥미는 웹으로 향했다

대학에 입학할 때는 내가 무엇에 끌리는지보다 전망을 먼저 봤다.

AI가 앞으로 중요해질 거라고 생각해 AI융합학부에 진학했다. 입학 전에는 혼자 공부하는 머신러닝 & 딥러닝을 읽었다. 길이와 무게를 이용해 도미와 빙어를 구분하는 k-최근접 이웃 예제를 따라 했던 기억이 있다.

코드를 실행하면 도미와 빙어가 분류됐다. 그런데 그 결과로 내가 무엇을 만들고 싶은지는 떠오르지 않았다.

반면 웹에서는 하나를 만들고 나면 다음 것을 만들고 싶었다.

노마드코더에서 Todo 앱과 날씨 앱, 뉴스 크롤러를 따라 만들었다. 클론 코딩에 불과했지만 코드를 바꾸면 화면이 바로 달라졌고, 기능을 붙이면 작은 결과물이 생겼다. 배포하면 다른 사람에게 보여줄 수도 있었다.

게임에서 좋아했던 일과도 닮아 있었다. 숨은 규칙을 찾아 바꾸고, 그 결과를 확인하는 일이었다. 다만 웹에서는 그 거리가 훨씬 짧았다.

그때는 어떤 개발자가 되고 싶은지 생각해본 적이 없다.

그냥 내가 만든 것을 사람들이 써주길 바랐다. 화면이 나오고, 배포되고, 사용자 수가 생기고, 커뮤니티에서 반응이 돌아오는 과정이 좋았다.

내 제품이 가치 있으면 됐다.

그때까지는 아직 나까지 증명할 필요는 없었다.

개발은 선택받아야 계속할 수 있었다

군 복무도 개발병으로 했다.

군대 때문에 개발 경력이 끊기는 것이 싫었다. 같은 시간을 보내더라도 조금 더 경험을 쌓고 싶었다. 개발병으로 일하면서 화면뿐 아니라 ERD와 DB까지 맡게 됐다.

충분히 이해하지 못한 상태에서 책임만 넓어지는 것 같아 부담스러울 때도 있었다. 그래도 맡은 만큼 이해하는 범위는 넓어졌다.

전역 전 휴가 때는 인턴 공고를 찾아 거의 닥치는 대로 지원했다. 인턴을 뽑지 않는 회사에는 자리를 만들어줄 수 없는지도 물었다.

몇 번의 면접 끝에 한 회사와 출근하기로 합의하고 근로계약서까지 작성했다. 전역 이후의 진로가 정해졌다고 생각해 자취방도 먼저 구했다.

그런데 전역 당일이 되자 연락이 닿지 않았다. 정말 초기 스타트업이니 갑자기 사정이 바뀔 수도 있다고 생각했다. 하지만 근로계약서까지 쓴 구직자에게 아무 설명 없이 연락을 끊는 것은 다른 문제였다.

며칠이 지나서야 출근하지 말라는 통보를 받았다. 구직자에 대한 최소한의 예의가 없는 회사에 더 기대를 걸고 싶지 않았다.

이미 방을 구했고 생활비가 나가기 시작했다. 다시 급하게 면접을 봤다. 어떤 회사에서 무엇을 배울지 따질 상황이 아니었다.

어떤 자리든 먼저 확보해야 했다.

이때부터 개발은 재미있는 제작 도구이면서, 계속 선택받아야 유지할 수 있는 직업이 됐다.

사람들이 내 제품을 사용하느냐만큼 회사가 나를 개발자로 받아주느냐도 중요해졌다. 제품의 가치와 내 가치가 조금씩 붙기 시작했다.

하지만 회사가 나를 뽑아줬다는 사실은 내가 채용될 수 있다는 것만 알려줬다.

내가 어떤 판단을 하는 개발자인지는 알려주지 않았다.

선택받는 것만으로는 부족했다

첫 회사에서는 작은 프로젝트를 넘어 실제 고객을 위한 제품을 고민할 수 있을 거라고 기대했다.

실제로는 제품을 성장시키는 경험보다 개발자로 일하는 법을 배우는 시간이 더 컸다. 그 과정에서 내가 부족하다는 감각도 커졌다.

다른 개발자들은 같은 문제를 어떻게 볼까. 무엇을 기준으로 결정을 내리고, 의견이 다를 때는 어떻게 맞춰갈까.

그게 궁금해 CMC라는 연합동아리에 들어갔다.

CMC에서는 기획자와 디자이너, 개발자가 한 팀을 꾸려 하나의 제품을 만들었다. 우리 팀은 소프트스킬을 다루는 피어나라는 제품을 만들었다.

제품의 주제는 소프트스킬이었지만, 만드는 동안 오히려 내 소프트스킬의 부족함을 봤다.

나는 기획과 디자인이 어느 정도 끝날 때까지 기다렸다가 마지막 리뷰어처럼 참여했다. 구현하면서 이상한 점을 발견해야 의견을 냈다.

문제를 발견하는 것과, 좋은 결정이 만들어지는 시점에 대화를 여는 것은 다른 능력이었다.

프로젝트 밖에서도 함께 공부할 동료가 생겼다. 다른 사람의 코드를 보는 것만큼, 그 사람이 어떤 질문을 하고 무엇을 중요하게 생각하는지를 가까이에서 보는 일이 많이 남았다.

피어나에서 내가 만난 가장 어려운 기술 문제는 웹뷰 기반 앱에서 이미지를 저장하는 일이었다.

웹에서 만든 이미지를 앱으로 넘겨 사용자의 기기에 저장해야 했다. 나는 이미지를 Base64 문자열로 바꿔 웹과 앱이 주고받게 하는 방법을 떠올렸다. 끝내 기능을 동작하게 만들었다.

당시의 나에게는 꽤 큰 문제를 해결한 경험이었다.

그런데 해결하고 나니 더 큰 질문이 생겼다.

웹과 네이티브가 섞인 제품을 실제 회사에서는 어떤 환경에서 함께 개발할까. 앱과 웹의 버전은 어떻게 맞추고, 무엇을 기준으로 배포하며, 실제 기기에서 안전하게 동작하는지는 어떻게 검증할까.

이런 문제를 더 큰 규모에서 겪은 사람들은 어떻게 일할까.

그 답을 가까이서 보고 싶어 토스에 가고 싶었다. 대단한 개발자임을 증명하기보다, 혼자 풀기 어려운 문제를 먼저 겪은 사람들과 함께 일하고 싶었다.

학교에서는 기본기를 공부했다. 밖에서는 디자인 시스템과 테스트, 웹뷰, 빌드와 배포, 오픈소스를 건드렸다. 들어가서 배우고 싶었던 환경을 작은 규모로 흉내 냈다.

그 뒤 반년 동안 토스에 계속 지원했다. 지원하고 부딪히고 다시 준비하는 일을 반복한 끝에 토스에 합류할 기회를 얻었다.

가까이 있는 것과 함께 일하는 것은 달랐다

좋은 사람들이 있는 곳에 들어가면 저절로 배울 수 있을 줄 알았다.

내가 가까이에서 배우고 싶었던 것은 코드였다. 큰 규모의 제품에서는 문제를 어떻게 나누고 어떤 구조를 선택하는지, 웹과 앱이 섞인 환경을 어떻게 개발하고 배포하는지 보고 싶었다.

토스에서 처음 들어간 팀에서는 엔지니어가 나 혼자였다.

당시 나는 구현과 소통 모두 미숙했다. 비즈니스의 요구를 구현 가능한 단위로 나누는 데 서툴렀고, 구현 과정에서 드러난 제약이나 막힌 상태를 팀이 이해할 수 있는 언어로 제때 설명하지도 못했다.

그래서 코드를 만드는 일만큼 팀에 적응하는 일도 어려웠다.

팀을 옮긴 뒤에는 그동안 어려워했던 소통의 문제가 더 선명하게 보였다.

새 팀의 리더는 기능을 구현하는 것만으로는 부족하다고 말했다. 책임을 맡았다면 이해관계자들과 먼저 대화하고, 일정과 불확실성을 명확하게 공유해야 한다는 피드백이었다.

그 피드백을 받으며 잘 일하는 데에는 코드보다 먼저 필요한 것이 있다는 걸 알게 됐다. 이해관계자들과 맥락을 맞추고, 지금 어디까지 진행됐는지, 무엇을 모르고 있는지, 일정이 어떻게 달라질 수 있는지를 먼저 공유해야 했다.

내 상태를 공유하는 일은 단순한 보고가 아니었다. 팀이 같은 정보를 바탕으로 다음 판단을 내릴 수 있게 만드는 일이었다.

소통하는 법을 조금 알게 되자, 처음 배우고 싶었던 엔지니어링의 어려움도 다르게 보였다.

첫 팀에서도 종종 시니어 프론트엔드 개발자와 격주로 이야기할 기회가 있었다. 회사 안의 다른 엔지니어들이 어떤 고민을 하고 어떤 기준으로 판단하는지는 위클리에서 들을 수 있었다.

둘 다 배울 기회였지만, 대부분 내가 이미 작업을 진행하고 결정을 내린 뒤에 조언이나 결론을 듣는 방식이었다. 진행 중인 상태와 막힌 지점을 어떻게 설명해야 할지 몰랐고, 그래서 대화가 실제 작업과 잘 이어지지 않았던 것 같다.

다른 사람의 판단을 듣는 것과, 내 판단이 굳기 전에 같은 문제를 꺼내 함께 고쳐나가는 것은 달랐다.

소통은 엔지니어링과 별개의 능력이 아니었다. 내가 무엇을 이해했고 어디에서 막혔는지 열어야 다른 사람의 판단도 내 작업 안으로 들어올 수 있었다.

좋은 판단을 보고 배우는 것과, 그 판단으로 실제 결과를 만드는 것은 같은 일이 아니었다.

배운 것을 결과로 이어보고 싶었다

토스에서 배운 것은 분명 있었지만, 그것만으로 내 판단이 실제 제품과 사업에서 어디까지 통하는지는 알 수 없었다.

큰 조직에서는 여러 사람과 팀이 하나의 결과를 만든다. 내가 한 선택이 제품과 사업에 어떤 영향을 줬는지 따로 떼어 보기는 어려웠다.

작은 팀에서는 조금 다를 것 같았다.

무엇을 만들지 정하는 일부터 구현과 배포, 사용자 반응을 확인하는 일까지 더 넓게 맡을 수 있을 거라고 생각했다. 내가 한 판단과 결과 사이의 거리가 짧아지면, 내 실력이 어디까지 통하는지도 더 분명하게 확인할 수 있을 것 같았다.

회사 이름을 빌리지 않고도 설명할 수 있는 결과를 갖고 싶다는 마음도 있었다.

그래서 작은 Web3 회사로 옮겼다.

사용자가 내가 만든 제품을 쓰고 실제로 돈을 냈다는 사실은 가장 간단하고 냉정한 답처럼 보였다.

매출을 만들면 내가 증명 가능한 개발자가 될 수 있다고 생각했다.

코드만 짠다고 개발자가 아니니까.

그 결과를 만들려면 제품을 움직일 기반도 필요했다. 당시에는 필요한 환경이 없다면 그것까지 직접 만들면 된다고 생각했다.

그때 남긴 기록에 “내가 곧 플랫폼 팀이다”라는 문장이 있다.

팀과 기반이 없다는 사실도 핑계가 아니라 빠르게 움직일 기회로 봤다. 엔지니어 한 명의 역량이 사업을 얼마나 성장시킬 수 있는지 증명하겠다고 썼다.

지금 보면 내 몫을 꽤 크게 잡은 말이었다.

당시에는 진심이었다.

시험조차 주어지지 않았다

내가 예상한 시험은 내 판단과 매출의 연결을 확인하는 일이었다.

실제로 가장 먼저 해야 했던 일은 제품을 볼 수 있게 만드는 일이었다.

사용자가 어디에서 막히는지 알 수 없었고, 오류도 체계적으로 모이지 않았다. 기본적인 UX에도 손볼 곳이 많았다.

Sentry와 Mixpanel을 붙였다. 매출을 확인할 대시보드도 직접 만들었다.

그런데 라이브 환경에 접근할 권한이 없었다. 내가 만든 대시보드의 실제 매출 숫자를 확인할 수도 없었다. 몇 달이 지나 따로 이야기한 뒤에야 접근 권한을 얻었다.

숫자를 볼 수 있게 된 뒤에도 내가 만들던 기능과 매출 사이의 연결은 잘 보이지 않았다.

제품이 어떤 사업 구조 안에서 움직이는지, 중요한 결정이 왜 내려졌는지 충분히 알기 어려웠다. 사용자 자체도 너무 적었다.

방문, 가입, 활성화, 재방문, 결제. 어디든 문제가 있어 보였지만 무엇이 가장 큰 병목인지 말할 만큼의 모수가 없었다. UX를 바꾸거나 새로운 기능을 만들어도 그 판단이 맞았는지 확인할 반응이 돌아오지 않았다.

당시에는 시험조차 주어지지 않았다고 생각했다.

내가 매출을 만들 수 있는 사람인지 확인하러 왔는데, 그걸 확인할 정보와 사용자, 의사결정 구조가 없다고 느꼈다.

이 글을 쓰며 그 문장을 다시 보게 됐다.

그 말은 내가 느꼈던 답답함을 설명했지만, 내가 무엇을 늦게 했는지까지 설명하지는 못했다.

나도 더 일찍 물었어야 했다.

매출은 어디에서 나는가. 지금 만드는 기능은 그 흐름의 어디에 놓여 있는가. 이 제품은 누구를 데려오려 하며, 사용자가 어떤 행동을 해야 결제로 이어지는가.

나는 그 질문보다 먼저 기능과 UX를 고쳤다. 당장 손댈 수 있는 일이었고, 바뀐 결과를 화면에서 바로 확인할 수 있는 일이었다.

사업 구조를 묻고 필요한 맥락을 요구하는 일은 뒤로 밀렸다.

혼자 잘하면 될 줄 알았다. 그런데 혼자서는 확인조차 할 수 없는 일이 많았다.

성적표에 무엇을 남길 것인가

마인크래프트 서버를 열 때는 내가 공유기 설정을 바꾸고 친구가 접속하는 사이에 거의 아무것도 없었다.

내가 한 일과 결과가 바로 붙어 있었다.

지금은 그 사이에 회사의 결정과 사업 방향, 시장과 규제, 유입과 사용자 수가 끼어 있다. 더 큰 결과를 원하게 됐지만, 그 결과에서 어디까지가 내 판단으로 만들어진 것인지 알아보기는 오히려 어려워졌다.

나는 오랫동안 성적표에는 숫자나 이름이 찍혀야 한다고 생각했다.

사용자가 늘었는지, 매출이 올랐는지, 어느 회사에 들어갔는지. 그런 표식이 없으면 그사이에 달라진 판단도 같이 사라졌다.

그런데 지나온 일을 써보니 숫자보다 먼저 바뀐 것이 있었다.

예전에는 결정이 끝난 뒤 이상한 점을 말했다. 지금은 책임을 맡으면 필요한 사람과 일정부터 맞추려고 한다. 예전에는 기능이 동작하면 문제를 해결했다고 생각했다. 이제는 그 기능을 계속 개발하고 배포하고 검증할 수 있는 조건까지 본다.

작은 회사에 들어간 뒤에도 처음에는 내가 손댈 수 있는 기능과 UX부터 고쳤다. 지금이라면 그보다 먼저 묻고 싶은 것이 있다.

이 제품의 매출은 어디에서 나는가. 지금 만드는 기능은 그 흐름의 어디에 있는가. 무엇이 없어서 아직 판단할 수 없는가.

이런 변화는 대시보드에 찍히지 않는다.

그렇다고 ‘성장한 것 같다’는 감상만으로 성적표를 채울 수도 없다. 숫자가 아닌 것이 내 성적표에 남으려면, 그것도 증거가 있어야 한다.

이전에는 무엇을 보지 못했는지, 지금은 무엇을 먼저 보는지. 같은 상황을 다시 만났을 때 어떤 선택이 달라졌는지. 그 판단이 말로만 남지 않고 다음 작업에서도 반복됐는지.

쓰고 보니 이 글은 어떤 개발자가 되고 싶은지 선언하는 글이 아니었다.

내 성적표에 무엇을 적을지 다시 정하는 글에 가까웠다.

내가 만든 것이 사용자와 사업에 어떤 결과를 남겼는지는 계속 확인하고 싶다. 그 숫자가 나오기 전까지 그사이에 달라진 판단을 전부 공란으로 둘 필요는 없다.

내가 바꾼 것이 현실에서 정말 다른 결과를 만드는가.

그리고 그 결과가 아직 나오지 않았을 때, 나는 무엇이 달라졌다고 말할 수 있는가.