⚠️ 10월 10일(화) 에도 동일한 강연이 있습니다.
⚠️ 10월 10일 참석자분들에게는 스포가 될 수 있습니다.

점핏 x 삼성 강남에서 좋은 자리를 마련해주셔서 테오님의 좋은 이야기 듣고 왔습니다.
테오님의 발표 내용과 저의 생각들을 중간중간 섞었습니다.

준비시간

삼성 강남 3층으로 가니 아늑한 강연장이 준비되어 있더군요. 조금 기다리니까 연예인(테오님) 등장. 시작시간까지 시간이 남아서 테오 스프린트를 모방한 스프린트를 했던 사람임을 밝히면서 악수도 했습니다. (TMI 실물이 훨씬 더 잘생기셨음)

시작 전까지 테오님이 참석자들에게 어떤 내용을 예상하는지 참석자들의 연차를 묻는 정도로 분위기를 예열해주셨습니다.

강의시작

테오님이 처음부터 협업 잘하는 개발자가 되는 노하우가 아닌 마인드나 지침에 관한 이야기임을 말해주셨습니다.

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

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

구현을 잘 하는 게 아니라 높은 품질의 코드를 만들어내고 코드의 품질을 지키는 것이라고 생각했었다. 하지만 시장은 고품질의 코드를 중요하게 생각하지 않는다. 결과물은 주로 기획, 디자인, 유용함, 시장가치 등으로 평가를 받는다. 그러므로 개발의 가치는 기술이 아니라 그 기술을 어떤 문제를 해결하는데에 있다.

매우 공감했다. 사용자는 기능만 사용하면 된다. 굳이 구현방법, 구현기술을 알 필요도 없고 알려고 하지 않는다. 그러므로, 코드보다 그 코드로 어떤 가치를 만들어 내는가가 중요하다는 이야기이다.

코드의 가치와 비즈니스

코드의 품질은 방부제와도 같아서 규모가 커지면 다시 코드의 품질이 중요해진다. 낙후된 코드(오래된 코드나 많이 사용하지 않는 라이브러리)로 만들어진 서비스는 개발자의 의욕마저 떨어뜨린다. 하지만 새로운 비즈니스로 인해 코드의 품질만 챙길 수 없는 때가 온다. 그래서 우리는 Speed, Cost, Quality 중에 하나를 포기하는 것이 아닌 적절한 위치를 찾아야 한다.

개발자의 직무로만 비즈니스의 가치를 높이는건 쉽지 않다. 개발자에게 코드의 품질, 안정성이 제일 중요한 목표이다. 개발자의 목표가 비즈니스 가치의 창출이 아니다보니 다른 직군과의 가치 충돌이 생긴다. 이 때 우리의 성과가 내 성과라는 자세로 임하는 것이 중요하다. 나를 위해 협업하자! 내가 남을 돕는게 곧 나를 돕는 일이다.

다른 직군과 충돌하는 이유를 알게 되었다. 서로 추가하는 가치와 목표가 다름으로써 충돌이 생기는 거 였다.

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

협업의 가치와 문제해결사

프로그래머를 넘어서 문제 해결사가 되자. 코드는 문제를 해결하는 도구일 뿐, 그 문제를 어떻게 해결하고 어떤 가치를 창출할 것인지를 결정하는 우리의 마음가짐과 태도이다. 그래서 개발로만 모든 문제를 해결할 필요는 없다.

공항 수하물 대기 시간이 너무 긴 민원을 시스템적으로 풀 수 없어서 물리적인 방법으로 푼 예시를 들어주셨다. 비슷한 내용으로 엘리베이터를 기다리는 시간이 지루하다는 것을 대기시간이 줄어든 엘리베이터를 개발하는 것이 아닌 문을 거울로 변경해서 대기시간을 지루하지 않게 하는 이야기도 있다. 문제를 기술, 개발로만 해결하려고 하지 말라는 이야기다. 출처 : 배달의민족 CEO에게 뽑고 싶은 개발자를 물어보았다

함께 문제를 해결하는 방법

1. 핵심이 되는 문제를 찾아야 한다.
2. 대립되어 보이는 상황에서 문제해결의 실마리가 있다.
3. 문제를 해결하는 방법은 최선의 방법 하나만 있는게 아니다. "우리의 상황, 우리의 문제" 라는 것을 인식해야 한다.

서비스의 로딩시간을 줄였던 실제 경험담을 이야기해주셨다. 서버에서 해결해야 하는 문제가 아닌 각 영역에서 조금씩 대안을 내서 문제를 해결하는 과정을 이야기해주셨다. 최선의 방법이 아닌 우리의 상황에 맞는 우리의 문제 해결 방법을 강조하셨다.

협업을 잘하는 개발자가 되자.

✅ 같이 일하기 편한 사람이 되자.

• 심리적 안정감을 주는 잘 들어주는 사람이 되어라. 다른 사람을 설득하려고 하지말고 생각의 주파수를 맞추려고 하자.

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

• 우리는 상대방은 내가 알고 있는 것을 당연히 알거라는 생각으로 말을 한다.
• 나부터 의도와 맥락을 언제나 분명히 하자.
• 말은 휘발되어 오해를 만드므로 꼭! 글을 함께 써라

많은 내용을 알려주셨지만 같은 맥락으로 추려보았다. 이 내용은 개발자뿐만 아니라 직장인이라면 가져야하는 이야기라고 생각한다.

마무리

절대적인 것은 없고 상대적이며 상황에 맞는 가치의 균형감각이 중요하다. 코드를 작성하는 것만이 개발이 아닌 다른 사람과 함께하는 모든 행위가 곧 개발이고 비즈니스이다.

마지막으로 지금까지의 내용을 정리해주셨다. 비즈니스의 한 영역에 '개발'을 담당하는 것이고 우리의 목표는 이 비즈니스를 성공시키는 것이다 라는 생각을 가지게 되었다.

Q&A

실제로 질문한 내용을 추려보았습니다. 제가 한 질문도 있지만 다른 분들의 질문에서 너무 좋은 이야기들이 나와서 추가합니다.

질문1) 실무에서 저연차 개발자가 강연의 내용처럼 회의의 주도권을 가질 수 있는가?

답변1) 저연차일 때는 주도권을 가지려고 하면 소위 나대는 사람이 될 수 있다. 그러므로 주도권이 아닌 잘 들어주는 개발자가 되려고 노력해라. 그러면 문제가 생기거나 대화를 할 때 너를 찾게 될 것이다. 이것이 사회적 자본이 되고 자본이 쌓이면 주도권을 가질 수 있다. 그리고 맥락과 의도를 먼저 말해주는 사람이 되려고 노력해라.

질문2) 비즈니스 가치가 높은 회사에서 일을 해야하는가? 상대적으로 낮은 가치에서 일을 하고 있다면 어떻게 해야하는가?

답변2) 현재의 회사가 낮은 가치라고 생각한다면 회사의 비즈니스의 이유와 가치를 찾아가는 과정을 연습하는 것도 중요하다. 회사의 비즈니스를 내가 선택해서 이직하는 것도 좋은 방법이다.

질문3) 레거시, 유지보수가 힘든 코드는 어떻게 하면 좋을까?

답변3) 현재 진행하는 프로젝트를 멈추고 바꾼다고 하면 좋아할 사람은 없다. 사이드 프로젝트처럼 야금야금 변경하여 짜잔하고 보여주는 것도 좋은 방법이다.

나의 이야기

이번 강연으로 많은 것을 깨달았다.

첫번째로 '개발자'에 대한 생각이 프로그래밍 언어로 무언가를 만드는 사람이 아닌 프로그래밍 언어로 문제를 해결하는 사람으로 바뀌었다. 마치 RPG게임에서 탱커, 딜러, 힐러처럼 역할군인거다.

두번째로, 막연했던 '개발을 잘하고 싶다'라는 목표가 구체화되었다. 로직과 아키텍처를 잘 짜는 것뿐만 아니라, 상대방의 요구를 잘 듣고 설명해주는 개발자가 되고 싶어졌다. (물론 둘 다 중요하지만...)