sungyup's.

becoming_a_better_programmer / 부록: 국내 개발자 8인의 이야기 / 2.2 훌륭한 프로그래머이자 팀플레이어 되는 법

2.2훌륭한 프로그래머이자 팀플레이어 되는 법

토스 진유림님의 이야기

코딩 말고도 개발 업무가 있다

1인분 코딩을 해내기에도 급급하던 사회 초년생을 지나 연차가 올라갈수록, 코딩 자체보다 코딩 외 개발 업무 비율이 커진다.

팀플레이어다운 행동 모으기

진유림님은 코딩만 하는 것 다음의 단계로 나아가기 위해, 주위를 둘러봤을 때 존경 받는 사람들이 뭐가 다른지 사례들을 모았다. 그렇게 모은 사례들을 3가지 주제들로 묶을 수 있었다.

근본 문제를 알아낸다.

사례 1. 문제에 나의 전문성 더하기

앱의 신분증 인증에서 유저들이 많이 나갔다. 팀원은 [다음에 입력하기] 버튼을 추가하자고 했는데, 처음엔 프론트엔드 공수가 많이 들지 않으니 그렇게 하려고 했다.

하지만 1차원적인 생각이었다. 근본 문제를 먼저 파악하고 전문성을 더하면 새로운 방향이 나올 수 있다. 예를 들어 이 경우엔, 앱 인증서 활용 동의를 사전에 받으면 아예 신분증 추가 인증 과정 자체를 없앨 수 있다.

개발자가 기획안보다 창의적으로 풀 수 있는 문제들이 있다. 업무 요청이 왔을 때 우리는 맥락을 먼저 파악하고, 본질을 꿰뚫고, 전문성을 더해 해결책을 보강해야 한다. 코딩이 전부가 아니고 이 작업이 업무의 일부다.

사례 2. 문제에 팀의 맥락 모으기

버그가 발생했을 때, 해당 버그만 개인적으로 고치는 것은 1차원적 검토다.

팀이 함께 테스트를 못했다거나 하는 복합적인 원인을 탐구할 수 있는 기회로, 팀적으로 어떻게 절차를 고칠지 논의해볼 수 있다.

의존 관계를 알아낸다.

사례 3. 일정의 의존 관계를 드러낸다.

외부사 API 완료 일정이 늦어진다면, 우리 일정도 그대로 미뤄야할까?

일정 지연이 유발하는 문제를 충분히 고민해야 한다. 보고를 듣는 사람은 '일정을 맞추려면 어떻게 해야하는지'를 궁금해한다. 스펙을 낮추더라도 해당 날짜까지 되는 안과 함께 고려해볼 수 있다.

사례 4. 기능의 의존 관계를 파악한다.

디자이너에게 시안을 받았는데 공수가 많이 들것 같으면, 열정적인 개발자는 어떻게든 개발하려고 한다. 이는 사실 수동적인 검토를 거쳤기 때문이다.

보다 적극적으로 검토한다면 일부를 간소화해 개발 공수를 줄였을때 이득 등을 비교하고 디자이너와 얘기해볼 수 있다.

한 번에 여러 기능을 개발해야 한다면 각 기능의 의존 관계를 파악하고 끊어서 배포하는 것이 좋다.

말하지 않은 것을 알아낸다.

사례 5. 동료의 욕구 파악하기

동료에게 단순히 요즘 잘 지내냐고 물어보기보단,

  1. 최근에 해 본 노력
  2. 못 하고 있어 아쉬운 것
  3. 내 업무를 느리게 만드는 것 을 동료가 말할 수 있도록 얘기해본다. 조직적인 문제라면 협력해서 고칠 수 있다.

사례 6. 팀장의 욕구 파악하기

팀장은 물론 "요즘 팀에 우선순위 공유가 안되는 것 같은데, 이를 해결하기 위해 제가 뭘 하면 될까요?"라는 질문을 좋아할 수 있다. 하지만 팀장 입장에선 답하기 쉽지 않다.

위의 질문 대신, "요즘 일할 때 우선순위 공유가 잘 안된다고 느껴져요. 팀장님은 어떠신가요?"라고 물어보면 팀장은 상황을 좀 더 쉽게 떠올리고 자신의 고민과 시도를 알려줄 수 있다.

맺음말

진유림님은 마지막으로 한 달간, 동료의 멋진 행동을 3개 모아보는 것을 제안한다. 관찰하고 적어서 객관화한다면 큰 의미가 있을 것이라며.