팀이 바뀌고 2주 반이 지났다.

 

조직 개편이 있을것이라는 예고가 있었다.

 

내가 옮겨질 가능성도 있었지만, 크게 생각하지 않았다.

 

나를 비롯한 몇명이 팀 이동을 하였다. 공지를 통해 통보받았다. 월요일이 되자마자 아무런 설명 없이 팀이 옮겨진 이유를 물어보았다.

 

감정은 감정이고, 바로 이직하지 않을 것이라면 이 팀에 빨리 적응하고 여기서 성장해야 한다고 마음을 바로잡았다.

 

2주동안은 계속 노션읽고, 코드 보면서 이해안가는것 물어보는 날들의 반복이었다.

 

2주만에 첫 일감이 주어졌다.

 

구글스프레드 시트로 알림톡 발송기능을 만들어달라는 요청사항이었다.

 

운영상의 이슈로 NHN Cloud를 이용할 수 없는 상황에서 대체재로 찾은 API PLEX가 화면을 제공하지 않고 api만 제공하는 상황이었다.

 

요점은 구글스프레드시트를 화면으로 쓰고 발송 api를 만들어달라는 것

 

처음으로 백엔드가 하던 알림톡 업무를 내가 하게 되었다. apps script가 자바스크립트 기반이여서 크게 어려움은 없었다.

 

다만 접수 응답과 발송 응답이 나뉘어 있는 시스템이 생소하여 이틀간 '성공 응답인데 왜 카톡은 안올까?' 라며 고민하다가 Data팀 동료분의 도움을 받아 해결할 수 있었다. 고객사(우리 회사)의 웹훅을 API PLEX에 연결하여 발송 응답을 받아야 했던 것이다.

 

발송 응답에서 실패 이유를 알 수 있었고, 실패한 부분을 수정하여 기능을 완성할 수 있었다.

 

그리고 CTO님과 1:1을 어제 하였다.

 

내가 그동안 갖고 있던 궁금증에 대해 많이 여쭤보았다. 

 

대화의 초반부에 내가 했던 말은 '저는 개발자로서 실패를 아직 안해본 것 같아요' 였는데, 대화가 끝날무렵 '어쩌면 제가 실패를 해놓고 실패인줄도 몰랐을 수 도 있겠네요' 라고 말할 만큼 생각이 바뀌었다.

 

까먹을까봐 오자마자 대충 적어놓았는데

• 문제를 정하고 목표를 정해야함
  • 목표를 정하지 않으면 실패하고도 실패한 줄 모름
  • 목표를 정하려면 문제를 인식해야함
  • 문제를 인식하기 전에는 행동하지 말 것
  • 문제를 인식하지 못하면 속력은 높을 지 언정 잘못된 방향으로 갈 수 있음.
  • 속력과 방향을 생각할 것
• 개인의 실패와 성공보다는 조직의 실패와 성공이 중요하다.
• 쿠팡이 여러 제품으로 쪼개져있다면 미친 유저 경험이다. 쿠팡은 쿠팡안에서 모든것을 해결하지 않는가.
  • 말로는 다들 고객중심사고를 해야한다고 하지만, 실제로는 다들 유지보수를 편하게 하기 위해 관리자중심사고를 하고 있음.
• PO의 역할은 문제를 찾아내는 것
• Q : 제품이 망하는 것은 개발자의 실패가 아니라 기획자의 실패 아닌가요?
  • 피드백들을 밟고 작은 발전을 이루어가는 과정속에 PO,PD,SE의 전문성이 모두 필요하기 때문에 개발자는 수동적인 존재가 아니라 주도적으로 제품을 개발하는 것임 (많은 대화의 요약)