점핏x삼성강남: 협업 잘하는 개발자 되는 방법

소개

강사 소개

• 유용태(테오)
• 시니어 웹 프엔 개발자
• 창업 - 6년 서비스 운영 경험

강의 소개

• 개발자가 되기 보다는 problem solver가 되자.
• 팁보다는 마인드를 중점으로 강의

 

좋은 개발자란 무엇일까요?

성장하면서 알게 된 개발의 가치관의 변화

좋은 개발자가 되기 위해선 당연히 개발을 잘해야 한다?

• 이론보다는 실전
• 할 줄 아는 것과 해내는 것은 다른 능력

구현을 잘하는 게 아니라, 높은 품질의 코드를 만들어내는 것이 중요하다

• 높은 품질의 코드는 생산성과 유지측면에서 매우 중요하다
• 단순히 구현하는 것을 너머 잘 유지가 되려면, 결국엔 기초로 돌아감 (기초를 잘 다져야 함)

예측가능한 퍼포먼스를 내는 개발자가 개발을 잘하는 개발자임

하지만 실전에서는 개발을 잘하는 것만으로는 충분하지 않더라.

• 사업과 개발을 함께 하다보면 가치의 충돌이 발생함
• 코드의 품질을 유지하려다보면 유연하게 대처하기가 어려울 때가 많음
• 반대로 더 빨리 만들어내기 위해서는 코드 품질을 다소 희생해야 함

그럼에도 코드의 품질을 지키는 것이 중요하다고 생각했음

그러나, 코드의 품질을 고집하다보면 시간, 성능의 압박을 받게 됨.

코드의 품질을 포기하면 개발자로서 자괴감에 빠짐
= 그 결과, 야근과 번아웃.

코드의 품질 vs 좋은 제품 vs 개발시간의 딜레마!

시장은 내 생각보다는 고품질의 코드를 중요하게 생각하지 않는다.

• 고품질 코드의 새로운 기술은 눈에 잘 드러나지 않음
• 개발의 결과물들은 대부분 기획, 디자인, 유용함, 시장가치 등으로 평가 받음
• 어플리케이션이 선택받는 첫 번째 이유는 코드를 잘 만들어서가 아님!

결국, 코드보다 그 코드로 어떤 가치를 만들어내는가가 더 중요하다.

• 같은 기술에 같은 사람이 같은 시간을 들여 만들어도 무엇을 만드느냐에 따라 가치가 달라진다
• 내가 만들고자하는 것은 어떤 가치를 만들어 내는가?에 대해 생각을 하자

개발자의 평가는 결국 어떻게보다 무엇을 개발하느냐에 따라 정해지더라.

• 사실 어떻게가 정말 중요하지만, 그걸 증명하기가 대단히 어려움
• 그래서 결국 무엇을 만들었는지로 판가름 난다
• 유명한 개발자를 떠올려보면, 실력보다는 무엇을 만들었냐가 떠오를 것임
• 그 개발자 실력은 우리가 알 수는 없음

기왕이면 더 나은 가치를 만들어 내자!

• 같은 시간을 쓰더라도 더 나은 가치를 만들어내자
• 개발은 가치를 만들어내기 위한 도구에 지나지 않는다는 것
• 나는 코드를 만들지만, 코드가 만들어내는 가치를 만들고 있는 것
• 유명한 서비스들을 보면 좋은 서비스를 만든 기업들 뿐임

 

“개발의 가치는 기술이 아니라, 그 기술로 어떤 문제를 해결하는데 그 가치가 있다”

 

 

코드의 가치와 비즈니스

“그렇다면 좋은 코드는 왜 필요한가?”

비즈니스가 성공하여 규모가 커지면, 다시 코드의 품질이 중요해진다

• 코드 품질이 떨어지면 결국 비즈니스 가치를 하락시킴
• 코드의 품질은 비즈니스의 가치를 높이기보다는, 떨어뜨리지 않도록하는 방부제 역할
• 즉, 비지니스의 가치를 떨어뜨리지 않게 하기 위해서는 코드의 품질이 중요함

낙후된 코드의 품질은 개발의욕마저 떨어뜨린다.

• 낮은 코드의 품질 → 생산성 떨어짐 → 낙후된 개발환경 → 번아웃
• 결국 비즈니스의 지속가능한 가치를 떨어뜨리게 됨

개발자의 평가가 어떻게 보다 무엇을 개발하느냐에 따라 정해지는 이유

• 비즈니스가 성공해야만 비즈니스의 복잡도와 규모가 커지게 되고, 자연스럽게 기술적 챌린지가 높아짐!
• 그렇기에 성공한 거대규모의 비즈니스를 개발한다는 것은, 같은 기술을 사용하더라도 난이도가 다르기에 자연스레 개발자 대우가 높아짐

비즈니스의 가치가 기술적 챌린지를 만들고, 결국 개발의 가치를 더 높인다

• 성공 → 규모 커짐 → 서비스 복잡도 높아짐 → 기술적 챌린지를 만듦 → 극복하는 경험이 개발자에게 기술적 성장 경험하게 해줌
• 가치는 돌고 도는 것!

필요에 의해서 필요한 기술은 필요한 만큼만!

• 특정 기술에 집착하기보다는, 상황에 맞게 더 빠르고 더 쉽게 적합한 기술을 찾고자하는 시각을 가지자.

비즈니스와 코드의 품질간의 균형감각

• 이 둘은 상반된 것이 아닌, 서로를 필요로하는 동반자 관계
• 비즈니스의 가치는 개발의 가치를 높임, 개발의 가치는 비즈니스를 구현하고 그 가치를 떨어뜨리지 않도록 함
• 그래서 어느 하나의 가치에 매몰되면 다른 가치를 볼 수 없음
• 개발자의 역할은, 코드의 품질을 유지하면서도 비즈니스의 가치를 높이는 역할을 함. 그래서 어렵다!

“꼭 하나를 버릴 필요가 없음. 어떤 삼각형을 만드느냐?”

그래서 협업이 중요하다!

 

 

협업 잘하는 커뮤니케이션 TIP

협업의 가치와 문제해결사

개발자의 직무로만 비즈니스의 가치를 높이는건 쉽지 않다

• 시장은 고품질 코드를 원하진 않지만, 저품질 코드를 원하지도 않음
• 개발에게 기대하는 것은 구현과 안정성!
• 개발을 잘했다고해서 비즈니스 가치가 그만큼 더 높아지진 않음

개발자 직군의 직접적인 목표가 비즈니스 가치의 창출이 아니므로 대개 가치의 충돌이 생긴다

• 요구사항의 완성도와 개발시간, 코드의 품질을 타협해야하는 순간들을 자주 겪게 됨

내 성과가 아니라 우리의 성과이고 우리의 성과가 내 성과이다

• 하지만 성과는 보통 비즈니스의 성과르 평가되기 마련임
• 개발의 가치는 비즈니스의 가치로 인해 만들어진다는 사실을 기억하자!
• 그래서 나를 도와줄 사람들이 필요하고, 내가 그들을 도와 가치를 높이기 위해서는 협업을 잘해야 함
• 나만 잘한다고 내 가치가 높아지는 게 아니다..

나를 위해 협업하자! 내가 남을 돕는게 곧 나를 돕는 일이다

• 그렇다고 이게 기획과 사업에 관여하라는 의미는 아님
• 결국 우리 회사가 잘 되도록 하는 것 또한 개발자의 일이다는 말임

개발은 코드로만 하는게 아니다

• pm이 개발자보다 더 돈을 많이 버는가, 시니어만이 해야 하는가?
• 코드가 만들어내는 가치 모두가 개발이다! (디자이너와 협업, 등..)

프로그래머를 넘어서 문제 해결사가 되자!

• 개발자의 진짜 역할을 “문제해결”
• 코드를 통해 문제를 해결하는 사람이기 때문에, 팀원과의 의사소통, 사용자의 니즈파악, 협업, 일정, 마감, 가치, 기술교체, 기술부채 등이 중요함. 이 모든 것도 다 개발이다

“코드를 작성하지 않아도 다른 사람과 함께하는 모든 행위가 곧 개발이고 비즈니스다”

 

 

함께 문제를 해결하는 방법

문제 해결에 대한 이야기 - 공항의 불만처리

• 공항에 내려서 짐찾는데 30분 넘게 기다려야해서 민원이 항상 많음 → 15분까지 줄여봄. 그래도 민원이 줄지 않음. 기술적으로 대기시간을 줄일 수 없는데 어떻게 이 문제를 해결했을까?
• → 비행기에서부터 수화물 찾으러 가는 곳의 거리를 더 멀게해서 해결함. 찾는 시간은 대기라고 생각하지 않아서 민원 줄고 사람들이 만족함

따라서, 개발로만 모든 문제를 해결할 필요가 없다

• 대기시간을 줄인다는, 그 그대로 구현하려고만 하는게 최선이 아닐 때도 있다
• 다른 각도로 접근하면 문제를 해결할 수 있는 방안이 있음
• 따라서 특정 방법에만 매몰되지 말고, 다같이 고민해서 문제를 해결하자

실제 경험담 예시

• 특정 서버 API 호출 결과가 10초 넘어감. 서비스 로딩이 너무 길다!
• 서버가 해결해야 한다!, 인프라 확충 문제다, 근데 비용이 비싸다, 클라이언트에서 캐싱해라, 그건 보안정책상 안된다, …
• → 최선의 방법? 쟁점들을 각자의 입장이 아닌, ‘함께 해결해야 할 문제”로 보고 내 전문성을 바탕으로 다른 입장의 문제들을 바라보자! 서로 조금씩 양보하자
• 이에 의한 부수적인 성과가 있었음
• 만약 이때 각자의 방식으로 문제를 해결하려했다면? ⇒ ㅠㅠ

“문제는 내가 해결하는 게 아니라, 팀이 함께 해결해야하는 것이다”

 

문제해결을 잘하는 법

문제해결을 잘하는 법(1)

• 핵심이 되는 문제를 찾아야 함
• 요구사항이 아니라, 문제로 받아들이고, 어떻게 해결하지?로 접근하기

문제해결 잘하는 법(2)

• 대립이 되어 보이는 상황에서 문제해결의 실마리가 있다
• 문제를 따라가다보면 대립을 만나고, 모순된 순간을 만날 수 있는데,
• 이럴 때일 수록 둘 다 해결할 수 있는 방법이 ㅇ진짜 문제해결방법임

문제해결 잘하는 법(3)

• 나, 너의 문제가 아닌 우리의 문제다!
• 문제 해결방법은 최선의 방법 하나만 있는게 아니다.
• 함께 풀어갈 것

 

 

협업을 잘하는 개발자가 되는 몇 가지 커뮤니케이션 팁

같이 일하기 편한 사람이 되자!

“안된다”라고’만’ 말하지 않기

• 문제와 그에 대한 해결책과 일정을 한데 뭉뚱그려 전달받는 경우가 많은데,
• 그 중 잘못된 개발방법이나 일정을 들으면 보통 개발자는 ‘no’라 함
• 하지만 이는 모든 것에 대한 반대로 전달되어 대립으로 이어지는 경우가 생기게 됨
• 안된다는 것이 많아지면, 함께하는 동료가 자기검열을 하고 불편해한다!
• 그러면 결국 내가 만드는 코드의 비즈니스 가치 하락으로 이어짐
• 안되면 왜 안되는지 풀어서 말하는 사람이 되자

시키는 일이 아니라 함께 해결해야하는 문제다

• 시키는대로만 해야하는 과제가 아님. 곧이곧대로만 하지 말고,
• 어떻게 문제를 해결할지는 함께 고민하고 함께 풀어가야 함

맥락의 차이가 오해를 만든다

• 당연히 상대방이 알거라고 생각하지 마라!
• 사람마다 중요도, 급한지, 어려움을 느끼는 정도는 다름
• 내가 모르는 무언가가 있구나, 하고 물어보자. 화내지 말고…

설득이 아니라, 생각의 주파수를 맞추는 것

• 된다/안된다의 이분법적인 사고 버리자
• 한쪽의 생각을 관철하기 위해서 어느 한쪽을 설득해야만 이기는 게임이 아님
• → 큰 틀에서 맥락을 공유하고 이해하라
• → 주파수가 맞게되면 같은 곳을 바라보고 문제를 쉽게 풀 수 있음!
• 최대한 있는 그대로 생각을 그저 펼쳐두기만해도 됨

잘 들어주는 사람이 되어라 = 심리적 안정감!

• 심리적 안정감을 만드는게 중요함(이 사람은 내가 어떤 말을 하더라도 들어준다라는 마음!)
• 들어준다는 것과 시키는대로 하는 것은 다른 의미다
• → 그저 들어주는 것만으로도 맥락이 공유되고, 새로운 문제 해결의 방식을 찾을 수 있음

나부터 의도와 맥락을 언제나 분명히 하자!

• 의도와 맥락이 없는 채로 얘기를 하면 이야기가 산으로 감! (특히 문자나 텍스트로 이야기를 할 때..)
• 협업에서 커뮤니케이션을 잘하려면 의도와 맥락을 선명하게 해라
  1. 무슨 목적을 가지고 이야기하는지 - 의도
  2. 어떤 정보를 상대방이 모르기에 알려줘야 하는지 - 맥락
• 의도와 맥락이 불분명하다면, 더 길어지기 전에 짚어서 왜 이야기를 하고 싶은건지, 이야기를 이해하기위한 배경이 무엇인지 짚어야 함

말은 휘발되어 오해를 만든다. 꼭 글도 함께 써라!

• 회의록 남긴다던지, … 생각이 바뀐 내용을 꼭 적어서 확인해야 함
• 말은 휘발되고 왜곡되기 때문에 맥락의 차이를 만듦

예측 가능한 사람이 되자

• 예측하기 어려운 사람과 함께 일하기는 어려움..
• 언제나 미리 항상 공유하라. 맥락만 공유하고 있어도 예측 가능하고 대응할 수 있음!
• 가급적 같은 가치관과 생각을 지니도록 하기

폭탄은 가지고 있지 말고 얼른 넘겨주기

• 어려우면 공유해라~

능동적인 커뮤니케이션이 어렵다면 장치를 마련하자

• fix 시간을 잡기
• 무작정 커피 마시러 가기

“함께 문제를 바라보고 해결하기 위해 주파수를 맞추는 사람이 되자”

 

 

Recap

• 성장하다보면 가치관도 사고도 함께 성장한다
  • 비즈니스 가치가 제일 중요함. 그 가치를 만들려면 협업을 해야 함
• 코드를 작성하는 것만이 개발이 아님
  • 모든 과정이 다 개발이다 (이력서에는 코드가 아니라, 내가 뭘 만들었는지가 남는다)
• 협업 또한 배워야 하는 것
  • 주체적으로 일할 수 있게 됨 → 일이 즐거워짐!

 

 

QnA

스프린트. 테스크 예상 시간?

• bdd.
• 테스크를 명확하게 하기
  • 행동 → 데이터 → 화면 을 1cycle로
• 해보지 않은 예측안되는 테스크는?
  • 일주일동안 할게 (x) → 일주일동안 해볼게(o)
• 내가 아는 것들은 나만의 알 수 있는 단위가 있어야 함
• 예측안되는건 ‘해볼게’하고 팀원에게 공유를 해라

주파수 맞추는 방법?

• 수렴하는 회의인지, 발산하는 회의인지 명확히 하기
• 발산하는 회의라면 건들지 않기. 다 들어주기. 수렴하지 않도록 하기(결정하지 않도록)
• 수렴한다면 결정할 수 있도록 하기. 근데 합의가 아님. 결정권자가 있다고 생각하고 하기

3년차 개발자가 주도권을 가질 수 있는가?

• 잘 들어주는 개발자가 되고 있다면, 사회적 자본을 쌓고 있다는 것
• 열심히 성실하게 주어진 일을 하는 개발자가 되어 있어야 함. 장기적으로. 주위 사람을 내 편으로 만들기.
• 그러다보면 어느새 내가 주도권을 가지고 있게 될 것. 이후로 하면 된다.
• 사회적 자본이 쌓여있지 않은 상태에서 주도권 휘두르면 나대는 사람이 될 뿐임
• ⇒ 실력 + 잘 듣는 사람 + 비개발자 시선에서 잘하는 사람

비즈니스 가치

• 왜 이 일을 해야하는가? 계속 생각하기 → 기획자, 팀장, 대표님에게 생각을 전달
• 개발의 결과물이 어떤 가치를 가지고 있는지까지 생각하면서 개발하기
• 이런 생각을 가지고 있으면, 이직의 기회가 있을 때 그런 시각을 가지고 있으면, 이직할 회사 중 어떤 회사가 괜찮은지 잘 판단할 수 있게 됨
• 좋은 기회가 왔을 때 잘 선택할 수 있게 된다 (영화배우가 좋은 대본을 골라야하듯이)

하던거 다 때려고치면 안됨

• 일부 기능부터는 새로운 기술을 쓰겠다 → o
• 허락받지말고, 사이드플젝처럼 해놓고 보여줘라

어떻게 설득해야하냐? → 내가 하던것도 하고 추가로 하면 된다

• 내가 주도권가지고 내가 만들어서 도입하면 됨