구글을 나온 뒤, "일을 잘한다"는 기준이 달라졌다
세일즈포스와 구글에서 소프트웨어 엔지니어로 일하다 2024년 7월 창업했다. 코드를 잘 짜는 기준은 그대로인데, 그 앞에 놓인 질문이 내 책임이 됐다. 어떤 고객의 문제를 왜 지금 푸는가. 엔지니어에서 창업자로 넘어오며 바뀐 "좋은 일"의 기준을 적었다.
2024년 7월 구글을 떠났다. 그전에는 세일즈포스와 구글에서 소프트웨어 엔지니어로 일했다. 지금은 CollabOps를 만들고, 고객을 만나고, 팀과 제품의 방향을 결정한다. 직함이 달라진 만큼 내가 하는 일을 평가하는 질문도 달라졌다.
엔지니어로 일할 때 중요하게 생각했던 것들은 여전히 중요하다. 문제를 정확히 이해하고, 유지할 수 있는 구조를 만들고, 동료가 검토할 수 있게 설명하고, 운영에서 확인하는 일. 창업하고 나서도 그때 익힌 사고방식의 도움을 거의 매일 받는다.
다만 이제는 그 앞에 놓인 문제까지 내 책임이 됐다.
엔지니어와 창업자는 무엇이 다른가?
문제가 주어지는지, 문제를 고르는지가 다르다. 어떤 고객의 문제를 풀 것인지, 왜 지금 풀어야 하는지, 어느 범위까지 만들 것인지. 엔지니어일 때는 이 질문에 답한 사람이 따로 있었다. 지금은 내가 답해야 하고, 기술적으로 아무리 좋은 선택을 해도 이 질문이 흐리면 회사가 앞으로 나아가는지 알 수 없다.
솔직히 처음에는 이 차이를 과소평가했다. 코드를 수정하면 변화가 바로 보인다. 고객의 구매 조건을 이해하는 일은 대화가 필요하고, 답이 늦게 나오기도 한다. 근데 회사의 방향을 결정하는 데 가장 중요한 정보는 대부분 그 느린 대화 안에 있었다. 내가 통제하기 쉬운 일과 회사에 필요한 일이 항상 같지는 않다는 걸 그렇게 배웠다.
기능을 더 만들면 제품 설명이 쉬워질까?
쉬워지지 않는다. 오히려 길어진다. 나도 구현한 것을 보여주는 일이 익숙하다. 이슈 관리가 되고, 코드 리뷰가 되고, 파이프라인이 실행된다고 설명할 수 있다. 근데 고객이 왜 기존 환경을 바꾸고 새 제품에 비용을 지불해야 하는지는 기능 목록과는 별도의 답이 필요했다.
그 답은 고객이 지금 내리기 어려운 결정이 무엇인지에서 나왔다. 우리 경우에는 "이번 변경을 운영에 내보내도 되는가"라는 결정이었고, 그 결정에 필요한 근거를 한 화면에 모으는 것이 제품의 중심이 됐다. 이 과정은 기능은 늘었는데, 왜 우리 제품인가는 더 어려워졌다에 따로 적었다. 기능을 만든 경험은 그대로 자산이지만, 그 자산을 어느 문제에 집중할지 정하는 일은 별도의 작업이었다.
대표가 직접 빨리 처리하는 것은 좋은 일인가?
그 일이 다음번에도 대표를 기다리게 만든다면 아니다. 팀을 이끄는 일에서도 비슷한 변화가 있었다. 내가 직접 해결할 수 있는 문제를 해결하는 것은 여전히 필요하다. 동시에 팀이 스스로 판단할 수 있게 맥락과 기준을 남기는 일이 더 중요해졌다.
예를 들어 화면의 목적이 불명확할 때 직접 문구를 고치는 방법이 있다. 10분이면 끝난다. 그와 함께 이 화면에 들어온 사용자가 가장 먼저 해결하려는 질문을 팀과 정리할 수도 있다. 한 시간이 걸린다. 후자의 결과물은 다음 화면을 만드는 사람의 판단에도 남는다. 대표가 만드는 결과물에는 코드와 문구뿐 아니라 이런 기준도 포함되어야 한다고 본다. 이 기준을 어떻게 전달하는지는 주도적으로 일해 달라는 말에는 무엇이 빠져 있을까에서 이어진다.
그래서 요즘은 하루를 돌아보는 질문이 달라졌다. 얼마나 많은 일을 처리했는지와 함께 이렇게 묻는다.
- 고객이 구매를 결정할 조건을 더 이해했는가
- 팀이 추측하던 기준을 설명했는가
- 이번에 만들지 않을 것을 정했는가
이 질문들이 기술의 중요성을 줄이지는 않는다. 오히려 기술을 어디에 집중해야 하는지 더 정확히 묻게 만든다. 사람과 시간이 제한된 회사에서 모든 좋은 기술을 동시에 확보할 수는 없다. 우리가 풀려는 문제에서 반드시 필요한 깊이를 선택해야 한다.
큰 조직의 경험은 작은 회사에 어떻게 적용해야 하나?
형식이 아니라 그 형식이 해결하던 문제를 가져와야 한다. 큰 조직에서 일한 경험은 귀중한 기준을 줬다. 코드 리뷰의 밀도, 설계 문서의 역할, 운영 지표를 보는 습관. 동시에 지금의 회사에는 지금의 조건이 있다. 인력과 고객, 운영 환경이 다른데 절차의 형식만 가져오면 어떤 과정은 너무 무거워진다. 경험을 적용하려면 그 방식이 원래 어떤 문제를 풀고 있었는지부터 다시 이해해야 했다.
나는 아직 엔지니어의 시선으로 회사를 보는 순간이 많다. 구조를 잡고 연결을 이해하고 실행 결과를 확인하는 일이 좋다. 그 시선에 고객과 팀, 사업의 조건을 더해가는 중이다.
구글을 나온 뒤 달라진 것은 좋은 일의 기준이 내 작업 바깥으로 넓어졌다는 점이다. 내가 만든 것이 잘 작동하는지. 다른 사람이 그것으로 일을 끝낼 수 있는지. 고객이 그 결과를 가치 있게 여기는지. 예전에는 첫 번째 질문에 답하면 하루가 끝났다. 지금은 세 질문에 함께 답해야 하루가 끝난다.
비슷한 글
시니어를 더 뽑으면, 팀은 정말 빨라질까
경력 많은 엔지니어를 채용하면 팀이 빨라질 거라는 기대는 자연스럽다. 근데 채용 전에 확인할 것이 있다. 일이 느린 이유를 어떤 장면으로 설명할 수 있는가. 작업 시간과 경과 시간의 구분, 기대하는 결과를 적는 법, 시니어의 성과를 보는 기준을 정리했다.
백재민
한국에는 PC방이 있었다. 개발자에게는 어떤 환경이 필요할까
유학 시절 스타크래프트에서 한국인이라는 말 한마디가 만들던 기대에서 시작한 질문이다. 실력은 어디에서 만들어지는가. PC방이 보여준 연습과 피드백의 반복을 개발자의 하루로 옮기면, 변경 뒤에 무엇이 일어나는지 보이는 환경이 된다.
백재민
"주도적으로 일해 달라"는 말에는 무엇이 빠져 있을까
작은 회사를 운영하며 주도성을 요구할 때마다 되돌아오는 질문이 있다. 나는 무엇을 맡겼고, 어디까지 결정하게 했고, 기준을 처음부터 설명했는가. 주도적으로 일할 수 있는 조건 네 가지와 리더가 먼저 해야 할 일을 정리했다.
백재민