티끌모아 로키산맥 🏔
search
로ᄏl
배움에 끝은 없다... 개발 또한 그러하다.
Today
Yesterday
2022년부터 꾸준히 참가신청을 했으나 항상 당첨이 안됐었고... 설마 3연속 탈락이겠어~라는 생각과함께 2024 인프콘도 티켓팅 대열에 합류했다.
하지만 결과는...
이렇게 올해도 인프콘 다녀온 사람들의 후기글을 보며 부러워하는 일만 남았다고 생각하고 포기하고있던 찰나!
혹시라도 전산 착오라는 이야기가 나올까봐 잽싸게 초대권을 등록하고 인프콘 행사날만 기다렸다.
2024 인프콘의 발표 세션들은 2024 인프콘 발표/프로그램 세션에서 확인할 수 있는데 몸이 5개면 좋을련만...
닝겐의 한계로 각 세션별로 한 개씩밖에 듣지 못했고 아래와 같이 총 5개의 세션을 들었다.
설계를 잘하는 방법은 "설계를 하지 않는 것!" 이다. 라며 시작부터 강한 어그로(?)를 끄셨던 재민님은 개념과 격벽의 이야기를 시작으로 웹툰 서비스, 커머스 등등의 사례로 예시를 들며 발표를 진행해주셨다.
개념: 웹툰 서비스를 만든다고 생각해보자.
작가, 연재, 작품, 결제, 구매, 리뷰.... 더 나아가서는 PD, 랭킹, 포인트, 소장, 만료 같은 개념들을 떠올려볼 수 있고 자연스럽게 이를 그룹핑하는 시도를 하게될 것이다. 개념을 생각하면 할 수록 더 많은 개념그룹이 생기게된다.
격벽: 격벽은 접근에 대한 제어와 통제의 역할
격벽을 만들었다면 변경한 개념과 관련된 코드만 수정이 생긴다.
하지만 개념과 격벽을 잘못 관리하고있다면 전혀 다른 개념 그룹이 수정된다거나 혹은 같은 개념 그룹이 수정되지 않는다거나하는 상황이 발생한다.
예시) 대출 - 사례
신청, 실행, 상환을 대출의 행위 정도로 바라봤으나 대출을 수정했을 때, 신청 서비스, 실행 서비스, 상환 서비스가 대출의 수정에 모두 영향을 받았고 대출이라는 개념을 너무 크게 잡은 것이 아닌가하는 의심이 발생 ➡️ 행위로 분리했던 신청, 실행, 상환을 행위가 아니라 대출과 같은 크기의 개념으로 뽑아냄 상환이 실패하면 상환 재시도, 추가 이자 등을 실행하게되는데, 이 개념으로 넘어갈 때 까지 상환 개념에서는 상황 성공 혹은 실패 상태가 나왔을 때, 개념적으로 자기의 역할을 다 한 것! 상환 실패에 대한 재시도 연체라는 새로운 개념을 만들어냄. 상환 실패의 결과물로 연체를 만들어 냄. 상환 재시도, 추가 이자 --> 연체 납부와 연체 이자 (행위) 상태는 개념이 아니다. 개념이 상태에 표기되는 것
하나의 개념이 많이 쓰이면 분리를 검토하자
상태에 의해 개념이 생기면 격벽을 세워보자.
1 급 개념 > 2급 개념 > 3급 개념 ... > N급 개념
개념이 많은 소프트웨어는 개념 계층을 나눠서 생각해야한다.
비즈니스를 지탱하는 것을 개념으로 지칭하는 것이 맞다.
외부연동사는 개념없는 곳에 속할 확률이 높다. (외부연동사는 커머스 사례에서 언급된 케이스)
격벽보다 더 높은 수준의 참조 불가의 벽 의 안쪽에 외부 연동사를 둬야한다.
외부 연동사는 (수집 및 정제 영역으로 보고) batch를 통해서 db에 데이터를 긁어 저장하는 용도 정도로만 써야한다.
참조 불가의 벽은 별도의 모듈로 분리해서 확실하게 격벽을 쳐주는 것이 좋다. core 모듈에 외부에 의존하는 개념이 생기면 안된다.
core 모듈에 외부에 의존하는 개념이 생기면 안된다.
미묘하지만 더 중요 혹은 덜 중요한 개념이 있다.
모든 것이 개념이 되진 않기 때문에 핵심 개념이 되는 것을 찾아서 관리해줘야하고 올바르게 개념이있는지 지속적으로 체크해줘야한다
외부나 핵심 비즈니스를 관리해서 더 명확하게해야한다.
분석 > 설계 > 구현 하지말고 지금할 수 있는 최소한의 구현을 먼저 했으면 좋겠다.
개념 + 격벽을 활용한 구현을 진행하고 증명 + 피드백 하면서 << 테스트 코드로 반복하면서... => (자연스럽게) 설계가 나오게 된다.
개념을 잡고 >> 격벽을 세워 >> 구현을 채워나가 >> "설계를 완성"한다
Q. 디버깅을 잘하는 사람과 못 하는 사람의 차이가 큰 게 무엇인지 ?
디버깅은 마법이 아닌 마술이다. (본인도 어떻게 하는지 모르는)
디버깅 고수들은 원인 파악에 시간을 많이 쏟는다. (전문성의 핵심)
(디버깅 정의)
디버깅 = 의도대로 동작하지 않는 무언가를 정상화하는 행위
정상적인 상황이 무엇인지 명확히 정의를 내려야한다.
정보 수집, 가설 설정, 가설 검증 <=> 어떤 조건에서 어떤 순서로 어떤 일들이 벌어져야 하는가? => 심적 표상
위의 단계는 심적 표상을 만들어내는 것
(사전) 작업을 위한 계획 세우기 (시간 분배 등) <-- 적절하게 멈추고 회고하기
고수들은 1~5 단계를 꼭 순서대로 진행하는 것은 아님.
1 <-> 5단계를 왔다갔다하며 진행함
컴퓨터<< 같은 입력, 같은 출력 정량적 지표는 승리 (실행 시간, FPS, ...)
사람<< 같은 행동, 다른 결과 정량적 지표는 패배 (PR 숫자, 근무시간, ...)
"동료들이 당신을 좋아하나요?"
Q. 이런 피드백이 들어왔는데, 이렇게 해보는 것은 어떠세요?
신뢰관계 형성X: 아, 좋은 말씀 감사합니다...
신뢰관계 형성O: 아, 좋은 말씀 감사합니다! 해볼게요!
팀 리더의 의사결정을 바로 수용
솔직한 이야기를 털어놓음
인정과 피드백
이분을 어떻게 변화시킬까요?
이분의 퍼포먼스를 어떻게 높일 수 있을까요?
`팀원들은 나를 믿고 좋아하는가?`
유능, 소통, 예측, 관심, 안전, 유사,
팀 리더가 개인 기여
Q. 리더는 역량적으로 모든 면에서 유능해야 하나요?
역량 그 자체보다는, 팀원의 문제를 해결해주는 것이 중요하다.
(성공한 스타트업은 진통제성 제품을 만드는 경우가 많다 -> 진통제성 문제는 풀기만해도 사람이 몰려든다)
> 팀원 사이의 갈등을 중재해서 해결,
> 미팅이 너무 많아서 힘들어하는 팀원의 일정 조정
> 팀 안에서 라포를 형성할 기회 형성
> 프론트엔드-백엔드 개발자 사이의 협의 조율
Q. 케미가 잘 맞는 팀원이 있고, 그렇지 않은 팀원이 있는데, 모든 팀원에게 다 개인적으로 관심을 가져야하나요?
Q. 팀원의 문제에 공감이 잘 안되는데, 어디까지 공감을해야 할까요?
말하기 방식에 초점을 맞출 필요가있다.
동감이 아닌 공감
* 동감: 상대방과 똑같이 감정 느끼기
* 공감: 상대방의 감정을 이해해주기 (T인 개발자여도 곰감은 배울 수 있다)
팀원의 고민에 대한 의식적인 관심
1 on 1이나 커피챗에서 팀원이 고민을
1주 뒤나 다음에 마주쳤을 때, 꼭 언급해서
신경쓰고 있다는 '티'를 내면 신뢰의 수준이 바뀐다.
(관심 받기를 싫어하는 사람은 없다)
양쪽이 번갈아가면서 이야기하고 있는가?
양쪽이 말하는 길이가 비슷한가?
티키타카가 잘되는가...?
리더와 팀원이 **유사한 점을 공유**할수록
리더와 적절한 TMI는 **대화의 마중물**
팀원이 리더 앞에서 자신의 시시콜콜한 이야기를 먼저 꺼내기는 어렵다.
팀원이 현재 상황을 안전하다고 느낄수록 신뢰가 생긴다.
Q. 팀 리더로서 어려운 이야기를 피해야 하나요?
Q. 팀원이 잘 할 수 있을지 걱정되는데, 팀원의 업무에 어디까지 간섭해야 하나요?
안전하게 이야기할 수 있고, 안전하게 간섭할 수 있다고 생각함.
토스에서는 이 3가지 중 어떤 방법을 써서 지시를 내릴 것인지 공유하려고 노력하는 중.
진실된 칭찬으로 팀원의 심리적 안정감을 높일 수 있다. (진실된이 중요하다)
모든 팀원에게는 칭찬할 부분이 있다. (팀원의 단점은 또한 장점이 된다)
신중한 팀원 <-> 우유부단한 팀원
행동이 빠른 팀원 <-> 성급한 팀원
사교적인 팀원 <-> 말이 많은 팀원
진중한 팀원 <-> 말이 없는 팀원
리더의 말과 행동이 일치하고,
팀원이 리더의 행동을 예측할 수 있을 때 신뢰가 증가한다.
1. 상호가 동의할 수 있는 사실부터 시작
2. 기대수준에 대한 명확한 정의
3. 상호 소통
팀원의 성공이 리더의 성공이고,
리더의 성공이 팀원의 성공일 때 신뢰가 증가한다.
나의 목표를 팀원에게 설득하는 것이 아닌
나와 팀원의 목표를 아우르는 **공동 목표의 설정**
동욱님 왈
일반적인 클린 코드 인식: 구현 능력과 속도가 떨어진다 ?
클린 코드를 처음 이야기한 사람: 켄트 벡
켄트벡 왈
작동하는 깔끔한 코드(= Clean Code That Works) 론 제프리즈의 핵심을 찌르는 이 한마디가 바로 TDD의 궁극적인 목표
Clean Code That Works
➡️ 코드 결벽증, 원칙 지향 개발 ?
클린코드가 강조하는 것은 유지보수성(maintainability)
유지보수하기 좋은 클린 코드는
개발 생산성과 유지보수성은
유지보수성 <-- 코드 --> 생산성
유지 보수성과 개발 생산성은 서로 영향을 주는 관계이다.
부채(Dept)
부채를 상환하는 행위를 리팩터링이라고 함.
(이 내용도 포함된다...)
부채가 지속적으로 효과를 발휘하려면 **리팩터링(부채상환)**이 동력이 되어야 한다
`유지보수성`이 좋은 코드는 변경가능성이 좋다
빠르게 변경되는 코드는 개발 생산성이 좋다
(이미 조영호님이 이에 같은 이야기를 하신적이 있음)
일부 기능을 완벽하게 만드는 것으로 시작 X
테스트
그런데 테스트를 작성하면 구현 능력과 구현 속도가 또...
테스트를 빠르고 효과적으로 작성하면서 개발하는 능력이 필요
테스트는 연습이 필요하다.
개발 시작은 빠르고 간단하게 ... <<
서로 영향을 주는 것이 세 가지만 있어도..
팀워크(teamwork)
코드 >> 유지보수성, 생산성, 팀워크 (풀기 어려운 문제...)
클린 코드의 많은 원칙은 팀의 동료 개발자와 관계를 두고 말한다.
나만을 위한 클린 코드는 없다
클린 코드의 많은 원칙은 상황에 따라
팀과 함께 결정하고 탐험하고 학습하고 성장한다 <-- 토비님 마인드
함께 탐험하는 것을 즐거워하는 팀
어떤 외국의 여성 개발자의 발표에서..
Great teams make great people.
교양있는 개발자
교양: 자신의 말을 하더라도 다른 사람의 기분을 나쁘지 않게 하는 것
-> 쉽지는 않다. 교양이 저절로 생기는 것은 아니다.
함께 코드를 작성하고, 읽고, 변경할 동료 개발자들에게 친절한 코드 를 만들었으면 좋곘다.
[토비님의 당부]
항상 친절하세요.
동료에게
자신에게
(스프링 개발에도) 클린 코드의 선순환 구조, 삼체 균형 모두 동일하게 적용 가능
자기 책임에 충실한 오브젝트로 구분하고 의존관계를 유연하게
클린 (자동) 구성 정보
계층과 모듈 경계에는 API, 즉 인터페이스를 사용
테스트를 안 만들거면 스프링을 뭐하러?
스프링 가치의 절반은 테스트.. << 토비님의 의견
DB 테스트에는 @Transactional을 사용 (재민님, 동욱님은 반대의 의견을 내셨었고 토비님은 이에대한 생각을 SNS에 밝히신적이 있다)
클린 스프링에서는 트랜잭셔널을 사용해야한다. (ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 강하게 어필하심)
클린 코드는 항상 코드에 관심을 가지고 보살피는 사람이 작성한 것처럼 보인다.
(조영호님 발표 때는 세션 막바지에 가까워져서 체력이 바닥난터라 살짝 지쳐있어 누락된 내용이 많다 🥲)
Q. 객체지향은 여전히 유용한가요?
A. 왜 그런 생각을 하셨어요 ?
객체지향을 배울 필요는 있다. (객체지향 언어를 쓰기 때문에)
맡으시는 도메인 혹은 팀의 특성에 따라서 정말 배워야하는가? 가 궁금했을 것으로 추측
가장 큰 포인트는 변경이다.
데이터와 프로세스를 별도의 클래스로 구현하는 방식
데이터를 바꾸면 프로세스도 같이 바껴야한다. (= 결합도가 높다)
캡슐화 때문에 데이터가 변경되도 하나의 클래스만 변경
객체지향 설계에서는 적합한 클래스로 분배되고, 분산된다.
객체지향 설계는 유연성을 위해서 큰 리팩터링이 필요하다. 그에반해 절차지향 설계는 국소적 리팩터링이 필요하다.
다른 코드를 수정하지 않고 데이터 변경과 타입 확장 가능
반면에 절차적인 코드는 무조건 내부 코드를 수정해야한다.
설계가 계속 발전하고 진행할 수록 코드의 규모만 커지지 일관성을 유지할 수 있다.
절차지향 설계는 그런 룰을 강제하기가 어렵다.
다형성과 기능 추가 사이의 긴장
타입 계층 전체 수정
절차적인 설계가 객체지향 설계보다 더 낫다
내가 다루는 것이 데이터라면 절차적인 설계로 짜는 것이 좋다.
데이터의 응집도 단위로 클래스를 분리한 것이 아니라 행위 단위로 클래스를 분리했기 때문에
특정한 목표에 맞게 절차적, 객체지향적 설계를 혼합해서 쓰고있다!
도메인 레이어가 필요없을 수 있음.
(질문을 이렇게 바꾸는게 더 적절하다! )
객체지향은 여전히 유용한가요? --> 객체지향은 언제 유용한가요? (혹은 언제 유용하지 않은가요?)
a를 배우는게 좋을까요? b를 배우는게 좋을까요? 등에 대한 질문...
일단 배워봐라
도구하나 배우라고 생각하는게 좋다.
어떤 설계도 어떤 기법도 모든 경우를 커버하지 못한다.
코드의 목적과 변경의 방향성에 따라
언제 어떤 기술을 사용할지 결정하세요
유용하지 않은 기술은 없다.
언제 어떤 경우에 유용한지를 생각하지 않는 경우가 많은 것 같음.
2024 인프콘이 끝난지 아직 하루도 안지났는데 벌써부터 2025 인프콘이 기대되는 것은 오늘 너무나도 끝내주는 발표들을 만난 탓이 아닐까 싶다. 즐거웠고 다른 세션들은 영상나오면 하나씩 챙겨볼 예정이다.
도메인 지식 탐구를 위반 이벤트 스토밍(Event Storming) 요약 (5) | 2021.07.16 |
---|