[우아한테크 세미나] 테크 리더 3인이 말하는 개발자 원칙

운이 좋게도 오프라인 세미나에 당첨되어 내용을 정리해보았다.

인프런 이동욱 님

제어할 수 없는 것에 의존하지 않기

일정은 지키지만 버그가 많은 개발자 VS 일정은 못 지키지만 버그가 없는 개발자

정답을 내리진 못함.
그렇지만 프로덕트 엔지니어의 일은 고객이 원하는 기능을 고객이 원하는 시점에 전달하는 것
아무리 급해도 항상 80 ~90 점짜리 프로젝트를 일정 내 만드는게 좋다.

일정을 항상 잘 지키는 분들의 공통점

• 본인만의 기준과 원칙으로 빠르게 적용함.

제어할 수 없는 것에 의존하지 않는 법

주민등록번호는 유일할 것 같지만 사실 유니크하지 않다.
SQL 에서 값을 만드는 것 보다는 애플리케이션에서 값을 다루는게 좋다.
제어할 수 없는 것에 의존할 수록 변화에 쉽게 흔들린다.

예시로 LocalDateTime.now() 로 작성한 코드는 테스트하기가 힘들다.
시간을 제어할 수 없기 때문

• 해결 방법
  • 방법 1 ) Mocking
    • 하지만 문제가 있음
    • 날짜 라이브러리가 교체되는경우, 혹은 테스트 프레임워크가 교체되는경우, 모든 테스트코드를 고쳐야 함. (변화에 쉽게 흔들리는 코드)
  • 방법 2 ) 파라미터로 LocalDateTime 을 넘김. 넘어오지 않는 경우는 now 로 동작하도록
    • 제어할 수 있는 것

제어할 수 없는 것과 제어할 수 있는 것으로 나누자

제어할 수 없는 것 : 외부 서비스 API
제어할 수 있는 것 : 비즈니스 로직 (계산 등..)

전염되는 제어할 수 없는 코드
제어할 수 없는 코드가 들어가는 순간 함수를 하나의 기능만 하도록 리팩토링 했더라도 해당 코드를 사용하는 모든 코드는 제어하기 힘들어진다.
제어할 수 있는 코드를 따로 나누어서 사용하면 제어하기가 쉬워진다.
가능하다면 제어 가능한 코드를 최대한 늘리자.

제어할 수 없는 팀원

어떻게 하면 좋은 개발자를 팀으로 데려올 것인가?

• 제어할 수 없는 것
  • 우리 회사의 매출
  • 우리 회사의 투자
  • 높은 개발자 연봉
  • 스타트업 시니어 권고사직
• 제어할 수 있는 것
  • 팀원의 성장 환경
    • 좋은 개발자를 모셔오는 건 못하더라도, 그분들에게 부탁을 해서 사내 강연을 부탁하여 좋은 시니어들의 노하우를 흡수하자.
    • 정기적인 외부 시니어 강연
    • 잦은 피드백을 줄 수 있는 환경을 만들자
      • 누군가 리뷰를 안해주더라도 알아서 코드를 검사해줌 (정적 분석 툴 사용 - ex) 소나큐브)

할 수 있는 것에만 집중을하고 긍정적으로 상황을 해석하는 것이 유일한 방법

[다른 팀은 조금만 걸어가면 경기를 치를 수 있는데, 
우리 팀은 경기장에 가기까지만 150km 를 걸어야하는 상황]

"장소를 옮겨 가면서 홈경기를 치르면 `원정경기에 강해질 것`이다.
다른 곳에서 시합할 때의 산만함이 혼란스러움에 익숙할 테니까."
-88연승의 비밀 중

항상 좋은 환경에만 있을 수 없다.
내가 할 수 있는 건, 안 좋은 환경에서도 좋은 점을 찾는 것이다.

무신사 박미정 님

실패를 축하합니다. 실패가 내 성장의 동력이 되려면

실패가 뭘까?

실패의 정의 : 일을 잘못하여 뜻한 대로 되지 아니하거나 그르침

• 새벽 5시에 일어나서 미라클 모닝 하려고 했는데 눈뜨니 아침 9시
• 내일까지 개발 완료라고 말했는데 버그가 발생해서 불가능을 인지한 경우

나 이런 실패들을 해봤지

결과 자체는 큰 문제가 없지만 내 의도와는 달리 언짢은 상태
한다고 했는데 목표에는 도달하지 못한 경우
성장하고 싶었는데 마음과는 다르게 멈춰있는 경우
개인 혹은 팀이 목표를 달성하지 못한 경우

개발자로서의 나의 실패

• 버그있는 코드 배포
  • 사용자가 서비스 이용 시 문제 발생
• 운영 DB 테이블 삭제
  • 데이터 복구 밤샘 작업에도 불구하고 손실된 데이터
• 코드 배포 후, 성능 문제 발생
  • 트래픽이 몰려 서비스 중단
• 언제나 발전이 없는 것 같은 코드 작성
  • 동료의 코드에 비해 한없이 초라해보이는 나의 코드

제품 만드는 사람으로서 나의 실패

• 나는 개발자니까 기술에만 집중하는 태도
  • 기술은 좋지만 서비스 이용자는 줄어듬
• 개발 문화만 너무 소중한 태도
  • 개발팀만 신남. 하지만 후퇴하는 제품

관리자로서 나의 실패

• 팀의 역량을 파악하기 전 일을 계획함
  • 프로젝트 중단
• 개발팀 과잉보호
  • 소통과 신뢰가 어려운 개발팀
• 팀원을 섣불리 이해하는 판단 (왜 그렇게했어?)
  • 말을 꺼내기 어려운 리더

---

개발자로서 나의 실패, 그 후

• 버그있는 코드 배포
  • 코드 리뷰 절차 강화
• 코드 배포 후, 성능 문제 발생
  • 성능 테스트 절차 강화

제품 만드는 사람으로서 나의 실패, 그 후

• 나는 개발자니까 기술에만 집중하는 태도
  • 최종 사용자 관점에서 고민하는 태도
• 개발 문화만 너무 소중한 태도
  • 동일한 목표로 바라보는 원팀으로의 협업

관리자로서 나의 실패, 그 후

• 팀의 역량을 파악하기 전 일을 계획함
  • 일과 사람을 냉정하게 바라보고 실현 가능성 판단
• 개발팀 과잉보호
  • 주도적으로 일을 찾는 팀
• 팀원을 섣불리 이해하는 판단 (왜 그렇게했어?)
  • 의문이 아니라 인정을 먼저

결과를 보고나니

• 배움이 아닌 회피를 택한 경우가 많았다.
• 하지만 그런 경험이 쌓이다보니 실패를 대하는 방법이 생겼다.

실패를 대하는 방법

• 1) 실패의 순간, 가라앉은 감정 충분히 느끼기
  • 회피하지 않고, 이 경험 안에서 느끼고 있는 감정을 알아채기
• 2) 그 감정에서 빠져나오기
  • 필요 이상의 감정에 매몰되어 있음을 인지하기
  • 빠져나오기
    • 문제가 뭐였을까?
    • 계속 같은 후회를 반복하고 있네? (인지)
    • 활자를 읽자 (의식)
      • 전자책 등등 뭐가됐든 또는 혼코노 가기
    • 더이상 감정에 매몰되지 않고 빠져나옴
• 3) 실패를 제대로 기록하기
  • 감정을 빼고 사실만 보고, 잘한 것 / 놓친 것을 적어보기
• 4) 단 한 가지의 실패만 선정하기
  • 이 실패를 반복하지 않기 위한 단 한 가지를 실행하기 (= 회복)
  • 안그래도 힘든데 모든 실패를 다 실행하기에는 벅차다. 자그마한 성공을 맛보면서 회복하라.

실패를 반복하지 않기 위한 단 한 가지

• 버그있는 코드 배포
  • 코드 리뷰 절차 강화 > 테스트 코드 작성 문화
• 코드 배포 후, 성능 문제 발생
  • 성능 테스트 절차 강화 > 고급 API 로직 분석

실패를 가만히 들여다보면 여러가지 액션 아이템이 떠오르죠.
하지만 `가장 임팩트 있는 단 한 가지`를 택해요.
실패를 대하는 `루틴이 너무 무겁지 않았으면` 해서요.
루틴이 무거워지는 순간 회피하게 될 것 같더라고요.

그래서 하고싶은 말은

실패는 당연하다는 걸 우리는 모두 알고있어요.

• TDD 사이클
  • 실패하는 테스트를 작성한다 (RED)
  • 테스트를 성공시킨다 (GREEN)
  • 리팩토링 (REFACTOR)

누구나 실패하고 누구나 힘들어해요

• 실패하지 않았다는 말은 시도하지 않았다는 말이죠.
• 실패한 적이 없는 사람은 늘 회피하는 사람일 거에요.
• 그리고 그 실패앞에서는 누구나 가라앉은 감정에 빠집니다.
• 그 상태를 느끼는게 중요해요.

굴속에서 빠졌을 때 잠시 우울해해도 괜찮습니다.
- 오프라 원프리 하버드 졸업연설에서

스스로 심리적 안정감을 만들어주세요

• 삶에서 너무나 당연한 실패인데 스스로에게는 참 인색하죠.
• 나 자신에게 실패해도 괜찮다고 당연하다고 해주세요.

컬리 박성철 님

소프트웨어로 사람들에게 도움이 되자

• 구글 엔지니어는 이렇게 일한다 책은 꼭 읽어보기

삶의 신조

• 생즉고 : 삶은 고난의 연속이라는 불교 용어
• 삶은 문제 투성이고 부조리하므로 삶에 기대하지 말고 순간순간을 진흙탕에서 배움
• 실패하기를 두려워하지 마라. 받아들이고 거기서부터 출발하라.

너를 잊지마

‘센과 치히로의 행방 불명’ 에서..

-‘여기서 일할래요.’ 하면서 자기 자신을 잃어버림

잊는 이유는?

• 세상과 단절했을 때
• 세상이 너무 매워서 더 수동적으로 일함.

평생 직장 따윈 없다 (입사할 때 퇴사를 생각)

최고가 되어 떠나라!

Q & A

테크 리더의 가장 중요한 역량 하나만 꼽으라면?

• 성철님 : 상황에 따라서 성장하는 사람
• 동욱님 : 위임과 호들갑떨기 (세상에 이런걸 했다고? 너 정말 최고야!)
• 미정님 : 실제로 많은 리더분들을 만나면 소프트 스킬을 잘 생각을 안하신다 (팀원을 관리하고 이해하고 그에 맞는 리더십을 보여줘야한다)

유연성 있게 성장할 수 있는 개발 방법 및 습관

• 성철님 : 과정을 즐기는 것 (실패하더라도 몰랐던 것을 알게되었구나 하고 긍정적으로 생각하며 과정을 즐기라)
• 동욱님 : 제가 틀렸네요. 라고 말하는 것. (주니어 때부터 습관을 들이지 않으면 시니어가 될수록 더 힘들다.)
• 미정님 : 내가 작성했던 코드를 다시 작성해봄 (확장성 등을 고려하면서..)

피드백을 주는 방법

• 성철님 : 사람들의 특징을 수용하고 그 사람이 잘못된 것이라 생각하지 않도록 피드백 함. 사람을 바꾸려고 하지 않는다.
• 동욱님 : 피드백을 빠르게 준다. 배트를 10000번 휘두룰 때, 10000번 다 채우고 피드백을 주는 것 보다. 5000번 휘두룰 시점에 주는게 피드백을 잘 기억할 수 있다.
• 미정님 : 따로 방법이 있는 것 같지는 않다. 팀원 한명한명이 어떤 사람인지 계속 관찰을 하고 그 사람에 맞는 피드백을 줘라.

같이 일해봤는데 다음에도 같이 일하고 싶은 개발자 유형은?

• 동욱님 : 엄청 집요한 사람. 중간에 포기하지 않고 어떻게든 일을 끝내서 결과물을 가져오는 개발자.

팀원분들이 성장에 대한 니즈가 없을 때, 니즈를 불어넣는 방법

• 성철님 : 일이 재밌으면 성장은 따라온다. 일이 재밌고 성취할 수 있는 경험이 생기면 자연스럽게 성장하고 싶을 것이다.

실패를 극복한 경험 (왜 현재의 내가 과거의 나보다 못할까?)

• 성철님 : 내가 자신감이 넘치면 번아웃을 줄일 수 있다. 작은 성취를 하면서 자존감을 올리자. (이불을 정돈하는 것에서부터 출발. 이불을 잘 갰구나! 뿌듯)
• 동욱님 : 성철님과 비슷. 추가로 나태해지지 않을 정도의 긴장감은 항상 가지고 있자.
• 미정님 : 저도 현재 겪고 있는 상황이에요. 하지만 환경은 제어할 수 없는 영역이다. 팀과 조직을 위해 뭘 했었어야 했지? 하면서 위에서 얘기했던 것을 행동함. 그래도 안된다면 휴가를 다 끌어모아서 일을 놓으면서 회복한다.

이직을 어떤 순간에 했을 때 성공적이었고, 후회스러웠는지?

• 성철님 : 목표를 미리 정하고 달성하면 떠난다는 마인드. 목표가 있다면 일을 하면서 어려운 상황이 있더라도 버틸 수 있게 된다.
• 동욱님 : 여기 절때 못다녀라고 생각되었을 때 오히려 안떠난다. 약간 만족하는 상황이라면 다른 회사를 골랐다. 이런식으로 하니 이직을 잘 했다라고 생각했다.
• 미정님 : 저는 이직을 많이 함. 내가 여기서 더이상 성장할 수 없을 것 같을 때 이직을 했었다. (단, 사전에 조직에게 이런 변화를 해보자하고 노력을 하자. 이걸 안했다면 성장이 아니라 회피다.) 성장을 할 수 있는 회사를 골라서 위주로 선택. 후회스러운 경험은 나 개발 잘하는데 왜 일안시켜줘? 라고 생각했을 때다. 나의 행동이 회사의 메커니즘을 이해하지 못한 상태로 탓만하고 회피만하다가 이직했기 때문에.

회고

좋은 말씀을 많이 해주셔서 너무 좋았다.
요즘 회사에서 일하면서 실패의 연속을 겪다보니 많이 힘들었는데
박미정님이 실패는 당연한거라고 나 자신에게는 실패해도 괜찮다고 말해달라고 하셨을 때, 되게 위안받는 느낌이 들었고 용기가 났다.
마음속에 새겨두면서 오늘도 열심히 살자!

실패하지 않는 사람은 늘 회피하는 사람이다.
오늘의 실패를 내일의 원동력으로