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

2023 3월 세미나

"개발자 원칙"의 저자 이동욱, 박미정, 박성철 님을 직접 모시고 개발자의 생존과 성장 원칙에 관해 깊이 있는 이야기를 나눕니다.

세미나 링크

여기 담긴 건, 제 생각

---

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

연사님 : 인프랩 CTO 이동욱님

일정을 잘 지키는 개발자.

일정과 퀄리티는 트레이드 오프가 있다. 프로그래머에게 요구되는 것은 100점이 아닌
80~90점짜리 프로그램을 기한 내에 완성하는 일이다.
일정을 잘 지키는 개발자들은 공통적으로
선택의 기로에서 원칙에 따라 빠르게 결정하고 중요한 것만 고민하더라

결국 좋은 원칙을 가지고 있어야 빠르면서도 90점짜리 프로그램을 만들 수 있을 것이다. 평소에도 고민하는 습관과 직접 만들어보며 테스트해보는 습관이 있어야만, 좋은 원칙을 세울 수 있을 것이라 생각한다.
책을 많이 읽고 찾아보는 것은 좋으나, 정작 내가 문제 해결 방법을 선택할 때 책의 내용을 적용할 수 없다면 무의미하더라.
컴포트 존을 벗어나서 다양한 코드를 짜보는 것이 재밌을 듯 하다.

제어할 수 없는 속성에 의존하지 말라.

주민번호를 PK로 쓰다가 주민번호 수집을 불가하도록 법률이 바뀐 뒤 시스템 변경이 필요해진 예.
외부에서 전달 받은 값은 절대 주요키로 선택하지 않는다.

변화에 쉽게 흔들리는 소프트웨어를 만들지 말자.

그 밖에 제어할 수 없는 것들

• 외부 라이브러리 (테스트 프레임워크)
• 외부 서비스 등
• UI / UX
• Data

제어할 수 있는 것들

• 비즈니스 로직

테스트 시 모킹이 필요한 함수와 필요 없는 함수를 분리하는 것을 구체적 예로 보여주심.

제어 가능한 (순수한) 코드를 최대한 늘려나가며,
반대로 제어가 어려운 코드를 격리할 영역에 몰아 넣어 제어할 수 없는 코드가 전염되지 않게 하자.

매우 공감한다.
작년에 외부 서비스 API를 프록시하듯이 쓰는 기능과 API를 만들었었다.
최근에 외부 서비스가 버전 업을 하면서 개발 당시와 사용법이 변경되면서 수정사항이 전염되어 자사 서비스 API까지도 변경이 필요한 일을 겪었다. (심지어 내가 작업했었다 흑..)
최대한 추상화를 잘 하고 구체적인 부분은 따로 뺐어야 했는데, 코드만 분리되어 있지 결국 변경으로 인한 문제가 전염이 된 케이스라고 생각한다. 베스트는 외부 서비스 API를 호출하는 모듈만 변경하여도 모든 기능이 정상적으로 동작하는 것이었다. 이번에 리펙토링하며 제대로 만들어보자는 욕심이 든다.

제어할 수 없는 팀원

리더로서 팀을 꾸리는데 있어 하시는 생각.

제어할 수 없는 것

• 우리 회사의 매출
• 우리 회사의 투자
• 높은 개발자 연봉
• 스타트업 전체의 권고사직

제어할 수 있는 것

• 좋은 시니어 개발자의 채용 사내 강연 -> 노하우를 흡수하자
  정기적인 외부 시니어 강연으로 먼저 필요한 강연을 제시하는 팀원들.
  
• 잦은 피드백을 줄 수 있는 환경
  정적 분석, 테스트 코드, Lint, 코드 포맷팅 (소나큐브)
  
• 팀원의 성장 환경
  할 수 있는 것에만 집중, 긍정적으로 상황 해석하기.
  

퇴사자가 Big Tech로 이직하고 팀 분위기가 싱숭 생숭한 분위기에서 CTO님께서 하신 말씀.

이렇게 큰 회사에서도 우리 회사 개발자를 뽑는 것을 보면 우리가 하고 있는 방법이 틀리지 않았다.
다만 우리 회사의 프로덕이 아직 트래픽이 낮은 것 뿐이지, 
개발 문화나 프로세스가 틀린 것이 아니니 앞으로 개발자로서 성장에 대해선 의심하지 않아도 될 것 같다. 
다만 앞으로 어떻게 회사가 5배 10배씩 성장하는 것을 경험할 수 있을지만 고민하자. 

-> 안 좋은 것에서도 좋은 것 찾아내기 습관.

좋은 개발자를 뽑기란 참으로 어렵다. 입사 이후 CTO님을 모신 것 외엔 신규 채용이 전혀 없었다. (힘들다!) 채용은 내가 제어할 수 없는 일이다. 마찬가지로 팀원 및 인력은 내가 제어할 수 없다.
하지만 중요하고 내가 잘할 수 있으며 내가 좋아하는 업무들을 우선순위 별로 나열하고, 하나하나 효율적으로 잘 처리해나가는 것은 내가 제어할 수 있다.
할 수 있는 것에만 집중하는 것은 개인적으로 나에게 아직 부족한 역량이다.
평소에 제어할 수 없는 것으로 인해 스트레스를 받는 일이 잦다.
내가 제어할 수 있는지, 없는지를 먼저 판단을 하고
제어할 수 없는 일이라면 생각을 말고 잘 정리하는 것이 좋은 사고흐름으로 보인다.

우리 회사 CTO님께서 평소 해주시는 말씀이나 태도와 이동욱 CTO님의 말씀이 매우 일치하는 면이 있어 '좋은, 잘하시는 분들께선 다들 비슷한 태도를 가지는구나'라 생각했다.

• 항상 감사하자.

마무리

제어할 수 없는 것에 거리두기 
제어할 수 있는 것에 집중하기

---

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

연사님 : 무신사 리드 개발자 박미정님

실패의 정의

• 뜻한 대로 되지 아니하거나 그르침
• ex. 미라클 모닝, 개발 일정을 못 지킴!
• ex2. 열심히 했지만 결과가 목표에 미치지 못한 상태.

미정님의 실패 경험

실패의 원인과 그로 인한 문제들.

'개발자'로서 실패

• 버그 있는 코드 배포 -> 이용 시 문제 발생
• 운영 DB 테이블 삭제 -> 복구하였지만 손실된 데이터
• 코드 배포 후, 성능 문제 발생 -> 서버 다운으로 서비스 중단
• 기시감이 드는 코드 작성 -> 성장하지 않는 것 같은 자괴감

운영 DB 삭제 빼고는 나도 모두 경험해본 이슈다. 😂

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

• 기술에만 집중하는 태도 -> 서비스를 떠나가는 사용자
• 개발 문화만 너무 소중한 태도 -> 개발팀만 신나고 후퇴하는 서비스

'관리자'로서 나의 실패

• 팀의 역량을 파악하기 전 일을 계획함 -> 프로젝트 중단
• 개발팀 과잉보호 -> 소통과 신뢰가 어려운 개발팀
• 팀원을 이해하기 전, 판단 -> 어려운 리더가 됨

매니저는 정말 어렵겠다고 생각한다.

실패, 그 후

실패 후 개선한 것들. 그리고 성장한 결과들

• 버그 있는 코드 배포 -> 코드 리뷰 절차 강화
• 운영 DB 테이블 삭제 -> 인프라 보안 강화
• 성능 문제 -> 성능 테스트 절차 강화
• 기시감 드는 코드 -> 코드를 다시 작성하는 태도

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

• 팀의 역량 파악 전 일을 계획함 -> 일과 사람을 냉정하게 바라보고 실현 가능성 판단 (어렵다)
• 개발팀 과잉보호 -> 주도적으로 일을 찾는 팀
• 팀원을 이해하기 전, 판단 -> 의문이 아닌, 이해와 인정 먼저하기

성장의 씨앗이 된 실패 경험들을 말했지만, 회피를 했던 실패 경험들도 많았다.
실패를 대하는 방법을 루틴화해서 성장의 씨앗이 되도록 하자.

실패를 대하는 방법

1. 실패의 순간, 가라앉은 감정 충분히 느끼기
   • 회피하지 말고 감정을 알아채자.
2. 그 감정에서 빠져나오기
   • 필요 이상으로 감정에 매몰되어 있음을 인지하기
   • 빠져나오기 위한 나만의 루틴 만들기
   • ex.
     - 문제의 원인을 고민
     • 같은 생각, 후회를 반복한다는 것을 인지
     • 다른 취미를 즐기며 감정 분리 의식
     • 감정에 매몰되지 않고 빠져나오기
3. 실패를 제대로 바라보기
   • 감정을 배제하고, 사실만 보고, 잘한 것 / 놓친 것 적어보기.

     감정을 배제하고 실패를 다시 바라보는 것은 참 어렵다.

4. 단 한 가지의 액션 아이템 선정하기
   • 실패를 반복하지 않기 위한 단 한 가지를 실행하며 회복하기

지난 날을 돌아보니, 큰 실패 경험을 겪고 그 감정의 여파로 인해 비교적 작은 실패들은 회고하지 않았던 것 같다. 대부분 2번에서 그치고, 3번 4번을 행하지 않은 케이스가 많았던 것 같다.

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

선정 기준 : 전파 속도가 빠르고, 실패 반복 가능성이 낮은 것.
ex. 버그 있는 코드 배포 -> 코드 리뷰 절차 강화 VS 테스트 코드 작성 문화
( 이미 코드 리뷰 문화가 있었어서 전자 선택)

임팩트 있는 단 한가지만 정하는 것 -> 루틴이 너무 무겁지 않아야 회피하지 않는다.
관리자가 팀/팀원의 실패를 대할 때에도 같은 프로세스를 거칠 수 있도록 함.
다만 루틴을 실행할 수 있도록 돕는 역할에 집중하기.

그래서 하고 싶은 말은..

1. 실패는 당연하다.
   • TDD
   • Agile
2. 누구나 실패하고 누구나 힘들어한다.
   • 실패하지 않은 사람은 도전하지 않거나 늘 회피하는 사람
   • 실패 앞에서는 누구나 가라앉는 감정에 빠진다
   • 그 상태를 받아들이는 것이 중요해요
3. 스스로 심리적 안전감을 만들어주자.
   • 자신에게 실패해도 괜찮다고 당연하다고 해주세요
   • 모든 실패는 나름의 의미가 있지만 모두 극복할 필요는 없어요
   • 나만의 실패를 대하는 루틴을 꼭 만들자

이전에 재밌게 읽었던 토스에서의 시간을 돌아보며 글이 떠올랐다.
조직 내 위계를 없애기 위해 '내가 싼 똥 자랑 대회'를 열었었는데, 개발자의 실패 경험을 가볍게 공유하며 심리적 안전감을 만들어주기에 좋은 문화가 아닌가 생각한다.

마무리

오늘 실패하신 분들의 내일의 성장을 축하합니다

마음이 따뜻해지는 강연이었습니다. 센세 😹
어서 사내 회고 문화를 도입해보고 싶다.

---

<덕업일치를 넘어서>에서 하고 싶었던 이야기

연사님 : 컬리 테크리더 박성철님

소개

1982년, 중학교 2학년때부터 개발에 빠지셔서 현재까지 프로그래밍을 통해 세상과 소통하는 사람.
개발자 히포크라테스 선서를 소개..

책을 기획한 의도

시작이 된 책들

• Programmers at Work - 전설적인 프로그래머들이 어떻게 일하는지 인터뷰한 책
• 영혼을 잃지 않는 디자이너 되기 -

두 책을 담은 책을 써보고 싶었다.

책에서 말하려던 것

1. 전문가로서의 프로그래머
   개발자의 도구는 기술 혁신 (골드 러시)에 의해 계속 발전(리셋)한다.
   골드 러시 이후의 소프트웨어 개발은 보다 체계적, 낮은 위험성, 자본 집약적인 개발 관행을 가진다. 골드 러시 이전의 개발 방식이 잘 통용되지 않는다.

   개발서적 Professional 소프트웨어 개발 핵심 요약 및 정리
   관련 내용은 여기 잘 정리되어 있다.

   전문가란?

         전문성 = 역량x동기x방향x협력
         역량 = 전문 역량 (컴퓨터 과학 + 소프트웨어 공학) + 일반 역량 (소통, 분석, 끈기, 자기관리, 집중)

   해커, 장인 정신 vs 전통 소프트웨어 공학 vs 협력 중심 개발 (팀 개발, 애자일)

   책 추천 -> 구글 엔지니어는 이렇게 일한다

   알파고를 시작으로 시장에 떠오른 ML과 최근 ChatGPT의 부상으로 떠오르는 LLM이 골드 러시가 아닐까 생각한다. 기술 혁신의 주기가 줄어들면서 어떤 개발자로 살아야할지 고민해볼만한 좋은 주제였다고 생각한다.

2. 나를 잃어버리지 않는 삶

   개발을 통한 자기 수양
   생즉고 : 삶은 고난의 연속
   자기동기관리
   자신을 잃어버리는 경우 : 너무 내 의식에만 빠지는 경우, 세상에 너무 수동적으로 맞춰지는 경우

강연을 들으면서 연사분께서 당연히 INTP일 것이라 생각했는데 맞춰서 재밌었다.

정말 말하고 싶었던 것

82년부터 변화, 발전한 컴퓨터 기술
점점 더 중요하고 쓸모 있어진다. -> 프로그래머도 더 중요해질 것이다.
우린 계속 변화하는 기술 위에 타있기 때문에, 계속 움직여야 한다.

마무리

아직 제가 선택한 길은 사람이 많이 다니는 길은 아닌 것 같아요.
어떤 길인지 선명하게 드러나지 않습니다. 
같이 걸어주시고, 이 길이 어떤 길이 될 지 같이 기대하면서 각자 의지를 가지고 걸어갔으면 좋겠습니다.

40년 전, 당장 10년 전의 개발자를 생각해보며, 향 후 10년 뒤 40년 뒤의 개발자란 직업에 대해서도 고민을 해보아야 할 필요성을 느낀 강연이었다. 재밌는 주제였습니다 ㅎㅅㅎ

---

Q&A

성철님, 동욱님, 미정님 순

테크 리더의 중요한 역량

공감 능력, 성장성

위임 (과락), 호들갑 떨기 (높을 수록 좋은 점수)

소프트 스킬

리더, 매니저는 기본 지식도 요구되는 가운데, 일을 분배하고 평가할 줄도 알아야하니 참으로 어렵다고 생각한다. 관리자냐 전문 기술자냐도 고민해볼만한 주제인듯.
나는 솔직히 관리자로서는 역량이 아직 매우 낮다고 평가한다. (경험도 없다!)

호들갑 떨기는 팀원들 맨탈 케어에 좋은 자세라고 생각한다. 개발자들은 모두 애 같아서 엄숙하고 무서운 팀장님 보단 평소엔 가볍지만 일에 대해선 확실하게 해주시는 동네 친한 형같은 스타일이 나는 좋더라. 항상 자란다자란다 해줘야 한다. 나도 잘 못하지만

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

성장 과정 자체를 즐기기.

제가 틀렸네요 말하기 습관

내가 썼던 코드 다시 쓰기.

좋은 피드백 방법론

자신이 잘하는 일을 자신이 잘하는 방법으로 할 수 있도록 환경 조성.
안 맞는 것과 잘못을 구분해서 평가하고 맞는 쪽으로 유도하기. 미안한 일이 아니다.

빠르게 피드백해주기. 만 번 스윙 중 5천번째 스윙을 피드백하면 고치기 어렵다.
모든 회의를 녹음해서 사내 공유 + 피드백이 필요한 사람은 들으면서 자기 회고할 수 있다.

팀원마다 좋은 방법이 다르다. 팀원의 성향을 관찰해야한다. 누구는 직설적인 것에 상처 받고, 누구는 직설적이어야 잘 받아들인다.

동욱님은 항상 비유를 잘 드시는 것 같다. 해당 방법들은 자기 피드백에도 도움이 될 수 있을 것 같다.

계속 협업하고 싶은 개발자

이동욱님
집요함 -> 포기하지 않고, 근본 문제까지 찾아내서 팀 내 공유

팀원들에게 성장에 대한 니즈를 주는 방법

박성철님
일이 재밌어지고, 성취할 수 있는 경험을 주자.

실패로 인해 목표를 잃고 무기력함 극복 방법, 왜 과거보다 못할까 고민 해결

스트레스 관리. 자기 모니터링, 즐길 수 있는 스트레스까지만 받을 수 있도록 하자.
자신감을 가지기. 작은 성취를 반복하자 (ex. 이불 개기)

ToDo로 간단한 집안일들 하나씩 클리어하기.
나태해지지 않을 정도의 긴장감과 번아웃 사이를 잘 조절하자.

지금도 겪고 있다.
과거보다 현재 팀리더 성과가 덜 나오는 상황.
강연에서 말한 루틴 적용. 개인적으로 회고를 하는 법 -> 휴가를 다 모아서 푹 쉬기.

좋은, 나쁜 이직이란? 이직을 결정하는 타이밍

박미정님
현 회사에서 목표한 바를 이뤘고, 다음 목표를 실현하기 어렵다 판단이 들었을 때 -> 성장 니즈에 맞는 회사 찾기.
주니어 때 자신이 할 수 있던 것을 도전해보지 않고, 불만에 차서 한 이직은 추후 후회가 남음. (팀 문화에 피해를 줘서)

이동욱님
어떤 회사로 보단 어떤 상황일 때가 중요하다. 계속 다녀도 문제 없을 때, 컴포트존일 때 이직을 고민하자. 이직이 실패해도 그냥 지금 회사를 계속 다니면 된다.
현 회사의 안 좋은 상황때문에 이직을 급하게 결정하면, 객관적으로 좋은 회사를 판단하지 못하고 현 회사의 나쁜 점이 없는 회사만 찾기 때문에, 다른 안좋은 회사를 갈 확률이 높다.

박성철님
여기서 할 일은 다 끝났다라고 생각할 때 떠나면 후회가 없다.

공감이 많이 가는 말이다. 회사에 아쉬운 점도 있겠지만 정말 좋은 점도 많다. 아쉬울 것이 없을 때 떠날 준비를 하는 것이 좋아보인다.