비즈니스적 마인드를 가진 개발자가 되는 방법

내용

• 문동욱 토스.
• 블로그
  • evan-moon.github.io
• 나의 비즈니스
  • 나의 기술 서비스를 판매하는 판매자.
• 회사의 비즈니스
  • 현실의 비즈니스 문제를 해결.
• 우리는 고객이 기업이다.
  • 우리(개발자)와 고객의 관계가 어떤가? 생각해야한다.
  • 고객(기업)의 마음을 이해해야합니다.
• 기업이란 ? 돈을 벌기위해 이것저것 하는 모임 기업.
• 기술적인 전문성을 발휘해서 돈을 벌어다 줄것을 기대.
• 내가 제공하는 기술 서비스는 얼마짜리일까?
  • 내가 파는 물건의 가격이 얼마일까?
  • 기업이 우리를 주문
    • 상품소개서(이력서), 영원사원과 대화(인터뷰), 리뷰(레퍼체크)
    • 3개월 지나면 환불도 안된다.
    • 해고도 마음대로 못함.
• 가격이 비싸보이면 보수적 관점으로 접근할 것이다.
• 최대의 이익을 얻기위해서 머리쓰는 게임.
• 최소한의 비용으로 최대의 이익.
  • 항상 머릿속에 담아두는 사람과 그렇지 않는 사람은 차이가 난다.
• 우리를 평가하기? 애매하다.
  • 추상레벨을 갖춘 좋은 설계
  • 프로그래밍 으로 제품을 생산.
  • 장애를 해소하기위한 조치를 한다.
  • 채용 인사 평가 보상과 같은 조직관리를 한다.’
  • 우리가 제공하는 기술 서비스
• 노동시간대비 물건의 생산량을 보면 된다.
• 측정하기 어렵지만, 측정하는 게 불가능하진 않음. 그런데 우리는 무엇을 보여줘야할까?
  • 기술 서비스 제공 -> 사용자의 문제해결 -> 매출발생 ->인적자원 추가 투자 -> 기술 서비스 제공.
• 우리는 현실의 비즈니스 문제를 해결하는 해결사이다.
• 방망이 깎던 노인.
  • 전통적인 장인 정신에 대한 존중이 필요하다.
  • 그러나 개발자인 우리는 사용자에게 초점이 맞춰져 있어야한다.
• 사용자들의 문제
  • 빨래질할 방망이가 필요해요.
    • 이것에 대한 대안은 아래가 될 수 있다.
    • 각목
    • 세탁기
    • 옷.
• 빨래질할 방망이가 필요해요.
  • 우리가 배민을 시킬때 배민의 아키택처를 생각하지 안흔다.
  • 방망이를 왜 깎았는지에 대해서 물어보게 된다.
• 채용 기준.
  • 어떻게 정해야할까?
  • 하드 스킬 : 높은 수준
  • 성과나 업적에 대한 행동근거가 명확한 분을 모시자.
    • 일상의 의사결정에 대한 기술적 근거가 중요하다.
    • 왜 중요한가?
    • TTFB를 10% 개선했어요
      • 그 작업은 왜하신거예요?
    • 굳이 왜 지금 그 작업을, 다른 작업은 안하시고, 왜 그걸!
      • 여기에 답을 “앱이 느려서요” 라고 했다면 공감이 잘 안됨.
    • 비즈니스랑 연결해서 설명하는 사람. 많지 않았다.
• 이 작업은 왜하기로 결정하신거에요?
  • 가독성 향상
  • 선언적 코드 작성
  • 응집도 높도 결합도 낮은
  • 장애 발생률
  • 성능 향상
  • 사용자가 이것을 원했었나요?
• 전직장에서 LCP를 개선한 분들이 많다.
  • 이걸 개선했다는 이력을 써주시는 분이 많다.
  • 결정하게 된 계기는 무엇인지?
  • 이건 너무 느리다고 판단해서 했다.
    • 비즈니스 근거가 빈약하다.
• 왜 그것이 가장 효율적인 방법이라고 판단했나요?
• 왜 우리가 그걸 해야하는데?
• 내가 했던 기술적인 의사결정들이 회사의 비즈니스와 사람의 의사결정의 근거가 되어야한다.
• 의사결정의 근거가 (사용자의 문제해결과 매출 발생)으로 이어졌을까요?
• 당신의 리소스를 왜 투자하셨나요. 우리가 무엇을 얻었나요?
• LCP개선이 사용자에게 어떤 도움이 되었는지?

토스의 LCP 개선 업무.

• LCP가 이렇게 해서 이렇게 매출에 대한 자료를 LCP를 개선하는 업무를 하고 있다.
• 토스 앱내에 운영 중인 서비스들의 페이지 개수 : 4,000개.
  • 단순 계산시 개선에 필요한 시간 자원의 비용 : 32000
  • 10000시간 * 개발자 3명
  • 시간 비용을 돈으로 환산하면 7억 4천.
  • 사무실 임대료, 인적 자원, 기타 등등.
  • 레슨런이 없는 것도 문제

결국 찾은것

• 개선대상이 되는 페이지를 구분하는 것

• 비즈니스 임팩트가 큰 순서대로 처리한다.

• 전체 트래픽 대비 몇%의 트래픽을 받고 있는가?
  • 50페이지 정도가 전체 트레픽의 80퍼센트를 받고 있음.
  • 50페이지만 수정하면 990만원이나 줄인다
• 왜 이걸 개선하고 있자.
• 비즈니스에 근거가 부족하다.
  • 데이터 조회 권한이 있는 것으로 비즈니스적 근거를 찾아본다.
  • 해당 서비스의 목표, 성과 지표의 상태가 어떠한가?
• OKR에 기여를 많이 하면서도 현재 개선은 없는 서비스를 찾아라.

핵심

• 전체 트래픽 대비 몇 %의 트래픽을 받고 있는가?
• 해당 서비스의 목표, 현재 성과 지표 상태가 어떠한가?
• 해당 페이지가 직접적으로 성과에 기여하는 페이지인가?

우리가 질문해보자.

• 팀의 목표는 무엇인가요?
• 개발 리소스를 그 작업에 투자하신 이유는 무엇인가요?
• 사용자 문제 해결에 어떤 도움을 준 것인가요?
• 그 사용자 지표 개선이 회사의 비즈니스에 어떤 영향을 주었나요?

질문

• 비즈니스적 임팩트를 확인할 수단이 없다면?
• 해당 페이지가 직접적으로 성과에 기여하는 페이지인가?
• 비즈니스적 임팩트가 낮은 업무를 받으면 어떻게 하나?
• 주도적으로 업무를 못정하면 어떻게 하나?

하고 싶은 이야기

• 하드스킬만 중요한것은 아니고, 소프트 스킬도 중요하다. 라는 점
• 제품을 만드는 메이커의 사고.

질문과 질문의 답. 또는 QNA 요약.

• 나의 질문 : 비즈니스적 마인드를 가졌을때 마주했던 어려움과 해결 경험.
  • 모든 사람을 다 설득하고 공감시킬수는 없다.
    • 결국 비즈니스 적 문제가 더 크다면 정면 돌파해야한다.
    • 아닌건 아니라고 말할 수 있어야한다.
• 비즈니스적 임팩트를 큰것부터 처리하는 것은 토스 내부에서 논의된 것인지.
  • NPS라는 지표 그런것도 있다.
• 기술부채가 사일로가 처리할 수 있는 이슈의 개수나 커밋의 개수로 파악할 수 있다.
• 리팩토링을 하는 이 행위가 생각하는 임팩트가 있을 것이다.
• 뭐가 이익을 지 잘 판단을 해야한다.
• 최대한 돈으로 환산하려는 노력을 해봐라.
• 의사결정만큼은 본인이하자.
  • 앱리뷰 별점 낮은 것부터 확인 하자.
  • NPS, 앱리뷰.
  • VOC 날것의 문제
• 지표 측정이 되도록 챌린지해야한다.
• 고액 연봉의 가치를 인정받는 개발자는
  • 비용은 7억 4천이 나오는데 왜 이만큼 받는 가? 라고 설득적으로 접근할 수도 있다.
• 토스 팀원들의 생산성을 높이기 위해 존재하는 팀.
• 괜찮은 회사를 가리는 방법
  • 요즘은 링크드인
    • 어떤 개발자들이 다니고 있는지 나온다.
    • 다 신입이야?
      • 이런 상황이 많지 않다고 생각할수도.
  • 더 VC
  • 혁신의 숲
  • 이 회사가 투자를 얼마나 받았는지.
  • 대표님과 커피쳇을 해봐라
    • 내가 이루고자 하는것과 성격 이 맞는지 , 스타트업일수록 이런 확인이 필요하다.

앞으로 Action Plan

• 아 내가 이런식으로 본인 PR을 잘 해두기.
  • 블로그 기록 정리, 링크드인 경험 공유.
• 비즈니스적 마인드 갖기.
  • 시키는 일도 비즈니스적으로 어떤 임팩트가 있을지 예측하기.(스스로 동기부여 효과, 다른 방향이 있으면 제안.)
  • 만약 제안할 수 있는 상황이 온다면 비즈니스적 영향도를 기록할 방법을 찾고 제안. 도입되었다면 영향도를 파악해서 주도적 업무 진행하기.
    • gpt가 말하는 비즈니스 임팩트를 파악하는 방법 : 수집할 KPI를 정의하고 대쉬보드 구축. https://chatgpt.com/share/66f7c348-6640-8011-b20f-992c991499ec