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

제어할 수 없는 것에 의존하지 않기 / 인프랩 이동욱 CTO

 

"일정은 지키지만 버그가 많은 것 vs 일정은 못 지키지만 버그가 없는 것"

 

프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을 기한 내에 완성하는 일이다.
- 나카지마 사토시

 

"프로덕트 엔지니어의 일은 고객이 원하는 기능을 고객이 원하는 시점에 전달하는 것"이 프로덕트 엔지니어로써의 해야할 일이다.

 

퀄리티 보다 일정이 중요한가? 아무리 급해도 항상 80~90점짜리 소프트웨어를 일정 내 개발하는 방법이 중요하다.

 

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

• 가장 좋은 코드를 선택하는 방법은? "본인만의 기준과 원칙으로 빠르게 결정"

 

"선택의 순간마다 고민 하는 사람"보다는 "원칙에 따라 빠르게 결정하고 중요한 것만 고민하는 사람"이 좋은 개발자이다.

 

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

"현실 세계의 변화와 세계 사이의 결합도를 줄여야 한다. 전화번호를 식별자로 사용하는가? 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라"
- 실용주의 프로그래머 중

 

절대 변하지 않을 것이라 믿고 의존했던 속성이었지만, 변경이 발생하여 대부분의 시스템의 주요키 변경이 발생.
=> 외부에서 전달 받은 값은 절대 주요키로 선택하지 않는다.

 

// SQL보다는 애플리케이션에서 값을 다룬다. password(), encrypt(), .. 등등

 

제어할 수 없는 것에 의존할수록 변화에 쉽게 흔들리는 소프트웨어가 만들어진다.

제어할 수 없는 코드

• 현재 시간(now())은 제어할 수 없는 것. => 모킹으로 테스트 통과

모킹을 해보니 테스트코드를 바꿔야 하거나 라이브러리를 바꾸어야 할 때, 의존도가 높아서 바꾸기 힘든 문제가 발생한다.

제어할 수 있는 코드

Default Parameter로 제어할 수 없는 값을 주입 받는다.
제어할 수 있는 상황 성공하는 테스트.

전염되는 제어할 수 없는 코드

• 여러 강의들 중 결제 금액 계산 결과가 100원이 넘는 건들만 골라서 PG 결제
• 함수를 리팩토링 했지만 모든 함수에 모킹이 필요함
• 제어할 수 없는 함수에 의존하는 모든 코드가 제어할 수 없는 코드가 됨.

제어할 수 없는 것 : 외부 서비스(Modal).
제어할 수 있는 것 : 결제 금액 계산 100원 이상 걸러내기.

 

"제어할 수 없는 코드란 순수하지 않은 함수 혹은 객체"

• 제어 가능한 코드로 최대한 늘려나가야할 영역
• 제어가 어려운 코드를 밀어넣어서 격리할 영역

제어할 수 없는 팀원

• 좋은 시니어 개발자 사내 강연
• 좋은 시니어들의 노하우를 흡수

잦은 피드백을 줄 수 있는 환경

• 정적 분석
• 테스트 코드
• Lint, 코드 포맷팅

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

---

실패를 축하합니다. / 무신사 박미정

개발자 원칙 책에서 이직 이야기 하지 않으셨나요?

• 이직에 대해서는 책 내용 자체로 충분할 것 같아요
• 그보다, 이직이라는 수단을 사용하기까지 다양한 시도와 그 시도의 결과가 실패인 순간들이 떠오르더라고요
• 그래서 제 마음대로 오늘은 실패에 대한 이야기를 해볼게요

실패가 뭘까요?

• 일을 잘못하여 뜻한대로 되지 아니하거나 그르침
• 새벽 5시에 일어나서 미라클 모닝 하려고 했는데 눈뜨니 아침 9시
• PM한테 내일까지 기능 개발 완료라고 했는데 불가능을 인지한 오늘 밤의 나

그래서 오늘의 이야기는

• 저는 철학자도, 심리학자도 아니지만 실패를 말합니다.
• 대단한 사람의 이야기보다 때로는 가까운 사람의 이야기가 필요하기도 하니까요.
• 저는 개발자, 제품 만드는 사람 그리고 관리자에요
• 각 입장에서 저와 동료들의 경험이 오늘 이야기의 재료입니다.
• 개인의 실패에 초점이 맞추어져 있지만 모든 실패에 적용할 수 있지 않을까 조심스레 생각해요.

나 이런 실패들을 해봤지

실패가 뭔가요?
=> 뜻한대로 되지 아니한 것

"개발자"로서 나의 실패

• 버그있는 코드 배포
  => 사용자가 서비스 이용시 문제 발생
• 운영 DB 테이블 삭제
  => 데이터 복구 밤샘 작업에도 불구하고 손실된 데이터
• 코드 배포 후, 성능 문제 발생
  => 서버 다운으로 서비스 중단
• 언제나 기시감이 드는 코드 작성
  => 나만 성장하지 않는 것 같은 자괴감

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

• 나는 개발자니까 기술에만 집중하는 태도
  => 코드는 미미하게 견고해졌지만, 서비스를 떠나가는 사용자
• 개발 문화만 너무 소중한 태도
  => 개발팀만 신나고 후퇴하는 제품/서비스의 성정

"관리자"로서 나의 실패

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

실패, 그 후

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

• 버그있는 코드 배포
  => 코드 리뷰 절차 강화
• 운영 DB 테이블 삭제
  => 인프라 보안 강화
• 코드 배포 후, 성능 문제 발생
  => 성능 테스트 절차 강화
• 언제나 기시감이 드는 코드 작성
  => 코드를 다시 작성해보는 습관 획득

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

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

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

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

결과를 보고나니

• 모두 예측 가능한 성장 결과이죠?
• 저 역시, 배움이 아닌 회피를 택한 경우가 무수히 많았어요.
• 그런 경험이 쌓이다보니 실패를 대하는 방법이 생기더라고요.
• 대단하진 않지만 루틴이 생겼다는 사실이 도움이 됐어요.

실패를 대하는 방법

1. 실패의 순간, 가라앉은 감정 충분히 느끼기

• 회피하지 않고 이 경험 안에서 느끼고 있는 감정을 알아채기

2. 그 감정에서 빠져나오기

• 필요 이상으로 감정에 매몰되어 있음을 인지하기
• 빠져나오기 위한 나만의 의식 만들기

3. 실패를 제대로 바라보기

• 감정을 배제하고 사실만 보고, 잘한 것 / 놓친 것을 적어보기

4. 단 한 가지의 액션 아이템 선정하기

• 이 실패를 반복하지 않기 위한 단 한 가지를 실행하기(= 회복)

가라앉은 감정에서 빠져나오는 과정
문제가 뭐였을까? 생각 또 생각 -> 같은 생각 혹은 후회를 반복하고 있네?(인지) -> 활자를 읽자(의식) -> 더이상 가라앉은 감정에 매몰되지 않고 빠져나옴

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

• 버그있는 코드 배포
  => 코드 리뷰 절차 강화 > 테스트 코드 작성 문화
• 코드 배포 후, 성능 문제 발생
  => 성능 테스트 절차 강화 > 고급 API 로직 분석
• 실패를 가만히 들어다보면 여러가지 액션 아이템이 떠오르죠.
• 하지만 가장 임팩트 있는 단 한가지를 택해요.
• 실패를 대하는 루틴이 너무 무겁지 않았으면 해서요.
• 루틴이 무거워지는 순간 회피하게 될 것 같더라고요.

그래서 하고 싶은 말

• 테스트 주도 개발(TDD)에서 이야기하는 사이클
  • RED(실패하는 테스트 작성)
  • GREEN(테스트 통과)
  • REFACTOR
• Agile 하게? Fail Fast: 실패를 빠르게 겪자.
• 실패하지 않았다는 말은 시도하지 않았다는 말이죠.
• 실패한 적이 없는 사람은 늘 회피하는 사람일 거에요.
• 그리고 그 실패 앞에서는 누구나 가라앉은 감정에 빠집니다.
• 그 상대를 받아들이는게 중요해요

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

• 조직의 심리적 안전감 이야기 많이 하잖아요
• 삶에서 너무나 당연한 실패인데 스스로에게는 참 인색하죠
• 나 자신에게 실패해도 괜찮다고 당연하다고 해주세요
• 모든 실패는 나름의 의미가 있지만 모두 극복할 필요는 없어요
• 나만의 실패를 대하는 루틴도 꼭 만들어 주시고요
• mail: mjpark03@gmail.com
• blog: mjspring.medium.com

<덕업일치를 넘어서>에서 하고 싶었던 이야기 / 컬리 박성철

삶은 고해다.

기술자 히포크라테스 선서 - 마리사 데일

• 사람이 목표이고 사람이 존중되어야 한다.
• 내 지식을 다가올 세대와 기꺼이 공유
• 최종 사용자의 이익과 가치에 내 능력을 활용
• 결정의 결과에 대한 공감, 공예, 신중
• "모른다"고 말하는 것을 부끄러워하지 않을 것
• 나는 내가 만든 해결책의 대상자들과 직접 접속하도록 노력
• 윤리적 딜레마나 도덕적 무모함이 일어날 때, 동참하지 않겠다.
• 삶에 심각한 결과를 초래할 부정적인 영향력이 내 힘 안에 있다.
• 내 작업이 결국 인류에게 영향을 미친다.
• 사용자의 착취를 막겠다.
• 모든 내 동료 인간 모두에 특별한 의무가 있음을 기억할 것이다.
• 나는 내가 관문을 지키는 사람
• 내가 사는 동안 존중받고 그 후에는 기억될 것이다.

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

박성철님의 부분은 오히려 유튜브를 보는 것을 추천합니다!

[참고]
https://www.youtube.com/watch?v=DJCmvzhFVOI

 

---

 

# 후기 #

개인적으로 유튜브에 있는 내용을 정리한 것인데.. 읽을만한 내용인지는 잘 모르겠다!