기능 분할 설계(Feature-Sliced Design, FSD) 아키텍처의 개념과 이 아키텍처 방법론이 해결하는 문제를 이야기하고, FSD를 기존 아키텍처 및 모듈식 아키텍처와 비교한 뒤 장단점에 대해 소개합니다.

(번역) 기능 분할 설계 - 최고의 프런트엔드 아키텍처

Feature-Sliced Design(FSD)
은 최근 프론트엔드 개발 커뮤니티에서 주목받고 있는 핫한 아키텍처 패턴입니다. 이 패턴은 애플리케이션을 기능(Feature) 단위로 분할하여 확장성과 유지보수성을 크게 향상시키는 전략을 제공하는데요.

기존 구조의 한계
전통적인 레이어 기반 폴더 구조(components, services, utils 등)는 프로젝트 규모가 커질수록 여러 문제점을 노출합니다. 컴포넌트간 암묵적 의존성 증가, 모듈간 경계가 모호해짐 등의 이유 때문인데요.

FSD 패턴의 개념
1. 기능(Feature) 단위의 구조화
FSD는 기능별로 모든 관련 파일을 아래와 같이 한 폴더에 모아 둡니다.
features/auth/
├── model/       # 상태 관리, 비즈니스 로직
├── api/         # API 요청 관련 코드
├── ui/          # 로그인 폼, 버튼 등 UI 컴포넌트
└── index.ts     # 퍼블릭 API

이렇게 로그인 관련 코드가 한 폴더에 집중되어 있어, 가독성이 뛰어나고 유지보수와 확장성이 용이해집니다. 다른 기능과 의존성을 최소화(de-coupling)항, 독립적인 개발이 가능합니다.

2. FSD의 계층 구조 (Layers, Slices, Segments)
FSD는 기능별 구조를 체계적으로 관리하기 위해 계층(Layers), 슬라이스(Slices), 세그먼트(Segments) 개념을 적용합니다.
 * Layers(레이어): 프로젝트를 역할별 계층으로 분리하여 코드의 책임을 명확히 구분
 * Slices(슬라이스): 개별 기능을 독립적인 모듈로 유지
 * Segments(세그먼트): 기능 내부에서도 역할별로 코드 분리
이러한 구조를 통해 기능별 역할이 명확해지고 코드가 섞이는 문제를 방지할 수 있습니다.

3. Private & Public Components 규칙
FSD에서는 컴포넌트의 접근 범위를 명확히 구분하여 유지보수성을 높입니다.
 * Public Component: 여러 곳에서 재사용 가능 (공통 UI, Button, Modal 등)
 * Private Component: 특정 기능 내부에서만 사용 (로그인 폼 내부의 입력 필드 등)
이를 통해 컴포넌트 간 불필요한 의존성을 줄이고, 재사용성과 유지보수성을 극대화할 수 있습니다.

FSD 패턴과 모노레포의 시너지
최근 프론트엔드 프로젝트에서 모노레포(Monorepo) 구조가 증가하고 있는데요 FSD 패턴과의 결합은 아래와 같은 여러 장점을 가질 수 있습니다.
✔ 기능별 패키지 관리 용이 → 개별 패키지로 독립적인 기능 관리 가능
✔ 기능 단위 개발 & 배포 가능 → 특정 기능만 별도 패키지로 분리하여 재사용
✔ 빌드 최적화 가능 →
Turborepo
같은 빌드 시스템과 결합해 패키지 단위 캐싱 적용

FSD 패턴은 기능 중심의 구조화로 명확한 아키텍처를 제공하여 유지보수성과 확장성을 극대화하는 설계 방식입니다. 폴더 구조를 체계적으로 정리하고, 기능 간 결합도를 낮춰 코드 관리와 개발 생산성을 향상시킵니다.
특히 중대형 프로젝트에서 폴더 구조와 모듈화를 고민하고 있다면, FSD는 효율적이고 확장 가능한 선택이 될 수 있습니다.

https://emewjin.github.io/feature-sliced-design/

<code >Feature-Sliced Design(FSD)</code>은 최근 프론트엔드 개발 커뮤니티에서 주목받고 있는 핫한 아키텍처 패턴입니다. 이 패턴은 애플리케이션을 기능(Feature) 단위로 분할하여 확장성과 유지보수성을 크게 향상시키는 전략을 제공하는데요. 기존 구조의 한계전통적인 레이어 기반 폴더 구조(components, services, utils 등)는 프로젝트 규모가 커질수록 여러 문제점을 노출합니다. 컴포넌트간 암묵적 의존성 증가, 모듈간 경계가 모호해짐 등의 이유 때문인데요. FSD 패턴의 개념1. 기능(Feature) 단위의 구조화FSD는 기능별로 모든 관련 파일을 아래와 같이 한 폴더에 모아 둡니다.<pre ><code>features/auth/
├── model/ # 상태 관리, 비즈니스 로직
├── api/ # API 요청 관련 코드
├── ui/ # 로그인 폼, 버튼 등 UI 컴포넌트
└── index.ts # 퍼블릭 API</code></pre>이렇게 로그인 관련 코드가 한 폴더에 집중되어 있어, 가독성이 뛰어나고 유지보수와 확장성이 용이해집니다. 다른 기능과 의존성을 최소화(de-coupling)항, 독립적인 개발이 가능합니다. 2. FSD의 계층 구조 (Layers, Slices, Segments)FSD는 기능별 구조를 체계적으로 관리하기 위해 계층(Layers), 슬라이스(Slices), 세그먼트(Segments) 개념을 적용합니다.<ul ><li>Layers(레이어): 프로젝트를 역할별 계층으로 분리하여 코드의 책임을 명확히 구분</li><li>Slices(슬라이스): 개별 기능을 독립적인 모듈로 유지</li><li>Segments(세그먼트): 기능 내부에서도 역할별로 코드 분리</li></ul>이러한 구조를 통해 기능별 역할이 명확해지고 코드가 섞이는 문제를 방지할 수 있습니다. 3. Private &amp; Public Components 규칙FSD에서는 컴포넌트의 접근 범위를 명확히 구분하여 유지보수성을 높입니다.<ul ><li>Public Component: 여러 곳에서 재사용 가능 (공통 UI, Button, Modal 등)</li><li>Private Component: 특정 기능 내부에서만 사용 (로그인 폼 내부의 입력 필드 등)</li></ul>이를 통해 컴포넌트 간 불필요한 의존성을 줄이고, 재사용성과 유지보수성을 극대화할 수 있습니다. FSD 패턴과 모노레포의 시너지최근 프론트엔드 프로젝트에서 모노레포(Monorepo) 구조가 증가하고 있는데요 FSD 패턴과의 결합은 아래와 같은 여러 장점을 가질 수 있습니다.✔ 기능별 패키지 관리 용이 → 개별 패키지로 독립적인 기능 관리 가능 ✔ 기능 단위 개발 &amp; 배포 가능 → 특정 기능만 별도 패키지로 분리하여 재사용 ✔ 빌드 최적화 가능 → <code >Turborepo</code> 같은 빌드 시스템과 결합해 패키지 단위 캐싱 적용 FSD 패턴은 기능 중심의 구조화로 명확한 아키텍처를 제공하여 유지보수성과 확장성을 극대화하는 설계 방식입니다. 폴더 구조를 체계적으로 정리하고, 기능 간 결합도를 낮춰 코드 관리와 개발 생산성을 향상시킵니다. 특히 중대형 프로젝트에서 폴더 구조와 모듈화를 고민하고 있다면, FSD는 효율적이고 확장 가능한 선택이 될 수 있습니다. https://emewjin.github.io/feature-sliced-design/

emewjin.github.io

FSD 패턴: 기능 중심 구조로 프론트엔드 복잡성 정복하기

🚀 아미고(Ameego) 안드로이드 론칭!!

백문이불여일견! 아래👇 링크에서 다운받으세요!

https://dub.sh/ameego-android

기기가 몇 개 없어서 테스트를 많이 못했습니다만..일단 올리고 보기로 했습니다. 특히 결제 테스트 많이 부탁드려요. 🥹

iOS는 아래👇 링크에서!

https://dub.sh/ameego-ios

감사합니다! 🙇🏻‍♀️🙇🏻

🚀 아미고(Ameego) 안드로이드 론칭!! 백문이불여일견! 아래👇 링크에서 다운받으세요! https://dub.sh/ameego-android 기기가 몇 개 없어서 테스트를 많이 못했습니다만..일단 올리고 보기로 했습니다. 특히 결제 테스트 많이 부탁드려요. 🥹 iOS는 아래👇 링크에서! https://dub.sh/ameego-ios 감사합니다! 🙇🏻‍♀️🙇🏻

‪아이콘 교체랑 몇가지 소소한 작업을 했는데 구글 리뷰가 너무 길어져서 일단 릴리즈하고 봅니다. 🥹‬

‪다음역은 일본을 시작으로 한 글로벌 론칭입니다!‬

코딩만 잘했다면 절대 도달하지 못했을 자리예요

평범한 개발자가 AWS 수석 아키텍트가 될 수 있었던 진짜 이유

데브필이라는 뉴스레터를 구독하고 있어요. 최근에 발행된 글을 보며 커리어에 대해 보다 유연한 생각을 갖게 됐어요.

개발자에서 일종의 영업직인 프리세일즈 엔지니어로 직무를 전환한 뒤 AWS 수석 아키텍트가 된 분의 이야기를 다루는 글이었어요.

커리어 패스는 개인마다 고유하다고 말하는 '평범한 개발자가 AWS 수석 아키텍트가 될 수 있었던 진짜 이유'를 읽어보세요.

https://maily.so/devpill/posts/10z3pqgkolw

데브필이라는 뉴스레터를 구독하고 있어요. 최근에 발행된 글을 보며 커리어에 대해 보다 유연한 생각을 갖게 됐어요. 개발자에서 일종의 영업직인 프리세일즈 엔지니어로 직무를 전환한 뒤 AWS 수석 아키텍트가 된 분의 이야기를 다루는 글이었어요. 커리어 패스는 개인마다 고유하다고 말하는 '평범한 개발자가 AWS 수석 아키텍트가 될 수 있었던 진짜 이유'를 읽어보세요. https://maily.so/devpill/posts/10z3pqgkolw

우디 디자인 취업고민

커리어의 선형적 성장에 얽매이지 마세요

﻿
조직에서 가장 중요한 포지션은 리더십이라고 생각합니다. 리더는 구성원을 이끌고, 목표 달성을 해야 하는 역할을 맡고 있는 사람입니다. 리더는 구성원에게 모범을 보여 구성원이 리더를 자연스럽게 따르도록 만들어야 합니다. 리더는 구성원에게 방향을 알려주고, 우선순위를 결정하는 역할을 합니다. 리더는 긍정적인 문화를 조성하고, 문화라는 약속을 철저히 지키야 합니다.

리더십에 정답이 있는 것은 아닙니다. 강력한 카리스마를 바탕으로 조직 구성원을 휘어잡는 리더가 있고, 부드러운 말과 행동으로 구성원을 설득하고 스스로 움직일 수 있도록 변화를 유도하는 리더가 있습니다. 누가 더 좋은 리더냐 우열을 가릴 수 없고, 구성원마다 선호하는 리더십이 있어서 더 잘 맞는 캐릭터가 좋다고 평가할 것입니다.

리더는 한 가지 모습을 고집할 것이 아니라 리드해야 하는 구성원에 따라 그들의 요구에 맞춰 리더십을 발휘해야 합니다. 강력한 리더십을 원하는 구성원에게 강한 챌린지를 제공하고, 부드러운 리더십을 원하는 구성원에게 엄마나 아빠와 같은 리더십을 보여주면 됩니다. 마이크로 매니징을 원하는 구성원에게 꼼꼼한 리더십으로 리드한다면 좋다고 생각합니다.

리더는 내부 구성원 중에서 탄생하는 것이 가장 바람직하다고 믿습니다. 외부에서 리드를 수혈하는 방식도 괜찮지만, 그것보다 이미 조직 상황을 잘 이해하고 있는 내부 구성원이 리더가 되는 것이 더 좋다고 생각합니다. 다른 구성원과의 관계나 이미 검증된 역량 등을 고려할 때, 기존 구성원을 리더로 세우는 것이 자연스러운 단계입니다.

리더가 될 준비를 시키는 것이 조직이 해야 할 일입니다. 기존 구성원에게 리더십에 대한 교육을 제공하여 누구라도 리더가 될 수 있다는 기회를 부여하는 것입니다. 꼭 리더가 되어야 리더십이 필요한 것이 아니라 모든 구성원에게 리더십은 하나의 덕목입니다. 누구나 자기 자신에 대한 리더십을 발휘해야 일을 주도적으로 할 수 있기 때문입니다. 목표, 계획, 추진 등 리더가 갖추어야 할 자질은 사실 누구에게나 필요한 공통 역량입니다.

조직의 성장은 전적으로 리더에게 달려 있습니다. 가혹한 이야기 같지만, 실제로 그렇습니다. 리더가 슈퍼맨처럼 미친 역량을 발휘해야 한다는 뜻이 아닙니다. 구성원과 소통하고 공감을 통해 목표를 달성할 수 있도록 부단히 노력해야 하기 때문입니다. 구성원에게 관심을 갖고 정성을 쏟지 않으면 조직이 성장할 수 없습니다. 그래서 리더의 역할이 중요하고 성장의 책임을 갖게 되는 것입니다.

조직 문화도 리더에게 키가 50% 이상 달려 있습니다. 그럼 구성원과 비중이 50%로 똑같다고 오해할 수 있습니다. 리더는 구성원보다 훨씬 적은 비중의 인원입니다. 구성원이 5명이라면 리더는 1명이고, 더 상위 조직 단위를 맡고 있는 리더도 1명입니다. 그러니까 리더 1명이 전체 구성원에게 줄 수 있는 영향력은 50% 이상입니다. 그러나 조직 문화는 리더 혼자 만들 수 없고, 구성원이 따르고 지켜야 하는 것이기 때문에 50%라고 하였습니다.

리더는 약속을 지키는 사람입니다. 구성원과의 약속과 자신과의 약속을 모두 지켜야 합니다. 원칙과 기준에 의해서 판단하고 행동하는 사람이 되어야 합니다. 작은 예외 상황도 가볍게 판단하지 않고 원칙과 기준에 맞게 행동해야 합니다. 아무도 보지 않고 아무도 지적하지 않는다고 해서 원칙과 기준을 무시하고 행동하는 것은 잘못된 판단입니다. 누가 보지 않더라도 약속을 지키는 것이 도덕적 양심이라고 믿습니다.

리더는 구성원에게 책임감을 가져야 합니다. 일을 잘 못하는 구성원이 있다면 밖으로 내모는 것이 아니라 끝까지 책임을 져야 합니다. 책임이란 일을 잘할 수 있도록 돕거나 구성원에게 더 잘 맞는 역할을 찾아주는 것을 의미합니다. 구성원의 강점을 발견하여 그 강점을 잘 발휘할 수 있도록 역할을 부여하는 것이 리더의 책임입니다. 구성원이 성과를 내지 못하는 것에 대한 책임이 리더에게 있다는 의미입니다. 성과를 만들지 못하는 구성원을 탓하는 리더는 자격이 없습니다.

리더는 바쁘지 않아야 합니다. 철저히 계획에 따라 움직여야 합니다. 정신없이 시간을 보내고 틈이 나면 구성원을 돌보는 것이 아니라 항상 구성원을 먼저 생각하고 계획적으로 팀을 다스려야 합니다. 그런 리더십이 있어야 구성원이 안정감을 느낄 수 있습니다. 리더가 안정되게 일을 하는 모습을 보여줘야 구성원도 따라서 편안하게 업무에 몰입할 수 있는 것입니다.

﻿조직에서 가장 중요한 포지션은 리더십이라고 생각합니다. 리더는 구성원을 이끌고, 목표 달성을 해야 하는 역할을 맡고 있는 사람입니다. 리더는 구성원에게 모범을 보여 구성원이 리더를 자연스럽게 따르도록 만들어야 합니다. 리더는 구성원에게 방향을 알려주고, 우선순위를 결정하는 역할을 합니다. 리더는 긍정적인 문화를 조성하고, 문화라는 약속을 철저히 지키야 합니다. 리더십에 정답이 있는 것은 아닙니다. 강력한 카리스마를 바탕으로 조직 구성원을 휘어잡는 리더가 있고, 부드러운 말과 행동으로 구성원을 설득하고 스스로 움직일 수 있도록 변화를 유도하는 리더가 있습니다. 누가 더 좋은 리더냐 우열을 가릴 수 없고, 구성원마다 선호하는 리더십이 있어서 더 잘 맞는 캐릭터가 좋다고 평가할 것입니다. 리더는 한 가지 모습을 고집할 것이 아니라 리드해야 하는 구성원에 따라 그들의 요구에 맞춰 리더십을 발휘해야 합니다. 강력한 리더십을 원하는 구성원에게 강한 챌린지를 제공하고, 부드러운 리더십을 원하는 구성원에게 엄마나 아빠와 같은 리더십을 보여주면 됩니다. 마이크로 매니징을 원하는 구성원에게 꼼꼼한 리더십으로 리드한다면 좋다고 생각합니다. 리더는 내부 구성원 중에서 탄생하는 것이 가장 바람직하다고 믿습니다. 외부에서 리드를 수혈하는 방식도 괜찮지만, 그것보다 이미 조직 상황을 잘 이해하고 있는 내부 구성원이 리더가 되는 것이 더 좋다고 생각합니다. 다른 구성원과의 관계나 이미 검증된 역량 등을 고려할 때, 기존 구성원을 리더로 세우는 것이 자연스러운 단계입니다. 리더가 될 준비를 시키는 것이 조직이 해야 할 일입니다. 기존 구성원에게 리더십에 대한 교육을 제공하여 누구라도 리더가 될 수 있다는 기회를 부여하는 것입니다. 꼭 리더가 되어야 리더십이 필요한 것이 아니라 모든 구성원에게 리더십은 하나의 덕목입니다. 누구나 자기 자신에 대한 리더십을 발휘해야 일을 주도적으로 할 수 있기 때문입니다. 목표, 계획, 추진 등 리더가 갖추어야 할 자질은 사실 누구에게나 필요한 공통 역량입니다. 조직의 성장은 전적으로 리더에게 달려 있습니다. 가혹한 이야기 같지만, 실제로 그렇습니다. 리더가 슈퍼맨처럼 미친 역량을 발휘해야 한다는 뜻이 아닙니다. 구성원과 소통하고 공감을 통해 목표를 달성할 수 있도록 부단히 노력해야 하기 때문입니다. 구성원에게 관심을 갖고 정성을 쏟지 않으면 조직이 성장할 수 없습니다. 그래서 리더의 역할이 중요하고 성장의 책임을 갖게 되는 것입니다. 조직 문화도 리더에게 키가 50% 이상 달려 있습니다. 그럼 구성원과 비중이 50%로 똑같다고 오해할 수 있습니다. 리더는 구성원보다 훨씬 적은 비중의 인원입니다. 구성원이 5명이라면 리더는 1명이고, 더 상위 조직 단위를 맡고 있는 리더도 1명입니다. 그러니까 리더 1명이 전체 구성원에게 줄 수 있는 영향력은 50% 이상입니다. 그러나 조직 문화는 리더 혼자 만들 수 없고, 구성원이 따르고 지켜야 하는 것이기 때문에 50%라고 하였습니다. 리더는 약속을 지키는 사람입니다. 구성원과의 약속과 자신과의 약속을 모두 지켜야 합니다. 원칙과 기준에 의해서 판단하고 행동하는 사람이 되어야 합니다. 작은 예외 상황도 가볍게 판단하지 않고 원칙과 기준에 맞게 행동해야 합니다. 아무도 보지 않고 아무도 지적하지 않는다고 해서 원칙과 기준을 무시하고 행동하는 것은 잘못된 판단입니다. 누가 보지 않더라도 약속을 지키는 것이 도덕적 양심이라고 믿습니다. 리더는 구성원에게 책임감을 가져야 합니다. 일을 잘 못하는 구성원이 있다면 밖으로 내모는 것이 아니라 끝까지 책임을 져야 합니다. 책임이란 일을 잘할 수 있도록 돕거나 구성원에게 더 잘 맞는 역할을 찾아주는 것을 의미합니다. 구성원의 강점을 발견하여 그 강점을 잘 발휘할 수 있도록 역할을 부여하는 것이 리더의 책임입니다. 구성원이 성과를 내지 못하는 것에 대한 책임이 리더에게 있다는 의미입니다. 성과를 만들지 못하는 구성원을 탓하는 리더는 자격이 없습니다. 리더는 바쁘지 않아야 합니다. 철저히 계획에 따라 움직여야 합니다. 정신없이 시간을 보내고 틈이 나면 구성원을 돌보는 것이 아니라 항상 구성원을 먼저 생각하고 계획적으로 팀을 다스려야 합니다. 그런 리더십이 있어야 구성원이 안정감을 느낄 수 있습니다. 리더가 안정되게 일을 하는 모습을 보여줘야 구성원도 따라서 편안하게 업무에 몰입할 수 있는 것입니다.﻿

리더십

나는 가끔 기적을 일으킨다. 7년 전 그날의 학술대회장에서도 그랬다. 많은 비가 내리는 날씨였지만 학술대회장은 성황이었다. 내 발표가 예정되어 있는 소강당 안에도 청중이 꽤 많이 앉아 있었다. 오늘은 흥행이 좀 되겠는걸. 내가 두 번째 발표이니, 첫 번째 발표가 진행될 동안 청중들이 어떤 질문을 할지 미리 생각 좀 해보자. 경청해 주셔서 감사하다는 첫 번

버스 안에서 | 한국일보

필자는 가끔 기적을 일으킨다. 7년 전 그날의 학술대회장도 그랬다. 많은 비가 내리는 날씨였지만 학술대회장은 성황이었다. 필자의 발표가 예정되어 있는 소강당에도 청중이 꽤 많이 앉아 있었다. ‘오늘은 흥행이 좀 되겠는걸. 내가 두 번째 발표이니, 첫 번째 발표가 진행될 동안 청중들이 어떤 질문을 할지 미리 생각해보자‘.

경청해주셔서 감사하다는 첫 발표자의 인사와 함께 박수 소리가 강당을 메웠다. 다음은 필자의 차례. 긴장된 마음 반, 기대감 반으로 연단에 올라 컴퓨터를 점검했다. 발표 슬라이드가 스크린에 뜬 것을 확인하고 고개를 돌렸을 때, 잠시 얼어붙었다. 대부분의 청중이 약속이라도 한 것처럼 자리를 뜨고 있었기 때문이다.

뭐지? 뭘까? 발표 보이콧? 사람들의 표정을 보았다. 보이콧은 아니었다. 영화 상영이 다 끝난 후 극장을 나서는 이들의 얼굴이었으니까. ’여러분, 아직 영화의 엔딩 크레딧이…아니 제 발표가 남았습니다.’라고 말하고 싶었지만, 그저 미소를 지은 채 그 광경을 바라볼 수밖에 없었다.

멋쩍은 듯 고개를 돌리다 학술대회 프로그램 안내문 속 발표자들의 소속이 문득 눈에 들어왔다. 첫 번째 발표자는 ‘인 서울’의 유명 사립대 소속, 두 번째 발표자인 필자는 ‘아웃 서울’의 지방대 소속.

장내가 정리되었다. 소강당 안의 인원은 10분의 1로 줄어 있었다. 띄엄띄엄 가뭄의 콩처럼 앉아 있는 이들은 대부분 안면이 있는 연구자들. 그제서야 깨달았다. ‘내가 또 기적을 일으켰구나.’ 그런 기적을 일으키는 능력은 필자가 고향의 지방국립대에 입학하던 그 순간부터 갖게 된 것이다.

대학 시절, 서울대를 다니던 고교 선배에게 그가 하던 과외를 물려받은 적이 있었다. 첫 달 수업을 끝내고 처음 과외비를 받았을 때, 필자가 받은 액수가 서울대 다니던 선배가 받은 돈의 절반이 되는 기적을 경험했다. 과외를 하며 학생의 성적을 비약적으로 높여 주었지만, 여전히 그 기적은 멈출 줄 몰랐다.

‘부모님, 이 친구 성적은 그 선배가 아닌 제가 올렸습니다.’라고 말하고 싶었지만, 애써 웃으며 이렇게 말했다. “감사합니다.” 그 학생의 부모는 아마 이렇게 말하고 다녔을 것이다. “역시! 서울대생에게 과외를 받더니 우리 애 성적이 올랐어“.

이놈의 기적은 도무지 멈출 줄을 몰라서 그 이후에도 수시로 기적의 순간을 목격해야 했다. 과외 알선 업소에 서류를 제출하고 사무실을 나올 때 등 뒤에서 어이없다는 말과 함께 들려오던 웃음소리. 임용을 위한 면접 자리에서 혼잣말인지 질문인지 구분이 안 가는 비아냥을 흥얼거리던 면접 위원들.

이런 기적들을 설명할 단어를 찾은 것은 얼마 전 공부 모임에서 번역서의 역어를 논의하다가 ‘장소’와 ‘공간’의 개념에 대한 토론을 할 때였다. 이 두 가지 용어는 학문 분야, 학자마다 다르게 정의하지만, 필자에게 장소는 물리적 실체이고 공간은 복잡한 사회적 관계에 의해 만들어지는 사회적 구성물을 뜻한다.

한날 한시 우리는 같은 장소에 있을 수 있지만, 그 장소는 각자에게 다른 공간이 될 수 있다. 이를테면 흑백분리법이 시행되던 1950년대 미국에서는 물리적 실체인 버스라는 ‘장소’를 백인 전용 칸과 유색인 칸으로 구분함으로써 인종차별의 ‘공간’을 구현했다.

버스를 백인 칸과 유색인 칸으로 구분하는 것도 모자라 화장실마저 따로 쓰게 하는 과거 미국의 인종차별이 기막히고 악랄하다고 생각하는가? 미안한 말이지만 시험 잘 보는 능력에 따라 사람들을 분류하고 차별해도 괜찮다고 생각하는 ‘지적 인종주의’가 팽배한 한국 사회도 과거 미국의 인종차별과 별반 다름없는 일들이 벌어진다.

그러나 우리는 미국처럼 찌질하게 버스 칸을 나누거나 화장실을 분리하지 않는다. 우리가 어떤 민족인가? 우리는 어떤 장소에 있는 사람이 지적으로 열등한 인종이라는 것이 밝혀지면, 그 장소를 통째로 차별과 혐오의 공간으로 탈바꿈시키는 통 큰 민족이다.

요컨대 필자가 한국 사회로부터 부여받은 기적을 일으키는 능력의 핵심은, 내가 가는 모든 장소를 순식간에 지적 인종주의가 작동하는 차별과 혐오의 공간으로 바꾸는 것에 있다. 종종 나 자신도 모르게 어느 버스의 백인 칸에 앉아 있는 것을 발견하고는 한다.

그 버스 안에서 ‘인 서울’ 출신의 ‘지적 백인’들은 나에게 말한다. 거기는 당신 자리가 아니야. 자리에서 일어나 당장 뒤로 꺼지시지. 아니, 그것은 지적 백인들의 목소리가 아니다. 그것은 그들의 목소리를 내면화한 나의 목소리다. 나는 로자 파크스가 아니기 때문이다.

1955년 미국 몽고메리에서 흑인 여성 로자 파크스는 백인 칸에서 일어나 뒤로 가라는 운전사의 명령을 거부하여 체포되었고, 그 사건은 미국 시민권 운동의 기폭제가 되었다. 그러나 우리 사회의 버스 승객들은 자신이 몇 번째 칸에 앉아 있든 관계없이 학력과 학벌에 기반한 차별을 당연한 원리로 받아들인다.

우리는 지적 인종주의를 몸과 마음에 습속으로 새겨놓고 있다. 이 습속은 무의식적으로 작용한다. 학벌이 좋은 선배의 과외비의 반에 해당하는 액수를 건넨 학부모는 별 문제의식을 느끼지 않았을 것이다. 그들의 몸과 마음은 그저 무의식적으로 반응했을 뿐이다. 동일한 노동을 하고 더 큰 성과를 이루었지만 학벌이 좋은 사람이 더 큰 몫을 챙기는 게 당연하다고 여길 뿐이다.

그런 반응을 하는 건 필자도 마찬가지다. 부끄럽지만, 지금도 필자의 출신 학교가 밝혀질 때마다 온몸의 털이 바짝 서는 것을 느낀다. 한국 사회가 나의 몸에 각인시킨 반응이다. 나의 출신이 밝혀질 때 사람들이 더 이상 나를 바라보지 않는다는 것을 잘 안다. 필자의 신체적 반응은 그런 경험들을 통해 만들어진 것이다.

지적 인종주의는 능력주의의 다른 이름이다. 능력주의의 추종자들은 그것의 정당성을 ‘효율’과 ‘합리’에서 찾는다. 그러나 사회의 모든 구성원을 차별이 작동하는 버스 안에 가두어 놓는 것이 과연 효율적이고 합리적인지는 의문이다.

지적 인종주의의 망상에 사로잡혀 끊임없이 서열을 따지며 서로가 서로에게 가해자인 동시에 피해자가 되는 사회. 그 버스 안의 풍경은 끔찍하다. 그러니 그냥 우리 모두, 함께 섞여서 버스를 타면 안될까?

필자는 가끔 기적을 일으킨다. 7년 전 그날의 학술대회장도 그랬다. 많은 비가 내리는 날씨였지만 학술대회장은 성황이었다. 필자의 발표가 예정되어 있는 소강당에도 청중이 꽤 많이 앉아 있었다. ‘오늘은 흥행이 좀 되겠는걸. 내가 두 번째 발표이니, 첫 번째 발표가 진행될 동안 청중들이 어떤 질문을 할지 미리 생각해보자‘. 경청해주셔서 감사하다는 첫 발표자의 인사와 함께 박수 소리가 강당을 메웠다. 다음은 필자의 차례. 긴장된 마음 반, 기대감 반으로 연단에 올라 컴퓨터를 점검했다. 발표 슬라이드가 스크린에 뜬 것을 확인하고 고개를 돌렸을 때, 잠시 얼어붙었다. 대부분의 청중이 약속이라도 한 것처럼 자리를 뜨고 있었기 때문이다. 뭐지? 뭘까? 발표 보이콧? 사람들의 표정을 보았다. 보이콧은 아니었다. 영화 상영이 다 끝난 후 극장을 나서는 이들의 얼굴이었으니까. ’여러분, 아직 영화의 엔딩 크레딧이…아니 제 발표가 남았습니다.’라고 말하고 싶었지만, 그저 미소를 지은 채 그 광경을 바라볼 수밖에 없었다. 멋쩍은 듯 고개를 돌리다 학술대회 프로그램 안내문 속 발표자들의 소속이 문득 눈에 들어왔다. 첫 번째 발표자는 ‘인 서울’의 유명 사립대 소속, 두 번째 발표자인 필자는 ‘아웃 서울’의 지방대 소속. 장내가 정리되었다. 소강당 안의 인원은 10분의 1로 줄어 있었다. 띄엄띄엄 가뭄의 콩처럼 앉아 있는 이들은 대부분 안면이 있는 연구자들. 그제서야 깨달았다. ‘내가 또 기적을 일으켰구나.’ 그런 기적을 일으키는 능력은 필자가 고향의 지방국립대에 입학하던 그 순간부터 갖게 된 것이다. 대학 시절, 서울대를 다니던 고교 선배에게 그가 하던 과외를 물려받은 적이 있었다. 첫 달 수업을 끝내고 처음 과외비를 받았을 때, 필자가 받은 액수가 서울대 다니던 선배가 받은 돈의 절반이 되는 기적을 경험했다. 과외를 하며 학생의 성적을 비약적으로 높여 주었지만, 여전히 그 기적은 멈출 줄 몰랐다. ‘부모님, 이 친구 성적은 그 선배가 아닌 제가 올렸습니다.’라고 말하고 싶었지만, 애써 웃으며 이렇게 말했다. “감사합니다.” 그 학생의 부모는 아마 이렇게 말하고 다녔을 것이다. “역시! 서울대생에게 과외를 받더니 우리 애 성적이 올랐어“. 이놈의 기적은 도무지 멈출 줄을 몰라서 그 이후에도 수시로 기적의 순간을 목격해야 했다. 과외 알선 업소에 서류를 제출하고 사무실을 나올 때 등 뒤에서 어이없다는 말과 함께 들려오던 웃음소리. 임용을 위한 면접 자리에서 혼잣말인지 질문인지 구분이 안 가는 비아냥을 흥얼거리던 면접 위원들. 이런 기적들을 설명할 단어를 찾은 것은 얼마 전 공부 모임에서 번역서의 역어를 논의하다가 ‘장소’와 ‘공간’의 개념에 대한 토론을 할 때였다. 이 두 가지 용어는 학문 분야, 학자마다 다르게 정의하지만, 필자에게 장소는 물리적 실체이고 공간은 복잡한 사회적 관계에 의해 만들어지는 사회적 구성물을 뜻한다. 한날 한시 우리는 같은 장소에 있을 수 있지만, 그 장소는 각자에게 다른 공간이 될 수 있다. 이를테면 흑백분리법이 시행되던 1950년대 미국에서는 물리적 실체인 버스라는 ‘장소’를 백인 전용 칸과 유색인 칸으로 구분함으로써 인종차별의 ‘공간’을 구현했다. 버스를 백인 칸과 유색인 칸으로 구분하는 것도 모자라 화장실마저 따로 쓰게 하는 과거 미국의 인종차별이 기막히고 악랄하다고 생각하는가? 미안한 말이지만 시험 잘 보는 능력에 따라 사람들을 분류하고 차별해도 괜찮다고 생각하는 ‘지적 인종주의’가 팽배한 한국 사회도 과거 미국의 인종차별과 별반 다름없는 일들이 벌어진다. 그러나 우리는 미국처럼 찌질하게 버스 칸을 나누거나 화장실을 분리하지 않는다. 우리가 어떤 민족인가? 우리는 어떤 장소에 있는 사람이 지적으로 열등한 인종이라는 것이 밝혀지면, 그 장소를 통째로 차별과 혐오의 공간으로 탈바꿈시키는 통 큰 민족이다. 요컨대 필자가 한국 사회로부터 부여받은 기적을 일으키는 능력의 핵심은, 내가 가는 모든 장소를 순식간에 지적 인종주의가 작동하는 차별과 혐오의 공간으로 바꾸는 것에 있다. 종종 나 자신도 모르게 어느 버스의 백인 칸에 앉아 있는 것을 발견하고는 한다. 그 버스 안에서 ‘인 서울’ 출신의 ‘지적 백인’들은 나에게 말한다. 거기는 당신 자리가 아니야. 자리에서 일어나 당장 뒤로 꺼지시지. 아니, 그것은 지적 백인들의 목소리가 아니다. 그것은 그들의 목소리를 내면화한 나의 목소리다. 나는 로자 파크스가 아니기 때문이다. 1955년 미국 몽고메리에서 흑인 여성 로자 파크스는 백인 칸에서 일어나 뒤로 가라는 운전사의 명령을 거부하여 체포되었고, 그 사건은 미국 시민권 운동의 기폭제가 되었다. 그러나 우리 사회의 버스 승객들은 자신이 몇 번째 칸에 앉아 있든 관계없이 학력과 학벌에 기반한 차별을 당연한 원리로 받아들인다. 우리는 지적 인종주의를 몸과 마음에 습속으로 새겨놓고 있다. 이 습속은 무의식적으로 작용한다. 학벌이 좋은 선배의 과외비의 반에 해당하는 액수를 건넨 학부모는 별 문제의식을 느끼지 않았을 것이다. 그들의 몸과 마음은 그저 무의식적으로 반응했을 뿐이다. 동일한 노동을 하고 더 큰 성과를 이루었지만 학벌이 좋은 사람이 더 큰 몫을 챙기는 게 당연하다고 여길 뿐이다. 그런 반응을 하는 건 필자도 마찬가지다. 부끄럽지만, 지금도 필자의 출신 학교가 밝혀질 때마다 온몸의 털이 바짝 서는 것을 느낀다. 한국 사회가 나의 몸에 각인시킨 반응이다. 나의 출신이 밝혀질 때 사람들이 더 이상 나를 바라보지 않는다는 것을 잘 안다. 필자의 신체적 반응은 그런 경험들을 통해 만들어진 것이다. 지적 인종주의는 능력주의의 다른 이름이다. 능력주의의 추종자들은 그것의 정당성을 ‘효율’과 ‘합리’에서 찾는다. 그러나 사회의 모든 구성원을 차별이 작동하는 버스 안에 가두어 놓는 것이 과연 효율적이고 합리적인지는 의문이다. 지적 인종주의의 망상에 사로잡혀 끊임없이 서열을 따지며 서로가 서로에게 가해자인 동시에 피해자가 되는 사회. 그 버스 안의 풍경은 끔찍하다. 그러니 그냥 우리 모두, 함께 섞여서 버스를 타면 안될까?

한국일보

mocking은 단위 테스트를 작성할 때, 해당 코드가 의존하는 부분을 가짜(mock)로 대체하는 기법을 말하는데요. 일반적으로 테스트하려는 코드가 의존하는 부분을 직접 생성하기가 너무 부담스러운 경우 mocking이 많이 사용됩니다.

예를 들어, 데이터베이스에서 데이터를 삭제하는 코드에 대한 단위 테스트를 작성할 때, 실제 데이터베이스를 사용한다면 여러 가지 문제점이 발생할 수 있습니다.

 * 데이터베이스 접속과 같이 Network이나 I/O 작업이 포함된 테스트는 실행 속도가 현저히 떨어질 수 밖에 없습니다.
 * 프로젝트의 규모가 커져서 한 번에 실행해야 할 테스트 케이스가 많이지면 이러한 작은 속도 저하들이 모여 큰 이슈가 될 수 있으며, CI/CD 파이프라인의 일부로 테스트가 자동화되어 자주 실행되야 한다면 더 큰 문제가 될 수 있습니다.
 * 테스트 자체를 위한 코드보다 데이터베이스와 연결을 맺고 트랜잭션을 생성하고 쿼리를 전송하는 코드가 더 길어질 수 있습니다. 즉, 배보다 배꼽이 더 커질 수 있습니다.
 * 만약 테스트 실행 순간 일시적으로 데이터베이스가 오프라인 작업 중이었다면 해당 테스트는 실패하게 됩니다. 따라서 테스트가 인프라 환경에 영향을 받게됩니다. (non-deterministic)
 * 테스트가 종료 직 후, 데이터베이스에서 변경 데이터를 직접 원복하거나 트렌잭션을 rollback 해줘야 하는데 상당히 번거로운 작업이 될 수 있습니다.

무엇보다 이런 방식으로 테스트를 작성하게 되면 독립적인 기능 단위로 테스트하겠다는 단위 테스팅(Unit Testing)의 본연의 의도에 맞지 않게 되겠죠?

mocking은 이러한 상황에서 실제 객체인 척하는 가짜 객체를 생성하는 매커니즘을 제공합니다. 또한, 테스트가 실행되는 동안 가짜 객체에 어떤 일들이 발생했는지를 기억하기 때문에 가짜 객체가 내부적으로 어떻게 사용되는지 검증할 수 있죠. 결론적으로, mocking을 이용하면 실제 객체를 사용하는 것보다 훨씬 가볍고 빠르게 실행되면서도, 항상 동일한 결과를 내는 테스트를 작성할 수 있습니다.

📺 동영상: https://youtu.be/xBdMoedbWB4
📝 포스팅: https://www.daleseo.com/vitest-fn-spy-on/

차세대 테스팅 프레임워크로 각광받고 있는 Vitest를 학습하시는 분들께 아래 게시물도 추천드리겠습니다.

📕 Vitest 처음 시작하기: https://careerly.co.kr/comments/115949
📗 Vitest 결과 매칭: https://careerly.co.kr/comments/116437
📘 Vitest 그룹화: https://careerly.co.kr/comments/116659
📙 Vitest 테스트 전/후 처리하기: https://www.daleseo.com/vitest-fn-spy-on/

Vitest와 함께 사용하면 시너지를 발휘하는 차세대 번들러 Vite에 대해서는 아래 게시물을 참고하세요.

📓 Vite 처음 시작하기: https://careerly.co.kr/comments/115727

mocking은 단위 테스트를 작성할 때, 해당 코드가 의존하는 부분을 가짜(mock)로 대체하는 기법을 말하는데요. 일반적으로 테스트하려는 코드가 의존하는 부분을 직접 생성하기가 너무 부담스러운 경우 mocking이 많이 사용됩니다. 예를 들어, 데이터베이스에서 데이터를 삭제하는 코드에 대한 단위 테스트를 작성할 때, 실제 데이터베이스를 사용한다면 여러 가지 문제점이 발생할 수 있습니다. <ul ><li>데이터베이스 접속과 같이 Network이나 I/O 작업이 포함된 테스트는 실행 속도가 현저히 떨어질 수 밖에 없습니다.</li><li>프로젝트의 규모가 커져서 한 번에 실행해야 할 테스트 케이스가 많이지면 이러한 작은 속도 저하들이 모여 큰 이슈가 될 수 있으며, CI/CD 파이프라인의 일부로 테스트가 자동화되어 자주 실행되야 한다면 더 큰 문제가 될 수 있습니다.</li><li>테스트 자체를 위한 코드보다 데이터베이스와 연결을 맺고 트랜잭션을 생성하고 쿼리를 전송하는 코드가 더 길어질 수 있습니다. 즉, 배보다 배꼽이 더 커질 수 있습니다.</li><li>만약 테스트 실행 순간 일시적으로 데이터베이스가 오프라인 작업 중이었다면 해당 테스트는 실패하게 됩니다. 따라서 테스트가 인프라 환경에 영향을 받게됩니다. (non-deterministic)</li><li>테스트가 종료 직 후, 데이터베이스에서 변경 데이터를 직접 원복하거나 트렌잭션을 rollback 해줘야 하는데 상당히 번거로운 작업이 될 수 있습니다.</li></ul> 무엇보다 이런 방식으로 테스트를 작성하게 되면 독립적인 기능 단위로 테스트하겠다는 단위 테스팅(Unit Testing)의 본연의 의도에 맞지 않게 되겠죠? mocking은 이러한 상황에서 실제 객체인 척하는 가짜 객체를 생성하는 매커니즘을 제공합니다. 또한, 테스트가 실행되는 동안 가짜 객체에 어떤 일들이 발생했는지를 기억하기 때문에 가짜 객체가 내부적으로 어떻게 사용되는지 검증할 수 있죠. 결론적으로, mocking을 이용하면 실제 객체를 사용하는 것보다 훨씬 가볍고 빠르게 실행되면서도, 항상 동일한 결과를 내는 테스트를 작성할 수 있습니다. 📺 동영상: https://youtu.be/xBdMoedbWB4📝 포스팅: https://www.daleseo.com/vitest-fn-spy-on/ 차세대 테스팅 프레임워크로 각광받고 있는 Vitest를 학습하시는 분들께 아래 게시물도 추천드리겠습니다. 📕 Vitest 처음 시작하기: https://careerly.co.kr/comments/115949📗 Vitest 결과 매칭: https://careerly.co.kr/comments/116437📘 Vitest 그룹화: https://careerly.co.kr/comments/116659📙 Vitest 테스트 전/후 처리하기: https://www.daleseo.com/vitest-fn-spy-on/ Vitest와 함께 사용하면 시너지를 발휘하는 차세대 번들러 Vite에 대해서는 아래 게시물을 참고하세요. 📓 Vite 처음 시작하기: https://careerly.co.kr/comments/115727

Vitest 함수 모킹과 스파잉

wharup님의 블로그 : 네이버 블로그

MSA에서 타 서비스의 테이블에 액세스 할 수 없다는 걸 많이 부담스러워합니다.
그런데 막연한 부담감에 걱정만 하다가 준비할 시기를 놓치기도 하고
특히 나누기 쉬운 시스템을 놓고 말도 안되는 편법을 적용하는 케이스를 보면
너무 안타까울 수 밖에 없습니다.

관련해서 서비스로 나눌 때 어렵게 만드는 포인트와 사전에 어떻게 찾을 수 있는 지를 정리해봤습니다.
관심있는 분들께 모쪼록 도움이 되었으면 좋겠습니다.

https://blog.naver.com/wharup/223754624748

MSA에서 타 서비스의 테이블에 액세스 할 수 없다는 걸 많이 부담스러워합니다.그런데 막연한 부담감에 걱정만 하다가 준비할 시기를 놓치기도 하고특히 나누기 쉬운 시스템을 놓고 말도 안되는 편법을 적용하는 케이스를 보면너무 안타까울 수 밖에 없습니다. 관련해서 서비스로 나눌 때 어렵게 만드는 포인트와 사전에 어떻게 찾을 수 있는 지를 정리해봤습니다.관심있는 분들께 모쪼록 도움이 되었으면 좋겠습니다. https://blog.naver.com/wharup/223754624748

blog.naver.com

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin. Latest version: 3.2.4, last published: 17 days ago. Start using dompurify in your project by running `npm i dompurify`. There are 2544 other projects in the npm registry using dompurify.

dompurify

React 개발을 하다보면 어쩔수 없이
dangerouslySetInnerHTML
을 사용해야 할때가 있습니다. CMS 에서 가져온 HTML을 그대로 렌더링하거나, 위지윅 에디터 또는 Markdown 을 HTML로 변환해야 할때 등등 인데요.

문제는
dangerous
라는 이름이 붙은 만큼
dangerouslySetInnerHTML
은 보안상
XSS(Cross-Site Scripting)
공격의 위험이 됩니다. XSS공격 이란 웹사이트에 악의적인 스크립트를 주입하는 공격 기법으로 사용자 입력값이 직접 HTML로 삽입되는 경우, 공격자는 악성 스크립트를 삽입하여 실행시킬수 있습니다. 이런 이유로 React 팀에서는 이 기능의 위험성을 강조하기 위해 일부러 '
dangerous
' 라는 이름을 사용했다고 설명하고 있는데요.

따라서
dangerouslySetInnerHTML
을 어쩔수 없이 사용할때는
Sanitization
(살균, 소독)을 시켜야 합니다. React 공식 문서에서도 HTML을 직접 삽입할 때는 XSS 방지를 위한 소독(sanitization)이 필요하다고 언급하고 있는데요. 마치 의료기구를 소독해서 세균을 제거하듯이, 사용자가 입력한 데이터에서 악성 코드를 자동으로 제거할 수 있습니다.

따라서 이런 경우 DOMPurify 같은 라이브러리 사용을 추천합니다. 사용법또한 매우 간단합니다. DOMPurify.sanitize 함수로 해당 HTML을 감싸주기만 하면 됩니다.

<div dangerouslySetInnerHTML={{
 __html: DOMPurify.sanitize(dirtyHTML)
}} />

React 팀에서는 가능하면
dangerouslySetInnerHTML
사용을 피하되 꼭 필요한 경우에는 Sanitize 하는걸 권장하고 있습니다. 따라서
dangerouslySetInnerHTML
을 어쩔 수 없이 사용해야 할 경우에는 DOMPurify 라이브러리를 이용해 소독하는 과정을 거쳐 보안을 좀 더 강화할 것을 추천드립니다.

https://www.npmjs.com/package/dompurify

React 개발을 하다보면 어쩔수 없이 <code >dangerouslySetInnerHTML</code>을 사용해야 할때가 있습니다. CMS 에서 가져온 HTML을 그대로 렌더링하거나, 위지윅 에디터 또는 Markdown 을 HTML로 변환해야 할때 등등 인데요. 문제는 <code >dangerous</code> 라는 이름이 붙은 만큼 <code >dangerouslySetInnerHTML</code> 은 보안상 <code >XSS(Cross-Site Scripting)</code> 공격의 위험이 됩니다. XSS공격 이란 웹사이트에 악의적인 스크립트를 주입하는 공격 기법으로 사용자 입력값이 직접 HTML로 삽입되는 경우, 공격자는 악성 스크립트를 삽입하여 실행시킬수 있습니다. 이런 이유로 React 팀에서는 이 기능의 위험성을 강조하기 위해 일부러 '<code >dangerous</code>' 라는 이름을 사용했다고 설명하고 있는데요. 따라서 <code >dangerouslySetInnerHTML</code>을 어쩔수 없이 사용할때는 <code >Sanitization</code>(살균, 소독)을 시켜야 합니다. React 공식 문서에서도 HTML을 직접 삽입할 때는 XSS 방지를 위한 소독(sanitization)이 필요하다고 언급하고 있는데요. 마치 의료기구를 소독해서 세균을 제거하듯이, 사용자가 입력한 데이터에서 악성 코드를 자동으로 제거할 수 있습니다. 따라서 이런 경우 DOMPurify 같은 라이브러리 사용을 추천합니다. 사용법또한 매우 간단합니다. DOMPurify.sanitize 함수로 해당 HTML을 감싸주기만 하면 됩니다. <pre ><code>&lt;div dangerouslySetInnerHTML={{
 __html: DOMPurify.sanitize(dirtyHTML)
}} /&gt;</code></pre> React 팀에서는 가능하면 <code >dangerouslySetInnerHTML</code> 사용을 피하되 꼭 필요한 경우에는 Sanitize 하는걸 권장하고 있습니다. 따라서 <code >dangerouslySetInnerHTML</code> 을 어쩔 수 없이 사용해야 할 경우에는 DOMPurify 라이브러리를 이용해 소독하는 과정을 거쳐 보안을 좀 더 강화할 것을 추천드립니다. https://www.npmjs.com/package/dompurify

React의 dangerouslySetInnerHTML 안전하게 사용하기

번아웃의 원인 분석을 통해 스스로를 돌아보고 이를 극복하는 과정을 정리해 보았습니다.

어느 날, 무기력이 찾아왔다 - 재그지그의 개발 블로그

- 번아웃의 원인 분석을 통해 스스로를 돌아보고 이를 극복하는 과정을 정리해 보았습니다.

---

1월 중순, 저는 새로운 기능을 구현하기 위해 팀원들과 스펙 회의를 진행했습니다. 그런데… 회의를 진행할수록 의욕이 떨어진다는 느낌을 받았습니다. 마치 넘어야 할 산이 끊임없이 나타난다는 느낌을 받았습니다. 가슴이 답답했고 무기력감이 몰려왔습니다.

작년까지만 해도 어렵고 도전적인 업무를 도맡아 했던 저였기에 이런 감정이 낯설고 당황스럽게 느껴졌습니다. 흔히 말하는 번아웃이 온 건가 싶더라구요. 그리고 작년 동료 평가에서 ”번아웃이 걱정 된다” 는 피드백을 들었던 것도 생각이 났습니다.

지금은 2월 중순이 되었고 당시의 감정은 어느 정도 추스렀습니다만, 이런 감정이 생긴 이유를 분석하고 싶었습니다. 그래서 오늘은 당시의 경험을 돌아보고 번아웃을 맞이한 이유와 해결책을 고민하는 과정을 정리해보려 합니다.

https://wormwlrm.github.io/2025/02/16/Analyzing-the-Reasons-of-My-Burnout.html

- 번아웃의 원인 분석을 통해 스스로를 돌아보고 이를 극복하는 과정을 정리해 보았습니다. --- 1월 중순, 저는 새로운 기능을 구현하기 위해 팀원들과 스펙 회의를 진행했습니다. 그런데… 회의를 진행할수록 의욕이 떨어진다는 느낌을 받았습니다. 마치 넘어야 할 산이 끊임없이 나타난다는 느낌을 받았습니다. 가슴이 답답했고 무기력감이 몰려왔습니다. 작년까지만 해도 어렵고 도전적인 업무를 도맡아 했던 저였기에 이런 감정이 낯설고 당황스럽게 느껴졌습니다. 흔히 말하는&nbsp;번아웃이 온 건가 싶더라구요. 그리고 작년 동료 평가에서 ”번아웃이 걱정 된다” 는 피드백을 들었던 것도 생각이 났습니다. 지금은 2월 중순이 되었고 당시의 감정은 어느 정도 추스렀습니다만, 이런 감정이 생긴 이유를 분석하고 싶었습니다. 그래서 오늘은 당시의 경험을 돌아보고 번아웃을 맞이한 이유와 해결책을 고민하는 과정을 정리해보려 합니다. https://wormwlrm.github.io/2025/02/16/Analyzing-the-Reasons-of-My-Burnout.html

재그지그의 개발 블로그

🧭 어느 날, 무기력이 찾아왔다

kotlinx.rpc는 JetBrains가 개발한 Kotlin 멀티플랫폼 RPC 라이브러리로 클라이언트와 서버 모두에서 Kotlin 언어의 표준 기능을 활용하여 원격 함수를 호출할 수 있도록 지원합니다. 이 덕분에 개발자는 네트워크 프로그래밍의 복잡한 세부사항을 몰라도, &hellip;

Introduction to kotlinx.rpc

올해도 발표하겠다고 다짐하기가 무섭게, 기회가 찾아왔다. 이번 발표에서는 kotlinx.rpc 기술을 소개하며, Kotlin 멀티플랫폼 생태계의 새로운 가능성을 탐색하는 시간을 가졌다.

kotlinx.rpc는 JetBrains가 개발한 코틀린 멀티플랫폼 RPC 라이브러리로 클라이언트와 서버 모두에서 코틀린 언어의 표준 기능을 활용하여 원격 함수를 호출할 수 있도록 지원한다. 이 덕분에 엔지니어는 네트워크 프로그래밍의 복잡한 세부 사항을 몰라도, 마치 로컬 함수처럼 원격 서비스를 호출할 수 있다.

나는 코틀린이라는 언어를 좋아한다. 기능도 훌륭하지만, 무엇보다 커뮤니티 중심으로 구성된 생태계와 끊임없이 발전하는 모습이 보기 좋다. 마치 내가 좋아하는 서비스가 승승장구하는 것을 보는 팬의 마음이랄까? 특히, 멀티플랫폼 기술은 나에게 큰 흥미를 불러일으키는 존재다. 3년 전 알파 단계에 머물러 있던 기술이 이제는 안정 단계에 접어들어 다양한 기업에서 활용되는 사례를 보며, 그 성장 가능성에 대한 확신을 갖게 되었다.

이번 발표를 준비하면서 오랜만에 코틀린 멀티플랫폼 프로젝트로 예제를 만들어봤다. 3년 전과 비교하면 정말 많이 안정되었고, 별다른 어려움 없이 쓱쓱 코딩할 수 있었다. 과거에는 불안정한 자동차를 운전하는 듯한 느낌이었다면, 현재는 고급 승용차를 다루는 듯한 안정감을 느꼈다.

더 나아가 컴포즈 멀티플랫폼을 활용하여 Desktop, Android, iOS에서 동일하게 동작하는 모바일 앱을 만들어봤다. 이 기술 또한 그사이 정말 많이 성장했다. 오랜만에 클라이언트 애플리케이션 개발이나, 상태 관리에서 조금 헤맸지만 흥미진진하고 즐거운 시간을 보낼 수 있었다.

---

이번 발표를 통해 kotlinx.rpc 기술을 소개하고, 코틀린 멀티플랫폼 생태계에 대한 흥미를 공유할 수 있어서 행복했습니다. 좋은 자리를 만들어주신 "Kotlin User Groups Seoul" 분들께 감사드립니다. 덕분에 즐겁게 발표하고, 많은 분과 소통할 수 있었습니다.

https://speakerdeck.com/arawn/introduction-to-kotlinx-dot-rpc

올해도 발표하겠다고 다짐하기가 무섭게, 기회가 찾아왔다. 이번 발표에서는 kotlinx.rpc 기술을 소개하며, Kotlin 멀티플랫폼 생태계의 새로운 가능성을 탐색하는 시간을 가졌다. kotlinx.rpc는 JetBrains가 개발한 코틀린 멀티플랫폼 RPC 라이브러리로 클라이언트와 서버 모두에서 코틀린 언어의 표준 기능을 활용하여 원격 함수를 호출할 수 있도록 지원한다. 이 덕분에 엔지니어는 네트워크 프로그래밍의 복잡한 세부 사항을 몰라도, 마치 로컬 함수처럼 원격 서비스를 호출할 수 있다. 나는 코틀린이라는 언어를 좋아한다. 기능도 훌륭하지만, 무엇보다 커뮤니티 중심으로 구성된 생태계와 끊임없이 발전하는 모습이 보기 좋다. 마치 내가 좋아하는 서비스가 승승장구하는 것을 보는 팬의 마음이랄까? 특히, 멀티플랫폼 기술은 나에게 큰 흥미를 불러일으키는 존재다. 3년 전 알파 단계에 머물러 있던 기술이 이제는 안정 단계에 접어들어 다양한 기업에서 활용되는 사례를 보며, 그 성장 가능성에 대한 확신을 갖게 되었다. 이번 발표를 준비하면서 오랜만에 코틀린 멀티플랫폼 프로젝트로 예제를 만들어봤다. 3년 전과 비교하면 정말 많이 안정되었고, 별다른 어려움 없이 쓱쓱 코딩할 수 있었다. 과거에는 불안정한 자동차를 운전하는 듯한 느낌이었다면, 현재는 고급 승용차를 다루는 듯한 안정감을 느꼈다. 더 나아가 컴포즈 멀티플랫폼을 활용하여 Desktop, Android, iOS에서 동일하게 동작하는 모바일 앱을 만들어봤다. 이 기술 또한 그사이 정말 많이 성장했다. 오랜만에 클라이언트 애플리케이션 개발이나, 상태 관리에서 조금 헤맸지만 흥미진진하고 즐거운 시간을 보낼 수 있었다. --- 이번 발표를 통해 kotlinx.rpc 기술을 소개하고, 코틀린 멀티플랫폼 생태계에 대한 흥미를 공유할 수 있어서 행복했습니다. 좋은 자리를 만들어주신 "Kotlin User Groups Seoul" 분들께 감사드립니다. 덕분에 즐겁게 발표하고, 많은 분과 소통할 수 있었습니다. https://speakerdeck.com/arawn/introduction-to-kotlinx-dot-rpc

Speaker Deck

코틀린 멀티플랫폼 개발의 즐거움을 나누다

커서를 쓰기 시작한 이후로 동영상 강의를 더 이상 구매하지 않고 있다는 걸 문득 깨달았습니다. 왜지? 돈 아끼는 걸 좋아한다지만 책 사거나 공부할 때만큼은 아끼지 않았는데.

다시 한 번 산업혁명

커서를 쓰기 시작한 이후로 동영상 강의를 더 이상 구매하지 않고 있다는 걸 문득 깨달았습니다.
왜지? 돈 아끼는 걸 좋아한다지만 책 사거나 공부할 때만큼은 아끼지 않았는데.

그냥 커서랑 챗GPT로 하면 되니깐.
언어든 프레임워크든 잘 모르는 채로 시작하는 게 두렵지 않게 되었습니다.
가나다도 모르는 채로 일단 시작부터 하고 잘 모르겠으면 그때 가서 공식 문서 슬쩍 보고 챗GPT에게 물어봐서 답을 얻는 게 더 편하니까.

2년여 전부터 스택오버플로에 전혀 들어가지 않게 되었는데…
6개월 전부터는 강의조차 안 보게 되었습니다.
며칠 전 재밌어 보이는 강의를 발견하고는 살까 하다가 금세 마음이 가라앉은 저를 발견했습니다.
‘그냥 커서랑 챗GPT로 하면 되잖아.’

이렇게 빠르게 바뀌어버린 제 모습을 보면서 놀라움과 두려움을 느낍니다.

어제 유튜브에서 새로운 산업 혁명의 시작이라는 단테와 노정석 대표님의 대화를 들었습니다.
공감이 가기도 하고 오싹하기도 하고… 복잡한 마음이 들었습니다.
앞으로 몇 년간 기존 산업이 하나씩 대체될 텐데 이런 세상에서 내가 잘 살아남을 수 있을까?

어릴 때 산업 혁명 시대 사람들은 참 좋았겠다 생각했습니다. 돈 벌 기회가 널려있으니까.
새로운 기회가 이렇게 많은데 결국 직업을 잃고 불평하는 사람들을 한심하다 생각하기도 했습니다.
날 그 시절로 데려다주면 내가 돈 다 끌어모을텐데.

막상 산업 혁명 시기가 다시 돌아오니 그 시대 사람들의 두려움을 저도 이해하게 됐습니다.
그들도 기회가 있다는 걸 모르진 않았을 겁니다. 잘 살아남을 수 있을지 걱정됐을 뿐.
살아남기 위해 애쓰고 발버둥 치다가 경쟁에 밀려 다시 돌아올 수 없었던 것 아닐까요?

미래에 대한 기대도 물론 있지만 두려운 마음이 좀 더 큰 것 같습니다.
스타트업 세상에서 모든 성취를 다 이룬 노정석 대표님도 저렇게 열심히 공부하는데, 나는 지금 열심히 살고 있는 것 맞나?

닭장 속에서 모이만 받아먹는 닭이 되지 않기 위해 (영상에서 말씀해주시는 표현) 더 간절한 마음으로 공부하고 코딩해 보려 합니다.

https://jeho.page/essay/2025/02/14/ai-revolution.html

커서를 쓰기 시작한 이후로 동영상 강의를 더 이상 구매하지 않고 있다는 걸 문득 깨달았습니다. 왜지? 돈 아끼는 걸 좋아한다지만 책 사거나 공부할 때만큼은 아끼지 않았는데. 그냥 커서랑 챗GPT로 하면 되니깐. 언어든 프레임워크든 잘 모르는 채로 시작하는 게 두렵지 않게 되었습니다. 가나다도 모르는 채로 일단 시작부터 하고 잘 모르겠으면 그때 가서 공식 문서 슬쩍 보고 챗GPT에게 물어봐서 답을 얻는 게 더 편하니까. 2년여 전부터 스택오버플로에 전혀 들어가지 않게 되었는데… 6개월 전부터는 강의조차 안 보게 되었습니다. 며칠 전 재밌어 보이는 강의를 발견하고는 살까 하다가 금세 마음이 가라앉은 저를 발견했습니다. ‘그냥 커서랑 챗GPT로 하면 되잖아.’ 이렇게 빠르게 바뀌어버린 제 모습을 보면서 놀라움과 두려움을 느낍니다. 어제 유튜브에서 새로운 산업 혁명의 시작이라는 단테와 노정석 대표님의 대화를 들었습니다. 공감이 가기도 하고 오싹하기도 하고… 복잡한 마음이 들었습니다. 앞으로 몇 년간 기존 산업이 하나씩 대체될 텐데 이런 세상에서 내가 잘 살아남을 수 있을까? 어릴 때 산업 혁명 시대 사람들은 참 좋았겠다 생각했습니다. 돈 벌 기회가 널려있으니까. 새로운 기회가 이렇게 많은데 결국 직업을 잃고 불평하는 사람들을 한심하다 생각하기도 했습니다. 날 그 시절로 데려다주면 내가 돈 다 끌어모을텐데. 막상 산업 혁명 시기가 다시 돌아오니 그 시대 사람들의 두려움을 저도 이해하게 됐습니다. 그들도 기회가 있다는 걸 모르진 않았을 겁니다. 잘 살아남을 수 있을지 걱정됐을 뿐. 살아남기 위해 애쓰고 발버둥 치다가 경쟁에 밀려 다시 돌아올 수 없었던 것 아닐까요? 미래에 대한 기대도 물론 있지만 두려운 마음이 좀 더 큰 것 같습니다. 스타트업 세상에서 모든 성취를 다 이룬 노정석 대표님도 저렇게 열심히 공부하는데, 나는 지금 열심히 살고 있는 것 맞나? 닭장 속에서 모이만 받아먹는 닭이 되지 않기 위해 (영상에서 말씀해주시는 표현) 더 간절한 마음으로 공부하고 코딩해 보려 합니다. https://jeho.page/essay/2025/02/14/ai-revolution.html

K리그 프로그래머

우리는 현재 AI의 발전으로 인해,
유래없는 미친 속도의 혁신과 발전을 경험하고 있습니다.

LLM(Large Language Model)을 필두로,
이미지 생성, 다국어 번역, 컨텐츠 요약, 영상 제작 AI까지
무궁무진한 AI들이 말 그대로 쏟아지고 있습니다.

최근 메타(Meta)가 3600명이라는 대규모 인원의 직원을
정리 해고했다는 소식을 보았습니다.
AI가 중급 개발자 능력을 대체할수 있다는
주커버그의 인터뷰가 공개된 지 몇 주만에요.

앞으로 AI의 미친 발전 속도로 인해,
이런 일들은 더욱 많이 발생할 것입니다.
수많은 사람들이 다시 일자리를 잃거나,
또는 자신의 자리를 빼앗길지도 모릅니다.

이럴 때일수록, 앞으로 더 중요하게 여겨질
인간만의 고유한 역량에는 무엇이 있을까요?

저는 바로 능동적 관리(Proactive Management) 역량이라고 생각합니다.

네. 여러분이 생각하시는 그 매니저(Manager)의 역할이 맞습니다.
최근 MZ세대들이 가장 기피하는 직무가 매니저라는 말이 있을만큼,
복잡도가 올라간 세상에서 매니저의 역할 및 임무들은 더욱 많아졌으며,
그 난이도도 예전에 비해 훨씬 올라갔습니다.

예전에는 단순히 매니저라는 직책이
수동적 관리 (Passive management)에 집중했다면,
이제는 미리 문제 상황이나 트랜드를 파악하고,
그에 빠르게 대처하는 능동적 관리 능력(Proactive Management)이
앞으로도 더 많이 요구될 거에요.

우리의 선택지가 하나 또는 둘이였을 때는
큰 관리 능력이 필요하지 않았지만,
우리의 선택지가 많아질 수록,
빠른 시간 내에 좋은 결정을 내리고,
그 결정들을 토대로 탄탄한 시스템(System)을
구축해야 하는 행위는 점점 더 늘어갈 것입니다.

우리의 일상 생활에서도 관리(management) 영역은 꾸준히 확대되어 왔습니다.

개인적인 차원에서는 여러분들이 즐겨보는
OTT 구독 관리, SNS 관리, 건강 상태 관리, 경제/재무 관리 등이 있습니다.

그리고 전 세계적으로는
지속 가능한 발전 (Sustainable Progress),
환경 보호 (Environmental Conservation)과 같은
미래에 꼭 이루어야 할 관리(management)가 있습니다.

저는 AI에게 모든 것을 맡기고,
인간이 AI에 대체된다는 절망감을 가지기보다는,
오히려 AI를 더 잘 이해하고, 어떻게 AI와 협력했을 때,
더 좋은 성과/결과를 만들어낼 수 있을지를 연구하고 있습니다.

앞으로의 시대가 어떻게 변화될지는 누구도 정확하게 예측할 수 없습니다.
하지만 나만의 고유한 관리 능력을 가진 이들이 더 많은 변화에 적응하고,
그들만의 탄탄한 시스템을 만들것이란 생각은 변함이 없습니다.

AI를 수용하되, AI 중심이 아닌,
이미 구축한 자신의 시스템 중심으로 AI를 수용한다면,
우리는 또다른 새로운 영역의 혁신을 마주할 수 있을 거에요.

우리는 현재 AI의 발전으로 인해,유래없는 미친 속도의 혁신과 발전을 경험하고 있습니다. LLM(Large Language Model)을 필두로,이미지 생성, 다국어 번역, 컨텐츠 요약, 영상 제작 AI까지무궁무진한 AI들이 말 그대로 쏟아지고 있습니다. 최근 메타(Meta)가 3600명이라는 대규모 인원의 직원을정리 해고했다는 소식을 보았습니다.AI가 중급 개발자 능력을 대체할수 있다는주커버그의 인터뷰가 공개된 지 몇 주만에요. 앞으로 AI의 미친 발전 속도로 인해,이런 일들은 더욱 많이 발생할 것입니다.수많은 사람들이 다시 일자리를 잃거나,또는 자신의 자리를 빼앗길지도 모릅니다. 이럴 때일수록, 앞으로 더 중요하게 여겨질인간만의 고유한 역량에는 무엇이 있을까요? 저는 바로 능동적 관리(Proactive Management) 역량이라고 생각합니다. 네. 여러분이 생각하시는 그 매니저(Manager)의 역할이 맞습니다.최근 MZ세대들이 가장 기피하는 직무가 매니저라는 말이 있을만큼,복잡도가 올라간 세상에서 매니저의 역할 및 임무들은 더욱 많아졌으며,그 난이도도 예전에 비해 훨씬 올라갔습니다. 예전에는 단순히 매니저라는 직책이수동적 관리 (Passive management)에 집중했다면,이제는 미리 문제 상황이나 트랜드를 파악하고,그에 빠르게 대처하는 능동적 관리 능력(Proactive Management)이앞으로도 더 많이 요구될 거에요. 우리의 선택지가 하나 또는 둘이였을 때는큰 관리 능력이 필요하지 않았지만,우리의 선택지가 많아질 수록,빠른 시간 내에 좋은 결정을 내리고,그 결정들을 토대로 탄탄한 시스템(System)을구축해야 하는 행위는 점점 더 늘어갈 것입니다. 우리의 일상 생활에서도 관리(management) 영역은 꾸준히 확대되어 왔습니다. 개인적인 차원에서는 여러분들이 즐겨보는OTT 구독 관리, SNS 관리, 건강 상태 관리, 경제/재무 관리 등이 있습니다. 그리고 전 세계적으로는지속 가능한 발전 (Sustainable Progress),환경 보호 (Environmental Conservation)과 같은미래에 꼭 이루어야 할 관리(management)가 있습니다. 저는 AI에게 모든 것을 맡기고,인간이 AI에 대체된다는 절망감을 가지기보다는,오히려 AI를 더 잘 이해하고, 어떻게 AI와 협력했을 때,더 좋은 성과/결과를 만들어낼 수 있을지를 연구하고 있습니다. 앞으로의 시대가 어떻게 변화될지는 누구도 정확하게 예측할 수 없습니다.하지만 나만의 고유한 관리 능력을 가진 이들이 더 많은 변화에 적응하고,그들만의 탄탄한 시스템을 만들것이란 생각은 변함이 없습니다. AI를 수용하되, AI 중심이 아닌,이미 구축한 자신의 시스템 중심으로 AI를 수용한다면,우리는 또다른 새로운 영역의 혁신을 마주할 수 있을 거에요.

능동적 관리 (Proactive Management)의 시대가 옵

우여곡절 끝에 아미고를 출시합니다. 우선 iOS만 출시했습니다. (우선 한국 스토어만, 안드로이드는 2주 뒤에 출시 예정)

https://bit.ly/ameego-ios

영어 학습이 궁극의 목표는 아닙니다만, 다른 이야기는 차차하도록 하고요. 영어를 배우는 앱으로써 Ameego의 컨셉을 간단히 소개드리면,

- 언제까지 듀오링고만(기초만) 할텐가? 조금 어려운 도전을 해야 실력이는다.

- 시중에 나온 자막을 보며 말하는 연습은 말하기가 아니라 사실 읽기 쓰기이다.

- 영어를 배우는 가장 좋은 방법은 논란의 여지가 없이 친구 사귀기이다. 말만 친구가 아니라 진짜 친구 같은 경험을 주자.

- 실리콘밸리의 영어 발음은 미국/영국 발음이 아니라 인도 발음이 표준이다 🤣 그러므로 다양한 발음과 말투에 노출되어야한다.

- 전화영어를 넘어 유학의 경험, 영어의 세상에 들어가는 경험을 주자.

마지막으로, 아직 결제 테스트가 부족합니다. 테스트삼아 많이 결제 해 주세요. 🥹

더 많은 이야기는 앞으로 지겹도록 하겠습니다. 감사합니다! 🙇🏻‍♀️🙇🏻

우여곡절 끝에 아미고를 출시합니다. 우선 iOS만 출시했습니다. (우선 한국 스토어만, 안드로이드는 2주 뒤에 출시 예정) https://bit.ly/ameego-ios 영어 학습이 궁극의 목표는 아닙니다만, 다른 이야기는 차차하도록 하고요. 영어를 배우는 앱으로써 Ameego의 컨셉을 간단히 소개드리면, - 언제까지 듀오링고만(기초만) 할텐가? 조금 어려운 도전을 해야 실력이는다. - 시중에 나온 자막을 보며 말하는 연습은 말하기가 아니라 사실 읽기 쓰기이다. - 영어를 배우는 가장 좋은 방법은 논란의 여지가 없이 친구 사귀기이다. 말만 친구가 아니라 진짜 친구 같은 경험을 주자. - 실리콘밸리의 영어 발음은 미국/영국 발음이 아니라 인도 발음이 표준이다 🤣 그러므로 다양한 발음과 말투에 노출되어야한다. - 전화영어를 넘어 유학의 경험, 영어의 세상에 들어가는 경험을 주자. 마지막으로, 아직 결제 테스트가 부족합니다. 테스트삼아 많이 결제 해 주세요. 🥹 더 많은 이야기는 앞으로 지겹도록 하겠습니다. 감사합니다! 🙇🏻‍♀️🙇🏻

🚀 Ameego, 마침내 출시!

[번역] 환경변수에 시크릿 값을 저장하지 않고 사용하는 더 나은 방법

오늘은 두나무의 조영제님이 번역해주신 글입니다.

우리가 자바스크립트로 프론트엔드나 백엔드 작업을 할 때는 환경 변수 관리를 위해 .env 파일을 사용하는 경우가 많습니다. 개발을 시작할 때 대부분 이렇게 관리하는 모습을 보았고, 아무래도 이 글에서 언급하는 것처럼 그렇게 하는 것이 편하기 때문일 것입니다.
이 글은 크게 두 가지를 다루고 있습니다. 첫 번째는 환경 변수에 시크릿 값을 저장하는 것이 왜 위험한지, 다양한 실제 사례를 통해 설명해줍니다. 두 번째는 시크릿 값을 안전하게 사용하는 다양한 방법에 대해 소개합니다. 이 글이 여러분이 운영하는 서비스의 보안 강화에 도움이 되길 바랍니다.

참고로 글 내에는 없지만 도플러 라는 서비스도 개인적으로 좋게 봤습니다!

글 링크: https://bit.ly/3CCk08b

오늘은 두나무의 조영제님이 번역해주신 글입니다. 우리가 자바스크립트로 프론트엔드나 백엔드 작업을 할 때는 환경 변수 관리를 위해 .env 파일을 사용하는 경우가 많습니다. 개발을 시작할 때 대부분 이렇게 관리하는 모습을 보았고, 아무래도 이 글에서 언급하는 것처럼 그렇게 하는 것이 편하기 때문일 것입니다.이 글은 크게 두 가지를 다루고 있습니다. 첫 번째는 환경 변수에 시크릿 값을 저장하는 것이 왜 위험한지, 다양한 실제 사례를 통해 설명해줍니다. 두 번째는 시크릿 값을 안전하게 사용하는 다양한 방법에 대해 소개합니다. 이 글이 여러분이 운영하는 서비스의 보안 강화에 도움이 되길 바랍니다. 참고로 글 내에는 없지만 도플러 라는 서비스도 개인적으로 좋게 봤습니다! 글 링크: https://bit.ly/3CCk08b

redis를 활용한 대규모 트래픽 처리

환경변수에 시크릿 값을 저장하지 않고 사용하는 더 나은 방법

테스트를 작성하다 보면 여러 테스트에 걸쳐서 반복되는 로직이 생기기 마련인데요. 이러한 공통 로직을 모든 테스트마다 중복해서 작성하면 개발 생산성이 떨이지고 유지보수가 힘들어집니다.

이번 포스팅에서는 Vitest를 이용해서 테스트 전이나 후에 항상 실행되야 하는 로직을 효과적으로 실행하는 방법에 대해서 알아보겠습니다.

📺 동영상: https://youtu.be/0fV30sUDAXE
📝 게시물: https://www.daleseo.com/vitest-before-after/

차세대 테스팅 프레임워크로 각광받고 있는 Vitest를 학습하시는 분들께 아래 게시물도 추천드리겠습니다.

📕 Vitest 처음 시작하기: https://careerly.co.kr/comments/115949
📗 Vitest 결과 매칭: https://careerly.co.kr/comments/116437
📘 Vitest 그룹화: https://careerly.co.kr/comments/116659

테스트를 작성하다 보면 여러 테스트에 걸쳐서 반복되는 로직이 생기기 마련인데요. 이러한 공통 로직을 모든 테스트마다 중복해서 작성하면 개발 생산성이 떨이지고 유지보수가 힘들어집니다. 이번 포스팅에서는 Vitest를 이용해서 테스트 전이나 후에 항상 실행되야 하는 로직을 효과적으로 실행하는 방법에 대해서 알아보겠습니다. 📺 동영상: https://youtu.be/0fV30sUDAXE📝 게시물: https://www.daleseo.com/vitest-before-after/ 차세대 테스팅 프레임워크로 각광받고 있는 Vitest를 학습하시는 분들께 아래 게시물도 추천드리겠습니다. 📕 Vitest 처음 시작하기: https://careerly.co.kr/comments/115949📗 Vitest 결과 매칭: https://careerly.co.kr/comments/116437📘 Vitest 그룹화: https://careerly.co.kr/comments/116659

Vitest 테스트 전/후 처리하기

React를 처음 접하는 개발자라면, 함수형 컴포넌트와 클래스형 컴포넌트의 차이, 그리고 상태 관리 방식에 대한 고민이 많을 것입니다.과거에는 React에서 상태(state)를 관리하려면 클래스형 컴포넌트를 사용해야 했습니다. 하지만 코드가 길어지고, 재사용성이 떨어지는 문제가 있었습니다. 이를 해결하기 위해 React Hook이 등장하였으며, 함수형 컴포넌트에서도 상태 관리와 생명주기 메서드의 역할을 수행할 수 있도록 도와줍니다. React Hook이 필요한 이유더 간결한 코드: 클래스형 컴포넌트보다 코드가 직관적이고 짧아짐가독성과 유지보수성 향상: 관심사 분리가 쉬워지고, 재사용성이 증가부수 효과 관리가 용이: useEffect를 활용하여 사이드 이펙트 관리를 쉽게 수행 가능백엔드 개발자의 입장에서 ..

백엔드 개발자를 위한 React Hook 가이드

과거에는 React에서 상태(state)를 관리하려면 클래스형 컴포넌트를 사용해야 했습니다. 하지만 코드가 길어지고, 재사용성이 떨어지는 문제가 있었습니다. 이를 해결하기 위해 React Hook이 등장하였으며, 함수형 컴포넌트에서도 상태 관리와 생명주기 메서드의 역할을 수행할 수 있도록 도와줍니다.
 
React Hook이 필요한 이유
 * 더 간결한 코드: 클래스형 컴포넌트보다 코드가 직관적이고 짧아짐
 * 가독성과 유지보수성 향상: 관심사 분리가 쉬워지고, 재사용성이 증가
 * 부수 효과 관리가 용이: useEffect를 활용하여 사이드 이펙트 관리를 쉽게 수행 가능

이번 글에서는 백엔드 개발자의 시선에서 React Hook을 이해하기 쉽게 설명하고, 실무에서 어떻게 활용할 수 있는지 살펴보겠습니다.
 
주요 React Hook 소개
 
[useState - 상태 관리]
useState는 컴포넌트 내부에서 상태(state)를 선언하고 변경할 수 있도록 도와줍니다.
import { useState } from "react";

function Counter() {
 const [count, setCount] = useState(0); // 상태 선언

 return (
 <div>
 현재 카운트: {count}
 <button onClick={() => setCount(count + 1)}>증가</button>
 </div>
 );
}

✅ useState는 Java에서 변수와 Setter 메서드를 사용하는 방식과 유사합니다.
하지만 React에서는 상태가 변경될 때마다 컴포넌트가 다시 렌더링된다는 차이점이 있습니다.
 
[useEffect - 부수 효과(Site Effect) 처리]
useEffect는 컴포넌트가 렌더링될 때 실행해야 하는 코드(데이터 가져오기, 이벤트 리스너 등록 등)를 처리하는 Hook 입니다.
import { useState, useEffect } from "react";

function Timer() {
 const [seconds, setSeconds] = useState(0);

 useEffect(() => {
 const interval = setInterval(() => {
 setSeconds((prev) => prev + 1);
 }, 1000);

 return () => clearInterval(interval); 
 }, []);

 return 타이머: {seconds}초;
}

✅ useEffect는 Spring의 @PostConstruct 및 @PreDestroy와 유사합니다.
 * @PostConstruct: 컴포넌트가 처음 렌더링될 때 실행 (useEffect의 초기 실행)
 * @PreDestroy: 컴포넌트가 사라질 때 정리 (useEffect의 Cleanup)

[useMemo - 성능 최적화]
useMemo는 불필요한 연산을 방지하여 성능을 최적화할 때 사용됩니다.
import { useState, useMemo } from "react";

function ExpensiveCalculation({ num }) {
 const squaredValue = useMemo(() => {
 console.log("연산 수행 중...");
 return num * num;
 }, [num]); // num이 변경될 때만 다시 계산

 return 계산 결과: {squaredValue};
}

✅ useMemo는 Java의 캐싱(Cache)과 비슷합니다.
useMemo를 활용하면 같은 입력값에 대해 불필요한 연산을 줄이고 캐싱된 값을 활용할 수 있습니다.
 
[useCallback - 함수 메모이제이션]
useCallback은 useMemo와 유사하지만, 함수의 참조값을 유지하여 불필요한 렌더링을 방지하는 Hook입니다.
import { useState, useCallback } from "react";

function Parent() {
 const [count, setCount] = useState(0);

 const handleClick = useCallback(() => {
 setCount((prev) => prev + 1);
 }, []);

 return <button onClick={handleClick}>증가</button>;
}

✅ useCallback은 Spring의 Singleton 패턴과 비슷합니다.
 
[useRef - DOM 접근 & 상태 유지]
useRef는 컴포넌트의 상태를 변경하지 않고도 특정 값을 유지하거나, DOM 요소에 직접 접근할 때 사용됩니다.
import { useRef } from "react";

function TextInput() {
 const inputRef = useRef(null);

 const focusInput = () => {
 inputRef.current.focus();
 };

 return (
 <div>
 <input ref={inputRef} type="text" />
 <button onClick={focusInput}>포커스 이동</button>
 </div>
 );
}

✅ useRef는 Java의 인스턴스 변수와 비슷한 역할을 합니다.
 
결론
React Hook은 함수형 컴포넌트에서 상태 관리와 부수 효과 처리를 쉽게 구현할 수 있도록 도와줍니다.
각 Hook의 활용 사례를 정리하면 다음과 같습니다.
 * useState → 컴포넌트 내부의 상태 관리
 * useEffect → 부수 효과 처리 (API 호출, 이벤트 리스너 등록 등)
 * useMemo → 연산 결과 캐싱 (불필요한 재계산 방지)
 * useCallback → 함수 메모이제이션 (불필요한 렌더링 방지)
 * useRef → DOM 접근 및 값 유지
백엔드 개발자라면, React를 API 연동이 필요한 대시보드나 어드민 UI 개발에 활용할 때가 많을 것입니다.
Hook을 잘 활용하면 성능을 최적화하고 유지보수하기 쉬운 코드 작성이 가능하므로, 실무에서도 유용하게 사용할 수 있습니다!

과거에는 React에서 상태(state)를 관리하려면 클래스형 컴포넌트를 사용해야 했습니다. 하지만 코드가 길어지고, 재사용성이 떨어지는 문제가 있었습니다. 이를 해결하기 위해 React Hook이 등장하였으며, 함수형 컴포넌트에서도 상태 관리와 생명주기 메서드의 역할을 수행할 수 있도록 도와줍니다.&nbsp;React Hook이 필요한 이유<ul ><li>더 간결한 코드: 클래스형 컴포넌트보다 코드가 직관적이고 짧아짐</li><li>가독성과 유지보수성 향상: 관심사 분리가 쉬워지고, 재사용성이 증가</li><li>부수 효과 관리가 용이: useEffect를 활용하여 사이드 이펙트 관리를 쉽게 수행 가능</li></ul> 이번 글에서는 백엔드 개발자의 시선에서 React Hook을 이해하기 쉽게 설명하고, 실무에서 어떻게 활용할 수 있는지 살펴보겠습니다.&nbsp;주요 React Hook 소개&nbsp;[useState - 상태 관리]useState는 컴포넌트 내부에서 상태(state)를 선언하고 변경할 수 있도록 도와줍니다.<pre ><code class="language-javascript">import { useState } from "react";

function Counter() {
 const [count, setCount] = useState(0); // 상태 선언

 return (
 &lt;div&gt;
 &lt;p&gt;현재 카운트: {count}&lt;/p&gt;
 &lt;button onClick={() =&gt; setCount(count + 1)}&gt;증가&lt;/button&gt;
 &lt;/div&gt;
 );
}</code></pre>✅ useState는 Java에서 변수와 Setter 메서드를 사용하는 방식과 유사합니다.하지만 React에서는 상태가 변경될 때마다 컴포넌트가 다시 렌더링된다는 차이점이 있습니다.&nbsp;[useEffect&nbsp;- 부수 효과(Site Effect) 처리]useEffect는&nbsp;컴포넌트가 렌더링될 때 실행해야 하는 코드(데이터 가져오기, 이벤트 리스너 등록 등)를 처리하는 Hook 입니다.<pre ><code class="language-javascript">import { useState, useEffect } from "react";

function Timer() {
 const [seconds, setSeconds] = useState(0);

 useEffect(() =&gt; {
 const interval = setInterval(() =&gt; {
 setSeconds((prev) =&gt; prev + 1);
 }, 1000);

 return () =&gt; clearInterval(interval); 
 }, []);

 return &lt;p&gt;타이머: {seconds}초&lt;/p&gt;;
}</code></pre>✅ useEffect는 Spring의 @PostConstruct 및 @PreDestroy와 유사합니다.<ul ><li>@PostConstruct: 컴포넌트가 처음 렌더링될 때 실행 (useEffect의 초기 실행)</li><li>@PreDestroy: 컴포넌트가 사라질 때 정리 (useEffect의 Cleanup)</li></ul> [useMemo&nbsp;- 성능 최적화]useMemo는 불필요한 연산을 방지하여 성능을 최적화할 때 사용됩니다.<pre ><code class="language-javascript">import { useState, useMemo } from "react";

function ExpensiveCalculation({ num }) {
 const squaredValue = useMemo(() =&gt; {
 console.log("연산 수행 중...");
 return num * num;
 }, [num]); // num이 변경될 때만 다시 계산

 return &lt;p&gt;계산 결과: {squaredValue}&lt;/p&gt;;
}</code></pre>✅ useMemo는 Java의 캐싱(Cache)과 비슷합니다.useMemo를 활용하면 같은 입력값에 대해 불필요한 연산을 줄이고 캐싱된 값을 활용할 수 있습니다.&nbsp;[useCallback&nbsp;- 함수 메모이제이션]useCallback은 useMemo와 유사하지만, 함수의 참조값을 유지하여 불필요한 렌더링을 방지하는 Hook입니다.<pre ><code class="language-javascript">import { useState, useCallback } from "react";

function Parent() {
 const [count, setCount] = useState(0);

 const handleClick = useCallback(() =&gt; {
 setCount((prev) =&gt; prev + 1);
 }, []);

 return &lt;button onClick={handleClick}&gt;증가&lt;/button&gt;;
}</code></pre>✅ useCallback은 Spring의 Singleton 패턴과 비슷합니다.&nbsp;[useRef&nbsp;- DOM 접근 &amp; 상태 유지]useRef는 컴포넌트의 상태를 변경하지 않고도 특정 값을 유지하거나, DOM 요소에 직접 접근할 때 사용됩니다.<pre ><code class="language-javascript">import { useRef } from "react";

function TextInput() {
 const inputRef = useRef(null);

 const focusInput = () =&gt; {
 inputRef.current.focus();
 };

 return (
 &lt;div&gt;
 &lt;input ref={inputRef} type="text" /&gt;
 &lt;button onClick={focusInput}&gt;포커스 이동&lt;/button&gt;
 &lt;/div&gt;
 );
}</code></pre>✅ useRef는 Java의 인스턴스 변수와 비슷한 역할을 합니다.&nbsp;결론React Hook은 함수형 컴포넌트에서 상태 관리와 부수 효과 처리를 쉽게 구현할 수 있도록 도와줍니다.각 Hook의 활용 사례를 정리하면 다음과 같습니다.<ul ><li>useState → 컴포넌트 내부의 상태 관리</li><li>useEffect → 부수 효과 처리 (API 호출, 이벤트 리스너 등록 등)</li><li>useMemo → 연산 결과 캐싱 (불필요한 재계산 방지)</li><li>useCallback → 함수 메모이제이션 (불필요한 렌더링 방지)</li><li>useRef → DOM 접근 및 값 유지</li></ul>백엔드 개발자라면, React를 API 연동이 필요한 대시보드나 어드민 UI 개발에 활용할 때가 많을 것입니다. Hook을 잘 활용하면 성능을 최적화하고 유지보수하기 쉬운 코드 작성이 가능하므로, 실무에서도 유용하게 사용할 수 있습니다!

덕토피아

🕊️ 백엔드 개발자를 위한 React Hook 가이드

01 . 10년 넘게 스테디셀러로 사랑받아온 임경선 작가님의 ⟪태도에 관하여⟫를 최근 다시 읽게 되었습니다. 오랜만에 봐도 여전히 좋은 문장들이 쏙쏙 눈에 들어왔고, 공감 되는 지점들 역시 또 한 번 반갑게 만날 수 있어 무척 기쁘더라고요. 더불어 최근 리뉴얼 된 버전을 사서 읽은 덕분에 조금씩 업데이트된 내용들을 만나는 소소한 재미도 있었습니다.
처음 이 책을 읽었던 게 2016년, 두 번째 읽은 것이 2020년, 그리고 이번에 다시 읽게 되었으니 삼회독을 하는 과정에서 저 또한 한뼘이라도 더 성장했기를 바라는 마음이 간절한 것도 사실이었죠.

02 . 그러다 문득 두 번째 읽을 당시 책 앞에 써놓은 소감 문구가 궁금해졌습니다. 저는 나름 제게 의미 있었다고 생각되는 책 앞에는 짧게나마 메모를 덧붙여 그 소감을 기록해놓는 습관이 있는데, 그 때의 나는 이 책을 읽고 무슨 생각을 했었나를 다시 확인하고 싶어진 것이죠. 아마도 사회생활을 시작한 지 7-8년 정도가 흐른 즈음이었고, 팬데믹이 한창이었던 만큼 실제 사람들과의 관계 보다 저 자신과 마주하는 순간들이 더 많았을 그 시간에, 나는 '태도에 관하여' 어떤 생각을 가지고 있었을까라는 질문이 떠오른 겁니다.

03 . 그리고 그때의 저는 이런 문구를 써놓았다는 사실을 발견했죠.
'누군가는 태도가 경쟁력이라고 했고 누군가는 태도가 지능이라고 했다.
하지만 나에게 태도는 반사 신경이다. 오랫동안 나의 몸과 마음에 새겨온 다짐들로 큰 고민 없이 언제나 즉각적으로 내보일 수 있는 것. 얄팍한 계산이나 요란한 허세를 거치지 않고 나의 진심으로부터 나의 행동까지 이어지는 최단거리.'

04 . 다행인 건 그때나 지금이나 태도에 관한 제 생각은 크게 달라지지 않았다는 사실이었습니다. (물론 생각이야 언제든 달라질 수 있지만 그래도 과거의 내가 지금과 비슷한 생각을 갖고 있었다는 사실 역시 반가운 지점이니까요)
살다 보면 이 사람 저 사람 다 겪게 되는 게 인지상정인데 그러다 보면 묘한 공통점 하나가 발견됩니다. 그중 하나는 '사람 사는 게 크게 다르지 않을 텐데, 누군가에게는 늘 이상한 일들이 일어난다'는 점이죠. 다시 말해 언제, 어디서, 누굴 만나든 본인의 답답함과 억울함을 풀어 놓기에만 급급한 사람들이 있고 그 사람들의 이야기를 듣다 보면 늘 그 주위에는 본인을 힘들게 하는 비상식적인 사람들만 존재한다는 것이었습니다.

05 . 처음엔 저도 곧이곧대로 그 말들을 들어주던 시절이 있었습니다. 하지만 시간이 지나다보니 저도 자연스레 알게 되더라고요. 실제로 그 사람에게 일어난 일이 1이라면 자기 방식대로 변형하고 곡해한 과정을 거쳐서 스스로 9..10.. 아니 그보다 더 큰 답답함과 억울함을 생산해 내고 있단 사실을 말이죠. 그러니 일반적인 상식 수준에서는 '그럴 수도 있지'라고 넘길만한 일을 '나에게 감히?'라는 방식으로 접근하고, 그저 평범한 말 한마디조차 심한 과장을 덧대어 옮기는 바람에 발화자에게 모든 책임을 덮어씌우는 행동을 반복하고 있었던 겁니다. 이쯤 되면 누군가에게 보여지는 태도만큼이나 누군가를 받아들이는 태도 역시 얼마나 중요한지를 깨닫게 되죠.

06 . 태도를 '반사 신경'이라고 표현한 것도 이 같은 생각에서였습니다. 우리네 삶에서는 좋은 관계를 유지하며 좋은 결과물을 만들기 위해 견지해야 하는 태도가 있나 하면 실생활에서 즉각적으로, 반사적으로 드러나는 태도들도 있습니다. 꼭 눈앞의 무엇인가를 위해서 갖춘 태도가 아니라 늘 본인의 기준 속에서 '옳다'라고 생각하기에 익혀온 것들이 말과 행동으로 전환되어 반응하는 순간들이 있기 때문이죠. 그리고 사실상 이런 태도들이야말로 그 사람에 대한 진짜 평가를 내리는데 굉장히 중요한 요인으로 작용하는 것일 수도 있습니다. 무의식적인 태도가 이 정도 수준이라면, 이 사람이 의식적으로 행동하기 시작했을 때는 얼마나 더 좋은 태도를 보일지 사뭇 기대가 되기 마련이니까요.

07 . 제가 봤을 때 태도의 반사 신경이 좋은 사람들 역시 비슷한 공통점을 가지고 있었습니다. 그 많은 것들 중 제가 가장 인상 깊게 본 특징은 본인에게 안 좋은 일이 일어났을 때의 반응이었는데요, 그 힘든 상황 속에서도 스스로의 감정에 매몰되어 누군가에게 그 기분을 일방적으로 전달하듯 말하는 게 아니라 늘 자신의 기준을 기반으로 적어도 한 번은 필터링을 거친 채로 생각을 표현한다는 것이었습니다. 배려라는 말로도 부족하고, 메타인지라는 단어로는 더 부족한 특유의 태도가 빛을 발하는 순간이죠.

08 . 예를 들어 '나에게 오늘 ~ 이런 이런 일이 있었는데, 여러 번 좋은 방향으로 생각해보려 해도 하루 종일 찜찜한 기분이 따라다니더라고. 내가 너무 민감한 걸까 아니면 상대가 무례했던 게 맞는 걸까?'라든지 '누군가 나에게 조언을 구해서 ~ 이렇게 이야기를 해줬는데, 가만히 생각하니 너무 내 입장에서 이야기를 전달했던 것 같아. 오해가 없도록 이따 다시 가서 더 잘 설명해 줘야 할 것 같아'처럼 자신에게 일어난 일을 여러 입장에서 고민해 본 후 나름 해결된 부분과 그렇지 않은 부분을 잘 정리하는 경우가 많았거든요. 심지어 가장 가까운 사람들에게 말할 때조차 자신의 부정적인 감정이 너무 날 것으로 전달될까 봐 늘 조심하는 태도를 발견할 때만 '아 나도 저런 태도는 꼭 배우고 익혀놓고 싶다'는 생각이 천 번이고 만 번이고 들게 되죠.

09 . 저는 이런 노력이 가능한 이유는 평소 본인이 가진 좋은 기준들이 반사 신경처럼 작용한 덕분이라고 생각합니다.
실제 운동역학에서는 반사 신경을 두고 이런 진단을 내리기도 합니다. '반사 신경이 뛰어나면 일반적인 움직임에서의 에너지 소모가 훨씬 효율적이다. 학습과 경험에 의해 자신만의 최적 동선이 갖춰진 결과 불필요한 에너지를 거의 사용하지 않기 때문이다'라고 말이죠.
그런 의미에서 보자면 태도 역시 마찬가지겠죠. 평소에 태도의 반사 신경이 좋은 사람들은 사소한 부분들을 대함에 있어 굳이 꼬아서 듣거나, 이기적으로 생각하거나, 소모적으로 언쟁할 에너지를 사용하지 않는 겁니다. 대신 진짜 그 에너지를 써야 하는 상황이 오면 자신을 객관화시켜 가면서까지 좋은 방향으로 답을 찾으려는 노력을 하는 거죠. 어디다 에너지를 써야 하고 어디다 쓰지 않아야 하는지를 본능적으로 아는 셈입니다.

10 . 태도의 중요성은 아무리 강조해도 지나침이 없겠지만 의도적으로, 의식적으로 좋은 태도를 가지려는 노력만큼이나 정말 언제 어디서 어떤 일이 일어나더라도 즉각적으로 보여줄 수 있는 태도들을 잘 익혀놓는 것도 중요하다고 생각합니다. 개인적으로 '좋은 사람들은 남들로 하여금 오해를 불러일으키지 않는다'는 말을 참 좋아하는데요, 이 역시 그동안 우리에게 반사 신경처럼 보여준 좋은 태도들이 기반이 되어 혹시라도 그 사람을 평가해야 하는 순간이 왔을 때마저 아주 명쾌하고 정확하게 상대를 받아들일 수 있도록 해주는 것인지도 모릅니다. '좋은 태도를 갖춘 사람'이란 그 한 문장으로 말이죠.
그러니 본인 기분 좋을 때는 세상이 다 같이 기뻐해 줘야 하고, 본인에게 조금이라도 기분 나쁜 일이 있으면 세상이 같이 울어줘야 한다는 얌체 심보는 저 멀리 던져두고 이제 언제든 즉시, 빠르고 가볍게 보여줄 수 있는 좋은 태도들을 학습해 나가는 것은 어떨까요? 어차피 평생 가지고 살아야 할 것이 태도라면 필요할 때마다 새로 익혀서 보여주는 건 너무 힘들고 비효율적일 테니까요.

01 . 10년 넘게 스테디셀러로 사랑받아온 임경선 작가님의 ⟪태도에 관하여⟫를 최근 다시 읽게 되었습니다. 오랜만에 봐도 여전히 좋은 문장들이 쏙쏙 눈에 들어왔고, 공감 되는 지점들 역시 또 한 번 반갑게 만날 수 있어 무척 기쁘더라고요. 더불어 최근 리뉴얼 된 버전을 사서 읽은 덕분에 조금씩 업데이트된 내용들을 만나는 소소한 재미도 있었습니다. 처음 이 책을 읽었던 게 2016년, 두 번째 읽은 것이 2020년, 그리고 이번에 다시 읽게 되었으니 삼회독을 하는 과정에서 저 또한 한뼘이라도 더 성장했기를 바라는 마음이 간절한 것도 사실이었죠. 02 . 그러다 문득 두 번째 읽을 당시 책 앞에 써놓은 소감 문구가 궁금해졌습니다. 저는 나름 제게 의미 있었다고 생각되는 책 앞에는 짧게나마 메모를 덧붙여 그 소감을 기록해놓는 습관이 있는데, 그 때의 나는 이 책을 읽고 무슨 생각을 했었나를 다시 확인하고 싶어진 것이죠. 아마도 사회생활을 시작한 지 7-8년 정도가 흐른 즈음이었고, 팬데믹이 한창이었던 만큼 실제 사람들과의 관계 보다 저 자신과 마주하는 순간들이 더 많았을 그 시간에, 나는 '태도에 관하여' 어떤 생각을 가지고 있었을까라는 질문이 떠오른 겁니다. 03 . 그리고 그때의 저는 이런 문구를 써놓았다는 사실을 발견했죠. '누군가는 태도가 경쟁력이라고 했고 누군가는 태도가 지능이라고 했다.하지만 나에게 태도는 반사 신경이다. 오랫동안 나의 몸과 마음에 새겨온 다짐들로 큰 고민 없이 언제나 즉각적으로 내보일 수 있는 것. 얄팍한 계산이나 요란한 허세를 거치지 않고 나의 진심으로부터 나의 행동까지 이어지는 최단거리.' 04 . 다행인 건 그때나 지금이나 태도에 관한 제 생각은 크게 달라지지 않았다는 사실이었습니다. (물론 생각이야 언제든 달라질 수 있지만 그래도 과거의 내가 지금과 비슷한 생각을 갖고 있었다는 사실 역시 반가운 지점이니까요) 살다 보면 이 사람 저 사람 다 겪게 되는 게 인지상정인데 그러다 보면 묘한 공통점 하나가 발견됩니다. 그중 하나는 '사람 사는 게 크게 다르지 않을 텐데, 누군가에게는 늘 이상한 일들이 일어난다'는 점이죠. 다시 말해 언제, 어디서, 누굴 만나든 본인의 답답함과 억울함을 풀어 놓기에만 급급한 사람들이 있고 그 사람들의 이야기를 듣다 보면 늘 그 주위에는 본인을 힘들게 하는 비상식적인 사람들만 존재한다는 것이었습니다. 05 . 처음엔 저도 곧이곧대로 그 말들을 들어주던 시절이 있었습니다. 하지만 시간이 지나다보니 저도 자연스레 알게 되더라고요. 실제로 그 사람에게 일어난 일이 1이라면 자기 방식대로 변형하고 곡해한 과정을 거쳐서 스스로 9..10.. 아니 그보다 더 큰 답답함과 억울함을 생산해 내고 있단 사실을 말이죠. 그러니 일반적인 상식 수준에서는 '그럴 수도 있지'라고 넘길만한 일을 '나에게 감히?'라는 방식으로 접근하고, 그저 평범한 말 한마디조차 심한 과장을 덧대어 옮기는 바람에 발화자에게 모든 책임을 덮어씌우는 행동을 반복하고 있었던 겁니다. 이쯤 되면 누군가에게 보여지는 태도만큼이나 누군가를 받아들이는 태도 역시 얼마나 중요한지를 깨닫게 되죠. 06 . 태도를 '반사 신경'이라고 표현한 것도 이 같은 생각에서였습니다. 우리네 삶에서는 좋은 관계를 유지하며 좋은 결과물을 만들기 위해 견지해야 하는 태도가 있나 하면 실생활에서 즉각적으로, 반사적으로 드러나는 태도들도 있습니다. 꼭 눈앞의 무엇인가를 위해서 갖춘 태도가 아니라 늘 본인의 기준 속에서 '옳다'라고 생각하기에 익혀온 것들이 말과 행동으로 전환되어 반응하는 순간들이 있기 때문이죠. 그리고 사실상 이런 태도들이야말로 그 사람에 대한 진짜 평가를 내리는데 굉장히 중요한 요인으로 작용하는 것일 수도 있습니다. 무의식적인 태도가 이 정도 수준이라면, 이 사람이 의식적으로 행동하기 시작했을 때는 얼마나 더 좋은 태도를 보일지 사뭇 기대가 되기 마련이니까요. 07 . 제가 봤을 때 태도의 반사 신경이 좋은 사람들 역시 비슷한 공통점을 가지고 있었습니다. 그 많은 것들 중 제가 가장 인상 깊게 본 특징은 본인에게 안 좋은 일이 일어났을 때의 반응이었는데요, 그 힘든 상황 속에서도 스스로의 감정에 매몰되어 누군가에게 그 기분을 일방적으로 전달하듯 말하는 게 아니라 늘 자신의 기준을 기반으로 적어도 한 번은 필터링을 거친 채로 생각을 표현한다는 것이었습니다. 배려라는 말로도 부족하고, 메타인지라는 단어로는 더 부족한 특유의 태도가 빛을 발하는 순간이죠. 08 . 예를 들어 '나에게 오늘 ~ 이런 이런 일이 있었는데, 여러 번 좋은 방향으로 생각해보려 해도 하루 종일 찜찜한 기분이 따라다니더라고. 내가 너무 민감한 걸까 아니면 상대가 무례했던 게 맞는 걸까?'라든지 '누군가 나에게 조언을 구해서 ~ 이렇게 이야기를 해줬는데, 가만히 생각하니 너무 내 입장에서 이야기를 전달했던 것 같아. 오해가 없도록 이따 다시 가서 더 잘 설명해 줘야 할 것 같아'처럼 자신에게 일어난 일을 여러 입장에서 고민해 본 후 나름 해결된 부분과 그렇지 않은 부분을 잘 정리하는 경우가 많았거든요. 심지어 가장 가까운 사람들에게 말할 때조차 자신의 부정적인 감정이 너무 날 것으로 전달될까 봐 늘 조심하는 태도를 발견할 때만 '아 나도 저런 태도는 꼭 배우고 익혀놓고 싶다'는 생각이 천 번이고 만 번이고 들게 되죠. 09 . 저는 이런 노력이 가능한 이유는 평소 본인이 가진 좋은 기준들이 반사 신경처럼 작용한 덕분이라고 생각합니다. 실제 운동역학에서는 반사 신경을 두고 이런 진단을 내리기도 합니다. '반사 신경이 뛰어나면 일반적인 움직임에서의 에너지 소모가 훨씬 효율적이다. 학습과 경험에 의해 자신만의 최적 동선이 갖춰진 결과 불필요한 에너지를 거의 사용하지 않기 때문이다'라고 말이죠.그런 의미에서 보자면 태도 역시 마찬가지겠죠. 평소에 태도의 반사 신경이 좋은 사람들은 사소한 부분들을 대함에 있어 굳이 꼬아서 듣거나, 이기적으로 생각하거나, 소모적으로 언쟁할 에너지를 사용하지 않는 겁니다. 대신 진짜 그 에너지를 써야 하는 상황이 오면 자신을 객관화시켜 가면서까지 좋은 방향으로 답을 찾으려는 노력을 하는 거죠. 어디다 에너지를 써야 하고 어디다 쓰지 않아야 하는지를 본능적으로 아는 셈입니다. 10 . 태도의 중요성은 아무리 강조해도 지나침이 없겠지만 의도적으로, 의식적으로 좋은 태도를 가지려는 노력만큼이나 정말 언제 어디서 어떤 일이 일어나더라도 즉각적으로 보여줄 수 있는 태도들을 잘 익혀놓는 것도 중요하다고 생각합니다. 개인적으로 '좋은 사람들은 남들로 하여금 오해를 불러일으키지 않는다'는 말을 참 좋아하는데요, 이 역시 그동안 우리에게 반사 신경처럼 보여준 좋은 태도들이 기반이 되어 혹시라도 그 사람을 평가해야 하는 순간이 왔을 때마저 아주 명쾌하고 정확하게 상대를 받아들일 수 있도록 해주는 것인지도 모릅니다. '좋은 태도를 갖춘 사람'이란 그 한 문장으로 말이죠. 그러니 본인 기분 좋을 때는 세상이 다 같이 기뻐해 줘야 하고, 본인에게 조금이라도 기분 나쁜 일이 있으면 세상이 같이 울어줘야 한다는 얌체 심보는 저 멀리 던져두고 이제 언제든 즉시, 빠르고 가볍게 보여줄 수 있는 좋은 태도들을 학습해 나가는 것은 어떨까요? 어차피 평생 가지고 살아야 할 것이 태도라면 필요할 때마다 새로 익혀서 보여주는 건 너무 힘들고 비효율적일 테니까요.

태도라는 '반사 신경'

Confronting direct reports about performance issues can feel overwhelming, especially for first-time managers, who may worry that sharing critical feedback could damage their relationship with the employee. But performance conversations, especially where you need to give critical feedback, don’t have to be scary. There are a few common mistakes to avoid when giving critical feedback. One of the biggest mistakes is avoiding the conversation or waiting too long to have it. Many new managers also fail to properly prepare before their performance discussions. If there are tasks, projects, or skills at which your employee is falling short, you should also be able to give them a clear explanation of why or where they haven’t met your expectations

5 Mistakes Managers Make When Giving Negative Feedback

연말연초에는 연간 평가를 진행하는 회사들이 많다. 그런데 직속 부하 직원의 성과 문제를 지적하는 것은 특히 관리자들에게 부담스럽게 느껴질 수 있다. 성과 대화는 결코 쉽지 않지만, 시간과 반복적인 경험을 통해 피드백을 전달하는 능력과 편안함이 향상될 것이다.

HBR이 알려주는 다음의 성과 대화에서 하지 말아야 할 것과 해야 할 것을 참고해보시길 바랍니다.

🏵️ 실수 1: 대화를 너무 오래 미루는 것
 * 성과 문제는 시간이 지나면서 저절로 해결되지 않기 때문에 올바르게 해결하려면 신중한 접근과 즉각적인 피드백이 필요하다.
✅ 가장 효과적인 방법은, 문제가 발생한 즉시 혹은 가능한 한 빠른 비판적 피드백 제공
 * 작은 문제들이 쌓여 눈덩이처럼 커지기 전에 미리 피드백을 주어야 한다. 공식적인 성과 평가 미팅을 기다릴 필요 없이, 즉시 해결하는 것이 중요하다.
✅ 효과적인 방법
✔ 직원에게 미리 논의할 내용을 알려주어 준비할 시간을 주는 것이 좋다.
예를 들어: "지난 프로젝트에서 마감 기한을 놓친 것을 확인했습니다. 이번 주 후반에 이
문제에 대해 논의하고, 앞으로 어떻게 하면 좋을지 함께 고민해 보고 싶습니다."
✔ 이렇게 하면 직원이 갑작스럽게 피드백을 받는 것에 대한 불안감을 줄이고, 사전에 준비할
수 있는 기회를 줄 수 있다.

🏵️ 실수 2: 충분한 준비 없이 대화에 임하는 것
 * 많은 신입 관리자들이 성과 대화를 하기 전에 충분히 준비하지 않는다. 하지만 준비 부족은 생산적인 대화를 방해할 수 있다.
✅ 비판적인 피드백을 줄 때는 철저한 준비 필수
 * 직원의 책임과 역할을 명확히 이해하고 있어야 한다.
 * 직원이 기대하는 성과 수준을 충족했는지 여부를 파악해야 한다.
 * 직원의 강점과 개선이 필요한 부분을 명확하게 알고 있어야 한다.
 * 기대한 성과를 충족하지 못한 이유를 구체적으로 설명할 수 있어야 한다.
✅ 대화 준비를 위한 체크리스트:
 * 이 직원이 이번 분기에 달성해야 할 목표는 무엇인가?
 * 내 기대치는 합리적이었으며, 명확하게 전달되었는가?
 * 이 직원의 업무가 팀 전체 목표에 어떻게 기여하는가?
 * 성과가 부족하다고 판단하는 근거(증거)는 무엇인가?
 * 실패한 사례를 구체적으로 설명할 수 있는가?
 * 이 직원이 다시 궤도에 오를 수 있도록 어떤 조언을 줄 수 있는가?
✅ 피해야 할 표현 vs. 더 나은 표현:
❌ "당신은 프로젝트 X에서 최선을 다하지 않았어요. 실망스럽습니다."
👍 "프로젝트 X의 트렌드 분석이 좀 더 철저했더라면, 우리가 시장에서 경쟁력을 갖출 수 있었을
것입니다. 나는 당신이 더 잘할 수 있다고 생각하기 때문에, 이번 보고서 결과가 다소
아쉽습니다."

🏵️ 실수 3: 적절한 질문을 하지 않는 것
✅ 성과 대화는 일방적인 피드백 전달이 아니라 양방향 소통
 * 직원의 성과 저하 원인을 파악하려면 올바른 질문을 던지는 것이 중요하다.
 * 직원의 관점을 이해해야 적절한 해결책을 제시할 수 있다. 신뢰를 쌓는 데 시간이 걸릴 수도 있으므로, 여러 번의 대화를 통해 점진적으로 해결하는 것이 중요하다.
✅ 잘못된 접근 vs 더 나은 접근
❌ "요즘 일에 집중을 못 하는 것 같아요."
👍 더 나은 접근:
✔ "요즘 업무에 대해 어떻게 느끼세요?"
✔ "현재 역할에서 어려움을 느끼는 부분이 있나요?"
✅ 직원의 성과 저하 원인 분석
 * 개인적인 문제 (건강 문제, 가족 문제 등)
 * 필요한 기술 부족 (경험이나 역량 부족)
 * 명확한 방향성 부재 (기대치가 명확하지 않음)
 * 동기 부족 (업무 만족도가 낮거나 관심 부족)

🏵️ 실수 4: 문제를 '사람'의 문제로 만드는 것
✅ 관리자는 직원을 도와주는 조력자(facilitator) 역할
 * 직원이 성과를 개선할 수 있도록 솔루션을 함께 고민하는 태도가 중요하다.
✅ 잘못된 접근 vs 더 나은 접근
❌ "당신은 내 기대치를 충족하지 못하고 있어요."
❌ "당신이 이 일을 망쳐서 프로젝트가 지연될 겁니다."
👍 더 나은 접근:
✔ "이 프로젝트를 성공적으로 마치려면 당신의 기술이 매우 중요합니다. 하지만 현재 마감
기한을 맞추는 데 어려움을 겪고 있는 것 같습니다. 어떤 점이 가장 큰 도전인가요?"

🏵️ 실수 5: 개선 계획을 마련하지 않는 것
 * 비판적인 피드백은 단순한 지적이 아니라 성장 기회를 제공하는 것이어야 한다.
✅ 대화 후 반드시 개선 로드맵 수립
 * 우려 사항과 개선 목표를 문서화
 * 직원과 협의하여 기대치를 명확히 설정
 * 진행 상황을 점검할 수 있는 마일스톤 및 체크인 일정 설정
✅ 효과적인 계획 예시
✔ "향후 한 달 동안 이 목표를 달성하기 위해 어떤 전략을 세울까요?"
✔ "이번 프로젝트에서 부족했던 부분을 보완할 수 있는 기회를 찾아볼까요?"

 * source: https://hbr.org/2025/01/5-mistakes-managers-make-when-giving-negative-feedback?ab=HP-hero-for-you-text-2

연말연초에는 연간 평가를 진행하는 회사들이 많다. 그런데 직속 부하 직원의 성과 문제를 지적하는 것은 특히 관리자들에게 부담스럽게 느껴질 수 있다. 성과 대화는 결코 쉽지 않지만, 시간과 반복적인 경험을 통해 피드백을 전달하는 능력과 편안함이 향상될 것이다. HBR이 알려주는 다음의 성과 대화에서 하지 말아야 할 것과 해야 할 것을 참고해보시길 바랍니다. 🏵️ 실수 1: 대화를 너무 오래 미루는 것<ul ><li>성과 문제는 시간이 지나면서 저절로 해결되지 않기 때문에 올바르게 해결하려면 신중한 접근과 즉각적인 피드백이 필요하다. </li></ul>✅ 가장 효과적인 방법은, 문제가 발생한 즉시 혹은 가능한 한 빠른 비판적 피드백 제공<ul ><li>작은 문제들이 쌓여 눈덩이처럼 커지기 전에 미리 피드백을 주어야 한다. 공식적인 성과 평가 미팅을 기다릴 필요 없이, 즉시 해결하는 것이 중요하다.</li></ul>✅ 효과적인 방법 ✔ 직원에게 미리 논의할 내용을 알려주어 준비할 시간을 주는 것이 좋다. 예를 들어: "지난 프로젝트에서 마감 기한을 놓친 것을 확인했습니다. 이번 주 후반에 이 문제에 대해 논의하고, 앞으로 어떻게 하면 좋을지 함께 고민해 보고 싶습니다." ✔ 이렇게 하면 직원이 갑작스럽게 피드백을 받는 것에 대한 불안감을 줄이고, 사전에 준비할 수 있는 기회를 줄 수 있다. 🏵️ 실수 2: 충분한 준비 없이 대화에 임하는 것<ul ><li>많은 신입 관리자들이 성과 대화를 하기 전에 충분히 준비하지 않는다. 하지만 준비 부족은 생산적인 대화를 방해할 수 있다. </li></ul>✅ 비판적인 피드백을 줄 때는 철저한 준비 필수<ul ><li>직원의 책임과 역할을 명확히 이해하고 있어야 한다.</li><li>직원이 기대하는 성과 수준을 충족했는지 여부를 파악해야 한다.</li><li>직원의 강점과 개선이 필요한 부분을 명확하게 알고 있어야 한다.</li><li>기대한 성과를 충족하지 못한 이유를 구체적으로 설명할 수 있어야 한다.</li></ul>✅ 대화 준비를 위한 체크리스트:<ul ><li>이 직원이 이번 분기에 달성해야 할 목표는 무엇인가?</li><li>내 기대치는 합리적이었으며, 명확하게 전달되었는가?</li><li>이 직원의 업무가 팀 전체 목표에 어떻게 기여하는가?</li><li>성과가 부족하다고 판단하는 근거(증거)는 무엇인가?</li><li>실패한 사례를 구체적으로 설명할 수 있는가?</li><li>이 직원이 다시 궤도에 오를 수 있도록 어떤 조언을 줄 수 있는가?</li></ul>✅ 피해야 할 표현 vs. 더 나은 표현: ❌ "당신은 프로젝트 X에서 최선을 다하지 않았어요. 실망스럽습니다." 👍 "프로젝트 X의 트렌드 분석이 좀 더 철저했더라면, 우리가 시장에서 경쟁력을 갖출 수 있었을 것입니다. 나는 당신이 더 잘할 수 있다고 생각하기 때문에, 이번 보고서 결과가 다소 아쉽습니다." 🏵️ 실수 3: 적절한 질문을 하지 않는 것✅ 성과 대화는 일방적인 피드백 전달이 아니라 양방향 소통<ul ><li> 직원의 성과 저하 원인을 파악하려면 올바른 질문을 던지는 것이 중요하다.</li><li> 직원의 관점을 이해해야 적절한 해결책을 제시할 수 있다. 신뢰를 쌓는 데 시간이 걸릴 수도 있으므로, 여러 번의 대화를 통해 점진적으로 해결하는 것이 중요하다.</li></ul>✅ 잘못된 접근 vs 더 나은 접근 ❌ "요즘 일에 집중을 못 하는 것 같아요." 👍 더 나은 접근: ✔ "요즘 업무에 대해 어떻게 느끼세요?" ✔ "현재 역할에서 어려움을 느끼는 부분이 있나요?"✅ 직원의 성과 저하 원인 분석<ul ><li>개인적인 문제 (건강 문제, 가족 문제 등)</li><li>필요한 기술 부족 (경험이나 역량 부족)</li><li>명확한 방향성 부재 (기대치가 명확하지 않음)</li><li>동기 부족 (업무 만족도가 낮거나 관심 부족)</li></ul> 🏵️ 실수 4: 문제를 '사람'의 문제로 만드는 것✅ 관리자는 직원을 도와주는 조력자(facilitator) 역할<ul ><li> 직원이 성과를 개선할 수 있도록 솔루션을 함께 고민하는 태도가 중요하다.</li></ul>✅ 잘못된 접근 vs 더 나은 접근 ❌ "당신은 내 기대치를 충족하지 못하고 있어요." ❌ "당신이 이 일을 망쳐서 프로젝트가 지연될 겁니다." 👍 더 나은 접근: ✔ "이 프로젝트를 성공적으로 마치려면 당신의 기술이 매우 중요합니다. 하지만 현재 마감 기한을 맞추는 데 어려움을 겪고 있는 것 같습니다. 어떤 점이 가장 큰 도전인가요?" 🏵️ 실수 5: 개선 계획을 마련하지 않는 것<ul ><li>비판적인 피드백은 단순한 지적이 아니라 성장 기회를 제공하는 것이어야 한다.</li></ul>✅ 대화 후 반드시 개선 로드맵 수립<ul ><li>우려 사항과 개선 목표를 문서화</li><li>직원과 협의하여 기대치를 명확히 설정</li><li>진행 상황을 점검할 수 있는 마일스톤 및 체크인 일정 설정</li></ul>✅ 효과적인 계획 예시 ✔ "향후 한 달 동안 이 목표를 달성하기 위해 어떤 전략을 세울까요?" ✔ "이번 프로젝트에서 부족했던 부분을 보완할 수 있는 기회를 찾아볼까요?" <ul ><li>source: https://hbr.org/2025/01/5-mistakes-managers-make-when-giving-negative-feedback?ab=HP-hero-for-you-text-2</li></ul>

Harvard Business Review

[HBR] 관리자가 부정적인 피드백을 줄 때 저지르는 5가지 실수

사용자는 400ms(0.4초) 이내 응답이 오면
‘즉각적’이라고 느껴 사용자 경험에 더 집중하고
적극적으로 클릭/탭을 이어갈 수 있습니다.

⌚️0.4초가 넘어가면, 로딩 피드백(스피너, 진행 바, 스켈레톤 화면 등)을 제공하는게 좋습니다. 작은 딜레이에도 적절한 피드백만 있다면, 사용자의 불안감과 이탈을 크게 줄일 수 있기 때문인데요,

- 구글·네이버 검색창에서 글자 하나만 쳐도 제안어가 뜨는 이유!
- 대형 이커머스 사이트(쿠팡, 11번가 등)에서 스크롤 시 다음 이미지가 빠르게 채워지는 구조

이 간단한 원칙이 UX 성패를 가를 수 있습니다.

사용자는 400ms(0.4초) 이내 응답이 오면‘즉각적’이라고 느껴 사용자 경험에 더 집중하고적극적으로 클릭/탭을 이어갈 수 있습니다. ⌚️0.4초가 넘어가면, 로딩 피드백(스피너, 진행 바, 스켈레톤 화면 등)을 제공하는게 좋습니다. 작은 딜레이에도 적절한 피드백만 있다면, 사용자의 불안감과 이탈을 크게 줄일 수 있기 때문인데요, - 구글·네이버 검색창에서 글자 하나만 쳐도 제안어가 뜨는 이유!- 대형 이커머스 사이트(쿠팡, 11번가 등)에서 스크롤 시 다음 이미지가 빠르게 채워지는 구조 이 간단한 원칙이 UX 성패를 가를 수 있습니다.

UX/UI 에서 0.4초는 마법의 숫자? 도허티 임계 이야기🪄

Accompanying lecture notes: https://www.cl.cam.ac.uk/teaching/2122/ConcDisSys/dist-sys-notes.pdf These videos form an 8-lecture series on distributed systems...

Distributed Systems lecture series

분산 시스템(distributed systems) 공부할 때 배워야하는 중요한 개념과 유튜브 영상 추천합니다. 지난번 소개한 책에서 상당히 세세하게 다루는 주제들이지만 책으로 먼저 접하기에는 조금 거리감이 있을 수 있습니다. 유튜브 영상으로 가볍게 시청하면서 개념 이해하는 것을 추천합니다.

📌 개념 이해 전에 알아야 할 분산 시스템이 필요한 이유
https://youtu.be/UEAMfLPZZhE

분산 시스템으로 만들어야 하는/만들지 말아야 하는 가장 기본 개념을 설명해주는 영상입니다.

📌 아래는 제가 뽑은 몇 가지 중요한 기본 개념과 추천하는 영상입니다. 아래 개념은 시스템 디자인 면접에서 많이 언급될 수 있습니다. 특히 1번, 3번, 5번 그리고 6번은 라지 스케일 시스템을 디자인할 때 자주 언급되는 개념입니다.

1️⃣ Replication
https://youtu.be/mBUCF1WGI_I

레플리케이션의 의미와 개념을 먼저 알려주고, 문제점과 장점을 예시를 통해 알려줘서 쉽게 이해할 수 있습니다. 기본 개념과 문제점을 이해하고, 가장 중요한 솔루션을 몇 가지 간단하게 배울 수 있습니다. 라지 스케일 디자인할 때 중요한 점이라 꼭 숙지하고, 시스템 디자인할 때 또는 면접 볼 때 큰 도움이 될 수 있는 주제인 것 같습니다.

2️⃣ Quorum
https://youtu.be/uNxl3BFcKSA

Quorum 아키텍쳐는 분산 시스템에서 자주 언급되는 개념입니다. 이 영상에서 분산 시스템에서 중요한 토픽인  "consistency" (특히 read-after-write consistency) 에 대해 조금 더 깊이 설명해 줍니다. 

3️⃣ Consensus
https://youtu.be/rN6ma561tak

4️⃣ Linearizability
https://youtu.be/noUNH3jDLC0

분산 시스템에서 의미하는 "linearizability"가 뭔지 예시를 보면서 배울 수 있습니다. 분산 시스템을 linearizable하게 만들 수 있는 방법도 설명해 줍니다.

5️⃣ Eventual Consistency
https://youtu.be/9uCP3qHNbWw

데이터 베이스 관련 이야기할 때 자주 논의되는 Cap Theorum을 설명합니다. 그리고 레플리케이션에서 주로 언급되는 "eventual consistency" 개념을 예시와 함께 자세하게 설명해줍니다. 이 개념은 꼭 먼저 알려드린 "linearizability"를 이해하고 시청하면 훨씬 더 쉽게 이해할 수 있습니다.

6️⃣  Fault tolerance
https://youtu.be/43TDfUNsM3E

"Fault tolerance"는 경우에 따라 다르겠지만 분산 시스템 디자인할 때 가장 많은 시간을 할애하는 것 같습니다. "high availability" 분산 시스템을 설계하는 방법에 대해 간단하게 설명해줍니다. 다른 건 몰라도 영상에서 언급하는 "crash recovery"에 대해 잘 이해해두면 좋을 것 같습니다.

📌 추가적으로 입문 단계에서 봐야할 영상
1️⃣ The Byzantine generals problem
https://youtu.be/LoGx_ldRBU0

2️⃣ Broadcasting Algorithm
https://youtu.be/77qpCahU3fo 

그 외 분산 시스템에서 자주 언급되는 다른 토픽 모두 커버하면 좋지만, 입문 단계라면 위 개념 먼저 이해하는 것이 좋을 것 같습니다. 

📌 학습 효과 극대화 하기
가장 좋은 방법은 distributed system 엔지니어가 되어 실무를 통해 배운 개념들을 보고 익히는 것입니다. 

그렇지 않을 경우,
1️⃣ 영상에 남겨진 코멘트를 읽어보면서 보면서 개념 다지기 (특히 토론 코멘트)

개인적인 학습 방법일 수도 있지만, 토론을 통해 익힌 개념은 절대 잊히지 않는 장점이 있는 것 같습니다. 코멘트를 읽으면 댓글 스레드에서 토론하는 시청자들이 종종 보이는데, 영상 시청 후 이와 같은 코멘트를 함께 읽어보는 것이 좋습니다.

2️⃣ 영상 시청 후 지난번 추천한 책을 읽으면서 좀 더 깊게 파고들기

영상 플레이리스트를 보면 주제를 한눈에 볼 수 있는데, 지난번 소개한 책에서 커버하는 주제와 거의 90% 겹칩니다. 책과 영상을 모두 봤지만, 개인적으로 책을 읽으면 영상보다 좀 더 깊이 설명해주는 부분이 있고, 실제 책을 출판하기 위해 작가가 읽었던 리서치 페이퍼의 레퍼런스가 포함되어 있습니다. 읽다가 좀 더 설명이 필요한 부분은 레퍼런스를 읽고 더 깊이 파고들 수 있는 장점이 있습니다.

3️⃣ 분산 시스템 디자인 면접 영상을 보면서 분산 시스템 개념 대입해보기

가장 중요한 건 개념을 실무에 대입해보는 것입니다. 저의 경우 실무가 책에서 언급된 개념과 일치하기 때문에 큰 도움이 되었던 것 같습니다. 실무를 통해 먼저 배우고 위 영상을 보니, 확실히 개념 이해에 큰 도움이 되었습니다. 실무에서 자주 볼 수 없는 개념이라면, 유튜브에 있는 분산 시스템 디자인 모의 면접 영상을 보면서 개념 대입을 직접 해보는 것이 좋습니다.

4️⃣ 분산 시스템 모의 면접을 통해 개념 모의로 사용해보기

마지막은 직접 해보는 것이 아닐까요? 업무 보면서 개념을 모의로 사용해보는 것이 가장 좋지만, 그렇지 않을 경우 (특히 시스템 디자인 면접 준비할 때), 모의 면접을 통해 직접 사용해보는 것도 큰 도움됩니다.

🪴 함께 읽으면 좋은 글:
[개발자가 꼭 봐야 할 책 - 데이터 중심 애플리케이션 설계]
https://careerly.co.kr/comments/67004

[자기 개발에 도움되는 개발 도서 효율적으로 읽는 법]
https://careerly.co.kr/comments/67007

[개발자의 공부법 - 뭘 공부해야 되지?]
https://careerly.co.kr/comments/67013

www.youtube.com

[분산 시스템 공부법] 유튜브 채널 추천, 학습 효과 극대화 하기

English Summary > English Full Text [ 요약 ] 자주 사용하는 두 가지 소프트웨어인 ChatGPT와 Blender를 통합하는 방법에 대해 설명합니다. Blender 아티스트가 일반적으로 사용하지 않는 Blender의 스크립팅 탭에 중점을 둡니다. 스크립팅 탭을 사용하면 워크플로를 자동화하거나 씬 또는 모델에서 미세 조정 옵션을 제공하는 데 사용할 수 있는 커스텀 Python 스크립트를 가져오거나 작성할 수 있습니다.

완전 자동 블렌더 스크립트를 생성하는 Chat GPT를 사용했습니다! :: ChatGPT 정리

자주 사용하는 두 가지 소프트웨어인 ChatGPT와 Blender를 통합하는 방법에 대해 설명합니다.
Blender 아티스트가 일반적으로 사용하지 않는 Blender의 스크립팅 탭에 중점을 둡니다.
스크립팅 탭을 사용하면 워크플로를 자동화하거나 씬 또는 모델에서 미세 조정 옵션을 제공하는 데 사용할 수 있는 커스텀 Python 스크립트를 가져오거나 작성할 수 있습니다.

이 문서에서는 유효한 스크립트를 제공하는 검증된 프롬프트의 예시를 제공하며 작성자는 그 자리에서 몇 가지 아이디어를 즉석에서 구현했습니다.
원하는 출력은 간단한 구체 고리이며, 저자는 프롬프트를 사용하여 짧은 스크립트를 실행합니다.
여러분이 스크립팅 탭을 사용하여 Blender에서 사용자 지정 스크립트를 실험해 보도록 합니다.

반업주부의 일상 배움사

없음 없음

지우

완전 자동 블렌더 스크립트를 생성하는 Chat GPT를 사용했습니다!

MySQL

python

typescript

Node.js

PostgreSQL

NCSoft
콩스튜디오-미큐트
블록체인
AI 서비스
디스코드 봇
AWS, GCP, Node.js, PHP, Go, Python
<- Java, Objective-C, Lua 
<- JS, ActionScript 
<- 웹디자인

요약가

플랫폼

콘텐츠

블록체인

방송 / 엔터테인먼트

Google Cloud Platform

Android

- 모든 클라우드 인프라 구축 및 관리
- K-Pop Starpic 모바일 앱 및 서버 개발
- Pixel Colorfil 모바일 앱 및 서버 개발
- Colorfil 서버 개발
- 디스코드 봇 개발
- 블록체인 프로젝트
- CI/CD, 정적 코드 분석(SonarQube)

시니어 백엔드 엔지니어

생산가공공학

원강민

블로그

AWS, GCP, Node.js, PHP, Go, Python<- Java, Objective-C, Lua <- JS, ActionScript <- 웹디자인
NCSoft, 콩스튜디오-미큐트
블록체인, AI, 디스코드 봇
banjubu.tistory.com

완전 자동 블렌더 스크립트를 생성하는 Chat GPT를 사용했습니다!

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필