가을 타나 봐
7월 15일부터 10월 15일까지, 3개월 간 혼자서 진행해 오던 사이드 프로젝트를 잠정 중단했다.
해당 프로젝트를 앞으로도 혼자서 3개월은 더 빡세게 개발해야 겨우 배포할 수 있겠다는 생각이 들었고,
그렇게 배포를 한다 한들 내 학습 로드맵, 진로 방향성에 큰 호용성이 있는 것 같지 않다는 판단을 했다.
그래서 프로젝트 잠정 중단이라는 결정을 내리게 되었다.
뭐, 사이드 프로젝트에 대한 더 자세한 이야기는 이번 달 월간 회고에서 다뤄보면 좋을 것 같다!
아무튼, 사이드 프로젝트를 중단하고 나서 앞으로는 개발 공부를 어떻게 진행해야 할지,
학습 로드맵을 먼저 바로 잡아야겠다는 생각을 하게 되었다.
그러다 문득, 예전부터 인프콘 다시보기를 정주행 하려고 했던 것이 기억나서 작년 것부터 인프콘 정주행을 하기로 했다.
사이드 프로젝트도 말아먹고 학습의 방향감을 잃은 지금, 모처럼의 휴식 겸 마음을 환기시키는 시간을 갖기로 했다!
"특히" 인상 깊었던 세션들
온라인 다시보기 영상으로 컨퍼런스를 보니까 좋은 점은 역시,
모든 세션들을 하나하나 빠짐 없이 들여다보고, 잠시 멈춰둔 채 메모도 하고,
소란스럽지 않은 환경에서 집중하고 경청할 수 있었다는 점이다.
모든 세션들을 다 집중해서 들었기 때문에, 나에게 특히 더 도움이 되는 세션 5개를 가려낼 수 있었다.
이 5개 외의 다른 세션들이 나빴다는 것은 결코 아니다.
다만 지금의 내가 앞으로의 개발 학습 방향을 잡아 나가기에 더할 나위 없이 좋았던 5개의 세션이 있었던 것뿐이다.
해당 세션들을 정리해 보자.
(레거시 시스템) 개편의 기술
배달 플랫폼에서 겪은 N번의 개편 경험기
우아한형제들 권용근
- 개편은 어떻게 결정되는가?
- ROI(투자자본수익률)에 따라 결정된다!
- 개편 = 서비스를 지속, 성장시키기 위한 것
- 기존 시스템 유지보수 비용 VS 개편 비용
- 개편을 어느 시기에 하는지, 그 타이밍이 중요
- 의존성을 한 방향으로 정리하라
- 의존성의 깊이로 층을 만들자
- 변경 대상에 대한 경계를 나누자
- 책임과 역할이 명확히 분리된 계층과 객체
- 도메인 계층, 인프라스트럭쳐 계층 등으로 명확히 분리
- 테스트를 확보하라
- 개편 전 기존의 테스트 케이스는 최대한 재사용
- 개편에 대한 안정감 부여
- 프로젝트 가시성을 확보하라
- 일정에 대한 리스크 관리를 위해 해야 할 일을 가시화하고 문서화
- 이해관계자를 설득하고, 후원을 받기에 좋음
- 부록. 도메인 이해 공유
- 도메인 이해 수준이 낮으면 이해하기에 급급하고, 의사결정 참여가 어려움
- 도메인 이해 수준이 높아도 많은 것을 떠안게 되어 큰 부담을 느끼게 될 수 있음
- DDD에 나오는 전술적 설계 이벤트 스토밍
- 소프트웨어 프로그램 도메인에서 무슨 일이 일어나는지 빠르게 알아내기 위한 워크샵 기반의 방법
- 도메인의 요소 하나하나를 가시화하는 과정을 거침
- 모든 구성원이 비즈니스 개선에 도움이 될 수 있도록 기여할 수 있음
사실 이 세션을 듣기 전에 세션 제목의 '레거시'라는 단어를 보고 딱히 와닿지 않는 내용일 것이라 생각했다.
하지만 정반대였다.
이 세션은 레거시를 개편하는 데에 필요한 모든 것을 알려주면서,
또 한 편으로는 이 과정을 통해 얼만큼 많은 것들을 배우고 성장할 수 있을지를 넌지시 알려주었다.
모든 시스템은 언젠가 레거시가 되고, 계속 사용되는 시스템이라면 개편이 필요한 시기가 올 것이다.
그러니 레거시를 개편하게 되는 날이 오면 오히려 성장의 기회로 삼아보는 것은 어떨까.
개발자의 셀프 브랜딩
라프텔 김민준 (velopert)
- 개발자 셀프 브랜딩
- 색깔 있는 개발자가 되자!
- 재밌는 것, 잘하는 것, 추구하는 것이 무엇인가?
- 나를 기억할 수 있는 심볼과 로고를 만들자
- 가장 중요한 것은 꾸준함
- 셀프 브랜딩을 통해 얻을 수 있는 것
- 수익보다는 더 많은 사람들에게 주는 영향력을!
- 채용과 이직의 기회
- 좋은 동료를 찾을 수 있는 기회
- 피드백과 큰 동기부여
- 팔로워가 생기면 내 프로젝트를 쉽게 알릴 수 있음
- 좋은 컨텐츠를 만들기 위해 생각하면 좋은 것들
- 처음에는 TIL 정리도 좋음
- 나중에는 "독자"에 대해서 생각하자!
- 독자라면 좋아할 글 선정
- 나만 다룰 수 있는 주제 선정
- 독자들에게 이야기해 준다는 마음으로 글을 쓰자
좋은 개발 컨텐츠를 만들면 어마어마하게 긍정적인 일들이 생긴다.
개발자의 셀프 브랜딩! 사실 예전부터 내가 크게 관심을 갖고 있던 주제이다.
독특하고 확 튀는 것을 좋아하는 나로서는 그야말로 이루고 싶은 과업이랄까.
하지만 브랜딩에 앞서 어떠한 영향력을 설파할 수 있을지 몰라서 전전긍긍하고 있는 실정이다.
이 세션에서 알려주는 해답은 사실 간단하다.
꾸준함!
더 많은 사람에게 도움이 되고 싶다는 마음으로 차근차근 나만의 컨텐츠들을 만들어보고,
더 많은 커뮤니티에 참여해봐야 한다.
어느 날 고민 많은 주니어 개발자가 찾아왔다
성장과 취업, 이직 이야기
우아한형제들 김영한
- 가고 싶은 회사들을 1, 2, 3 티어로 정리하라
- 1티어 = 네카라쿠배
- 2티어 = 1티어 급은 아니지만 정말 가고 싶은 회사
- 3티어 = 아쉽지만 취업이나 이직을 꼭 해야 하니까 가는, 지금보다는 나은 환경
- 우선 1티어 회사에서 사용하는 기술들을 조사해라
- 비슷한 기술을 사용하는 2, 3티어 회사들을 찾아라
- 회사에서는 당장 실무에 사용되는 기술을 잘 다루는 경력자를 선호하기 때문
- 일단 3티어로 취업한 뒤 업그레이드를 해나가자
- 이직하기 좋은 회사
- 엔지니어가 개발, 운영, 개선 사이클을 다 경험해 볼 수 있는 회사
- 이력서
- 서류에서 떨어진다 = 티어에 못 미친다 OR 이력서 작성 방법이 부족하다
- 이력서 잘 쓰는 방법도 공부해야 한다
- 프로그래머는 문제 해결사이므로, 문제를 기술적으로 어떻게 해결했는지 자세히 적어라
- 기술적으로 깊이 있는 개발자 선호
- 하나만 파는 게 아니라, 그 주변까지 파고 들어가야 한다
- 깊이 파고 학습한 개발자들은 보통 문제 해결을 잘 함
- 면접
- 면접에서 떨어진다 = 내공이 실제로 부족하다
- 내가 이걸 진짜로 알고 있는 것인지 고민해 보자
- 시스템
- 시스템 = 하루 3끼 밥을 먹는 것
- 목표는 열정이고, 열정은 불쏘시개 같은 것
- 열정 대신 꾸준히 지속되는 시스템에 의존하자
- 성장
- 빠른 피드백 사이클이 중요
- 테스트 케이스와 같이 빠르게 성공과 실패를 확인하자
- 시스템을 통한 성장 → 이직 시도 → 피드백 → 사이클
- 시스템에 따라 매일 3시간씩 공부 → 1년에 1,000 시간 → 이렇게 하면 언젠가 1티어 회사에 충분히 갈 수 있음
- 주니어 3년 차에 조심
- 대충 업무 굴러가는 게 보여서 본인이 잘한다고 생각할 수 있음
- 이럴 때일수록 성장이 멈추지 않기 위해 공부해야 함
- 기존 방식에 익숙해지면 3년차 경험을 10년 동안 반복한다
- 공부는 하면 할수록 배울 것이 더 나온다 → "기술적 겸손함"
- 빠른 피드백 사이클이 중요
- 휴식
- 대나무가 마디를 만들면서 쉬듯이 컨디션 사이클을 지키자
- 삶의 방향과 시스템을 점검하는 시간이 필요
시스템을 통해서 더 좋은 개발자로
지속해서 성장하는 것 자체가 중요해요.
좋은 회사, 높은 연봉은
자연스럽게 따라오는 거예요.
가타부타 말이 필요가 없는 김영한 님의 세션이었다.
사실 예전에 유튜브 영상으로 한번 봤지만 다시 봐도 너무 좋았다.
학습 로드맵을 다시 정하기 위해 인프콘 정주행을 하고 있는 만큼,
열정 대신 시스템이라는 주제에 다시 한 번 더 깊이 공감했다.
AWS로 알아보는 서비스 아키텍처의 변화와 진화
From zero to hero
LG U+ 연구위원 송주영
- 아키텍처란?
- 아키텍처 = 좋은 아이디어를 얼만큼 빠르게 구현하고 적용시킬 수 있는가?
- 사람의 규모가 커진다고 속도가 빨라지는 것이 아니고, 아키텍처가 필요하다
- 삼성의 MSA 경험
- 삼성에서 매년 나가는 제품들은 3~4억 개
- 이 제품들을 관리하는 서버의 크기는 어마어마함 → MSA는 선택이 아닌 필수
사실 이 세션은 경험담 위주여서 이런 식으로 정리하기에는 마땅치 않다.
하지만 정말이지 그 경험담에 압도되는 세션이었다.
이 세션에서 얘기하는 것은 AWS Container Hero 송주영 님의 2011년부터 2022년까지의 경험담이기도 하면서,
AWS 클라우드 환경이 진화하는 과정이기도 하다.
치열하게 고민하고 성장해 나가면서, 나도 저렇게 멋진 경험들을 쌓아나가고 싶어졌다.
인프런 아키텍처의 과거와 현재, 그리고 미래
리스크 기반의 적정 소프트웨어 아키텍처
인프랩 이동욱 (향로)
- 적정 소프트웨어 아키텍처
- A라는 목표를 B라는 일정 안에 달성하기 위해 감수하는 제약 조건
- 시즌 1
- 개발자 == 대표님
- 혼자서 모든 걸 하기 위해 외부 자원을 최대한 활용
- PHP, jQuery로 만들어진 워드프레스 호스팅 서비스 1대
- 회원 수 10만이 되면서 서버가 느려졌음
- 시즌 2
- BE 1 / FE 1 / DevOps 1 / 대표 1
- 한 명이 빠지면 개발이 가능하도록 해야 함
- 그래서 기술 스택을 통일
- CDK - JS / 순수 함수형 Fx 시리즈 / AWS ECS Fargate, RDS, Circle CI
- 구현 코드 최소화, 라이브러리 단일화, 익숙한 패턴, 단일 프로젝트
- 결국 3.5명이 5개월 안에 전체 시스템 전환 완료
- 하지만 신규 개발자에게는 익숙지 않은 구조
- 시즌 3
- BE 3 / FE 3 / DevOps 1 / CTO 1
- 코드 수정에 대한 자신감, 진입 장벽 낮추기, 독립적 개발
- Class & Type, 테스트 코드, 정적 분석, eslint & prettier
- TypeScript, React, Next, Nest, TypeORM, Terraform
- FE & BE 계층 분리, API 명세
- 빅뱅 방식 대신 점진적 개편 방식을 채택
- 빅뱅 = 서비스 개선을 멈추고 전체를 다시 만들어서 한 번에 교체 (약 1년 소요)
- 점진적 개편 = 서비스 개선과 시스템 개편 병행, 기능을 그룹별로 이관 (약 2년 소요)
- 스타트업의 6개월은 일반 기업의 2년에 준하기 때문에
- 팀원들에게 달리는 마차의 바퀴를 바꾸는 경험을 통해 200 ~ 300% 성장하는 경험을 주었음
- 하지만 3일 간 2시간 씩의 장애가 발생
- CTO의 멘탈이 아이스크림처럼 녹았음
- 한 프로젝트의 문제가 다른 프로젝트에도 영향을 끼치는 문제
- 시즌 4
- BE 8 / FE 11 / DevOps 4 / CTO 1
- 시스템 간의 연관성 때문에 문제가 발생하므로 장애를 격리해야 한다
- MSA를 할 순 없지만 독립적으로 운영하는 서비스들은 분리
- 끝나지 않은 레거시 개편 + 높아진 장애 민감도 + 다양한 기능 요구사항
- 사실 알려진 모범답안은 Elasticsearch와 DynamoDB를 활용하는 것
- 하지만 100만 회원 서비스에서 많은 요소들을 수준 높게 관리하는 것은 사실상 불가능
- 기술의 가짓수를 줄이자!
- 2~3년은 버틸 수 있는 적정 기술 선택
- Elasticsearch, DynamoDB 대신 MongoDB Atlas 선택
- 하나의 기술로 검색 엔진, Data Lake, 실시간 데이터 처리를 한 번에 해결
- 이벤트 드리븐 아키텍처 설계
위대한 글쓰기는 존재하지 않는다.
오직 위대한 고쳐 쓰기만 존재할 뿐이다.
- 엘윈 브룩스 화이트
마치 내가 인프랩에 있었던 것 마냥 인프랩의 성장기를 쭈욱 따라가 볼 수 있는 세션이었다.
서비스가 어떤 방식으로 발전해 가는지를 한눈에 확인할 수 있어서 도움이 많이 되었다.
특히, 맞닥뜨린 문제를 해결하기 위해 기술 스택을 선정하는 과정이 너무 흥미로웠다.
역시 무작정 많은 기술들을 다 도입하기보다는 상황에 맞는 적정 기술을 선택하는 것이 중요하다는 것을 깨닫게 해 주었다.
테스트! 테스트! 테스트!
사실 인프콘 2022의 28개에 달하는 세션들 중 '테스트'를 메인 주제로 하는 세션은 한 개 밖에 없었다.
그럼에도 불구하고 나는 "테스트"라는 단어를 각종 세션들로부터 숱하게 들을 수 있었다.
"다른 건 몰라도 e2e 테스트는 꼭 해봐야겠다고 느꼈다"거나,
"테스트를 통해 개편에 대한 안정감을 확보했다"거나 하는 말들이 정말로 꾸준히 나왔다.
솔직히 말하자면 나는 회사에서 요즘 테스트 코드를 잘 작성하고 있지 않다.
그래서 이번 인프콘 2022 정주행을 하는 동안 상당히 뜨끔뜨끔하게 되는 느낌을 많이 받았다.
나를 믿지 말고, 테스터를 믿지 말고, 테스트 코드를 믿어야 한다.
앞으로 현업에서나 개인 학습에서나 커뮤니티에서나 테스트 코드를 작성하는 습관을 꼭 안착시켜야겠다!
우선 내가 할 수 있는 범위 안에서 최선의 것을 하자
이번 인프콘 2022 정주행을 통해 깨달은 값진 선물이다.
세션을 진행해 주시는 분들이 소개해 주는 시스템 구조를 들여다보면,
사실 내가 알지도 못했던 어떤 현란한 기술 스택들, MSA 같은 복잡한 아키텍처 같은 것들이 들어있지는 않았다.
동료들이 서로 이해하지도 못하는 정교하고 복잡한 아키텍처를 만드는 것보다 더 중요한 것은 지속 가능성이었다.
단순한 3 tier 아키텍처를 만든다 하더라도
그 안에 테스트 코드가 얼마나 견고하며 지속 가능한 코드를 가지고 있는지를 생각해야 한다.
그러니 어렵고 복잡한 것들을 배워 나가려고 하기보다는 단순하지만 견고한 것을 만들고 개선시켜야 한다.
어떤 것이든 만들어 놓고 개발 → 운영 → 개선 사이클을 경험해 보는 것이 중요하다.
당장 해야 할 것들!
처음에 내가 인프콘 정주행을 하면서 학습 로드맵을 정한다고 하지 않았는가.
물론 인프콘 2023도 정주행을 할 것이지만 그전에 잠시 이번 인프콘 2022를 통해 배운 것들을 정리해 보고 넘어가야 한다.
아래의 것들을 먼저 해놓고 다시 인프콘 2023을 정주행 해야겠다.
- 1티어, 2티어, 3티어 회사들을 선정하자
- 선정한 회사의 JD를 살펴보며, 앞으로 어떤 기술 스택을 학습할 것인지 로드맵을 정하자
- 이력서를 업데이트해놓자
- 커뮤니티에 참여하자
'Essay > Conference 후기' 카테고리의 다른 글
INFCON 2023 다시보기 (1) | 2023.11.19 |
---|---|
Games on AWS 2023 (0) | 2023.10.24 |
AWS Summit Seoul 2023 (0) | 2023.05.04 |
Games on AWS (0) | 2022.10.26 |
이게 무슨 일이야! 컨퍼런스 (0) | 2022.04.01 |