구름의 COMMIT은 한 달에 한 번 수요일마다 기술, 개발, 성장, 조직 문화 등을 주제로 열리고 있습니다. 2024년 9월 COMMIT에서는 ‘비즈니스 마인드를 가진 개발자’를 주제로 문동욱 토스 프론트엔드 챕터 리드가 경험을 나누어 주셨습니다.
단순한 개발을 넘어 제품 개발을 비즈니스 관점으로 풀어낸 이야기에 개발자뿐 아니라 디자이너, 기획자, 대학생 등 많은 분이 구름스퀘어를 찾아주셨어요.
단순히 코드를 작성하는 개발자에 그치지 않고, 제품의 비즈니스적 가치를 창출하고 극대화하는 동욱 님의 이야기를 9월 COMMIT에서 자세히 들어봤습니다.
written by Somma
| 🎤 이 아티클은 문동욱 님의 9월 COMMIT 강의 내용을 바탕으로 재구성되었습니다. |
개발자는 “ ”이다
「비즈니스 마인드를 가진 개발자가 되는 방법」에 대한 이야기를 하기에 앞서서, 한 가지 질문을 먼저 던져보려고 합니다. 여러분은 개발자가 어떤 역할을 하는 사람이라고 생각하나요?
많은 분이 “개발자는 코딩으로 현실 문제를 해결하는 사람이다.”고 답을 합니다. 사실 포괄적으로 정의를 하자면 이 말도 맞습니다. 우리는 코딩, 프로그래밍을 통해서 제품을 생산하고, 그 제품으로 현실 문제를 해결하는 사람이 맞죠. 하지만, 우리가 여기서 꼭 염두에 둬야 하는 사실이 하나 있습니다.
바로 우리가 기업에 고용되었다는 사실입니다. 오늘 이야기할 내용은 모두 이 ‘담백한’ 사실에서부터 출발합니다. 물론 1인 개발자로 사업하는 분이나 비영리 오픈소스에도 기여하시는 분처럼 형태에 얽매이지 않는 다양한 개발자가 있지만, 그 외의 개발자 대부분은 누군가에게 고용되어서 고용주에게 기술 서비스를 제공합니다.
나의 비즈니스 VS 회사의 비즈니스
우리가 개발자로서 생각해 볼 두 가지 비즈니스가 있습니다.
첫 번째는 바로 나의 비즈니스입니다. 개발자는 고용 시장에서 기술 서비스를 판매하는 판매자, 즉 자영업자처럼 자신의 기술을 파는 사람입니다. 이건 단순히 회사에 소속된 직원이 아니라, 나만의 비즈니스를 운영하는 것과 같습니다.
두 번째는 회사의 비즈니스입니다. 우리가 제공하는 기술 서비스는 회사에 고용되는 형태로 판매되며, 회사는 우리의 기술을 통해 회사의 비즈니스 목표를 달성하려고 합니다. 우리는 단순히 한 번 팔고 끝나는 것이 아니라 지속적으로 문제를 해결하고 가치를 제공해야 합니다. 그래야 해결사로서 지속적인 역할을 맡을 수 있습니다.
이번 COMMIT에서는 이 두 가지 비즈니스를 중점으로 잘 풀어나갈 수 있는 방향과 저의 경험을 이야기하려 합니다.
나의 비즈니스
나의 비즈니스는 고용 시장에서 기술 서비스를 제공하는 판매자의 역할을 이해하는 것에서부터 시작됩니다. 기업은 단순한 고용주가 아닌 우리의 기술 서비스를 구매하는 고객입니다. 이 관계는 우리가 제공하는 가치를 기반으로 이루어지며, 그 가치 측정은 결국 기업이 더 많은 돈을 벌 수 있게 하는가에 달려 있습니다.
기업은 이윤을 극대화하기 위해 존재합니다. 우리가 기술을 제공하는 이유는 기업이 더 큰 이익을 창출하게 하기 위해서입니다. 우리와 기업의 관계는 우리가 가치를 제공하면 그에 상응하는 보상을 받는 구조입니다. 따라서, 기술 서비스를 제공하는 우리 역시 이윤을 창출하는 비즈니스를 운영하는 셈입니다.
중요한 점은 우리의 기술 서비스가 기업에 실질적인 문제를 해결해야 한다는 것입니다. 문제를 해결함으로써 기업은 더 큰 매출을 올리고, 더 크게 성공하면, 다시 우리에게 보상이 돌아오는 선순환 구조가 만들어집니다. 이 과정에서 적정한 서비스 품질과 가격을 맞추는 것이 중요한데요. 이것이 곧 나의 비즈니스의 본질입니다.
회사의 비즈니스
흔히 개발자를 “코딩으로 문제를 해결하는 사람”이라고 하지만, 문제 해결보다는 아름다운 설계나 고가용성 시스템에 더 집중하기 쉽습니다. 기술에 집중하는, 고집하는 태도를 보고 개발자의 장인 정신을 언급하곤 하는데, 전통적인 ‘장인’과는 다른 점이 있습니다.
혹시 『방망이 깎던 노인』이라는 수필을 아나요? 이 작품에서 노인은 방망이를 완벽하게 깎기 위해 끝없이 작업을 이어갑니다. 그의 장인 정신은 ‘’품질’에 집중하는데, 이 부분이 앞서 언급한 개발자의 장인 정신과 비슷해 보일 수 있습니다.
그런데 만약 고객이 당장 빨래를 해야 한다면, 완벽한 방망이가 아니라 당장 쓸 수 있는 방망이가 필요할 것입니다. 고객의 요구를 읽지 못하고 ‘품질’만 고집하기보다는, 개발자라면 사용자의 문제를 해결할 수 있는 가장 적합한 솔루션을 시의적절하게 제공해야 합니다.
결국 중요한 것은 기술 자체의 완벽함이 아니라, 그것이 실제로 사용자의 문제를 해결하는지 여부입니다. 사용자가 우리 서비스나 제품을 사용하는 이유는 그들이 가진 문제를 해결하기 위함이지, 기술적으로 얼마나 잘 만들어졌는지는 알 수도 없고 관심도 없습니다. 그렇기 때문에 기술적인 의사결정을 할 때는 항상 사용자의 문제 해결과 비즈니스 임팩트를 최우선으로 생각해야 합니다.
사용자의 경험과 가치를 향상 시키는 기술
토스 프론트엔드 챕터는 채용 시 프로그래밍 실력에 대해 유독 높은 기준을 요구하는 것으로 잘 알려져 있습니다. 이에 못지 않게 중요하게 여기는 것이 ‘행동 근거’입니다. 자신의 성과나 업적에 대한 의사결정의 이유가 명확한 사람인가를 보는 거죠. 이는 제 개인의 의견이 아니라, 프론트엔드 챕터의 모든 구성원들이 공유하는 생각입니다.
토스 개발자 각자는 자율적으로 최종 의사결정을 하고 있습니다. 의사결정권을 위임한 대신 결정에 대한명확한 근거는 필수입니다. 의사결정의 근거는 단순히 기술적인 성과에 그쳐서는 안 되고, 기술적 성과가 사용자 경험과 비즈니스에 어떤 기여를 했는지까지 명확히 설명해야 합니다.
예를 들어, SSR(Server Side Rendering) 서버의 성능을 개선해 TTFB(Time to First Byte)를 줄였다고 가정해 봅시다. 분명 좋은 성과지만, 왜 그 작업에 시간을 투자했는지 동료를 설득할 수 있어야 합니다. 기술적 성과가 사용자 경험이나 비즈니스에 직접적인 임팩트를 주지 않는다면, 동료들은 “그 성과가 왜 중요한가?”라는 의문을 가질 수밖에 없습니다.
이러한 이유로 의사결정의 근거가 명확하지 않거나 타당하지 않다면, 그 사람은 토스에서 일하기 어렵다고 판단합니다. 그래서 면접에서 “이 작업을 하기로 결정한 과정을 설명해주세요”, “왜 그 작업이 필요하다고 판단했나요?”와 같은 질문을 자주 하죠.
면접 시 많은 분들은 기술 성과만을 강조합니다. “성능을 향상시켰다”, “코드 가독성을 높였다”와 같은 말은 결국 “방망이를 잘 깎았다”는 말과 다르지 않습니다. 중요한 것은 기술 성과로 사용자가 어떤 혜택을 보았는가입니다.
결국, 개발자는 단순히 코드를 작성하는 것이 아니라, 기술을 통해 사용자의 문제를 해결하고 회사의 비즈니스 목표에 기여해야 합니다.
기술 성과를 비즈니스 성과로 연결하는 방법
최근 토스 앱 내 웹뷰 페이지들의 LCP(Largest Contentful Paint) 개선 작업을 하고 있는데요, 어떤 근거로 동료를 설득하고 이 일을 하고 있는지 소개하겠습니다.
토스 앱에서 실제 트래픽이 있는 웹 페이지는 약 4,000개입니다. 이 4,000개 페이지 모두의 LCP를 개선하는 게 효율적일까요? 한 페이지당 개선에 하루가 걸린다면 전체를 다 하려면 32,000시간이 소요됩니다. 개발자 3명을 투입하더라도 10,000시간이 드는 업무량입니다. 작업에 너무 많은 시간과 비용이 들죠. 그래서 비용을 절감할 방법을 고민했습니다.
개발자 1명의 연봉을 줄일 수는 없으니, 개선할 페이지의 수를 줄이는 것이 우선이었습니다. 그래서 비즈니스 임팩트가 큰 페이지부터 먼저 개선하는 계획을 세웠습니다. 사용자에게 직접적으로 영향을 줄 수 있고, 비즈니스에도 기여할 수 있기 때문입니다.
페이지 트래픽 비율을 기준으로 상위 50개 페이지만 개선해도 전체 웹뷰 트래픽의 88%를 개선할 수 있었습니다. 덕분에 개선에 드는 예상 비용(인적 자원 등)을 7억 4천만 원에서 990만 원으로 크게 줄일 수 있었죠.
트래픽만 많다고 그 페이지를 무조건 개선하진 않았습니다. 그 페이지가 소속된 서비스의 OKR(Objectives and Key Results)을 확인해 해당 서비스가 얼마나 중요한지를 보고 개선이 필요한지 판단했습니다. 이밖에도 그 페이지가 팀의 주요 목표나 성과에 직접적으로 기여하는지, 사용자들이 어떤 경로로 유입됐는지도 고려했습니다. 목적을 가지고 방문한 사용자는 로딩에 조금 시간이 걸려도 이탈 확률이 적기 때문입니다.
이 작업이 끝나면 최적화가 비즈니스 지표에 어떤 영향을 미쳤는지 살펴볼 계획이죠.
기술 의사결정의 본질
개발자는 단순히 기능을 구현하는 사람이 아닙니다. 사용자와 비즈니스의 문제를 해결해야 하는 사람이어야 합니다. 성능 개선이라는 기술적인 의사결정일지라도, 그 근거에는 비즈니스가 있어야 하죠.
개발자에게는 우리가 하는 일이 비즈니스에 어떤 영향을 끼치는지, 그 결과가 사용자의 문제 해결에 어떻게, 또 얼마나 기여하는지를 검토할 책임이 있습니다.
따라서 우리는 항상 다음과 같은 질문들을 고민해야 합니다:
- 팀의 목표는 무엇인가요?
- 그 목표를 위해 투자한 리소스는 무엇이며, 투자를 결정한 근거는 무엇인가요?
- 그 투자로 무엇을 얻었으며, 사용자 문제 해결에 어떤 영향을 미쳤나요?
- 그 성과가 회사 비즈니스에 어떤 기여를 했나요?
이 네 가지 질문들로 기술적 성장뿐만 아니라 사용자의 경험을 개선 시키는 데에 많은 도움이 될 것입니다.
마무리
개발자의 역할은 단순한 기술자가 아니라, 시장에서 기술 서비스를 판매하는 판매자이자 기업에 고용되어 현실의 비즈니스 문제를 해결하는 해결사라고 지금껏 이야기했습니다.
한 가지 당부하고 싶은 것은, 개발자가 비즈니스에 집중해야 하는 이유가 “하드 스킬 외에도 중요한 것이 있다”는 뜻이지, 하드 스킬이 중요하지 않다는 건 아니라는 점입니다.
끝으로 강조하고 싶은 말은 다음과 같습니다.
- 우리가 전문가로서 집중해야 할 것은 우리의 성장이나 기술적 욕구보다는 사용자라는 점
- 사용자의 현실 문제를 해결하면서 발생하는 이익이 바로 우리가 기업에 제공하는 기술 서비스의 본질적인 가치라는 점
개발자로서의 성장뿐 아니라 시장의 일원으로서, 그리고 제품을 만드는 메이커로서의 여러분의 사고를 확장하는 데 이 글이 작은 도움이 되면 좋겠습니다.
