우아한 테크 세미나 <개발자 원칙>, 오프라인 참가 후기

본 포스팅은 3월 우아한 테크 세미나를 기록한 내용입니다.

 

3월 우아한 테크 세미나 오프라인 참가에 당첨됐다.

 

 

 

개발자의 원칙을 집필하신 인프런 이동욱님, 무신사 박미정님, 컬리 박성철님께서 연사하는 자리였다.

이동욱님을 실제로 볼 수 있다는 팬심과 개발 세미나에 기대에 참가했고,

너무너무너무너무너무 설레하며... 맨 앞자리에서 이 세 분의 세미나를 들을 수 있었다.

 

총 네 세션으로 "제어할 수 없는 것에 의존하지 않기", "실패를 축하합니다", "<덕업일치를 넘어서>에서 하고 싶었던 이야기", 그리고 "QNA"로 진행이 되었다. 개인적인 생각으로, 첫 번째 세션은 개발과 개발 문화에 가까운 내용이었고, 두 번째 세션은 실패를 다루는 스킬에 대한 내용, 그리고 마지막으로는 성철님의 소프트웨어 개발자에 대한 고찰에 대한 내용이었다.

그리고.. 간식으로 주신 에그타르트가 진짜 심각하게 맛있었다. 나갈 때 하나씩 가져가라고 하셨는데 왜 안받았을까...

 

이하 내용은 해당 세미나를 들으면 기록한 내용이다.

 

---

 

 

첫 번째 세션: 

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

인프랩 이동욱

 

첫 번째 세션은 인프랩 이동욱님의 “제어할 수 없는 것에 의존하지 않기”세션으로 시작했다.

결론부터 말하자면, 제어할 수 있는 것과 없는 것을 구분하고, 제어할 수 있는 것에 집중하는 것이 이동욱님의 메세지였다.

여러가지 예시로 이 메세지를 뒤받침 해주셨는데, 가령 가장 첫 질문이 아래와 같았다.

 

Q. 일정은 지키지만 버그가 많은 것   VS   일정은 못지키지만 버그가 없는 것

 

많은 사람들이 후자를 선택하지 않을까 한다.

하지만, 이동욱님이 말씀하신 건 전자였다.

곧이어 아래의 인용구로 전자의 타당성에 대한 설명을 열었다.

 

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

- <오늘, 또 일을 미루고 말았다>, 나카지마 사토시

 

“프로덕트 엔지니어의 일은 고객이 원하는 기능을 고객이 원하는 시점에 전달하는 것”이라고 말한다.

 

그렇다는 건, 일정이 퀄리티보다 중요한가?

이것 또한 아니다.

 

아무리 급해도 항상 80~90짜리 소프트웨어를 일정 내 개발할 수 있는 방법을 탐구해야 하는 것이다.

그렇다면, 일정을 어떻게 해야 잘 지킬 수 있을까?

일정을 항상 잘 지키는 분들의 공통점을 살펴보면 결론은 다음과 같다.

 

마주한 문제를 가장 현실적인 해결책으로 해결해 나아가며,

이를 원칙으로 쌓아나가, 빠르고 효율적인 코드를 만들어 가는 사람이었다.

 

이상적인 해결책으로 코드를 풀어나가는 길이 아닌,

현실적으로 해결할 방법을 터득하여 빠르게 개발할 수 있는 개발자를 말한다.

그렇다면, 가장 현실적인 문제를 해결하는 방법이란 무엇인가?

 

이에 대한 대답에 바로 “제어할 수 없는 것에 의존하지 않기” 법칙이 적용된다.

지금부터 제어할 수 없는 것의 문제를 볼 수 있는 예시를 살펴보자.

 

 

예시 1. 주민 번호를 메인키 값으로 해도 될까?

누구나 "주민 번호"는 절대 변하지 않고, 유니크하기 때문에 메인 키로 잡아 두기 적합하다고 생각할 것이다.

그런데, 실제로 언젠가 예기치 못한 무분별한 수집을 하지 말라는 국가 정책이 결정되었다.

즉, 더 이상 주민 번호를 메인 키(PK)로 사용하지 못하게 되었다고 한다.

 

더 이상 주민 번호를 메인 키(PK)로 사용하지 못하게 되어,

메인 키를 변경해야 하기 때문에 모든 시스템에 문제가 크게 발생하게 된 것이다.

 

여기서 제어할 수 없는 것은 주민 번호라는 외적인 요소였다.

그 어떻게 조절할 수 없는 값이 아니다.

이 경험을 통해, 또 제어할 수 없는 것에 의존하지 않기 위해, 아래와 같은 원칙을 세울 수 있다.

 

원칙 1. 그래서 외부에서 전달 받은 값은 절대 주요키로 선택하지 않는다.

원칙 2. 애플리케이션에서 메인 키 값을 생성하고 다룬다.

 

이로 인해 DB 샤딩, DB 드라이버 변경, 분산 환경 등의 확장이나 변경에 영향을 받지 않을 수 있게 된다.

 

 

 

예시 2. 일요일에만 할인하는 시스템

일요일에만 할인을 하는 시스템을 만든다.

일요일이면 할인을 하는 코드를 짰는데 테스트 코드에 LocaldAteTime.now()를 하게 되니 일요일이 아닌 날 테스트를 돌리면 오류가 발생한다.

 

상황: 일요일만 할인하는 로직 → 토요일에 테스트 돌리면 오류 ⇒ 날짜를 모킹하여 테스트 통과

 

하지만 의존하는 시스템에 변화가 생기면?

가령, 날짜 라이브러리를 변경해야 하면?

혹은, jest로 모든 테스트를 mocking하고 있었는데, jest가 변경되어야 한다면?

→ 변화에 쉽게 흔들리는 소프트웨어

 

해결은 Default Parameter를 설정하여 현재 시간과 무관하게, 값이 없어도 돌아갈 수 있는 외부에 전혀 의존하지 않는 코드를 제작하는 것이다.

변화되는 것에, 또 외부의 것에 의존하지 말아야 하며, 이에 대응하는 생각이 필요하다.

 

 

 

예시 3. 일요일에만 할인하는 시스템

여러 결제 강의들 중 결제 금액 계산 결과가 100원이 넘는 건들만 골라서 PG 결제 요청을 보내는 목표를 가진다.

요청을 보낼 requestPg 함수는 async - await 키워드를 가진 함수다.

 

이제부터 모든 함수가 하나의 역할만 하도록 기능 추출한다: payCourses > payAll > pay > requestPg

→ 문제점: 모든 함수에 sync await 사용하게 된다.

 

제어할 수 없는 함수에 의존하는 모든 코드가 제어할 수 없는 코드가 된다.

asyn requestPg 를 의존하고 있기 때문에 세 개의 함수가 모두 async 를 달아야 하는 문제가 발생했다.

아래 코드처럼, 제어할 수 없는 코드로 인해 async - await 이 전파되었다.

 

async const payCourses = () => { 
	...
	await payAll();
}

async const payAll = () => { 
	...
	await pay();
}

async const pay = () => { 
	...
    await requestPg();
}

/* 제어할 수 없는 코드 */
aysnc const requestPg = () => {
	...
}

 

 

해결책은? 제어 할 수 있는 코드와 제어 할 수 없는 코드를 분리하자.

위와 같은 코드를 아래와 같이 분리한다.

 

async const payCourses = () => {    
    getCourseAmounts();
    
	await requestPg();
}

/* 제어할 수 없는 코드 */
aysnc const requestPg = () => {
	...
}

/* 제어할 수 있는 코드 */
const getCourseAmounts = () => { 
	...
}

UI, Data는 제어하기 어려움 → 제어할 수 없는 영역

Business Logic 은 제어 가능한 코드로 최대한 늘려나가야 할 영역이다.

문제점의 공통점 ⇒ 변화에 쉽게 흔들리는 소프트웨어가 만들어진다.

 

제어할 수 없는 팀원은?

제어할 수 없는 것: 매출, 투자, 연봉, 권고사직

제어할 수 있는 것: 팀원의 성장 환경

 

제어 1. 사내 강연 : 개발자를 모셔오지는 못하더라도 사내 강연으로 초청하자는 선택을 했다.

제어 2. 잦은 피드백 : 정적분석, 테스트 코드, Lint, 코드 포맷팅

 

효과: 팀원들이 먼저 필요한 사내강연을 요청하기 시작했다.

 

어려운 환경에서의 어떻게 해결할까?

가령, 농구 선수단이 모두 매일같이 거리가 먼 학교로 가서 연습을 해야하는 상황이라면, 감독은 어떻게 해야 할까?

현명한 감독은 "원정 경기에 강해질 것"이라는 설득을 했고, 설득으로 그들을 제어할 수 있었다.

 

항상 좋은 환경에 있을 수는 없다.

제어할 수 없는 것에 거리를 두고,

제어할 수 있는 것에 집중해야 한다.

 

---

 

두 번째 세션: 

실패를 축하합니다

무신사 박미정

 

 

수 많은 이직을 경험했다. 이직이라는 수단을 사용하며, 많은 시도를 했고 많은 실패를 겪었다고 한다.

그러다, 많은 실패를 겪으면서 그 내용들을 카테고라이징을 할 수 있지 않을까? 라는 시점으로 실패에 대한 두 번째 세션이 시작된다.

 

📌 이런 실패를 해봤다 —

실패: 뜻한 대로 되지 아니하거나 그르침

 

1# 개발자

- 버그있는 코드 배포

- 운영 테이블 삭제로 데이터 손실

- 코드 배포 후, 성능 문제 발생

- 언제나 기시감 드는 코드 작성

 

2# 관리자

- 팀의 역량을 파악하기 전 일을 계획 : 프로젝트 중단

- 개발팀 과잉보호: 소통과 신회가 어려운 개발팀

- 팀원을 이해하기 전 판단 : 대화가 어려운 리더

 

3# 제품을 만드는 사람

- 개발자니까 기술에만 집중하는 태도 → 코드의 미미한 성장에 비해 떠나가는 사용자들

- 개발 문화만 너무 소중한 태도

 

📌 이런 실패를 해봤다, 그 후 —

1# 개발자

인프라 보안 강화, 성능 테스트 절차 강화 …

 

2# 제품 만드는 사람

최종 사용자 관점에서 고민하는 태도 - 최종 사용자가 만족해야 가치가 생긴다!

 

3# 관리자

일과 사람을 냉정하게 바라보고 실현 가능성 판단. 본인이 케어할 수 있는 팀이 주도적으로 성장할 수 있게뜸 만드느 것.

왜 그렇게 밖에 할 수 없었을까?

 

실패를 극복하는 원칙

1. 실패를 회피하지 않고 경험 안에서 느끼고 있는 감정을 충분히 느끼기
   • 회피하지 않고 충분히 우울함을 느낀다
2. 감정에서 빠져나오기
   • 필요 이상으로 우울함에 매몰되어 있구나를 인지
   • 시그널 인지 → 똑같은 생각을 반복한다면, 활자를 읽는다. 감정을 분리하기 가장 좋은 수단
3. 실패를 제대로 바라보기
   • 내 실패를 적어 내려가자. 이 과정으로 내 실수를 정확하게 인지하고 인식
4. 단 한가지의 액션 아이템 선정하기
   • 이 실패를 반복하지 않기 위한 단 한가지를 실행 (회복)

 

 

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

실패의 극복에 대한 전파 속도를 높이고, 실패 반복 가능성 낮추는 것이다.

 

버그: 코드 리뷰 절차 강화 > 테스트 코드 작성 문화

코드 배포 후, 성능 문제 발새이 성능 테스트 절차 강화 > 고급 API 로직 분석

하지만, 가장 임팩트 있는 단 한 가지를 택한다. 실패를 대하는 루틴이 너무 무겁지 않도록.

 

2022년 ‘리더십’ 및 ‘팀’에 대한 성찰

 

개인 뿐만 아니라, 팀원들이 실패를 할 때에도 이 규칙을 적용해야 한다.

우리는 모두가 실패는 당연하다는 것을 알고있다.

• 테스트 주도 개발에서 이야기하느 사이클 → 실패하는 테스트 작성
• Agile 하게? Fail Fast

 

매번 성공하는 사람?

되게 멋없다 ~ 본인이 될 것 같은 것만 하는 구나 ~

 

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

 

 

실패/실수 - “기록”

대부분의 사람들은 위인전에는 성공 얘기만 적힌 줄 안다.

하지만, 실제 위인들은 실수와 실패를 엄청나게 기록했다.

 

 

책 추천

: IMPOSTOR. 임포스터.

내가 할 수 있는 것과 내가 할 수 없는 것을 구분하는 학습

 

 

---

 

 

 

세 번째 세션: 

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

컬리 박성철

 

 

생즉고 生卽苦, 삶은 그 자체로 모든 요소가 괴로움에 속한다.

즉, 삶은 고해다.

→ 우리는 이 어려운 세상을 어떻게 할까.

 

 

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

…

• 삶에 심각한 결과를 초래할 부정적적인 영향력이 나에게도 있다
• 내 작업이 결국 인류에게 영향을 미친다
• 사용자의 착취를 막겠다.
• 모든 내 동료 인간, 특별한 의무가 있음을 기억할 것
• 나는 내가 관문을 지키는 사람임
• 내가 사는 동안 조중받고 그 후에는 기억될 것

 

원칙  —

연사자님의 원칙은 "소프트웨어로 사람들에게 도움이 되자 (Others first, Yourself last)"라고 설명한다.

 

 

책의 의도   —

연사는 아래의 두 책을 먼저 소개한다.

• Programmers at Work  : 전설적인 프로그래머들의 이야기
• 영혼을 읽지 않는 디자이너 되기 : 주로 혼자 일하고, 스스로 디자인에 일가견이 있는 줄 아는 클라이언트와 마주치면서, 어떻게 영혼을 잃지 않는가

 

위의 두 책이 전하는 섞어두었다고 한다.

1. 직업으로써의 프로그래머
2. 영혼 잃지 않기

 

왜 개발자는 다 애 같을까?

개발자들은 왜 애처럼 취급당할까?

 

실리콘밸리와 한국의 컴퓨터 역사는 다르다.

- 실리콘밸리에서 볼 수 있는 컴퓨터의 역사 - 흔히 아는 컴퓨터, 그 이전의 기계 장치들

- 한국의 컴퓨터의 역사 - 애플: 컴퓨터

 

개발 업계는 항상 새로운 분야

• 소프트웨어 장인정신 vs 소프트웨어 개발

지식 근로자는 스스로 성과를 내야 하는 사람이다.

나를 잃어버리지 않는 것이 중요하다.

 

전문가란 무엇인가?

Specialist, Expert, Professional, .. 다양한 단어가 있지만, 우리는 직업으로서의 전문가 Professional를 말한다.

전문가 = 역량 x 동기 x 방향(cos ⍬) x 협력

 

 

사실, 매슬로의 욕구단계설은 거짓이다.

자아 실현의 욕구는 자기 내부에서 나오는 것으로, 어떤 욕구가 채워지던 말던 항상 자아 실현의 욕구는 존재한다.

우리는 대폭발로 튕겨나가는 파편이다.

 

 

---

QNA

1/ 테크리더의 가장 중요한 역량을 꼽으라면?

• 성철님: 공감 능력 -(정정)→ 성장하는 리더 (리더도 실수하기 마련, 성장하도록 해야한다)
• 동욱님:
  • 과락 : 위임을 못하는 사람은 테크리더는 절대 안된다.
  • 호들갑 떨기: 호들갑을 잘 떠는 사람은 의외로 테크리더로 좋다.
• 미정님: 소프트 스킬도 챙겨야 한다.

 

2/ 유연성있게 성장할 수 있는 개발 방법이나 습관이 있나요?

• 미정님: 작성했던 코드를 다시 작성해보기. 시스템 설계도 다시 한 번 해보곤 한다.
• 동욱님: “제가 틀렸네요”라고 말할 수 있는 것. 이게 생각보다 너무 힘들다.
• 성철님: 성장 자체를 즐기는 것이다. 자격 미달이라고 생각하는 건 압박이라고 생각이 들고, 곧 재미가 없어지기 때문이다.

 

3/ 피드백을 주고 받는 방식은 어떻게 해야 하나요?

• 미정님: 그 사람에게 맞는 피드백을 준다. 둘러대거나 직접적으로 말하는 방식이 있다.
• 동욱님: 피드백을 주는 시점을 빠르게 한다. 만 번 다 시도하고 피드백을 주면 비효율이니 바로, 그 즉시 피드백한다.
• 성철님: 교정(안좋은) 피드백을 없앤다.

 

4/ 여러 사람을 만나면서, 이런 사람이랑 일하고 싶다하는 사람이 있나요?

• 동욱: 같이 일하면서 이 사람이랑은 다음 회사에서도 같이 일하고 싶다하는 부분이 있었다. 어디서 느꼈냐면, 엄청난 집요함이 있다. 전문성있는 분이며, 근본 문제까지 집요하게 파서 공유하는 분이었다.

 

5/ 팀원들의 성장에 대한 니즈를 끌어올릴 수 있는 방법이 있나요?

• 성철: 어렵다. 그치만, 일을 재밌으면 성장하고 싶어한다.

 

 

6/ 번아웃 - 실패에 대한 연장선으로, 오랜 시간 동안 실패를 겪는 것. 과거와 현재를 비교하면서 나는 왜 못하지를 생각하곤 한다.

• 미정: 성과에 대한 자신이 있었는데, 현재 결과만 보면 계속 좋지 못함. 탓하고 싶어도 제어할 수 없는 것이다.
  • 회복을 하는 방법: 휴가를 다 끌어모아서 쉬는 것이다.
  • 이후 문제를 직면하고 루틴을 돌리는 중이다.
• 성철: 스트레스를 기피해야 하는 것처럼 생각하는데 그렇지만은 않다. U Stress, D Stress가 있다. 자신감이 넘치면 U Stress 가 넓어지고 자신감을 회복하고 도전감을 찾는 것.
  • 이불을 개는 것. 작은 성취를 한다.
• 동욱: 퀘스트처럼 "화장실 청소, 주말 일정 2, 주말 일정 3, … " 클리어를 시키며 사소한 만족을 즐긴다.
  • (아무도 열지 못하는) 일기를 많이 쓰는 편이다.
  • 어느 정도의 번아웃인지는 모르겠지만, 나태해지지 않을 만큼의 긴장감을 유지하는 것은 필요하다.

 

 

7/ 이직의 성공과 후회가 있었나요?

• 미정: 이직은 내가 성장을 하고싶은데 성장하기가 어렵다라는 시점이 있을 때한다. 아무것도 해보지 않고 이직을 하는 건 회피이고, 이직을 할 땐 성장하고자 하는 포인트가 항상 있었다. 어떤 회사를 나왔을 때 어떤 사람이 되고 싶다는 생각을 한다.
• 동욱: 지금해도 상관없는데? 라는 생각이 들 때 이직을 한다. 지금 회사의 불만이 있다면 가지마라. 지금 "못참겠다" 싶으면 그 불만에 초점을 맞춰서 이상한 곳으로 갈 확률이 크다.
• 성철: 잘못된 이직이라고 생각해본 적은 없다. 이직을 해서 마음이 편했다. (현재) 지인이 “매년 어떤 일을 하고 떠날 거야” 라고 생각한다고 말했다. 홀가분하게 떠날 수 있는 상황에 떠났다. 내가 할 일은 여기서 끝냈다.

 

 

 

 

Youtube Link