Create 20241222.mdx

data/blog/20241222.mdx

@@ -0,0 +1,234 @@
+> 어제 Devfest Incheon / Songdo 2024를 다녀와서 인상깊었던 2가지 세션을 개발팀 팀원들과 공유해 봅니다 ☺️
+
+# 1. DevRel이 말하는 개발자의 문장력 - 최가인님
+
+## 오늘의 목표
+
+1. 나한테 어떤 글 습관이 있는지 인지
+2. 최소한의 원칙으로 내일은 오늘의 문장보다 조금 더 나은 문장으로 업그레이드해서 커뮤니케이션 할 수 있다
+
+## 우리는 왜 글을 쓰는가
+
+- 조지 오웰, <나는 왜 쓰는가>
+    - 개인의 이기심
+    - 미학적 열정
+    - 역사적 충동
+    - 정치적 목적
+
+## 쉽지 않은 커뮤니케이션
+
+- Scrum
+- Squad : 작은 애자일 팀
+- 역할, 우선순위, 프로세스, 결과물, 가지고 있는 정보 등등… 차이가 존재함
+
+- 각 플랫폼에 맞는 글의 형식, 구성, 분량이 존재함
+- 읽는 사람이 부담없고 받아들이기가 쉬워야 함
+- 당근, 노션에서는 노션으로 발표를 진행함
+
+### 메일
+
+- 드림/**올림**
+    - 배상 (→ 올림으로 순화해서 사용)
+
+## 맥락을 품어라
+
+- (슬랙, 디스코드) 스레드로 근거를 설명
+
+## 본질이 중요하다
+
+- **허세를 부리지 말자**
+    - Charles Derver, <대화 나르시시즘>
+        - 주도권을 자신에게 돌려놓으려는 욕망
+        - 엔지니어에게 주로 보임
+        - 본인은 모르는 경우가 많다
+        - **자신의 언어에 국한되지 않는, 사용자 중심적인, 엔드 유저에게 전해질 수 있는 표현을 사용해야 한다**
+    - William Knowlton Zinasser, <공부가 되는 글쓰기>
+        - 각종 명사와 현학적인 전문용어로 점철된 글 == 자신이 조직 내에서 중요한 존재라는 느낌을 가질 뿐, 아무 뜻도 없는 단어
+        - 엔지니어에게 주로 보임2
+- **생존에 필요한 문장**
+    - 우리에게 필요한 문장은 예술이 아니다
+        - **표현법 == 머릿속 생각을 누군가에게 전달할 수 있는 상태로 치환하는 일**
+        - **무엇을 말할 것인가**
+    - 호의나 존경심을 느낄 때
+        - 독창적인 관점이 있는가
+        - 새로운 깨달음을 주는가
+        - 나를 진정으로 배려하고 나의 시간을 효과적으로 아껴주었는가
+- **불필요하고 예민한 이야기를 세심하게 전달할 수 있어야 한다**
+    - SPIKES Model
+        - Setting (편안한 환경 조성)
+        - Perception (환자의 인식 정도) → 그 사람이 뭘 알고 있는지 먼저 인지
+        - Invitation (얼마나 알고 싶어 하는가)
+        - Knowledge (정확한 정보 전달)
+        - Emotion (공감)
+        - Strategy and Summary (계획 수립과 요약)
+    - ‘안녕하세요’ 인삿말 하나만 넣어도 그 뒤에 날카로운 얘기를 해도 조금의 편안한 환경을 조성할 수 있다
+    - 기본적인 원칙만이라도 잘 지키자
+
+## 본인의 관점과 경험을 담아라
+
+- 테크 블로그를 보면, 보통 자신의 ‘관점’이 없다
+- **직접적인 관계가 있어야 메시지의 힘이 강해진다**
+- **설득력을 높이기 위해 많이 쓰고 많이 퇴고하라**
+    - 언어화 과정
+        - 무의식 속 표현 저장고를 가득 채우자
+        - 쓰기가 쉽지 않다면 많이 보고 많이 분석하라
+    - 퇴고 체크리스트
+        - Why와 What에 글 쓰는 시간의 80%를 투입하지만, 그만큼 중요한 퇴고를 놓치지 말 것
+        - 자신이 무의식적으로 반복하는 안 좋은 표현을 골라내라
+        - 같은 글을 오래 들여다 보면 확증 편향을 빠지기 쉬우니 동료를 활용하라
+
+## 글의 얼굴은 ‘제목’입니다
+
+- 제목이 중요하다
+
+## 글의 리듬을 살려라
+
+- **쉼표를 언제 찍지?**
+    - 같은 자격의 어구를 열거할 때
+        - 비전, 미션, 핵심 가치 등
+    - 짝을 지어 구별할 때
+        - 테스트 커버리지 향상과 개발 속도 증가, 완벽한 테스트와 빠른 출시는 상극이다
+    - 이웃하는 수를 계략적으로 나타낼 때
+        - 5, 6월
+    - 열거 순서를 나타내는 어구 다음
+    - 특별한 효과를 위해 끊어 읽는 곳을 나타낼 때
+    - 한 문장 안에서 앞말을 같은 어구로 다시 설명할 때
+- **말줄임표도 잘 쓰자**
+    - 이거 누가 한 거예요?
+    - 이거… 누가 한 거예요…?
+
+## 책 추천
+
+- 김선영(글밥), <어른의 문장력>
+
+<br />
+
+# 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을 추가해야 하는가?
+
+    → Component API가 오히려 복잡해질 수 있다
+
+
+## 컴포넌트 조합 아이디어 2 - Compound Component 패턴
+
+### Compound Component 패턴
+
+- 하나의 컴포넌트를 여러 조각으로 나눈 후, 외부에서 이들을 조합
+- 부모 컴포넌트가 상태를 관리, 자식 컴포넌트는 상태를 받아 UI 렌더링
+    - 자식 컴포넌트들을 상태 관리 로직에서 분리되어 UI 표현에만 집중
+- React에서는 일반적으로 Context API를 통해 구현
+
+### Kotlin
+
+1. Scope **인터페이스 생성**
+    - 자식 컴포넌트들이 접근할 수 있는 함수 등등 가지고 있음
+2. 대상 리시버 지정
+3. 자식 컴포넌트 (상태 접근)
+
+- 자식 컴포넌트들은 부모 컴포넌트의 상태를 공유하면서도, 부모 컴포넌트에 직접 의존하지 않음
+- 새로운 요구사항이 생겨도 자식 컴포넌트를 유연하게 조합 가능
+
+### 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가 완전히 다른 형태로 진화할 가능성도 있다
+
+## 결론
+
+- 각 패턴의 장단점을 정확히 이해하고,
+컴포넌트의 역할과 책임, 예상되는 변경 사항을 고려하여 적절한 패턴을 선택해야 한다
+- 패턴 및 원칙 중심의 개발보다는, 구현하고 보니 패턴화 되어 있다 → 이런 게 더 좋다