인프콘에 참석하다

 

나는 인프런을 애용한다.

 

백엔드 엔지니어로서 경력을 시작한지 얼마 되지 않은데다,

회사에서도 사수와 CTO는 저 멀리 싱가폴에 있기에

더욱이 구글과 스택오버플로우, 인터넷 강의 등에 의존해야만 했다.

 

때문에 스팀 게임 수집하듯이 하나하나 인프런 강의 등을 사모은 결과

꽤나 많은 돈을 인프런에 썼다..

강의 소모하는 속도보다 새로 수집하는 속도가 훨씬 빠르다는건 비밀

 

어쨌든, 그렇게 마음의 의존도가 큰 인프런 주최의 행사가 열린다는 소식을 듣곤

 

꽤나 설레었던 것 같다.

 

같이 가기로 한분이 계셨었는데 나만 당첨되어서 결국 나 혼자 가게 되었다..

 

경쟁률이 대략 10:1이라고 하더라 (아마?) 운이 좋다.

 

기다리던 끝에 행사날, 가벼운 마음으로 집을 나서 코엑스에 도착했다.

도착해서 기념품을 받고 입장하니 포토존부터 보였다.

 

사진찍고 싶었지만 부끄러워서 바로 입장

영롱하다

기업 부스에는 사람이 굉장히 많았다.

 

각 부스마다 방문객에게 각기 다른 기념품을 주는 것 같았다.

 

나는 기다리는게 엄두가 안나서 일단 무신사부스만 방문

 

반팔티랑 스티커 받았다

데브계의 게이브 뉴웰 이형주 인프런 대표님

 

데브계의 아이돌 향로님

향로님 첫 인사를 세계최초예능지향.. 하셔서 빵터졌다 (개발바닥 유튜브 인사)

실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고

 

오프닝 끝나고 본격적으로 본행사로 들어갔다.

 

한정수님 강연으로 시작.

 

성장하기 극히 어려운 콘크리트 환경에서 시작하여

 

요소들을 하나하나 극복해가며 성장해가는 과정을 심도있게 보여주셨다

 

딱 내게 필요한 좋은 강연이었다

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

 

다음은 향로님.

 

인프런의 시작에서부터 현재까지

 

서비스를 유지하고 발전시키기 위해

 

어떤 변천사를 거쳤는지 잘 알려주셨다.

 

회사의 스택이 될 기술을 결정짓는 요소는

 

그저 퍼포먼스가 다가 아니라, 즉

 

최고가 아닌 회사 상황에 맞는 최적의 기술을 선택하여야 한다.

 

(신규 입사자의 러닝커브, 구현 코드 최소화, 각종 라이브러리와의 호환성 등)

 

더불어 지속 가능한, 코드 수정에 자신감이 생기는, 예측 가능한 코드의 중요성도 강조하셨다.

 

각 모듈간의 장애 격리에 대해서도. 

나 홀로 시골 개발자의 성장 전략.

 

마찬가지로 유튜브를 통해 많은 도움을 받았던 얄코님의 발표도 들었다.

 

첫 번째는 '토이 프로젝트를 통해 개발, 배포, 자동화, 운영 전 단계를 경험해보라!

 

그리고 이를 이용해 다양한 기술, 스택을 접목해보라'는 조언을 주셨다

 

또한 이렇게 배운 내용을 실무에 적용해보라는 것도!

 

두 번째로는 지식공유활동.

 

알다시피 지식을 그냥 내가 가지고 있는 것과

 

그걸 남에게 전달하는 것은 체득의 차원이 다르다.

 

이를 위해 다양한 수단을 이용할 수 있다.

 

얄코님처럼 유튜브를 이용하던지, 아니면 블로그나 책 등.

 

인프런에 강의를 올릴 수도 있을 것이다.

 

다만 유튜브는 시간 대비 효율이 떨어진다고 하셨다.

 

그리고 다른 작가들은 출판사를 찾아다니며 출판해달라고 해야하지만,

 

어느 정도 실력이 있고 블로그나 깃허브 등으로 인증이 되는 개발자라면

 

오히려 출판사에서 찾아오는 경우가 제법 많다고 하셨다.

 

때문에 개발자는 글 쓰기가 유리한 직업이다.

 

또 성장에 있어 인센티브는 큰 동력 중 하나이기에

 

이러한 활동들에서 수입도 생긴다면 좋은 선순환이 이루어질 수 있다고 하셨다.

 

 

 

 

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

무신사에서 오신 박미정님의 강연.

 

여기는 강연 사진을 못 찍었다 ㅠㅠ

 

내용은 정말 알차고 좋았다.

 

시작은 '나쁜 냄새는 빨리 발견할수록 고생을 덜 한다'는 말로.

 

아주 공감했다. 아직 내 코드에는 냄새가 많이 나서..

 

리뷰를 여러 단계로 나누어 강연을 진행하셨다.

 

1. 요구사항 분석 단계의 리뷰

• 문제를 명확히 정의해야한다.
  기획 단계에서 서로 다른 요구조건을 생각할 수 있다.
  나중에 통합할 때 '어?'가 나오는 순간.. omg.
• Ex) 어떤 기능이 필요하여 개발에 착수할 뻔 했는데, 알고보니 이미 이용중인 SaaS에 있던 기능이었다.
  여기서의 문제는 '기능의 부재가 아닌 기능의 존재를 모른다'는 데에 있었다.

2. 설계 단계의 리뷰

• 문제 해결에 도달하는 과정에 대한 리뷰
• 설계를 리뷰하지 않으면??
  하지 않아도 될 일, 하면 좋을 일을 하다가 '필요한 일'을 하지 못하게 된다
• 동료, 그리고 다른 시스템에 주는 영향도를 놓칠 수 있다
• 시스템의 복잡도를 높이고, 팀의 설계 원칙을 어길 수 있다

Ex) 개발자 A가 기존 메뉴 서비스를 분리하기 위해 아키텍처를 설계하였는데,

MSA, CQRS, Event Sourcing 등 오만가지 소위 말하는 '좋은' 기술들을 이용하여 설계하였다.

근데 왜??? 굳이?

- 주어진 리소스를 전혀 고려하지 않은 광범위한 아키텍처 설계이다.

- 레거시 변경점을 최소화하기로 한 룰 위반이었다

- 메뉴 서비스 분리라는 '목적'보다 '수단'에 더 많은 리소스를 할애하였다

 

여기서 설계 리뷰의 효과는..

- 구축 범위 축소

- 예측 가능한 일정

- 우선 순위가 높은 일에 집중

- 기일을 지킴으로서 유관부서와의 신뢰 향상

 

3. 구현 단계의 리뷰

• 프로그램이나 설계 등을 구축하며 진행하는 리뷰
• 코드리뷰, 페어 프로그래밍
• 목적은?
  - 코드의 논리적 오류 발견
  - 다른 모듈 혹은 도메인에 대한 부작용 발견
  - 코드 설계 개선
  - 지식, 기술 공유 및 토론을 통한 팀 내 개발 규칙/문화 제안
  - 요구사항을 완전히 반영했는지 확인
  - 코드에 대한 확장성, 응집도 등에 대한 설계 방향 재고
  - 기술 공유, 팀 내 개발 규칙/문화 제안
  
  
• 팀 내 정착시키면 좋을 코드리뷰 문화?
  - 팀원 전체 캘린더에 코드 리뷰 집중시간 등록
  - 작성자는 코드에 담고있는 요구사항/이슈를 충분히 설명
  - 문제 발생 시, 코드 리뷰에서 발견 가능한 문제였을지 반드시 회고
  (예방할 수 있었던 문제다)
• 피드백은?
  - 반드시 경험이 많아야만 좋은 리뷰를 할 수 있는 것은 아니다
  - 지금보다 더 나은 방향으로 고민하고 제시하는 의견은 무엇이든 유용함
  - 작성자의 코드 작성 의도를 궁금해하는 것 역시 좋은 리뷰이다

4. 테스트 단계의 리뷰

• 테스트란 : 시스템이 정해진 요구를 만족하는지 확인하는 절차.
• 테스트는 크게 세 가지로 나뉜다.
  - 단위 테스트 : 특정 모듈에 대한 테스트
  - 통합 테스트 : 소프트웨어를 결합해가며 테스트
  - 인수 테스트 : 실제 운영 환경에서 사용할 준비를 위한 테스트
• 테스트 자체로 리뷰의 의미를 가지나, 테스트를 수행했다고 해서 곧 리뷰가 완료되었다는 의미는 아니다.
  - 테스트 자체를 리뷰해야한다.
    - 테스트 코드를 리뷰
    - 테스트 시나리오를 리뷰

5. 배포 단계의 리뷰

• 최종 사용자에게 소프트웨어를 전달하는 과정에서의 리뷰
• 배포 전 리뷰하는 것은 :
  - 릴리즈 노트
  - 배포 시기
  - ci/cd 파이프라인 자동화
• 배포 후 리뷰하는 것은 :
  - 배포한 기능이 잘 쓰이고 있는가
  - 성능 문제는 없는가

6. 장애 발생 시의 리뷰

• 근본적인 원인에 대한 리뷰 ('누가'에 대해서는 제외한다)
• 재발 방지 대책 수립에 대한 리뷰

7. 첨언

• 개발자가 개발을 잘 하면 그냥 개발만 잘 하는 개발자다..
• 리뷰를 잘 하는 개발자는? 일을 잘 하는 개발자다. (개발 잘하는 개발자 <<< 일 잘하는 개발자)
• 각 단계의 리뷰는 결국 팀원 개개인의 일하는 능력을 향상시킨다.
• 그렇게 일을 잘하는 '팀'이 된다.

 

 

제주 동북쪽 바닷가 마을에 사는 N잡러 이야기

 

스튜디오밀, 1분코딩 유튜브를 운영하시는 유준모님의 강연.

 

준모님은 굉장히 자유를 중시하고 사랑하는 분이었다.

 

내가 여러 강연 중 이 강연을 선택한 것도 제목부터 내 워너비 라이프를 살고계신 분 같았기 때문이다.

 

준모님은 본 강연에서의 자유를 아무것도 안해도 되는 것이 아닌,

 

내가 사랑하는 사람들과 시간을 보내며 하고싶은 일을 하는 것이라고 짚고 가셨다.

엄청 매력적이다

1. 1인 기업

 

준모님은 1인 기업 형태로 본인의 일들을 진행하고 계셨다.

 

1인 기업의 장점..
- 자유
- 고정 인건비 지출 없음
- 시간 효율이 좋음

 

특히 It 1인 기업은 크게 투자금이 들어갈게 없기에.. 도전하고 싶어졌다.

 

2. N잡러

 

여러가지의 일을 한다는 것.

- A가 망하면(싫어지면) B나 C의 대안이 존재하는 것.

- 심적인 자유가 엄청나다고 하셨다.

 

한 가지만 파기 vs 이것저것 하기?

- 어떤 일에 시간을 투자했을때 0~10까지 전문성이 쌓인다고 가정했을 때,

0에서부터 6, 7까지 가는데의 비용에 비해 7,8에서 9,10까지 가는게 훨씬 힘들다.

반면 일반적으로 어떤 분야에서 6~7정도만 되어도 어느정도 먹고 살 수 있는 일이 많다.

때문에 여러 가지의 일을 6~7까지만 쌓고 또 다른 일에 투자하는 것이 효율적이다.

 

안그래도 요즘 다양한 일을 해보고 싶다는 생각이 자라고 있었는데,

거기에 불을 붙여주는 강연이었다.

 

아, 끝나고 따로 찾아가서 준모님이 구축하신 앱의 데이터를 어떻게 수집했는지 여쭈었는데,

나는 당연히 공공데이터를 이용한다던지 그런 방식을 예상했는데,

2,000개 이상의 카페를 직접 매일같이 돌아다니며 수집하셨단다.

존경하지 않을 수 없는 부분이었고,

스스로 반성하게 되었고 굉장히 자극받았다.

마지막으로 개발바닥 유튜브 생방송 시간이었다.

여기서도 좋은 이야기를 많이 들었는데,

그 중 기억에 남는 것은

'그냥 개발만 잘하는 개발자가 면접자리에 온다면 뽑지않고 외주를 맡기면 그만이다.

본인이 주체적으로 문제를 파악하고 해결해야하고, 안주하지 않고 더 좋은 것을 향한 방향성이 있어야한다' 라는 말이었다.

이 또한 나 스스로에게 질문을 던지고, 반성하게 만드는 대목이었다.