주니어개발자의 2022 인프콘 후기

올해도 연말이 되니 개발자 컨퍼런스가 많이들 열리는데,

단순히 콘서트처럼 보기에는 너무 가볍게 지나갈 것 같아서 올해도 역시 관심이 있던 세션을 간단하게 정리해보려고 한다.

그리고 나중에 생각날 때 내가 참고하려고 정리해두는 목적도 있다.

 

그 첫 번째는 인프콘이다.

https://www.inflearn.com/course/infcon2022

[무료] 인프콘 2022 다시보기 - 인프런 | 강의

 

(레거시 시스템) 개편의 기술 - 배달 플랫폼에서 겪은 N번의 개편 경험기

1. 레거시 개편은 왜 일어나는가? - 레거시는 무엇이고, 개편은 어떻게 결정되는가?

2. 경험한 개편은? - 배달플랫폼에서 겪었던 4가지 개편 소개

3. 개편의 기술 - 개편에 사용했던 4가지 방법 공개

 

지금 겪고 있는 상황과 비슷해서 관심있게 본 세션이다.

개발적으로 어떤 원칙을 가지고 해결했는지 듣는 것도 즐거웠고,

개편 당시의 구체적인 상황을 듣는 것도 재미있는 세션이다. 

이런 세션을 들으면 뭔가 개편도 굉장히 도전적이고 재미있어 보인다.

 

실전! 멀티 모듈 프로젝트 구조와 설계

1. "WHY" 멀티 모듈 프로젝트 구조가 중요할까요?

2. "WHAT"을 기준으로 멀티 모듈 프로젝트 구조를 나뉘어야 할까요?

3. "HOW" 실전 멀티 모듈 프로젝트 구현을 해야 될까요?

 

admin, api, batch로 이루어진 프로젝트와 그것들이 의존하고 있는 core와 common.

나에겐 굉장히 익숙한 구조의 프로젝트다.

그 core와 common에 대한 의존성이 꼬이고 그로인해 모듈을 새로 설계한 경험에 대해서 소개해주고 있다.

해결에 사용된 방법론으로는 DDD에서 이야기하는 바운디드 컨텍스트를 기준으로 나누었다.

바운디드 컨텍스트를 실무에 적용한 예시를 본 적이 없어서 집중해서 보았는데,

이렇게도 프로젝트를 한번 해보고 싶다는 생각이 들었다.

 

개발자의 셀프 브랜딩

1. 개발 콘텐츠는 어떤 종류가 있을까?

2. 개발자 셀프 브랜딩

3. 무엇을 얻었나?

4. 좋은 콘텐츠를 만들기 위해 생각하면 좋은 것들

5. 기술 서적 출판에 관한 이야기

 

개발자로서 유명세를 얻는 것은 어려운 일이지만 기분 좋을 일이기도 할 것이다.

셀프 브랜딩 방법도 좋은 컨텐츠였지만, 그보다도 왜 셀프 브랜딩을 하는지에 대한 내용이 인상깊었다.

가끔 유명해진다고 한들 무슨 이득이 있을까 고민을 하기도 했었는데 그런 생각을 정리하는데 도움을 주었다. 

(추가로 아래 링크는 블로그 쓸때 다이어그램 그릴 때 좋다고 한다. 나중에 쓰려고 일단 링크만 킵해둔다.)

https://www.diagrams.net/

 

어느 날 고민 많은 주니어 개발자가 찾아왔다 - 성장과 취업, 이직 이야기

1. 나의 개발자 커리어 이야기

2. 이직 - 이직 준비, 채용, 이력서, 면접

3. 학습

4. 시스템

5. 성장

 

인프런 대표강사 영한님의 발표다.

제목처럼 성장과 취업, 그리고 이직에 대한 분석과 팁을 다루고 있는데 

내가 지금까지 본 성장과 취업, 그리고 이직에 대해서 가장 현실적이고 괜찮은 팁을 제시하고 있다.

진짜 취업을 준비하는 그 누구에게도 추천해주고 싶은 좋은 세션이다.

이력서와 면접에 대하여 정말 내가 느끼던 중요한 핵심들을 가장 잘 정리하고 있는 것 같다. 

이걸 취준할 때 들었어야 하는데..

 

나와 팀을 성장시키는 리뷰들 코드 리뷰만 리뷰가 아니라니까?

0. 개발자의 일과 리뷰?

1. 요구사항(문제) 분석 단계의 리뷰

2. 설계 단계의 리뷰

3. 구현 단계의 리뷰

4. 테스트 단계의 리뷰

5. 배포 단계의 리뷰

6. 장애 발생 시 리뷰

7. 그리고, 성장

 

코드 리뷰를 포함한 팀에서 이루어지는 모든 리뷰 과정에 대한 정리를 해주셨다.

목차처럼 개발팀에서 일어날 수 있는 모든 단계에의 리뷰 상황들에 대해서 설명해 준다.

최근 업무가 리뷰가 잘 진행될 수가 없는 환경이라 너무나도 아쉽지만,

리뷰를 통해 성장하는 좋은 팀이란 어떤 것인지에서 인사이트를 얻을 수 있는 세션이었다.

 

코드 리뷰의 또 다른 접근 방법: Pull Requests vs Stacked Changes

1. Pull Request 관점에서의 코드 리뷰

2. Stacked Changes 관점에서의 코드 리뷰

3. Graphite

 

깃헙을 통해서 리뷰할 때 가장 힘든 게 몇 가지 있는데,

- 비즈니스 로직과 상관없는 코드가 너무 많은 상황

- 변경 자체가 너무 여러 단계고 복잡한 상황

그런 상황에 대한 해결책으로 나오는게 후자에 쓰여있는 Stacked Changes라고 한다.

하나의 pr을 여러개로 나누고, 그것을 선후관계가 명확한 하나의 stack처럼 구성하는 것이다.

뭔가 팀에 적극적으로 도입하자고 하기는 애매하지만, 상황이 되면 한 번 써보는 것도 괜찮은 것 같다.

다음은 세션에서 소개해준 stacked changes를 위한 소프트웨어인 grahite의 링크다.

https://graphite.dev/

 

인프런 아키텍처의 과거, 현재 그리고 미래

이전 인프런의 스택은 가끔씩 jojoldu 님의 글이나 영상을 통해서 본 적은 있는데,

인프런의 cto가 되시고 정말 많은 일들을 하고 계시는 것 같다.

내가 대충 보기엔 저게 저 인원과 시간으로 되나 싶긴 한데, 그럼에도 그 사이에 많은 것들이 바뀌어가고 있는 것 같다.

스타트업의 특성상 아키텍처 개편과 서비스 개선을 동시에 이루어나가야 하는데,

그 사이에서 찾은 타협점 등 그 중간중간 이루어진 결정에서 배울 것들이 있는 것 같다.

 

이 이력서, 누구 거에요?

1. 주인공과 견적서 - 이력서 전체를 관통하는 핵심

2. 이야기 구조 - 주제 정의, 경험, 교육 부분을 이야기 구조로 살펴보기

3. 포트폴리오 - 내가 드러나는 포트폴리오 구성

4. 피드백 - 내가 보는 나와 남이 보는 나

 

신입과 주니어 개발자의 이력서와 포트폴리오 작성에 대한 세션이다.

꽤나 핵심을 찌르는 내용이 많아서 재미있게 봤다.

내가 취업 준비를 할 때 이런 세션이 있었더라면 더 잘 준비하지 않았을까라는 생각도 조금 들었다.

나중에 개발자 취준생들을 만난다면 위 영한님 세션과 같이 보라고 추천해 줄 예정이다.