Microsoft has quietly shelved its underwater data centre project, dubbed Project Natick, according to an interview with the company's head of cloud operations.

Microsoft quietly shelves underwater data centre project

2013년에 시작해서 10년간 열심히 친환경 홍보효과를 챙기고, 실제 2018년 북해에서 테스트를 시작하면서 기술 가능성도 확인되었고, 유망한 운영 이점도 찾았지만, 결과적으로 충분한 돈이 안되면 안한다는 것으로 밖에 해석이 안되는 결정입니다.

Microsoft가 해저 데이터 센터(프로젝트 Natick) 를 더 이상 운영하지 않기로 결정했습니다.
해저 데이터 센터는 데이터 센터의 수중 배치 가능성 테스트를 위해 스코틀랜드 바다 아래에 거대한 튜브를 설치하고 여러 가지 요소를 테스트했습니다.

산소가 아닌 질소로 채운 해저 데이터 센터는 육상 데이터 센터에 비해 고장률이 8분의 1에 불과해서 데이터 센터를 인간 생활 환경과 분리하면 열로 발생하는 전통적인 문제를 많이 해결할 수 있을 것으로 전망했습니다.

최적의 성능을 위한 환경을 조성하는 데 있어 사람과 기계는 매우 다른 요구 사항을 가지고 있다는 것을 찾아낸 것이죠.

마이크로소프트는 해저 데이터 센터 사용을 중단한 이유에 대해서는 공개하지 않고, 단지 이 프로젝트에서 얻은 교훈을 다른 사례에 활용할 것이라고 합니다. 뭐 사실 지상에 뚝딱 세우는 데이터센터에 비하면 얼마나 많은 고민거리, 전문인력, 행정절차가 필요하겠습니까. 뭐 중단할 이유가 100가지도 넘겠죠.

전 세계적으로 데이터 센터에 대한 수요는 엄청난 상황에서 마이크로소프트는 데이터 센터를 개선하기 위해 프로젝트 Natick에서 얻은 운영 경험은 사용하겠지만, 더 이상 운영은 하지 않겠다라는게 결정이네요. 좀 씁쓸하지만 이런 실험은 사실 기업보다는 국가에서 지원하는게 맞을듯도 합니다.

2013년에 시작해서 10년간 열심히 친환경 홍보효과를 챙기고, 실제 2018년 북해에서 테스트를 시작하면서 기술 가능성도 확인되었고, 유망한 운영 이점도 찾았지만, 결과적으로 충분한 돈이 안되면 안한다는 것으로 밖에 해석이 안되는 결정입니다. Microsoft가 해저 데이터 센터(프로젝트 Natick) 를 더 이상 운영하지 않기로 결정했습니다.해저 데이터 센터는 데이터 센터의 수중 배치 가능성 테스트를 위해 스코틀랜드 바다 아래에 거대한 튜브를 설치하고 여러 가지 요소를 테스트했습니다. 산소가 아닌 질소로 채운 해저 데이터 센터는 육상 데이터 센터에 비해 고장률이 8분의 1에 불과해서 데이터 센터를 인간 생활 환경과 분리하면 열로 발생하는 전통적인 문제를 많이 해결할 수 있을 것으로 전망했습니다. 최적의 성능을 위한 환경을 조성하는 데 있어 사람과 기계는 매우 다른 요구 사항을 가지고 있다는 것을 찾아낸 것이죠. 마이크로소프트는 해저 데이터 센터 사용을 중단한 이유에 대해서는 공개하지 않고, 단지 이 프로젝트에서 얻은 교훈을 다른 사례에 활용할 것이라고 합니다. 뭐 사실 지상에 뚝딱 세우는 데이터센터에 비하면 얼마나 많은 고민거리, 전문인력, 행정절차가 필요하겠습니까. 뭐 중단할 이유가 100가지도 넘겠죠. 전 세계적으로 데이터 센터에 대한 수요는 엄청난 상황에서 마이크로소프트는 데이터 센터를 개선하기 위해 프로젝트 Natick에서 얻은 운영 경험은 사용하겠지만, 더 이상 운영은 하지 않겠다라는게 결정이네요. 좀 씁쓸하지만 이런 실험은 사실 기업보다는 국가에서 지원하는게 맞을듯도 합니다.

Engineering and Technology Magazine

<마이크로소프트 해저 데이터센터 셧 다운 결정>

Large Language Models (LLMs) with billions of parameters have drastically transformed AI applications. However, their demanding computation during inference has raised significant challenges for deployment on resource-constrained devices.

ReLU Strikes Back: Exploiting Activation Sparsity in Large Language Models

오늘은 ICLR 2024에서 oral accept을 받은 논문 하나를 소개해보려 합니다.

ReLU Strikes Back: Exploiting Activation Sparsity in Large Language Models

요즘에 ReLU를 많이 쓰지 않는 것 같아요. GeLU와 SiLU와 같은 non-ReLU 계열들이 더 빠른 convergence를 가지고 성능 측면에서도 좋다는 결과들이 많이 등장했기 때문입니다.

그러나 이 논문에서는 scaling law에서 얘기하는 바처럼 충분히 많은 데이터로 큰 모델을 학습할 때는 activation function의 종류는 큰 영향을 주지 못한다고 말합니다. 실제로 OPT 1.3B에 대해 학습해보았을 때, ReLU, GeLU, SiLU에 대해 다 비슷비슷한 성능을 보였어요.

ReLU는 non-ReLU 계열들과 다르게 activation sparsity가 높습니다. pre-activation value가 음수면 모두 0으로 보내버리니 당연하겠죠? activation sparsity가 높으면 학습 및 추론에서 연산량을 줄일 수 있기 때문에 효율적입니다.

따라서 저자들은 성능도 비슷한데 효율적인 ReLU를 쓰는게 어떻냐고 제안했고 그 제안이 충분히 합리적이었기 때문에 oral accept을 받았다고 생각합니다. 논문에는 ReLU로 pre-train 되지 않은 모델들은 어떻게 ReLU를 사용하게 할지도 자세히 설명해주니 한번 읽어보시길 추천드려요!

오늘 모델 학습할 때는 ReLU 한잔 어떠실까요?

논문 링크: https://arxiv.org/abs/2310.04564

오늘은 ICLR 2024에서 oral accept을 받은 논문 하나를 소개해보려 합니다. ReLU Strikes Back: Exploiting Activation Sparsity in Large Language Models 요즘에 ReLU를 많이 쓰지 않는 것 같아요. GeLU와 SiLU와 같은 non-ReLU 계열들이 더 빠른 convergence를 가지고 성능 측면에서도 좋다는 결과들이 많이 등장했기 때문입니다. 그러나 이 논문에서는 scaling law에서 얘기하는 바처럼 충분히 많은 데이터로 큰 모델을 학습할 때는 activation function의 종류는 큰 영향을 주지 못한다고 말합니다. 실제로 OPT 1.3B에 대해 학습해보았을 때, ReLU, GeLU, SiLU에 대해 다 비슷비슷한 성능을 보였어요. ReLU는 non-ReLU 계열들과 다르게 activation sparsity가 높습니다. pre-activation value가 음수면 모두 0으로 보내버리니 당연하겠죠? activation sparsity가 높으면 학습 및 추론에서 연산량을 줄일 수 있기 때문에 효율적입니다. 따라서 저자들은 성능도 비슷한데 효율적인 ReLU를 쓰는게 어떻냐고 제안했고 그 제안이 충분히 합리적이었기 때문에 oral accept을 받았다고 생각합니다. 논문에는 ReLU로 pre-train 되지 않은 모델들은 어떻게 ReLU를 사용하게 할지도 자세히 설명해주니 한번 읽어보시길 추천드려요! 오늘 모델 학습할 때는 ReLU 한잔 어떠실까요? 논문 링크: https://arxiv.org/abs/2310.04564

arXiv.org

아직 죽지 않았다, ReLU!

AI 비즈니스의 지속 가능성을 위해 초기 비용 예산을 신중하게 고려하고, AI 서비스의 구축 방법별 비용 요인을 비교하며, 효과적인 예산 관리와 비용 절감 전략을 제시합니다.

AI의 경제학: 성공적인 AI 비즈니스를 위한 비용 최적화 전략 | 인사이트리포트 | 삼성SDS

삼성 SDS 인사이트 매거진에 기고한 글입니다.

AI는 혁신적인 기술이지만, 대다수의 AI 기업에서 매출과 비용의 균형을 맞추지 못해 재정적인 어려움을 겪고 있습니다. 한국의 스타트업들도 예외는 아니죠. 구체적인 매출 예상이 확실하지 않은 상황에서 사전에 비용 예산을 심각하게 고려하지 않아 기업 운영에 실패하는 사례가 발생하고 있습니다.
이유야 간단하죠. 뚜렷한 비즈니스 성과를 내지 못하고 있는 상황에서 생성형 AI 기술은 많은 비용이 요구되기 때문입니다.
***
비용(Cost)은 AI 비즈니스의 지속가능성을 평가할 때, 초기부터 가장 먼저 우선적으로 고려해야 할 요소입니다. 특히 생성형 AI는 도입 방법 및 사용자, 인터랙션 규모 등에 따라 예상치를 넘는 비용이 발생합니다. 글에서는 지속 가능한 AI 비즈니스를 위해 비용을 산출하고 관리하는 방법에 대해서 다뤄보고자 했습니다.

삼성 SDS 인사이트 매거진에 기고한 글입니다. AI는 혁신적인 기술이지만, 대다수의 AI 기업에서 매출과 비용의 균형을 맞추지 못해 재정적인 어려움을 겪고 있습니다. 한국의 스타트업들도 예외는 아니죠. 구체적인 매출 예상이 확실하지 않은 상황에서 사전에 비용 예산을 심각하게 고려하지 않아 기업 운영에 실패하는 사례가 발생하고 있습니다.이유야 간단하죠. 뚜렷한 비즈니스 성과를 내지 못하고 있는 상황에서 생성형 AI 기술은 많은 비용이 요구되기 때문입니다.***비용(Cost)은 AI 비즈니스의 지속가능성을 평가할 때, 초기부터 가장 먼저 우선적으로 고려해야 할 요소입니다. 특히 생성형 AI는 도입 방법 및 사용자, 인터랙션 규모 등에 따라 예상치를 넘는 비용이 발생합니다. 글에서는 지속 가능한 AI 비즈니스를 위해 비용을 산출하고 관리하는 방법에 대해서 다뤄보고자 했습니다.

Samsungsds

<성공적인 AI 비즈니스를 위한 비용 최적화 전략>

무려 37년전에 애플에서 만든 노코드 툴(!)의 원조 하이퍼카드의 웹 시뮬레이터. 저는 실제로 써 본 적은 없지만, 컨셉이 정말 매우 미래지향적입니다. 지금봐도 미래지향적임. 시뮬레이터 구현을 정말 잘 해 놨네요. 심심풀이 장난감으로 재밌습니다. 👍

무려 37년전에 애플에서 만든 노코드 툴(!)의 원조 하이퍼카드의 웹 시뮬레이터. 저는 실제로 써 본 적은 없지만, 컨셉이 정말 매우 미래지향적입니다. 지금봐도 미래지향적임. 시뮬레이터 구현을 정말 잘 해 놨네요. 심심풀이 장난감으로 재밌습니다. 👍

아참, 링크 👉 https://hcsimulator.com/

APM과 정적 분석 툴을 이해하고 효과적으로 활용하는 방법에 대해 설명합니다.

APM과 정적 분석 툴의 이해와 활용

F-Lab 에서 APM 과 정적 분석 툴에 대해 정리한 글이 있어 공유드립니다.

글에서 정리한 내용을 요약하자면 다음과 같습니다.

📌 APM(Application Performance Management)
APM(Application Performance Management)은 애플리케이션의 성능을 관리하고 최적화하기 위해 사용되는 도구입니다. 그래서 실시간으로 애플리케이션의 성능 데이터를 수집하고 분석하도록 구현되어 있습니다.

세계적으로 Dynatrace, New Relic, Cisco(AppDynamics)의 3사가 시장을 주도하고 있으며 국내에서는 제니퍼 소프트와 네이버의 Pinpoint 가 유명합니다.

APM 은 애플리케이션의 성능 지표를 실시간으로 수집 및 분석하기 때문에 문제가 발생했을 때 즉각적인 알림이 가능하고
이를 통해 개발자는 성능 저하 상황을 신속하게 파악하고 대응할 수 있는 장점이 있습니다.

📌 정적 분석 툴
정적 분석 툴은 코드의 품질을 개선하고 유지보수를 용이하게 합니다.
대표적으로 SonarQube 가 있으며, 이러한 정적 분석 툴은 코드의 복잡성, 중복, 코드 스멜 등을 분석하여 개선점을 제시합니다.

또한, 정적 분석 툴은 코드 내의 잠재적인 보안 위험도 식별하고, 개선 방안을 제시할 수 있어 보안 취약점을 탐지하고 개선하고자 할 때도 사용이 가능합니다.

좀 더 자세한 내용을 공유드린 원문 링크를 참고해주세요.

📚 원문
 * https://f-lab.kr/insight/understanding-apm-and-static-analysis-tools?gad_source=1&gclid=CjwKCAjwvvmzBhA2EiwAtHVrb8fJphZOdibK7tZmht05KLacNb-ynovPlSHf935Ebz6xMH1W9JvavhoCdoYQAvD_BwE

F-Lab 에서 APM 과 정적 분석 툴에 대해 정리한 글이 있어 공유드립니다. 글에서 정리한 내용을 요약하자면 다음과 같습니다. 📌 APM(Application Performance Management)APM(Application Performance Management)은 애플리케이션의 성능을 관리하고 최적화하기 위해 사용되는 도구입니다. 그래서 실시간으로 애플리케이션의 성능 데이터를 수집하고 분석하도록 구현되어 있습니다. 세계적으로 Dynatrace, New Relic, Cisco(AppDynamics)의 3사가 시장을 주도하고 있으며 국내에서는 제니퍼 소프트와 네이버의 Pinpoint 가 유명합니다. APM 은 애플리케이션의 성능 지표를 실시간으로 수집 및 분석하기 때문에 문제가 발생했을 때 즉각적인 알림이 가능하고 이를 통해 개발자는 성능 저하 상황을 신속하게 파악하고 대응할 수 있는 장점이 있습니다. 📌 정적 분석 툴정적 분석 툴은 코드의 품질을 개선하고 유지보수를 용이하게 합니다. 대표적으로 SonarQube 가 있으며, 이러한 정적 분석 툴은 코드의 복잡성, 중복, 코드 스멜 등을 분석하여 개선점을 제시합니다. 또한, 정적 분석 툴은 코드 내의 잠재적인 보안 위험도 식별하고, 개선 방안을 제시할 수 있어 보안 취약점을 탐지하고 개선하고자 할 때도 사용이 가능합니다. 좀 더 자세한 내용을 공유드린 원문 링크를 참고해주세요. 📚 원문<ul ><li>https://f-lab.kr/insight/understanding-apm-and-static-analysis-tools?gad_source=1&amp;gclid=CjwKCAjwvvmzBhA2EiwAtHVrb8fJphZOdibK7tZmht05KLacNb-ynovPlSHf935Ebz6xMH1W9JvavhoCdoYQAvD_BwE</li></ul>

F-Lab : 상위 1% 개발자들의 멘토링

🔬 APM과 정적 분석 툴의 이해와 활용

APIs (Application Programming Interfaces) are essential tools for developers, allowing them to... Tagged with javascript, beginners, api, opensource.

Free APIs You Need to Know About in 2024

세상에 제공되는 무료 API 들은 많겠지만,
그 중 재밌어 보이는 API 를 정리한 글이 있어 공유드립니다.

게임과 음악 심지어 NASA 와 NBA API 까지 있는게 재밌네요.

다양한 무료 API 들이 정리되어 있으니 관심있으신 분들은 한번 보시면 좋겠습니다.

📚 원문
 * https://dev.to/raajaryan/free-apis-you-need-to-know-about-in-2024-2ieg

세상에 제공되는 무료 API 들은 많겠지만,그 중 재밌어 보이는 API 를 정리한 글이 있어 공유드립니다. 게임과 음악 심지어 NASA 와 NBA API 까지 있는게 재밌네요. 다양한 무료 API 들이 정리되어 있으니 관심있으신 분들은 한번 보시면 좋겠습니다. 📚 원문<ul ><li>https://dev.to/raajaryan/free-apis-you-need-to-know-about-in-2024-2ieg</li></ul>

DEV Community

🚀 2024년 알아야 할 무료 API

인공지능(AI)과 머신러닝(ML) 기술의 급속한 발전은 소프트웨어 개발 프로젝트에 큰 변화를 불러오고 있습니다. 이러한 변화는 개발자들에게 새로운 숙제를 안겨주는 동시에 많은 기회를 제공할 것으로 보입니다. 즉, 앞으로는 머신러닝을 이해하고 활용할 수 있는 역량이 개발자의 경쟁력을 높이는 핵심 요소가 될 것입니다. 이번 글에서는 머신러닝의 기본 개념과 어떤 종류의 머신러닝이 있는지 살펴보고, 전반적인 머신러닝 개발 프로세스와 활용 사례를 알아보겠습니다.

'머신러닝' 기초 지식 톺아보기 | 요즘IT

최근 RAG 와 LLM Application 관련 프로젝트를 진행하면서 인공지능 분야에 대한 관심이 많아졌는데요,
그 중 중요한 개념인 머신러닝에 대한 기초 지식을 초보자도 이해할 수 있게 잘 정리된 글이 있어 공유드립니다.

사실 저도 처음에는 인공지능(AI), 머신러닝(ML), 딥러닝(Deep Learning) 이 모두 똑같은 개념인 줄 알았는데요,
알고보니 다른 개념이었고 이에 대한 내용은 다음과 같습니다.

📌 인공지능(AI) 이란?
인간의 지능을 모방하는 기술을 총칭하며, 머신러닝(ML), 딥러닝(Deep Learning)을 포함하는 상위 개념입니다.

📌 머신러닝(ML) 이란?
인공지능을 구현하는 방법론 중 하나로, 크게 지도 학습, 비지도 학습, 강화 학습으로 분류됩니다.
머신러닝 외에 인공지능을 구현하는 방법으로 규칙 기반, 논리 기반, 에이전트 기반 접근법 등이 있습니다.

📌 딥러닝(Deep Learning) 이란?
머신러닝의 한 종류입니다.
인공 신경망을 기반으로 한 심층 학습 기술로서 전통적인 머신러닝 기법에 비해 대규모의 데이터를 처리할 수 있으며, 이미지 인식, 음성 인식, 자연어 처리 등에서 널리 사용되고 있습니다.

머신러닝의 학습 유형과 개발 프로세스 등의 상세한 내용은 공유드린 원문 링크를 참고해주세요.

📚 원문
 * https://yozm.wishket.com/magazine/detail/2611/

최근 RAG 와 LLM Application 관련 프로젝트를 진행하면서 인공지능 분야에 대한 관심이 많아졌는데요,그 중 중요한 개념인 머신러닝에 대한 기초 지식을 초보자도 이해할 수 있게 잘 정리된 글이 있어 공유드립니다. 사실 저도 처음에는 인공지능(AI), 머신러닝(ML), 딥러닝(Deep Learning) 이 모두 똑같은 개념인 줄 알았는데요,알고보니 다른 개념이었고 이에 대한 내용은 다음과 같습니다. 📌 인공지능(AI) 이란?인간의 지능을 모방하는 기술을 총칭하며, 머신러닝(ML), 딥러닝(Deep Learning)을 포함하는 상위 개념입니다. 📌 머신러닝(ML) 이란?인공지능을 구현하는 방법론 중 하나로, 크게 지도 학습, 비지도 학습, 강화 학습으로 분류됩니다.머신러닝 외에 인공지능을 구현하는 방법으로 규칙 기반, 논리 기반, 에이전트 기반 접근법 등이 있습니다. 📌 딥러닝(Deep Learning) 이란?머신러닝의 한 종류입니다.인공 신경망을 기반으로 한 심층 학습 기술로서 전통적인 머신러닝 기법에 비해 대규모의 데이터를 처리할 수 있으며, 이미지 인식, 음성 인식, 자연어 처리 등에서 널리 사용되고 있습니다. 머신러닝의 학습 유형과 개발 프로세스 등의 상세한 내용은 공유드린 원문 링크를 참고해주세요. 📚 원문<ul ><li>https://yozm.wishket.com/magazine/detail/2611/</li></ul>

요즘IT

🤖 머신러닝 기초 지식 톺아보기

Milvus vector database documentation Milvus v2.3.x documentation

(아재 개그스러운 제목에 대해 먼저 사죄드립니다. 🙇🏻‍♂️)

Vector DB 란 scalar 데이터가 아닌 vector embedding 을 저장/인덱스/쿼리를 하는 DB 를 말합니다.
embedding model 를 통해 특정 dimension 으로 벡터화 된 값을 관련 메타데이터와 함께 하나의 엔티티로 저장하게 되는데요,
속도와 정확성간의 trade-off 를 위해 인덱스 생성 후 Approximate Nearest Neighbor (ANN) 검색을 하는 형태로 동작합니다.

최근 RAG 와 관련된 프로젝트를 진행하면서 Milvus 라는 Vector DB 를 사용하게 되었는데요,
저희가 Milvus 를 사용하게 된 이유는 다음과 같습니다.

 * ANN benchmark(https://ann-benchmarks.com/index.html) 에서 milvus 는 성능상 상위 랭커이다.
 * 커뮤니티가 활성화되어 있다.
 * sdk 가 잘 되어 있다. (python, Go, Java, etc)
 * langchain-community 패키지에 통합이 잘되어 있다.(langchain 은 LLM 기반 어플리케이션 구현을 지원해주는 Framework 입니다.)
 * k8s 환경에서 scale out, scale up, fail over 이 가능하다.
 * on-disk index 를 포함해서 다양한 index 를 지원한다. (DiskANN 을 최초로 지원)
 * 지속적으로 release 되면서 유지 보수되고 있다.
 * 오픈소스이다. 공짜다.
 * admin tool 인 attu 가 공식적으로 오픈소스로 제공되고 있어 milvus manage 가 쉽다.

현재까지 프로젝트 진행하면서 특별한 말썽(?)을 일으키지 않고 준수한 성능을 보여주어 매우 만족하고 있습니다.

혹시나 Vector DB 를 고민하고 계신 분들이 있다면 Milvus 도 한번 검토해보시면 좋을것 같습니다.

📚 함께 보면 좋은 글
 * Milvus Document: https://milvus.io/docs/v2.3.x
 * Devocean Milvus Quick Start: https://devocean.sk.com/blog/techBoardDetail.do?ID=165368

(아재 개그스러운 제목에 대해 먼저 사죄드립니다. 🙇🏻‍♂️) Vector DB 란 scalar 데이터가 아닌 vector embedding 을 저장/인덱스/쿼리를 하는 DB 를 말합니다.embedding model 를 통해 특정 dimension 으로 벡터화 된 값을 관련 메타데이터와 함께 하나의 엔티티로 저장하게 되는데요,속도와 정확성간의 trade-off 를 위해 인덱스 생성 후 Approximate Nearest Neighbor (ANN) 검색을 하는 형태로 동작합니다. 최근 RAG 와 관련된 프로젝트를 진행하면서 Milvus 라는 Vector DB 를 사용하게 되었는데요,저희가 Milvus 를 사용하게 된 이유는 다음과 같습니다. <ul ><li>ANN benchmark(https://ann-benchmarks.com/index.html) 에서 milvus 는 성능상 상위 랭커이다.</li><li>커뮤니티가 활성화되어 있다.</li><li>sdk 가 잘 되어 있다. (python, Go, Java, etc)</li><li>langchain-community 패키지에 통합이 잘되어 있다.(langchain 은 LLM 기반 어플리케이션 구현을 지원해주는 Framework 입니다.)</li><li>k8s 환경에서 scale out, scale up, fail over 이 가능하다.</li><li>on-disk index 를 포함해서 다양한 index 를 지원한다. (DiskANN 을 최초로 지원)</li><li>지속적으로 release 되면서 유지 보수되고 있다.</li><li>오픈소스이다. 공짜다.</li><li>admin tool 인 attu 가 공식적으로 오픈소스로 제공되고 있어 milvus manage 가 쉽다.</li></ul> 현재까지 프로젝트 진행하면서 특별한 말썽(?)을 일으키지 않고 준수한 성능을 보여주어 매우 만족하고 있습니다. 혹시나 Vector DB 를 고민하고 계신 분들이 있다면 Milvus 도 한번 검토해보시면 좋을것 같습니다. 📚 함께 보면 좋은 글<ul ><li>Milvus Document: https://milvus.io/docs/v2.3.x</li><li>Devocean Milvus Quick Start: https://devocean.sk.com/blog/techBoardDetail.do?ID=165368</li></ul>

milvus.io

🚌 Vector DB 버스 타실래요? Milvus!

📅 날짜: 7월 11일 (목)
🕙 시간: 오전 10시 - 오후 5시
📍 장소: 카카오강남오피스

NVIDIA와 KakaoCloud가 공동으로 주최하는 이번 부트캠프에서는 최신 AI 기술을 탐구하고, 실습을 통해 배울 수 있는 기회를 제공합니다. AI 개발자분들의 많은 참여 바랍니다!

📌 주요 프로그램
1. 오전 세션: AI 개발자를 위한 기술 세미나 (10:00 ~ 12:00)
- 스타트업을 위한 AI 솔루션 소개: 실무에서 바로 적용 가능한 NVIDIA의 AI 솔루션을 소개합니다.
- NVIDIA NIM 업데이트 및 Usecase 데모: 다양한 산업군에서 성공적으로 적용된 AI 사례를 통해 실질적인 인사이트를 얻을 수 있습니다.
- KakaoCloud와 클라우드 기술 소개: 카카오클라우드 서비스와 AI 개발을 위한 최신 클라우드 기술을 소개합니다.

2. 오후 세션: AI 인퍼런스 부트캠프 (13:30 ~ 17:00)
- TensorRT-LLM 및 Triton Inference Server, NIM 부트캠프: NVIDIA의 최신 도구들과 카카오클라우드 인프라를 활용하여 AI 모델을 개발하고, 효율성을 극대화하는 방법을 배울 수 있습니다.
- 실습 세션: 직접 코딩하고 실습해보는 시간을 통해 배운 내용을 바로 적용해 볼 수 있습니다.

💡 참고사항:
- 신청 마감: 6월 30일 (일)
- 참가비: 무료
- 참가 인원: 30명

AI 개발자라면 놓칠 수 없는 이번 기회를 꼭 잡으세요! 자세한 내용과 신청은 아래 페이지에서 확인하세요.

https://festa.io/events/ixXac5sghD6Um7dNMe1gBd

📅 날짜: 7월 11일 (목) 🕙 시간: 오전 10시 - 오후 5시 📍 장소: 카카오강남오피스 NVIDIA와 KakaoCloud가 공동으로 주최하는 이번 부트캠프에서는 최신 AI 기술을 탐구하고, 실습을 통해 배울 수 있는 기회를 제공합니다. AI 개발자분들의 많은 참여 바랍니다! 📌 주요 프로그램 1. 오전 세션: AI 개발자를 위한 기술 세미나 (10:00 ~ 12:00) - 스타트업을 위한 AI 솔루션 소개: 실무에서 바로 적용 가능한 NVIDIA의 AI 솔루션을 소개합니다. - NVIDIA NIM 업데이트 및 Usecase 데모: 다양한 산업군에서 성공적으로 적용된 AI 사례를 통해 실질적인 인사이트를 얻을 수 있습니다. - KakaoCloud와 클라우드 기술 소개: 카카오클라우드 서비스와 AI 개발을 위한 최신 클라우드 기술을 소개합니다. 2. 오후 세션: AI 인퍼런스 부트캠프 (13:30 ~ 17:00) - TensorRT-LLM 및 Triton Inference Server, NIM 부트캠프: NVIDIA의 최신 도구들과 카카오클라우드 인프라를 활용하여 AI 모델을 개발하고, 효율성을 극대화하는 방법을 배울 수 있습니다. - 실습 세션: 직접 코딩하고 실습해보는 시간을 통해 배운 내용을 바로 적용해 볼 수 있습니다. 💡 참고사항: - 신청 마감: 6월 30일 (일) - 참가비: 무료 - 참가 인원: 30명 AI 개발자라면 놓칠 수 없는 이번 기회를 꼭 잡으세요! 자세한 내용과 신청은 아래 페이지에서 확인하세요. https://festa.io/events/ixXac5sghD6Um7dNMe1gBd

Festa

[NVIDIA x KakaoCloud] 원데이 AI 개발자 부트캠프 �

대규모 트래픽을 감당하는 시스템 디자인의 핵심, 로드 밸런싱의 모든 것

로드 밸런싱 알고리즘 A to Z: 코드와 함께 파헤치는 5가지 전략

트래픽을 여러 서버에 분산시켜 과부하를 방지하고 응답 속도를 높여주기 위해 사용하는 장치가 로드 밸런서(Load Balancer) 인데요,

현업에서 가장 많이 사용되는 5가지 로드 밸런싱 알고리즘에 대한 장단점과 샘플 구현 코드까지 정리한 글이 있어 공유드립니다.

글에서 정리한 로드 밸런싱 알고리즘은 다음과 같습니다.

📌 라운드 로빈(Round Robin)
# 작동 원리
 * 요청이 목록의 첫 번째 서버로 전송됩니다.
 * 다음 요청은 두 번째 서버로 전송되는 식입니다.
 * 목록의 마지막 서버 다음에는 알고리즘이 첫 번째 서버로 돌아갑니다.
# 사용 시기
 * 모든 서버의 처리 능력이 비슷하고 요청 처리에 동등한 능력을 가진 경우.
 * 단순성과 부하의 고른 분산이 더 중요한 경우.
# 장점
 * 구현과 이해가 쉽습니다.
 * 트래픽의 고른 분산을 보장합니다.
# 단점
 * 서버 부하나 응답 시간을 고려하지 않습니다.
 * 서버의 처리 능력이 다를 경우 비효율성을 초래할 수 있습니다.

📌 가중 라운드 로빈(Weighted Round Robin)
# 작동 원리
 * 각 서버에는 처리 능력이나 가용 자원에 따라 가중치가 할당됩니다.
 * 높은 가중치의 서버는 들어오는 요청 중 비례적으로 더 큰 부분을 받습니다.
# 사용 시기
 * 서버의 처리 능력이나 가용 자원이 다를 때.
 * 각 서버의 용량에 따라 부하를 분산시키고 싶을 때.
# 장점
 * 서버 용량에 따라 부하를 균형 있게 조정합니다.
 * 서버 자원을 더 효율적으로 사용합니다.
# 단점
 * 단순 라운드 로빈보다 구현이 약간 더 복잡합니다.
 * 현재 서버 부하나 응답 시간을 고려하지 않습니다.

📌 최소 연결(Least Connections)
# 작동 원리
 * 각 서버의 활성 연결 수를 모니터링합니다.
 * 활성 연결 수가 가장 적은 서버에 들어오는 요청을 할당합니다.
# 사용 시기
 * 현재 활성 연결 수에 따라 부하를 분산시키고 싶을 때.
 * 서버의 처리 능력은 비슷하지만 동시 연결 수준이 다를 수 있을 때.
# 장점
 * 현재 서버 부하에 따라 더 역동적으로 부하를 균형 조정합니다.
 * 어떤 서버도 많은 수의 활성 연결로 과부하되는 것을 방지하는 데 도움이 됩니다.
# 단점
 * 서버의 처리 능력이 다를 경우 최적이 아닐 수 있습니다.
 * 각 서버의 활성 연결을 추적해야 합니다.

📌 최소 응답 시간(Least Response Time)
# 작동 원리
 * 각 서버의 응답 시간을 모니터링합니다.
 * 응답 시간이 가장 빠른 서버에 들어오는 요청을 할당합니다.
# 사용 시기
 * 응답 시간이 다양한 서버가 있고 요청을 가장 빠른 서버로 라우팅하고 싶을 때.
# 장점
 * 응답 시간이 가장 빠른 서버를 선택하여 전체 지연 시간을 최소화합니다.
 * 서버 응답 시간의 변화에 역동적으로 적응할 수 있습니다.
 * 빠른 응답을 제공하여 사용자 경험 개선에 도움이 됩니다.
# 단점
 * 분산 시스템에서 도전적일 수 있는 서버 응답 시간의 정확한 측정이 필요합니다.
 * 서버 부하나 연결 수와 같은 다른 요인을 고려하지 않을 수 있습니다.

📌 IP 해시(IP Hash)
# 작동 원리
 * 클라이언트의 IP 주소에서 해시 값을 계산하고 이를 사용하여 요청을 라우팅할 서버를 결정합니다.
# 사용 시기
 * 같은 클라이언트의 요청이 항상 같은 서버로 전달되어야 하는 세션 지속성(Session Persistence)이 필요할 때.
# 장점
 * 구현이 간단합니다.
 * Sticky Session이 필요한 애플리케이션에 유용합니다.
# 단점
 * 특정 IP 주소가 다른 주소보다 더 많은 트래픽을 생성할 경우 불균등한 부하 분산으로 이어질 수 있습니다.
 * 서버가 다운되면 해시 매핑을 재구성해야 하므로 유연성이 부족합니다.

샘플 구현 코드 등과 같은 상세한 내용은 공유드린 원문 링크를 참고해주세요.

📚 원문
 * https://maily.so/devpill/posts/67aebb20?utm_source=oneoneone

트래픽을 여러 서버에 분산시켜 과부하를 방지하고 응답 속도를 높여주기 위해 사용하는 장치가 로드 밸런서(Load Balancer) 인데요, 현업에서 가장 많이 사용되는 5가지 로드 밸런싱 알고리즘에 대한 장단점과 샘플 구현 코드까지 정리한 글이 있어 공유드립니다. 글에서 정리한 로드 밸런싱 알고리즘은 다음과 같습니다. 📌 라운드 로빈(Round Robin)# 작동 원리<ul ><li>요청이 목록의 첫 번째 서버로 전송됩니다.</li><li>다음 요청은 두 번째 서버로 전송되는 식입니다.</li><li>목록의 마지막 서버 다음에는 알고리즘이 첫 번째 서버로 돌아갑니다.</li></ul># 사용 시기<ul ><li>모든 서버의 처리 능력이 비슷하고 요청 처리에 동등한 능력을 가진 경우.</li><li>단순성과 부하의 고른 분산이 더 중요한 경우.</li></ul># 장점<ul ><li>구현과 이해가 쉽습니다.</li><li>트래픽의 고른 분산을 보장합니다.</li></ul># 단점<ul ><li>서버 부하나 응답 시간을 고려하지 않습니다.</li><li>서버의 처리 능력이 다를 경우 비효율성을 초래할 수 있습니다.</li></ul> 📌 가중 라운드 로빈(Weighted Round Robin)# 작동 원리<ul ><li>각 서버에는 처리 능력이나 가용 자원에 따라 가중치가 할당됩니다.</li><li>높은 가중치의 서버는 들어오는 요청 중 비례적으로 더 큰 부분을 받습니다.</li></ul># 사용 시기<ul ><li>서버의 처리 능력이나 가용 자원이 다를 때.</li><li>각 서버의 용량에 따라 부하를 분산시키고 싶을 때.</li></ul># 장점<ul ><li>서버 용량에 따라 부하를 균형 있게 조정합니다.</li><li>서버 자원을 더 효율적으로 사용합니다.</li></ul># 단점<ul ><li>단순 라운드 로빈보다 구현이 약간 더 복잡합니다.</li><li>현재 서버 부하나 응답 시간을 고려하지 않습니다.</li></ul> 📌 최소 연결(Least Connections)# 작동 원리<ul ><li>각 서버의 활성 연결 수를 모니터링합니다.</li><li>활성 연결 수가 가장 적은 서버에 들어오는 요청을 할당합니다.</li></ul># 사용 시기<ul ><li>현재 활성 연결 수에 따라 부하를 분산시키고 싶을 때.</li><li>서버의 처리 능력은 비슷하지만 동시 연결 수준이 다를 수 있을 때.</li></ul># 장점<ul ><li>현재 서버 부하에 따라 더 역동적으로 부하를 균형 조정합니다.</li><li>어떤 서버도 많은 수의 활성 연결로 과부하되는 것을 방지하는 데 도움이 됩니다.</li></ul># 단점<ul ><li>서버의 처리 능력이 다를 경우 최적이 아닐 수 있습니다.</li><li>각 서버의 활성 연결을 추적해야 합니다.</li></ul> 📌 최소 응답 시간(Least Response Time)# 작동 원리<ul ><li>각 서버의 응답 시간을 모니터링합니다.</li><li>응답 시간이 가장 빠른 서버에 들어오는 요청을 할당합니다.</li></ul># 사용 시기<ul ><li>응답 시간이 다양한 서버가 있고 요청을 가장 빠른 서버로 라우팅하고 싶을 때.</li></ul># 장점<ul ><li>응답 시간이 가장 빠른 서버를 선택하여 전체 지연 시간을 최소화합니다.</li><li>서버 응답 시간의 변화에 역동적으로 적응할 수 있습니다.</li><li>빠른 응답을 제공하여 사용자 경험 개선에 도움이 됩니다.</li></ul># 단점<ul ><li>분산 시스템에서 도전적일 수 있는 서버 응답 시간의 정확한 측정이 필요합니다.</li><li>서버 부하나 연결 수와 같은 다른 요인을 고려하지 않을 수 있습니다.</li></ul> 📌 IP 해시(IP Hash)# 작동 원리<ul ><li>클라이언트의 IP 주소에서 해시 값을 계산하고 이를 사용하여 요청을 라우팅할 서버를 결정합니다.</li></ul># 사용 시기<ul ><li>같은 클라이언트의 요청이 항상 같은 서버로 전달되어야 하는 세션 지속성(Session Persistence)이 필요할 때.</li></ul># 장점<ul ><li>구현이 간단합니다.</li><li>Sticky Session이 필요한 애플리케이션에 유용합니다.</li></ul># 단점<ul ><li>특정 IP 주소가 다른 주소보다 더 많은 트래픽을 생성할 경우 불균등한 부하 분산으로 이어질 수 있습니다.</li><li>서버가 다운되면 해시 매핑을 재구성해야 하므로 유연성이 부족합니다.</li></ul> 샘플 구현 코드 등과 같은 상세한 내용은 공유드린 원문 링크를 참고해주세요. 📚 원문<ul ><li>https://maily.so/devpill/posts/67aebb20?utm_source=oneoneone</li></ul>

데브필 DevPill

📈 로드 밸런싱 알고리즘 A to Z

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

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

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

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

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

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

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

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

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

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

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

코딩 놓으려 했는데

네이버 폼 설문에 바로 참여해 보세요.

[토스 프론트엔드 멘토링] Frontend Accelerator 1기에 지원하기

토스에서는 프론트엔드 멘토링 시스템 Frontend Accelerator 1기를 모집한다고 하네요.
Frontend Accelerator란 4주 동안 토스 프론트엔드 리드와 멘토-멘티의 관계를 맺어 토스 엔지니어링의 일하는 방식을 경험하고, 기술 관련 피드백을 얻는 프로그램인데요.
프로그램 종료 이후, 훌륭한 성장을 이뤄내신 분은 토스 Frontend Developer 채용 서류 패스 기회를 준다고 하니 좋은 기회가 될것 같습니다. 아래는 상세 내용 입니다

멘토링 진행 과정
 * 멘티에게 과제를 부여하고, 멘토는 가이드와 피드백을 주며 멘티가 리팩토링해나가는 과정을 함께합니다.
 * 멘토링은 모두 온라인으로 진행되며, 토스 슬랙 채널과 구글밋 미팅을 기반으로 진행됩니다.

일정
 * 7월 25일 ~ 8월 16일까지 1주일에 1회, 총 4회 정기 미팅을 진행합니다.
 * 이 외 시간에는 멘토와 멘티가 필요에 따라 자유롭게 소통합니다.

지원 대상
 * 프론트엔드 엔지니어로서 빠르게 성장을 경험하고 싶으신 분
 * 토스 프론트엔드 리드와의 네트워킹에 니즈가 있으신 분
 * 토스 프론트엔드 엔지니어가 실제로 마주하게 되는 문제를 함께 고민하고 싶으신 분

지원 자격
 * 3년 이하의 경험을 가진 분이라면 누구나 지원 가능합니다. 실무 경험이 없어도 괜찮습니다.

멘티 선발 과정
 1. 지원: 6월 17일 ~ 6월 26일까지
 2. 테스트: 6월 29일 (지원해주신 모든 분들께 테스트 참여의 기회가 부여됩니다.)
 3. 캐주얼챗: 7월 4일 ~ 7월 5일 중 조율 (테스트 합격자를 대상으로 캐주얼챗을 제안드립니다.)
 4. 선발 결과 발표: 7월 8일
 5. 멘토링 기간: 7월 25일 ~ 8월 16일 (주 1회, 1시간씩 온라인 미팅을 진행합니다.)

지원 방법
 * 6월 17일 ~ 6월 26일까지 이력서 없이 간단한 답변만으로 누구나 지원이 가능합니다.
 * 지원해주신 모든 분들께 6월 29일 온라인 테스트 (20분 소요)의 기회가 부여됩니다.

토스에 채용이 되지 않는다고 해도 멘토링을 하면서 많이 성장할 수 있는 기회가 될것 같습니다. 3년 이하의 주니어 분들은 지원을 해보시는것을 추천드립니다.

토스에서는 프론트엔드 멘토링 시스템 Frontend Accelerator 1기를 모집한다고 하네요.Frontend Accelerator란 4주 동안 토스 프론트엔드 리드와 멘토-멘티의 관계를 맺어 토스 엔지니어링의 일하는 방식을 경험하고, 기술 관련 피드백을 얻는 프로그램인데요.프로그램 종료 이후, 훌륭한 성장을 이뤄내신 분은 토스 Frontend Developer 채용 서류 패스 기회를 준다고 하니 좋은 기회가 될것 같습니다. 아래는 상세 내용 입니다 멘토링 진행 과정<ul ><li>멘티에게 과제를 부여하고, 멘토는 가이드와 피드백을 주며 멘티가 리팩토링해나가는 과정을 함께합니다.</li><li>멘토링은 모두 온라인으로 진행되며, 토스 슬랙 채널과 구글밋 미팅을 기반으로 진행됩니다.</li></ul> 일정<ul ><li>7월 25일 ~ 8월 16일까지 1주일에 1회, 총 4회 정기 미팅을 진행합니다.</li><li>이 외 시간에는 멘토와 멘티가 필요에 따라 자유롭게 소통합니다.</li></ul> 지원 대상<ul ><li>프론트엔드 엔지니어로서 빠르게 성장을 경험하고 싶으신 분</li><li>토스 프론트엔드 리드와의 네트워킹에 니즈가 있으신 분</li><li>토스 프론트엔드 엔지니어가 실제로 마주하게 되는 문제를 함께 고민하고 싶으신 분</li></ul> 지원 자격<ul ><li>3년 이하의 경험을 가진 분이라면 누구나 지원 가능합니다. 실무 경험이 없어도 괜찮습니다.</li></ul> 멘티 선발 과정<ol ><li>지원: 6월 17일 ~ 6월 26일까지</li><li>테스트: 6월 29일 (지원해주신 모든 분들께 테스트 참여의 기회가 부여됩니다.)</li><li>캐주얼챗: 7월 4일 ~ 7월 5일 중 조율 (테스트 합격자를 대상으로 캐주얼챗을 제안드립니다.)</li><li>선발 결과 발표: 7월 8일</li><li>멘토링 기간: 7월 25일 ~ 8월 16일 (주 1회, 1시간씩 온라인 미팅을 진행합니다.)</li></ol> 지원 방법<ul ><li>6월 17일 ~ 6월 26일까지 이력서 없이 간단한 답변만으로 누구나 지원이 가능합니다.</li><li>지원해주신 모든 분들께 6월 29일 온라인 테스트 (20분 소요)의 기회가 부여됩니다.</li></ul> 토스에 채용이 되지 않는다고 해도 멘토링을 하면서 많이 성장할 수 있는 기회가 될것 같습니다. 3년 이하의 주니어 분들은 지원을 해보시는것을 추천드립니다.

네이버 폼

토스 프론트엔드 멘토링 시스템 "Accelerator 1기 모집"

『소프트웨어 장인』에 이은 또 한 권의 '로버트 C. 마틴 시리즈' 베스트셀러!70년 동안 개발자들에게 검증 받은 개발 방법론과 주옥 같은 팁들을 한 권으로 총 정리! `좋은 소프트웨어 설계를 하라`는 말에 명확한 답과 방법을 떠올릴 수 있는가? 개발은 명확한...

읽기 쉬운 코드 - 예스24

안녕하세요. 오늘은 최근에 읽은 책 소개를 하나 할까 합니다.

종종 주니어 개발자 분들과 이야기를 나누다보면 '읽기 좋은 코드란 무엇일까요?' '코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?' 라는 질문을 많이 받곤 합니다. 그 기준은 무엇이고, 어떻게 발전 시킬수 있을지에 대한 고민도 많이 듣게되구요.

종종 주니어 개발자들과의 대화에서 "읽기 좋은 코드란 무엇일까요?", "코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?"에 대한 질문을 많이 받습니다. 그런 코드를 위해 구체적으로 어떤 방식으로 코드를 작성해야 하는지, 발전시킬수 있는지에 대해서도 질문을 많이 듣습니다.

생각나는 여러 기준을 제시하며 대화를 나누곤 했지만, 그러한 기준을 정확히 어디서 배웠고 어떻게 내재화하게 되었는지 생각해보면 그 출처가 명확하지 않았습니다. 나름 선호하는 코드 스타일과 개선이 필요한 코드를 식별하고 규칙을 만들어 적용해왔지만, 도움이 될 수 있는 구체적인 액션 아이템을 제시할때는 어려움을 느끼곤 했습니다.

그러다 최근 이 두 책을 제공받아 읽게 되었습니다. 그러다 최근 두 권의 책을 읽게 되었습니다. 이 책들은 좋은 코드를 작성하기 위한 기준과 코드에 안정성을 부여하는 방법에 대해 명확한 저자의 관점으로 구체적인 예시와 함께 설명하고 있습니다. 여러 곳에서 배운 지식들을 체계적으로 정리하고 재조명할 수 있는 좋은 기회가 되었습니다.

최근 비슷한 고민을 하는 개발자들뿐만 아니라 주니어 개발자들에게도 명확한 지침서가 될 수 있을 것이라 생각되어 다음 책들을 추천합니다. 목차를 확인해보시고 관심이 간다면 주문하여 읽어보시길 바랍니다.

 * 읽기 쉬운 코드: http://gilbut.co/c/24034992MF
 * 코드 작성 가이드: http://gilbut.co/c/24046947nM

안녕하세요. 오늘은 최근에 읽은 책 소개를 하나 할까 합니다. 종종 주니어 개발자 분들과 이야기를 나누다보면 '읽기 좋은 코드란 무엇일까요?' '코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?' 라는 질문을 많이 받곤 합니다. 그 기준은 무엇이고, 어떻게 발전 시킬수 있을지에 대한 고민도 많이 듣게되구요. 종종 주니어 개발자들과의 대화에서 "읽기 좋은 코드란 무엇일까요?", "코드를 어떻게 하면 읽기 좋게 작성할 수 있을까요?"에 대한 질문을 많이 받습니다. 그런 코드를 위해 구체적으로 어떤 방식으로 코드를 작성해야 하는지, 발전시킬수 있는지에 대해서도 질문을 많이 듣습니다. 생각나는 여러 기준을 제시하며 대화를 나누곤 했지만, 그러한 기준을 정확히 어디서 배웠고 어떻게 내재화하게 되었는지 생각해보면 그 출처가 명확하지 않았습니다. 나름 선호하는 코드 스타일과 개선이 필요한 코드를 식별하고 규칙을 만들어 적용해왔지만, 도움이 될 수 있는 구체적인 액션 아이템을 제시할때는 어려움을 느끼곤 했습니다. 그러다 최근 이 두 책을 제공받아 읽게 되었습니다. 그러다 최근 두 권의 책을 읽게 되었습니다. 이 책들은 좋은 코드를 작성하기 위한 기준과 코드에 안정성을 부여하는 방법에 대해 명확한 저자의 관점으로 구체적인 예시와 함께 설명하고 있습니다. 여러 곳에서 배운 지식들을 체계적으로 정리하고 재조명할 수 있는 좋은 기회가 되었습니다. 최근 비슷한 고민을 하는 개발자들뿐만 아니라 주니어 개발자들에게도 명확한 지침서가 될 수 있을 것이라 생각되어 다음 책들을 추천합니다. 목차를 확인해보시고 관심이 간다면 주문하여 읽어보시길 바랍니다. <ul ><li>읽기 쉬운 코드: http://gilbut.co/c/24034992MF</li><li>코드 작성 가이드: http://gilbut.co/c/24046947nM</li></ul>

예스24

읽기 쉬운 코드 / 코드 작성 가이드

일본인 정원사 '이 한마디', 엔비디아 젠슨 황 인생 바꿨다, 엔비디아 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

한국경제

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

In business, being a nice person in the room can be more impactful than being the smartest. I share my insights on empathy, respect, and active listening as key skills for successful meetings and creating a positive team environment.

Do not try to be the smartest in the room; try to be the kindest. | Jorge Galindo's blog

"가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요."

"잘 듣고, 존중하고, 공감하고, 해결 중심 접근 방식을 통해 팀의 생산성을 향상 시킬 수 있습니다."

"친절함은 전염성이 있습니다. 당신이 친절하기 시작하면 다른 사람들도 친절해질 것이고, 팀 전체에 영향을 끼칠 것입니다"

"가장 똑똑한 사람은 몇몇 사람이 그리워 하지만, 친절한 사람은 모두가 그리워 합니다"

https://www.jorgegalindo.me/en/blog/posts/do-not-be-the-smartest-in-the-room-try-to-be-the-kindest

"가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요." "잘 듣고, 존중하고, 공감하고, 해결 중심 접근 방식을 통해 팀의 생산성을 향상 시킬 수 있습니다." "친절함은 전염성이 있습니다. 당신이 친절하기 시작하면 다른 사람들도 친절해질 것이고, 팀 전체에 영향을 끼칠 것입니다" "가장 똑똑한 사람은 몇몇 사람이 그리워 하지만, 친절한 사람은 모두가 그리워 합니다" https://www.jorgegalindo.me/en/blog/posts/do-not-be-the-smartest-in-the-room-try-to-be-the-kindest

Jorgegalindo

가장 똑똑한 사람이 아닌 가장 친절한 사람이 되세요

들어가며 안녕하세요. 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

라인에서 Cache를 사용할 때 발생하는 Thundering He

[#유퀴즈온더블럭] 천우희가 외모 때문에 오디션 떨어졌었다고😲? 예쁘고 귀엽고 사랑스러운데 연기까지 잘해버려서 세상이 질투했나 보다😎

1. “(데뷔 전에 오디션을 볼 떄) ‘배우 할 수 없다. 못 생겼다' 이런 얘기를 많이 들었어요"

2. “그 당시 허탈함이 있었는데, 그렇게 저한테 타격감은 없었어요. 저는 힘들 걸 ‘너무 힘들다' 이러는 성격이 아니고, ‘와~ 얼마나 잘 되려고 (지금) 이럴까?’ 이렇게 생각하는 편이에요"

3. “집에서 알바할 때도, 제가 전을 직접 부쳤거든요. 하면서도 ‘내 인생이 점점 버라이어티해지는군. 재밌겠어', 약간 이렇게 생각하고"

4. “그냥 이런 생각을 많이 했어요. ‘에피소드 하나 더 생긴다고 생각하지 뭐~', 약간 이렇게" (갈등 = 에피소드)

5. “(그런 상황에서도) 내가 할 수 있는 게 뭘까? 좀 자기 객관화를 해야겠다는 생각이 들더라고요. ‘내가 가지고 있는 포지션과 내가 가지고 있는 강점이 뭐지?’라는 생각을 하면서, 제가 나이대에 있는 배우들을 다 검색해봤어요" (=치열한 자료 조사)

6. “다 검색해봤는데, 저랑 느낌이 비슷한 사람은 없더라고요. (그래서) 그냥 그 치기 어린 나이에 생각했던 건 나는 ‘모 아니면 도다’였어요”

7. “크게 절망하지 않았던 게, 좌절하지 않았던 게, ‘(못 생겨서 배우를 할 수 없다면 하면) 내가 한 번 보여주지. 내가 이 얼굴로 배우의 얼굴이 뭐가 좋은지 진짜 보여줄게’, 이런 마음이 있었어요” (=의지력)

8. “똑같은 상황이라도, 저는 결국 ‘마음가짐’이라고 생각하거든요. 힘들다 힘들다 생각하면 그 생각 안에서 (내가) 못 벗어나는 거에요? 그래서 ‘얼마나 잘 되려고 이럴까?'라고 생각하면서 항상 좋은 면을 생각해보려고 하죠"

- 배우 천우희

https://www.youtube.com/watch?v=dyuaT8xyvDg&t=599s

1. “(데뷔 전에 오디션을 볼 떄) ‘배우 할 수 없다. 못 생겼다' 이런 얘기를 많이 들었어요" 2. “그 당시 허탈함이 있었는데, 그렇게 저한테 타격감은 없었어요. 저는 힘들 걸 ‘너무 힘들다' 이러는 성격이 아니고, ‘와~ 얼마나 잘 되려고 (지금) 이럴까?’ 이렇게 생각하는 편이에요" 3. “집에서 알바할 때도, 제가 전을 직접 부쳤거든요. 하면서도 ‘내 인생이 점점 버라이어티해지는군. 재밌겠어', 약간 이렇게 생각하고" 4. “그냥 이런 생각을 많이 했어요. ‘에피소드 하나 더 생긴다고 생각하지 뭐~', 약간 이렇게" (갈등 = 에피소드) 5. “(그런 상황에서도) 내가 할 수 있는 게 뭘까? 좀 자기 객관화를 해야겠다는 생각이 들더라고요. ‘내가 가지고 있는 포지션과 내가 가지고 있는 강점이 뭐지?’라는 생각을 하면서, 제가 나이대에 있는 배우들을 다 검색해봤어요" (=치열한 자료 조사) 6. “다 검색해봤는데, 저랑 느낌이 비슷한 사람은 없더라고요. (그래서) 그냥 그 치기 어린 나이에 생각했던 건 나는 ‘모 아니면 도다’였어요” 7. “크게 절망하지 않았던 게, 좌절하지 않았던 게, ‘(못 생겨서 배우를 할 수 없다면 하면) 내가 한 번 보여주지. 내가 이 얼굴로 배우의 얼굴이 뭐가 좋은지 진짜 보여줄게’, 이런 마음이 있었어요” (=의지력) 8. “똑같은 상황이라도, 저는 결국 ‘마음가짐’이라고 생각하거든요. 힘들다 힘들다 생각하면 그 생각 안에서 (내가) 못 벗어나는 거에요? 그래서 ‘얼마나 잘 되려고 이럴까?'라고 생각하면서 항상 좋은 면을 생각해보려고 하죠" - 배우 천우희 https://www.youtube.com/watch?v=dyuaT8xyvDg&amp;t=599s

YouTube

배우 천우희의 스토리적 사고

Google Maps will start showing you slower routes. Here's why

《2분 더 걸려도 Green Route로 가실래요? 🍃》

구글 맵(Google Maps)이 새로운 경로 탐색 기능을 추가했습니다. 지금까지는 가장 빠른 길을 기본으로 안내했고 사용자 대부분은 구글이 추천한 경로를 그대로 따라가는 패턴을 보였는데요. 이젠 나뭇잎 모양을 눌러 조금 느리지만, 이산화탄소가 더 적게 나오는 경로를 선택할 수 있는 기능을 추가했습니다. 가장 빠른 길과 비교해 늘어나는 시간, 이산화탄소를 줄이는 정도를 "8% lower CO2 emissions"와 같이 표기하는게 특징이죠. 현재는 조금 더 걷는 방식으로 Green Route를 제안하지만 자동차 대신 기차, 자전거를 타면 얼마나 이산화탄소 배출을 줄일 수 있는지도 추가할 계획입니다.

[ 큐레이터의 문장 🎒 ]

생각해 볼 대목이 있습니다.

➊ 구글은 넛지 개념을 적용해 사용자 행동을 환경에 더 나은 방식으로 변화하려는 시도를 하고 있습니다. "2분 정도 걸어갈 수 있지"라며 Green Route를 선택하는 사용자가 적지 않을 테니까요.

➋ 구글이 서비스하는 내비게이션 서비스 'Waze'는 더 빠른 길 안내를 위해 조용한 동네, 골목길로 길 안내를 한다는 이유로 비난을 받았는데요. Green Route가 지역 주민들의 반발을 사지 않도록 최적화할 필요가 있습니다.

[ 함께 보면 좋은 콘텐츠 📮 ]

➊ REDBUSBAGMAN, 《여행은 발견하는 거야!》
https://www.redbusbagman.com/googlemapslocalguide

➋ REDBUSBAGMAN, 《Google Maps가 모빌리티서비스 시장을 움직이는 방법》
https://www.redbusbagman.com/trendreport201908/

Fast Company

Marketer

YINA

손창우

송도현

도시 마이크로모빌리티 로봇 등에 관심이 많습니다. 

Figma

UX 디자인

글쓰기

데이터 분석

브랜드 디자인

사용자 조사

인터랙션 디자인

콘텐츠 기획

'더 나은 도시생활'을 만드는 에피소드, 솔루션으로서의 주거상품을 만들기 위해 공간에서의 사용자 경험을 정의합니다.

[프로젝트]

- 에피소드 용산 241 (2023~present)
- 에피소드 신촌2 (2024~present)
- 에피소드 남산 (2023~present)

Space UX Researcher

CX(Customer eXperience) Lead 

1. Robo-taxi Customer eXperience (UX, Fleet, Space, Voice)
2. UX Design (RSI, Rear-Seat Infotainment)
3. UX Writing (Map Studio, RSI, Roof Indicator)

Customer Experience Design Lead

Senior UX Designer

1. Define 'SKT Service Design Identity'
2. T place(next TPS, T Premium Store) Service Design lead
3. SKT Smart Office Experience Design lead
4. SKT Recruiting Experience Design lead

Senior UX Designer

Conducting both qualitative and quantitative UX research for advertisers, sellers and consumers as well.

Senior UX Researcher

UX Researcher working for CX(Customer eXperiecne) Team and before in charge of SAMSUNG Nexshop Marketing solution concept design and schematic development in Samsung SDS Big Data Biz Unit. This solution is designed for retail business to provide a better shopping experience with customer behavior analytics.

UX Researcher

UX Designer working for Digital Customer Experience Team, while in charge of CXI(Customer eXperience Innovation).

1. Define HMC new SI(Service Identity) straightened to brand architecture.
 - Equipped the first half 2018 HMC Brand Strategy Committee
2. Develop 'Quality Time' service design theme and visualize Out-of-Car service use cases.
3. Design In-Car experience (Quality Drive) & Out-of-Car experience (Quality Time) along with Baidu to make new digital services fit for the Chinese auto

Design Management

심리학, 경제학, 철학

경험을 들여다봅니다. 심리학과 철학, 디자인경영을 공부했습니다. 현대차와 SK텔레콤, 자율주행 스타트업, 이커머스 기업을 거쳐 오프라인에서 더 나은 경험을 만들기 위해 UX 리서처로 일합니다. UX 리서처에게는 현상을 들여다보는 내적 호기심, 상대가 말하고 싶은 것을 묻는 공감, 표면과 근본을 구분해서 사고하는 균형감각이 중요하다고 믿습니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필