[후기] 01. 인프콘(INFCON 2022)

출발

 
일어나자마자 휴대폰을 봤더니 인프런으로부터 메시지가 와있었다.

그리고 여유부리다가 기차 출발시간이 11시 4분이었는데 대전역에 11시에 도착해버려서 내림과 동시에 바로 뛰어서 무사히 탔다.. 😅

12시즈음에 수서역에 도착한다음 강남 6번 버스를 타고 코엑스로 곧장 달려갔다. 코엑스는 첫 방문이라 촌놈티 내면서 서울 풍경을 눈에 담아두려고 열심히 두리번댔다.
 

행사장에 입장하자마자 등록테스크에서 네임택, 리플렛, 티셔츠를 수령하고 시작전에 부스를 돌아보려했지만 사람이 너무 많아서 도망쳤다(?)

시작

0. 오프닝

시작은 인프랩의 CEO이신 이형주 님이 인프콘을 주최하게 된 계기와 소개로 시작되었다. 이후에는 CTO이신 향로 님이  'Learn Share and Grow'라는 슬로건을 가지고 인프런의 취지와 22년도 하반기 로드맵에 대해 설명해주셨고, 홍현희 리드님이 전체적으로 행사를 어떻게 즐기는지를 소개해주셨다.

네모친 칸들이 내가 참여한 세션들이다.

1. 첫 번째 세션

실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고 (한정수 님)

첫 슬라이드와 5분채 되지않은 시간동안 정말 겸손하신 분이라는 걸 느꼈다.
본인을 '조금 빨리 시작한 개발자'라고 소개하시면서 "'아, 이런 방식으로 하는 사람도 있구나'라고 생각하고 들어달라"고 하셨다.

전체적인 발표 구성은 "좋았던 선택 vs 후회되는 선택"을 연차별로 풀어나가셨다.
발표자분이 전달하고자 하는 의도와 다르기 이해한 걸 수도 있겠지만 나에게 크게 와닿은 내용은 다음과 같다.

• 성장하기 힘든 환경이 아닌 나무가 자랄 수 없는 콘크리트 바닥의 환경이라면 벗어나라
• 주니어 개발자나 예비 개발자라면 코딩테스트를 놓지마라
• 코드 리뷰를 '적극적으로' 실천해라
• 스터디 및 세미나를 다녀라
• 레거시에 불만을 갖지말라. 불만이 아닌 어떻게 개선할지

가장 중요시하게 여시기는 건 코드리뷰와 팀원 및 동료이신 것 같았다. 4번(4년)의 좋았던 선택에 두 가지가 빠짐없이 들어갔던 걸로 기억한다.
또한, 회고에 대해서도 중요시 하는 것 같았다.
TIL, 연간 회고, 학습 내용 정리 처럼 꾸준하게 일정한 기간마다 회고를 하신 기록들이 보였다.
 

2. 두 번째 세션

나도 내 코드의 문제를 찾고 싶다고요?! (한주승 님)

발표자 님의 실제 사례로 시작이 되었는데 너무 유쾌하게 풀어나가셔서 몰입감이 대단했다.

이미지에 흐릿하게 부제로 써있는 테스트 할 때 기억할 7가지를 정리하면
내가 어떠한 입력을 넣었을 때 예상했던 결과가 나오지 않으면 테스트케이스와 요구사항에서 문제를 찾고, 구현이나 인터페이스로 해결방안을 찾으라
는 말을 해주셨다.

또, 테스트케이스가 얼마나 중요한 지에 대해서도 예시를 들어주었다.
사진을 찍거나 기록해두질 못해서 발표 PPT에 있던 예시 코드를 대강 적어봤다.

int result = getFunction1();
boolean isFalse = getFunction1();

if(isFalse == false) {
  printf("%s", &result);
}

단순히 출력만 하는 예시처럼 보여서 의심의 여지없이 당연히 되겠지라고 생각하며 테스트를 실행했지만 아이러니하게도 오류가 발생했다는 예시 상황이다.
오류의 원인은 result를 출력할 때 int타입을 string타입으로 출력하려고 했기에 발생한 문제이다.

그리고 문제나 해결방안을 찾는 과정에서 팀원간 발생할 수 있는 감정의 개입이 없도록 하는 것이 좋다고 했다. 인터페이스는 전체의 문제지만, 구현의 경우에는 그러지않기에 감정의 개입이 일어날 수 있다고 했다.

더 나아가서, A 기능을 하는 것이 있다면 이 기능을 사용자의 입장에서 어떻게 더 편하게 사용할 수 있는지에 대해 사용자의 입장이 되어보라고도 해주었다.

3. 세 번째 세션

코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes (서지연 님)

시작하기에 앞서 Pull Requests를 안다는 전제하에 진행되었는데 아쉽게도 협업 경험이 없는 나에게 크게 와닿지는 못했지만 새로운 방식을 새로이 알게 되었다.

Stacked Changes은 스택처럼 쌓이게 되는 방법으로 관련된 툴로는 Graphite review라는 게 있다고 한다.

4. 네 번째 세션

나와 팀을 성장시키는 리뷰들 (박미정 님)

코드 리뷰가 주제였던 두 번째 세션과 세 번째 세션 그리고 코드 리뷰가 주제가 아님에도 불구하고 코드 리뷰를 강조해주신 첫 번째 세션의 한정수님에 이어 네 번째 세션마저도 코드 리뷰와 관련된 것이다.
(그만큼 중요!! 별표 다섯개~!)

요구사항 분석 -> 설계 -> 구현 -> 테스트의 과정을 거치면서 각 단계별 리뷰를 진행할 경우 어떠한 성장이 이루어지는지에 대해 말씀해주셨다.

이상하게도 이 세션이 유독 다른 세션에 비해 많은 것들이 와닿았다. 아무래도 앞선 세션을 들으면서 생긴 배경지식이 덕분같다.

암튼 모든 개발 단계에 있어서 리뷰가 중요하다는 것을 새삼 느끼게 되었던 것 같다.
마지막으로 개발을 잘하는 사람과 일을 잘하는 사람에 대한 얘기도 해주셨다.

5. 다섯 번째 세션

지금 당장 DevOps를 해야하는 이유

DevOps라는 용어는 들어봤지만 편하게 들으려고 들은 세션이었지만 생각보다 얻은 것이 많았다.
특히, 개발부터 배포까지의 과정들에서의 전반적으로 흐름을 익힌 것 같았다.

6. 여섯 번째 세션

(레거시 시스템) 개편의 기술 (권용근 님)

레거시의 사전적인 의미는 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등을 말한다. (wiki)

Q> 그렇다면 레거시는 왜 일어나는가?
A> 트래픽 성능에 의해서, 과거의 기술이라서, 입력(요구사항)에 대응할 수 없어서
(연사자님이 말한 내용이지만 지금 작성하는 코드도 결국 레거시라는...)

사전에 기본 배경들을 설명해주시고 발표주제인 배달 플랫폼에서 겪은 N번의 개편 경험기를 주제로 설명해주셨다.
4번의 개편을 진행하면서 기존 시스템의 문제점과 어떻게 개편했는지를 말씀해주셨는데 경험이 부족한 나에겐 추상적이게 들렸지만 도움이 되었다.

실무의 경험이 있거나 개편을 하려는 개발자라면 도움이 정말 많이 됐을 세션이라 생각된다.

개편을 하기 위한 가장 큰 핵심은 그동안 묵혀지고 얽힌 코드들을 어떻게 정리할 수 있을까 였다.

그에 대한 해결책이
1. 의존성
2. 역할과 책임
이었다.

의존성을 한 방향으로 정리하기 위해 우선 계층형 아키텍처처럼 분리를 한다고 한다.
도메인을 분리시키고.. Service들을 정리하고.. 계층을 나누고.. 분리된 도메인을 계층처럼 관리하라.. 였던 것 같다.
나에겐 너무 어려운.. 😵‍💫

다음으로는 협업도구인 Jira를 예시로 일정과 관련해서 얘기해주셨다.
이런 일정관리 툴을 사용하면 두 가지 장점이 존재한다고 한다.

1. 일정을 관리할 수 있다. 또한, 서로의 관리 상황을 알 수 있다.
2. 이해관계자를 설득하기 원활하다.

그 다음으로는 원래 다른 주제들을 준비하셨지만 시간이 초과될 것 같아 부록을 준비하셨다고 한다.

우선 도메인에 대해 말을 해주었다.
도메인은 '주문', '거래'등을 말한다고 한다. 그리고 이 도메인은 사람마다 지식의 차이가 존재한다고 한다.
예를 들면, 해당 회사에 N년 이상 근무한 사람과 갓 입사한 신입 개발자와 비교한다면 도메인 지식에 대한 차이가 존재할 수 밖에 없다.

도메인 지식이 크게 차이가 날 경우 도메인 지식이 적은 개발자는 도메인 지식을 익히기 위해 큰 비용이 발생하게 되고, 의사결정 과정에 참여하기도 어려워진다. 그렇게 되면 도메인 이해 관계가 높은 사람의 부담 또한 커질 수 밖에 없다.

그래서 모두의 도메인 지식을 높이는 방법으로 '이벤트스토밍'에 대해 소개해주셨다.
 
사실 우연히 지난주에 이벤트스토밍에 대해 살짝 듣게 되었다.
이벤트스토밍을 실제로 적용해봤더니 효과가 있었고 방법론에 대해서 다들 제법 흥미로워 하시는 눈치였다.
그렇지만 이벤트스토밍이 제대로 이뤄지기 위해서는 실제 문제 해결에 관련된 모든 사람(질문이 있는 사람, 도메인에 대해 잘 아는 전문가)과 진행을 원활하게 돕는 중간자 역할을 하는 사람 등 여러 조건들이 필요로 한다고 한다.

7. 일곱 번째 세션

어느 날 고민 많은 주니어 개발자가 찾아왔다 (김영한 님)

대망의...... 연예ㅇ... 아니 영한님이다..!

세션 시작 직전에 화면이 뜨자마자 사람들이 사진 찍기했는데 영한님이 재치있게 반응해주셔서 분위기가 좋았다.

시작은 연사님의 성장배경으로 시작되었는데 여기서 한가지 배움이 있었다.
연사님의 강의 처음 소개 PPT처럼 화면에 H1 태그로 몇 글자의 소스만 띄워두고 말로 해주셨다. 생각보다 몰입과 집중이 잘 되었고 오프라인 발표 방식 중 이런 방식이 내 취향에 잘 맞다고도 생각했다. 따라서 듣는 사람은 눈으로 PPT를 읽지 않아도 되기 때문에 발표자에게 몰입이 된다.

다시 본론으로 돌아가서 연사님의 발표 부제는 성장과 취업, 이직 이야기이다.
이직, 신입 vs 경력, 채용, 이력서, 면접, 프로젝트 경험, 학습, 시스템, 피드백, 변화와 도전, 기술적 겸손함의 순으로 진행해주셨다.

1. 이직: 가고자하는 회사를 단계별로 나누고, 좋은 회사의 기술 스택을 참고해서 준비한다. 낮은 단계의 회사들은 비슷한 기술을 사용하는 회사로 정하는 것이 면접면에서도 유리하다.
2. 신입 vs 경력: 좋은 회사일수록 경력보다 신입으로 입사하기가 더 어렵다. 그래서, 조금 낮은 단계의 회사부터 성장하는 것도 방법이다.
3. 채용: (실력있는) 개발자 TO는 많다. 기존에는 사람과 IT회사가 N:1이었지만, 이제는 1:N이다. 이 말은 즉, 회사에서 좋은 인재를 서로 가져가려고 한다.
4. 이력서: 이력서 작성 방법을 알아야 한다. 겸손한 것도 중요하지만 본인 마케팅도 중요하다.
5. 면접: 결국 확률이다. 면접관의 성향에 따라 달라진다.
6. 프로젝트 경험: 단순히 뭘 해봤냐가 중요한 것이 아니다. 문제 발생 > 해결 방법이 중요한 것이다. 문제를 기술적으로 어떻게 해결했는지 자세히 적는다.
7. 학습: "내가 아는 것이 진짜 아는 것인가?". 스스로 깊게 파는 것이 중요하다. 학습의 3단계는 학습(강의, 책) -> 체득(실무, 토이프로젝트) -> 정리(블로그, 세미나, 노트)이다.
8. 수영을 예시로 들 수 있다. 수영강사가 팔을 휘휘하면서 보여준다고 내가 잘 할 수 있는가? X.
9. 시스템: 목표와 시스템은 다르다. 목표는 성공과 실패에 집중하지만, 시스템은 과정에 집중한다. 내가 이해한 바로 다르게 표현하면 '습관'이다. 열심히? X. 열정? X. 매일 몸이 움직이도록 하는 것이다.
10. 하나의 예시로 김연아 선수님의 "그냥 하는거지.."를 예로 들어주셨다.
11. 피드백 사이클: 피드백은 빠르면 빠를수록 좋다. 가령, 테스트케이스가 좋은 이유도 이러한 이유도. 테스트를 돌리면 빠르게 알 수 있기 때문이다.
12. 변화와 도전: 특히 도전을 두려워말라 하셨다. 앞선 피드백과 연관 지어주셨다. 영한 님은 면접을 자주 보는 사람이 완벽하게 준비되고 면접을 보는 사람이 금방 성장할 수 있다고 한다.
13. 또한, 어떠한 회사에서 변화와 도전을 시도해볼때 적극적으로 하게 된다면 혁신이 될 수도 있다.
14. 기술적 겸손함: 본인의 실력에 대해 만족을 하는 사람은 그렇지 않은 사람과 차이가 난다고 한다. 즉, 현재에 만족하게 되면 우물안 개구리가 될 수 있다는 말이다.

끝

집으로

모든 세션이 끝나자마자 버스타고 수서역으로 출발했다.

사람이 많은 곳에 반나절 있었더니 기 빨리기도 했고, 저녁도 먹지 못해서 지친 상태였다.

---

이번 인프콘을 경험하고 느낀 건 다음과 같다.

• 코드리뷰
• 팀원과 동료
• 습관(시스템)
• 정리
• 환경

동료도 분명히 중요하지만, 회사도 성장 가능하고 소통과 존중이 갖춰진 환경이어야 한다는 걸 배웠다.