항해 DEV LAB 후기

 

나는 항해 코스를 듣지 않았지만, 주변에 들은 분들이 꽤 있다.

 

내가 이런 세션을 들으러 다니는걸 좋아한다는건 그분들도 다 아시기 때문에.. 항해 DEV LAB에 같이 가자고 추천 받았다.

 

참석이 확정되고 스케줄을 받았는데, 다음과 같았다.

 

 

세션보단 네트워킹에 초점을 맞춘 스케줄이었다.

 

그러나 막상 세션 장소에 도착해보니 너무 덥고, 시끄러워서 의사소통이 썩 원활하진 않았다.

 

세션도... 다 좋지는 않았는데, 일단 정리는 해봤다.

 

1. AI와 자동화로 주니어 개발자 키우기

 

인프랩은 개발자가 33명으로 구성되어 있다. 그중에 첫 직장 11명이고, 대부분 주니어로 구성되어 있다.

그러나 처음 채용을 할 때는, 좋은 시니어를 뽑자가 목표

- 어떤 사람을 뽑아야 할까?

1. 셀프모티베이션

2. 제품과 조직의 align이 된 사람

3. 전문성
4. 리더십과 매니지먼트

5. 기술과 제품 관점 결정력이 필요함

그러나 21년에 개발자 영입이 대란이어서 경쟁이 심했다...
- 모든 요구사항을 충족하는 시니어를 뽑을 수 없음
- 원하는 능력리 과연 경력과 비례할까? 그렇진 않을 것 같다.
- 훈련 불가능한 요소를 가진 사람을 뽑자(비전과 모티베이션을 가진 사람)

 

또 다른 문제: 1년간 훈련된 신입이 2년만에 이직한다면?
- 신입이 align하기 위해서는 1년정도의 기간이 필요한데 어떻게하는게 좋을까?
- 적응하는 기간을 단축시켜서 2~3년 이후에 이직하더라도 사람이 떠나더라도 활약기간을 늘려보자는게 지향점

 

신입사원의 적응 기간을 단축시키기 위한 노력들

1. 입사하게 된다면 우리 팀의 미션을 공유
- 프로덕트 엔지니어임을 강조
- 내부고객은 개발팀을 구성하는 모든 구성원
- 외부고객은 실제 고객임을 인지시킴

 

2. 일 잘하는 사람에 대한 명확한 정의

 

3. 잦은 주기의 피드백 환경

기본적인 코드 리뷰
- 리뷰가 병목이 되면 안됨
- 그러나 신입개발자는 리뷰가 없으면 불안해함
- 기본적인 테스트 커버리지를 통과해야함
- 소나큐브 적용 PR분석과 전체 분석을 통해 전반적인 코드 퀄리티를 올리도록 함
- code rabbit AI 코드 리뷰 도구 : 쿼리 최적화, 누락된 테스트, 전체적인 시퀀스 다이어그램도 만들어 줌
- 코드 리뷰 시간 단축을 위한 노력 서포터가 없어도 피드백받을 수 있도록

테스트 코드
- PR마다 수행하고 기존보다 커버리지가 낮으면 실패하도록 한다.
- 소나큐브를 통해서 진행
- DORA 매트릭을 통해서 개발팀의 생산성을 측정하는 주요 지표

- 켄트백은 별로 좋지 않게 봄 개발자의 생산성은 지표로 측정할 수 없다 - 동욱님도 비슷한 의견
- 그러나 지연된 이유나 어디서 병목이 발생했는지 알 필요가 있음
- DORA 대시보드를 그라파아 대시보드를 만들어서 관리
- PR 첫 리뷰까지 걸리는 시간, 커밋까지 걸리는 시간 등등을 측정함 

 

언제든지 답변을 얻을 수 있는 환경

1. metasearch : jira slack github 등 파편화된 모든 내역을 검색할 수 있는 환경을 제공

2. AI slack bot : 사내 위키 jira를 보고 자동으로 답변, 어떤 문서를 참고했는지까지 보여준다

3. AI 데일리 분석 노트 : 매출분석 학습수 구매자 수 등 다양한 리포트를 받을 수 있음

4. 꼭 서포터가 없어도 피드백을 받을 수 있는 환경

- 문서화를 강조 : 한번의 문서화를 해두면 반복적인 질문은 봇이 찾아줄거다..

- 신규 입사자는 봇에게 답변을 얻고 최신화 한다.

- 용어 정리 : 시트로 정리해서 bot이 학습하도록 한다. 회사에서만 사용하는 특별한 용어를 한곳에서 정리

- 구두 논의 내용 주기적인 정리 후 slack에 공유 언제든지 맥락을 놓치지 않고 팔로우 할 수 있게됨

5. 직접구축보다는 오픈소스

- Mantine gluestack ui 같은 오픈 소스 디자인 시스템을 활용

- 자체개발은 리액트 버전업 대응, 문서화 등이 어려워 사용하지 않음

- 오픈소스를 쓰면 AI에게 질문하면 적합한 응답을 받을 수 있어서 도구 적응기간 대폭 감소시킬 수 있음

 

마무리

동기부여가 되어있고 팀 전체에 자극을 주고 회사의 목표에 전심전력을 다하는 동료라면 주니어, 시니어의 구분이 필요가 없어진다.

 

Q&A

1. AI 기술은 mongodb vectordb를 사용해서 임베딩검색을 구축함

2. 사람이 많을수록 좋지 않을수 있어서 적은팀으로 최고의 가치를 만들기 위해 노력함

3. 사내에 개발자 편의성을 위한 개발들은 대부분 개발자들이 개인 시간을 투자해서 대부분 만들었다

4. 슬랙이 주 7일 활성화되어있음…

5. 데브옵스 팀의 비율이 상대적으로 높다(20%) 소개한 일들의 대부분이 jira 티켓으로 관리되지 않는 일들이다.

 

정리

개인적으로 꽤나 도움됐던 세션이었다.

 

같이 일하는 개발자들의 매니징도 신경쓰고 있는 상황에서 내가 겪는 애로사항들을 여러가지 기술을 통해 해결? 대응? 한게 상당히 인상 깊었다. 적용해보고 기술도 몇가지 얻어갈 수 있었다.

 

그리고 무엇보다 강력한 작은 팀으로 결과를 얻겠다는 의지가 느껴졌다.

나는 CTO가 팀의 기술 한계를 결정짓는다는 말을 꽤나 신봉하는데, 이번 세션에서 다시 한번 이 말의 의미를 느꼈다.

 

그런데, 중간에 특성화고에서 채용하신 말을 하셨는데... 이 말의 의미를 다른사람들이 알까 싶다.

 

책임분리와 깔끔한 폴더 구조

부제 : 프론트엔드 개발자 관점으로 바라보는 관심사 분리와 좋은 폴더 구조

 

프론트엔드는 총 세 가지 언어를 배운다 : HTML, CSS, JS

 

관심사의 분리가 중요하다

- 비슷비슷한 것끼리 모아두면 인지의 부하가 굉장히 올라간다.

- 언어 모듈 파일 함수 클래스 특정 계층이 구분 가능하도록 역할을 잘 나누고 분리하자!

- 명확한 하나의 기준을 정하자

 

ajax 등장 서버와 클라이언트의 분리됨

 

컴포넌트를 수직적으로 구성하는 방식으로 만들어보자….

그러나 데이터 관리가 안되서 컴포넌트간 교류가 너무 비정상적으로 늘어나서 결국 스파게티가 되버림

수평적 구조로 회귀함..

css와 html의 구조를 변경하고 의존성이 단방향으로 구성되도록 함

 

수직으로고 수평으로도 데이터적으로도 구조를 나누고 클린아키텍처에 대한 고민이 몇 년간 지속되어 왔음

 

FSD 아키텍처를 써보자

이게 가장 중요한 부분이었던 것 같은데, 내가 이해를 못한건지 따로 언급을 안하신 건지 잘 모르겠다.

 

궁금해서 아래 링크에서 다시한번 읽어봤음

기능 분할 설계(FSD)를 이용한 FE 아키텍처 구성

Feature-Sliced Design

 

흔히하는 실수

같은 구조면 같은 컴포넌트로 만들려고 한다.

- 하지만 다루는 데이터가 다르면 분리해야한다.

- 결합도를 낮춰라

 

상황에 따라 잘 구성해야한다.

 

정리

이 세션이 시작될 때 전반적인 세션 시간이 꽤나 밀려서 그런지 엄청나게 빠르게 발표를 진행하셨다.

FE 세션이고, 빌드업이 길어서 세션을 듣는데 집중력이 흩어졌었다. 그래서 메모 내용이 너무 파편적이었다...

무엇보다 아키텍처보다는 책임 분리를 위한 폴더 구조에 대한 이야기라 가벼운 이야기기도 해서 큰 관심이 가지 않았다.

발표자분이 테오의 스프린트를 운영하시는 분이라 꽤 기대했는데 급하게 마무리하셔서 발표 내용은 전반적으로 아쉬웠다.

 

 

아래 두 세션은 이제 항해 졸업자분들이 한 세션이라고 한다.

개인적으론 너무 얕게 아는 것을 공유하려는 것 같아서, 도움이 될 것 같지 않았다. 이 때 이탈자가 많이 생겼었다.

Git workflow로 팀워크 혁신하기

 

git 관리, 브랜치 전략에 대한 고민이 많았음

 

피처 개발 중 메인 브랜치에 머지가 들어왔을 때 피처 브랜치에 메인을 머지하는 건 정답이 아니다. 메인 브랜치에 적용된 내용이 피처에서 작업한 것 처럼 되기 때문?

 

squash merge? 브랜치에서 붙는 방식이 아닌 중간 이력들이 메인에 붙음. 세부 이력이 남지 않는 단점아닌 단점이 있음

rebase ? 피쳐브랜치의 시작지점을 마스터의 마지막 지점으로 만들어줌

rebase merge : 메인 이후에 이어붙음, 피처브랜치에서 작업한 세세한 커밋들이 모두 남아버림

squash merge + rebase merge를 활용함

 

rule을 만들어라

컨벤션을 제각각으로 쓰면 이력이 이상하게 남음..

git hook으로 특정상황에서 강제로 규칙을 적용 시켜버림

 

정리 : 발표자분이 긴장을 너무 많이한것 같았다... 그런데 결론이 그냥 GitHub PR 전략 중 하나 아닌가 싶다...

 

클라우드로 무장한 고가용성 및 장애복구 비법

 

어떻게해야 클라우드를 잘 쓸 수 있는가?

- 컨테이너 마이크로서비스 데브옵스

- 세가지가 대표적인 예

- 개발보다 어려운 운영.. 개발이 개발에 집중할 수 있는 환경을 구축하는게 중요

 

고가용성과 뛰어난 장애 복구 기능을 갖춘 견고한 백엔드 서비스의 토대를 마련

- 고가용성과 재해복구

- 서비스 중단 없이 얼마나 지속이 될 수 있는가

- 예기치 못한 상황에서 시스템이 다운됐을 때 얼마나 빨리 복구 할 수 있나

- RTO RP(point)O 어느시간 어느지점에서 복구할 것인가.. 복구 시간 목표와 복구 지점 목표

 

고가용성

다중 가용 영역, 배포 자동화된 페일오버, 무중단 배포

 

재해복구 DR

데이터가 컨테이너에 저장되면 안된다. 분산환경에 저장해야한다. 멀티리전 복제본 등으로 관리

 

오토스케일링 그룹

인스턴스의 수를 수동으로 조절, 매트릭 기반 조절, 스케줄 기반 조절

 

정리

MSP에서 일하시는 분 같은데... AWS가 제안하는 ASG를 사용하는 아키텍처 중 가장 기본적인 방식을 설명하셨다.

공식 문서, 공식 유튜브, 공식 자료에서 확인할 수 있는 기본적인 방식을 소개해서 이런게 발표할만한 내용인가? 싶었다.

발표 스킬이 굉장히 좋으셨는데, 발표 내용은 AWS 공식 유투브에서 볼 수 있을 만한 내용이었다.... 

 

클린 아키텍처

부제 : 무한 성장하는 시스템의 비밀

 

 

남의 집을 따라하면 그 끝은 남의 집이다

 

좋은 설계란?

- 미래를 멀리 보지 말라

- 클린아키텍처 원본에는 코드가 없다-

- 도메인을 보호해라 srp를 지켜라 등등

 

총 세 가지의 가이드라인을 세웠음

key 1. 비즈니스

책임에 맞게 레이어를 분리해라

비즈니스 로직을 지켜라

인프라 레이어와 외부 요청으로부터 보호되어야 한다.. 역할을 분리한다

분리된 역할을 조립했을 때 완성된 하나의 역할을 만들 수 있도록 분리하자

인터페이스? 외부의 표현계층, 진입점이나 탈출점이다

 

단방향 의존만 가능하게 만드는 component 레이어를 두고 조립하는 계층을 만들고 사용한다. 서비스는 단순히 진입점이 된다.

 

key 2. 숙성

함부로 일반화 시키지말고 도메인을 적절히 만들어야한다. 숙성을 시켜서 

 

key 3. 책임

모든 객체는 책임이 있어야한다.

 

개발을 말랑말랑하게 해야한다…

하나의 기능을 만들 때 3시간을 넘기면 안된다.

우선 기능 개발을 하고 테스트를 만들면서 풀어라

 

 

정리

일단 발표가 준비가 덜된 느낌을 받았다. 그래서 그런지 나도 잘 정리할 수 없었다.

그리고 발표 내용은 무한 성장하는 시스템의 비밀까지 아니었고, 본인이 생각하는 방식의 클린 아키텍처를 말씀하셨다.

 

잘하는 분인건 알겠는데 "본인이 생각하는 클린아키텍처" 라는 말이 서두에 꼭 들어가야 될 것 같다.

워딩이 센 편이어서 잘못 물리면 싸움이 날만할 내용이었기 때문이다...

나도 들으면서도 그게 맞나? 생각이 들었는데, 같이 가신 분도 비슷한 생각을 하셨었다...

 

마침 하고 있는 업무여서 나한테 정말 필요한 내용이었는데, 코드 기반의 발표가 아니라서 전반적으로 아쉬운 발표였다.

아키텍처의 사례를 많이 언급하진 않았는데 개중에 component 레이어를 두는 건 괜찮은 방식 같아서 적용해보려고 한다.

 

수강생들에게 열렬한 지지를 받는 분이여서 꽤 재밌긴했다.

다만, 본인만의 기준이 강해서 다른 사람들이 각자의 철학과 기준을 갖도록 만들어 주시는 분은 아닌 듯했다. 

 

마치며

공부하러 간게 아니고 재미를 찾아 갔다면 꽤 괜찮은 시간이었을 것 같다.

 

왜냐면 이동욱 CTO님 세션을 제외하곤 세션이 전반적으로 아쉬웠기 때문이었다.... 

 

그렇지만 네트워킹 시간도 너무 시끄럽고 짧았다. 그리고 8명 끼리 묶어서 소통도 원활하지 않았다.

 

무엇보다 너무 더웠다. 

 

선물 교환식이랑 케이터링은 좋았는데... 내가 받은건 호두과자였다. 옆사람은 상쾌환을 받았다. 

 

404 NOT FOUND 티셔츠를 받은 사람과 왕 엔터키를 받은사람이 부러웠다...

 

재참석의사가 있냐면 인원이 100명이하면 생각해볼 것 같다. 200명은 너무 많은 것 같아요..