[2022.08.26] INFCON 2022

https://infcon.day/

인프콘 2022 - INFCON 2022

 

  3년 만의 오프라인 컨퍼런스라니! 끝날 듯 끝나지 않는 코로나가 잠시 주춤 해든 틈을 타 개최되었다. (요새 다시 기승을 부리고 있어 네이버 DEVIEW는 취소되어 버렸을 정도) 재시작의 시작을 끊은 컨퍼런스가 네이버나 카카오가 아닌 인프랩이라는 사실에 또 한 번 놀랐다. 시리즈 A 단계의 회사가 네이버/카카오가 하는 정도의 대규모 컨퍼런스를 열다니, 보통 대단한 일이 아니다. 엄청난 시간, 열정, 비용 등이 소모되는 일일 텐데 말이다. 정말 같이 나누고 성장하는 것을 중요하게 생각하는 듯 한 모습을 보여주었다.

 

 

---

시간표

  행사 전체 시간표는 아래처럼 진행되었다. 흥미로운 주제들이 많았지만 한 타임에 한 개만 들어야 하는 아쉬움이 있었다. 나중에 영상 공개가 되면 봐야겠다.

출처: 인프콘 홈페이지 (https://cdn.inflearn.com/infcon/infcon_timetable.png)

 

---

 

오프닝 (13:00 ~ 13:30)

12:55쯤, 행사 시작 전

 

정말 맨손으로 바닥부터 인프런을 시작해 여기까지 끌고 온 대표 이형주님

 

CTO 향로 이동욱님, 기존 슬로건의 앞에 With를 추가하고자 한다고

 

인프콘 전체 총디렉을 맡은 홍연의님

  소감  

  2015년 1인으로 시작해 현재 94만명의 회원을 보유한 인프랩. 워드프레스와 MySQL로 회원 10만 명 까지 버티고 다음 아키텍처로 넘어갔다고... 단순한 강의 사이트를 넘어 커뮤니티 & 질문(스택오버플로우 같은), 이력서 관리 등 개발자가 계속 사용하는 플랫폼으로 확장하려는 의지를 보여주었다.

 

 

실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고. Pixelic 한정수 (103호, 13:45 ~ 14:25)

정말 많은 내용을 빠르게 잘 전달하였다

소감

  내 또래에 애기가 둘이나 있는데 이 정도 열정을 보일 수 있다니 너무 놀랬다. 정말 밀도 높은 삶을 몇 년간 살아온 것 같다. 개발에 대한 열정과 갈망 등이 느껴졌고 회사들에서 배우고 느낀 것들을 바탕으로 더 발전해 나가고 있는 점도 훌륭해 보였다.

 

 

인프런 아키텍처의 과거와 현재, 그리고 미래. 인프랩 이동욱 (103호 14:40 ~ 15:20)

적정 기술을 여기서 쓸줄이야

소감

  개발을 잘 모르는 대표 혼자서 만든 시스템인 시즌 1부터 현재의 시즌 4까지의 여정을 보여주었다. 자원(시간, 인력)은 유한하니 그때 상황에 맞는 선택을 해서 달리는 바퀴를 교체하였다. (시스템 및 아키텍처를 무중단으로 업그레이드해야 한다) 매일 장애가 나는 시즌도 있었고 많은 우여곡절이 있었지만, 스타트업이 현재까지 왔다는 것만으로도 대단한 일이다.

  현재 상황에 맞는 적정 기술(소프트웨어)을 사용하여 시스템을 확장해 나가려 한다는 부분이 공감이 되었다. 모든 것을 잘하려고 하면 모든 것을 망칠 수 있다. 한 번에 하나씩 집중해 문제를 돌파해 나가야 한다.

 

 

코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes. 컨텍스츠아이오 서지연 (103호, 15:35 ~ 15:55)

이번에도 코드 리뷰와 관련된 발표를 하시는 치즈님

소감

  기존의 단순한 Pull Requests 방식이 아닌 맥락과 단계별 변화까지 공유할 수 있는 Stacked Changes 방식을 처음 들어보았다. 개별 PR이 아닌 여러 개의 묶음으로 스택을 쌓듯이 커밋하고 리뷰를 받을 수 있어 좋아 보였다. 다만 방식이 좀 새로워서 도입하기에는 구성원 모두가 먼저 공부하고 테스트해봐야 할 듯하다.

 

 

실전! 멀티 모듈 프로젝트 구조와 설계. 네이버 김대성 (105호, 16:10 ~ 16:50)

네이버 뮤직, 라인뮤직의 리더라고 하신다

소감

  아마 회사마다 조직마다 모두 다른 프로젝트 구조를 갖고 있을 것이다. 그만큼 답이 없고 다양하게 구성할 수 있는 것이 프로젝트 구조이다. 하지만 그간의 경험과 노하우들을 바탕으로 나름의 해법을 찾아낸 것 같다. 시스템이 복잡해져 감에 따라 테스트, 배포, 유지보수가 쉬운 구조로 바뀌어야 할 것이다.

 

 

지금 당장 DevOps를 해야 하는 이유. 퍼플아이오 김충섭 (Subicura) (105호, 17:05 ~ 17:25)

Docker 구글링하면 제일 먼저 나오는 그분, subicura

소감

  DevOps가 거창하지 않다는 것에 위로(?)를 받았다. 현재의 시스템에서 개발자의 시간을 단축시켜주는 어떤 행동도 DevOps가 될 수 있다고. 개선 -> 도입/측정 -> 공유/전파 -> 축적의 사이클을 쌓아가면서 회사의 CI/CD 생산성을 쌓아 가야 한다고 한다. 그렇게 조금씩 세이브되는 시간이 쌓일수록 개발자들과 회사에는 큰 비용절감으로 다가올 것이다.

 

 

(레거시 시스템) 개편의 기술. 우형 권용근 (102호, 17:40 ~ 18:20)

여전히 열정적인 킹뽀대 용근님

소감

  뭔가 기술적인 이야기 위주일 듯하였으나 여러 번의 개편을 해 보온 경험을 나누는 자리였다. 코드는 작성하는 순간 레거시가 되기 마련이고 언젠가 개편을 할 날이 올 것이다. 달리는 바퀴를 교체한 경험을 잘 배워서 나중에 써먹을 수 있기를.

 

 

어느 날 고민 많은 주니어 개발자가 찾아왔다. 우형 김영한 (103호, 18:35 ~ 19:15)

인프런 및 대한민국 개발 1타 강사 연예인 김영한님

소감

  밑바닥부터 우아한형제들의 기술이사 자리까지 올라온 분이라 신뢰가 가는 내용들이었다. 경험에서 우러나오는 생생한 조언들은 정말 많은 개발자들이 들어야 한다고 생각한다.

  좋은 내용이 많았지만 가장 놀란 것은 매일 30분 정도의 운동과 매일 3시간 정도 자기 계발(공부 or 강의 준비)에 시간을 쏟고 있다는 점이다. 이직하기 전에 이직을 목표로 열심히 공부하고 달리던 나는 목표지향적이었다. 하지만 시스템에 몸을 맡겨서 계속 돌아가게 만드는 것이 훨씬 더 지속 가능하고 롱런할 수 있는 길이라는 것을 알려주었다. 시스템의 가장 대표적인 예로 김연아님을 꼽을 수 있다고...

아! 이것이 답이었다!

 

집으로(19:20 ~ )

행사 종료 후 19:20 즈음의 모습

 

---

 

필기 내용 (날것 그대로)

 

오프닝 103호

이형주 (CEO)

• 꿈, 배움, 그리고 성장
• 1인으로 시작해 94만
• 인프런 서비스 타임라인: 꾸준한 발전
• 미래
  • 교육을 넘어서
  • 인생은 길고 커리어도 길다
  • 교육, 채용, 커뮤니티
  • 꿈: 커리어 전반을 유저와 함께하는 서비스

Why INFCON?

• 감사합니다.
  • 가장 인프랩스럽게 함께 이야기를 나눌 수 있는 자리
  • 함께 성장해야 한다고 생각

이동욱 (CTO)

• Learn, Share, and Grow
• 7년간의 발자취
  • 2015.12 오픈..
• 업데이트 예정
  • 에디터 개편
    • 10만개의 질문 존재
    • 한국의 스택오버플로우 지향
  • 강의실 모바일 뷰 개선
  • 스터디 개편
    • 서비스, 플랫폼으로 확장 예정
  • 랠릿 인프런 통합
  • 그 외: 검색엔진, 검색어 고도화, 랠릿 이력서 개선, 강의 로드맵 개선
• With Learn, Share, and Grow
• 제품 로드맵
  • 매년 인프콘 개최 예정
  • 획기적인 제품 방향성 공유
• 패치노트
• 데이터 공개
  • 개인별 학습 데이터 지식 공유 데이터를 볼 수 있는 서비스 제공

홍연의 (커뮤니티 리드)

• 인프콘 알차게 즐기기

 

실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고. Pixelic 한정수 (103호 13:45 ~ 14:25)

• 소개
  • 사업보다 개발이 더 재밌을 것 같아서 사업 접고 개발 시작

1년 차: 나무가 자랄 수 없는 콘크리트 바닥

• 26곳 지원, 3곳 합격. 클라우드 캐시 스타트업에서 커리어 시작
• 클라우드캐시: 폐업
  • 경험한 것들
    • 이상한 최종 과제: 베트남 P2P 대출 시장 조사해서 보고서를 제출해라
    • 일을 하지 않는 CTO: 웹툰을 보면서 머릿속으로 아키텍처를 짜고 있는 거야
    • 7개월간 제품 개발 X: 실무를 하나도 경험하지 못해서 불안한 마음이 커져감
    • 임금 체불
    • 7개월 만에 퇴사: 2018.12 다시 백수로 돌아감 (29.9살)
• 좋았던 선택들
  • 학습한 내용 깃헙 & 블로그에 정리
  • Git & GitHub 코드리뷰환경 세팅
  • 컴공 전공자와 CS 기초 스터디
  • 개발자 커리어 세미나 참여
    • 알게 된 지인이 사내추천
  • 코딩 테스트를 포기하지 않은 것
• 후회되는 선택들
  • 코딩 테스트 준비를 미리 하지 않은 것
  • 우아한 테크캠프 2기에 지원하지 않은 것
  • 더 빠르게 퇴사하지 않은 것

2년 차: 본격 서비스 개발자

• 줌인터넷 포털개발팀
• 줌인터넷에서 경험한 것들
  • 신입 개발자 파일럿 프로젝트
    • 서비스 설계뿌터 배포까지 직접 진행
    • 9:00 ~ 11:50 회사에서 개발 진행
    • 개발 과정 Notion에 기록 & 공유
  • 첫 서비스 개발 및 배포
  • IDC -> AWS 이전
  • 회사 기술블로그 글 기고
• 좋았던 선택들
  • 이직 타이밍
  • 서비스 분야(도메인) 정하고 이직
    • 결제 도메인: 안정성, 트랜잭션 처리, 고가용성, 내결함성 등이 중요
  • <출퇴근길 개발 읽기> 운영
  • 동기들과 개발 스터디
  • 넥스트스텝 TDD & 클린코드 강의 수강
  • 독서 프로젝트 시작: 내 나이만큼 책 읽기
• 후회되는 선택들
  • 회사 업무와 개인 공부 분리
  • 레거시(Legacy) 코드에 불만을 가진 것

3년 차: 성장 vs 육아

• Toss Payments 코어플랫폼팀
• 토스 페이먼츠에서 경험한 것들
  • 가상계좌 결제 시스템 마이그레이션
    • 20년된 진짜 레거시 코드...
  • CTO님의 코드 리뷰
  • 너무나 뛰어난 동료들
  • 오전 11시 출근, 새벽 0~3시 퇴근
  • 5개월 만에 퇴사 (2021.06.30)
• 좋았던 선택들
  • 코드 리뷰를 자주 요청드린 것
  • 담당했던 프로젝트의 배포까지 끝내고 퇴사한 것
  • 퇴사 이후 4개월 휴식기
• 후회되는 선택들
  • 육아 난이도 망각하고 토스에 합류한 것
  • 개발자의 길을 포기하려 한 것

4년 차: 미국 실리콘밸리로

• Pixelic
• Pixelic에서 경험중인 것들
  • Full Remote + 원하는 시간과 장소
  • 비동기(Asynchronous) 커뮤니케이션
  • Share Up (제품 개발 프로세스)
    • 미국 Basecamp 에서 공개한 제품 개발 프로세스 (100% 원격 + 비동기 업무)
  • Pre 시리즈 A 투자 유치
  • Y Combinator 합격
  • 회사 지분 소유 (RSA)
• 좋았던 선택들
  • 6번 피벗(pivot)한 팀에 합류한 것: 단단하고 유능한 팀
  • 새로운 기술 스택(Ruby on Rails)에 과감하게 도전한 것
    • 살면서 했던 가장 좋았던 선택들 == 손에 쥐고 있던 것들을 놓아 버렸던 선택들
  • 초반에 시스템 아키텍쳐 직접 그려보고 피드백 받은 것
• 후회되는 선택들
  • 아직은 없음

마무리

• 후회 최소화
  • 정답은 없다

 

인프런 아키텍처의 과거와 현재, 그리고 미래. 인프랩 이동욱 (103호 14:40 ~ 15:20)

• 적정 소프트웨어 아키텍처
  • A라는 목표를 B라는 일정안에 달성하기 위해 감수해야 하는

시즌 1

• 개발자 == 대표님
• 혼자서 모든 것을 해야함
• 외부 자원을 최대한 활용하자
• 워드프레스 (PHP, jQuery, MySQL)
• 회원수 10만까지 버팀
• 기능은 그대로 둔채, 서비스를 직접 다시 만들자

시즌 2

• 개발자: BE 1, FE 1, DevOps 1, 대표 1
• 기술스택 통일
• 낮은 러닝 커브
• 최소 관리
• 3.5명의 개발자로 5개월 만에 전체 시스템 전환 완료! (워드프레스 -> Full JS)
• 신규 개발자들이 채용 되면서 점점 발생하는 문제들
  • 신입 개발자들은 익숙치 않은 구조, 패턴
  • 단일 프로젝트 (FE+BE) -> 비횰율적인 Reload, Build
  • 높은 진입장벽
  • 낮아진 심리적 안정감
  • 느려진 번들링, 리로드
  • 불가능한 Component 개발

시즌 3

• 개발자: BE 3, FE 3, DevOps 1, CTO 1
• 심리적 안정감
  • Class & Type
  • 테스트 코드 & 정적분석
  • eslint & prettier
• 낮은 진입 장벽
  • TypeScript
  • React & Next.js
  • Nest.js & TypeORM
  • 계층형 아키텍처 & DI
  • 테라폼 & Go
• 독립성
  • FE & BE 계층 분리
  • API 명세 기반 개발
  • 분리된 저장소
• 빅뱅 vs 점진적 개편
  • 점진적 개편 선택
• New FE, New BE
• 한 기능의 장애가 전체 서비스에 영향...

시즌 4

• 개발자: BE 8, FE 11, DevOps 4, CTO 1
• 장애 격리
• 독립적으로 운영 하는 서비스들은 다 분리한다.
• 데이터베이스 분리는 시즌5에 하자..
  • 분산된 데이터베이스로 높아지는 복잡도
  • 트랜잭션 관리 어려움
  • 기존 쿼리들의 전체 개편
• 모범답안은 알겠다, 다만
  • 기술의 가지수를 최소화
  • 2~3년을 버틸 수 있는
  • 적정 기술을 선택한다
  • ES, DDB 대신 -> MongoDB Atlas
  • 하나에만 집중하자
• 위대한 글쓰기는 존재하지 않는다. 오직 위대한 고쳐 쓰기만 존재할 뿐이다. - 엘원 브룩스 화이트 -
• 고객이 요구하는 서비스를 요구한 타이밍에 출시가 중요

 

코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes. 컨텍스츠아이오 서지연 (103호, 15:35 ~ 15:55)

• 코드 리뷰를 잘 한다는 것?
• 코드 리뷰가 길어지면... 그 결과
• 구현 하나 하나 Stack 쌓듯이
  • API endpoint -> 서버 로직 생성 -> 프론트 컴포넌트 생성
• Stacked Changes 장점
  • 코드 변경 크기 줄고, 작업의 명확성 올라가고, 리뷰 속도 빨라짐
• 구글의 Gerrit, 메타의 phabricator
• 1. Graphite
  • open-source CLI and a code review dashboard
  • 작업의 결과 공유 -> 작업자의 고민과 의식의 흐름까지 공유
• 1. 결론
  • 코드 변경 크기, 작업 명확성, 빠른 속도
  • 중요한건 공감

 

실전! 멀티 모듈 프로젝트 구조와 설계. 네이버 김대성 (105호, 16:10 ~ 16:50)

• 소개: 네이버 뮤직플랫폼팀 리더

1. "WHY" 멀티 모듈 프로젝트 구조가 중요할까요?
   • 아키텍처는 프로젝트 초기에 이루어져야 하는 일련의 설계 결정이다.
   • 아키텍처는 요소의 구조와 그 관계에 관한 것
   • 나중에 변경하기 어렵다. 리스크를 줄이기 위한 시작
   • CORE & COMMON 문제
     • Too many connections
     • NoClassDefFoundError
     • Copy & Paste
     • All Build & Deploy
       • 개발 생산성 저하
2. "WHAT"을 기준으로 멀티 모듈 프로젝트 구조를 나뉘어야 할까요?
   • CORE, COMMON 모듈은 삭제, 그래도 정말 필요한지 한번 더 고민
     • spring-core
     • commons-lang
   • BOUNDED CONTEXT - 경계나누기
     • DDD는 큰 모델을 서로 다른 BC로 나누고 상호 관계를 명시하여 처리합니다.
     • boot(SERVER), data(DOMAIN), INFRA, cloud(SYSTEM)
3. "HOW" 실전 멀티 모듈 프로젝트 구현을 해야 할까요?
   • 위 4가지 기준으로 모듈 그룹 분리
   • 문제점
     • 계속 늘어나는 모듈들 -> 복잡도 증가 -> 늘어나는 빌드시간 + ...
   • DATA -> INFRA 멀티 모듈 프로젝트 관계구현
   • BOOT -> DATA 멀티 모듈 프로젝트 관계구현
     • 서비스 레이어 구현은 어디에? 양쪽
       • 이벤트 발생 & 구독 이벤트 처리
   • CLOUD -> BOOT 멀티 모듈 프로젝트 관계구현
     • istio. Service Mesh

• RESULT
  • 콘웨이 법칙

 

지금 당장 DevOps를 해야 하는 이유. 퍼플아이오 김충섭 (Subicura) (105호, 17:05 ~ 17:25)

1. 개발과 배포를 빠르게
   • 프로젝트에서 가장 중요한 것
     • 속도/일정. 언제까지 되나요?
   • 아마존: 평균 11.7 초마다 배포
   • 어떻게 빠르게?
     • 공부 열심히 하기
     • 개발자 채용
     • 애자일 / 각종 방법론
     • MSA
2. DevOps란 무엇인가?
   • 오늘의 주제: DevOps
     • 개발과 운영의 합성어
     • 빠른 시간에 개발 및 배포하는 것을 목적
     • 도구보다는 목적과 티이밍
     • 철학 & 방법론 => 문화
   • 개발 운영 프로세스. 빌드와 배포 자동화
   • 개선 -> 도입/측정 -> 공유/전파 -> 축적
3. DevOps 도입하기
   • 조금씩 개선해보자
     • npm -> yarn
     • git clone -> git shallow clone
     • 배포 깨짐 -> docker
     • 직접 UI 테스트 -> e2e
     • 반복적인 작업 -> chatbot
     • -> 자동화, 측정, 공유, 축적
4. DevOps를 하자
   • 도입해야 하는 이유
     • 하루 10분 절약 * 1달 * 개발자 수
     • 패시브 스킬 장착
     • 인프라 지식을 배울 수 있다
     • 개발 시야가 넓어지고 더 깊이 이해할 수 있다
     • 회사 홍보와 채용에 도움이 된다
     • 잠을 푹 잘 수 있다
   • 먼저 시작하세요!

 

(레거시 시스템) 개편의 기술. 우형 권용근 (102호, 17:40 ~ 18:20)

1. 레거시 시스템 개편은 왜 일어나는가?
   • 현재는 비주류인 기술
   • 현재는 성능이 부족한 시스템
   • 새로운 요구사항을 대응할 수 없는 시스템
   • 그럼 개편은 어떻게 결정이 될까?
     • 투자자본수익률(ROI)
   • 서비스를 지속, 성장 시키기 위해 일어난다
2. 내가 경험한 개편은?
   • 2018 결제시스템 개편
     • 현재는 성능이 부족한 시스템
       • DB 파티셔닝
   • 2018 주문시스템 개편
     • 현재는 성능이 부족한 시스템, 현재는 비주류인 기술
   • 2019 가게노출 시스템 개편
     • 현재는 성능이 부족한 시스템, 현재는 비주류인 기술, 새로운 요구사항을 대응할 수 없는(어려운) 시스템
   • 2021 회원시스템 개편
     • 현재는 성능이 부족한 시스템, 현재는 비주류인 기술
3. 개편의 기술
   • 제 1장. 의존성을 한 방향으로 정리하라
     • 스파게티 의존성
       • 사이드 이펙트
     • 스파게티 의존성 발생 이유
       • 기능을 쫓다보면 어느새 발생..
     • 같은 레이어를 참조해도 역방향으로 판단
     • 사이드 이펙트 추적이 가능해짐
   • 제 2장. 변경 대상에 대한 경계를 나눈다
     • 책임과 역할이 제각각
     • 패키지나 모듈로 나눔
     • 계층에 책임과 역할을 정의
     • 개편에서 다루어야할 계층을 확보 -> 원래 소프트웨어에서 다루어야할 계층 가능성 있음
     • 변경 범위에 대한 가시성 확보
   • 제 3장. 테스트를 확보한다
     • TC 작성
     • JUnit e2e 테스트
     • 요청 비교 테스트
   • 위 3가지가 개편에만 필요한가? 유지보수하기 좋은 소프트웨어
   • 제 4장. 프로젝트 가시성 확보
     • 큰 문제를 작은 문제로 만들어 풀어나간다
     • 더 정확한 일정 예측 -> 일정에 대한 리스크 관리를 더 잘 할수 있음
     • 진행상황 공유
   • 부록 1. 도메인 이해 공유
     • 이해도가 다른 사람들이 모임
       • 서로 다르게 이해함
       • 도메인 지식 많은 사람: 부담, 도메인 지식 적은 사람: 코더가 되버림
       • 커뮤니케이션 비용 증가
     • 이벤트 스토밍
       • DDD, 전술적 설계
       • 어떤 문제를 해결해야 하는지 빠르게 알아내는 방법
       • 도메인 적은 사람들의 이해도가 올라감
       • 온라인 도구: miro
   • 부록 2. 변화를 측정한다
     • 주문수, 비용, CPU, TPS 등
     • 불확실성의 정도를 낮

 

어느 날 고민 많은 주니어 개발자가 찾아왔다. 우형 김영한 (103호, 18:35 ~ 19:15)

• 나의 개발자 커리어 이야기
  • 어릴 때 게임 폐인 -> 게임 프로그래머의 꿈
  • IT 학원 (8개월, 4~500만원), 고졸
  • 서울에서 취업 준비
  • 첫 취업. 부도난 인력 파견 회사
  • IT 학원 강사
  • SI -> 부도: 가장 힘든 시기
  • 남는 시간을 쪼개서 개발 공부
  • 다음 커뮤니케이션(카카오), SK 플랫폼
  • 우아한형제들 기술이사
    • 결제, 정산, 주문, 메인프론트 등의 레거시 -> MSA
  • 밑바닥부터 올라온 케이스
  • 개발자부터 기술이사까지 수 많은 개발자 채용, 성장
  • 인프런 16만 수강생 수. 많은 개발자 상담, 조언
  • 성장, 취업, 이직 주니어 개발자에게 조언
• 이직 - 이직 준비, 채용, 이력서, 면접
  • 이직준비 - 어떤 회사를 갈 것인가?
  • 가고 싶은 회사를 1,2,3 티어로 정리
  • 기술과 채용 확률
    • 기술 맞추기
      • 1티어 회사들 채용 사이트 - 사용 기술 조사
      • 비슷한 기술을 사용하는 2, 3티어 회사들 찾기
    • 채용 확률 높이기
      • 실무에서는 당장 사용하는 기술을 잘 다루는 경력자를 선호
      • 기술을 맞추어두면, 올라갈 확률이 올라감
  • 신입 vs 경력
    • 신입으로 취업 vs 경력직 이직
    • 3티어 -> 2티어 -> 1티어로 더 취업하기 쉬움
  • 성장: 개발, 운영, 개선 사이클
  • 타인 제품을 마들어주는 회사
    • SI, SM
  • 본인 제품을 만드는 회사
    • 서비스, 플랫폼 회사
    • 좋은 개발 경험 = 개발 + 운영 + 개선
  • 채용
    • 채용은 확률이다
      • 면접관은 사람이다. 선호하는 것이 다 다르다.
      • 기술과 성향이 맞다면 합격 확률이 높음
      • 티어가 높은 회사가 평균 기대치가 높다
    • 개발자 TO는 무제한이다 (실력있는)
      • 시장에 실력있는 개발자 부족
      • 실력이 가장 중요하다.
  • 이력서
    • 서류에서 계속 탈락
      • 아직 실력과 경험이 해당 티어에 가기에는 부족
      • 실력은 있지만 이력서 작성 방법 부족
    • 필살기
      • 기술 면접관을 낚는 마법의 단어
      • 프로그래머 = 문제 해결사
        • 문제는 풀어야 한다
        • 해결 방법이 궁금하다
      • ["문제와 해결"]
      • 문제를 기술적으로 어떻게 해결했는지 자세히 적는다.
    • 깊이
      • 스스로 깊이있게 파고 학습한 개발자들은 보통 문제를 잘 해결한다.
    • 이력서 잘 쓰는 방법도 공부해야함
    • 문제 -> 해결 포인트
  • 면접
    • 서류 통과 면접 탈락
      • 실제로 내공이 부족
      • 내가 안다는 것이 진짜 아는 걸까?
• 학습
  • 뭘 공부해야 하나?
    • 가고 싶은 회사의 기술 스택 참고
  • 학습의 3단계
    1. 학습: 강의, 책
    2. 체득: 실무 적용, 토이 프로젝트
    3. 정리: 노트, 블로그, 세미나 만들기
  • 지속적인 학습과 성장
• 시스템
  • 목표 VS 시스템
    • 목표는 달성하면 성공, 아니면 실패
    • 목표와 열정. 열정이 꺼지면 좌절하고 포기
  • 과정 자체에 충실할 필요가 있음
  • 시스템 예시
    • 퇴근 후 30분 운동, 19:30 ~ 22:30 학습, 강의 준비
  • 열정이나, 열심히 하는게 아니다. 그냥 시스템에 나를 맡기는 것
  • 시스템을 돌린다
    • 이렇게 반복한다.
    • 본인에게 맞도록 개선
  • 피드백 사이클
    • 빠를수록 좋다
    • 던진 공이 스트라이크인지 한달 뒤에 확인할 수 있다면?
    • 테스트 케이스: 빠르게 성공 실패를 확인
  • 시스템과 피드백 사이클
    • 시스템을 통한 성장 -> 이직 시도 -> 피드백 ->
  • 시스템과 성장
• 성장
  • 보통 개발자
    • 기존 방식으로 문제를 해결하려고 함
    • 3년차의 경험을 10년간 사용
  • 실력 있는 시니어로 성장하는 개발자
    • 공부하면 할수록 더 배울 것이 나옴
    • 본인이 배워야 할 것이 많다 생각함
    • 실력은 있지만 겸손함
    • 지속적인 성장, 엄청난 내공
    • 기술적인 혁신, 더 큰 도전을 즐김
    • 실력있는 시니어 개발자로 성장
  • 기술적 겸손함
  • 대나무 이야기
    • 대나무에 마디가 있는 것은 더 크게 성장하기 위함
    • 사람은 컨디션 사이클이 있다. 계속 기계처럼 할 수 없음
  • 시스템을 통해서 더 좋은 개발자로 지속해서 성장하는 것이 중요
  • 좋은 회사, 높은 연봉은 자연스럽게 따라온다.
  • 개발은 팀웍
  • 성장을 통해 주변 동료들에게 ...