🌱 서론

(사람들이 점심시간을 포기하고 줄을 서는 바람에 점심을 먹고 온 나는 뒤에서 의자에도 앉지 못한 채 바닥에 앉아 강의를 들어야했다.. 😭)

• 📣 스피커 : 김영한 (전 우아한형제들 기술이사)
• 세션을 선택한 이유
  - 인프런에서 영한님의 강의를 들을 때 마다 주니어 개발자가 실무 현장에서 겪는 고민들이 어떤 것인지 정말 잘 알고 계신다는 것과, 가려운 부분이 어떤 부분인지 너무 잘 알고 계신다는 것을 느낀다. 작년 인프콘 세션에서도 성장에 대한 깊은 고민을 하고 있는 주니어 개발자들에게 뼈와 살이 되는 강의를 해주셨다. 이번에는 또 어떤 명강의를 준비하셨을지 기대되었다.

✍🏻 세션 정리

1. 성장 기본기 - 기술과 비지니스

마음에 드는 회사에 취업하는 것이 성공했는가?
개발자에게는 취업을 한 것으로 끝이 아니다.
직장에서 개발자로 일을 하게 되었다면, 이제 진짜 시작인 것이다.

그렇다면 '성장' 은 과연 무엇일까?
개발자에게 있어서 '성장' 은 두가지 큰 축 으로 바라볼 수 있다.

🍧 성장의 첫번째 축, '기술'

🙋🏻‍♂️실무 환경에서 볼 수 있는 3가지 유형의 개발자

1. 기술 공부를 하지 않는 개발자

• 기술공부를 하지 않는 이유 : 기술 공부를 하지 않아도 팀에서 필요한 업무를 처리 가능할 수 있다.
• 기술에 대한 깊은 이해가 없다.
• 반복적이고 비슷한 개발 업무를 한다.
• 장애가 발생하면 근본 원인을 파악하여 해결하는 것을 어려워한다.
• 새로운 기술의 도입에 주저한다.
• 1년차의 경험을 10번 반복하면 그런 10년차 개발자가 된다. 🫠

2. 기술 트랜드 찍먹하는 개발자

• 기술 공부를 하긴 하지만, 팀에서 현재 사용하는 기술에 대한 깊은 이해가 없다.
• 키워드만 알뿐 실제로 다루는 것에는 어려워한다.
• 유행만 쫓아가고 깊이가 없다.
• 팀 내에서 신뢰를 잃기가 쉬워진다.

3. 팀 기술을 잘 이해한 후 새로운 기술을 공부하는 개발자

• 우선적으로 팀 내에서 사용하는 기술 역량을 잘 쌓는다.
• 기술에 대한 이해도가 있으므로 자신감이 생겨 업무를 원할하게 진행 가능하다.
• 기술적인 장애가 발생했을 때, 원인을 빠르고 정확하게 파악하여 해결한다.
• 이를 통해 팀내에서 신뢰가 생기게 된다.
• 쌓인 신뢰를 기반으로 새로운 기술에 대해 도전할 수 있게 된다.
  - 성장은 또 다른 성장으로 이어지게 된다. 📈

💻 팀 내에서 사용하는 기술 학습의 중요도

팀 기술 학습의 장점

• 실무에서 실제로 사용하는 비지니스를 다루는 것이므로, 해결을 해야한다는 빠르고 강한 동기부여가 생긴다.
• 그렇기 때문에, 실제 팀내에서 어떤 기술을 사용하는지 파악하는 것과 당장 사용하고 있는 기술에 대한 학습이 중요하다.

기술 학습의 중요도
1순위 : 팀내 현재 사용하고 있는 기술
2순위 : 업계 메인 기술
3순위 : 최신 기술

📖 기술을 '학습' 한다는 것은 무엇을 의미하는가.

단지 강의를 들었다는 것으로 기술을 학습했다고 생각 하지 말자.

• 이론과 실습의 조화를 시켜야한다.
• 고민 없이 그냥 흡수하는 것은 아무런 의미가 없다.
• 나의 언어로 그 기술에 대해 설명할 수 있어야 한다.

단지 그 기술을 업무에서 사용하고 있다는 이유만으로도 기술을 안다고 생각하지 말자.

• 1년차의 경험을 10번 반복하지 말자.
• 기술의 기본원리를 깊이 이해하는 것이 중요하다.
• 기술에 대한 문제가 생겼을 때, 근본 원인이 무엇인지 파악하고 해결 할 수 있어야 한다.

🏃🏻 경기와 훈련

영한님은 항상 찰떡같은 비유를 들어서 설명해주신다.
운동선수를 빗대서 개발자의 학습의 중요도를 설명해 주셨다.

운동선수가 평소에 훈련하지 않는다면 근육이 빠지고 도태된다.
개발자도 마찬가지다.

운동선수 - 개발자

• 경기 - 회사 업무
• 훈련 - 회사 업무 외의 학습의 시간

개발자는 회사 업무외에 훈련하고 학습하는 시간이 중요하다.
회사 업무는 마치 경기와 같아서 나의 개인적인 성장을 위해서는 별도의 훈련을 해야한다.

잊지말자.

🍰 성장의 두번째 축, '비지니스 이해'

많은 개발자들이 '기술' 에만 많이 집중을 하고 본인이 속한 회사와 팀 내의 비지니스 에 대한 이해에는 소홀하다.
나 또한 마찬가지였다.
개발자로서 '공부' 하고 '학습' 한다고 생각을 하면 당연히 내가 사용하는 기술에 대해 공부를 떠올리곤 했다.

영한님 역시, 주니어때 그렇게 하셨었다고 한다.

기술을 학습하는 것에 투자하는 것 만큼, 비지니스에 대한 이해에도 투자를 해야한다.

'회사에서 내가 지금 왜 이 코드를 작성하고 있는가?'
회사의 어떠한 비지니스를 동작시키고, 그 비지니스로 인해 회사가 돈을 벌기 때문이다.

기술을 아무리 잘알고, 클린코드를 하고 리팩토링의 대가여도
비지니스가 없다면, 그 코드는 개발자를 먹여살릴 수 없다.

⌨️ 코드가 쓰여지는 이유

• 코드는 비지니스를 위해 쓰여진다.
• 비지니스란 세상의 문제를 해결하는 것을 의미한다.
• 세상의 문제를 해결하고, 그 코드는 문제 해결에 대한 대가를 받는다.
• 즉, 코드는 세상의 문제를 해결하기 위해 쓰여진다.

🗺️ 큰 지도 만들기 - 비지니스와 개발의 연결고리 만들기

개발자는 비지니스 구현이 어떻게 되어있는가에 대한 고민을 해야한다.

데이터 정리

• 각각의 엔터티들이 어떤 관계를 가지고 있고 무엇을 의미하는지를 파악한다.
• 현실의 문제를 어떤 엔터티 모델로 나누었는지 고민한다.
• 사실 핵심 테이블은 많지 않다. 비지니스 구현에 있어서 핵심 테이블이 무엇인지를 먼저 파악한다.
• 핵심 테이블을 파악 했다면, 그 테이블의 핵심 필드가 무엇인지 파악한다.

핵심 업무 프로세스 정리

• 비지니스의 동작 프로세스를 그려본다.
• 핵심 도메인이 어떤 방식으로 구현되어있는지를 파악한다.

데이터 정리와, 핵심 업무 프로세스 정리를 통해 전체 비지니스의 플로우를 그리면서 이해도를 높여야 한다.

🙋🏻‍♂️ 비지니스 모델에 있어서 개발자가 취하는 2가지 자세

비지니스 모델에 이해도가 약한 개발자 🫠

• 큰 그림에서 전체 상황을 이해하지 못한다.
• 프로세스에 대한 지도가 없으므로 모르는 것이 생겼을 때, 어디까지 질문해야할지 모른다.
• 작업 영향 범위가 파악이 되지 않은 상태이므로 코드를 작성하고 변경할 때 사이드 이펙트가 생긴다.
• 요구사항이 들어왔을 때 의도를 파악하기 어려워 제대로 처리하지 못한다.
  - 비지니스에 대한 이해가 약하면 기술적으로 아무리 뛰어나도 요구사항을 처리하는 것에 실패할 가능성이 매우 높다.

비지니스 모델 이해에 힘쓰는 개발자 🤓

• 프로세스에 대한 전체적인 지도가 있으므로 질문의 범위가 명확하다.
• 시간이 지날 수록 전체적인 프로세스에 살을 붙이면서 아키텍처에 대한 이해도가 높아진다.
• 변경사항에 대한 영향 범위가 어디까지인지 명확하므로 버그나 로직의 미스가 적다.
• 비지니스에 대한 이해도를 바탕으로 확신과 자신이 생기므로 기술적 혁신도 가능하게 된다.

🍡 좋은 아키텍처를 설계하는 법

좋은 기술, 최신 기술, 트렌디한 기술도 매우 중요하다.
하지만, 개발을 잘하고 좋은 아키텍처 설계하기 위해서는 비지니스에 대한 이해가 필수적이다.

늘 그렇듯, 아키텍처 설계는 트레이드 오프의 관계다.
정답이 없는 상황에서 아키텍처의 선택은 매우 변동성이 있다.
이 변동의 판단 근거는 기술의 트렌디함이 아닌, 비지니스에 대한 이해도에 크게 의존한다.

'중요한 것과 중요하지 않은 것'
'변경 가능한 것과 변경 불가능한 것'
이러한 판단이 매우 필수적이고, 이러한 판단은 비지니스 이해도에 의존하기 때문이다.

좋은 아키택처를 설계하기 위해서는 비지니스에 대한 이해가 필수적이다.

2. 성장 부스팅 - 용기, WHY

🐣 약간의 용기 - 컴포트 존을 벗어나기

많은 개발자들이 업무를 맡을 때, 다 알아야 그 업무를 할 수 있다고 생각한다.
절대 그렇지 않다.

모르는 부분에 도전하고, 그것을 통해 나의 영역을 넓히는 것이 매우 중요하다.

편안한 업무, 반복적이고 똑같은 업무만 한다면 성장이 없다.
컴포트 존을 벗어나면 두려움이 온다.
모르는 것에 대한 두려움 속에서 모름을 앎으로 바꿔가면,
어느 순간 성장해 있는 자신을 발견한다.

🙋🏻 WHY - 질문하기

근본적인 이유를 알아야, 본질적인 답을 찾을 수 있다.

기술이든, 비지니스든 근본적인 이유를 알아야 올바른 대안을 찾을 수 있다.
근본적인 이유를 알기 위해서는 '질문' 을 해야한다.

기술에 대한 질문

• 내가 왜 이 기술을 선택하고 사용하는가?
• 이렇게 하는 것이 맞는가?
• 이 문제는 어떻게 해결 해야하는가?

비지니스에 대한 질문

• 이 비지니스는 어떻게 해결해야 하는가?
• 왜 이 부분은 이런 방법으로 풀어야 하는가?

절.대.로
위에서 시킨다고 해서 그냥 하면 안된다.🙅🏻
고민 없이 개발을 하고 비지니스를 받아들이면 내 것이 되지 않는다.

🍬 왜? 를 위한 마법의 문장

'왜' 라는 질문은 자칫 누군가에게는 공격하는 것처럼 보일 수 있다.

무서운 '왜?' 😡
"왜 이런식으로 기획이 되었나요?"
"코드를 왜 이렇게 짜셨나요?"

우어.. 🙄
무척이나 공격적이다.

자칫 "왜 이딴식으로 기획을 했나요?", "왜 이따구로 코드를 짰나요?" 처럼 들릴 수 있다.

팀 내의 개발자들과 코드리뷰를 잘 하기 위해서도,
기획팀과의 소통을 잘 하기 위해서도
누군가에게 질문할 때 '왜' 라는 질문을 잘 해야한다.

고민이 있습니다 : '왜'를 존중으로 보이게 함으로 부드럽게 표현을 가능하게 하는 마법의 문장.

이 문장을 필두로 궁금함을 물어보면 소통하기가 더욱 편하고 쉬워진다. 🧚🏻‍♂️

3. 주니어 시절 자주하는 고민들

🧃 성장하기 좋은 환경은 어디인가요?

• 지금 당장 좋은 환경도 중요하지만, 앞으로 일하기 좋은 방향으로 바꾸어 나가려고 노력하는 조직이 좋은 환경이다.
• 구성원들의 좋은 환경을 위해 고민하는 시니어들이 많은 조직이 좋다.
• 또한, 눈 앞의 당장의 업무를 빠르게 해결하는 것보다 고민과 생각하는 것을 응원하는 조직이 좋은 환경이다.

🍮 개발 할 때, 생각과 고민이 너무 많아요.

• 고민을 한다는 것은 긍정적이다.
• 고민을 한다는 것은 무언가 알고 있기에 고민하는 지점이 많아지는 것이다.

하.지.만,
고민을 너무 많이해서 개발 속도가 나지 않는다면 마냥 좋다고는 할 수 없다.

2,3년차 주니어 개발자가 개발할 때, 고민과 생각이 많아지는 지점은 주로 다음 3가지다.

고민 지점
1. 어플리케이션 구조 : 최대한 단순하게 시작을 하자. 단순하게 시작하면서 고민의 깊이를 높여가자.
2. 최적화 : 처음부터 최적화를 고민하면 시작조차 할 수 없다. 최적화에도 단계가 있다.
어설픈 최적화는 도리어 개발 품질을 약화시킬 수 있다.
3. 아키텍처 : 최대한 단순하게 생각하자. MSA 가 정답이 절대 아니다. 무조건 단순하게 생각하고 구성하는 것이 시작이다.

🐢 거북이 마음을 가지자.

인간의 CPU 는 하나고, 컨텍스트 스위칭 비용은 매우 크다.
그러므로 이것저것 한번에 공부를 하려고하면 도리어 지치고 얻는 것이 없어지게 된다.

조급한 마음을 가진다고 되는 것이 아니다.
공부할 것은 원래 상당히 많고, 개발자로 살아가면서 평생 해야 할 것들이다.

거북이 마음을 가지고 하나씩 처리하는 것이 중요하다.
거북이 마음을 가지고 하나씩 전진하는 것이 중요하다.

🙏🏻 개인 소감

• 늘 그렇듯, 영한님의 강연은 항상 따뜻하다.
  그리고 그 따뜻함 속에 늘 배울 부분이 존재한다.
  이번 세션에서는 특히 내가 상대적으로 소홀히 여겼던 비지니스에 대한 이해도의 중요성에 대해 깨닫게 되었다.
  개발자로 살아가면 살아갈 수록, 분명 나는 공부를 그래도 매일 하고 있음에도 해야할 것들이 더욱 많아지는 것 같은 부담과 무게가 있었는데, 영한님의 세션을 통해 위로와 위안을 받았다.
  거북이 마음을 가지고 꾸준히 성장하는 개발자가 되자. 🐢