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

1. 이동욱

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

• 프로그래머에게 요구되는 것은 100점이 아닌 80~90점 짜리 프로그램을 기한 내에 완성하는 것

• 프로덕트 엔지니어의 role (연구원이 아니다!)

  • 고객이 원하는 기능을 고객이 원하는 시점에 전달하는 것

• 가장 좋은 코드를 선택하는 방법은?

  	A 코드 VS B 코드
  	그 때 그 때마다 (클린코드 vs 오브젝트) 다르다.
  	그럼 코드를 잘 빠르게(80~90점) 짜는 사람들의 공통점은?

  • 본인만의 기준과 원칙으로 빠르게 결정
  • 정말 설계가 필요하지 않다? => 일단 빠르게 작성
    • 해왔던 경험과 원칙으로 빠르게 결정
  • 중요한 결정만 시간을 쓴다.
    • 선택의 순간마다 고민하는 사람 X

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

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

ex) SI 시절 전화번호/주민등록번호 등 현실세계 유니크한 key값이 있는데, 주민번호를 DB Key값으로 많이 사용했다. (주민번호가 생성되는 원칙/규칙 변하지 않을 것이라 생각하고 사용, 유니크하니까)

• 즉 외부에서 전달 받은 값은 절대 주요키로 선택하지 않는다.

  • SQL에서보다는 애플리케이션에서 값을 다룬다.
    ex) password(), encrypt()
    암호화 구간 선택:
    DB SQL 프로시저 vs 애플리케이션 코드
    => 어플리케이션 코드
    why? DB에서 성능 튜닝이 어렵기 때문
    이게 분산환경이 되던, DB Migration을 하던 영향을 덜 받음

• 제어할 수 없는 것에 의존할 수록 변화에 쉽게 흔들리는 소프트웨어

• 제어할 수 없는 코드

  • ex)일요일이면 할인

    const now = LocalDateTime.now();
    if (now.dayOfWeek() === DayOfWeek.SUNDAY){
    this._amount = this._amount * 0.9;
    }

    그렇다면 테스트 코드는 일요일에만 성공하는 테스트가 만들어진다.
    그러면 모킹(모듈 모킹, TS에서 가능, LocalDate를 모킹)
    그리고 나서는 문제가 없을까?

    날짜 라이브러리(js-joda)가 교체 된다면?
    테스트 프레임워크 (jest)가 교체된다면?
    => 변화에 쉽게 흔들리는 소프트웨어

• 모든 테스트 코드를 고치는 상황에 직면

• 쓰고 있는 라이브러리를 바꾸는데 모든 테스트코드를 바꾼다?
  즉, 제어할 수 없는 것에 의존하여 생긴 문제.

• (해결) Default Parameter discount 함수 호출 시, 인자가 없다면 현재 시간으로, 있다면 그 값으로 호출됨.

  discount(now = LocalDateTime.now())
  # Testcode
  
  it('일요일에는 주문 금액 10% 할인', () => {
    discount(LocalDateTime.of(2023,3,26));
  
    expect ...
  }

• 여러 강의들 중 결제 금액 결과가 100원이 넘는 건들만 PG결제

• 리팩토링 ( 함수 분리 ) 했더니 모든 함수에 모킹이 필요...?

나는 클린코드 원칙에 따라서 했는데 이게 왜 이러지 ...?

• 제어할 수 없는 함수. 즉 async/await 이 걸려있는 requestPg에 전염당함

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

• 즉 내가 만들지 않아 모킹할 수 밖에 없는 친구들을 제어할 수 없음

• UI, Data(DB, ORM, axios...)는 제어하기 어려움

• Business Logic(우리가 만드는)는 제어하기 쉬움!!

• 즉 가능하다면 제어가능한 코드로 최대한 늘려가야 할 영역이고, 제어가 어려운 코드를 밀어 넣어서 격리할 영역

• 제어할 수 없는 팀원

  회사 매출/투자
  높은 개발자 연봉
  스타트업 개발자 퇴직
  => 점점 스타트업 개발자 채용이 어려워진다
  그런데 이것들은 내가 제어할 수 있는 것이 아니다.

• 좋은 시니어 개발자 채용은 불가능. => 사내 강연

• => 좋은 시니어들의 노하우를 흡수

• 정기적인 외부 시니어 강연 -> 필요한 노하우를 먼저 제시하는 팀원들
  잦은 피드백을 줄 수 있는 환경

1. 정적 분석 (PR시 SonarCube 등)
2. 테스트 코드 (실패시 배포 실패)
3. Lint, 코드 포맷팅 (JS, TS 환경)

즉. 제어할 수 있는 것은 팀원의 성장 환경이다.

할 수 있는 것에만 집중하고, 긍정적으로 상황 해석하기.
내가 할 수 있는 유일한 일이다.

Q. 수년간 160km 떨어진 다른 학교에서 연습 경기를 해야 하는 팀의 감독이라면?
A. 장소를 옮겨 가면서 홈경기를 치르면 원정경기에 강해질 것이다. 다른 곳에서 시합할 때의 산만함과 혼란스러움에 익숙할 테니까.

배민으로 이직하신 인프랩 팀원

어? 뭐야 배민/네카라 갈 수 있네? 싱숭생숭!

아. 그럴수도 있겠구나. 큰 회사도 우리 회사 개발자 뽑는 것을 보니, 우리가 하고 있는 개발 문화/ 프로세스가 틀리지 않다. 프로세스를 의심하지 말자. 어떻게 해야 5배 10배 더 커질 수 있을 까 고민해보자.

항상 좋은 환경에서 있을 순 없다.
안좋은 환경에서 안좋은 일이 벌어지면, 이번 사건에서 나는 운을 축적했구나. 생각하자.

항상 감사하기.

제어할 수 없는 것에 거리두기

제어할 수 있는 것에 집중하기.

무신사 박미정

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

배민 베트남 현지에서 일했다.

1. 프롤로그
   개발자 원칙 이직 이야기

실패가 뭘까요?

• 일을 잘못하여 뜻한 대로 되지 아니하거나 그르침.
• 미라클모닝 대차게 실패
• PM한테 내일까지 가능! 했는데 오늘 밤 불가능을 인지한 나

2. 나, 이런 실패들을 해봤지 😀
   개발자로서 나의 실패

• 버그있는 코드 배포
• 운영 DB 테이블 삭제
• 코드 배포 후, 성능 문제 발생
• 언제나 기시감이 드는 코드 작성

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

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

관리자로서 나의 실패

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

3. 실패, 그 후 😎
   개발자로서 실패, 그 후

• 코드 리뷰 절차 강화
• 인프라 보안 강화
• 성능 테스트 절차 강화
• 코드 다시작성해보는 습관

제품 만드는 사람 실패, 그 후

• 최종 사용자 관점에서 고민하는 태도
• 동일한 목표를 바라모는 원팀으로의 협업

관리자로서 나의 실패

• 일과 사람을 냉정하게 바라보고 실현 가능성 판단
• 주도적으로 일을 찾는 팀
• 의문이 아닌, 이해와 인정 먼저

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

실패를 대하는 방법
1. 실패의 순간, 가라앉은 감정 충분히 느끼기
- 회피하지 않고 이 경험 안에서 느끼고 있는 감정을 알아채기 (회피하지 않기)
2. 그 감정에서 빠져나오기
- 필요 이상으로 감정에 매몰되어 있음을 인지하기
- 빠져나오기 위한 나만의 의식 만들기
- 아 똑같은 생각 계속 하고 있네? (인지) -> 활자를 읽자 (책, 스마트폰 등)
3. 실패를 제대로 바라보기.
- 감정을 배제하고 사실 만 보고, 잘한 것 / 놓친 것을 적어보기
4. 단 한가지의 액션 아이템 선정하기
- 이 실패를 반복하지 않기 위한 단 한가지를 실행하기 ( = 회복 )

내가 이 실패를 반복하지 않기 위해서 이걸 했다 !

실패를 반복하지 않기 위한 단 한가지
개발자로 나의 실패 그 후

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

-> 전파 속도 UP + 실패 반복 가능성 DOWN

실패를 가만히 들여다 보면 여러가지 액션 아이템(하고 싶은 일)이 떠오른다.
하지만 가장 임팩트 있는 단 한가지만 택하자
루틴 자체가 무겁지 않아야 한다
루틴이 무겁다면, 순간 회피하게 된다.

아침마다 1시간 씩 기록한다고 하신다.

4. 그래서 하고싶은 말은
   실패는 당연하다는 것을 모두 알고 있다.
   TDD의 사이클

• RED (실패하는 테스트 작성)
• GREEN (테스트 통과)
• Refactor

Agile하게? == Fail Fast

누구나 실패하고, 누구나 힘들어 한다.

• 실패하지 않았다 == 시도하지 않았다.
• 실패한 적 없는 사람은 늘 회피하는 사람이다.
• 실패 앞에서는 누구나 가라앉고, 그 상태를 받아들이는 것이 중요하다.

굴 속에 빠졌을 땐, 잠시 우울해해도 괜찮습니다.
- 오프라

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

• 조직에게 요구한다. (의견 낼 수 있도록)
• 삶에서 너무나 당연한 실패이니, 나에게도 스스로 실패가 괜찮다는 인식을 만들어주자
• 모든 실패는 나름의 의미가 있지만 모두 극복할 필요는 없다.
• 나만의 실패를 대하는 루틴도 꼭 만들자.

임포스터라는 책이 좋다 ! (가면증후근을 예방하기 위한 메타인지 학습법)

컬리 박성철

"덕업일치를 넘어서"에서 하고 싶었떤 이야기

삶은 고해다.
우리가 어려운 세상을 어떻게 살 것인가? (제어할 수 있는 것)에 대하여 고민해보자.

실제 세상과 맞물리는 것을 좋아한다.
기술자 히포크라테스 선서 (프로덕트 디자이너)