- Published on
Devfest Incheon / Songdo 2024 후기
- Authors
- Name
- 불타는 라쿤들
어제 Devfest Incheon / Songdo 2024를 다녀와서 인상깊었던 2가지 세션을 개발팀 팀원들과 공유해 봅니다 ☺️
1. DevRel이 말하는 개발자의 문장력 - 최가인님
오늘의 목표
- 나한테 어떤 글 습관이 있는지 인지
- 최소한의 원칙으로 내일은 오늘의 문장보다 조금 더 나은 문장으로 업그레이드해서 커뮤니케이션 할 수 있다
우리는 왜 글을 쓰는가
- 조지 오웰, 나는 왜 쓰는가
- 개인의 이기심
- 미학적 열정
- 역사적 충동
- 정치적 목적
쉽지 않은 커뮤니케이션
Scrum
Squad : 작은 애자일 팀
역할, 우선순위, 프로세스, 결과물, 가지고 있는 정보 등등… 차이가 존재함
각 플랫폼에 맞는 글의 형식, 구성, 분량이 존재함
읽는 사람이 부담없고 받아들이기가 쉬워야 함
당근, 노션에서는 노션으로 발표를 진행함
메일
- 드림/올림
- 배상 (→ 올림으로 순화해서 사용)
맥락을 품어라
- (슬랙, 디스코드) 스레드로 근거를 설명
본질이 중요하다
- 허세를 부리지 말자
- Charles Derver, 대화 나르시시즘
- 주도권을 자신에게 돌려놓으려는 욕망
- 엔지니어에게 주로 보임
- 본인은 모르는 경우가 많다
- 자신의 언어에 국한되지 않는, 사용자 중심적인, 엔드 유저에게 전해질 수 있는 표현을 사용해야 한다
- William Knowlton Zinasser, 공부가 되는 글쓰기
- 각종 명사와 현학적인 전문용어로 점철된 글 == 자신이 조직 내에서 중요한 존재라는 느낌을 가질 뿐, 아무 뜻도 없는 단어
- 엔지니어에게 주로 보임2
- Charles Derver, 대화 나르시시즘
- 생존에 필요한 문장
- 우리에게 필요한 문장은 예술이 아니다
- 표현법 == 머릿속 생각을 누군가에게 전달할 수 있는 상태로 치환하는 일
- 무엇을 말할 것인가
- 호의나 존경심을 느낄 때
- 독창적인 관점이 있는가
- 새로운 깨달음을 주는가
- 나를 진정으로 배려하고 나의 시간을 효과적으로 아껴주었는가
- 우리에게 필요한 문장은 예술이 아니다
- 불필요하고 예민한 이야기를 세심하게 전달할 수 있어야 한다
- SPIKES Model
- Setting (편안한 환경 조성)
- Perception (환자의 인식 정도) → 그 사람이 뭘 알고 있는지 먼저 인지
- Invitation (얼마나 알고 싶어 하는가)
- Knowledge (정확한 정보 전달)
- Emotion (공감)
- Strategy and Summary (계획 수립과 요약)
- ‘안녕하세요’ 인삿말 하나만 넣어도 그 뒤에 날카로운 얘기를 해도 조금의 편안한 환경을 조성할 수 있다
- 기본적인 원칙만이라도 잘 지키자
- SPIKES Model
본인의 관점과 경험을 담아라
- 테크 블로그를 보면, 보통 자신의 ‘관점’이 없다
- 직접적인 관계가 있어야 메시지의 힘이 강해진다
- 설득력을 높이기 위해 많이 쓰고 많이 퇴고하라
- 언어화 과정
- 무의식 속 표현 저장고를 가득 채우자
- 쓰기가 쉽지 않다면 많이 보고 많이 분석하라
- 퇴고 체크리스트
- Why와 What에 글 쓰는 시간의 80%를 투입하지만, 그만큼 중요한 퇴고를 놓치지 말 것
- 자신이 무의식적으로 반복하는 안 좋은 표현을 골라내라
- 같은 글을 오래 들여다 보면 확증 편향을 빠지기 쉬우니 동료를 활용하라
- 언어화 과정
글의 얼굴은 ‘제목’입니다
- 제목이 중요하다
글의 리듬을 살려라
- 쉼표를 언제 찍지?
- 같은 자격의 어구를 열거할 때
- 비전, 미션, 핵심 가치 등
- 짝을 지어 구별할 때
- 테스트 커버리지 향상과 개발 속도 증가, 완벽한 테스트와 빠른 출시는 상극이다
- 이웃하는 수를 계략적으로 나타낼 때
- 5, 6월
- 열거 순서를 나타내는 어구 다음
- 특별한 효과를 위해 끊어 읽는 곳을 나타낼 때
- 한 문장 안에서 앞말을 같은 어구로 다시 설명할 때
- 같은 자격의 어구를 열거할 때
- 말줄임표도 잘 쓰자
- 이거 누가 한 거예요?
- 이거… 누가 한 거예요…?
책 추천
- 김선영(글밥), 어른의 문장력
2. Compose UI 조합 심화 - 김수현님
용어 정리
Composition
: 객체 지향 프로그래밍에서 객체들을 조합하여 복잡한 기능을 구현하는 Composition- 객체를 조합하여 구조를 설계하는 방식
컴포넌트
는 UI 컴포넌트
중복을 제거한 컴포넌트 분리
DRY 원칙 : 중복을 제거하여 재사용 가능한 코드 블럭을 만들어라
ex) 공통점 & 차이점이 있는 컴포넌트 (프로필 카드인데, ‘내’ 프로필인 경우에만 하단에 수정 및 공유 버튼 추가되는 컴포넌트)
- 가장 직관적인 해결책 - 조건문
- But, 무분별한 조건문은 컴포넌트의 복잡도 증가로 이어진다 (조건문 지옥)
- DRY 원칙의 함정 → 만약 두 코드가 동일한 이유가 수정되어야 한다면 ‘중복’이지만, 수정되는 이유가 다르면 중복이 아님!
⇒ 컴포넌트 내 조건문 추가는 서로 다른 수정 이유를 갖는 컴포넌트들이 묶였다는 뜻 (해당 로직은 재사용에 적합하지 않다!)
- 변경에 유연하게 대응할 수 있는 UI 구조가 필요하다!
컴포넌트 조합 아이디어 1 - Slot 패턴
Slot 패턴
특정 영역을 외부에서 자유롭게 구성할 수 있도록 하는 디자인 패턴
- 부모 컴포넌트는 자식 컴포넌트의 구체적인 구현에 대한 의존성 없이 UI 구조 정의하는 식으로 구현 가능
bottomContent
라는 Slot으로 받자 → 캡슐화- 요구사항이 바뀌어도 Slot으로 전달되는 컴포넌트만 수정하면 된다
활용 사례 - Compose Material Design Components
- 내부에서 대부분 Slot 패턴 활용
Slot 패턴을 쓰기 좋은 상황
- 컴포넌트의 레이아웃 구조는 유지하면서 특정 영역의 컨텐츠만 변경해야 하는 경우
한계
- 요구사항 추가 가정
- 차이점이 여러 군데에서 발생하는 경우
- UI 변경 사항이 발생할 때마다 Slot을 추가해야 하는가?
컴포넌트 조합 아이디어 2 - Compound Component 패턴
Compound Component 패턴
- 하나의 컴포넌트를 여러 조각으로 나눈 후, 외부에서 이들을 조합
- 부모 컴포넌트가 상태를 관리, 자식 컴포넌트는 상태를 받아 UI 렌더링
- 자식 컴포넌트들을 상태 관리 로직에서 분리되어 UI 표현에만 집중
- React에서는 일반적으로 Context API를 통해 구현
Kotlin
- Scope 인터페이스 생성
- 자식 컴포넌트들이 접근할 수 있는 함수 등등 가지고 있음
- 대상 리시버 지정
- 자식 컴포넌트 (상태 접근)
- 자식 컴포넌트들은 부모 컴포넌트의 상태를 공유하면서도, 부모 컴포넌트에 직접 의존하지 않음
- 새로운 요구사항이 생겨도 자식 컴포넌트를 유연하게 조합 가능
Compound Component 패턴이 언제나 적합하진 않다
- 비즈니스 로직과 밀접하게 연결된 경우 : 복잡도가 증가함에 따라 Scope 관리가 어려움
- UI는 동일하지만, UI에서 참조하는 클래스가 변경되는 경우
- Scope 인터페이스 수정, 관련된 모든 자식 컴포넌트에 영향!
- 부모의 상태가 변경되더라도 자식들은 그 변경을 감지할 수 없는 경우가 있을 수 있음
- 컴포넌트의 상태가 자주 변경될 가능성이 있는 경우 State Wrapping 고려
- 잘 사용하기 위해서는 리컴포저블과 선언형에 대한 이해가 필요함
활용 사례 - 디자인 시스템
- 여러 하위 컴포넌트들을 부모 컴포넌트와 조합해서 사용할 때 진가를 발휘한다
- 외부에서 사용하기 편리하고 일관된 API 제공 가능
활용 사례 - Lazy lists
LazyColumn
,LazyRow
LazyListScope
컴포넌트 조합 아이디어 중간 정리
- 사진
Slot 패턴과 Compound Component 패턴
- 둘은 서로 배타적인 관계가 아니라 상호 보완적인 관계
- Slot 패턴은 컴포넌트의 재사용성을 위한 기반 마련
- Compound Component 패턴은 이를 바탕으로 더욱 유연한 UI 구축 가능
- Stateless 컴포넌트는 UI에 집중, Stateful 컴포넌트는 상태 관리 로직 캡슐화
UI Composition Best Practices
Stream Video SDK
- 화상 통화, 오디오 룸 및 라이브 스트리밍 앱을 구축하기 위한 SDK
- 화상 통화 기능의 하단 액션 바 예시
- Slot 패턴 사용
- 오픈소스 프로젝트를 통해 디자인 패턴과 소프트웨어 아키텍처를 비롯한 다양한 모범 사례를 무료로 보고 아이디어를 얻을 수 있다
되돌아보기: 조건문이 정말 나쁜가? 중복이 정말 나쁜가?
중복은 코드의 겉모습이 아닌, 코드 수정의 이유가 같은지에 따라 판단
핵심은 조건문 자체를 피하는 것이 아닌, 조건문의 남용으로 인해 발생하는 복잡성 증가를 경계해야 한다는 것
- 일단은 조건문으로 적용하고, 복잡성이 증가하면 패턴을 적용하는 것도 좋다
굳이 복잡한 패턴을 적용하는 게 더 나쁜 경우도 있다 (간단한 조건문으로 끝날 수 있는 경우도 있다)
UI 개발에서 지나치게 DRY 원칙에 집착하면, 오히려 코드의 복잡성을 높이고 유연성을 떨어뜨릴 수 있다
나의 프로필과 다른 사람의 프로필 UI가 현재는 유사하지만, 미래의 비즈니스 요구사항 변경에 따라 두 UI가 완전히 다른 형태로 진화할 가능성도 있다
결론
- 각 패턴의 장단점을 정확히 이해하고, 컴포넌트의 역할과 책임, 예상되는 변경 사항을 고려하여 적절한 패턴을 선택해야 한다
- 패턴 및 원칙 중심의 개발보다는, 구현하고 보니 패턴화 되어 있다 → 이런 게 더 좋다