YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

저는 아직 사용해보지 못했습니다. 정확히는 담당하고 있는 앱이나 개인 앱을 6로 전환하지 않았죠 아직.

Swift 4에서 5로 전환 했을 때를 생각해보면 뭔가 특별하게 바꾼게 기억나진 않네요

새로운게 나오면 써보고 싶지만 실제 프로젝트에 적용해 볼 수는 없어서 포기하고 있다가 막상 나중에 어떤 이유로든 도구나 제한 OS를 업그레이드 해서 사용할 수 있게되면 빌드 오류만 잊고 사용하게 되죠.

이 글은 Apple의 조금 오래된 Swift5를 사용하는 예제를 Swift6로 전환했을 때 발생하는 오류들을 해결하는 방법에 대해서 알려줍니다.

많이 알려진 것 처럼 Swift 6에서는 Concurrency가 많이 바뀌어서 대부분 그것과 관련된 오류 입니다.

Sendable과 MainActor가 거의 모든걸 해결 하는 것 같네요

여러분은 어떤 버전의 Swift를 사용하고 계신가요?

사실 어제 녹화했는데 마이크가 제대로 안꽂혀있어서 오늘 다시했어요 ㅠㅠ

https://youtu.be/GFVPsm2LnI8

저는 아직 사용해보지 못했습니다. 정확히는 담당하고 있는 앱이나 개인 앱을 6로 전환하지 않았죠 아직. Swift 4에서 5로 전환 했을 때를 생각해보면 뭔가 특별하게 바꾼게 기억나진 않네요 새로운게 나오면 써보고 싶지만 실제 프로젝트에 적용해 볼 수는 없어서 포기하고 있다가 막상 나중에 어떤 이유로든 도구나 제한 OS를 업그레이드 해서 사용할 수 있게되면 빌드 오류만 잊고 사용하게 되죠. 이 글은 Apple의 조금 오래된 Swift5를 사용하는 예제를 Swift6로 전환했을 때 발생하는 오류들을 해결하는 방법에 대해서 알려줍니다. 많이 알려진 것 처럼 Swift 6에서는 Concurrency가 많이 바뀌어서 대부분 그것과 관련된 오류 입니다. Sendable과 MainActor가 거의 모든걸 해결 하는 것 같네요 여러분은 어떤 버전의 Swift를 사용하고 계신가요? 사실 어제 녹화했는데 마이크가 제대로 안꽂혀있어서 오늘 다시했어요 ㅠㅠ https://youtu.be/GFVPsm2LnI8

youtu.be

Swift 6를 사용해보셨나요?

제가 담당하고 있는 앱은 오래된 소스라 Widget만 SwiftUI로 되어있는데요.

SwiftUI가 좋다고는 하지만 여전히 모든 것을 해결하지는 못해서 Bridge가 필요하기도 한 것 같네요.

이 글은 SwiftUI와 UIKit의 장/단점을 비교하고 여전히 UIkit을 사용할 수 밖에 없는 이유에 대해서도 짚어줍니다.

UIKit은 원래 Objective-C를 위해 만들어진 것이라 최신 Swift에서 지원하는 신규 기능들을 사용할 수 없는 단점이 있다네요

여러분은 뭘로 개발하고 계신가요?

https://youtu.be/jQpNvs1CaGM

제가 담당하고 있는 앱은 오래된 소스라 Widget만 SwiftUI로 되어있는데요. SwiftUI가 좋다고는 하지만 여전히 모든 것을 해결하지는 못해서 Bridge가 필요하기도 한 것 같네요. 이 글은 SwiftUI와 UIKit의 장/단점을 비교하고 여전히 UIkit을 사용할 수 밖에 없는 이유에 대해서도 짚어줍니다. UIKit은 원래 Objective-C를 위해 만들어진 것이라 최신 Swift에서 지원하는 신규 기능들을 사용할 수 없는 단점이 있다네요 여러분은 뭘로 개발하고 계신가요? https://youtu.be/jQpNvs1CaGM

아직 UIKit을 사용하고 계시나요?

Get a Free System Design PDF with 158 pages by subscribing to our weekly newsletter: https://bit.ly/bytebytegoytTopic Animation tools: Adobe Illustrator and After Effects. Checkout our bestselling System Design Interview books: Volume 1: https://amzn.to/3

Caching Pitfalls Every Developer Should Know

 1. Cache Stampede 문제 회피하기:

일반적으로 Cache-Aside Pattern 을 통해 캐시 시스템을 구현하게 되면, 캐시를 먼저 조회해보고 캐시 키가 없다면 데이터베이스에서 이를 조회하도록 구현할 겁니다.

Cache Stampede 는 캐시의 특정 키가 만료될 때 대규모 클라이언트가 데이터베이스에서 해당 키를 조회할 때 발생할 수 있는 문제입니다.

해결 방법은 다양합니다:
 * Locking
 * External Process 를 이용하는 방법
 * Probabilistic early expiration

Locking:
 * 이 방법은 캐시에서 데이터가 만료되었다는 걸 알면 Locking 을 걸어둬서, 다른 클라이언트들이 데이터베이스를 조회하지 않도록 하는 방법입니다.
 * 즉 정리하자면 Lock 을 가진 데이터가 Recompuation (= 만료된 캐시 키를 데이터베이스에서 조회해서 다시 캐시에 채우는 연산) 을 수행하고, Lock 을 가지지 못한 클라이언트는 일정 시간을 기다렸다가 다시 캐시에 조회하도록 하는 방법입니다.
 * 이 방법을 좀 더 응용하자면 Lock 을 가지지 못한 클라이언트는 꼭 기다릴 필요는 없습니다. 그냥 Not Found 로 리턴하거나, 오래된 버전의 데이터를 받아오는 방법이 있다면 이를 이용하는 Fallback 접근 방식을 취하는 것도 방법입니다.

External Process 를 이용하는 방법:
 * 이 방법은 외부 프로세스에서 캐시에 데이터를 채우도록 하는 매커니즘입니다.
 * 캐시 키가 만료되기 전에 먼저 수행하도록 하는 Proactively 방식과 캐시 키가 없을 때 반응해서 채우도록 하는 Reactive 방식이 있습니다.
 * Locking 매커니즘에 대해 구현을 하지 않아도 되므로 보다 간단한 솔루션입니다.

Probabilistic early expiration:
 * 캐시에서 데이터를 조회하는 클라이언트가 확률적으로 캐시 키가 만료되기 전에 Recomputation 과정을 수행하도록 하는 기법입니다.
 * 이 확률은 캐시 키가 만료에 가까울 때 증가하도록 구현하면 됩니다.

 2. Cache Penetration 문제 회피하기:

Cache Penetration 는 존재하지도 않는 키를 캐시에서 조회하고 실패해서 데이터베이스에 추가로 조회하면서 데이터베이스 안정성을 떨어뜨리는 문제입니다.

해결 방법은 다양합니다:
 * implement a placeholder for non-existing keys:
 * Bloomfilter

implement a placeholder for non-existing keys:
 * 존재하지 않는 데이터의 경우에도 캐시에 NULL 값으로 세팅해 놓는 방법입니다.
 * 이렇게 적용한다면 계속해서 추가적인 데이터베이스로의 부하는 일어나지 않을 것이지만 캐시 리소스를 많이 차지할 수도 있는 문제가 발생할 수 있습니다.

Bloomfilter:
 * Bloomfilter 를 데이터베이스 앞단에 별도의 컴포넌트로 사용한다면 존재하지 않는 데이터를 명확하게 구별할 수 있습니다.
 * 다만 Bloomfilter 특성상 존재하지 않는 데이터는 명확히 구별하지만 존재하는 데이터라고 판단한 경우에도 존재하지 않는 데이터가 있을 수 있다는 점을 알고 있어야 합니다.

 3. Cache Crash 와 Cache Avalanche 문제 회피하기:

Cache Crash 는 캐시 시스템이 장애가 나서 캐시를 이용할 수 없는 문제를 말하며, Cache Avalanche 는 캐시 시스템이 재시작하거나 할 때 캐시 데이터가 비어있는 상태에서 일어나는 문제를 말합니다.

Cache Crash 문제가 발생하면 모든 부하는 데이터베이스로 가기 때문에 안정성이 떨어지는 문제가 발생할 수 있고, Cache Avalanche 문제가 발생하면 Cache Stampede 현상처럼 모든 키가 miss 가 나서 모든 캐시 부하가 데이터베이스로 가기 때문에 안정성이 떨어지는 문제가 발생할 수 있습니다.

이런 문제들에서 시스템의 안정성을 올리는 해결 방법은 다양합니다:
 * Circuit Breaker
 * Redundancy
 * Warm-up

Circuit Breaker:
 * 과부하 상태일 때 트래픽을 일시적으로 차단해서 서버가 무너지도록 않도록 하고, 서버의 안정성을 회복하도록 하는 방법입니다.

Redundancy:
 * Cache Cluster 를 구축하는 것처럼 여러 개의 캐시 인스턴스를 운영해서 하나의 인스턴스가 장애가 나도 문제가 없도록 하는 방법입니다.

Warm-up:
 * 캐시 서비스를 운영환경에 투입하기 전에 자주 사용하는 데이터를 로드시킨 후 서비스에 투입되는 방법입니다.

References:
 * https://www.youtube.com/watch?v=wh98s0XhMmQ

<ol ><li>Cache Stampede 문제 회피하기: </li></ol> 일반적으로 Cache-Aside Pattern 을 통해 캐시 시스템을 구현하게 되면, 캐시를 먼저 조회해보고 캐시 키가 없다면 데이터베이스에서 이를 조회하도록 구현할 겁니다. Cache Stampede 는 캐시의 특정 키가 만료될 때 대규모 클라이언트가 데이터베이스에서 해당 키를 조회할 때 발생할 수 있는 문제입니다. 해결 방법은 다양합니다:<ul ><li>Locking</li><li>External Process 를 이용하는 방법 </li><li>Probabilistic early expiration</li></ul> Locking: <ul ><li>이 방법은 캐시에서 데이터가 만료되었다는 걸 알면 Locking 을 걸어둬서, 다른 클라이언트들이 데이터베이스를 조회하지 않도록 하는 방법입니다. </li><li>즉 정리하자면 Lock 을 가진 데이터가 Recompuation (= 만료된 캐시 키를 데이터베이스에서 조회해서 다시 캐시에 채우는 연산) 을 수행하고, Lock 을 가지지 못한 클라이언트는 일정 시간을 기다렸다가 다시 캐시에 조회하도록 하는 방법입니다. </li><li>이 방법을 좀 더 응용하자면 Lock 을 가지지 못한 클라이언트는 꼭 기다릴 필요는 없습니다. 그냥 Not Found 로 리턴하거나, 오래된 버전의 데이터를 받아오는 방법이 있다면 이를 이용하는 Fallback 접근 방식을 취하는 것도 방법입니다. </li></ul> External Process 를 이용하는 방법: <ul ><li>이 방법은 외부 프로세스에서 캐시에 데이터를 채우도록 하는 매커니즘입니다. </li><li>캐시 키가 만료되기 전에 먼저 수행하도록 하는 Proactively 방식과 캐시 키가 없을 때 반응해서 채우도록 하는 Reactive 방식이 있습니다. </li><li>Locking 매커니즘에 대해 구현을 하지 않아도 되므로 보다 간단한 솔루션입니다. </li></ul> Probabilistic early expiration: <ul ><li>캐시에서 데이터를 조회하는 클라이언트가 확률적으로 캐시 키가 만료되기 전에 Recomputation 과정을 수행하도록 하는 기법입니다. </li><li>이 확률은 캐시 키가 만료에 가까울 때 증가하도록 구현하면 됩니다. </li></ul> <ol start="2"><li>Cache Penetration 문제 회피하기: </li></ol> Cache Penetration 는 존재하지도 않는 키를 캐시에서 조회하고 실패해서 데이터베이스에 추가로 조회하면서 데이터베이스 안정성을 떨어뜨리는 문제입니다. 해결 방법은 다양합니다: <ul ><li>implement a placeholder for non-existing keys:</li><li>Bloomfilter</li></ul> implement a placeholder for non-existing keys: <ul ><li>존재하지 않는 데이터의 경우에도 캐시에 NULL 값으로 세팅해 놓는 방법입니다. </li><li>이렇게 적용한다면 계속해서 추가적인 데이터베이스로의 부하는 일어나지 않을 것이지만 캐시 리소스를 많이 차지할 수도 있는 문제가 발생할 수 있습니다.</li></ul> Bloomfilter: <ul ><li>Bloomfilter 를 데이터베이스 앞단에 별도의 컴포넌트로 사용한다면 존재하지 않는 데이터를 명확하게 구별할 수 있습니다. </li><li>다만 Bloomfilter 특성상 존재하지 않는 데이터는 명확히 구별하지만 존재하는 데이터라고 판단한 경우에도 존재하지 않는 데이터가 있을 수 있다는 점을 알고 있어야 합니다. </li></ul> <ol start="3"><li>Cache Crash 와 Cache Avalanche 문제 회피하기:</li></ol> Cache Crash 는 캐시 시스템이 장애가 나서 캐시를 이용할 수 없는 문제를 말하며, Cache Avalanche 는 캐시 시스템이 재시작하거나 할 때 캐시 데이터가 비어있는 상태에서 일어나는 문제를 말합니다. Cache Crash 문제가 발생하면 모든 부하는 데이터베이스로 가기 때문에 안정성이 떨어지는 문제가 발생할 수 있고, Cache Avalanche 문제가 발생하면 Cache Stampede 현상처럼 모든 키가 miss 가 나서 모든 캐시 부하가 데이터베이스로 가기 때문에 안정성이 떨어지는 문제가 발생할 수 있습니다. 이런 문제들에서 시스템의 안정성을 올리는 해결 방법은 다양합니다: <ul ><li>Circuit Breaker</li><li>Redundancy</li><li>Warm-up </li></ul> Circuit Breaker: <ul ><li>과부하 상태일 때 트래픽을 일시적으로 차단해서 서버가 무너지도록 않도록 하고, 서버의 안정성을 회복하도록 하는 방법입니다. </li></ul> Redundancy: <ul ><li>Cache Cluster 를 구축하는 것처럼 여러 개의 캐시 인스턴스를 운영해서 하나의 인스턴스가 장애가 나도 문제가 없도록 하는 방법입니다. </li></ul> Warm-up: <ul ><li>캐시 서비스를 운영환경에 투입하기 전에 자주 사용하는 데이터를 로드시킨 후 서비스에 투입되는 방법입니다. </li></ul> References: <ul ><li>https://www.youtube.com/watch?v=wh98s0XhMmQ</li></ul>

www.youtube.com

모든 개발자가 알아야 하는 Caching Pitfalls

 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가지 데이터베이스 확장성 전략

10 Insights On Real-World Container Usage (Sponsored) As organizations have scaled their containerized environments, many are now exploring the next technology frontier of containers by building next-gen applications, enhancing developer productivity, and

The Scaling Journey of LinkedIn

대표적인 비즈니스 네트워킹을 지원하는 소셜 네트워크인 Linkedin 이 규모가 커지면서 어떻게 대용량 트래픽을 처리하게 되었는지 정리해 보았습니다. 

이 글에서는  대규모 트래픽을 처리하기 위한 ‘확장성’ 을 지원하기 위한 방법들에 대해서 간략하게 소개할게요. 

Linkedin 이 어떠한 최신 기술들을 도입했는지, 개발자 경험은 어떻게 개선했는지 등의 내용은 원문을 통해 보시는 걸 추천드립니다~ 

<Linkedin 의 트래픽 처리 기술>

 1. Monolithic Architecture 를 독립된 Microservice 로 전환: 

이 결정은 독립된 마이크로서비스로 변경함에 따라서 Scale-out 을 쉽게 하기 위함, 가용성 문제를 해결하기 위함, 그리고 새로운 기능을 쉽게 추가하기 위함이라고 합니다. 

초기에 Linkedin 은 모놀리식 서비스의 Scale-out 과 Database Replication 을 통해 부하를 분산하는 식으로 해결했지만, 시스템의 부분적인 실패가 전체 시스템에 영향을 미치지 않도록 하기 위해서, 그리고 서비스의 새로운 기능을 쉽게 릴리즈 하기 위해서 Microservice 로 전환 했다고 합니다. 

Linkedin 의 마이크로서비스 개수는 2015년 기준으로 750개 이상의 서비스를 구축했다고 합니다. 

 2. 독립적인 Member Graph Service 서비스 도입

Linkedin 의 특성상 회원 간 연결이 중요한 만큼 회원들 간의 관계를 보여주는 건 단일 모노리식 서비스로는 감당이 안 되었기 때문에 독립적인 서비스로 분할했다고 합니다.

그래서 확장성이 있고, 초당 수십만 건의 쿼리를 처리할 수 있는 독립적인 그래프 서비스를 개발했다고 합니다. 

이 그래프 서비스를 위해서 높은 가용성과 내구성을 그리고 파티셔닝을 지원하는 GraphDB 를 선택했고, 회원과 네트워킹 정보를 저장하는 분산 캐시 서비스를 도입해서 적용했다고 합니다. 

 3. 독립적인 Search Service 도입 

Member Graph Service 와 마찬가지로 LinkedIn 의 핵심 서비스 중 하나는 검색 서비스입니다. 

사람들은 이런 검색 서비스를 통해서 사람들을 찾고, Jobs 을 찾고, Companies 를 찾을 수 있습니다. 

그리고 개인화된 검색 기능까지 필요하다고 요구사항을 정의했기 때문에 Lucene 기반의 검색 서비스를 만들어야겠다고 판단했다고 합니다. 

 4. Caching Service 도입 

더 나은 확장성을 도입하기 위해서 Linkedin 은 Caching 을 도입하기로 결정했는데요. 

Linkedin 이 택한 캐싱 전략은 다음과 같습니다: 
 * 미드 티어 캐싱: Memcached 및 Couchbase 와 같은 캐싱 솔루션을 어플리케이션과 데이터베이스 사이에 둬서 다양한 도메인과 파생된 데이터를 저장하도록 했습니다. 이 캐시의 목적은 데이터베이스에 대한 요청을 줄이고 응답 시간을 단축하기 위함이라고 합니다. 
 * 데이터 레이어 캐싱: Voldemort 라는 AWS 의 DynamoDB 와 같은 캐싱을 사용해서 데이터베이스에 저장된 데이터들을 사전 계산한 값을 저장해둬서 데이터베이스의 부하를 줄였다고 합니다. 그리고 데이터베이스에 가깝게 배치해서 데이터베이스와의 통신 지연을 최소화 했다고 합니다. 

하지만 시간이 지나면서 캐싱 솔루션의 대표적인 문제인 캐싱 데이터와 데이터베이스의 데이터가 일관성이 안 맞는 문제가 생겨서 결국 미드 티어 캐싱은 제거했다고 합니다. 

 5. Kafka 도입 

Linkedin 이 성장하면서 데이터의 양도 급격하게 증가했다고 합니다. 이러한 데이터를 효율적으로 수집하고 분석하기 위해서 데이터를 데이터 웨어하우스에 적재하기로 했고, 이러한 솔루션으로 Kafka 를 도입했다고 합니다. 

Kafka 는 대량의 데이터를 스트리밍하고 큐잉하기 위해 적절하므로 이를 선택했다고 합니다. 

References:
 * https://blog.bytebytego.com/p/the-scaling-journey-of-linkedin?utm_source=post-email-title&publication_id=817132&post_id=144264389&utm_campaign=email-post-title&isFreemail=true&r=2clrg7&triedRedirect=true&utm_medium=email

대표적인 비즈니스 네트워킹을 지원하는 소셜 네트워크인 Linkedin 이 규모가 커지면서 어떻게 대용량 트래픽을 처리하게 되었는지 정리해 보았습니다.&nbsp; 이 글에서는&nbsp; 대규모 트래픽을 처리하기 위한 ‘확장성’ 을 지원하기 위한 방법들에 대해서 간략하게 소개할게요.&nbsp; Linkedin 이 어떠한 최신 기술들을 도입했는지, 개발자 경험은 어떻게 개선했는지 등의 내용은 원문을 통해 보시는 걸 추천드립니다~&nbsp; &lt;Linkedin 의 트래픽 처리 기술&gt; <ol ><li>Monolithic Architecture 를 독립된 Microservice 로 전환:&nbsp;</li></ol> 이 결정은 독립된 마이크로서비스로 변경함에 따라서 Scale-out 을 쉽게 하기 위함, 가용성 문제를 해결하기 위함, 그리고 새로운 기능을 쉽게 추가하기 위함이라고 합니다.&nbsp; 초기에 Linkedin 은 모놀리식 서비스의 Scale-out 과 Database Replication 을 통해 부하를 분산하는 식으로 해결했지만, 시스템의 부분적인 실패가 전체 시스템에 영향을 미치지 않도록 하기 위해서, 그리고 서비스의 새로운 기능을 쉽게 릴리즈 하기 위해서 Microservice 로 전환 했다고 합니다.&nbsp; Linkedin 의 마이크로서비스 개수는 2015년 기준으로 750개 이상의 서비스를 구축했다고 합니다.&nbsp; <ol start="2"><li>독립적인 Member Graph Service 서비스 도입</li></ol> Linkedin 의 특성상 회원 간 연결이 중요한 만큼 회원들 간의 관계를 보여주는 건 단일 모노리식 서비스로는 감당이 안 되었기 때문에 독립적인 서비스로 분할했다고 합니다. 그래서 확장성이 있고, 초당 수십만 건의 쿼리를 처리할 수 있는 독립적인 그래프 서비스를 개발했다고 합니다.&nbsp; 이 그래프 서비스를 위해서 높은 가용성과 내구성을 그리고 파티셔닝을 지원하는 GraphDB 를 선택했고, 회원과 네트워킹 정보를 저장하는 분산 캐시 서비스를 도입해서 적용했다고 합니다.&nbsp; <ol start="3"><li>독립적인 Search Service 도입&nbsp;</li></ol> Member Graph Service 와 마찬가지로 LinkedIn 의 핵심 서비스 중 하나는 검색 서비스입니다.&nbsp; 사람들은 이런 검색 서비스를 통해서 사람들을 찾고, Jobs 을 찾고, Companies 를 찾을 수 있습니다.&nbsp; 그리고 개인화된 검색 기능까지 필요하다고 요구사항을 정의했기 때문에 Lucene 기반의 검색 서비스를 만들어야겠다고 판단했다고 합니다.&nbsp; <ol start="4"><li>Caching Service 도입&nbsp;</li></ol> 더 나은 확장성을 도입하기 위해서 Linkedin 은 Caching 을 도입하기로 결정했는데요.&nbsp; Linkedin 이 택한 캐싱 전략은 다음과 같습니다:&nbsp;<ul ><li>미드 티어 캐싱: Memcached 및 Couchbase 와 같은 캐싱 솔루션을 어플리케이션과 데이터베이스 사이에 둬서 다양한 도메인과 파생된 데이터를 저장하도록 했습니다. 이 캐시의 목적은 데이터베이스에 대한 요청을 줄이고 응답 시간을 단축하기 위함이라고 합니다.&nbsp;</li><li>데이터 레이어 캐싱: Voldemort 라는 AWS 의 DynamoDB 와 같은 캐싱을 사용해서 데이터베이스에 저장된 데이터들을 사전 계산한 값을 저장해둬서 데이터베이스의 부하를 줄였다고 합니다. 그리고 데이터베이스에 가깝게 배치해서 데이터베이스와의 통신 지연을 최소화 했다고 합니다.&nbsp;</li></ul> 하지만 시간이 지나면서 캐싱 솔루션의 대표적인 문제인 캐싱 데이터와 데이터베이스의 데이터가 일관성이 안 맞는 문제가 생겨서 결국 미드 티어 캐싱은 제거했다고 합니다.&nbsp; <ol start="5"><li>Kafka 도입&nbsp;</li></ol> Linkedin 이 성장하면서 데이터의 양도 급격하게 증가했다고 합니다. 이러한 데이터를 효율적으로 수집하고 분석하기 위해서 데이터를 데이터 웨어하우스에 적재하기로 했고, 이러한 솔루션으로 Kafka 를 도입했다고 합니다.&nbsp; Kafka 는 대량의 데이터를 스트리밍하고 큐잉하기 위해 적절하므로 이를 선택했다고 합니다.&nbsp; References:<ul ><li>https://blog.bytebytego.com/p/the-scaling-journey-of-linkedin?utm_source=post-email-title&amp;publication_id=817132&amp;post_id=144264389&amp;utm_campaign=email-post-title&amp;isFreemail=true&amp;r=2clrg7&amp;triedRedirect=true&amp;utm_medium=email</li></ul>

Bytebytego

LinkedIn 의 확장성을 위한 트래픽 처리 기술

그랩 | MAU 20만 이상의 LLM Application과 이를 뒷받침하는 LLMOps 환경을 구축하면서 배우고 익힌 경험/노하우 공유회 영상입니다., 현재 MAU 20만 이상의 LLM Application과 이를 뒷받침하는 LLMOps 환경을 구축하면서 배우고 익힌 경...

[지금 무료] LLM Application In Production | 그랩 - 인프런

최근 Project Pluto 에서 LLM 어플리케이션을 실제 프로덕션 환경에서 활용하는 내용에 대해 공유해주셨네요.

아직 정답이 없는 기술 속에서 정답에 가까워지기 위한 노력을 하고 있는 점 그리고 값진 경험을 공유해준다는 점에서 감사합니다~

Project Pluto 는 실제로 Supernews 라는 어플리케이션을 통해서 LLM 을 전문적으로 사용하고 있다고 하는데요.

이 앱은 Financial News 를 전문적인 저널리스트 없이 오로지 LLM 으로만 기사를 작성해서 제공해준다고 합니다.

참고하실 점은 LLM 을 다룰 때 BloombergGPT 처럼 처음부터 모델을 밑바닥부터 학습시켜서 사용하는 방식은 아니고, API 방식으로 사용하고 있다고 합니다.

RAG(Retrieval-Augmented Generation) 를 잘 사용하는 방법이나 LLMOps 에 대해 관심이 있으신 분들이 들어보시면 좋을 것 같습니다. (저는 특히 RAG 부분에서 많은 영감을 받았습니다.)

한번 시간 내서 들어보시면 좋으실 것 같아요. 링크는 아래와 같습니다.

https://www.inflearn.com/course/llm-application-in-production/dashboard

최근 Project Pluto 에서 LLM 어플리케이션을 실제 프로덕션 환경에서 활용하는 내용에 대해 공유해주셨네요. 아직 정답이 없는 기술 속에서 정답에 가까워지기 위한 노력을 하고 있는 점 그리고 값진 경험을 공유해준다는 점에서 감사합니다~ Project Pluto 는 실제로 Supernews 라는 어플리케이션을 통해서 LLM 을 전문적으로 사용하고 있다고 하는데요. 이 앱은 Financial News 를 전문적인 저널리스트 없이 오로지 LLM 으로만 기사를 작성해서 제공해준다고 합니다. 참고하실 점은 LLM 을 다룰 때 BloombergGPT 처럼 처음부터 모델을 밑바닥부터 학습시켜서 사용하는 방식은 아니고, API 방식으로 사용하고 있다고 합니다. RAG(Retrieval-Augmented Generation) 를 잘 사용하는 방법이나 LLMOps 에 대해 관심이 있으신 분들이 들어보시면 좋을 것 같습니다. (저는 특히 RAG 부분에서 많은 영감을 받았습니다.) 한번 시간 내서 들어보시면 좋으실 것 같아요. 링크는 아래와 같습니다. https://www.inflearn.com/course/llm-application-in-production/dashboard

인프런

LLM Application in Production

여정민 Software Engineer | 아래의 25개의 논문들은 현대 컴퓨팅 시스템의 기반 기술들을 소개하고 있는데요. 이러한 기술들은 대규모 서비... | 커리어리

여정민 / 컴퓨터 세계를 완전히 변화시킨 25개의 논문 | 커리어리

이전에 쓴 글인 "컴퓨터 세계를 완전히 변화시킨 25개의 논문" 를 따라서 하나씩 관심있는 논문을 소개해볼까 합니다.
 * 참고: https://careerly.co.kr/comments/104598?utm_campaign=self-share
   
   
이번 글은 제가 가장 관심있는 기술 중 하나인 Apache Flink™: Stream and Batch Processing in a Single Engine 입니다.

Apache Flink 는 실시간 데이터 처리 능력과 고급 스트리밍 분석 기능을 제공하는 분산 데이터 처리 엔진이에요.

주로 스트리밍/배치 애플리케이션, 데이터 파이프라인, 실시간 업데이트를 위한 머신러닝 시스템 , 실시간 데이터 분석 등 다양한 분야에서 사용됩니다.

현재 한국에서는 Apache Kafka 만큼 잘 알려져 있진 않지만 향후에는 대세적인 기술이 되지 않을까 싶습니다.

글은 블로그에 정리해 놓았으니 시간 나실 때 한번 봐주세요~

https://youngerjesus.tistory.com/102

이전에 쓴 글인 "컴퓨터 세계를 완전히 변화시킨 25개의 논문" 를 따라서 하나씩 관심있는 논문을 소개해볼까 합니다. <ul ><li>참고: https://careerly.co.kr/comments/104598?utm_campaign=self-share </li></ul>이번 글은 제가 가장 관심있는 기술 중 하나인 Apache Flink™: Stream and Batch Processing in a Single Engine 입니다. Apache Flink 는 실시간 데이터 처리 능력과 고급 스트리밍 분석 기능을 제공하는 분산 데이터 처리 엔진이에요. 주로 스트리밍/배치 애플리케이션, 데이터 파이프라인, 실시간 업데이트를 위한 머신러닝 시스템 , 실시간 데이터 분석 등 다양한 분야에서 사용됩니다. 현재 한국에서는 Apache Kafka 만큼 잘 알려져 있진 않지만 향후에는 대세적인 기술이 되지 않을까 싶습니다. 글은 블로그에 정리해 놓았으니 시간 나실 때 한번 봐주세요~ https://youngerjesus.tistory.com/102

커리어리

Apache Flink 논문 리뷰

2024년 7월~12월 사이의 취업 기록, Meta 입사

2025년 미국 뉴욕 소프트웨어 엔지니어 취업기

지난 6개월 동안 미국에서 취업 활동했던 후기를 간략히 정리했습니다. 정보가 도움이 되셨으면 좋겠습니다.

 * 200개 이상의 포지션에 지원, 8개 회사와 면접 진행, 3곳 최종 합격
 * 생애 첫 ‘리트코드 스타일’ 코딩 인터뷰 통과 비법
 * 시스템 디자인 면접 준비
 * 2025년 1월 Meta 입사

지난 6개월 동안 미국에서 취업 활동했던 후기를 간략히 정리했습니다. 정보가 도움이 되셨으면 좋겠습니다. <ul ><li>200개 이상의 포지션에 지원, 8개 회사와 면접 진행, 3곳 최종 합격</li><li>생애 첫 ‘리트코드 스타일’ 코딩 인터뷰 통과 비법</li><li>시스템 디자인 면접 준비</li><li>2025년 1월 Meta 입사</li></ul>

www.nyprogrammer.com

지난 6개월 동안 미국에서 취업 활동했던 후기를 간략히 정리했습니

“재호야, 문제 원인은 찾았니? 언제까지 고칠 수 있겠니?”
“휴… 잘 모르겠어요.”
“난 네가 모르겠다고 말하는 게 제일 무서워.”

저에게는 이사님이 제 자리에 와서 언제까지 되겠니 묻는 게 가장 무서운 순간이었는데…
이사님은 제가 잘 모르겠다 말하는 게 가장 무섭다고 합니다.
서로가 무서운 이 웃픈 상황.

늦어도 좋으니 제발 일정을 알려 달라고.
이사님의 입장도 이해는 했습니다. 일정이 정해져야 영업팀과 운영팀에 알려서 고객들과 커뮤니케이션을 할 테니까.
하지만 정말 모르겠는 걸 어떡해… 함부로 말하다가 약속을 못 지키면?
그야말로 죽을 맛이었습니다. 어디가 문젠지 짐작도 안 가는데, 일정의 독촉은 계속 되고...
개발하면서 이렇게 스트레스받았을 때가 있었던가?

그건 파일 시스템 드라이버를 만들 때 였습니다.
(N:에 마운트 하는 네이버 클라우드 탐색기를 떠올리시면 됩니다.)

윈도우를 며칠간 사용하다 보면 메모리가 사용량이 조금씩 높아진다는 제보들이 있었습니다.
처음엔 그게 우리 드라이버 때문인지 믿을 수가 없었습니다.
하지만 사내 사용자들의 제보도 계속 이어졌고, 문제를 찾기 위해 애쓰는 날들이 계속됐습니다.

애플리케이션과는 달리 커널 코드에서 메모리가 새면 찾기도 어려울뿐더러 컴퓨터를 껐다 켜기 전까지는 해소가 되지 않습니다. 지옥 같은 날들을 지나, 결국 어떤 부분에서 그러는지를 찾아냈습니다.

버그 제보를 받은 날부터 고치기까지 한 달쯤 걸렸던가?
아침에 눈을 뜨면 한숨부터 나오면서 회사 가기가 무서웠던 날들이었습니다.

오늘 편안하게 앉아서 창밖을 바라보다 문득 이때 생각이 났습니다.
회사를 그만두고 이런 압박이 없어져서 정말 다행입니다만… 생각해 보니 이런 압박 덕분에 결국 문제를 해결해 내고 성장할 수 있었던 것 같습니다.
그래도 이 정도로 스트레스받아가며 여생을 살고 싶진 않네요. (웃음)

* TMI 토킹
오래된 기억이지만 문제는 FsRtlNotifyFullReportChange 의 구현 때문이었습니다.

만약 똑같은 경로에서 윈도 탐색기 두 개를 열어 놓고,
한 쪽에서 파일 하나를 생성하면 다른 쪽 탐색기에서도 새로 만들어진 파일이 곧장 보여야 합니다.

이건 윈도 탐색기가 ReadDirectoryChangesW 함수를 잘 구현해 줬기 때문에 되는 일이기도 하지만, 파일 시스템에서도 FsRtlNotifyFullReportChange 를 구현해 줘야만 합니다.
파일 시스템에서 이 부분을 구현 안 하면 애플리케이션에서 아무리 디렉터리 변경을 기다리고 있더라도 통지가 오지 않게 되는 것입니다.
이 함수를 어떻게 구현해야 한다고 자세하게 알려주는 문서는 없었습니다. 우리는 다행히 이 부분을 잘 구현해둬서 파일 알림 통지가 잘 되고 있었는데… 통지만 잘 될 뿐 여기서 메모리가 새고 있었던 것입니다. 너무 적게 새어나가고 있어서 찾을 수가 없을 정도로.
이 버그를 완전히 고쳤을 때 얼마나 기뻤던지.

“재호야, 문제 원인은 찾았니? 언제까지 고칠 수 있겠니?” “휴… 잘 모르겠어요.” “난 네가 모르겠다고 말하는 게 제일 무서워.” 저에게는 이사님이 제 자리에 와서 언제까지 되겠니 묻는 게 가장 무서운 순간이었는데… 이사님은 제가 잘 모르겠다 말하는 게 가장 무섭다고 합니다. 서로가 무서운 이 웃픈 상황. 늦어도 좋으니 제발 일정을 알려 달라고. 이사님의 입장도 이해는 했습니다. 일정이 정해져야 영업팀과 운영팀에 알려서 고객들과 커뮤니케이션을 할 테니까. 하지만 정말 모르겠는 걸 어떡해… 함부로 말하다가 약속을 못 지키면? 그야말로 죽을 맛이었습니다. 어디가 문젠지 짐작도 안 가는데, 일정의 독촉은 계속 되고... 개발하면서 이렇게 스트레스받았을 때가 있었던가? 그건 파일 시스템 드라이버를 만들 때 였습니다. (N:에 마운트 하는 네이버 클라우드 탐색기를 떠올리시면 됩니다.) 윈도우를 며칠간 사용하다 보면 메모리가 사용량이 조금씩 높아진다는 제보들이 있었습니다. 처음엔 그게 우리 드라이버 때문인지 믿을 수가 없었습니다. 하지만 사내 사용자들의 제보도 계속 이어졌고, 문제를 찾기 위해 애쓰는 날들이 계속됐습니다. 애플리케이션과는 달리 커널 코드에서 메모리가 새면 찾기도 어려울뿐더러 컴퓨터를 껐다 켜기 전까지는 해소가 되지 않습니다. 지옥 같은 날들을 지나, 결국 어떤 부분에서 그러는지를 찾아냈습니다. 버그 제보를 받은 날부터 고치기까지 한 달쯤 걸렸던가? 아침에 눈을 뜨면 한숨부터 나오면서 회사 가기가 무서웠던 날들이었습니다. 오늘 편안하게 앉아서 창밖을 바라보다 문득 이때 생각이 났습니다. 회사를 그만두고 이런 압박이 없어져서 정말 다행입니다만… 생각해 보니 이런 압박 덕분에 결국 문제를 해결해 내고 성장할 수 있었던 것 같습니다. 그래도 이 정도로 스트레스받아가며 여생을 살고 싶진 않네요. (웃음) * TMI 토킹 오래된 기억이지만 문제는 FsRtlNotifyFullReportChange 의 구현 때문이었습니다. 만약 똑같은 경로에서 윈도 탐색기 두 개를 열어 놓고, 한 쪽에서 파일 하나를 생성하면 다른 쪽 탐색기에서도 새로 만들어진 파일이 곧장 보여야 합니다. 이건 윈도 탐색기가 ReadDirectoryChangesW 함수를 잘 구현해 줬기 때문에 되는 일이기도 하지만, 파일 시스템에서도 FsRtlNotifyFullReportChange 를 구현해 줘야만 합니다. 파일 시스템에서 이 부분을 구현 안 하면 애플리케이션에서 아무리 디렉터리 변경을 기다리고 있더라도 통지가 오지 않게 되는 것입니다. 이 함수를 어떻게 구현해야 한다고 자세하게 알려주는 문서는 없었습니다. 우리는 다행히 이 부분을 잘 구현해둬서 파일 알림 통지가 잘 되고 있었는데… 통지만 잘 될 뿐 여기서 메모리가 새고 있었던 것입니다. 너무 적게 새어나가고 있어서 찾을 수가 없을 정도로. 이 버그를 완전히 고쳤을 때 얼마나 기뻤던지.

언제까지 고칠 수 있겠니?

원문 : React Tech Stack [2025] 리액트 생태계에서는 항상 새로운 기술들이 등장하고 있습니다. 이번 글에서는 2025년에 풀스택 애플리케이션을 개발하기 위한 인기 있는 리액트 기술 스택 하나(!)를 탐구해 보겠습니다. 이를 통해 여러분만의 제품(예: SaaS) 또는 최소한의 MVP를 만들 수 있을 것입니다. 애초에 이 가이드를 쓴 이유는 무엇인가요? 저는 프리랜서 웹 개발자와…

(번역) 2025 리액트 기술 스택

오늘은 42dot의 유경상님이 번역해주신 글입니다.

이 글에서는 저자가 자신의 실무 경험과 현재 트렌드를 바탕으로 2025년 리액트 풀스택 애플리케이션 개발을 위한 기술 스택을 제안합니다. Next.js, Tailwind CSS, TypeScript, Prisma, Supabase 등의 핵심 기술과 함께 UI/UX, 상태 관리, 인증, 결제를 위한 도구들을 추천하며, 각 선택의 이유와 장점에 대해 설명하고 있습니다. 새해를 맞아 새로운 리액트 기반의 프로젝트를 준비하시는 분들께 이 글을 추천드립니다 :)

> 글 링크 : https://ykss.netlify.app/translation/2025_react_tech_stack/

오늘은 42dot의 유경상님이 번역해주신 글입니다. 이 글에서는 저자가 자신의 실무 경험과 현재 트렌드를 바탕으로 2025년 리액트 풀스택 애플리케이션 개발을 위한 기술 스택을 제안합니다. Next.js, Tailwind CSS, TypeScript, Prisma, Supabase 등의 핵심 기술과 함께 UI/UX, 상태 관리, 인증, 결제를 위한 도구들을 추천하며, 각 선택의 이유와 장점에 대해 설명하고 있습니다. 새해를 맞아 새로운 리액트 기반의 프로젝트를 준비하시는 분들께 이 글을 추천드립니다 :) &gt; 글 링크 : https://ykss.netlify.app/translation/2025_react_tech_stack/

ykss.netlify.app

2025 리액트 기술 스택

[번외편] 영어 실력이 부족하여 고민하고 있는 분들에게

해외에서 살다보면 가장 열등감을 느낄 수 있는 부분이 바로 의사 소통 능력입니다.

그들은 이미 잘 알고 있지만, 나는 모르는 것.
그들끼리 당연하게 사용하는 언어를 나는 이해하지 못하는 것,
전달하고자 하는 바를 제대로 전달하지 못해 느끼는 좌절감과 무력감.

해외에서 사시는 분들은 살면서 한번 정도는 경험해본 경험들일 거에요.

저도 미국 생활 초반, 이 기분을 많이 느꼈습니다.
서브웨이에서 원하는 메뉴를 제대로 주문하지 못해,
내가 원하지 않는 메뉴를 받았을 때의 그 기분은 말로 표현하기가 힘들죠.

하지만 그 경험 덕분에,
저는 미국에서 내가 원하는 것을 정확하게 말하는 것이 얼마나 중요한지, 그리고 적극적으로 표현하는 행동이 어떤 결과를 만드는 지를 살면서 깨달을 수 있었습니다.

해외에서 살면서 유창한 영어 실력보다 더욱 중요한 것은 내가 원하는 바를 어떻게 표현하는지를 배우는 것이라고 생각합니다.

언어를 사용하는 방법 중 저는 말하기가 가장 중요하다고 생각합니다. 말하기에는 읽기, 쓰기, 듣기와 달리 나의 의도와 태도가 가장 많이 반영됩니다.

어떤 관용어를 사용하거나, 어떤 문장 구조를 사용하거나, 또는 어떤 고급 단어를 사용하는지보다,

내가 가지고자 하는 의도와 태도를 담아서 말하는 법을 익히는 것,
그것이 해외 생활에서 가장 크게 배운 교훈 중 하나였습니다.

[번외편] 영어 실력이 부족하여 고민하고 있는 분들에게 해외에서 살다보면 가장 열등감을 느낄 수 있는 부분이 바로 의사 소통 능력입니다. 그들은 이미 잘 알고 있지만, 나는 모르는 것. 그들끼리 당연하게 사용하는 언어를 나는 이해하지 못하는 것, 전달하고자 하는 바를 제대로 전달하지 못해 느끼는 좌절감과 무력감. 해외에서 사시는 분들은 살면서 한번 정도는 경험해본 경험들일 거에요. 저도 미국 생활 초반, 이 기분을 많이 느꼈습니다. 서브웨이에서 원하는 메뉴를 제대로 주문하지 못해, 내가 원하지 않는 메뉴를 받았을 때의 그 기분은 말로 표현하기가 힘들죠. 하지만 그 경험 덕분에, 저는 미국에서 내가 원하는 것을 정확하게 말하는 것이 얼마나 중요한지, 그리고 적극적으로 표현하는 행동이 어떤 결과를 만드는 지를 살면서 깨달을 수 있었습니다. 해외에서 살면서 유창한 영어 실력보다 더욱 중요한 것은 내가 원하는 바를 어떻게 표현하는지를 배우는 것이라고 생각합니다. 언어를 사용하는 방법 중 저는 말하기가 가장 중요하다고 생각합니다. 말하기에는 읽기, 쓰기, 듣기와 달리 나의 의도와 태도가 가장 많이 반영됩니다. 어떤 관용어를 사용하거나, 어떤 문장 구조를 사용하거나, 또는 어떤 고급 단어를 사용하는지보다, 내가 가지고자 하는 의도와 태도를 담아서 말하는 법을 익히는 것,그것이 해외 생활에서 가장 크게 배운 교훈 중 하나였습니다.

[번외편] IT 직무로 해외 취업을 고려하는 분들에게 드리고 싶은

그만 성장해야겠다

영상 컨텐츠를 확인해보면 유독 우리나라 사람들은 성장 성장 성장 노래합니다.

갓생이라는 이름으로 스스로를 착취하고 전시합니다.

그래서 종혁님의 글에서 이 문구가 와닿네요.

"올해는 작은 목표만 세웠다. 멀리 나아가기보다, 나를 가까이에서 둘러싼 것들에 대해 더 알고 싶다."

https://maxkim-j.github.io/posts/stop-growing/

영상 컨텐츠를 확인해보면 유독 우리나라 사람들은 성장 성장 성장 노래합니다. 갓생이라는 이름으로 스스로를 착취하고 전시합니다. 그래서 종혁님의 글에서 이 문구가 와닿네요. "올해는 작은 목표만 세웠다. 멀리 나아가기보다, 나를 가까이에서 둘러싼 것들에 대해 더 알고 싶다." https://maxkim-j.github.io/posts/stop-growing/

maxkim-j.github.io

우리는 성장을 강요받는다

This will be a happy new year - let me explain..

2025 - UX is dead - Long live Problem Solving

최근 링크드인에서 화제가 된 글을 UX 리서처 관점에서 재해석해보았습니다. 이 글은 트레바리 <리서치 하는데요> 시즌4 멤버인 아름 님께서 소개해주셨습니다. 마침 2번째 모임에서 『대체 뭐가 문제야』라는 책을 함께 읽고 '문제 정의'에 대해 토론을 하며 UX를 업으로 하는 사람으로서 어떻게 문제를 제대로 정의하고, 근원적인 솔루션을 도출할 수 있을까? 고민했기에 다소 자극적인 포스팅이지만 가만히 생각해 볼 지점들도 있습니다.

시간을 들여서라도 원문을 꼭 함께 살펴보시면 좋겠습니다. Anthony Sean McSharry - LinkedIn 포스트 "2025 - UX is dead - Long live Problem Solving"

[ 큐레이터의 문장 🎒 ]

UX는 정말 죽었나?

현재 UX 업계는 중대한 위기를 맞이했다며 저자는 이렇게 주장합니다. 누구나 사용자 경험을 이야기하고 UX를 한다고 자신의 직무에 UX를 붙입니다.

UX has become a joke - anyone can do (or rather not do) it and just add 'UX' to their title.

UX란 말이 농담거리가 되어버렸어요. 누구나 UX를 한다고 하고(또는 하지도 않으면서), 그저 직함에 'UX'만 붙이면 그만입니다. 단순한 도발이라고 보기에는 현실적인 부분이 많습니다. 저자는 현재 UX 업계의 문제점을 이렇게 짚어냅니다.

Focus on UI design, talk endlessly about 'empathy', use tools that cannot provide realistic usability tests, create hi-fidelity prototypes instead of hi-functioning prototypes, do not understand or do research, use made up Personas.

UI 디자인에만 매달리고, '공감'이란 말만 반복하며, 실제 사용성 검증이 불가능한 도구들을 쓰고 있어요. 제대로 작동하는 프로토타입은 만들지 않으면서 겉모습만 그럴듯한 시안만 만들죠. 리서치는 이해하지도 못하고 수행하지도 않으면서 근거 없는 페르소나만 만들어냅니다.

진정한 UX의 역할은 무엇일까?

그렇다면 진정한 UX란 무엇일까요? 저자는 이렇게 설명합니다.

UX 담당자가 해결해야 할 문제는

 * 3가지 도메인(사용자, 비즈니스, 기술)을 모두 아우르며
 * 디지털 뿐만 아니라 피지컬, 물리적 환경에서도 작동합니다
 * 소프트웨어만큼 프로세스도 중요하고
 * 운영 효율을 높이고
 * 비용은 줄이면서
 * 기능적으로 가치 있고 매력적인 해결책을 만들어내야 합니다

UX 죽음에 책임있는 자들은 누구인가?

 1. UI 디자인에만 집중하는
 2. '공감'에 대해 끝없이 이야기하는(구체적인 문제정의와 솔루션 없이)
 3. 현실적인 사용성 테스트를 제공할 수 없는 도구를 사용하는
 4. 고기능(High-functioning) 프로토타입 대신 그럴듯해보이는 프로토타입을 만드는
 5. UX 리서치를 이해하지 못하거나 수행하지 않는
 6. (AI 등을 통해) 만들어낸 페르소나를 사용하는
 7. 마케팅 카피를 쓰고 이를 UX라고 부르는
 8. UX가 디지털에만 존재한다고 생각하는
 9. 아름답게 디자인된 포트폴리오를 가진
 10. Figma 같은 쓸모없는 도구를 사용하는(Figma의 장점은 '쉬운 도구'라는 것인데 주객전도로 Figma로 리서치까지 모두 다 할 수 있다고 맹신하는)
 11. 기술을 이해하지 못하는
 12. 비즈니스를 이해하지 못하는
 13. 심리학이 그들의 결정과 작업에 어떤 영향을 미치는지 이해하지 못하는
 14. 직원을 사용자로 고려하지 않는
 15. CX와 UX가 다른 것이라고 주장하는
 16. 서비스 디자인을 하지 않는(무엇이라 부르든)
 17. 애자일 내부에서 부분, 일부로 작동하는(애자일 스프린트가 시작되기 전에 충분한 리서치와 검증이 선행되어야 함)
 18. 이러한 믿음을 홍보하고 잘못된 내용을 리더들, 컨퍼런스에서 발표하는

2025년, 우리는 어디로 가야 하나?

If you are a real UXer (a true problem solver) your value is more important than ever, but your title will have to change.

(그럼에도) 진정한 UX 역할자, 즉 진정한 문제 해결자라면 당신의 가치는 그 어느 때보다 빛날 것입니다. 다만 직함은 바뀌어야 할 거예요.

UX 리서처가 갖춰야 할 역량들

 1. 리서치 방법론 균형감각과 고도화
 * 정성적/정량적 리서치의 균형
 * 비즈니스 지표와의 연계, 논리성
 
 
 2. 문제 해결 능력 강화
 * 정성적/정량적 데이터에 기반한 의사결정 지원
 * 비즈니스/기술 영역에 대한 이해까지
 * 실질적인 비즈니스 운영까지 고려
 
 
 3. 리서치 임팩트 입증
 * 리서치로 발견한 문제 해결에 대해 리서치 투자 대비 효과 측정 필요
 * 비즈니스 성과와 연계한 리서치 효능 분석

이제는 UX라는 직함이 아니라 실제 문제를 해결할 수 있는 능력이 중요한 시대입니다. 2025년, UX 리서처는 단순히 '사용자 조사만 하는 사람'이 아닌 '실질적인 비즈니스 문제를 해결하는 전문가'로 거듭나야 합니다.

2025년은 UX 업계의 중요한 전환점이 될 것 같습니다. 하지만 UX 리서처들에게는 오히려 기회일 수 있습니다. 탄탄한 리서치 역량을 바탕으로 진정한 비즈니스 문제 해결에 기여할 수 있다면, UX 리서처의 가치는 더욱 빛날 수 있을 테니까요.

https://www.linkedin.com/pulse/2025-ux-dead-long-live-problem-solving-anthony-sean-mcsharry-mxele/

최근 링크드인에서 화제가 된 글을 UX 리서처 관점에서 재해석해보았습니다. 이 글은 트레바리 &lt;리서치 하는데요&gt; 시즌4 멤버인 아름 님께서 소개해주셨습니다. 마침 2번째 모임에서 『대체 뭐가 문제야』라는 책을 함께 읽고 '문제 정의'에 대해 토론을 하며 UX를 업으로 하는 사람으로서 어떻게 문제를 제대로 정의하고, 근원적인 솔루션을 도출할 수 있을까? 고민했기에 다소 자극적인 포스팅이지만 가만히 생각해 볼 지점들도 있습니다. 시간을 들여서라도 원문을 꼭 함께 살펴보시면 좋겠습니다. Anthony Sean McSharry - LinkedIn 포스트 "2025 - UX is dead - Long live Problem Solving" [ 큐레이터의 문장 🎒 ] UX는 정말 죽었나? 현재 UX 업계는 중대한 위기를 맞이했다며 저자는 이렇게 주장합니다. 누구나 사용자 경험을 이야기하고 UX를 한다고 자신의 직무에 UX를 붙입니다. UX has become a joke - anyone can do (or rather not do) it and just add 'UX' to their title. UX란 말이 농담거리가 되어버렸어요. 누구나 UX를 한다고 하고(또는 하지도 않으면서), 그저 직함에 'UX'만 붙이면 그만입니다. 단순한 도발이라고 보기에는 현실적인 부분이 많습니다. 저자는 현재 UX 업계의 문제점을 이렇게 짚어냅니다. Focus on UI design, talk endlessly about 'empathy', use tools that cannot provide realistic usability tests, create hi-fidelity prototypes instead of hi-functioning prototypes, do not understand or do research, use made up Personas. UI 디자인에만 매달리고, '공감'이란 말만 반복하며, 실제 사용성 검증이 불가능한 도구들을 쓰고 있어요. 제대로 작동하는 프로토타입은 만들지 않으면서 겉모습만 그럴듯한 시안만 만들죠. 리서치는 이해하지도 못하고 수행하지도 않으면서 근거 없는 페르소나만 만들어냅니다. 진정한 UX의 역할은 무엇일까? 그렇다면 진정한 UX란 무엇일까요? 저자는 이렇게 설명합니다. UX 담당자가 해결해야 할 문제는 <ul><li>3가지 도메인(사용자, 비즈니스, 기술)을 모두 아우르며</li><li>디지털 뿐만 아니라 피지컬, 물리적 환경에서도 작동합니다</li><li>소프트웨어만큼 프로세스도 중요하고</li><li>운영 효율을 높이고</li><li>비용은 줄이면서</li><li>기능적으로 가치 있고 매력적인 해결책을 만들어내야 합니다</li></ul> UX 죽음에 책임있는 자들은 누구인가? <ol><li>UI 디자인에만 집중하는</li><li>'공감'에 대해 끝없이 이야기하는(구체적인 문제정의와 솔루션 없이)</li><li>현실적인 사용성 테스트를 제공할 수 없는 도구를 사용하는</li><li>고기능(High-functioning) 프로토타입 대신 그럴듯해보이는 프로토타입을 만드는</li><li>UX 리서치를 이해하지 못하거나 수행하지 않는</li><li>(AI 등을 통해) 만들어낸 페르소나를 사용하는</li><li>마케팅 카피를 쓰고 이를 UX라고 부르는</li><li>UX가 디지털에만 존재한다고 생각하는</li><li>아름답게 디자인된 포트폴리오를 가진</li><li>Figma 같은 쓸모없는 도구를 사용하는(Figma의 장점은 '쉬운 도구'라는 것인데 주객전도로 Figma로 리서치까지 모두 다 할 수 있다고 맹신하는)</li><li>기술을 이해하지 못하는</li><li>비즈니스를 이해하지 못하는</li><li>심리학이 그들의 결정과 작업에 어떤 영향을 미치는지 이해하지 못하는</li><li>직원을 사용자로 고려하지 않는</li><li>CX와 UX가 다른 것이라고 주장하는</li><li>서비스 디자인을 하지 않는(무엇이라 부르든)</li><li>애자일 내부에서 부분, 일부로 작동하는(애자일 스프린트가 시작되기 전에 충분한 리서치와 검증이 선행되어야 함)</li><li>이러한 믿음을 홍보하고 잘못된 내용을 리더들, 컨퍼런스에서 발표하는</li></ol> 2025년, 우리는 어디로 가야 하나? If you are a real UXer (a true problem solver) your value is more important than ever, but your title will have to change. (그럼에도) 진정한 UX 역할자, 즉 진정한 문제 해결자라면 당신의 가치는 그 어느 때보다 빛날 것입니다. 다만 직함은 바뀌어야 할 거예요. UX 리서처가 갖춰야 할 역량들 <ol><li>리서치 방법론 균형감각과 고도화<ul><li>정성적/정량적 리서치의 균형</li><li>비즈니스 지표와의 연계, 논리성</li></ul> </li><li>문제 해결 능력 강화<ul><li>정성적/정량적 데이터에 기반한 의사결정 지원</li><li>비즈니스/기술 영역에 대한 이해까지</li><li>실질적인 비즈니스 운영까지 고려</li></ul> </li><li>리서치 임팩트 입증<ul><li>리서치로 발견한 문제 해결에 대해 리서치 투자 대비 효과 측정 필요</li><li>비즈니스 성과와 연계한 리서치 효능 분석</li></ul></li></ol> 이제는 UX라는 직함이 아니라 실제 문제를 해결할 수 있는 능력이 중요한 시대입니다. 2025년, UX 리서처는 단순히 '사용자 조사만 하는 사람'이 아닌 '실질적인 비즈니스 문제를 해결하는 전문가'로 거듭나야 합니다. 2025년은 UX 업계의 중요한 전환점이 될 것 같습니다. 하지만 UX 리서처들에게는 오히려 기회일 수 있습니다. 탄탄한 리서치 역량을 바탕으로 진정한 비즈니스 문제 해결에 기여할 수 있다면, UX 리서처의 가치는 더욱 빛날 수 있을 테니까요. https://www.linkedin.com/pulse/2025-ux-dead-long-live-problem-solving-anthony-sean-mcsharry-mxele/

www.linkedin.com

《2025년 UX는 죽었다》

2023년말 OpenAI에서 샘 알트먼의 축출(?)에 큰 역할을 했다는 Open AI 공동창업자 일리야가 어떤 사람인지 궁금해서 뒤져보다가 The Guardian과 했던 인터뷰를 찾았다. iHuman이란 제목으로 The Guardian에서 만든 AI에 관한 다큐멘터리의 일부라는데 이 사람이 갖고 있는 AI(혹은 AGI)에 관한 생각을 엿볼 수 있는데 확실히 OpenAI가 보여주었던 행보와 다름을 느낄 수 있었다. 일부 생각해볼만한 것들을 정리해보았다.

 1. 먼저 AI가 여러가지 문제를 해결하겠지만 새로운 문제를 만들어낼 것이란 점을 분명히 했고 예로 가짜 뉴스와 사이버 공격의 범람, 자율 AI 무기와 안정적인 독재정권의 탄생을 든다.
 2. ChatGPT가 AGI로 발전할 것이라 믿고 있는 듯한 발언을 한다. 이 인터뷰때 일리야의 바디랭귀지를 보면 걱정을 많이 하고 있음을 느낄 수 있다 (내 감정이 이입된 것인지도 모르겠지만): "자신의 목표를 가진 완전히 자율적인 존재를 만들 수 있다고 확신하지만 이 존재들의 목표가 우리 인간의 목표와 일치하도록 하는 것이 중요하다"
 3. "What inspires you"라는 질문에 대해서는 사람이 할 수 있는데 기계가 할 수 없는 것들에 대한 철학적으로 접근해보는 것이라고 하며 "학습", "경험", "사고" 등이 무엇인지 질문해보는 것을 예로 든다.
 4. AGI(Artificial General Intelligence)를 '인간이 하는 모든 일이나 작업을 더 잘 할 수 있는 컴퓨터 시스템'로 정의를 하며 AGI가 생각보다 빨리 완성될 가능성이 높다고 믿기에 지금부터 AGI를 인류의 이익과 맞추는 작업이 필요하다고 이야기한다. 일리야는 AGI가 전문가들이 생각하는 것보다 빠르게 분명히 탄생할 것으로 믿는 것 같다.
 5. 첫 번째 AGI 시스템은 천 만개 이상의 주택의 에너지를 소모하는 딥러닝 전문 프로세서로 가득찬 거대 데이터 센터의 모양을 띨 것인데 이 첫 시스템의 믿음과 욕망을 인류에게 도움되도록 디자인하는 것이 중요하다고 말한다. 왜냐면 이런 시스템은 자연에서 생명체처럼 자기가 생존할 수 있는 형태로 발전할 것이라 처음 시작이 중요하다는 거다. 현재 사람과 동물간의 관계를 미래 AGI와 사람간의 관계로 설명한 부분도 참 흥미로왔다 (공존하겠지만 한쪽의 이익이 분명히 우선시된다)
 6. AGI를 먼저 만들려는 경쟁이 사실 시작된 셈이고 그래서 여러 나라들의 협업을 통해 AGI를 만드는 것이 중요하다는 말을 하며 아래 이야기로 끝을 맺는다.

"The future is going to be good for the AI regardless. It would be nice if it were good for humans as well"

AI를 이미 하나의 존재로 표현하는 부분이 인상적이며 언제 AGI라는 것이 가능해질지 궁금한데 미국 시간으로 2025년 1월 4일 오전 10시에 샘 알트먼이 올린 트윗을 보면 이런 내용이 있다.

i always wanted to write a six-word story. here it is:
___
near the singularity; unclear which side.

Singularity는 이 문맥에서는 인공지능이 인간의 지능을 넘어서는 시점을 이야기하는데 unclear which side라는 부분이 결국 인간에게 도움이 되는지 안되는지를 나타내는 것 같다. 어그로를 끌려는 마케팅인지는 모르겠지만 샘 알트먼의 이런 태도를 일리야가 싫어한 것은 아닌지 모르겠다.

다음 포스팅에서 일리야의 NeurIPS 2024에서 했던 "Sequence to sequence learning with neural networks: What a Decade"라는 톡의 내용을 요약해보고자 한다.

2023년말 OpenAI에서 샘 알트먼의 축출(?)에 큰 역할을 했다는 Open AI 공동창업자 일리야가 어떤 사람인지 궁금해서 뒤져보다가 The Guardian과 했던 인터뷰를 찾았다. iHuman이란 제목으로 The Guardian에서 만든 AI에 관한 다큐멘터리의 일부라는데 이 사람이 갖고 있는 AI(혹은 AGI)에 관한 생각을 엿볼 수 있는데 확실히 OpenAI가 보여주었던 행보와 다름을 느낄 수 있었다. 일부 생각해볼만한 것들을 정리해보았다. <ol ><li>먼저 AI가 여러가지 문제를 해결하겠지만 새로운 문제를 만들어낼 것이란 점을 분명히 했고 예로 가짜 뉴스와 사이버 공격의 범람, 자율 AI 무기와 안정적인 독재정권의 탄생을 든다.</li><li>ChatGPT가 AGI로 발전할 것이라 믿고 있는 듯한 발언을 한다. 이 인터뷰때 일리야의 바디랭귀지를 보면 걱정을 많이 하고 있음을 느낄 수 있다 (내 감정이 이입된 것인지도 모르겠지만): "자신의 목표를 가진 완전히 자율적인 존재를 만들 수 있다고 확신하지만 이 존재들의 목표가 우리 인간의 목표와 일치하도록 하는 것이 중요하다"</li><li>"What inspires you"라는 질문에 대해서는 사람이 할 수 있는데 기계가 할 수 없는 것들에 대한 철학적으로 접근해보는 것이라고 하며 "학습", "경험", "사고" 등이 무엇인지 질문해보는 것을 예로 든다.</li><li>AGI(Artificial General Intelligence)를 '인간이 하는 모든 일이나 작업을 더 잘 할 수 있는 컴퓨터 시스템'로 정의를 하며 AGI가 생각보다 빨리 완성될 가능성이 높다고 믿기에 지금부터 AGI를 인류의 이익과 맞추는 작업이 필요하다고 이야기한다. 일리야는 AGI가 전문가들이 생각하는 것보다 빠르게 분명히 탄생할 것으로 믿는 것 같다.</li><li>첫 번째 AGI 시스템은 천 만개 이상의 주택의 에너지를 소모하는 딥러닝 전문 프로세서로 가득찬 거대 데이터 센터의 모양을 띨 것인데 이 첫 시스템의 믿음과 욕망을 인류에게 도움되도록 디자인하는 것이 중요하다고 말한다. 왜냐면 이런 시스템은 자연에서 생명체처럼 자기가 생존할 수 있는 형태로 발전할 것이라 처음 시작이 중요하다는 거다. 현재 사람과 동물간의 관계를 미래 AGI와 사람간의 관계로 설명한 부분도 참 흥미로왔다 (공존하겠지만 한쪽의 이익이 분명히 우선시된다)</li><li>AGI를 먼저 만들려는 경쟁이 사실 시작된 셈이고 그래서 여러 나라들의 협업을 통해 AGI를 만드는 것이 중요하다는 말을 하며 아래 이야기로 끝을 맺는다.</li></ol> "The future is going to be good for the AI regardless. It would be nice if it were good for humans as well" AI를 이미 하나의 존재로 표현하는 부분이 인상적이며 언제 AGI라는 것이 가능해질지 궁금한데 미국 시간으로 2025년 1월 4일 오전 10시에 샘 알트먼이 올린 트윗을 보면 이런 내용이 있다. i always wanted to write a six-word story. here it is:___near the singularity; unclear which side. Singularity는 이 문맥에서는 인공지능이 인간의 지능을 넘어서는 시점을 이야기하는데 unclear which side라는 부분이 결국 인간에게 도움이 되는지 안되는지를 나타내는 것 같다. 어그로를 끌려는 마케팅인지는 모르겠지만 샘 알트먼의 이런 태도를 일리야가 싫어한 것은 아닌지 모르겠다. 다음 포스팅에서 일리야의 NeurIPS 2024에서 했던 "Sequence to sequence learning with neural networks: What a Decade"라는 톡의 내용을 요약해보고자 한다.

일리야 수츠케버 The Guardian 인터뷰 요약

This repo includes ChatGPT prompt curation to use ChatGPT and other LLM tools better. - f/awesome-chatgpt-prompts

GitHub - f/awesome-chatgpt-prompts: This repo includes ChatGPT prompt curation to use ChatGPT and other LLM tools better.

최근 ChatGPT를 사용하지 않는 사람을 찾아보기 힘들 만큼 많은 분들이 이를 활용하고 계십니다. 대부분은 프롬프트를 즉석에서 작성해 요청하는 경우가 많지만, 고품질 프롬프트를 사용하면 더욱 정교하고 만족스러운 결과를 얻을 수 있습니다.

GitHub의 Awesome ChatGPT Prompts는 다른 사용자들이 미리 만들어둔 고품질 프롬프트 209개를 체계적으로 정리해둔 저장소입니다.

이 프롬프트들은 다양한 분야에서 유용하게 활용할 수 있으며, 여러분의 작업 효율을 크게 향상시킬 수 있습니다.

주요 활용 방법:
 1. 웹사이트를 통한 검색
    https://prompts.chat/ 웹사이트를 이용하면 저장소의 내용을 쉽게 검색할 수 있습니다.
 2. CSV 파일 검색
    저장소 내 prompts.csv 파일은 (https://github.com/f/awesome-chatgpt-prompts/blob/main/prompts.csv) 프롬프트를 한눈에 확인하고, 웹브라우저에서 검색할 수 있도록 제공됩니다.
 3. 터미널에서 검색
    터미널 사용에 익숙하다면 저장소를 다운로드한 뒤, 제공된 스크립트인 find-prompt를 실행해 프롬프트를 빠르게 찾아볼 수 있습니다. (https://github.com/f/awesome-chatgpt-prompts/blob/main/scripts/find-prompt)

나만의 프롬프트 관리:
 * 본인만의 프롬프트를 정리하고 싶다면 CSV 파일에 직접 추가해 저장할 수 있어 관리도 편리합니다.

활용 팁:
저장소의 프롬프트를 참고해 ChatGPT를 더 효과적으로 활용해 보세요. 다른 사용자가 만들어둔 프롬프트를 살펴보고, 이를 참고해 나만의 프롬프트를 작성하면 ChatGPT와의 대화가 한층 더 풍부해질 것입니다.

GitHub 저장소 링크:
https://github.com/f/awesome-chatgpt-prompts

최근 ChatGPT를 사용하지 않는 사람을 찾아보기 힘들 만큼 많은 분들이 이를 활용하고 계십니다. 대부분은 프롬프트를 즉석에서 작성해 요청하는 경우가 많지만, 고품질 프롬프트를 사용하면 더욱 정교하고 만족스러운 결과를 얻을 수 있습니다. GitHub의 Awesome ChatGPT Prompts는 다른 사용자들이 미리 만들어둔 고품질 프롬프트 209개를 체계적으로 정리해둔 저장소입니다. 이 프롬프트들은 다양한 분야에서 유용하게 활용할 수 있으며, 여러분의 작업 효율을 크게 향상시킬 수 있습니다. 주요 활용 방법:<ol ><li>웹사이트를 통한 검색 https://prompts.chat/ 웹사이트를 이용하면 저장소의 내용을 쉽게 검색할 수 있습니다.</li><li>CSV 파일 검색 저장소 내 prompts.csv 파일은 (https://github.com/f/awesome-chatgpt-prompts/blob/main/prompts.csv) 프롬프트를 한눈에 확인하고, 웹브라우저에서 검색할 수 있도록 제공됩니다. </li><li>터미널에서 검색 터미널 사용에 익숙하다면 저장소를 다운로드한 뒤, 제공된 스크립트인 find-prompt를 실행해 프롬프트를 빠르게 찾아볼 수 있습니다. (https://github.com/f/awesome-chatgpt-prompts/blob/main/scripts/find-prompt) </li></ol> 나만의 프롬프트 관리:<ul ><li>본인만의 프롬프트를 정리하고 싶다면 CSV 파일에 직접 추가해 저장할 수 있어 관리도 편리합니다.</li></ul> 활용 팁:저장소의 프롬프트를 참고해 ChatGPT를 더 효과적으로 활용해 보세요. 다른 사용자가 만들어둔 프롬프트를 살펴보고, 이를 참고해 나만의 프롬프트를 작성하면 ChatGPT와의 대화가 한층 더 풍부해질 것입니다. GitHub 저장소 링크: https://github.com/f/awesome-chatgpt-prompts

GitHub

ChatGPT를 위한 고품질 프롬프트 모음

성공에 관한 두 가지 시각이 있다. 하나는 강점 강화고 다른 하나는 약점 보완이다. 어느 쪽이 정답일까?    직장생활을 하면서 자신의 강점과 장점을 인정받는 순간은 참 뿌듯하다. 그 장점으로 인해 리더가 된 경우 더 그렇다. 그런데 리더가 된 이후엔 강점이 곧 약점이 되기도 한다. 사례를 보자.      A팀장은 신입 시절부터 목표 집중력이 좋다는 말을 들어왔다. 결과를 낼 때까지 끈기있게 밀어붙이는 업무 스타일을 고수해왔다. 계획대로 되지 않은 일은 적극적으로 관여해 차질이 없게 하는

성공하는 리더는 강점을 강화한 사람도, 약점을 보완한 사람도 아니다

성공에 관한 두 가지 시각이 있다. 하나는 강점 강화고 다른 하나는 약점 보완이다. 어느 쪽이 정답일까?

직장생활을 하면서 자신의 강점과 장점을 인정받는 순간은 참 뿌듯하다. 그 장점으로 인해 리더가 된 경우 더 그렇다. 그런데 리더가 된 이후엔 강점이 곧 약점이 되기도 한다. 사례를 보자.

A팀장은 신입 시절부터 목표 집중력이 좋다는 말을 들어왔다. 결과를 낼 때까지 끈기있게 밀어붙이는 업무 스타일을 고수해왔다. 계획대로 되지 않은 일은 적극적으로 관여해 차질이 없게 하는 진행했다. 발군의 업무 추진력을 인정받아 팀장이 되었다.

A팀장은 변한 게 없다. 여전히 결과지향적이고 집중력이 탁월하다. 그런데, 팀장이 되고 나서는 하나의 일이 아니라 여러 프로젝트를 동시에 관리해야 하는데, 우선순위에 지나치게 집착하는 바람에 돌발 상황에 대처하지 못하는 일이 발생하기 시작했다.

하나의 프로젝트를 마치기 전에 다른 프로젝트를 시작하는 것도 어려워했다. 뜻대로 진행되지 않을 때 쉽게 화를 내고 짜증내는 일도 잦아졌다. 과거엔 전략 실행 능력이 탁월했다는 평가를 받았지만, 어느새 전략적 사고력이 상대적으로 떨어진다는 말이 나오기 시작했고, 최근엔 비전과 전략적 사고에서 최악의 평가를 받았다.

A팀장에게만 나타난 독특한 현상이라고 생각하는가? 그렇지 않다. 세계적인 조직심리학자 로버트 호건(Robert Hogan)은 리더십에 관한 연구들의 여러 연구시점, 다양한 장소, 다양한 집단을 종합해 성공하는 리더와 실패하는 리더에는 눈에 띄는 점이 있다는 사실을 발견했다.

성공하는 리더들 간의 공통점은 비교적 적지만, 실패하는 리더의 공통점은 훨씬 많았다. 그 공통점 중 하나는 바로 자신의 장점이 약점으로 변질되는 순간을 인식하지 못한다는 것이다(Hogan, R. (2017). Personality and the fate of organizations. Psychology Press.).

조직풍토조사(Organizational Clmate Survey)에서는 보수, 복리후생, 작업환경, 안전, 성취, 자율성, 사회적 지지 등에 대한 구성원들의 인식 수준을 측정한다. 흥미로운 점은 구성원들의 조직풍토 인식에 있어 최악을 만드는 요인이 바로 리더라는 점이다.

조직풍토 조성에 리더가 중요하다는 사실은 어떤 조직이나 알고 있다. 조직에서 누군가를 리더로 선정할 때는 조직풍토를 개선하고자 하는 의도가 깔린 것이다. 하지만, 리더의 강점은 언제든 약점이 될 수 있다.

매우 독립적인 사람이 리더가 되면 팀 구축과 육성에 약점을 보이고, 부하들에게 권한을 위양하지도 부하들 간의 갈등을 해결하지도 못한다. 매우 창의적인 사람이 리더가 되면 조직화하지 못하고 과업을 세밀하게 검토하지 못한다. 자기 주장과 의지과 확고한 사람이 리더가 되면 주변 사람과의 논쟁에서 이기려고 하고, 상사와 전략적 관점에 차이가 있을 경우 좁히지 못한다.

리더십에 있어 성공은 강점을 강화하는 것도 약점을 보완하는 것도 아니다. 자신의 강점이 약점이 될 수 있는 순간을 인식하고 적절히 대응할 수 있어야 한다. 섣불리 강점을 강화하라거나 약점을 보완하라는 조언을 해서는 안된다.

그렇다면, 강점을 유지하고 약점으로 변질되지 않게 만드는 대안은 무엇일까?

1️⃣가장 중요한 것은 자기 인식 강화다.
360도 피드백은 필수다. 비공식적 멘토들을 통해 피드백을 받는 것도 필요하다.

2️⃣적극적인 학습이다.
자신의 강점이 약점이 될 수 있음을 인지함과 동시에 이를 보완할 수 있는 효과적 대안을 시행하는 것이다. 효과적인 대안은 이미 많이 연구되어 있다. 학습이 부족할 뿐이다.

3️⃣경력 경로의 확대다.
조직 내 다양한 분야의 업무 경험과 사람들과의 인간관계를 경험하는 것은 보다 폭넓은 관점을 갖게 한다.

4️⃣균형잡힌 삶이다.
자아강도(ego strength)는 불균형 상태에서 강해진다. 아닌 줄 알면서도 끝까지 우길 때가 있다. 자아에 위협을 받는 상태여서다. 직장에서의 나 뿐만 아니라, 가정에서, 사회에서, 친구로서의 나 등 자아가 다양한 사람은 자아의 위협에 비교적 잘 대응할 수 있다.

그래서 직장 뿐만 아니라, 가정, 운동, 취미, 학습, 봉사활동, 사회 모임 등 다양한 장면에서 자아를 돌아보는 것은 자아 위협에 효과적으로 대응할 수 있는 방안이다.

리더로서 성공은 강점 강화도 약점 보완도 아닌, 리더가 되기 전의 강점이 리더가 된 후에 약점으로 변질되는 시점에 대한 인식과 대응이라는 것을 기억하자.

성공에 관한 두 가지 시각이 있다. 하나는 강점 강화고 다른 하나는 약점 보완이다. 어느 쪽이 정답일까? 직장생활을 하면서 자신의 강점과 장점을 인정받는 순간은 참 뿌듯하다. 그 장점으로 인해 리더가 된 경우 더 그렇다. 그런데 리더가 된 이후엔 강점이 곧 약점이 되기도 한다. 사례를 보자. A팀장은 신입 시절부터 목표 집중력이 좋다는 말을 들어왔다. 결과를 낼 때까지 끈기있게 밀어붙이는 업무 스타일을 고수해왔다. 계획대로 되지 않은 일은 적극적으로 관여해 차질이 없게 하는 진행했다. 발군의 업무 추진력을 인정받아 팀장이 되었다. A팀장은 변한 게 없다. 여전히 결과지향적이고 집중력이 탁월하다. 그런데, 팀장이 되고 나서는 하나의 일이 아니라 여러 프로젝트를 동시에 관리해야 하는데, 우선순위에 지나치게 집착하는 바람에 돌발 상황에 대처하지 못하는 일이 발생하기 시작했다. 하나의 프로젝트를 마치기 전에 다른 프로젝트를 시작하는 것도 어려워했다. 뜻대로 진행되지 않을 때 쉽게 화를 내고 짜증내는 일도 잦아졌다. 과거엔 전략 실행 능력이 탁월했다는 평가를 받았지만, 어느새 전략적 사고력이 상대적으로 떨어진다는 말이 나오기 시작했고, 최근엔 비전과 전략적 사고에서 최악의 평가를 받았다. A팀장에게만 나타난 독특한 현상이라고 생각하는가? 그렇지 않다. 세계적인 조직심리학자 로버트 호건(Robert Hogan)은 리더십에 관한 연구들의 여러 연구시점, 다양한 장소, 다양한 집단을 종합해 성공하는 리더와 실패하는 리더에는 눈에 띄는 점이 있다는 사실을 발견했다. 성공하는 리더들 간의 공통점은 비교적 적지만, 실패하는 리더의 공통점은 훨씬 많았다. 그 공통점 중 하나는 바로 자신의 장점이 약점으로 변질되는 순간을 인식하지 못한다는 것이다(Hogan, R. (2017). Personality and the fate of organizations. Psychology Press.). 조직풍토조사(Organizational Clmate Survey)에서는 보수, 복리후생, 작업환경, 안전, 성취, 자율성, 사회적 지지 등에 대한 구성원들의 인식 수준을 측정한다. 흥미로운 점은 구성원들의 조직풍토 인식에 있어 최악을 만드는 요인이 바로 리더라는 점이다. 조직풍토 조성에 리더가 중요하다는 사실은 어떤 조직이나 알고 있다. 조직에서 누군가를 리더로 선정할 때는 조직풍토를 개선하고자 하는 의도가 깔린 것이다. 하지만, 리더의 강점은 언제든 약점이 될 수 있다. 매우 독립적인 사람이 리더가 되면 팀 구축과 육성에 약점을 보이고, 부하들에게 권한을 위양하지도 부하들 간의 갈등을 해결하지도 못한다. 매우 창의적인 사람이 리더가 되면 조직화하지 못하고 과업을 세밀하게 검토하지 못한다. 자기 주장과 의지과 확고한 사람이 리더가 되면 주변 사람과의 논쟁에서 이기려고 하고, 상사와 전략적 관점에 차이가 있을 경우 좁히지 못한다. 리더십에 있어 성공은 강점을 강화하는 것도 약점을 보완하는 것도 아니다. 자신의 강점이 약점이 될 수 있는 순간을 인식하고 적절히 대응할 수 있어야 한다. 섣불리 강점을 강화하라거나 약점을 보완하라는 조언을 해서는 안된다. 그렇다면, 강점을 유지하고 약점으로 변질되지 않게 만드는 대안은 무엇일까? 1️⃣가장 중요한 것은 자기 인식 강화다.360도 피드백은 필수다. 비공식적 멘토들을 통해 피드백을 받는 것도 필요하다. 2️⃣적극적인 학습이다.자신의 강점이 약점이 될 수 있음을 인지함과 동시에 이를 보완할 수 있는 효과적 대안을 시행하는 것이다. 효과적인 대안은 이미 많이 연구되어 있다. 학습이 부족할 뿐이다. 3️⃣경력 경로의 확대다.조직 내 다양한 분야의 업무 경험과 사람들과의 인간관계를 경험하는 것은 보다 폭넓은 관점을 갖게 한다. 4️⃣균형잡힌 삶이다.자아강도(ego strength)는 불균형 상태에서 강해진다. 아닌 줄 알면서도 끝까지 우길 때가 있다. 자아에 위협을 받는 상태여서다. 직장에서의 나 뿐만 아니라, 가정에서, 사회에서, 친구로서의 나 등 자아가 다양한 사람은 자아의 위협에 비교적 잘 대응할 수 있다. 그래서 직장 뿐만 아니라, 가정, 운동, 취미, 학습, 봉사활동, 사회 모임 등 다양한 장면에서 자아를 돌아보는 것은 자아 위협에 효과적으로 대응할 수 있는 방안이다. 리더로서 성공은 강점 강화도 약점 보완도 아닌, 리더가 되기 전의 강점이 리더가 된 후에 약점으로 변질되는 시점에 대한 인식과 대응이라는 것을 기억하자.

ㅍㅍㅅㅅ

성공에 관한 두 가지 시각이 있다. 하나는 강점 강화고 다른 하나

개발/프로그래밍 무료 작품을 확인해보세요.

개발/프로그래밍 무료 - 전자책 - 최대 90% 할인! 웰컴 마크다운 - 리디

RIDI 에서 무료로 볼 수 있는 다양한 기술 서적을 제공하고 있네요. 저는 특정 기술 분야에 대한 체계적인 지식이 필요할 때, 책을 통해 학습하는 편인데요. RIDI에 있는 책들을 보니 목차와 내용이 매우 충실해 보입니다.

개인적으로는 종이책을 선호하지만, 전문적인 지식이 필요하거나 빠르게 읽어야 할 때 RIDI의 전자책이 유용할 것 같습니다. 또한, RIDI는 PC용 뷰어도 제공해주어서, 데스크톱 환경에서도 편리하게 독서를 즐길 수 있다는 점도 장점입니다.

https://ridibooks.com/category/free-books/2220

RIDI 에서 무료로 볼 수 있는 다양한 기술 서적을 제공하고 있네요. 저는 특정 기술 분야에 대한 체계적인 지식이 필요할 때, 책을 통해 학습하는 편인데요. RIDI에 있는 책들을 보니 목차와 내용이 매우 충실해 보입니다. 개인적으로는 종이책을 선호하지만, 전문적인 지식이 필요하거나 빠르게 읽어야 할 때 RIDI의 전자책이 유용할 것 같습니다. 또한, RIDI는 PC용 뷰어도 제공해주어서, 데스크톱 환경에서도 편리하게 독서를 즐길 수 있다는 점도 장점입니다. https://ridibooks.com/category/free-books/2220

리디

RIDI로 만나는 무료 기술 서적

[WEEKLY BIZ] 실리콘밸리 기업들은 '될 때까지 되는 척'한다

"전 세계 시가총액 1위 기업인 애플만 해도 성공의 도화선이었던 첫 아이폰 발표 당시 대량 생산된 아이폰이 출고 준비를 마친 것처럼 밝혔지만, 실상은 성능이 불안정한 시제품 몇십 개만 만들어 둔 상황이었다. 세계 전기차 시장을 개척한 테슬라 역시 조립 라인도 갖춰지지 않은 상황에서 차량 주문을 받아 생산 지연으로 집단소송 위기에 처한 적이 여러 번이다."

테라노스에 이어 미디어 스타트업 '오지'까지 사기가 드러났다. 실리콘밸리에서 대형 사기극이 횡행하는 이유는 "될 때까지 되는 척(fake it till you make it)” 하는 문화 때문. 과거 애플과 테슬라가 보여준 '허풍'과 테라노스식 '사기'를 어떻게 구분해야 할지가 최근의 화두.

n.news.naver.com

프로덕트 매니저/서비스 기획

한주현

플랫폼 기획자

유지현

성공할 창업가

류의성

대표

브랜드 마케터

브랜드 컨설턴트

광고기획자

Business

TBWA KOREA에서 광고를 시작해서 현재 광고대행사 이노션의 기획자(AE)로 일하고 있다. '임팩트가 없으면 죽음을' 이라는 모토를 가지고 광고를 만든다. 무신사 '다 여기서 사',  구글 어시스턴트 'Google에게 시키세요', 우르오스 '남자공학적' 같은 히트 캠페인을 기획했다.  현재 페이스북과 브런치에서 브랜드에 대한 재미있는 인사이트를 전하고 있다. 올 9월, 팔리는 브랜드의 비결을 담은 '드디어 팔리기 시작했다'를 출간했다.

브랜드보이

Brunch

Facebook

Youtube

브랜드 컨설팅 회사 <브랜드보이> 대표이자 유튜버, 작가, 강연자. 브랜드보이는 브랜드에 미친 남자다. 브랜드와 놀고, 브랜드로 돈까지 번다. 광고회사 TBWA, 이노션의 기획자를 거쳐 토스의 브랜드 마케터로 일했다. <믹스> <드디어 팔리기 시작했다>를 출간했다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필