운이 좋게 이번에 인프콘 참가에 당첨되어 다녀오게 되었습니다.
장소는 코엑스 그랜드볼룸이였습니다.
역시나 사람들이 엄청 많았습니다. (거의 1000~ 1500명 온다고 들었습니다.)
오프닝이 1시 시작이어서 조금 일찍 간다고 12시 20분~30분 에 도착했는데도 이미 많은 사람들이 있었습니다. (코엑스가 생각보다 커서 시간 계산을 잘못함) 인프콘의 여러 기업 부스에서 프로그램에 참여하면 선물을 받을 수 있었습니다. 일찍 갔으면 빠르게 끝낼 수 있었을 것 같았는데 제가 도착했을 때도 줄이 꽤 길었습니다. (토스는 후드티도 주는 거 같더라고요.. ㅎㄷㄷ 줄이 너무 길어서 엄두가 안 났습니다.)
정확히 1시에 형주님, 동욱님, 연희님 순서로 인프콘 오프닝 개회사를 발표하였습니다. 개회사 이후에 원하는 시간에 자유롭게 이동하면서 세션에 참가하는 형태였습니다. 저는 어떤 걸 들을지 미리 정해놔서 현장에서 크게 바꾸진 않았습니다. 이번 컨퍼런스에서 가장 좋았던 것은 아무래도 동욱, 영한님(팬이기에)을 본 게 아닌가 합니다.
제가 들은 세션은 아래와 같습니다. (제가 백엔드라서, 프론트는 듣지 않았습니다.)
- 실리콘 밸리로 떠난 비전공자 개발자의 지난 4년 회고 (한정수 님)
- 인프런 아키텍처의 과거와 현재, 그리고 미래(이동욱 님)
- 성공하는 스터디를 만드는 10가지 방법(한윤석 님)
- 실전! 멀티 모듈 프로젝트 구조와 설계(김대성 님)
- 지금 당장 DevOps를 해야 하는 이유(김충섭 님)
- (레거시 시스템) 개편의 기술(권용근 님)
- 어느 날 고민 많은 주니어 개발자가 찾아왔다.(김영한 님)
오프라인 세미나는 거의 처음이었는데 인프콘을 계기로 오프라인 세미나에 대해 긍정적인 느낌을 많이 받아서 앞으로도 많이 참여할거 같습니다. 이번 인프콘은 발표나, 이벤트등 오랫동안 빡세게 준비한거 같다는 느낌을 많이 받았습니다.
주변에 인프콘 당첨된 사람이 한 명도 없을 만큼 경쟁률이 치열했나 봅니다.(지원자만 만명이 넘었다고 하니) 이런 소중한 기회를 받은 만큼 좋은 말들을 기억, 기록하고 싶어서 모든 세션을 적으면서 들었습니다. (굉장히 힘들었습니다.)
모든 세션은 추후에 공개된다고 들었습니다 그전에 미리 제가 들은 발표 내용을 확인하고 싶으신 분은 아래 더보기를 눌러주시길 바랍니다. :)
(장문 주의, 오타 주의)
이형주 님 시작
이동욱 님 앞으로 어떤 서비스를 개발할 것인지
홍연의 님의 인프콘 즐기기
첫 번째 세션 한정수 님
- 평범한 사람이 약간 먼저 경험한 이야기
- 비전공자를 위한 개발자 취업 올인원 가이드 홍보
- 주의사랑 : 아 저사람은 저렇게 했구나 식으로 듣기
- 1년차 나무가 자랄 수 없는 콘크리트 바닥
> 클라우드 OO
- 경험했던것들 : 이상한 최종 과제
- 베트남 p2p대출 시장을 조사해서 보고서를 제출
- 일을 하지않는 cto
- 7개월간 제품 개발x
- 임금 체불
- 7개월 만에 퇴사
- 7개월간 할달받은 과제 : 게시판 crud aws공부
이직할 회사가 정해지지 않음, 집에서 집중적으로 이직 준비하고 싶었음
1년 차 때 좋았던 선택
- 학습한 내용 깃헙, 블로그 정리
- 깃과 깃헙 >>>> 코드리뷰 환경 세팅
- ==> 환경 좋지않아도 개선하려는 노력
- 컴공 전공자와 cs 기초 스터디
- 개발자 커리어 세미나 참여
- 코딩 테스트를 포기하지 않음
김남준 님 사내추천을 통해 줌 인터넷 포털 개발팀 입사
10일 만에 코테 통과한 노하우 > 강의를 참고하세요
후회되는 선택들
- 코테준비를 미리 하지 않은것
- > 국비랑 첫회사 다니면서 거의 1년을 버림
- 우아한 테크캠프 2기에 지원하지 않은것
- 더빠르게 퇴사하지 않은것
- 성장하기 어려운 환경과 아예 성장이 불가능한 콘크리트 바닥을 구분해야함
2년 차 줌인터넷
- 줌닷컴(뉴스줌, 허브줌)
- 연봉 54퍼 상승
- 줌인터넷에서 경험한것
- 신입 개발자 파일럿 프로젝트
- 서비스 설계부터 배포까지 직접
- 과도한 질문은 제한
- 오전9시 ~ 밤 11시 50분까지 진행
- 단기간에 spring vue.js를 단기간에 학습 개발 배포
- 개발 과정 노션에 기록, 공유
- 뉴스줌 개발하면서 많이 성장
- idc >> aws 이전하는 경험
- 회사 기술블로그 글 기고 amazon mq의 virtual topics를 활용한..(토스 이직에 중요한 역할)
2년 차
이직 타이밍이 좋았음 > 서비스가 안정되었기 때문
- 서비스 도메인을 정하고 이직한게 도움이 많이됨
- 돈과 직결되는게 중요
- 트랜잭션 처리, 고가용성, 내결함성
- 결제 도메인인 회사 vs 다른 도메인의 결제 파트
- 토스랑 네이버 파이넨셜 지원
- 토스 페이먼츠가 먼저 합격 소식을 받음
같은 도메인의 회사들에만 지원할 경우 좋은 점
- 경력기술서를 하나로 통일가능
- 기술면접 준비 더 깊게 가능
- 기술 면접이 비슷하게 나옴
출퇴근길 개발 읽기 / 고퀄리티 개발 컨텐츠 모음 운영한 게 잘한 선택
동기들과 개발 스터디
카카오페이 이직 / 우형 이직
넥스트 스텝 tdd & 클린 코드 강의 수강
=> 지인이 이 강의 듣고 카카오 이직
독서 프로젝트 시작
=> 개발만 공부하니 시야가 좁아진걸 느낌
후회되는 선택
- 회사 공부와 개인 공부 분리했던것
- 기획자의 요구 와 장애 대응만 함
- 개발 강의 수강 대신 회사 코드 품질 개선, 테스트 코드 추가가 더 도움됐을듯
- 레거시 코드에 대한 불만을 가진것
- 당시에는 최선의 선택이었을 수 있다.
- 불만을 갖기보다 더 개선하려고 노력 필요
- 레거시 코드 개선 경험은 기술면접에서 가치가 높음
- 개발자 업무의 절반 이상은 기존 코드 개선
3년 차 성장 vs 육아
- 연봉 전직장 대비 52퍼 인상
- 토스에서 경험한것
- 가상계좌 결제 시스템 마이그레이션
- lg플러스의 pg사업 인수, 데이콤 시절부터 이어져 온 20년 묵은 코드
- 코틀린 스프링 기반의 마이크로서비스
- cto님의 찐한 코드리뷰
- 경력도 실력도 부족한 나에게 시간을 많이 투자해 주셨음
- 회의실에서 1~4시간 코드리뷰 >>> 쉽게 경험하기 힘든 성장의 기회
너무나 뛰어난 동료들
> 개발에 올인할 자신이 없음
오전 11시 출근, 새벽 0~3시 퇴근
> 육아 중이 아니었다면 최고의 성장 환경
> 10개월 된 딸과 함께할 시간 부족
> 와이프 홀로 독박 육아
5개월 만에 퇴사
퇴사 이유
> 딸과 함께하는 시간이 필요
> 독박 육아로 지친 와이프
> 미국 회사 취업준비
- 미국 영주권 면접이 7월에 예정된 상태
> 프로젝트가 배포됨
3년 차 좋았던 선택
cto님에게 코드 리뷰를 자주 요청드린 것
담당했던 프로젝트의 배포까지 끝내고 퇴사한 것
퇴사 이후 4개월 휴식기
> 개발자로 딱 3년 일함 (3년 만의 휴식기)
> 육아 분담
> 운동 시작
> 미국 이민 준비
> 독서 삼매경
3년 차 때 후회되는 선택들
육아 난이도 망각하고 토스에 합류한 것
개발자의 길을 포기하려 한 것
- 워낙 잘하는 개발자분들이 많았음
- 나는 개발자로서 자격이 없다는 생각 시작
픽셀릭 이라는 회사로 이직
연봉 30프로 상승 (줌인터넷 2배)
- 풀 리모트 + 원하는 시간과 장소
- 비동기 커뮤니케이션
- shape up (제품 개발 프로세스)
- a 시리즈 투자 유치
- y combinator 합격
- 회사 지분 소유(RSA)
- 매년/매달 정해진 %씩 받는 구조
4년 차 좋았던 선택
6번 피벗 한 팀에 합류한 것
새로운 기술 스택(루비 온 레일즈)에 과감하게 도전한 것
> java / spring이 아니더라도 도전하자는 마인드
> 점점 재밌어짐
> 자바 스프링 방식이 무조건 옳다는 고정관념이 깨짐
초반에 시스템 아키텍처 직접 그려보고 피드백받은 것
- 이해한 부분까지만 직접 그려보는 것을 추천
- 직접 그려보면 본인이 모르는 부분을 바로 파악 가능
코드만 읽을 때보다 훨씬 빠르게 프로젝트 파악 가능
4년 차 후회되는 선택들
아직까지는 없다.
후회를 최소화하자
두 번째 세션 이동욱 님
- 인프런 아키텍처의 과거, 현재 그리고 미래
- 부재 : 적정 소프트웨어 아키텍처
- A라는 목표를 B라는 일정안에 달성하기 위해 감수하는 조건
시즌 1
- 개발자 == 대표님
- 혼자서 모든것을 다 해야 한다.
- 직접 개발은 최소화하고, 외부 자원을 최대한 활용하자
- 그래서 당시 선택한 방법이 워드프레스
> 미칠 듯이 느려지는 서비스
> 알 수 없는 데이터
> 워드프레스로 인한 기능 확장의 한계
> 직접 관리해야 하는 서버, 배포, 데이터 베이스
시즌2
- 기능은 그대로 둔채, 서비스를 직접 다시 만들자
- 백엔드 1명 프론트 1명 데브옵스 1명 대표 1명
> 문제점 : 한 명이 빠져도 개발이 가능해야 한다.
> 해결 :기술 스택 통일하자
- fe be devops를 하나의 언어로
> 낮은 러닝 커브
- jquery, funcation programming fxjs, ssr, fxdom, fxsql
> 최소 관리
- circle ci, AWS(Fargate, ECS)
결과
- 구현 코드의 최소화
- 단일화된 라이브러리
- 익순한 패턴 (서버사이드 랜더링)
- 단일 프로젝트 (풀 js스택)
- 3.5명의 개발자로 5개월만에 전체 시스템 전환 완료!
> 좋은 결말을 맞이할 줄 알았으나………
> 신규 개발자들이 채용되면서 점점 발생하는 문제들
구현 코드 최소화하다 보니
> 타입을 표현할 수 있는 방법이 없음
> 객체 리터럴
> 5개월 만에 개편하다 보니 테스트 코드가 없음
> 예측할 수 없는 함수 결과
> ide의 지원 없는 개발(리팩터링, hint)
단일 라이브러리의 문제점
> 부족한 생테계
> 대부분의 라이브러리가 react기반이라 몇 년 전 라이브러리를 사용해야 함
익숙한 패턴의 문제
> 신입 개발자들은 익숙지 않은 구조, 패턴
단일 프로젝트의 문제점
> 비효율적인 리로드, 번들링의 문제가 있었음
> 로컬 첫 실행 2분, 로컬 리로드 20초…
문제점 정리
- 신규 입사자의 높은 진입장벽
- 작업자의 낮아진 심리적 안정감
- 참을 수 없이 느려진 번들링. 리로드 속도
- 불가능한 컴포넌트 개발
시즌3
백3 프론트3 데브옵스1 / javaspring만 하던 cto 1명
심리적 안정감
> 코드 수정에 대한 자신감
> 코드레벨에서 예측
> 클래스 타입을 쓰자
> 테스트 코드 정적 분석
> eslint & prettier
낮은 진입 장벽
- 외부 개발자들이 많이 사용하는 라이브러리/구조/패턴
- typescrit
- react & Next.js
- nest.js & typeORM
- 계층형 아키텍처 & DI
- 테라폼 & Go
독립성
- fe & be 계층 분리
- api 명세 기반 개발
- 분리된 저장소
개선을 어떻게??
빅뱅 vs 점진적 개편
> 빅뱅 : 서비스 개선 멈추고 전체를 다시 만들어서 한번에 교체
> 점진적 개편 :
> 점진적 개편 선택
> 스타트업에서는 6개월이란 시간은 일반 기업의 2년에 준하는 시간
> 매년 2~3배 성장하는 서비스를 중단 없이 개편하는 경험
> 달리던 마차의 바퀴를 바꾸는 경험 필요하다고 생각
이제 남은 기능을 이관하면 되는데…
실상 : 3일 동안 2시간씩 서버가 죽는 장애
> 녹아내리는 멘탈…
한 기능의 장애가 전체 기능의 장애로 확장되는 상황
시즌4
be8 fe11 devops4 js/ts/java 아는 cto1
단일 프로젝트에 모든 하위 서비스 운영
목표 : 한 기능의 장애가 전체 장애로 이어지지 않도록 분리
> 독립적으로 운영하는 서비스들은 다 분리한다.
> 애플리케이션 서버의 메모리, CPU를 많이 점유하는 작업으로 인한 장애는 격리됨
데이터베이스 장애 격리는???
- 다음 시즌 5에……....
- 분산된 데이터베이스로 높아지는 복잡도
- 트랜잭션 관리의 어려움
- 기존 쿼리들의 전체 개편
- 비즈니스 서비스는 계속 쌓여감…
- 검색엔진, 스냅숏, 데이터 lake
- 끝나지 않은 레거시 개편
- 높아진 장애 민감도
- 다양한 요구사항
100만 회원 서비스에서 레거시를 개편하면서 postgral, redis, ddb, es를 모두 안정적으로??
> 기술의 가짓수를 최소화하자
> 가장 좋은 아키텍처/기술보다는 2~3년을 버틸 수 있는 적정 기술을 선택한다.
- DynamoDB와 같은 NoSQL이면서 ES와 같은 루씬 검색엔진 & 노리 한글 형태소 분석기
몽고 디비 atlas로 검색 엔진, data lake, 실시간 데이터 처리 등을 한 번에 해결하자
검색엔진이라는 추가 의존성
but 기존 서비스와 장애 격리된 구조
자세한 내용은 기술 블로그에서..
마무리
위대한 글쓰기는 존재하지 않는다.
오직 위대한 고쳐 쓰기만 존재할 뿐이다.
- 엘윈 브룩스 화이트
동욱님은 초안은 대충 쓰고 계속 개편한다고 하심..
3 세션 한윤석 님
- 질문 만들기
- 챕터마다 문제를 만들어 온다
- 랜덤하게 문제를 뽑아서 랜덤한 사람에게 질문을 합니다.
- 답변에 대해서 토론
- 핵심 질문에 답하기
- 무엇 왜 어떻게
- 답변에 대해서 토론을 합니다
- 답변에 대해서 정리합니다
- 강의식으로 전달하기
- 짧은 리뷰
- 스터디 범위를 훑어 보면서 공부 했던것을 떠올립니다.
- 책 같이 살펴보기
- 5분 동안 책 전체에서 내가 읽고 싶은 부분을 탐색
- 탐색한 것을 짧게 공유
- 15분 정도 읽고 싶은 부분을 읽습니다.
- 내용을 공유하고 토론합니다.
- 그룹 작게 나누기
- 한번도 말안할때도 있음
- 구글밑은 자동으로 그룹 나누는기능도 있음
- 3~4명씩 각 다른 채널로 나눠진다
- 주어진 시간동안 활동을 한다
- 다시 모여서 공유한다
- 과제
- 빈칸 채우기 퀴즈
반복 읽기 vs 빈칸 채우기(생각하면서 읽어야 함)
- 완전한 문장으로 만들기
- 리팩터링이란 무엇일까요? 에 대한 완전한 문장으로 답변하기
- > 질문을 합니다
- > 책을 보지 않고 최대한 완전한 문장으로 답변
- > 책을 보고 완전한 문장으로 만듭니다.
- 같이 서평 작성하기
생각나는 것을 쏟아내기
쏟아낸 것을 정리해야 합니다.
시간 안에 완성해야 합니다.
더 시도해 볼 것
- 리팩토링을 아는것보다 직접해 보는게 중요
- 빈 칸 채우기 + 플래시 카드를 접목해서 지속적인 암기
- 리더가 필요 없는 스터디 만들기
- 스터디내용보다는 공부하는 방법에 대해서 다루기
- 다른 회사 개발팀과 같이 스터디하기
네 번째 세션 , 김대성 님
실전 멀티 모듈 프로젝트 구조와 설계, 김대성
네이버 뮤직 플랫폼팀 리더, 바이브
멀티모듈 프로젝트를 적절하게 만드는 방법
- why 멀티 모듈 프로젝트 구조가 중요할까요
- what을 기준으로 멀티 모듈 프로젝트 구조를 나뉘어야 할까요
- how 실전 멀티 모듈 프로젝트 구현을 해야 될까요
why 멀티 모듈 프로젝트가 중요한가요?
아키텍처는 프로젝트 초기에 이루어져야 하는 일련의 설계 결정이다
아키텍처는 요소의 구조와 그 관계에 관한 것이다
위 문장을 아키텍처 -> 멀티 모듈로 바꾸어 말해보자
나중에 변경하면 어렵다 + 리스크를 줄이기 위한 시작이다.
어드민 서버 core 서버 common 서버 api서버 배치 서버
> 일 년 뒤에???
core와 common의 프로젝트가 커진다 (개발자의 중복제거 때문에 공통화하는 관습으로 생김)
위와 같은 구조의 문제점 4가지
- Too Many connections 문제
- noClassDefFoundError : 특정한 모듈이 하위 버전 라이브러리를 참조하는 경우 업그레이드 난해함
- copy & paste 문제
- 참조하는 곳이 너무 많아 일단 if else분기처리 copy&paste
- 깨진 창문 효과
- all build & Deploy
멀티 모듈 구조를 나누지 않아서 위와 같은 문제가 발생했었다
무엇을 기준으로 멀티 모듈 프로젝트 구조를 나뉘어야 할까요? (가장 중요하다 생각합니다.)
역할 책임 협력 관계가 올바른지
지속적으로 늘어나는 멀티 모듈
그러면 무슨 기준으로 나누나요
+ core, common모듈은 삭제하고, 그래도 core /common이 정말 필요한지? 한 번 더 고민하기
결론 DDD의 바운디 드 콘텍스트 (매우 중요)
DDD는 큰 모델을 서로 다른 Bounded Context로 나누고 상호 관계를 명시하여 처리합니다.
멀티 모듈 그룹 경계 나누기
서버 모듈 : 배치 어드민 api
인프라 : and vod photo billing
클라우드 : config gateway discovert aws/gcp/azure
데이터 모듈 : meta user
how 실전 멀티 모듈 프로젝트 구현을 해야 될까요?
project에서 boot / data/ infra / cloud로 그룹 분리하기
boot 멀티 모듈
- 메타, 어드민, 배치 , chart
data 멀티 모듈
- 메타, 유저, 차트 , 라이브러리
인프라 멀티 모듈
- vod, aod, photo, billing
클라우드 멀티 모듈
- gateway, discovery, config
>> 이상태로 운영하니까 문제점 발생
> 계속 늘어나는 모듈 > 복잡도 증가 > 늘어나는 빌드 시간
data > 인프라 멀티 모듈 프로젝트 관계 구현
boot -> data 멀티 모듈 의존관계
서비스 레이어 구현은 어디다가 두어야 할까요?
요약
왜 멀티 모듈 프로젝트가 중요할까요?
> 잘못 구성되면 나중에 변경하기 고통스럽다
> 프로제그 초기에 이루어져야 하는 일련의 설계 과정이다
> 개발 생산성에 막대한 영향을 미친다
무엇을 기준으로 멀티 모듈 프로젝트 구조를 나뉘어야 할까요
> 경계 안에서 의미를 가질 수 있는 그룹을 정의하는 것이 가장 중요하다(바운디드 컨텍스트)
> 역할, 책임, 협력 관계가 올바른지 다시 한번 생각한다
> 부트, 인프라, 데이터, 시스템
어떻게 실전 멀티 모듈 프로젝트를 구현해야 할까요
> 프로젝트가 커지고 있다면 다시 경계를 나누고 그 기준으로 소스 저장소를 분리한다
> 인프라 라이브러리에는 데이터 관련 구현을 지향한다
> 서비스 구현은 각자 역할에 맞게 각각 구현될 수 있다.
> 시스템 레벨 구현이 실제 서비스 애플리케이션과 밀접하게 연관되지 않도록 격리하거나 전환한다.
결론
“시스템을 설계하는 조직은 어떤 조직이든 그 조직의 소통 구조를 닮은 구조를 가진 시스템으로 설계할 것이다.”
잘설계된 멀티 모듈의 프로젝트는 다시 잘 합쳐지거나 다시 잘 쪼개 질 수 있는 프로젝트입니다.
다섯 번째 세션, 지금 당장 DevOps를 해야 하는 이유
- 개발과 배포를 빠르게
프로젝트에서 가장 중요한 것은???
> 빠르게 개발한 게 중요하다고 생각합니다. (속도/일정)
개발을 빠르게, 배포를 더 자주 하는 회사, 개발하고 배포까지 더 빠르게
일주일 > 몇 분 이내에
아마존 같은 경우는 11.7초에 한 번씩 코드를 릴리스한다 (발표 동안에도 20번은 배포했을 듯…)
어떻게 개발과 배포를 빠르게 할 수 있을까??
- 공부를 열심히 합니다.
- 개발자를 많이 채용합니다.
- 애자일 / 각종 방법론을 도입합니다.
- MSA를 도입합니다.
오늘의 주제 : DevOps를 도입한다
1. DevOps란?
빠른 시간에 개발과 배포를 빠르게 하기 위해 합치는 것
쿠버네티스 기가 막히게 공부했어요 > 이번에 도입해보면 어때요?
> DevOps : 좋은 도구를 잘 사용하는 것??????
>> 무엇보다 도구가 적절한 타이밍에 들어와야 한다.
Devops == 도구보다는 목적과 타이밍이 중요하다
데브 옵스의 목적 : 서비스를 빠른 시간에 개발/배포하는 것
개발/운영 프로세스 버전별 진화
코드 작성 > 머지 리퀘스트 > 테스트 빌드 > 디플로이 > 클라우드 > 모니터링
개선 > 도입/측정 > 공유/전파 > 축적 > 다시 개선
3. DevOps 도입하기
프로젝트는 속도가 중요하다
개발과 배포를 빠르게 하는 방법을 찾고 개선한다
데브옵스는 빠른 개발과 배포를 중요하게…(못적음)
할게 많다 >>> 조금씩 개선하자
git clone이 느린데? > shallow clone
주간 보고 정리가 오래 걸리네 > git changlog generator / gitmoji
배포가 깨지는데? > 도커
QA가 오래 걸리는데> e2e테스트
로그인하고 승인 귀찮은데? > 슬랙 챗봇 (yes버튼만 누르면 로그인)
- 자동화
- 측정
- 공유
- 축적
자동화 하자
소스 푸시 > 자동 빌드 자동 배포
부하 발생 > 오토 스케일링
배포 > 자동 테스트(e2e)
측정 하자
웹에서 로그를 검색하고 알림 설정 / 조치
각종 리소스 사용량 모니터링 / 개선
보안 검사 도구를 도입해서 보안 강화
공유하자
노하우와 프로세스를 문서화
개발에 도움이 되는 내용 공유 / 발표하자
문제 발생 > 회고 > 개선
축적하자
더 나은 방법 도입 / 개선
개선이 되고 나아진다면 OK
자연스럽게 사용
그래서 지금 당장 DevOps를 해야 하는 이유는?
개발과 배포가 10분 절약되면 > 10분 * 1달 * 개발 자수
DevOps를 도입하여 개발과 배포가 빨리 지면 남들보다 빠르게 기능 개발 가능
좋은 기능을 가진 제품을 제시간에 출시할 수 있고
서비스가 성장하고
회사가 대박 나고
나도 대박???
개인적으로 이야기하면
인프라 지식을 배울 수 있다. ( 데브옵스를 하다 보니까 인프라 전문가가 된 분이 많다)
개발 시야가 넓어지고 더 깊이 이해할 수 있다
회사 홍보와 채용에 도움이 된다
잠을 푹 잘 수 있다.
도움한다고 무조건 좋은 건 아닐 수도 있다, 오히려 느려질 수 도 있지만
나중에 쌓이면 큰 효과를 볼 수 있을 거라고 생각합니다.
여섯 번째 세션, 레거시 시스템 개편의 기술(권용근 님)
- 레거시 개편은 왜 일어나는가?
- 경험한 개편은?
- 개편의 기술
레거시 시스템 개편은 왜 일어 나는가?
레거시 시스템이란? 레거시 시스템은 낡은 기술이나 방법론.. (못 들음)
> 현재는 성능이 부족한 시스템
> 현재 구조로는 새로운 요구사항에 대한 대응을 못함
레거시 시스템은 항상 개편되어야 하는가?
- 현재는 비주류인 기술
- 시간을 더 들인다
- 성능이
- 돈을 더 투자하면 되지 않나?
- 새로운 요구사항 도입을 못하면?
시간. 비용, 인원, 생명주기, 학습비용, 비즈니스 지연, 채용. 퇴사 리스크, 한계
비용 측정을 현재 기준으로 하면 도움이 되지 않을 수 있다.
개편을 어느 시기에 하는가는 굉장히 중요하다
- 너무 늦게 하거나, 너무 일찍 하는 것이 안 좋을 수도 있다.
레거시 시스템 개편은 왜 일어나는가?
서비스를 지속, 성장시키기 위해서 일어난다.
내가 경험한 개편은?
배달의 민족 개편 경험에 대해서
결재 시스템 개편 : 데이터 베이스 파티셔닝, 호돌맨님이랑 같이
주문시스템 개편 : 데이터 모델링이 트래픽을 받을 수 없어 뜯어 고침, 향로님이랑 같이
가게 노출 시스템 개편 : 현재는 비주류인 기술(프로젝트를 새로 만듦)
회원 시스템 개편 : 현재는 성능이 부족한 시스템(AWS 한계치를 쓰고 있었음)
개편의 기술
제1장 의존성을 한 방향으로 정리하라
> 발표한 적이 있음 : 스파게티 의존성(의존성이 꼬여있음)이 주문 시스템에 있었음
- 어느 곳에서 문제 발생할지 측정하기 어려움
스파게티 코드는 왜 발생했을까?
> 재사용성으로 인해 다른 service를 참고함
> 기능을 쫒다보니 스파게티 의존성이 생김
스파게티 코드는 어떻게 풀 수 있을까
- 의존성을 한 방향으로 정리하라
- 의존의 깊이 설정
- 같은 층을 의존하는 것도 다른 방향
> 사이드 이펙트를 추적할 수 있게 됨
- 변경 대상에 대한 경계를 나눈다.
- 책임과 역할이 제각각
- 변경 범위를 파악하기 어렵다
- 패키지나 모듈로 나눌수 있다.
> 개편에서 다루어야 할 계층을 확보
> 계측의 책임과 역할 분리/통합
무엇을 얻을 수 있는가?
> 제각각의 책임과 역할을 적절히 분리하고 모았더니
> 변경 범위에 대한 가시성을 확보하였다
- 제3장 테스트를 확보한다
- 개편할때 테스트를 작성하는것은 현실적으로 어렵다
- 가게 노출시스템 개편할때 언어, 프레임워크, 디비 개편할때
- 회원 시스템
무엇을 얻었나?
변경해도 괜찮다는 안정감
제1장 의존성을 한 방향으로 정리하라
> 정돈된 의존성
제2장 변경 대상에 대한 경계를 나눈다
> 책임과 역할이 명확한 계층과 객체
제3장 테스트를 확보한다
> 안정감
>>> 꼭 개편하지 않더라도 유지보수하기 좋은 소프트웨어인지 확인하자
제4장 프로젝트 가시성 확보
큰 문제를 작은 문제로 만들어서 풀어나간다 > 더 정확한 일정 예측이 가능해진다
해야 할 일들을 가시화하면 더 좋아진다
> 일정에 대한 리스크를 더 잘 관리할 수 있다.
해야할 일들을 엑셀로 문서화하였음
> 일정을 관리할 수 있음
> 서로 뭐 하고 있는지 알 수 있음
> 장기화될 때 진행상황을 지표화할 수 있었음
>>> 이해관계자가 이 프로젝트를 후원하기 좋아진다.
부록 1 도메인 이해 공유
사람마다 도메인 이해 수준의 차이가 있다
도메인이란 : 주문 시스템 개편이라면 주문이라는 자체에 대한 이해
주문 시스템을 개편할 때
> 일을 하다가 도메인을 잘 모르는 사람은 도메인도 이해하는데 오래 걸리고
> 도메인을 잘 모르는 사람은 의사결정 과정에 참여하기 어려움
>> 모두가 힘들어짐
추천 방식 : 이벤트 스토밍 방식(tdd의 전술적 설계과정)
>> kcd 2020 발표 참고하기
이벤트 스토밍은 소프트웨어 프로그램 도메인에서 무슨 일이 일어나고 있지 빠르게 알아내기 위한 워크숍 기반 방법입니다.
부록 2 변화를 측정한다
측정이라는 것은 어떠한 관찰/수단을 이용하여 우리가 살펴보는 ‘무엇’에 대한 불확실성의 정도를 낮추는 행위 + 공유
나쁜 지표가 나와도 무조건 나쁘지 않다고 생각 어떤 거와 트레이드오프 했는지가 중요
>>> 기꺼이 나와 내 동료들에게 좋은 유산이 될 것이다.
>>> 우리 모두 개편을 잘할 수 있다.
마지막 세션 김영한 님
+ 개발자 커리어 이야기
+ 이직
+ 학습
+ 시스템
+ 성장 순으로
개발자 커리어 이야기
게임을 너무 좋아함 > 프로게이머는 안될 거 같고 게임 프로그래머가 되자
>> 좋은 컴퓨터를 샀는데 일 년 동안 게임을 함
전역 후 피자배달 , It학원 등록, 고졸
> 마감을 하면 택시비가 나와서 택시 안 타고 걸어감
> 8개월 동안 학원 열심히 다님
서울에서 취업 준비
첫 취업 부도 난 인력 파견 회사
> 월급이 밀림
IT학원 강사가 됨
> 자바 스프링 JSP를 가르침
> 그냥 걸어만 가는데 커리큘럼이 머릿속에서 생각남
>> 어려운걸 쉽게 설명하는 강점이 있구나
학원강사만 할 수 없으니 SI회사 취업
퇴근 시간 항상 10시 11시
> 이렇게는 못살겠다는 생각 이듬
>> 결정적으로 부도남 (3달 월급 밀림)
>>> 이때 가장 힘든 시기
목표가 생김 > 네카라쿠배
> 실직적으로 먼산…
>> 계속 한 단계씩 올라가면 되지 않을까?
>>> 남는 시간을 쪼개서 개발 공부
서비스 기술 스택 공부, 버스/지하철에서 공부, 주말에 공부
>> 결국 다음 커뮤니케이션 합격(카카오) - 개발 인생에 가장 행복함
분위기가 너무 좋음(아침에 커피 마시면서 시작)
저녁 6시에 칼퇴함
sk planet, 우형이직
> 레거시를 MSA로 바꾸는 일을 함
밑바닥부터 올라온 케이스
> 개발자부터 기술이사까지 수많은 개발자 채용, 성장
인프런 16만 수강생 수많은 개발자 상담, 조언을 함
성장, 취업, 이직 주니어 개발자에게 조언을 해보겠습니다.
이직
어떤 회사를 갈거다
가고 싶은 회사를 1,2,3 티어로 정리해라
1 티어는 : 언젠간 가고 싶은 회사
2 티어 : 1 티어보단 약하지만 가고 싶은 회사
3 티어 : 2 티어보단 아쉽지만 취업을 해야 하니까
기술과 채용 확률
기술 맞추기
- 1 티어 회사들 채용 사이트 - 사용 기술 조사
- 비슷한 기술을 사용하는 2,3 티어 회사들 찾기
채용 확률 높이기
- 실무에서 당장 사용하는 기술을 잘 다루는 경력자를 선우
- 기술을 맞추어 두면, 3티어 회사에 입사해도 경력을 쌓아서 1티어에 갈 확률이 높아짐
신입으로 취업 vs 경력 이직
+ 1티어 회사는 신입으로 취업이 10배는 더 어려움
+ 일단 3티어 회사로 취업
+ 그게 안되면 개발 회사로 우선 취업
+ 3티어 > 2티어 > 1티어으로 더 취업하기 쉬움
이직 준비 - 성장/연봉의 관점
+ 성장 : 개발/운영 개선 사이클이 있는 회사
개발해주는 회사 vs 자기 제품을 개발하는 회사
타인을 제품을 만들어주는 회사 : SI, SM
본인 제품을 만들어주는 회사: 서비스, 플랫폼 회사
- 내가 만든 코드를 내가 운영하고 개선
- 트래픽이 많으면 더 좋음
- 실력에 따른 기여도가 크고 초과 연봉 가능
채용 2가지
- 채용은 확률이다
- 개발자 TO는 무제한이다(실력이 있는)
채용은 확률이다
예를 들어서 여러 개발자들이 다음 회사에 지원했다. 결과는??
> 네카라쿠배인, 2 티어 1곳
> 그때그때 다르다
> 2티어 회사만 합격
> 네카라쿠배인 합격하고 2티어 회사 불합격
채용은 확률이다
+ 같은 사람을 여러 명이 면접을 봐도 서로 합격 불합격이 갈림
+ 면접관은 사람이다. 면접관마다 선호하는 것이 다르다
+ 기술 : 자바, 스프링, jpa
+ 성향 : 기술 경험해본 사람을 뽑고 싶어 함 vs 성장 가능성이 있는 사람을 뽑고싶어함
+ 기술과 성향이 맞다면 합격 확률이 높음
자바, DB의 강점
+ DB 선호 면접관이면 합격
+ 스프링, JPA 선호 면접관이면 탈락
자바 스프링이 관점
+ 자바, 스프링 선호 면접관 O
+ DB선호 면접관 걸리면 탈락
티어가 높은 회사가 평균 기대치가 높다
+ 개발자의 실력과 깊이가 점점 더 중요
+ 사용자
+ 트래픽
+ 돈
+ 개발자 기여
- 수익, 장애
개발자 채용 TO는 무제한이다(실력 있는)
개발자 채용 전쟁
+ 과거 : TO 1자리를 두고 여러 명의 개발자가 경쟁
+ 현재 : 좋은 개발자 1명을 두고 여러 회사가 경쟁
+ 1티어 회사들도 TO가 거의 무제한이다
+ 시장에 실력 있는 개발자가 부족
+ 실력이 가장 중요하다.
이력서
+ 아직 실력과 경험이 해당 티어에 가기에는 부족
- 기대치를 낮추고 회사 티어를 낮추어야 한다
- 학습과 경험을 더 쌓아야 한다
+ 실력은 있지만 이력서 작성 방법 부족
- 나쁜 케이스 : 프로젝트만 나열
- 이력서 잘 쓰는 방법도 찾아서 공부해야 함
이력서 - 필살기
기술 면접관을 낚는 마법의 단어
>> 문제와 해결
Solving problems is the core of computer science
프로그래머 == 문제를 푸는 사람
프로그래머의 뇌?
+ 문제는 풀어야 한다
+ 해결방법이 궁금하다
“이 프로젝트 안에서 이러한 문제가 있었는데 어떤 식으로 풀어서 해결했다.“
> 굉장히 자세히 적어야 함
문제를 기술적으로 어떻게 해결했는지 자세히 적는다.
무슨 플젝을 했다 했다 했다는 하나도 중요하지 않다.
그 과정을 굉장히 자세하게 적는다.
깊이
+ 기술적으로 깊이 있는 개발자를 선호한다.
+ 깊이라는 것은 하나만 파는 게 아니라 깊이 파기 위해 그 주변까지 파고 들어가야 한다.
+ 스스로 깊이 있게 파고 학습한 개발자들은 보통 문제를 잘 해결한다.
면접관이 기술적으로 계속 깊이있게 질문해서 언젠간 모를 때까지 물어볼 수도 있다
이력서 잘 쓰는 방법도 공부해야 함
+ 겸손도 중요하지만, 본인 마케팅도 중요함
+ 당신이 뭘 잘하는지 구체적으로 잘 적어야 상대가 알 수 있다.
+ 면접관 관점에서 생각
문제 -> 해결 포인트
+ 어떤 문제가 있었다 -> 기술적으로 어떻게 해결했다
+ 이런 것을 통해 나의 기술적 깊이를 보여주어야 한다.
+ 이게 바로 면접에서 물어보는 낚시가 된다. 내가 준비한 필살기를 물어볼 확률이 높다.
서류 통과 면접 탈락
+ 실제로 내공이 부족
+ 내가 안다는 것이 진짜 아는 걸까?
- 모 개발자의 스프링 강의를 다 들었는데?? 그렇다고 정말 스프링을 잘 아는 걸까
- 학습 -> 체득 -> 정리
+ 면접 시간은 짧다.
- 내가 아는 것을 정리해서 상대박에게 잘 설명할 수 있어야 한다.
학습
+ 궁극적으로 가고 싶은 회사의 기술 스택을 참고
+ 채용 공고에 다 나와 있음
+ 목표로 하는 회사에서 사용하는 기술 학습
+ 서비스, 플랫폼 백엔드
학습의 3단계
- 학습 : 강의. 책
- 체득 : 실무 적용, 토이 프로젝트 >> 이 단계를 꼭 거쳐야 한다.!!!!!
- 정리 : 노트, 블로그, 세미나 만들기
- 이직할 생각이 있으면 정리를 해야 한다.
- 짧은 면접시간 안에 대답을 해야 한다.
- 면접관 : DI의 장점이 무엇인가요?
- 학습만 한 사람 대답 못함
- 체득까지 간 사람 대충은 대답
- 정리한 사람 : 설명이 됨 (면접관이 놀람, 똑똑해 보임)
최근에 전원 합격 나온 사람들 보면 정리의 단계까지 간 사람들 임
강의를 들었다는 게 중요한 게 아니다 > 체득하고 정리하는 게 중요하다
학습을 통해 나의 레벨을 높이고 다시 도전한다
지속적인 학습과 성장
+ 지속해서 학습하고 지속해서 성장하려면?
+ 이런 과정을 삶 속에서 지속하려면?
+ 마라톤 : 개발자는 꾸준히 공부해야 한다
시스템을 만들어야 한다
목표 vs 시스템
목표??
이번 달까지 영어 점수 100점을 만든다
이번달까지 모 개발자의 스프링 강의들 다 듣는다
목표는 달성하면 성공, 아니면 실패
열정을 앞세워 목표를 준비하다 포기
열정이 생긴다 > 목표를 잡는다 > 실패한다 > 좌절한다 > 포기한다. 반복
열정은 불쏘시개 같은 것?
목표의 성공, 실패가 아닌 과정에 충실해야 한다 >> 시스템
시스템(하루 3끼 밥을 먹는 것)
시스템 루틴
- 퇴근 후 30분 운동, 19:30 ~ 22:30강의 준비
-그냥 이 시간에 앉아서 하는 것
-열정이나 열심히 하는 게 아니다 그냥 시스템에 나를 맡기는 것
김연아 님
무슨 생각하면서 스트레칭을 하세요?
> 무슨 생각을 해 그냥 하는 거지..
시스템을 돌린다
+ 이렇게 반복한다
+ 시스템도 본인에게 맞도록 개선이 필요하다
+ 시스템을 통해 지속해서 성장 > 개발 역량 상승 > 자연스럽게 이직 확률 증가
피드백 사이클
+ 피드백은 빠를수록 좋다
+ 야구선수의 공던지기 연습
+ 던진 공이 스크라이크에 몇 달 뒤에 알 수 있다면??
+ 테스트 케이스의 좋은 점 : 빠르게 성공 실패 확인
면접을 자주 보는 개발자가 더 빨리 좋은 회사에 취업, 서비스 회사에서 더 큰 성장
완벽하게 준비되고 면접 보는 개발자가 : 준비 과정에서 본인이 어떤 것이 부족한지 인지하기 어렵다
시스템과 피드백 사이클
+ 시스템을 통한 성장 > 이직 시도 > 피드백
시스템과 성장
+실무에서 업무시간 이후에 학습하는 개발자가 그렇게 많지 않음
+시스템으로 매일 3시간씩 학습 == 1년 1000시간 학습
성장
+ 진짜 실력 있는 시니어로 성장하는 개발자, 그렇지 못한 개발자 차이점
+ 개발자 A : 본인이 매우 잘한다 생각
+ 개발자 B : 본인이 아직 부족하다 생각
시니어 입장에서 개발자 A는 보통의 개발자, 개발자 B는 가장 뛰어난 개발자
보통 개발자
+ 주니어 3년 정도 되면 대충 업무 굴러가는 게 보임
+ 더 이상 공부할 것이 없다 생각함
+ 업무를 잘하니 본인이 잘한다고 생각
+ 성장이 멈춤
+ 혁신이 어려움, 우물 안 개구리
실력 있는 시니어로 성장하는 개발자
+ 공부하면 할수록 더 배울 것이 나옴
+ 본인이 배워야 할 것이 많다 생각함
+ 실력은 있지만 겸손함
+ 지속적인 성장, 엄청난 내공
+ 기술적인 혁신, 더 큰 도전을 즐김
+ 실력 있는 시니어 개발자로 성장
>>> 기술적 겸손함이 있어야 한다.
대나무 이야기
> 대나무에 마디가 있는 것은 더 크게 성장하기 위함
> 사람은 컨디션 사이클이 있다. 계속 기계처럼 할 수 없음
> 마을을 다지고, 삶의 방향과 시스템을 점검하는 시간이 필요, 우리는 사람입니다.
> 저는 3개월에 한 번 정도 산에 가거나, 좋은 카페를 간다
마지막으로
진짜 하고 싶은 이야기
시스템을 통해서 더 좋은 개발자로 지속해서 성장하는 것 자체가 중요하다!!
좋은 회사, 높은 연봉은 자연스럽게 따라온다.
그리고 개발은 팀워크이다.
> 지금은 혼자서 개발할 수 있는 시대는 끝났다.
성장을 통해 주변 동료들에게 좋은 기술 리더십과 좋은 영향력을 발휘했으면 좋겠다
성장을 통해 주변 동료들에게 인정받고 함께 일하고 싶은 개발자로 남는 것!
'세미나' 카테고리의 다른 글
| YOUTHCON'22 (1) | 2022.12.31 |
|---|---|
| YOUTHCON'21 요약 (0) | 2021.12.19 |
| [OKKY 7월 세미나] 개발자에게 좋은 이직/퇴사를 위한 꿀팁 (0) | 2021.07.25 |
| SLASH 21 컨퍼런스 (0) | 2021.05.01 |
| [2월 우아한테크세미나] 우아한 스프링 부트 (0) | 2021.04.04 |
