우아한 테크 세미나

By Jimmyberg
senimar

우아한 테크 세미나

Agenda

1. 제어할 수 없는 것에 의존하지 않기 / 인프랩 이동욱
2. 실패를 축하합니다: 실패가 내 성장의 동력이 되려면 / 무신사 박미정
3. “덕업일치를 넘어서” 에서 하고 싶었던 이야기 / 컬리 박성철

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

일정은 지키지만 버그 많은 코드 vs 일정은 못지키지만 버그 없는 코드

  • 100점이 아닌 80~90점짜리이지만, 일정내 완료할 있는 수준의 코드
  • 코드를 개발할 때, 상황에 맞는 기준의 원칙에 따라 빠르게 결정!
  • 매순간마다의 선택을 고민하기보다는, 좀 더 빠르게 원칙에 맞는 선택을 하는 것을 추천!

제어할 수 없는 것 vs 제어할 수 있는 것

제어할 수 없는 것이란?

예시-1) 외부에서 전달받은 정보를 식별자로 사용하는 것
  • 전화번호를 식별자로 사용하는 경우
  • 주민등록번호를 식별자로 사용하는 경우
예시-2) DB, Third-Party 시스템의 식별자를 사용하는 것
  • 특정 DB 의 Object 를 사용 (Oracle’s Sequence, 또는 DBMS UUID 같은..)

제어할 수 있는 것이란?

  • 외부 시스템의 식별자 같은 정보보다는, 개발자가 제어하고 관리할 수 있는 애플리케이션 내 식별자를 최대한 사용하는 것
  • 라이브러리 의존성을 낮추기 위해 라이브러리 활용하는 함수를 최대한 분리하는 설계

제어할 수 없는 외부 라이브러리 의존성 분리

  • 이동욱님은 JS 언어 기준 LocalDateTime 을 구현해주는 라이브러리를 예시로 설명해주었다.
  • LocalDateTime 을 구현해주는 라이브러리는 다양하게 제공되는데, 라이브러리를 선택하는 과정에서 성능이 더 좋은 라이브러리 또는 특정 기능을 제공하는 라이브러리르 선택하여 불가피하게 프로젝트의 의존성이 변경될 때 많은 시행착오를 겪을 수 있다.
WebClient 라이브러리 의존성 분리
  • Spring F/W 진영에서 HTTP 통신을 RestTemplate 라이브러리를 많이 사용하지만, 해당 라이브러리가 Deprecated 되는 점을 감안하여 WebClient 라이브러리를 많이 사용하게 된다.
  • WebClient 라이브러리는 API 응답 결과를 Reactor 객체로 반환하기 때문에, Blocking I/O 기반의 프로젝트에서는 이를 구현하기 쉽지 않을 수 있다.
fun getUser(userId: Long): Mono<User> {
  return webClient
    .get()
    .uri("/user?id=$userId")
    .retrieve()
    .bodyToMono(User::class.java)
}

fun main() {
  val user = getUser(1)   // `user` 는 Mono 객체..
}

위와 같은 코드를 작성하면 getUser() 함수에서 받은 Mono<User> 때문에 다른 함수에서도 계속 Mono 객체를 사용할 수밖에 없다.

fun getUser(userId: Long): User {
  return webClient
    .get()
    .uri("/user?id=$userId")
    .retrieve()
    .bodyToMono(User::class.java)
    .block()
}

fun main() {
  val user = getUser(1)   // `user` 는 User 객체..
}

위 코드에서는 getUser() 함수에서 반환하기 전에 .block() 함수를 통해 User 객체를 바로 반환하였다.

이런 코드 설계를 하면 추후에 getUser() 함수를 WebClient 가 아닌 다른 라이브러리를 활용하더라도 그 함수를 호출하는 외부 함수 코드를 바꿀 필요가 없다.

제어할 수 없는 코드와 제어할 수 있는 코드를 분리하자!!

  • 전염되는 제어할 수 없는 코드? 리팩토링을 통해서 단일 기능 함수를 추출했는데, 호출 함수에 대해 의존성이 있기 때문에 제어할 수 없는 코드로 전염
  • 제어할 수 없는 코드와 제어할 수 있는 코드를 분리하는 것이 핵심
  • 제어할 수 없는 코드 = 순수 함수가 아닌 코드

테크 리더로서 제어할 수 없는 vs 제어할 수 있는 것의 차이

유능한 개발자 채용을 위해…
  • 제어할 수 없는 것 : 연봉, 복지, 비즈니스 모델 등..
  • 제어할 수 있는 것 : 개발 문화
    • 유일하게 제어할 수 있는 개발 문화 발전을 위해 사내 강연 진행하고, 주니어 개발자의 성장을 위해 피드백을 받을 수 있는 환경 구축
    • 코드 리뷰, 기술 스펙 고도화, 정적 분석, 테스트 코드, Lint, 코드 포맷팅 등

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

실패가 내 성장의 동력이 되려면

실패가 무엇일까?

  • 결과에 대한 문제점 발생
  • 결과 자체가 문제가 되지 않았지만, 목표치보다 못하는 경우
  • 개발자로서의 실패?
    • 코드에 대한 버그, 실수들..
    • 개발만 중요하다는 시각
    • 개발 문화만 소중하게 보는 시각
  • 관리자로서의 실패?
    • 현재 역량 기준이 아닌 예전 역량 기준의 설계
    • 이해보다 판단을 먼저한 경우

실패를 대하는 방법

1. 나만의 방식으로 실패를 회피하지 않고 대면하자!
2. 실패의 감정에서 빠져나오자!
  • 실패의 감정을 느끼는 시그널을 찾는다.
3. 실패를 다시 직면하자!
  • 실패에 대한 정확한 원인이나 사실을 적거나 정리한다.
4. 반복하지 않기 위한 행위 아이템을 찾자!
  • 코드 리뷰 강화, 성능 테스트 강화, 외부 고급 API 로직 분석 등
5. 실패 극복을 위한 루틴도 가볍게 하자!

팀의 실패도 동일하게 직면하고 극복하도록 함께 한다.

실패를 하더라도 괜찮아

  • TDD 처럼 실패를 먼저 확인하는 것 처럼 실패는 어쩌면 당연하다!
  • 굴속에 빠졌을 땐, 잠시 우울해도 괜찮다!
  • “실패해도 괜찮다” 라는 자신에게 심리적 안전감을 주고, 실패를 극복할 수 있는 강인함을 다지자!
  • 기록은 실패를 성공으로 바꾸는 힘을 가지자!
  • 오늘의 실패를 통해 얻는 내일의 성과와 성장에 대해 축하하자!

이직은 다양한 시도의 결과가 모두 실패였을 때 선택한 수단이었다.

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

  • “삶은 고해다” : 세상은 살기 너무 힘들다
    • 생활과 밀접한 일을 하는 이유 (배민과 컬리에서 일하는 이유)
  • 개발자 히포크라테스 선서
    • 사람 목표
    • 지식 공유
    • 사용자의 이익과 가치에 개발자 능력 사용
    • 결정의 결과에 대한 공감, 공예, 신중함 필요
    • 모르는 것에 대한 부끄러워 하지 않는다.
    • 내 창작물과 사용자들에 대한 접속을 노력
    • 비윤리적인 것에 동참하지 않는다.
    • … 등등 너무 많음
  • 직업으로서의 프로그래머 + 영혼을 잃지 않기
  • 왜 개발자는 다 애 같을까? or 왜 애처럼 취급 당할까?
    • 우리나라에 컴퓨터 세대는 다른 나라에 비해 없다.
    • 산업에 발전하면서 새로운 산업이 나올 때마다 개발자 세대 교체는 단절되었다.
      • 단절되다보니 자연스럽게 애가 되었고, 그런 인식이 굳혀져버렸다..?
  • 전문가가 될 필요성
    • 봄보다는 겨울을 이겨내기 위해서는 전문가가 되어야 한다.
  • 각자만의 전문성을 가진 개인이 모여 팀을 만들어 내는 애자일의 모습이 개발자로서 가야할 길이다.
  • 전문가 = (역량 + 동기 + 방향 + 협력)
  • 자신을 잊지 않고 자신을 위해서 일하자!
  • 컴퓨터는 점점 우리 생활 속에 들어와서 쓸모있어지고 있다. 개발자는 더 쓸모있는 직업이 된다!

Q&A

  • 테크 리더의 역량
    • 관리자가 아니라 리더라면, 공감 능력
    • 리더도 성장하는 것
    • 위임을 지키는 것
    • 호들갑 떨기
    • 사람에 대한 소프트 스킬
  • 유연성 있게 성장할 수 있는 방법
    • 시간흘러 내 코드를 다시 작성하는 것
    • 내가 틀렸다고 하는 것
    • 과정을 즐기는 것
  • 피드백을 주는 방식
    • 그 사람을 자주 관찰하고 사람에 대한 맞는 피드백을 주고자 노력한다.
    • 문제에 대한 피드백을 빠르게 바로 주려고 노력한다.
    • 사람에 대한 특징 수용하여 장점을 피드백하고, 그 사람의 잘못이라기 보단 다름을 인정한다.
  • 일해보고 싶은 유형의 개발자는?
    • 집요함이 있는 개발자
  • 팀원 부흥 방법은?
    • 일을 재밌게 느낄 수 있도록
  • 번아웃 극복 경험?
    • 쉬면서 실패 극복 루틴으로~!

출처