2024 항해 데브랩 후기
✔️ 2024.08.31일에 항해 데브랩 컨퍼런스에 다녀왔습니다.
다양한 네트워킹 활동이 있었지만, 발표 세션만을 간단하게 정리하며 남겨보고자 합니다.
[목차]
- AI와 자동화로 주니어 개발자 키우기 - 이동욱님
- 책임 분리의 마법: 깔끔한 폴더 구조 만들기 - 테오님
- 클린 아키텍처: 무한 성장하는 시스템의 비밀 - 허재님
1. AI 와 자동화로 주니어 개발자 키우기
개발바닥의 연예인 - 인프랩 CTO 향로(이동욱)님의 발표였습니다.
스타트업으로 시작한 서비스 회사에서, 인재풀을 확보하고 개발팀이 잘 성장하기 위해 고민했던 과정과 결과에 대해 이야기해 주셨습니다.
이동욱 CTO님이 처음 인프랩에 들어가서 인원을 채용할 때 몆가지 기준을 세워 시니어를 뽑기로 결정했지만, 그 당시 인력풀이 너무 비쌌으며 마땅한 인재를 찾기가 어려우셨다고 합니다.
그런 상황에서 고민을 하시다, 꼭 필요한 조건만을 남기고 다시 생각해보니 시니어 개발자 채용이 아닌 같이 일하기 좋은 동료를 뽑는다로 방향을 바꿨습니다.
| ✔️ 인프랩에서 원했던 인재풀 → 시니어 | ✔️ 좋은 시니어 이전의, 같이 일하기 좋은 동료 |
|
+ (연차 대비 훌륭한 전문성) 은 당연한 거라고 함 |
→ 원하는 인재풀을 바꾸다보니, 경력이 중요해지지 않았고 저연차(주니어) 혹은 신입을 많이 뽑게 되었다고 합니다.
"하지만, 이렇게 뽑아도 2년안에 퇴사한다면??"
보통 어느 조직에 들어가든 1년을 훈련 시켜야 1인분을 하기 시작하는데, 이 적응시간을 줄이자
📌 인프랩에서 AI를 활용해 온보딩 및 적응시간을 줄였던 방법
1) 입사하면 팀의 미션 공유함 (인프랩 개발팀의 미션과 가치)
https://tech.inflab.com/20231117-devteam-value/
인프랩 개발팀의 미션과 가치
안녕하세요 인프랩의 향로입니다. 최근 인프랩 팀은 적극적으로 개발자 채용을 하고 있습니다. 인프랩 채용 공고 지원하시는 분들 입장에서는 인프랩 개발팀은 어떤 것을 추구할까, 나와…
tech.inflab.com
2) 잦은 주기의 피드백 환경 조성
흔히, 신규 입사자를 위한 온보딩을 위해 "서포터"를 두기 마련인데 인프랩은 사람도 적었고 "서포터가 존재하지 않을 때" 도 도움을 받을 수 있는 환경을 고민했고 이를 AI 를 활용해서 해결했다고 합니다.
가. 코드 정적분석 (소나큐브)
- Sonar Cube 는 PR 시 해당 PR 코드에 대한 Sonar Rule 에 위반하는 악취 코드를 선별해줍니다.
- 또한 PR이 올라온 후, 수정되는 시간 즉 → PR 내부의 기술 부채를 해결하는데 얼마나 시간이 걸렸는지 등을 기록해주어 회고시 많은 도움이 되었다고 합니다.
나. 코드 레빗 AI (CodeRabbit)
- 코드 레빗 또한 PR(풀 요청) 검토 프로세스를 간소화하는 데 도움을 주기 위해 설계된 AI 기반 코드 검토 도구입니다. (Saas)
- 소나 큐브는, rule 기반으로 코드 레빗은 AI 기반으로 동작하는 분석 도구이기때문에 코드 수정 방향성 제시, 테스트 코드 제안 등 실질적으로 서포터의 코드 리뷰역할을 담당하였다고 합니다.
- 또한 PR 코드에대한 시퀀스 다이어그램을 만들어주어, 실질적인 코드리뷰어(사람)가 더 빠르게 구조를 파악할 수 있어 도움이 되었다고 합니다.
다. DORA 메트릭스
- 개발 생산성에 대해 분석하고 해당 통계를 대시보드로 보여주는 모니터링 툴입니다.
- 개발자의 생산성을 숫자로 표기할 수는 없지만, 계획된 기획 기간을 지키지 못했을 때 병목 지점을 파악할 수 있는 회고의 지표로 사용했다고 합니다.
- PR 반영이 늦었는지
- 빌드 시간이 늦었는지
- 커밋이 늦었는지
- 인프랩 테크 블로그 : https://tech.inflab.com/20240221-dora-metric-with-devlake/
라. 언제든지 답변 받을 수 있는 환경
- MetaSearch : 회사 내부 문서들을 통합하여 검색할 수 있는 환경
- AI Slack Bot : 사내 wiki, Jira, 용어정리 스프레드(사내 비지니스 용어)를 참고하여 답변할수있는 Slack Bot
- AI 데일리 분석 노트 : 하루 매출, 인프런 상세페이지 pv 와 uv, 학습 수, 첫 구매자 수, 신규 강의 수 등등에 대한 통계
→ 이런 결과를 위해 “문서화 강조” : AI Bot이 문서화를 토대로 답변하기 때문에, 한번의 문서화가 팀원 전체의 생산성을 개선
- 문서화에 대한 중요성을 모두가 인지하고 있어 작성하는 것이 당연한 문화가 조성됨
- 구두 논의 내용또한 슬랙에 기록
- 문서 최신화 환경이 구성됨 (신규 입사자가 업무를 진행하면서 Bot 의 답변이 이상혀면 본인이 최신 문서를 수정함)
→ 선순환 구조
3) 직접 구축보단 오픈소스
사내 프로세스를 직접 만들기 보다는 프레임워크 버전 업데이트에 대응이 가능한 오픈소스를 100% 활용하여 사용한다고 합니다
2. 프론트엔드 개발자 관점으로 보는 관심사의 분리와 좋은 폴더 구조
테오의 스프린트로 알고있었던 "테오님"의 발표셨습니다.
Front-end 의 발전에 따라 과심사의 분리가 어떻게 이루어져 나갔고
좋은 폴더구조를 확립하기위한 "프론트의 진화 패러다임?" 에 대한 흐름을 알 수있었던 발표였습니다.
1) 관심사 분리의 시작
- 역할이 다른데 역할에 유리한 방식대로 분리하자 (HTML, CSS, JS)
2) 컴포넌트
- 수평이 아닌 수직으로 관심사를 분리하자
- 하나의 컴포넌트 안에, 디자인 개발 문서 등등을 다 넣음
- 역할이 아닌 기능 중심의 모듈화
+ 여기서 더하여 계층적 관심사가 필요 (컴포넌트로 관심사를 분리했지만, 컴포넌트가 너무 많아지면 관리가 힘들어짐)
→ 아토믹 디자인 패턴
3) 의존성 단방향 관리가 중요해짐
- 데이터와 view 간의 의존성 분리를 하여 더 계층적 분리를 하기 시작
- 서버 데이터 관리 (하나의 기능 혹은 패러다임으로 해결하려 하지 않고, 관심사를 더 세부적으로 나누어 계층을 분리)
→ 이렇게 만들어진 폴더 구조
4) 관심의 방향성
관점에 따라 관심사는 달라진다
- 계층적 구조로 분리를 하다보면 독립적인 기능 구조가 필요하고
- 독립적인 기능구조를 잘 분리하여 재사용가능한 구조로 만들기 위해서는 계층적구조가 필요하다
- 이렇게 나누어진 2가지 관점을 모듈(수직)과 레이어(수평)라고 부르기 시작했다고 합니다.
- + 클린 아키텍처(데이터의 흐름을 관심사로 하는 새로운 관심사 계층)
서로 프롭스? 되어야한다?
4) FSD 아키텍쳐
- 하지만 폴더 구조는 1개다!
- 현대는 멋지게 분류했지만 특정 관심사로는 갈기갈기 찢어져, 파편화가 됨
- 한번 더 관심사의 분리가 필요해졌고, 최근 떠오르는 아키텍처가 FSD 아키텍처라 합니다.
마지막으로
✔️ 폴더 구조는 프로젝트 구조와 함께 성장해야 합니다.
✔️ 흔히하는 실수 - 모양이 같으면 같은 컴포넌트로 한다.
- Ui 컴포넌트와 도메인 컴포넌트는 다르다
- 컴포넌트 분리를 관심사에 따라서 분리하자
3. 클린 아키텍처 : 무한 성장하는 시스템의 비밀
항해 플러스 멘토로 계신 무신사 백엔드 개발자 - 허재님의 발표입니다.
"코드를 어떻게 짜야하는가" 가 세션의 주된 주제였고
유연한 코드를 위한 아키텍처 설계에 대한 이론 설명이였습니다.
좋은 코드란 ?
- 구조화되어있고, 각잡혀있는 이쁜 궁전 ??
- 아니다~ 남의 집 따라하면 그 끝은 남의 집이다.
- 우리만의 규칙을 세우고, 규칙을 따라야한다.
좋은 설계란?
- 미래를 멀리 보지 마라
- 처음부터 개쩌는 코드를 짤려고,, 구조 생각하고 클래스 생각하고,,,, 하지말고
- 언제든 변경 가능한 구조를 짤 수 있어야한다.
클린 아키텍처
- 로버트 C 마틴은 : 클린아키텍처에 대해 예제를 넣지 않았다.
- 스스로 생각하며 클린 아키텍처란 무엇인지 생각해보자
허재 님의 3가지 가이드라인
허재님은 코드를 작성할때 클린하고 유연한 구조를 잡기위해 3가지 기준을 세우셨다고 합니다.
1. 비즈니스 로직을 보호하자
2. 도메인을 충분히 숙성시킨 후 책임을 부여하자
3. 모든 객체에는 책임이 있어야한다. 함부로 많은 책임을 부여하지 말자
1) 비즈니스
1. 레이어드 아키텍처 : 왜 레이어를 나누어야할까?
- ✔️ DIP 를 지켜 비지니스 로직을 지키기 위해서
- 비지니스 로직은 외부 상황에서 보호하기 위해서 infra 를 분리한다.
2. 그럼 비즈니스는 어떻게 가둬야할까
- 단방향으로 의존성이 흐르게 설계하자
- Interface : 외부의 진입으로 부터의 명세
- Use-Case : 요구사항 구현을 위한 선언적 구조?
- Domain (User, Post, Reservation 등등,,)
- 유즈케이스 : 도메인 서비스 = 1:1 (이런 구조여야 책임 분리를 잘한 것)
- 서비스는 진입점
- 컴포넌트가 실제 비지니스 로직
- 흔히 Domain 에 비지니스 로직을 두는데, 이를 한단계 내려 Compnent 로 두었다고 하셨습니다.
- Componet
- 서비스의 재사용이 가능한 비지니스 로직 (각각의 기능을 세부적으로 나눈 것)
- infrastructure
- 인프라 접근도 컴포넌트만 접근할 수 있어야한다.
- 인프라(DB) 가 바뀌는 경우가 거의 없긴한데, 현실세계의 문제를 강결합으로 풀지 않기 위해 컴포넌트를 나누고 인프라 의존성 공부를 한다.
2) 숙성
- 비지니스를 설계할때, 충분히 성숙된 도메인이었을 때 도메인으로 내보내야한다.
- 콘서트 예약 시스템에서 [예약] 시스템을 도메인으로 보았다면 (domain - reservation, user, concert)
- ‘여기서 만약 숙박 예약이 추가된다면??
- 위의 구조에서 reservation 은 예약이 아니라, 콘서트 예약이다.
- 즉 예약이 될만큼 충분히 숙성되지 않았다
- 핵심은 책임
- 함부로 일반화 시키지 말자
3) 책임
- 예약(도메인)이 가진 특징이 뭘까 고민
- 컴포넌트로 세부 사항 비지니스를 구현
- 컴포넌트를 갈아끼워서 요구사항을 충족할 수 있도록
- 모든 객체에는 책임이 있어야한다.
- 도메인은 충분히 숙성시켜야 한다. 함부로 도메인에 책임을 과하게 주면 안된다.
다시, 좋은설계란?
- 개발을 말랑말랑하게
- 변경에 유연하게 대응할 수 있는 시스템 구조를 설계해야한다는 말 같습니다.
👏 내 생각
허재님 강의의 요점은, 좋은 코드와 좋은 설계란 변경에 유연하게 대처할 수 있는 구조이며
그런 구조란, 미래의 선택을 미리 하지 않도록 하는 것이고 → 그러기 위해서는 선택되지 않은 역할을 도메인에 함부로 주는 실수를 해서는 안된다. 라고 생각됩니다.
현실 세계에서의 더 많은, 자세한 책임을 준다는 "디테일한 역할을 부여하는 것" 이고 소프트웨어 세계에서 많은 책임을 준다는 "추상적으로 역할을 부여한다" 이 차이를 조심해야할 것 같습니다.
핵심은 도메인에 대한 "비지니스 로직을 분리하자", "도메인은 충분히 숙성시킨 후 추출이 가능해지면 상위 도메인으로 추출하자"
Component 에 비지니스 로직을 부여한다는 것은, 코드를 보지 않아 잘 이해가 가지 않았지만 infrastructure에 대한 접근이 Compnent 에서만 가능한걸로 보아 Entity 에 대한 책임을 가지고 그를 이용해 도메인 레이어에서 재상용이 가능하게 만든 것이 아닌가,, 조심스럽게 유추해보았습니다.
다소 아쉬운 점이 있었던 컨퍼런스였지만, 좋은기회로 가게되어 포스팅으로 남겨보았습니다.
끝!