들어가며 안녕하세요. LINE+ Contents Service Engineering 조직에서 백엔드 개발을 맡고 있는 양강현, 이병찬입니다. 저희가 속해 있는 Contents Se...

Req-Saver로 캐시의 골칫거리 'Thundering Herd 문제' 쉽게 풀기!

라인에서 Cache를 사용할 때 발생하는 Thundering Herd 문제를 어떻게 해결했는지를 설명한 글입니다.

저도 이번에 이러한 현상을 Thundering Herd라고 부르는지 처음 알게 되었는데 보통 캐시를 쓰게 되면 디비에서 데이터를 가져와서 Redis 같은 캐시에 넣어두고 이후에는 캐시해서 조회해서 빠른 응답을 주게 됩니다. 하지만 캐시의 데이터를 계속 쓸수는 없고 캐시도 데이터가 많아지면 오래된 데이터는 사라지기 때문에 캐시에 데이터가 없거나 하면 디비에 가서 데이터를 가져와서 다시 캐시에 채워주게 됩니다.

이러한 경우 서버가 1대라면 문제가 안되지만 서버가 많고 당연히 사용자 요청도 동시에 많이 이뤄지기 때문에 캐시가 TTL로 없어지거나 하면 수많은 요청이 동시에 캐시에 데이터가 없어서 디비에 가서 디비에서 연결이 몰리고 이 데이터를 다시 캐시에 채워넣으려고 여러번 저장이 이뤄지게 되는데 이 문제를 Thundering Herd 문제라고 합니다.

이 문제를 Req-Saver라는 라이브러리를 만들어서 여러 요청이 들어왔을 때 하나의 요청만 디비에 갔다와서 데이터를 채워넣고 다른 요청은 캐시에 채워진 데이터로 응답하도록 지연시키는 구현을 했고 이를 스프링에 적용해서 성능 비교를 한 결과 평균 51%의 성능이 향상되었다고 합니다.

서비스에 따라 다르긴 하지만 부하가 심한 경우 캐시 만료에 따라 디비나 캐시에 부하가 몰릴 수 있는데 꽤 괜찮은 방법으로 보입니다.

https://techblog.lycorp.co.jp/ko/req-saver-for-thundering-herd-problem-in-cache

라인에서 Cache를 사용할 때 발생하는 Thundering Herd 문제를 어떻게 해결했는지를 설명한 글입니다. 저도 이번에 이러한 현상을 Thundering Herd라고 부르는지 처음 알게 되었는데 보통 캐시를 쓰게 되면 디비에서 데이터를 가져와서 Redis 같은 캐시에 넣어두고 이후에는 캐시해서 조회해서 빠른 응답을 주게 됩니다. 하지만 캐시의 데이터를 계속 쓸수는 없고 캐시도 데이터가 많아지면 오래된 데이터는 사라지기 때문에 캐시에 데이터가 없거나 하면 디비에 가서 데이터를 가져와서 다시 캐시에 채워주게 됩니다. 이러한 경우 서버가 1대라면 문제가 안되지만 서버가 많고 당연히 사용자 요청도 동시에 많이 이뤄지기 때문에 캐시가 TTL로 없어지거나 하면 수많은 요청이 동시에 캐시에 데이터가 없어서 디비에 가서 디비에서 연결이 몰리고 이 데이터를 다시 캐시에 채워넣으려고 여러번 저장이 이뤄지게 되는데 이 문제를 Thundering Herd 문제라고 합니다. 이 문제를 Req-Saver라는 라이브러리를 만들어서 여러 요청이 들어왔을 때 하나의 요청만 디비에 갔다와서 데이터를 채워넣고 다른 요청은 캐시에 채워진 데이터로 응답하도록 지연시키는 구현을 했고 이를 스프링에 적용해서 성능 비교를 한 결과 평균 51%의 성능이 향상되었다고 합니다. 서비스에 따라 다르긴 하지만 부하가 심한 경우 캐시 만료에 따라 디비나 캐시에 부하가 몰릴 수 있는데 꽤 괜찮은 방법으로 보입니다. https://techblog.lycorp.co.jp/ko/req-saver-for-thundering-herd-problem-in-cache

LY Corporation Tech Blog

Smudge.ai is a Chrome extension that gives you ChatGPT-powered shortcuts in your right-click menu.

rate limiter - smudge.ai blog

특정 사용자가 서비스의 리소스를 모두 차지하지 않도록 Rate Limit을 보통 사용하는데 이를 구현하는 알고리즘을 설명한 글입니다. 각 알고리즘을 애니메이션으로 비교해서 보여주기 때문이 이해하기 좋은 글입니다.

Fixed WIndow는 가장 간단하면서도 사용자가 예측하기 쉽지만 Windows가 시작 도리때 요청이 몰리거나 Window의 시간이 길다면 타임존의 영향을 받아서 Rate Limit이 의도와 다르게 동작할 수 있습니다.

Sliding Windows 방식은 동시에 받을 수 있는 요청수를 제한하기 때문에 요청을 원활하게 분산할 수 있지만 대신 적용하는데 리소스가 많이 필요합니다.

Token Bucket 방식은 버킷에 토큰이 있어야만 요청을 보낼 수 있는 방식으로 토큰은 일정 시간 간격으로 버킷에 채워지는 형태입니다. 유연한 방식이지만 사용자가 자신의 토큰이 어느정도 있는지 예측하기가 쉽지 않은 문제가 있습니다.

https://smudge.ai/blog/ratelimit-algorithms

특정 사용자가 서비스의 리소스를 모두 차지하지 않도록 Rate Limit을 보통 사용하는데 이를 구현하는 알고리즘을 설명한 글입니다. 각 알고리즘을 애니메이션으로 비교해서 보여주기 때문이 이해하기 좋은 글입니다. Fixed WIndow는 가장 간단하면서도 사용자가 예측하기 쉽지만 Windows가 시작 도리때 요청이 몰리거나 Window의 시간이 길다면 타임존의 영향을 받아서 Rate Limit이 의도와 다르게 동작할 수 있습니다. Sliding Windows 방식은 동시에 받을 수 있는 요청수를 제한하기 때문에 요청을 원활하게 분산할 수 있지만 대신 적용하는데 리소스가 많이 필요합니다. Token Bucket 방식은 버킷에 토큰이 있어야만 요청을 보낼 수 있는 방식으로 토큰은 일정 시간 간격으로 버킷에 채워지는 형태입니다. 유연한 방식이지만 사용자가 자신의 토큰이 어느정도 있는지 예측하기가 쉽지 않은 문제가 있습니다. https://smudge.ai/blog/ratelimit-algorithms

Smudge

DevToys is a cross-platform Swiss Army knife for developers. DevToys helps in daily tasks like formatting JSON, comparing text, testing RegExp. No need to use many untruthful websites to do simple tasks with your data.

DevToys - A Swiss Army knife for developers

devtoys는 base64 인코딩 디코딩, uuid 생성, html 인코더 디코더, json <-> yaml 변환, 마크다운 프리뷰 등 다양한 기능을 지원하는데요!

전 개발하다가 가끔 구글에서 json2table web.. 이런 식으로 찾아서 볼 때도 있는데..
이 앱 한개로 다 해결돼요!

(무료라서 무조건 좋군요..ㅋㅋㅋㅋ)

https://devtoys.app/

devtoys는 base64 인코딩 디코딩, uuid 생성, html 인코더 디코더, json &lt;-&gt; yaml 변환, 마크다운 프리뷰 등 다양한 기능을 지원하는데요! 전 개발하다가 가끔 구글에서 json2table web.. 이런 식으로 찾아서 볼 때도 있는데.. 이 앱 한개로 다 해결돼요! (무료라서 무조건 좋군요..ㅋㅋㅋㅋ) https://devtoys.app/

Devtoys

개발자라면 이걸 깔아보는 거 어때요?

너무좋네요 ㅎㅎㅎ 감사합니다!!

The world of Copilot is getting bigger, improving the developer experience by keeping developers in the flow longer and allowing them to do more in natural language.

Introducing GitHub Copilot Extensions: Unlocking unlimited possibilities with our ecosystem of partners

GitHub에서 Copilot Extension을 발표했습니다.

이를 이용하면 Copilot에 서드파티를 연동할 수 있기 때문에 VS Code에서 Copilot Chat을 이용해서 단순히 코드에 대한 대화만 하는 것이 아니라 사용 중인 서드파티에 대한 정보도 얻을 수 있습니다.

오픈시 연동되 서드파티 서비스를 보면 LaunchDarkly, MongoDB, Docker, Sentry, Octopus Deploy 등이 있는데 각 회사에서 익스텐션을 만들어서 연동하는 방식이고 사용자는 코드를 푸시한 후 현재 실행되고 있는 배포의 상황을 물어보거나 사용중인 데이터베이스나 서비스의 오류 등을 Copilot을 통해서 확인할 수 있기 때문에 상당히 유용할 것으로 생각하고 있습니다.

LLM에서 아쉬운 부분이 할루시네이션에 대한 정확도도 있지만 작업 환경에 대한 컨텍스트가 부족한 부분이었는데 이런 부분을 상당히 해소해 줄 수 있지 않을가 기대하고 있습니다.

https://github.blog/2024-05-21-introducing-github-copilot-extensions/

GitHub에서 Copilot Extension을 발표했습니다. 이를 이용하면 Copilot에 서드파티를 연동할 수 있기 때문에 VS Code에서 Copilot Chat을 이용해서 단순히 코드에 대한 대화만 하는 것이 아니라 사용 중인 서드파티에 대한 정보도 얻을 수 있습니다. 오픈시 연동되 서드파티 서비스를 보면 LaunchDarkly, MongoDB, Docker, Sentry, Octopus Deploy 등이 있는데 각 회사에서 익스텐션을 만들어서 연동하는 방식이고 사용자는 코드를 푸시한 후 현재 실행되고 있는 배포의 상황을 물어보거나 사용중인 데이터베이스나 서비스의 오류 등을 Copilot을 통해서 확인할 수 있기 때문에 상당히 유용할 것으로 생각하고 있습니다. LLM에서 아쉬운 부분이 할루시네이션에 대한 정확도도 있지만 작업 환경에 대한 컨텍스트가 부족한 부분이었는데 이런 부분을 상당히 해소해 줄 수 있지 않을가 기대하고 있습니다. https://github.blog/2024-05-21-introducing-github-copilot-extensions/

The GitHub Blog

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께

그 누구도 나의 서사를 대신 써주지 않는다

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께

코노님이 작성한 글입니다. 지금처럼 경력자를 후려치는 마케팅이 성행하는 시기에 살펴볼만한 대목이 많네요!

 * 물경력과 성장: 글에서는 '물경력 탈출’과 같은 마케팅이 저연차 개발자들의 불안을 자극하는 것에 대해 비판하며, 진정한 성장의 의미를 탐구합니다.
 * 개인적 경험의 가치: 다양한 경험들이 개발자로서의 성장에 어떻게 기여하는지를 공유하며, 링크드인에 적을 수 없는 경험들도 중요하다고 강조합니다.
 * 자기 인정의 중요성: 필자는 타인의 인정을 넘어 자기 스스로를 인정하는 것이 진정한 성장으로 이어진다고 주장합니다.
 * 본인의 서사 쓰기: 자신의 경험을 소중히 여기고, 타인의 시선에 휘둘리지 않으며, 자신만의 서사를 써나가야 한다고 강조합니다.

https://codingpause.hashnode.dev/about-growing-up

'성장'과 '물경력' 사이에서 혼란스러워하는 분들께 코노님이 작성한 글입니다. 지금처럼 경력자를 후려치는 마케팅이 성행하는 시기에 살펴볼만한 대목이 많네요! <ul ><li>물경력과 성장: 글에서는 '물경력 탈출’과 같은 마케팅이 저연차 개발자들의 불안을 자극하는 것에 대해 비판하며, 진정한 성장의 의미를 탐구합니다.</li><li>개인적 경험의 가치: 다양한 경험들이 개발자로서의 성장에 어떻게 기여하는지를 공유하며, 링크드인에 적을 수 없는 경험들도 중요하다고 강조합니다.</li><li>자기 인정의 중요성: 필자는 타인의 인정을 넘어 자기 스스로를 인정하는 것이 진정한 성장으로 이어진다고 주장합니다.</li><li>본인의 서사 쓰기: 자신의 경험을 소중히 여기고, 타인의 시선에 휘둘리지 않으며, 자신만의 서사를 써나가야 한다고 강조합니다.</li></ul> https://codingpause.hashnode.dev/about-growing-up

코딩 놓으려 했는데

1️⃣ The C Programming Language

컴퓨터 프로그래밍의 근본 (주니어)

2️⃣ Code Complete

소프트웨어 개발의 모든 것 (주니어, 미드)

3️⃣ Refactoring

소프트웨어 유지보수의 모든 것 (주니어, 미드)

4️⃣ 구글 엔지니어는 이렇게 일한다

소프트웨어 개발 협업에 대한 모든 것 (미드, 시니어)

5️⃣ 최고의 프롬프트 엔지니어링 강의

AI/LLM과 프롬프트 엔지니어링의 근본(주니어, 미드, 시니어)

이상한 것이 끼어있는 것 같지만 착각입니다.

1️⃣ The C Programming Language 컴퓨터 프로그래밍의 근본 (주니어) 2️⃣ Code Complete 소프트웨어 개발의 모든 것 (주니어, 미드) 3️⃣ Refactoring 소프트웨어 유지보수의 모든 것 (주니어, 미드) 4️⃣ 구글 엔지니어는 이렇게 일한다 소프트웨어 개발 협업에 대한 모든 것 (미드, 시니어) 5️⃣ 최고의 프롬프트 엔지니어링 강의 AI/LLM과 프롬프트 엔지니어링의 근본(주니어, 미드, 시니어) 이상한 것이 끼어있는 것 같지만 착각입니다.

모든 개발자를 위한 프로그래밍 책 Top 5

추천해주신 도서가 다 좋아보입니다! 5번은 이미 읽고 있는 거네요! 
🤣

 1. Materialized Views:
 * 정의:
   * Materialized View(MV)는 쿼리 결과를 저장하고 있는 데이터베이스 객체입니다. 이렇게만 말하면 SQL 데이터베이스에만 국한된 개념처럼 보이지만 좀 더 넓은 개념의 의미로 보면 Materialized View는 데이터의 사본을 미리 계산하고 저장하여 성능을 향상시키는 기법입니다.
 * When to use:
   * 복잡한 쿼리: 여러 조인, 집계 및 계산을 포함하는 복잡한 쿼리라서 데이터를 직접 쿼리하기 어려울 때
   * 반복적인 읽기 작업: 자주 읽히는 데이터의 경우 Materialized View 기법을 통해서 읽기 성능을 향상 시킬 수 있습니다.
   * 데이터 집계: 집계 연산 (Aggregation, 합계, 평균, 개수 등) 에서 Materialized Views 를 통해 사전 집계된 결과를 제공해서 성능을 향상 시킬 수 있습니다.
   * 서로 다른 데이터 저장소의 기능을 활용하기 위해서. 예를 들면 쓰기에 효율적인 데이터 스토어는 데이터를 저장소 역할로 사용하고, 쿼리와 읽기 성능이 좋은 관계형 데이터 스토어에서 Materialized View 를 저장하는 식으로.
 * How to use:
   * SQL 에서의 Materialized View 는 Materialized View 객체를 생성하고, 갱신 전략과 그것에 맞는 갱신 주기를 설정하고 조회하면 됩니다.
   * 추가로 너무 자주 갱신할 경우 성능에 부담이 되고, 너무 늦게 갱신하면 오래된 데이터를 볼 수 있는 문제가 발생할 수 있습니다.
 * Considerations:
   * 갱신 오버헤드: 갱신 시 리소스가 소요되는 걸 고려해서 갱신 전략과 갱신 주기를 설정하세요.
   * Dsposability and Regeneratibility: Materialized View 가 없어지거나 만료되더라도 원본 데이터에서 다시 만들 수 있어야 합니다.
   * Consistency: Materialized View 는 원본 데이터로 만들어진 별도의 캐싱 데이터 이므로 데이터 일관성이 안 맞을 수 있습니다. 이것에 대한 고려도 필요합니다.
   * 원본 데이터가 단순하거나 쿼리하기 쉽다면 이 기법은 적절하지 않을 수 있습니다.

 2. Indexing:
 * 정의:
   * 데이터베이스의 특정 열에 대해 검색 속도를 향상시키기 위해 데이터 구조를 사용하는 전략입니다.
 * When to use:
   * 빈번한 검색: 자주 검색되는 열에 대해 인덱스를 생성하면 검색 성능을 크게 향상시킬 수 있습니다.
   * JOIN 및 WHERE 절: JOIN이나 WHERE 절에서 자주 사용되는 열에 인덱스를 생성하면 쿼리 성능이 향상됩니다.
   * 정렬과 그룹화: ORDER BY나 GROUP BY 구문에서 자주 사용되는 열에 인덱스를 생성하면 성능이 개선될 수 있습니다.
 * How to use:
   * 데이터베이스에서 인덱스를 사용하는 방법은 간단합니다. 인덱스로 사용할 테이블 칼럼을 선택하고 생성만 하면 사용됩니다.
 * Considerations:
   * 인덱스 오버헤드: 인덱스 생성 및 유지 관리에는 추가 저장 공간과 CPU 자원이 필요합니다. 인덱스가 많아지면 데이터 삽입, 업데이트, 삭제 작업의 성능이 저하될 수 있습니다.
   * 인덱스 선택: 모든 열에 인덱스를 생성하는 것은 바람직하지 않습니다. 자주 사용되는 열과 쿼리 성능에 중요한 열에 인덱스를 생성하는 것이 좋습니다.

 3. Denormalziation
 * 정의:
   * 비정규화(Denormalization)는 데이터베이스의 성능을 향상시키기 위해 데이터를 중복 저장하는 전략입니다. 이는 데이터를 정규화하여 중복을 최소화하는 것과 반대되는 개념으로, 특정 쿼리 성능을 최적화하기 위해 데이터를 중복 저장하여 조인을 줄이고 조회 속도를 향상시킵니다.
 * When to use:
   * 읽기 성능 향상: 데이터 읽기 작업이 빈번하고, 읽기 성능이 중요할 때 비정규화를 통해 데이터를 중복 저장하여 조회 속도를 높일 수 있습니다.
   * 복잡한 조인 줄이기: 여러 테이블을 조인하는 복잡한 쿼리를 자주 실행해야 하는 경우, 비정규화를 통해 조인을 줄이고 쿼리 성능을 향상시킬 수 있습니다.
   * 데이터 통합: 서로 다른 데이터 소스에서 데이터를 통합하여 조회할 때, 비정규화를 통해 데이터를 하나의 테이블에 저장하고 조회 성능을 높일 수 있습니다.
 * How to use:
   * 비정규화를 적용하려면 먼저 어떤 데이터가 중복 저장될지 결정해야 합니다. 자주 사용되는 데이터를 식별하고, 해당 데이터를 중복 저장하여 조회 성능을 향상시킵니다.
 * Considerations:
   * 데이터 일관성: 데이터가 중복 저장되므로 일관성을 유지하기 어려울 수 있습니다. 데이터가 변경될 때마다 비정규화된 데이터를 업데이트해야 하므로, 이를 위한 추가적인 로직이 필요합니다
   * 저장 공간 증가: 비정규화는 데이터를 중복 저장하므로 저장 공간 요구량이 증가할 수 있습니다. 데이터베이스의 저장 공간을 충분히 확보해야 합니다.

 4. Vertical Scaling:
 * 정의:
   * Vertical Scaling(수직적 확장)은 기존 서버나 데이터베이스의 하드웨어 사양을 업그레이드하여 성능을 향상시키는 방법입니다. 주로 CPU, RAM, 스토리지와 같은 자원을 추가하거나 교체하는 방식으로 이루어집니다.
 * When to use:
   * 단일 서버의 성능이 충분하지 않을 때: 현재 사용 중인 서버가 증가하는 데이터 처리량을 감당하지 못할 때 수직적 확장을 통해 성능을 향상시킬 수 있습니다.
   * 애플리케이션 구조가 수평적 확장을 지원하지 않을 때: 애플리케이션이 여러 서버에 분산될 수 없는 경우, 단일 서버의 성능을 높이는 것이 효과적입니다.
   * 쉽게 성능 향상이 필요할 때: 하드웨어 업그레이드는 상대적으로 쉽게 성능을 향상시킬 수 있는 방법입니다.
 * How to use:
   * 하드웨어 업그레이드: 서버의 CPU, RAM, 스토리지 등의 하드웨어를 업그레이드합니다.
   * 가상 머신 또는 클라우드 인스턴스 업그레이드: 클라우드 환경에서는 더 높은 사양의 인스턴스로 업그레이드할 수 있습니다.
 * Considerations:
   * 비용: 수직적 확장은 초기 비용이 높을 수 있습니다. 고성능 하드웨어는 높은 비용을 수반하므로 예산을 고려해야 합니다.
   * 확장 한계: 수직적 확장은 물리적 한계가 있습니다. 하드웨어의 최대 성능에 도달하면 더 이상 확장할 수 없으므로, 장기적인 확장성 계획을 고려해야 합니다.
   * 단일 장애점(Single Point of Failure): 단일 서버에 의존하는 경우, 해당 서버가 장애를 일으키면 전체 시스템이 영향을 받을 수 있습니다. 이 경우 고가용성 및 백업 계획을 수립하는 것이 중요합니다.

 5. Caching:
 * 정의:
   * 캐싱 (Caching) 은 자주 조회되는 데이터를 임시 저장소에 저장하여 데이터베이스 접근을 줄이고 응답 시간을 단축시키는 전략입니다. 메모리나 고속 스토리지를 사용하여 데이터를 임시로 저장함으로써 데이터베이스 성능을 향상시킬 수 있습니다.
 * When to use:
   * 자주 조회되는 데이터: 특정 데이터가 자주 조회되는 경우, 캐싱을 통해 데이터베이스 부하를 줄이고 응답 시간을 개선할 수 있습니다.
   * 읽기 성능 최적화: 읽기 작업이 빈번하고, 빠른 응답 시간이 중요한 경우 캐싱을 통해 성능을 최적화할 수 있습니다.
   * 복잡한 쿼리 결과 캐싱: 복잡한 쿼리를 자주 실행해야 하는 경우, 쿼리 결과를 캐싱하여 성능을 향상시킬 수 있습니다.
   * API 응답 속도 개선: 웹 애플리케이션이나 API의 응답 속도를 개선하기 위해 캐싱을 사용할 수 있습니다.
 * How to use:
   * 캐시 설정: 캐시를 설정하려면 먼저 캐시 저장소를 선택합니다. Redis, Memcached, 로컬 메모리 등을 사용할 수 있습니다.
   * 캐시 정책 결정: 캐시 만료 시간(TTL, Time to Live)과 갱신 정책을 설정합니다. 캐시 만료 시간은 데이터의 유효 기간을 결정하며, 갱신 정책은 캐시 데이터가 만료되거나 갱신될 시점을 결정합니다.
   * 데이터 일관성 유지: 캐시된 데이터와 원본 데이터의 일관성을 유지하기 위한 전략을 마련합니다. 원본 데이터가 변경될 때 캐시를 갱신하거나 무효화하는 로직을 구현합니다.
 * Considerations:
   * 캐시 적중률(Cache Hit Rate): 캐시의 효율성을 높이기 위해 캐시 적중률을 모니터링합니다. 캐시 적중률이 낮다면 캐시 정책을 재검토하여 개선합니다.
   * 데이터 일관성: 캐시된 데이터는 원본 데이터가 변경되었을 때 일관성을 유지하기 어려울 수 있습니다. 데이터가 갱신될 때 캐시를 무효화하거나 갱신하는 전략이 필요합니다.
   * 캐시 오버헤드: 캐싱은 추가 저장 공간과 메모리 사용을 필요로 합니다. 캐시 크기를 적절히 관리하여 메모리 사용량을 최적화해야 합니다.
   * TTL 설정: 캐시 만료 시간을 적절히 설정하여 데이터의 최신성과 성능 사이의 균형을 맞춥니다. 너무 짧으면 캐시의 이점을 살리기 어렵고, 너무 길면 오래된 데이터를 반환할 위험이 있습니다.

 6. Replication:
 * 정의:
   * 데이터베이스 복제(Replication)는 데이터베이스의 데이터를 다른 서버에 복제하여 고가용성 및 성능을 향상시키는 전략입니다. 복제된 데이터베이스는 읽기 작업을 분산시키고, 데이터베이스 장애 시에도 시스템을 지속적으로 운영할 수 있도록 합니다.
 * When to use:
   * 고가용성 요구: 시스템의 고가용성이 중요한 경우, 복제를 통해 장애 시에도 서비스가 중단되지 않도록 할 수 있습니다.
   * 읽기 성능 향상: 읽기 작업이 빈번한 경우, 여러 복제본으로 읽기 작업을 분산시켜 성능을 향상시킬 수 있습니다.
   * 백업 및 복구: 데이터를 다른 서버에 복제함으로써 백업 및 복구 작업을 용이하게 할 수 있습니다.
   * 지연시간 향상: 여러 지역에 걸쳐 데이터를 분산하여 사용자에게 더 가까운 서버에서 데이터를 제공할 수 있습니다.
 * How to use:
   * 마스터-슬레이브 복제: 한 서버(마스터)가 쓰기 작업을 처리하고, 다른 서버들(슬레이브)이 읽기 작업을 처리하도록 설정하도록 할 수 있습니다.
   * 다중 리더 복제: 두 개 이상의 서버가 모두 쓰기 및 읽기 작업을 처리할 수 있도록 설정하도록 할 수 있습니다.
   * 비동기 및 동기 복제: 비동기 복제는 성능이 좋지만 데이터 일관성이 떨어질 수 있고, 동기 복제는 데이터 일관성이 높지만 성능이 저하될 수 있습니다. 필요에 따라 선택합니다.
   * 멀티 스레딩 복제: 복제 작업을 병렬로 처리하여 성능을 향상시키는 방법입니다. 슬레이브 서버에서 여러 스레드를 사용하여 마스터의 데이터를 병렬로 복제합니다.
   * 리더 없는 복제(Leaderless Replication): 모든 노드가 동등한 역할을 하여 데이터 읽기 및 쓰기 작업을 분산 처리하는 방식입니다. 주로 NoSQL 데이터베이스에서 사용되며, 각 노드가 독립적으로 작동하여 고가용성과 확장성을 제공합니다.
 * Considerations:
   * 복제 지연: 네트워크 지연이나 복제 설정에 따라 데이터 복제에 시간이 걸릴 수 있습니다. 복제 지연이 발생한다면 최신 데이터 조회의 어려움, 복제 서버의 성능 저하 등이 일어날 수 있기 때문에 복제 지연을 최소화하기 위한 네트워크 설정 및 모니터링이 필요합니다.
   * 데이터 일관성: 비동기 복제는 실시간으로 데이터가 동기화되지 않으므로 일관성 문제가 발생할 수 있습니다. 동기 복제를 통해 데이터 일관성을 유지할 수 있지만 성능에 영향을 줄 수 있습니다.
   * 충돌 해결: 마스터-마스터 복제에서는 동일한 데이터에 대한 충돌이 발생할 수 있습니다. 충돌 해결 정책을 마련해야 합니다.

 7. Shrading:
 * 샤딩(Sharding)은 데이터베이스를 여러 개의 작은 단위(샤드)로 분할하여 각각 독립적인 데이터베이스 서버에 저장하는 전략입니다. 각 샤드는 전체 데이터의 일부를 포함하며, 이를 통해 대규모 데이터베이스의 성능과 확장성을 향상시킬 수 있습니다.
 * When to use:
   * 데이터베이스 크기가 매우 큰 경우: 단일 서버가 전체 데이터를 처리하기 어려운 경우 샤딩을 통해 데이터베이스를 분할하여 처리 성능을 높일 수 있습니다.
   * 높은 트래픽: 많은 사용자가 동시에 데이터베이스에 접근할 때 샤딩을 통해 트래픽을 여러 서버에 분산시킬 수 있습니다.
   * 높은 쓰기/읽기 작업: 데이터 쓰기와 읽기 작업이 많은 경우, 샤딩을 통해 특정 샤드에서만 작업을 처리하여 성능을 최적화할 수 있습니다.
   * 데이터 분리 요구: 지리적 위치나 비즈니스 요구에 따라 데이터를 분리하여 저장해야 할 때 샤딩을 활용할 수 있습니다.
 * How to use:
   * 샤드 키 선택: 데이터를 분할할 기준이 되는 샤드 키를 선택합니다. 일반적으로 사용자 ID, 지역 코드, 타임스탬프 등이 샤드 키로 사용됩니다.
   * 샤딩 알고리즘 선택: 샤딩 알고리즘을 선택하여 데이터를 분할합니다. 주요 알고리즘으로는 다음과 같은 두 가지가 있습니다:
     * Range 기반 샤딩: 샤드 키의 범위에 따라 데이터를 분할합니다. 예를 들어, 특정 사용자 ID 범위마다 다른 샤드에 저장합니다.
     * Hashing 기반 샤딩: 샤드 키를 해싱하여 데이터를 분산합니다. 이 방식은 데이터를 고르게 분산시키는 데 유리합니다.
   * 데이터베이스 분할: 샤드 키를 기반으로 데이터를 여러 데이터베이스 서버에 분할 저장합니다.
   * Routing 로직 구현: 데이터베이스 시스템이 자동으로 샤딩을 지원하지 않는 경우, 애플리케이션 레벨에서 샤드 키를 이용해 데이터를 적절한 샤드에 라우팅하는 로직을 구현합니다. MongoDB와 같은 일부 데이터베이스는 이 로직을 자체적으로 지원합니다
 * Considerations:
   * 데이터 일관성: 여러 샤드에 데이터가 분산되므로, 트랜잭션을 처리할 때 데이터 일관성을 유지하는 것이 어려울 수 있습니다. 분산 트랜잭션 관리나 eventual consistency 모델을 고려해야 합니다.
   * 샤드 간 조인: 샤드 간 조인이 필요한 경우 성능 저하가 발생할 수 있습니다. 가능한 샤드 내에서 데이터를 처리하고, 샤드 간 조인을 최소화하는 설계를 고려해야 합니다.
   * 샤드 키 선택: 샤드 키를 적절히 선택하지 않으면 특정 샤드에 데이터가 집중되어 부하가 증가할 수 있습니다. 고르게 분산되는 샤드 키를 선택하는 것이 중요합니다.
   * 리밸런싱 문제: 데이터 분포가 불균형해질 때, 샤드 추가/제거가 발생할 때 리밸런싱 작업이 필요합니다. 이를 위해 데이터 이동 및 재분할 작업을 효율적으로 자동화하는 방법을 마련해야합니다.
   * Hot Spot 문제: 특정 샤드에 데이터가 집중되어 해당 샤드에 과부하가 발생하는 문제가 발생할 수 있습니다.

<ol ><li>Materialized Views:</li></ol><ul ><li>정의:<ul ><li>Materialized View(MV)는 쿼리 결과를 저장하고 있는 데이터베이스 객체입니다. 이렇게만 말하면 SQL 데이터베이스에만 국한된 개념처럼 보이지만 좀 더 넓은 개념의 의미로 보면 Materialized View는 데이터의 사본을 미리 계산하고 저장하여 성능을 향상시키는 기법입니다.</li></ul></li><li>When to use:<ul ><li>복잡한 쿼리: 여러 조인, 집계 및 계산을 포함하는 복잡한 쿼리라서 데이터를 직접 쿼리하기 어려울 때</li><li>반복적인 읽기 작업: 자주 읽히는 데이터의 경우 Materialized View 기법을 통해서 읽기 성능을 향상 시킬 수 있습니다.</li><li>데이터 집계: 집계 연산 (Aggregation, 합계, 평균, 개수 등) 에서 Materialized Views 를 통해 사전 집계된 결과를 제공해서 성능을 향상 시킬 수 있습니다.</li><li>서로 다른 데이터 저장소의 기능을 활용하기 위해서. 예를 들면 쓰기에 효율적인 데이터 스토어는 데이터를 저장소 역할로 사용하고, 쿼리와 읽기 성능이 좋은 관계형 데이터 스토어에서 Materialized View 를 저장하는 식으로.</li></ul></li><li>How to use:<ul ><li>SQL 에서의 Materialized View 는 Materialized View 객체를 생성하고, 갱신 전략과 그것에 맞는 갱신 주기를 설정하고 조회하면 됩니다.</li><li>추가로 너무 자주 갱신할 경우 성능에 부담이 되고, 너무 늦게 갱신하면 오래된 데이터를 볼 수 있는 문제가 발생할 수 있습니다.</li></ul></li><li>Considerations:<ul ><li>갱신 오버헤드: 갱신 시 리소스가 소요되는 걸 고려해서 갱신 전략과 갱신 주기를 설정하세요.</li><li>Dsposability and Regeneratibility: Materialized View 가 없어지거나 만료되더라도 원본 데이터에서 다시 만들 수 있어야 합니다.</li><li>Consistency: Materialized View 는 원본 데이터로 만들어진 별도의 캐싱 데이터 이므로 데이터 일관성이 안 맞을 수 있습니다. 이것에 대한 고려도 필요합니다.</li><li>원본 데이터가 단순하거나 쿼리하기 쉽다면 이 기법은 적절하지 않을 수 있습니다.</li></ul></li></ul> <ol start="2"><li>Indexing:</li></ol><ul ><li>정의:<ul ><li>데이터베이스의 특정 열에 대해 검색 속도를 향상시키기 위해 데이터 구조를 사용하는 전략입니다.</li></ul></li><li>When to use:<ul ><li>빈번한 검색: 자주 검색되는 열에 대해 인덱스를 생성하면 검색 성능을 크게 향상시킬 수 있습니다.</li><li>JOIN 및 WHERE 절: JOIN이나 WHERE 절에서 자주 사용되는 열에 인덱스를 생성하면 쿼리 성능이 향상됩니다.</li><li>정렬과 그룹화: ORDER BY나 GROUP BY 구문에서 자주 사용되는 열에 인덱스를 생성하면 성능이 개선될 수 있습니다.</li></ul></li><li>How to use:<ul ><li>데이터베이스에서 인덱스를 사용하는 방법은 간단합니다. 인덱스로 사용할 테이블 칼럼을 선택하고 생성만 하면 사용됩니다.</li></ul></li><li>Considerations:<ul ><li>인덱스 오버헤드: 인덱스 생성 및 유지 관리에는 추가 저장 공간과 CPU 자원이 필요합니다. 인덱스가 많아지면 데이터 삽입, 업데이트, 삭제 작업의 성능이 저하될 수 있습니다.</li><li>인덱스 선택: 모든 열에 인덱스를 생성하는 것은 바람직하지 않습니다. 자주 사용되는 열과 쿼리 성능에 중요한 열에 인덱스를 생성하는 것이 좋습니다.</li></ul></li></ul> <ol start="3"><li>Denormalziation</li></ol><ul ><li>정의:<ul ><li>비정규화(Denormalization)는 데이터베이스의 성능을 향상시키기 위해 데이터를 중복 저장하는 전략입니다. 이는 데이터를 정규화하여 중복을 최소화하는 것과 반대되는 개념으로, 특정 쿼리 성능을 최적화하기 위해 데이터를 중복 저장하여 조인을 줄이고 조회 속도를 향상시킵니다.</li></ul></li><li>When to use:<ul ><li>읽기 성능 향상: 데이터 읽기 작업이 빈번하고, 읽기 성능이 중요할 때 비정규화를 통해 데이터를 중복 저장하여 조회 속도를 높일 수 있습니다.</li><li>복잡한 조인 줄이기: 여러 테이블을 조인하는 복잡한 쿼리를 자주 실행해야 하는 경우, 비정규화를 통해 조인을 줄이고 쿼리 성능을 향상시킬 수 있습니다.</li><li>데이터 통합: 서로 다른 데이터 소스에서 데이터를 통합하여 조회할 때, 비정규화를 통해 데이터를 하나의 테이블에 저장하고 조회 성능을 높일 수 있습니다.</li></ul></li><li>How to use:<ul ><li>비정규화를 적용하려면 먼저 어떤 데이터가 중복 저장될지 결정해야 합니다. 자주 사용되는 데이터를 식별하고, 해당 데이터를 중복 저장하여 조회 성능을 향상시킵니다.</li></ul></li><li>Considerations:<ul ><li>데이터 일관성: 데이터가 중복 저장되므로 일관성을 유지하기 어려울 수 있습니다. 데이터가 변경될 때마다 비정규화된 데이터를 업데이트해야 하므로, 이를 위한 추가적인 로직이 필요합니다</li><li>저장 공간 증가: 비정규화는 데이터를 중복 저장하므로 저장 공간 요구량이 증가할 수 있습니다. 데이터베이스의 저장 공간을 충분히 확보해야 합니다.</li></ul></li></ul> <ol start="4"><li>Vertical Scaling:</li></ol><ul ><li>정의:<ul ><li>Vertical Scaling(수직적 확장)은 기존 서버나 데이터베이스의 하드웨어 사양을 업그레이드하여 성능을 향상시키는 방법입니다. 주로 CPU, RAM, 스토리지와 같은 자원을 추가하거나 교체하는 방식으로 이루어집니다.</li></ul></li><li>When to use:<ul ><li>단일 서버의 성능이 충분하지 않을 때: 현재 사용 중인 서버가 증가하는 데이터 처리량을 감당하지 못할 때 수직적 확장을 통해 성능을 향상시킬 수 있습니다.</li><li>애플리케이션 구조가 수평적 확장을 지원하지 않을 때: 애플리케이션이 여러 서버에 분산될 수 없는 경우, 단일 서버의 성능을 높이는 것이 효과적입니다.</li><li>쉽게 성능 향상이 필요할 때: 하드웨어 업그레이드는 상대적으로 쉽게 성능을 향상시킬 수 있는 방법입니다.</li></ul></li><li>How to use:<ul ><li>하드웨어 업그레이드: 서버의 CPU, RAM, 스토리지 등의 하드웨어를 업그레이드합니다.</li><li>가상 머신 또는 클라우드 인스턴스 업그레이드: 클라우드 환경에서는 더 높은 사양의 인스턴스로 업그레이드할 수 있습니다.</li></ul></li><li>Considerations:<ul ><li>비용: 수직적 확장은 초기 비용이 높을 수 있습니다. 고성능 하드웨어는 높은 비용을 수반하므로 예산을 고려해야 합니다.</li><li>확장 한계: 수직적 확장은 물리적 한계가 있습니다. 하드웨어의 최대 성능에 도달하면 더 이상 확장할 수 없으므로, 장기적인 확장성 계획을 고려해야 합니다.</li><li>단일 장애점(Single Point of Failure): 단일 서버에 의존하는 경우, 해당 서버가 장애를 일으키면 전체 시스템이 영향을 받을 수 있습니다. 이 경우 고가용성 및 백업 계획을 수립하는 것이 중요합니다.</li></ul></li></ul> <ol start="5"><li>Caching:</li></ol><ul ><li>정의:<ul ><li>캐싱 (Caching) 은 자주 조회되는 데이터를 임시 저장소에 저장하여 데이터베이스 접근을 줄이고 응답 시간을 단축시키는 전략입니다. 메모리나 고속 스토리지를 사용하여 데이터를 임시로 저장함으로써 데이터베이스 성능을 향상시킬 수 있습니다.</li></ul></li><li>When to use:<ul ><li>자주 조회되는 데이터: 특정 데이터가 자주 조회되는 경우, 캐싱을 통해 데이터베이스 부하를 줄이고 응답 시간을 개선할 수 있습니다.</li><li>읽기 성능 최적화: 읽기 작업이 빈번하고, 빠른 응답 시간이 중요한 경우 캐싱을 통해 성능을 최적화할 수 있습니다.</li><li>복잡한 쿼리 결과 캐싱: 복잡한 쿼리를 자주 실행해야 하는 경우, 쿼리 결과를 캐싱하여 성능을 향상시킬 수 있습니다.</li><li>API 응답 속도 개선: 웹 애플리케이션이나 API의 응답 속도를 개선하기 위해 캐싱을 사용할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>캐시 설정: 캐시를 설정하려면 먼저 캐시 저장소를 선택합니다. Redis, Memcached, 로컬 메모리 등을 사용할 수 있습니다.</li><li>캐시 정책 결정: 캐시 만료 시간(TTL, Time to Live)과 갱신 정책을 설정합니다. 캐시 만료 시간은 데이터의 유효 기간을 결정하며, 갱신 정책은 캐시 데이터가 만료되거나 갱신될 시점을 결정합니다.</li><li>데이터 일관성 유지: 캐시된 데이터와 원본 데이터의 일관성을 유지하기 위한 전략을 마련합니다. 원본 데이터가 변경될 때 캐시를 갱신하거나 무효화하는 로직을 구현합니다.</li></ul></li><li>Considerations:<ul ><li>캐시 적중률(Cache Hit Rate): 캐시의 효율성을 높이기 위해 캐시 적중률을 모니터링합니다. 캐시 적중률이 낮다면 캐시 정책을 재검토하여 개선합니다.</li><li>데이터 일관성: 캐시된 데이터는 원본 데이터가 변경되었을 때 일관성을 유지하기 어려울 수 있습니다. 데이터가 갱신될 때 캐시를 무효화하거나 갱신하는 전략이 필요합니다.</li><li>캐시 오버헤드: 캐싱은 추가 저장 공간과 메모리 사용을 필요로 합니다. 캐시 크기를 적절히 관리하여 메모리 사용량을 최적화해야 합니다.</li><li>TTL 설정: 캐시 만료 시간을 적절히 설정하여 데이터의 최신성과 성능 사이의 균형을 맞춥니다. 너무 짧으면 캐시의 이점을 살리기 어렵고, 너무 길면 오래된 데이터를 반환할 위험이 있습니다.</li></ul></li></ul> <ol start="6"><li>Replication:</li></ol><ul ><li>정의:<ul ><li>데이터베이스 복제(Replication)는 데이터베이스의 데이터를 다른 서버에 복제하여 고가용성 및 성능을 향상시키는 전략입니다. 복제된 데이터베이스는 읽기 작업을 분산시키고, 데이터베이스 장애 시에도 시스템을 지속적으로 운영할 수 있도록 합니다.</li></ul></li><li>When to use:<ul ><li>고가용성 요구: 시스템의 고가용성이 중요한 경우, 복제를 통해 장애 시에도 서비스가 중단되지 않도록 할 수 있습니다.</li><li>읽기 성능 향상: 읽기 작업이 빈번한 경우, 여러 복제본으로 읽기 작업을 분산시켜 성능을 향상시킬 수 있습니다.</li><li>백업 및 복구: 데이터를 다른 서버에 복제함으로써 백업 및 복구 작업을 용이하게 할 수 있습니다.</li><li>지연시간 향상: 여러 지역에 걸쳐 데이터를 분산하여 사용자에게 더 가까운 서버에서 데이터를 제공할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>마스터-슬레이브 복제: 한 서버(마스터)가 쓰기 작업을 처리하고, 다른 서버들(슬레이브)이 읽기 작업을 처리하도록 설정하도록 할 수 있습니다.</li><li>다중 리더 복제: 두 개 이상의 서버가 모두 쓰기 및 읽기 작업을 처리할 수 있도록 설정하도록 할 수 있습니다.</li><li>비동기 및 동기 복제: 비동기 복제는 성능이 좋지만 데이터 일관성이 떨어질 수 있고, 동기 복제는 데이터 일관성이 높지만 성능이 저하될 수 있습니다. 필요에 따라 선택합니다.</li><li>멀티 스레딩 복제: 복제 작업을 병렬로 처리하여 성능을 향상시키는 방법입니다. 슬레이브 서버에서 여러 스레드를 사용하여 마스터의 데이터를 병렬로 복제합니다.</li><li>리더 없는 복제(Leaderless Replication): 모든 노드가 동등한 역할을 하여 데이터 읽기 및 쓰기 작업을 분산 처리하는 방식입니다. 주로 NoSQL 데이터베이스에서 사용되며, 각 노드가 독립적으로 작동하여 고가용성과 확장성을 제공합니다.</li></ul></li><li>Considerations:<ul ><li>복제 지연: 네트워크 지연이나 복제 설정에 따라 데이터 복제에 시간이 걸릴 수 있습니다. 복제 지연이 발생한다면 최신 데이터 조회의 어려움, 복제 서버의 성능 저하 등이 일어날 수 있기 때문에 복제 지연을 최소화하기 위한 네트워크 설정 및 모니터링이 필요합니다.</li><li>데이터 일관성: 비동기 복제는 실시간으로 데이터가 동기화되지 않으므로 일관성 문제가 발생할 수 있습니다. 동기 복제를 통해 데이터 일관성을 유지할 수 있지만 성능에 영향을 줄 수 있습니다.</li><li>충돌 해결: 마스터-마스터 복제에서는 동일한 데이터에 대한 충돌이 발생할 수 있습니다. 충돌 해결 정책을 마련해야 합니다.</li></ul></li></ul> <ol start="7"><li>Shrading:</li></ol><ul ><li>샤딩(Sharding)은 데이터베이스를 여러 개의 작은 단위(샤드)로 분할하여 각각 독립적인 데이터베이스 서버에 저장하는 전략입니다. 각 샤드는 전체 데이터의 일부를 포함하며, 이를 통해 대규모 데이터베이스의 성능과 확장성을 향상시킬 수 있습니다.</li><li>When to use:<ul ><li>데이터베이스 크기가 매우 큰 경우: 단일 서버가 전체 데이터를 처리하기 어려운 경우 샤딩을 통해 데이터베이스를 분할하여 처리 성능을 높일 수 있습니다.</li><li>높은 트래픽: 많은 사용자가 동시에 데이터베이스에 접근할 때 샤딩을 통해 트래픽을 여러 서버에 분산시킬 수 있습니다.</li><li>높은 쓰기/읽기 작업: 데이터 쓰기와 읽기 작업이 많은 경우, 샤딩을 통해 특정 샤드에서만 작업을 처리하여 성능을 최적화할 수 있습니다.</li><li>데이터 분리 요구: 지리적 위치나 비즈니스 요구에 따라 데이터를 분리하여 저장해야 할 때 샤딩을 활용할 수 있습니다.</li></ul></li><li>How to use:<ul ><li>샤드 키 선택: 데이터를 분할할 기준이 되는 샤드 키를 선택합니다. 일반적으로 사용자 ID, 지역 코드, 타임스탬프 등이 샤드 키로 사용됩니다.</li><li>샤딩 알고리즘 선택: 샤딩 알고리즘을 선택하여 데이터를 분할합니다. 주요 알고리즘으로는 다음과 같은 두 가지가 있습니다:<ul ><li>Range 기반 샤딩: 샤드 키의 범위에 따라 데이터를 분할합니다. 예를 들어, 특정 사용자 ID 범위마다 다른 샤드에 저장합니다.</li><li>Hashing 기반 샤딩: 샤드 키를 해싱하여 데이터를 분산합니다. 이 방식은 데이터를 고르게 분산시키는 데 유리합니다.</li></ul></li><li>데이터베이스 분할: 샤드 키를 기반으로 데이터를 여러 데이터베이스 서버에 분할 저장합니다.</li><li>Routing 로직 구현: 데이터베이스 시스템이 자동으로 샤딩을 지원하지 않는 경우, 애플리케이션 레벨에서 샤드 키를 이용해 데이터를 적절한 샤드에 라우팅하는 로직을 구현합니다. MongoDB와 같은 일부 데이터베이스는 이 로직을 자체적으로 지원합니다</li></ul></li><li>Considerations:<ul ><li>데이터 일관성: 여러 샤드에 데이터가 분산되므로, 트랜잭션을 처리할 때 데이터 일관성을 유지하는 것이 어려울 수 있습니다. 분산 트랜잭션 관리나 eventual consistency 모델을 고려해야 합니다.</li><li>샤드 간 조인: 샤드 간 조인이 필요한 경우 성능 저하가 발생할 수 있습니다. 가능한 샤드 내에서 데이터를 처리하고, 샤드 간 조인을 최소화하는 설계를 고려해야 합니다.</li><li>샤드 키 선택: 샤드 키를 적절히 선택하지 않으면 특정 샤드에 데이터가 집중되어 부하가 증가할 수 있습니다. 고르게 분산되는 샤드 키를 선택하는 것이 중요합니다.</li><li>리밸런싱 문제: 데이터 분포가 불균형해질 때, 샤드 추가/제거가 발생할 때 리밸런싱 작업이 필요합니다. 이를 위해 데이터 이동 및 재분할 작업을 효율적으로 자동화하는 방법을 마련해야합니다.</li><li>Hot Spot 문제: 특정 샤드에 데이터가 집중되어 해당 샤드에 과부하가 발생하는 문제가 발생할 수 있습니다.</li></ul></li></ul>

반드시 알아야 하는 7가지 데이터베이스 확장성 전략

자바스크립트의 History API와 클라이언트 단 라우팅

URL이 바뀔 때 마다 새로운 페이지를 서버로 요청하지 않는 SPA(Single Page Application)에서는 보통 클라이언트 단에서 라우팅(routing)을 하는데요. 그래서 React, Svelte, Vue.js와 같은 대부분의 프론트엔드 프레임워크을 사용할 때는 이러한 클라이언트 단 라우팅을 지원하는 라이브러리와 함께 쓰는 경우가 많습니다.

그런데 이러한 라우팅 라이브러리는 대부분은 내부적으로 자바스크립트의 History API를 사용하고 있다는 것을 알고 계셨나요? 이번 글에서는 클라이언트 단 라우팅을 이해하는데 핵심적인 자바스크립트의 History API에 대해서 알아보고 간단한 실습도 진행해보겠습니다.

📝 포스팅: https://www.daleseo.com/js-history-api/
🧑‍💻 실습 코드: https://codepen.io/daleseo/pen/JjwPBwv

실제 애플리케이션을 개발하실 때는 이미 많은 프로젝트에서 검증이 된 유명한 라우팅 라이브러리를 사용하실테니 이렇게 직접 라우팅을 구현할 일은 없으실 것입니다. 하지만 라우팅 라이브러리가 내부적으로 어떻게 동작하시는지 이해하신다면 버그가 생겼을 때 디버깅이 용이해지고 나중에 다른 프론트엔드의 라우팅 라이브러리를 배울 때도 큰 도움이 될 것입니다.

URL이 바뀔 때 마다 새로운 페이지를 서버로 요청하지 않는 SPA(Single Page Application)에서는 보통 클라이언트 단에서 라우팅(routing)을 하는데요. 그래서 React, Svelte, Vue.js와 같은 대부분의 프론트엔드 프레임워크을 사용할 때는 이러한 클라이언트 단 라우팅을 지원하는 라이브러리와 함께 쓰는 경우가 많습니다. 그런데 이러한 라우팅 라이브러리는 대부분은 내부적으로 자바스크립트의 History API를 사용하고 있다는 것을 알고 계셨나요? 이번 글에서는 클라이언트 단 라우팅을 이해하는데 핵심적인 자바스크립트의 History API에 대해서 알아보고 간단한 실습도 진행해보겠습니다. 📝 포스팅: https://www.daleseo.com/js-history-api/🧑‍💻 실습 코드: https://codepen.io/daleseo/pen/JjwPBwv 실제 애플리케이션을 개발하실 때는 이미 많은 프로젝트에서 검증이 된 유명한 라우팅 라이브러리를 사용하실테니 이렇게 직접 라우팅을 구현할 일은 없으실 것입니다. 하지만 라우팅 라이브러리가 내부적으로 어떻게 동작하시는지 이해하신다면 버그가 생겼을 때 디버깅이 용이해지고 나중에 다른 프론트엔드의 라우팅 라이브러리를 배울 때도 큰 도움이 될 것입니다.

Daleseo

일본인 정원사 '이 한마디', 엔비디아 젠슨 황 인생 바꿨다, 엔비디아 CEO "日정원사와의 만남이 날 성공하게 만들어" 젠슨 황, 美대학 졸업식 연설 일본 정원사, 찌는 듯한 날에도 묵묵히 나뭇잎·이끼 정리하며 "정원 가꿀 시간은 충분" 말에 인생에서 가장 큰 깨달음 "평생 바치면 시간은 충분 우선순위 정해 집중하라" "매일 아침 중요한 업무부터 봐 출근도 전에 이미 성공적인 하루"

일본인 정원사 '이 한마디', 엔비디아 젠슨 황 인생 바꿨다

우리는 늘 시간에 쫓겨서 살아갑니다.
해야 할 일이 많고, 하고 싶은 일이 많습니다.

회사의 CEO인 젠슨황에게도 그러했을 것입니다.
젠슨황은 1년에 1달동안은 해외에서 일을 한다고 해요.
자녀들이 10살때에 일본에서 1달동안 일을 한적이 있는데,
덥고 습한날 거대한 정원을 대나무 집게로 다듬는 정원사를 보며 물었습니다.

황 : 무엇을 하고 있나요?
정원사 : 죽은 이끼를 따고 있어요.
황: 정원이 너무 넓지 않나요?
정원사 : 25년간 정원을 가꿨고, 앞으로도 시간은 충분합니다.
황 : !!

이 순간이 젠슨황에게 가장 큰 깨달음을 준 시간이라고 해요.
너무나 넓어 보이는 정원이지만,
지금껏 25년간 정원을 가꿔온 정원사는 급하지 않았습니다.
매일 매일 자신을 믿으며 정원을 가꿀뿐이었죠.

직접적으로 겪은 이야기가 아니기에 여러분에게는 크게 와닿지 않을 수 있습니다.
젠슨황은 이렇게 얘기하네요.

'여러분이 평생을 바쳐 완성하고 싶은 기술을 찾기 바랍니다.
많은 일이 일어나고 있고 해야할 일이 많지만
인생의 우선순위를 정하고, 삶의 우선순위를 정하면 시간은 충분할 거예요.'

우리에게는 아직 시간이 많습니다.
우선순위를 정하고 방향을 잘 정해서 나아가봅시다.

https://www.hankyung.com/article/202406171169i

우리는 늘 시간에 쫓겨서 살아갑니다.해야 할 일이 많고, 하고 싶은 일이 많습니다. 회사의 CEO인 젠슨황에게도 그러했을 것입니다.젠슨황은 1년에 1달동안은 해외에서 일을 한다고 해요.자녀들이 10살때에 일본에서 1달동안 일을 한적이 있는데,덥고 습한날 거대한 정원을 대나무 집게로 다듬는 정원사를 보며 물었습니다. 황 : 무엇을 하고 있나요?정원사 : 죽은 이끼를 따고 있어요.황: 정원이 너무 넓지 않나요?정원사 : 25년간 정원을 가꿨고, 앞으로도 시간은 충분합니다.황 : !! 이 순간이 젠슨황에게 가장 큰 깨달음을 준 시간이라고 해요.너무나 넓어 보이는 정원이지만,지금껏 25년간 정원을 가꿔온 정원사는 급하지 않았습니다.매일 매일 자신을 믿으며 정원을 가꿀뿐이었죠. 직접적으로 겪은 이야기가 아니기에 여러분에게는 크게 와닿지 않을 수 있습니다.젠슨황은 이렇게 얘기하네요. '여러분이 평생을 바쳐 완성하고 싶은 기술을 찾기 바랍니다.많은 일이 일어나고 있고 해야할 일이 많지만인생의 우선순위를 정하고, 삶의 우선순위를 정하면 시간은 충분할 거예요.' 우리에게는 아직 시간이 많습니다.우선순위를 정하고 방향을 잘 정해서 나아가봅시다. https://www.hankyung.com/article/202406171169i

한국경제

젠슨황의 인생에 가장 큰깨달음을 준 한마디 - 시간은 충분하다

We analyzed data from thousands of applications and cloud environments to assess trends in application security posture and adoption of DevSecOps best practices.

State of DevSecOps

Datadog에서 2~4월까지 애플리케이션과 컨테이너 이미지, 클라우드 환경을 분석해서 공개한 DevSecOps 분석 리포트입니다.

분석 결과 다음과 같은 7가지 특징을 정리했습니다.

 1. Java 서비스는 서드파티 취약점의 영향을 가장 많이 받습니다.
 2. 자동화된 보안 스캐너의 공격 시도는 대부분 조치할 수 없는 노이즈일 뿐입니다.
 3. 식별된 취약점 중 일부만 우선순위를 정할 가치가 있습니다.
 4. 경량 컨테이너 이미지를 사용하면 취약점이 감소합니다.
 5. Infrastructure as Code의 도입률은 높지만, 도입률이 클라우드 업체별로 꽤 차이가 있습니다.
 6. 수동 클라우드 배포는 여전히 널리 퍼져있습니다.
 7. CI/CD 파이프라인에서 수명이 짧은 크리덴셜의 사용률이 여전히 너무 낮습니다.

4번 처럼 경량 컨테이너가 공격 표면이 적어서 취약점도 감소한다는 것은 너무 당연한 얘기이지만 관심있는 부분에 대한 데이터도 있어서 흥미로웠습니다.

취약점 같은 경우 도구를 처음부터 사용했다면 비교적 괜찮지만 중간에 취약점 분석 도구를 도입하는 경우 크게 의미 없어 보이는 수많은 취약점 리포트에 압도되어 제대로 처리하기가 어렵습니다. 이런 부분을 어떻게 도입하면 좋을지 고민이 있었는데 실제로 의미있는 취약점이 일부라는 부분에 관심이 갔습니다.

CI/CD 파이프라인에서도 크리덴셜 관리에 관심을 가지고 있는데 짧은 수명 주기로 정기적으로 교체하기 위한 시스템을 만들기 위해 고민중인데 업계 전체적으로도 이런 부분을 잘 하고 있지 못하다는 것도 재밌었습니다.

https://www.datadoghq.com/state-of-devsecops/

Datadog에서 2~4월까지 애플리케이션과 컨테이너 이미지, 클라우드 환경을 분석해서 공개한 DevSecOps 분석 리포트입니다. 분석 결과 다음과 같은 7가지 특징을 정리했습니다. <ol ><li>Java 서비스는 서드파티 취약점의 영향을 가장 많이 받습니다. </li><li>자동화된 보안 스캐너의 공격 시도는 대부분 조치할 수 없는 노이즈일 뿐입니다.</li><li>식별된 취약점 중 일부만 우선순위를 정할 가치가 있습니다.</li><li>경량 컨테이너 이미지를 사용하면 취약점이 감소합니다.</li><li>Infrastructure as Code의 도입률은 높지만, 도입률이 클라우드 업체별로 꽤 차이가 있습니다.</li><li>수동 클라우드 배포는 여전히 널리 퍼져있습니다.</li><li>CI/CD 파이프라인에서 수명이 짧은 크리덴셜의 사용률이 여전히 너무 낮습니다.</li></ol> 4번 처럼 경량 컨테이너가 공격 표면이 적어서 취약점도 감소한다는 것은 너무 당연한 얘기이지만 관심있는 부분에 대한 데이터도 있어서 흥미로웠습니다. 취약점 같은 경우 도구를 처음부터 사용했다면 비교적 괜찮지만 중간에 취약점 분석 도구를 도입하는 경우 크게 의미 없어 보이는 수많은 취약점 리포트에 압도되어 제대로 처리하기가 어렵습니다. 이런 부분을 어떻게 도입하면 좋을지 고민이 있었는데 실제로 의미있는 취약점이 일부라는 부분에 관심이 갔습니다. CI/CD 파이프라인에서도 크리덴셜 관리에 관심을 가지고 있는데 짧은 수명 주기로 정기적으로 교체하기 위한 시스템을 만들기 위해 고민중인데 업계 전체적으로도 이런 부분을 잘 하고 있지 못하다는 것도 재밌었습니다. https://www.datadoghq.com/state-of-devsecops/

Datadog

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)

앞서 연차로 인한 압박에 관한 글을 쓰기도 했지만 아무래도 사교육과 선행학습이 일상인 환경에서 자라고 교육받다보니 다들 기술 지향적으로 뭘 배워두면 내 커리어가 안전해질까 등으로 항상 정답을 찾으려 많이 하려 하는 듯 하다. 다시 한번 학교 바깥의 세상에는 정해진 커리큘럼도 없고 시험처럼 정답이 정해진 형태의 테스트가 있지도 않다.

긴 커리어에서 더 건강한 관점은 내가 원하는 것이 무엇인지 고민하고 나에게 맞는 환경을 찾아 거기서 현재에 집중하며 맡은 업무 파악(의사 소통 -> 문제 정의)하고 그 업무를 성공으로 이끌어내는 경험을 하는 것이 중요하다. 피터 드러커의 "The Effective Executive"라는 책을 보면 모든 지식 노동자는 본인이 하고 있는 "공헌"이 무엇인지 고민해봐야 한다는 이야기를 한다. 여기서 포인트는 "맞는" 공헌을 하고 있는지 아니면 뭔가 잘못된 공헌을 하고 있는지 살펴봐야 한다는 점이다.

잘못된 공헌으로는 어떤 것들이 있을까?

 1. 매니저로써 팀빌딩에 힘을 쓰기 보다는 개인으로 하는 코딩에 더 노력하는 것을 들 수 있다. 팀에 인력이 부족해서 라면 모르겠지만 대신할 사람이 있는데 그렇다면 큰 문제다.
 2. 매니저로 모든 일에 직접 끼어들다보니 본인이 없으면 팀이 안 돌아간다면 결국 본인이 병목이 되면서 문제가 된다. 1, 2번에서 매니저라고 했지만 팀내 시니어 멤버라면 본인을 대입해서 생각해볼 필요가 있다. 프로세스로 돌아가게 하거나 나를 대신할 사람을 계속 찾는 노력을 계속해야 한다.
 3. 불필요하게 새로운 프레임웍의 도입을 서두르는 것인데 일반적으로 이야기하자면 문제해결이나 가치창출에 집중하는 것이 아니라 너무 기술중심으로 가는 거다.
 4. 주니어라면 처음에는 모르는 것들이 많을 수 있지만 동일한 질문이나 도움을 반복한다면 뭔가 잘못된 것이다. 팀에 공헌하는 사람이 되고 싶다면 발전하는 사람이 되어야 하며 때로는 모르거나 이해가 안되거를 대충 체면치레하며 넘어가지 말고 구체적으로 물어보고 이해해야 한다.
 5. 다른 큰 범주는 문제정의를 잘 하고 맞는 방향으로 노력을 하는 것이 아니라 잘못된 "노력"을 강조하는 것이다.맞는 방향으로 노력했지만 결과가 안 좋았다면 그건 괜찮지만 열심히 했다는 이유만으로 모든 것이 인정되는 것은 아니다. 등산이라면 어느 산으로 올라가는지 먼저 파악해야지 아무 산이나 열심히 올라간 다음에 그걸 인정해달라는 건 말이 안 된다.

조직 사회에서 인정받고 자신감을 쌓는 제일 좋은 방법은 "결과"를 내는 사람이 되는 것이며 이는 내가 지금 할 수 있는 "맞는 공헌"이 무엇이 있는지 생각해보고 내 매니저나 동료들과 많이 이야기해보는 것이다. 개발자 관점에서 조심할 부분은 너무 기술적으로만 바라보는 것이다.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s></li></ol> 앞서 연차로 인한 압박에 관한 글을 쓰기도 했지만 아무래도 사교육과 선행학습이 일상인 환경에서 자라고 교육받다보니 다들 기술 지향적으로 뭘 배워두면 내 커리어가 안전해질까 등으로 항상 정답을 찾으려 많이 하려 하는 듯 하다. 다시 한번 학교 바깥의 세상에는 정해진 커리큘럼도 없고 시험처럼 정답이 정해진 형태의 테스트가 있지도 않다. 긴 커리어에서 더 건강한 관점은 내가 원하는 것이 무엇인지 고민하고 나에게 맞는 환경을 찾아 거기서 현재에 집중하며 맡은 업무 파악(의사 소통 -&gt; 문제 정의)하고 그 업무를 성공으로 이끌어내는 경험을 하는 것이 중요하다. 피터 드러커의 "The Effective Executive"라는 책을 보면 모든 지식 노동자는 본인이 하고 있는 "공헌"이 무엇인지 고민해봐야 한다는 이야기를 한다. 여기서 포인트는 "맞는" 공헌을 하고 있는지 아니면 뭔가 잘못된 공헌을 하고 있는지 살펴봐야 한다는 점이다. 잘못된 공헌으로는 어떤 것들이 있을까? <ol ><li>매니저로써 팀빌딩에 힘을 쓰기 보다는 개인으로 하는 코딩에 더 노력하는 것을 들 수 있다. 팀에 인력이 부족해서 라면 모르겠지만 대신할 사람이 있는데 그렇다면 큰 문제다.</li><li>매니저로 모든 일에 직접 끼어들다보니 본인이 없으면 팀이 안 돌아간다면 결국 본인이 병목이 되면서 문제가 된다. 1, 2번에서 매니저라고 했지만 팀내 시니어 멤버라면 본인을 대입해서 생각해볼 필요가 있다. 프로세스로 돌아가게 하거나 나를 대신할 사람을 계속 찾는 노력을 계속해야 한다.</li><li>불필요하게 새로운 프레임웍의 도입을 서두르는 것인데 일반적으로 이야기하자면 문제해결이나 가치창출에 집중하는 것이 아니라 너무 기술중심으로 가는 거다.</li><li>주니어라면 처음에는 모르는 것들이 많을 수 있지만 동일한 질문이나 도움을 반복한다면 뭔가 잘못된 것이다. 팀에 공헌하는 사람이 되고 싶다면 발전하는 사람이 되어야 하며 때로는 모르거나 이해가 안되거를 대충 체면치레하며 넘어가지 말고 구체적으로 물어보고 이해해야 한다.</li><li>다른 큰 범주는 문제정의를 잘 하고 맞는 방향으로 노력을 하는 것이 아니라 잘못된 "노력"을 강조하는 것이다.맞는 방향으로 노력했지만 결과가 안 좋았다면 그건 괜찮지만 열심히 했다는 이유만으로 모든 것이 인정되는 것은 아니다. 등산이라면 어느 산으로 올라가는지 먼저 파악해야지 아무 산이나 열심히 올라간 다음에 그걸 인정해달라는 건 말이 안 된다.</li></ol> 조직 사회에서 인정받고 자신감을 쌓는 제일 좋은 방법은 "결과"를 내는 사람이 되는 것이며 이는 내가 지금 할 수 있는 "맞는 공헌"이 무엇이 있는지 생각해보고 내 매니저나 동료들과 많이 이야기해보는 것이다. 개발자 관점에서 조심할 부분은 너무 기술적으로만 바라보는 것이다.

좋은 개발자가 알아야하는 9가지 포인트들 - 8. 결과를 내는데 

트위터에 끄적였던 내용인데, 커리어리에도 공유해봐요.

----

’애플에서는 단순하게 일합니다‘ 를 읽다 든 생각인데, 쿠팡이 잘한 점 중 하나는 단 하나의 회사만 벤치마킹 했다는 점인 것 같다.
쿠팡은 (특히) 엔지니어링 조직의 운영을 아마존을 대부분 카피했는데 어느 한 부분만 카피하기보다 전 시스템을 그대로 가져왔다. 리더쉽원칙 부터 레벨제도까지…

어떻게 보면 시행착오를 최소한으로 줄이고, 특정 부분이 아닌 조직을 지탱하는 전체 시스템을 그대로 가져와서 운영했다.
탄탄한 기업의 견고한 시스템을 구성하는 요소들은 오랜시간 갈고 닦이는 과정에서 서로 강하게 연관되어 있을 수 밖에 없고 함께 운용되어야 가치를 발할 수 있다고 생각한다.

생각보다 이 점을 간과하고 특정한 부분 하나, 둘만 배껴 잘 동작하길 바라는 국내 회사가 많은 듯 하다.
책에서 보니 메타가.. 어디서 보니 넷플릭스가… 배끼려면 전체를 이해하고 가져와야 한다는 생각을 한다.
아니면 지금 회사에 맞게 새로 창조하거나…

쓰고보니 쿠팡 경영진들은 그렇게 생각 안할 수도 있을 것 같은데… 말단 사원이 느끼기에는 그랬다.
아니 이렇게까지 배껴도 되나 싶을 정도로 ‘아마존, 세상의 모든 것을 팝니다’ 에서 봤던 내용과 비슷했는데(인터뷰를 앞두고 이 책을 읽고 오라고 추천받았었다), 꽤 괜찮은 전략이었다고 생각한다.

시스템은 카피하고, 시행착오를 줄여 아낀 에너지와 비용을 제품을 만드는데 집중했다.
지금의 쿠팡은 어떨지 모르겠지만 퇴사하고 시간이 꽤 지난 시점에서, 회고해보니 뭐에 집중해야할지 잘 알았던 것 같다.

그 다음 우형, 당근 등 회사에 이직했는데 전사 인원이 훨씬 줄어든 규모였음에도 오히려 회사가 커진 기분이 들었다.
쿠팡의 119 채널은 조금만 서비스가 이상해도 전사 누구나 언제나 편하게 제보했고, 부서에 무관하게 뛰어들어 문제를 파악하고 개선안을 제시하는 문화가 있었다.

공개적으로 질문하고, 누구든 답변했다.
이게 쉽지 않은거구나. 하고 알게 됐다.
사업부마다 소규모 스타트업인 것 처럼 분리되어 느껴지는 회사가 대부분이었는데, 쿠팡은 의도했는지 아닌지 모르지만 이 부분에 있어서는 직원으로서 경험이 가장 좋았다.

’애플에서는 단순하게 일합니다.‘ 에서 애플로 복귀한 잡스가 가장 먼저 한 일이 제품별 부서를 기능별 부서로 재 조직하고, 회사를 하나의 조직으로서 운용하고, 평가하도록 했다는 부분, 새 조직구조를 지탱하기 위해 만들고 지켰던 원칙들에 대한 이야기를 읽다보니 문득 생각이 들어 끄적거려봤다.

전체 직원수, 회사의 규모와 직원 한 명, 한 명이 느끼는 조직의 크기가 꼭 같지만은 않은 것 같다. 생각보다 이 부분을 많은 회사가 놓치는 것 같기도 하고… “이 정도 규모에선 그런 걸 기대하긴 이제 어렵죠.” 라는 말을 너무 쉽게 꺼내는 것 같기도 하고…

여기까지 쓰고보니, 요즘 업계 상황을 보면 월급 안 밀리고, 안 잘리고, 퇴근할 때(!) 퇴근하는 거에 감사해야한다는 생각이 들었다.
뭐가 문제의 원인인지 얼마나 시간이 흘러야 업계 상황이 나아질지, 나아지긴 할런지… 하고 생각이 들었다.
좋은 회사, 건강한 회사, 행복한 IT 인들 많아지길…

트위터에 끄적였던 내용인데, 커리어리에도 공유해봐요. ---- ’애플에서는 단순하게 일합니다‘ 를 읽다 든 생각인데, 쿠팡이 잘한 점 중 하나는 단 하나의 회사만 벤치마킹 했다는 점인 것 같다.쿠팡은 (특히) 엔지니어링 조직의 운영을 아마존을 대부분 카피했는데 어느 한 부분만 카피하기보다 전 시스템을 그대로 가져왔다. 리더쉽원칙 부터 레벨제도까지… 어떻게 보면 시행착오를 최소한으로 줄이고, 특정 부분이 아닌 조직을 지탱하는 전체 시스템을 그대로 가져와서 운영했다.탄탄한 기업의 견고한 시스템을 구성하는 요소들은 오랜시간 갈고 닦이는 과정에서 서로 강하게 연관되어 있을 수 밖에 없고 함께 운용되어야 가치를 발할 수 있다고 생각한다. 생각보다 이 점을 간과하고 특정한 부분 하나, 둘만 배껴 잘 동작하길 바라는 국내 회사가 많은 듯 하다.책에서 보니 메타가.. 어디서 보니 넷플릭스가… 배끼려면 전체를 이해하고 가져와야 한다는 생각을 한다.아니면 지금 회사에 맞게 새로 창조하거나… 쓰고보니 쿠팡 경영진들은 그렇게 생각 안할 수도 있을 것 같은데… 말단 사원이 느끼기에는 그랬다.아니 이렇게까지 배껴도 되나 싶을 정도로 ‘아마존, 세상의 모든 것을 팝니다’ 에서 봤던 내용과 비슷했는데(인터뷰를 앞두고 이 책을 읽고 오라고 추천받았었다), 꽤 괜찮은 전략이었다고 생각한다. 시스템은 카피하고, 시행착오를 줄여 아낀 에너지와 비용을 제품을 만드는데 집중했다.지금의 쿠팡은 어떨지 모르겠지만 퇴사하고 시간이 꽤 지난 시점에서, 회고해보니 뭐에 집중해야할지 잘 알았던 것 같다. 그 다음 우형, 당근 등 회사에 이직했는데 전사 인원이 훨씬 줄어든 규모였음에도 오히려 회사가 커진 기분이 들었다.쿠팡의 119 채널은 조금만 서비스가 이상해도 전사 누구나 언제나 편하게 제보했고, 부서에 무관하게 뛰어들어 문제를 파악하고 개선안을 제시하는 문화가 있었다. 공개적으로 질문하고, 누구든 답변했다.이게 쉽지 않은거구나. 하고 알게 됐다.사업부마다 소규모 스타트업인 것 처럼 분리되어 느껴지는 회사가 대부분이었는데, 쿠팡은 의도했는지 아닌지 모르지만 이 부분에 있어서는 직원으로서 경험이 가장 좋았다. ’애플에서는 단순하게 일합니다.‘ 에서 애플로 복귀한 잡스가 가장 먼저 한 일이 제품별 부서를 기능별 부서로 재 조직하고, 회사를 하나의 조직으로서 운용하고, 평가하도록 했다는 부분, 새 조직구조를 지탱하기 위해 만들고 지켰던 원칙들에 대한 이야기를 읽다보니 문득 생각이 들어 끄적거려봤다. 전체 직원수, 회사의 규모와 직원 한 명, 한 명이 느끼는 조직의 크기가 꼭 같지만은 않은 것 같다. 생각보다 이 부분을 많은 회사가 놓치는 것 같기도 하고… “이 정도 규모에선 그런 걸 기대하긴 이제 어렵죠.” 라는 말을 너무 쉽게 꺼내는 것 같기도 하고… 여기까지 쓰고보니, 요즘 업계 상황을 보면 월급 안 밀리고, 안 잘리고, 퇴근할 때(!) 퇴근하는 거에 감사해야한다는 생각이 들었다.뭐가 문제의 원인인지 얼마나 시간이 흘러야 업계 상황이 나아질지, 나아지긴 할런지… 하고 생각이 들었다.좋은 회사, 건강한 회사, 행복한 IT 인들 많아지길…

`애플에서는 단순하게 일합니다.` 를 읽다가...

이메일로 앱을 만들어 달라는 요청을 받곤 합니다.
모두 거절합니다.

앱을 만든다는 것은 너무 피곤하고 고통스러운 일.
아마 요청하는 사람들은 이 피곤함을 잘 모를 겁니다.

이렇게 거절당한 사람들 중 앱 의뢰 시장에서 실패를 맛보고 온 사람들이 있습니다.
위시켓, 크몽 같은 앱 개발 의뢰 시장.

이런 시장에서 일상의 작은 불편함을 고쳐달라는 의뢰 정도는 괜찮은 것 같지만…
서비스라 불릴만한 것을 만들어 달라는 것은 좀 걱정스럽습니다.
과연 원하는 결과를 얻을 수 있을까?

건물주를 하면서 집수리 의뢰를 많이 해봤습니다.
내가 할 줄 모르는 일들을 의뢰할 때 스트레스를 많이 받았습니다.
과연 제대로 일을 해줄까? 눈탱이 맞는 건 아닐까?
결과가 맘에 들 때도 있고 맘에 안 들 때도 있었는데…
어쨌든 내 문제를 해결해 주긴 했습니다.

개발자 같은 경우에는 어떨까요?
기대했던 것과 너무 다른 결과물을 받아 들고는 실망하는 일이 비일비재할 겁니다.
문제를 해결했다고 말할 수 없는 결과물.

"내가 원했던 건 이게 아니라고."
"뭔 소리야, 난 개발 명세서에 쓰여있는 대로 만들었다고."

이런 경험을 해본 사람들이 믿고 개발 맡길 사람이 없다고 하소연하는 것.

어느 의뢰 시장에나 이런 문제가 있겠지만 개발 시장은 좀 더 미스매치가 심한 것 같습니다.
아마 의뢰하는 사람뿐 아니라 개발하는 사람도 스트레스를 많이 받을 겁니다.
서로의 생각을 일치시킨 채로 일을 시작하는 것 자체가 이 세계의 고난도 기술인 걸요.

하소연하는 의뢰인들에게 말합니다.
“공부해서 직접 앱을 만드시는 게 더 빠르지 않을까요?”

앱 하나를 온전히 만든다는 게 쉬운 일은 아니지만…
모르는 사람에게 부탁해서 원하는 앱을 갖게 되는 것 보다는 쉬울 것 같습니다.

이메일로 앱을 만들어 달라는 요청을 받곤 합니다. 모두 거절합니다. 앱을 만든다는 것은 너무 피곤하고 고통스러운 일. 아마 요청하는 사람들은 이 피곤함을 잘 모를 겁니다. 이렇게 거절당한 사람들 중 앱 의뢰 시장에서 실패를 맛보고 온 사람들이 있습니다. 위시켓, 크몽 같은 앱 개발 의뢰 시장. 이런 시장에서 일상의 작은 불편함을 고쳐달라는 의뢰 정도는 괜찮은 것 같지만… 서비스라 불릴만한 것을 만들어 달라는 것은 좀 걱정스럽습니다. 과연 원하는 결과를 얻을 수 있을까? 건물주를 하면서 집수리 의뢰를 많이 해봤습니다. 내가 할 줄 모르는 일들을 의뢰할 때 스트레스를 많이 받았습니다. 과연 제대로 일을 해줄까? 눈탱이 맞는 건 아닐까? 결과가 맘에 들 때도 있고 맘에 안 들 때도 있었는데… 어쨌든 내 문제를 해결해 주긴 했습니다. 개발자 같은 경우에는 어떨까요? 기대했던 것과 너무 다른 결과물을 받아 들고는 실망하는 일이 비일비재할 겁니다. 문제를 해결했다고 말할 수 없는 결과물. "내가 원했던 건 이게 아니라고." "뭔 소리야, 난 개발 명세서에 쓰여있는 대로 만들었다고." 이런 경험을 해본 사람들이 믿고 개발 맡길 사람이 없다고 하소연하는 것. 어느 의뢰 시장에나 이런 문제가 있겠지만 개발 시장은 좀 더 미스매치가 심한 것 같습니다. 아마 의뢰하는 사람뿐 아니라 개발하는 사람도 스트레스를 많이 받을 겁니다. 서로의 생각을 일치시킨 채로 일을 시작하는 것 자체가 이 세계의 고난도 기술인 걸요. 하소연하는 의뢰인들에게 말합니다. “공부해서 직접 앱을 만드시는 게 더 빠르지 않을까요?” 앱 하나를 온전히 만든다는 게 쉬운 일은 아니지만… 모르는 사람에게 부탁해서 원하는 앱을 갖게 되는 것 보다는 쉬울 것 같습니다.

앱 개발 의뢰 시장

01 . 의외로 세상에는 다작을 하는 크리에이터들이 많습니다. 이제는 일반적인 말이 되었지만 '영감이 떠오를 때까지 기다리지 말고, 작은 영감의 불씨라도 살리려 애를 써라'는 말은 위대한 작품들이 다작의 결과물로서 탄생함을 짚어주는 말이기도 하죠.
그래서 다작 작가들의 어록 또한 적지 않은데요, 미국의 대표적인 다작 작가인 소설가 '스티븐 킹'은 '크리스마스와 생일을 빼고는 매일 글을 쓴다'고 했고, 하도 글을 많이 써서 책공장이란 별명이 붙은 일본 작가 '히가시노 게이고'는 '작품을 쓴다는 생각으로 글을 쓰기보단, 글을 쓰다 보면 어느 순간 작품이 되어있더라'란 말로 유명합니다.

02 . 그중에서도 제가 가장 좋아하는 말은 2007년 노벨문학상 수상자인 영국 작가 '도리스 레싱'의 말입니다.
'나는 생산하는 삶을 사랑한다. 책을 읽는 것이 즐거우냐 아니면 쓰는 것이 즐거우냐고 묻는다면 나는 1초의 망설임도 없이 쓰는 것이라고 말한다. 책을 읽을 때는 누군가가 생산해 놓은 것을 소비한다는 느낌이지만 글을 쓸 때는 누군가의 소비를 위해 내가 직접 생산한다는 느낌이 들기 때문이다. 그러니 나의 모든 소비는 나의 생산을 위한 것이다.'

03 . 저는 이 말이 다작에 대한 노력을 새롭게 조명하게끔 해주었다고 생각합니다. 물론 세상의 모든 일을 소비와 생산으로 딱 구분 지어 바라보기는 어렵겠지만 우리 삶의 많은 부분은 소비에 초점이 맞춰져있는 것이 사실입니다. 특히 직장을 다니거나 학업을 하는 시간을 제외한 일상의 순간을 떠올려보면 이런 기억들은 더욱 또렷해지죠. 누군가가 만든 콘텐츠를 보거나, 누군가가 기획해놓은 공간에서 시간을 보내거나, 누군가가 마련한 경험에 몸을 맡기는 일은 대부분 소비의 측면으로 볼 수 있으니 말입니다.

04 . 한편으론 당연한 일일 수 있습니다. 내가 일하는 시간이 온전한 생산의 시간이었다면 그 외 일상은 소비를 하며 즐기는 게 밸런스가 맞는 삶이지 않냐고 되물을 수 있으니 말이죠. 특히 우리나라처럼 일터에서의 생산성에 높은 방점을 찍는 환경이라면 사실 회사에 다니거나 일을 하는 것만으로도 생산에 필요한 모든 에너지를 쏟아붓는다고 해도 과언이 아니거든요. 저도 사실 어떤 날은 세상 일을 모두 내가 다 한 것만 같은 지친 마음으로 퇴근하는 경우가 많으니까요.

05 . 하지만 저는 그럼에도 일상생활 속에서의 생산성을 확보하는 것도 참 중요한 포인트 중 하나라고 생각합니다. 그중에서도 더 중요한 건 내가 좋아하는 것들을 소비하는 수준에만 그치지 말고 새롭게 변형하거나 내가 직접 그 콘텐츠의 공급자가 되어봄으로써 또 하나의 생산 동력을 마련해 보는 것이죠. 뭐든 가장 가까운 것에서부터 시작하는 게 쉽고도 간편한 법이니까요.
제 주변만 해도 그런 분들이 의외로 적지 않습니다. 음식을 좋아하는 지인은 바쁜 일상 속에서도 직접 푸드 관련 뉴스레터를 제작해 양질의 콘텐츠를 제공하고 있고, 영화를 사랑하는 지인 한 분은 며칠 전 영화 콘텐츠를 소개하는 1인 팟캐스트를 시작했다고 하시더군요. 저는 이런 모든 시도가 엄연히 내 일상을 훨씬 더 애정 하게 만드는 긍정의 생산들이라고 생각합니다.

06 . 물론 이런 삶을 추천해도 두려움이 먼저 앞선다는 분들이 있습니다. 그리고 보통은 두 가지 이유를 들죠.
하나는 '나는 보는 것은 할 수 있는데 만드는 재주는 없다'는 겁니다. 아마 이 말을 듣고서는 '오! 나도 그런데!'라고 생각하는 분들도 많으실 거라고 봅니다. 하지만 이건 전제 자체가 잘못되었습니다. 저는 생산하는 삶을 강조했지 그 결과물이 최상의 수준을 갖춰야 한다거나 특별한 역량을 동원해 생산력을 발휘하라고 말씀드린 적이 없거든요. 아니 오히려 그런 마음으로 접근했다가는 며칠도 못가 쉽게 실망하고 포기하게 될 가능성이 더 큽니다. 그러니 '잘 하고 싶은 마음'은 버리고 '그냥 해보는 마음'을 가지는 게 생산적인 삶을 사는 첫 시작이라고 생각합니다.

07 . 다른 하나는 '한두 번은 해보겠는데 지속할 소스가 없다'는 겁니다. 이 말 역시 어떤 의미인지 잘 알고 있습니다. 예를 들어 맛집 블로그를 시작해 보겠다고 호기롭게 첫 포문을 열었는데 몇 개 포스트를 올리고 나니 왠지 다른 사람들이 다 간 곳만 재탕해서 리뷰하는 것 같고, 나만의 것을 찾자니 그건 또 한계가 있는 것 같고, 매번 비슷한 표현에 비슷한 문장들만 나열하고 있는 것 같고, 찍은 사진도 다 거기서 거기 같은 느낌이 드는 거죠. 그리고 이건 비단 블로그뿐 아니라 글이든 영상이든 음악이든 뭐든 간에 콘텐츠를 생산하는 사람들이 겪는 숙명의 고민과도 같습니다.

08 . 그러나 이럴 때일수록 큰 변화를 바라기보다 아주 작은 것들을 조금씩 바꿔간다는 생각으로 지속력을 발휘하는 게 좋습니다. '더 이상 새로울 게 없다'는 생각으로 쉽게 포기하지 말고 내 눈에 비슷하게 보이는 콘텐츠라도 계속 생산하면서 '뭔가 조금이나마 다르게 변주를 줄 부분이 없는지'를 찾는 게 디테일을 보완하는 나만의 역량으로 연결될 수 있기 때문입니다. 그러다 보면 의외의 순간에서 터지는 콘텐츠가 하나둘씩 발견되기 시작하고 어느 순간 콘텐츠를 생산하는 나의 능력 역시 쑥 성장하기 마련이니까요.

09 . 예전에 을지로에 있는 한 꼬리뼈찜 가게를 방문한 적이 있었는데요, 거기서 어느 나이 지긋하신 회사원 몇 분이 자리를 잡더니 이내 술을 주문하는 장면을 보게 되었습니다. 흔하디흔하게 볼 수 있는 술자리의 모습이었는데 그중 한 분께서 이런 말씀을 하시더군요.
"야. 오늘은 우리 생산적으로 마시자. 어제는 쓸데없는 얘기만 한가득했으니까 오늘은 다들 좋은 얘기, 도움 되는 얘기해."

10 . 저는 그 발상이 정말 신기하고도 재미있었습니다. 물론 중간중간 귀를 쫑긋 세웠을 땐 딱히 생산적인 대화인 것 같지 않은 말들이 오고 갔지만 그런 마음가짐으로 술자리를 시작하는 장면은 난생처음 보는 광경이었으니까요, 술도 생산적으로 마실 수 있겠구나 싶은 생각이 들었던 거죠.
'안 그래도 피곤한데 매사 생산적으로 살 필요가 있나' 싶으신 마음도 일견 이해하지만, 그렇다고 어디 소비하는 삶은 안 피곤한가요.... 사실 따지고 보면 소비든 생산이든 모두 에너지가 드는 일이고, 어떤 식으로든 나의 집중력과 몰입을 일정 부분 상납해야 하는 대상이라면 꼭 소비만 하며 살 필요는 없지 않을까요?
그러니 내일부터라도 작게나마 일상의 순간들을 조금이라도 더 생산적으로 바꿀 수 있는 뭔가를 찾아보는 노력을 해보는 건 어떨까 싶네요. 의외로 생산적인 삶이 우리의 인생을 더 재미난 방향으로 이끌어줄 수도 있을 테니까요.

01 . 의외로 세상에는 다작을 하는 크리에이터들이 많습니다. 이제는 일반적인 말이 되었지만 '영감이 떠오를 때까지 기다리지 말고, 작은 영감의 불씨라도 살리려 애를 써라'는 말은 위대한 작품들이 다작의 결과물로서 탄생함을 짚어주는 말이기도 하죠. 그래서 다작 작가들의 어록 또한 적지 않은데요, 미국의 대표적인 다작 작가인 소설가 '스티븐 킹'은 '크리스마스와 생일을 빼고는 매일 글을 쓴다'고 했고, 하도 글을 많이 써서 책공장이란 별명이 붙은 일본 작가 '히가시노 게이고'는 '작품을 쓴다는 생각으로 글을 쓰기보단, 글을 쓰다 보면 어느 순간 작품이 되어있더라'란 말로 유명합니다. 02 . 그중에서도 제가 가장 좋아하는 말은 2007년 노벨문학상 수상자인 영국 작가 '도리스 레싱'의 말입니다. '나는 생산하는 삶을 사랑한다. 책을 읽는 것이 즐거우냐 아니면 쓰는 것이 즐거우냐고 묻는다면 나는 1초의 망설임도 없이 쓰는 것이라고 말한다. 책을 읽을 때는 누군가가 생산해 놓은 것을 소비한다는 느낌이지만 글을 쓸 때는 누군가의 소비를 위해 내가 직접 생산한다는 느낌이 들기 때문이다. 그러니 나의 모든 소비는 나의 생산을 위한 것이다.' 03 . 저는 이 말이 다작에 대한 노력을 새롭게 조명하게끔 해주었다고 생각합니다. 물론 세상의 모든 일을 소비와 생산으로 딱 구분 지어 바라보기는 어렵겠지만 우리 삶의 많은 부분은 소비에 초점이 맞춰져있는 것이 사실입니다. 특히 직장을 다니거나 학업을 하는 시간을 제외한 일상의 순간을 떠올려보면 이런 기억들은 더욱 또렷해지죠. 누군가가 만든 콘텐츠를 보거나, 누군가가 기획해놓은 공간에서 시간을 보내거나, 누군가가 마련한 경험에 몸을 맡기는 일은 대부분 소비의 측면으로 볼 수 있으니 말입니다. 04 . 한편으론 당연한 일일 수 있습니다. 내가 일하는 시간이 온전한 생산의 시간이었다면 그 외 일상은 소비를 하며 즐기는 게 밸런스가 맞는 삶이지 않냐고 되물을 수 있으니 말이죠. 특히 우리나라처럼 일터에서의 생산성에 높은 방점을 찍는 환경이라면 사실 회사에 다니거나 일을 하는 것만으로도 생산에 필요한 모든 에너지를 쏟아붓는다고 해도 과언이 아니거든요. 저도 사실 어떤 날은 세상 일을 모두 내가 다 한 것만 같은 지친 마음으로 퇴근하는 경우가 많으니까요. 05 . 하지만 저는 그럼에도 일상생활 속에서의 생산성을 확보하는 것도 참 중요한 포인트 중 하나라고 생각합니다. 그중에서도 더 중요한 건 내가 좋아하는 것들을 소비하는 수준에만 그치지 말고 새롭게 변형하거나 내가 직접 그 콘텐츠의 공급자가 되어봄으로써 또 하나의 생산 동력을 마련해 보는 것이죠. 뭐든 가장 가까운 것에서부터 시작하는 게 쉽고도 간편한 법이니까요. 제 주변만 해도 그런 분들이 의외로 적지 않습니다. 음식을 좋아하는 지인은 바쁜 일상 속에서도 직접 푸드 관련 뉴스레터를 제작해 양질의 콘텐츠를 제공하고 있고, 영화를 사랑하는 지인 한 분은 며칠 전 영화 콘텐츠를 소개하는 1인 팟캐스트를 시작했다고 하시더군요. 저는 이런 모든 시도가 엄연히 내 일상을 훨씬 더 애정 하게 만드는 긍정의 생산들이라고 생각합니다. 06 . 물론 이런 삶을 추천해도 두려움이 먼저 앞선다는 분들이 있습니다. 그리고 보통은 두 가지 이유를 들죠.하나는 '나는 보는 것은 할 수 있는데 만드는 재주는 없다'는 겁니다. 아마 이 말을 듣고서는 '오! 나도 그런데!'라고 생각하는 분들도 많으실 거라고 봅니다. 하지만 이건 전제 자체가 잘못되었습니다. 저는 생산하는 삶을 강조했지 그 결과물이 최상의 수준을 갖춰야 한다거나 특별한 역량을 동원해 생산력을 발휘하라고 말씀드린 적이 없거든요. 아니 오히려 그런 마음으로 접근했다가는 며칠도 못가 쉽게 실망하고 포기하게 될 가능성이 더 큽니다. 그러니 '잘 하고 싶은 마음'은 버리고 '그냥 해보는 마음'을 가지는 게 생산적인 삶을 사는 첫 시작이라고 생각합니다. 07 . 다른 하나는 '한두 번은 해보겠는데 지속할 소스가 없다'는 겁니다. 이 말 역시 어떤 의미인지 잘 알고 있습니다. 예를 들어 맛집 블로그를 시작해 보겠다고 호기롭게 첫 포문을 열었는데 몇 개 포스트를 올리고 나니 왠지 다른 사람들이 다 간 곳만 재탕해서 리뷰하는 것 같고, 나만의 것을 찾자니 그건 또 한계가 있는 것 같고, 매번 비슷한 표현에 비슷한 문장들만 나열하고 있는 것 같고, 찍은 사진도 다 거기서 거기 같은 느낌이 드는 거죠. 그리고 이건 비단 블로그뿐 아니라 글이든 영상이든 음악이든 뭐든 간에 콘텐츠를 생산하는 사람들이 겪는 숙명의 고민과도 같습니다. 08 . 그러나 이럴 때일수록 큰 변화를 바라기보다 아주 작은 것들을 조금씩 바꿔간다는 생각으로 지속력을 발휘하는 게 좋습니다. '더 이상 새로울 게 없다'는 생각으로 쉽게 포기하지 말고 내 눈에 비슷하게 보이는 콘텐츠라도 계속 생산하면서 '뭔가 조금이나마 다르게 변주를 줄 부분이 없는지'를 찾는 게 디테일을 보완하는 나만의 역량으로 연결될 수 있기 때문입니다. 그러다 보면 의외의 순간에서 터지는 콘텐츠가 하나둘씩 발견되기 시작하고 어느 순간 콘텐츠를 생산하는 나의 능력 역시 쑥 성장하기 마련이니까요. 09 . 예전에 을지로에 있는 한 꼬리뼈찜 가게를 방문한 적이 있었는데요, 거기서 어느 나이 지긋하신 회사원 몇 분이 자리를 잡더니 이내 술을 주문하는 장면을 보게 되었습니다. 흔하디흔하게 볼 수 있는 술자리의 모습이었는데 그중 한 분께서 이런 말씀을 하시더군요."야. 오늘은 우리 생산적으로 마시자. 어제는 쓸데없는 얘기만 한가득했으니까 오늘은 다들 좋은 얘기, 도움 되는 얘기해." 10 . 저는 그 발상이 정말 신기하고도 재미있었습니다. 물론 중간중간 귀를 쫑긋 세웠을 땐 딱히 생산적인 대화인 것 같지 않은 말들이 오고 갔지만 그런 마음가짐으로 술자리를 시작하는 장면은 난생처음 보는 광경이었으니까요, 술도 생산적으로 마실 수 있겠구나 싶은 생각이 들었던 거죠.'안 그래도 피곤한데 매사 생산적으로 살 필요가 있나' 싶으신 마음도 일견 이해하지만, 그렇다고 어디 소비하는 삶은 안 피곤한가요.... 사실 따지고 보면 소비든 생산이든 모두 에너지가 드는 일이고, 어떤 식으로든 나의 집중력과 몰입을 일정 부분 상납해야 하는 대상이라면 꼭 소비만 하며 살 필요는 없지 않을까요? 그러니 내일부터라도 작게나마 일상의 순간들을 조금이라도 더 생산적으로 바꿀 수 있는 뭔가를 찾아보는 노력을 해보는 건 어떨까 싶네요. 의외로 생산적인 삶이 우리의 인생을 더 재미난 방향으로 이끌어줄 수도 있을 테니까요.

이왕이면 '생산적인 일상'이 낫지

SVGR - Transforms SVG into React Components. - SVGR

SVGR은 SVG(Scalable Vector Graphics) 파일을 React 컴포넌트로 변환하는 도구입니다. SVG 파일은 웹사이트에서 이미지를 표시하는 한 방법인데요. 크기를 늘리거나 줄여도 선명한 상태를 유지할 수 있는 이미지 파일입니다. SVGR을 사용하면 이 SVG 파일을 React 애플리케이션에서 쉽게 사용할 수 있는 컴포넌트로 바꿀 수 있습니다. 즉, SVG 파일을 가져와서 React 코드 안에서 바로 사용할 수 있게 도와주는 도구입니다.

 1. SVG 파일을 React 컴포넌트로 변환: SVGR은 SVG 파일을 React 컴포넌트로 변환하여 코드 내에서 직접 사용할 수 있도록 합니다. 이렇게 하면 SVG 파일을 React 코드 안에 포함시키고, 필요할 때마다 사용할 수 있습니다.
 2. SVG 최적화: SVGR은 SVG 파일을 최적화하여 파일 크기를 줄이고 로드 시간을 단축시킵니다. 최적화된 파일은 웹사이트를 빠르게 로드할 수 있게 도와줍니다.
 3. 사용자 정의 설정: SVGR은 다양한 설정 옵션을 제공하여 변환 과정을 사용자에 맞게 조정할 수 있습니다. 예를 들어, 특정 속성을 유지하거나 제거하는 등의 설정을 할 수 있습니다.
 4. 플러그인 및 API 지원: SVGR은 Webpack, Rollup 등의 번들러와 함께 사용할 수 있는 플러그인 및 CLI(Command Line Interface) 도구를 제공합니다. 이를 통해 프로젝트에 쉽게 통합할 수 있습니다.

주의사항: viewBox 속성
SVG 파일에는
viewBox
라는 속성이 있습니다.
viewBox
는 SVG 이미지의 크기와 비율을 제어하는 데 사용되는데요. 이 속성이 있어야 이미지를 화면 크기에 맞게 조정할 수 있습니다. 그러나 SVGR의 기본 설정에서는 최적화를 위해
viewBox
속성을 자동으로 제거가 됩니다. 이렇게 되면 SVG 이미지 크기를 키웠을 때 퀄리티가 유지되지 않을수 있습니다. 즉 벡터 그래픽의 가장 큰 장점인 크기에 상관없이 선명한 화질을 유지하는 기능이 사라지는 것인데요.
이미지의 퀄리티가 중요하다면,
viewBox
속성을 유지하는 것이 좋습니다. 따라서 Webpack 설정에서
removeViewBox: false
로 설정하는것을 추천드립니다.

https://react-svgr.com/

SVGR은 SVG(Scalable Vector Graphics) 파일을 React 컴포넌트로 변환하는 도구입니다. SVG 파일은 웹사이트에서 이미지를 표시하는 한 방법인데요. 크기를 늘리거나 줄여도 선명한 상태를 유지할 수 있는 이미지 파일입니다. SVGR을 사용하면 이 SVG 파일을 React 애플리케이션에서 쉽게 사용할 수 있는 컴포넌트로 바꿀 수 있습니다. 즉, SVG 파일을 가져와서 React 코드 안에서 바로 사용할 수 있게 도와주는 도구입니다. <ol ><li>SVG 파일을 React 컴포넌트로 변환: SVGR은 SVG 파일을 React 컴포넌트로 변환하여 코드 내에서 직접 사용할 수 있도록 합니다. 이렇게 하면 SVG 파일을 React 코드 안에 포함시키고, 필요할 때마다 사용할 수 있습니다.</li><li>SVG 최적화: SVGR은 SVG 파일을 최적화하여 파일 크기를 줄이고 로드 시간을 단축시킵니다. 최적화된 파일은 웹사이트를 빠르게 로드할 수 있게 도와줍니다.</li><li>사용자 정의 설정: SVGR은 다양한 설정 옵션을 제공하여 변환 과정을 사용자에 맞게 조정할 수 있습니다. 예를 들어, 특정 속성을 유지하거나 제거하는 등의 설정을 할 수 있습니다.</li><li>플러그인 및 API 지원: SVGR은 Webpack, Rollup 등의 번들러와 함께 사용할 수 있는 플러그인 및 CLI(Command Line Interface) 도구를 제공합니다. 이를 통해 프로젝트에 쉽게 통합할 수 있습니다.</li></ol> 주의사항: viewBox 속성SVG 파일에는 <code >viewBox</code>라는 속성이 있습니다. <code >viewBox</code>는 SVG 이미지의 크기와 비율을 제어하는 데 사용되는데요. 이 속성이 있어야 이미지를 화면 크기에 맞게 조정할 수 있습니다. 그러나 SVGR의 기본 설정에서는 최적화를 위해 <code >viewBox</code> 속성을 자동으로 제거가 됩니다. 이렇게 되면 SVG 이미지 크기를 키웠을 때 퀄리티가 유지되지 않을수 있습니다. 즉 벡터 그래픽의 가장 큰 장점인 크기에 상관없이 선명한 화질을 유지하는 기능이 사라지는 것인데요.이미지의 퀄리티가 중요하다면, <code >viewBox</code> 속성을 유지하는 것이 좋습니다. 따라서 Webpack 설정에서 <code >removeViewBox: false</code>로 설정하는것을 추천드립니다. https://react-svgr.com/

React-svgr

SVGR로 SVG를 React에 통합: viewBox 속성의 중요

트위터에 시간관리 방법을 잘 정리해둔 글이 있어서 공유드립니다.
시간을 어떻게 사용할지에 대해서는 많은 사람들이 만든 테크닉들이 있는데요.
그런 다양한 시간 관리 방법의 핵심만 빼내서 이미지 한장에 정리해두었네요!

정리해둔 방법들은 아래와 같습니다.
여러분에게 맞는 방법을 찾아서 실행해보시는건 어떨까요?

 * Pomodoro Technique
   * 작업 계획하기 (Plan your tasks)
   * 1개의 포모도로 실행하기
   * 4개의 포모도로 반복 후 긴 휴식 취하기
 * 2 Minute Rule
   * 2분 이하로 걸리는 작업은 즉시 실행하기
 * Eliminate Multitasking
   * 하나의 작업에 집중하기
 * Eat That Frog
   * 가장 어려운 작업을 하루의 첫 번째로 수행하기
 * 80/20 Rule (팔레토 법칙)
   * 20%의 노력으로 80%의 결과를 얻기 위해 중요한 작업에 집중하기
 * Eisenhower Matrix
   * 긴급하고 중요한 작업: 실행 (Do)
   * 긴급하지 않지만 중요한 작업: 일정 잡기 (Schedule)
   * 긴급하지만 중요하지 않은 작업: 위임 (Delegate)
   * 긴급하지도 중요하지도 않은 작업: 삭제 (Delete)
 * Time Blocking
   * 시간을 블록으로 나누어 특정 작업에 할당하기
   * 블록 시간 동안 다른 일을 하지 않기
     * 예시:
       * 8:00 - 11:00: 집중 작업 (Deep Work)
       * 11:00 - 11:30: 이메일 확인 (Do Emails)
       * 11:30 - 12:30: 점심시간 (Lunch Break)
       * 12:30 - 2:00: 중요한 작업 2개 (2 Urgent Tasks)
       * 2:00 - 3:00: 휴식시간 (Take Break)
       * 3:00 - 5:00: 약속 (Appointments)
 * 3-3-3 Rule
   * 가장 중요한 프로젝트에 3시간 투자하기
   * 3개의 짧은 작업 수행하기
   * 3개의 유지 관리 작업 수행하기
 * Getting Things Done (GTD)
   * GTD 방법의 5단계:
     * Step 1: 캡처 (Capture)
     * Step 2: 명확히 하기 (Clarify)
     * Step 3: 조직화 (Organize)
     * Step 4: 반성 (Reflect)
     * Step 5: 참여 (Engage)

출처 : https://x.com/milan_milanovic/status/1799782855075381625

트위터에 시간관리 방법을 잘 정리해둔 글이 있어서 공유드립니다.시간을 어떻게 사용할지에 대해서는 많은 사람들이 만든 테크닉들이 있는데요.그런 다양한 시간 관리 방법의 핵심만 빼내서 이미지 한장에 정리해두었네요! 정리해둔 방법들은 아래와 같습니다.여러분에게 맞는 방법을 찾아서 실행해보시는건 어떨까요? <ul ><li>Pomodoro Technique<ul ><li>작업 계획하기 (Plan your tasks)</li><li>1개의 포모도로 실행하기</li><li>4개의 포모도로 반복 후 긴 휴식 취하기</li></ul></li><li>2 Minute Rule<ul ><li>2분 이하로 걸리는 작업은 즉시 실행하기</li></ul></li><li>Eliminate Multitasking<ul ><li>하나의 작업에 집중하기</li></ul></li><li>Eat That Frog<ul ><li>가장 어려운 작업을 하루의 첫 번째로 수행하기</li></ul></li><li>80/20 Rule (팔레토 법칙)<ul ><li>20%의 노력으로 80%의 결과를 얻기 위해 중요한 작업에 집중하기</li></ul></li><li>Eisenhower Matrix<ul ><li>긴급하고 중요한 작업: 실행 (Do)</li><li>긴급하지 않지만 중요한 작업: 일정 잡기 (Schedule)</li><li>긴급하지만 중요하지 않은 작업: 위임 (Delegate)</li><li>긴급하지도 중요하지도 않은 작업: 삭제 (Delete)</li></ul></li><li>Time Blocking<ul ><li>시간을 블록으로 나누어 특정 작업에 할당하기</li><li>블록 시간 동안 다른 일을 하지 않기<ul ><li>예시:<ul ><li>8:00 - 11:00: 집중 작업 (Deep Work)</li><li>11:00 - 11:30: 이메일 확인 (Do Emails)</li><li>11:30 - 12:30: 점심시간 (Lunch Break)</li><li>12:30 - 2:00: 중요한 작업 2개 (2 Urgent Tasks)</li><li>2:00 - 3:00: 휴식시간 (Take Break)</li><li>3:00 - 5:00: 약속 (Appointments)</li></ul></li></ul></li></ul></li><li>3-3-3 Rule<ul ><li>가장 중요한 프로젝트에 3시간 투자하기</li><li>3개의 짧은 작업 수행하기</li><li>3개의 유지 관리 작업 수행하기</li></ul></li><li>Getting Things Done (GTD)<ul ><li>GTD 방법의 5단계:<ul ><li>Step 1: 캡처 (Capture)</li><li>Step 2: 명확히 하기 (Clarify)</li><li>Step 3: 조직화 (Organize)</li><li>Step 4: 반성 (Reflect)</li><li>Step 5: 참여 (Engage)</li></ul></li></ul></li></ul> 출처 : https://x.com/milan_milanovic/status/1799782855075381625

내게 맞는 시간 관리 방법을 찾자

IIllllllIII - IlIIlllIllllIIIllIIlIlllIlllllIIllllIlll

모든 URL을 I/l(I 대문자 와 L의 소문자 l) 만 사용해서 만드는 서비스인데요..!
블라인드의 바코드 닉네임들이 떠오르는군요..ㅋㅋㅋㅋ

물론 코드로 뜯어보면 바로 다시 해독할 수 있겠지만 재밌는 아이디어 같아요 ㅋㅋㅋ

https://llili.li/

모든 URL을 I/l(I 대문자 와 L의 소문자 l) 만 사용해서 만드는 서비스인데요..!블라인드의 바코드 닉네임들이 떠오르는군요..ㅋㅋㅋㅋ 물론 코드로 뜯어보면 바로 다시 해독할 수 있겠지만 재밌는 아이디어 같아요 ㅋㅋㅋ https://llili.li/

llili.li

url을 못 알아보는 단축 url로 만들어주는 재미난 서비스

Socket.IO 기본 사용법

실시간 양방향 통신을 위해서 웹소켓(WebSocket)이 표준이 된지가 꽤 되었고, 현재 대부분의 모던 브라우저에서 웹소켓 API를 지원하고 있습니다. 하지만 여전히 우리는 모든 사용자가 최신 브라우저를 사용한다고 단정할 수 없으며, 웹소켓이 지원되지는 않는 환경에서는 어쩔 수 없이 대안 기술을 사용해야 하죠.

Socket.IO는 이런 호환성 부분에 대해서 개발자가 크게 걱정할 필요없이 실시간 양방향 통신을 하는 웹 애플리케이션을 작성할 수 있도록 도와주는 라이브러리입니다. 이번 포스팅에서는 간단한 실습을 통해서 Socket.IO를 기본적으로 어떻게 사용하는지 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/socket-io/
🧑‍💻 실습 코드: https://codesandbox.io/p/devbox/nostalgic-gianmarco-v2m5yx

웹소켓(WebSocket)에 대해서 기본 개념을 먼저 잡으시고 싶으시다면 아래 게시물을 추천드립니다.
📕 실시간 양방향 통신을 위한 웹소켓(WebSocket): https://careerly.co.kr/comments/105820

실시간 양방향 통신을 위해서 웹소켓(WebSocket)이 표준이 된지가 꽤 되었고, 현재 대부분의 모던 브라우저에서 웹소켓 API를 지원하고 있습니다. 하지만 여전히 우리는 모든 사용자가 최신 브라우저를 사용한다고 단정할 수 없으며, 웹소켓이 지원되지는 않는 환경에서는 어쩔 수 없이 대안 기술을 사용해야 하죠. Socket.IO는 이런 호환성 부분에 대해서 개발자가 크게 걱정할 필요없이 실시간 양방향 통신을 하는 웹 애플리케이션을 작성할 수 있도록 도와주는 라이브러리입니다. 이번 포스팅에서는 간단한 실습을 통해서 Socket.IO를 기본적으로 어떻게 사용하는지 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/socket-io/🧑‍💻 실습 코드: https://codesandbox.io/p/devbox/nostalgic-gianmarco-v2m5yx 웹소켓(WebSocket)에 대해서 기본 개념을 먼저 잡으시고 싶으시다면 아래 게시물을 추천드립니다.📕 실시간 양방향 통신을 위한 웹소켓(WebSocket): https://careerly.co.kr/comments/105820

1-on-1과 개인적 관심을 통해 잘 가르쳐주고 싶지만, 이를 거부하는 팀원들에 의해 점점 위축되어가는 부장님들도 있다.

새로운 기술이 나왔으니 공부해보면 좋겠다며 자료를 전달해주거나 책을 선물해 주었더니, 업무냐며 업무라면 정식으로 업무 요청을 해 달라던 이야기가 생각난다.

이 이야기는 한 번 들었던 것이 아니라 세미나에 오셨던 여러 회사의 여러 부장(팀장)님들에 걸쳐 반복적으로 들었던 이야기다.

진짜 꼰대적 상황이 있기도 하겠지만, 부장님들의 진심과 고충도 이해해주면 좋을 것 같다.

1-on-1과 개인적 관심을 통해 잘 가르쳐주고 싶지만, 이를 거부하는 팀원들에 의해 점점 위축되어가는 부장님들도 있다. 새로운 기술이 나왔으니 공부해보면 좋겠다며 자료를 전달해주거나 책을 선물해 주었더니, 업무냐며 업무라면 정식으로 업무 요청을 해 달라던 이야기가 생각난다. 이 이야기는 한 번 들었던 것이 아니라 세미나에 오셨던 여러 회사의 여러 부장(팀장)님들에 걸쳐 반복적으로 들었던 이야기다. 진짜 꼰대적 상황이 있기도 하겠지만, 부장님들의 진심과 고충도 이해해주면 좋을 것 같다.

1-on-1과 개인적 관심을 통해 잘 가르쳐주고 싶지만, 이를 거

오늘은 꼭 헬스장 가야지! 오늘은 덜 먹어야지! 오늘은 뇌과학자 장동선 박사님과 함께 한다고 해놓고 실천하기 힘든 사람과 의지력이 강한 사람은 뇌과학적으로 어떻게 다른지 알아봤습니다 배우는 즐거움이 있는 본격 취미 탐구 라이프 채널!

😩 한다고 해놓고 왜 안할까? 실천력 강한 사람의 뇌과학적 비밀? | 🧠 AMCC, 자제력, 미라클모닝 @CuriousBrainLab

 * 요즘 자기 계발 파트에서 뇌과학과 접목을 많이 시킴
   * 어설프게 뇌과학을 성공 법칙에 붙이면 안됨
   * 대부분 우리가 원하는 것의 정답은 우리가 알고 있음. 그것을 알면서 행동이 따라지지 않는 것
 * 성공하는 사람들의 3가지 능력
   * 절제력 : 안하려는 것을 안하는 능력
   * 행동력 : 한다면 한다
   * 이성적 : 판단하고 생각한 것을 따라감
 * 참을성과 행동력을 담당하는 뇌 부분은?
   * 전두엽. 전전두엽, 전두엽에서 감정 조절 & 통제
     * 청소년기에 이게 덜 발달됨
     * 전두엽 발달은 20대 초중반 완성
   * 전두엽에서 나가는 신호, 들어오는 신호가 들어오는 통로. AMCC
     * 하기 싫은데 해내야 하는 것을 하면, AMCC 영역이 더 두꺼워짐
     * 감정 제어, 충동 제어하는 파트
 * 도파민의 보상회로
   * 통제 회로. 중피질 회로
     * 하기 싫은데 하려면 동기부여가 되어야 함.
     * 다른 도파민 회로 사용법
     * 우리는 게임을 할 때 재밌다!라고 하는데 프로게이머는 통제 회로를 사용해서 분석하고 집중함
   * 짧은 경로 : 욕망 회로
 * AMCC를 발달시킬 수 있는 행동과 마음가짐
   * 내적 동기 : 성장, 즐거움, 열정 등
   * 팁
     * 스스로에게 함정 파놓기. 안하면 안되도록 환경 만들기
     * 시작이 어렵지 시작하면 재밌음
 * 성공한 사람들의 공통점
   * 목표를 위해 멈추지 않는 꾸준함
   * 그 안에서 실행하기
   * 눈 앞의 쾌락이 아닌 노력하며 얻는 기쁨
   * 꾸준하게 하는 것은 뇌의 가능성을 키우는 일

https://youtu.be/nWhFw9sb-Ak?si=U62l1BxDlFNGtxsx

<ul ><li>요즘 자기 계발 파트에서 뇌과학과 접목을 많이 시킴<ul ><li>어설프게 뇌과학을 성공 법칙에 붙이면 안됨</li><li>대부분 우리가 원하는 것의 정답은 우리가 알고 있음. 그것을 알면서 행동이 따라지지 않는 것</li></ul></li><li>성공하는 사람들의 3가지 능력<ul ><li>절제력 : 안하려는 것을 안하는 능력</li><li>행동력 : 한다면 한다</li><li>이성적 : 판단하고 생각한 것을 따라감</li></ul></li><li>참을성과 행동력을 담당하는 뇌 부분은?<ul ><li>전두엽. 전전두엽, 전두엽에서 감정 조절 &amp; 통제<ul ><li>청소년기에 이게 덜 발달됨</li><li>전두엽 발달은 20대 초중반 완성</li></ul></li><li>전두엽에서 나가는 신호, 들어오는 신호가 들어오는 통로. AMCC<ul ><li>하기 싫은데 해내야 하는 것을 하면, AMCC 영역이 더 두꺼워짐</li><li>감정 제어, 충동 제어하는 파트</li></ul></li></ul></li><li>도파민의 보상회로<ul ><li>통제 회로. 중피질 회로<ul ><li>하기 싫은데 하려면 동기부여가 되어야 함.</li><li>다른 도파민 회로 사용법</li><li>우리는 게임을 할 때 재밌다!라고 하는데 프로게이머는 통제 회로를 사용해서 분석하고 집중함</li></ul></li><li>짧은 경로 : 욕망 회로</li></ul></li><li>AMCC를 발달시킬 수 있는 행동과 마음가짐<ul ><li>내적 동기 : 성장, 즐거움, 열정 등</li><li>팁<ul ><li>스스로에게 함정 파놓기. 안하면 안되도록 환경 만들기</li><li>시작이 어렵지 시작하면 재밌음</li></ul></li></ul></li><li>성공한 사람들의 공통점<ul ><li>목표를 위해 멈추지 않는 꾸준함</li><li>그 안에서 실행하기</li><li>눈 앞의 쾌락이 아닌 노력하며 얻는 기쁨</li><li>꾸준하게 하는 것은 뇌의 가능성을 키우는 일</li></ul></li></ul> https://youtu.be/nWhFw9sb-Ak?si=U62l1BxDlFNGtxsx

YouTube

한다고 해놓고 왜 안할까? 실천력 강한 사람의 뇌과학적 비밀

23년 7월 GitHub은 저장소에 적용할 수 있는 [저장소 규칙(Repository Rules)](https://github.blog/2023-07-24-github-repository-rules-are-now-generally-available/) 기능을 정식으로 공개했다. 협업하다...

GitHub의 조직차원에서 저장소에 적용할 규칙을 관리할 수 있는 Repository Rules :: Outsider's Dev Story

GitHub을 회사에서 협업을 하다보면 협업을 쉽게 하기 위해서 꽤 많은 규칙을 만들게 됩니다. 대표적으로는 Pull Request 위주로 작업하기 위해 main 브랜치에 직접 푸시하는 걸 막는 등의 규칙이 있습니다.

이런 부분은 각 저장소는 협업자끼리 결정하면 되지만 회사가 커지고 저장소도 많아지면 조직 차원에서의 관리가 필요해지게 됩니다. 이는 어떤 안정장치일 수도 있고 약속된 관례를 일관되게 적용되도록 하는 규칙일 수도 있습니다.

아무래도 인프라 조직에 있다보니 인프라 뿐만 아니라 개발에서 가장 중요한 플랫폼 중 하나인 GitHub의 관리에 대한 부분도 관심이 많이 갔고 GitHub을 제어할 수 없으면 다른 부분도 제어하기 어렵다는 문제가 있습니다.

이런 문제를 어떻게 해결하면 좋을지 고민했는데 작년에 GitHub에서 내놓은 Repository Rules 기능이 이 문제를 해결하기 위한 기능이라는 것을 깨닫고 (이제서야) 어떤 기능인지 정리해 봤습니다.

https://blog.outsider.ne.kr/1724

GitHub을 회사에서 협업을 하다보면 협업을 쉽게 하기 위해서 꽤 많은 규칙을 만들게 됩니다. 대표적으로는 Pull Request 위주로 작업하기 위해 main 브랜치에 직접 푸시하는 걸 막는 등의 규칙이 있습니다. 이런 부분은 각 저장소는 협업자끼리 결정하면 되지만 회사가 커지고 저장소도 많아지면 조직 차원에서의 관리가 필요해지게 됩니다. 이는 어떤 안정장치일 수도 있고 약속된 관례를 일관되게 적용되도록 하는 규칙일 수도 있습니다. 아무래도 인프라 조직에 있다보니 인프라 뿐만 아니라 개발에서 가장 중요한 플랫폼 중 하나인 GitHub의 관리에 대한 부분도 관심이 많이 갔고 GitHub을 제어할 수 없으면 다른 부분도 제어하기 어렵다는 문제가 있습니다. 이런 문제를 어떻게 해결하면 좋을지 고민했는데 작년에 GitHub에서 내놓은 Repository Rules 기능이 이 문제를 해결하기 위한 기능이라는 것을 깨닫고 (이제서야) 어떤 기능인지 정리해 봤습니다. https://blog.outsider.ne.kr/1724

Outsider's Dev Story

이야 이런거 정말 좋네요 감사합니다

모던 애자일 백엔드

조영은

LG CNS 소프트웨어 아키텍트

seongmo

휴맥스 SW 엔지니어

이진(JIN)

개발자

안승원

Java/ASP 개발자

웹 개발자

Java 개발자

여행 서비스 백엔드 및 프론트엔드 개발, 인프라 관리

시니어 웹 개발자

시니어 소프트웨어 엔지니어

javascript

Kubernetes

React

typescript

Next.js

Node.js

Github

Argo CD

프론트엔드, 백엔드, 모바일 개발팀을 리드하며 OTT 서비스 개발

개발팀 Lead

컴퓨터학과

Outsider

블로그

트위터

오픈소스를 좋아하는 개발자로 종종 블로그에 글을 쓰고 있습니다. 현재는 인프라 관련 일을 하고 있으며 새로운 트랜드를 파악하는 걸 즐겨하고 즐겁게 코딩하는걸 좋아합니다.

댓글 1

비슷한 게시물

주간 인기 TOP 10

추천 프로필