Bard is now Gemini. Get help with writing, planning, learning, and more from Google AI.

‎Gemini - chat to supercharge your ideas

https://gemini.google.com/
구글이 Gemini 2.5 Pro (실험 버전)를 무료로 풀었습니다!
리더보드에서는 Gemini 2.5 Pro 가 꽤 격차를 내며, 1위를 달리고 있는데요. 개인적으로도 역대 가장 좋은 성능을 체감하고 있습니다.
가장 진보된 모델(실험 버전이긴 하지만)의 전면 무료화는 매우 공격적인 전략으로 보이는데요. OpenAI(ChatGPT)나 Anthropic(Claude) 등 경쟁사들의 유료 모델과 직접 경쟁하면서, 사용자들에게 '무료'라는 강력한 유인책을 제공하여 시장 점유율을 빼앗아 오려는 의도로 볼 수 있습니다.

과연 이 전략은 성공할 수 있을까요?

참고로 현재 제한된 횟수 안에서 API 도 무료로 사용가능합니다.
- 무료 : RPM 5, RPD 25
- 유료 : RPM 20, RPD 100

더 보기
- Google, Gemini 2.5 Pro 출시 - 따라올테면 따라와봐
https://www.facebook.com/share/p/1AQWWGuMt1/

- OpenAI를 따라잡기 위한 구글의 2년간의 분투기
https://www.facebook.com/share/p/18rSta3Hf2/

#구글Gemini #AI전쟁 #ChatGPT #Claude #무료AI #기술경쟁

https://gemini.google.com/구글이 Gemini 2.5 Pro (실험 버전)를 무료로 풀었습니다!리더보드에서는 Gemini 2.5 Pro 가 꽤 격차를 내며, 1위를 달리고 있는데요. 개인적으로도 역대 가장 좋은 성능을 체감하고 있습니다.가장 진보된 모델(실험 버전이긴 하지만)의 전면 무료화는 매우 공격적인 전략으로 보이는데요. OpenAI(ChatGPT)나 Anthropic(Claude) 등 경쟁사들의 유료 모델과 직접 경쟁하면서, 사용자들에게 '무료'라는 강력한 유인책을 제공하여 시장 점유율을 빼앗아 오려는 의도로 볼 수 있습니다. 과연 이 전략은 성공할 수 있을까요? 참고로 현재 제한된 횟수 안에서 API 도 무료로 사용가능합니다.- 무료 : RPM 5, RPD 25- 유료 : RPM 20, RPD 100 더 보기- Google, Gemini 2.5 Pro 출시 - 따라올테면 따라와봐https://www.facebook.com/share/p/1AQWWGuMt1/ - OpenAI를 따라잡기 위한 구글의 2년간의 분투기https://www.facebook.com/share/p/18rSta3Hf2/ #구글Gemini #AI전쟁 #ChatGPT #Claude #무료AI #기술경쟁

Gemini

🚀 구글의 AI 승부수? Gemini 2.5 Pro 전면 무료화!

1. 두려움 대신 믿음을 택하는 것, 사실 이는 많은 사람에게 도전이다. 우리는 내면의 비평가가 던지는 부정적인 말을 듣는 데 더 익숙하다.

2. 나는 그 내면의 비평가에게 '나이젤'이라는 이름을 붙였다. 그리고 무려 50년 넘는 세월을 나이절과 함께 보냈다.

3. 나이절은 불가능할 정도로 높은 기준을 요구하는, 마치 깐깐한 인테리어 디자이너 같은 존재다.

4. 내가 쓰는 글은 무엇 하나 그에게 만족스럽지 않았고 나는 늘 가차없는 비판을 받아야 했다.

5. 시간이 흐르면서 나는 나이절을 무시하는 법을 익혔다. 이제는 내 작업이 독창적이고 특별할 때도 목청 높여 비판하는 그 목소리를 아무렇지도 않게 넘길 수 있다.

6. 우리 모두에게는 각자의 나이절이 있다. 두려움에 얼어붙고 멈춰 서게 하는 존재 말이다.

7. 당신 안의 비평가에게 이름을 붙이고 캐릭터를 설정해보자. 그리고 그 비평가의 목소리를 약하게 만들어보자.

#아티스트웨이 📚

1. 두려움 대신 믿음을 택하는 것, 사실 이는 많은 사람에게 도전이다. 우리는 내면의 비평가가 던지는 부정적인 말을 듣는 데 더 익숙하다. ​ 2. 나는 그 내면의 비평가에게 '나이젤'이라는 이름을 붙였다. 그리고 무려 50년 넘는 세월을 나이절과 함께 보냈다. ​ 3. 나이절은 불가능할 정도로 높은 기준을 요구하는, 마치 깐깐한 인테리어 디자이너 같은 존재다. ​ 4. 내가 쓰는 글은 무엇 하나 그에게 만족스럽지 않았고 나는 늘 가차없는 비판을 받아야 했다. ​ 5. 시간이 흐르면서 나는 나이절을 무시하는 법을 익혔다. 이제는 내 작업이 독창적이고 특별할 때도 목청 높여 비판하는 그 목소리를 아무렇지도 않게 넘길 수 있다. ​ 6. 우리 모두에게는 각자의 나이절이 있다. 두려움에 얼어붙고 멈춰 서게 하는 존재 말이다. ​ 7. 당신 안의 비평가에게 이름을 붙이고 캐릭터를 설정해보자. 그리고 그 비평가의 목소리를 약하게 만들어보자. ​#아티스트웨이 📚

< 내 안의 비평가에 맞서는 법: 이름을 붙이고 무시하기 >

https://blog.naver.com/madaboutit/223791084337

Java에서 병렬 처리나 비동기 작업을 구현할 때 Thread를 직접 생성해 사용하는 방식은 더 이상 일반적이지 않습니다. 요즘 Java에서는 ExecutorService를 사용하여 스레드 풀(Thread Pool)을 효율적으로 관리하는 것이 표준입니다. 특히 Executors 클래스에서 제공하는 팩토리 메서드들을 활용하면 다양한 유형의 스레드 풀을 간편하게 생성할 수 있습니다.이번 글에서는 Executors가 제공하는 대표적인 스레드 풀 4종류를 살펴보고, 각각의 사용 시나리오와 주의할 점을 예제 중심으로 정리해보겠습니다. newFixedThreadPool(int nThreads)이 메서드는 정해진 개수만큼의 스레드를 미리 생성하고, 그 스레드들이 재사용되며 작업을 처리합니다. 더 많은 작업이 들어오면..

Java의 ExecutorService 스레드 풀 정복하기

이번 글에서는 Executors가 제공하는 대표적인 스레드 풀 4종류를 살펴보고, 각각의 사용 시나리오와 주의할 점을 예제 중심으로 정리해보겠습니다.
 
newFixedThreadPool(int nThreads)
이 메서드는 정해진 개수만큼의 스레드를 미리 생성하고, 그 스레드들이 재사용되며 작업을 처리합니다. 더 많은 작업이 들어오면 내부 큐에 쌓이고, 기존 스레드들이 작업을 처리하면 순차적으로 소비됩니다.
ExecutorService executor = Executors.newFixedThreadPool(4); 

✅ 사용 시점
 * 처리할 작업량은 많지만, 동시에 처리해야 하는 작업 수를 제한하고 싶은 경우
 * CPU 자원을 고르게 사용하며, 안정적인 처리량을 원하는 경우
🧪 예시
for (int i = 0; i < 10; i++) {
 final int taskId = i;
 executor.submit(() -> {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 Thread.sleep(1000); // 모의 작업
 });
}

⚠️ 주의
 * 과도하게 큰 작업 큐가 쌓일 수 있음 → 메모리 사용량 증가
 * 스레드 수는 CPU 코어 수나 애플리케이션 특성에 맞게 설정해야 함
 
newCachedThreadPool()
이 스레드 풀은 요청이 많으면 새로운 스레드를 계속 생성하고, 특정 기간 동안 사용되지 않으면 제거합니다. 캐시된 스레드를 재사용하므로 빠르고 유연합니다.
ExecutorService executor = Executors.newCachedThreadPool();

✅ 사용 시점
 * 작업이 짧고 빠르게 끝나는 I/O 중심의 작업일 때
 * 짧은 burst가 자주 발생하는 상황에서 유용
🧪 예시
for (int i = 0; i < 100; i++) {
 final int taskId = i;
 executor.submit(() -> {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 });
} 

⚠️ 주의
 * 요청이 많을 경우 스레드가 무제한으로 늘어나 과부하가 될 수 있음
 → 실제 운영에서는 ThreadPoolExecutor로 커스텀 제어 필요
 
newSingleThreadExecutor()
항상 단 하나의 스레드만 사용하여 작업을 처리합니다. 작업은 FIFO 순서로 실행되며, 순서가 중요한 로직에 적합합니다.
ExecutorService executor = Executors.newSingleThreadExecutor();

✅ 사용 시점
 * 작업 순서가 중요할 때
 * 하나의 리소스(DB, 파일 등)에 대해 직렬화된 접근이 필요할 때
🧪 예시
for (int i = 0; i < 5; i++) {
 final int taskId = i;
 executor.submit(() -> {
 System.out.println("Processing task " + taskId);
 Thread.sleep(500);
 });
} 

⚠️ 주의
 * 하나의 스레드에 의존하기 때문에 처리량은 낮음
 * 스레드가 죽으면 새로운 스레드로 대체되므로 중단되지는 않음
 
newScheduledThreadPoool(int corePoolSize)
지연 실행(delay)이나 주기적인 작업(interval) 실행에 특화된 스레드 풀입니다. ScheduledExecutorService를 반환하며, Java의 타이머 역할도 수행할 수 있습니다.
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);

✅ 사용 시점
 * 주기적인 백업 작업, 모니터링, 알림 전송 등
 * 특정 시간 후 작업을 실행하고 싶을 때
🧪 예시
scheduler.scheduleAtFixedRate(() -> {
 System.out.println("Heartbeat sent by " + Thread.currentThread().getName());
}, 1, 5, TimeUnit.SECONDS); // 1초 후 시작, 5초마다 반복

⚠️ 주의
 * 작업이 너무 오래 걸리면 다음 주기 작업이 지연될 수 있음
 → 처리 시간이 일정하지 않다면 scheduleWithFixedDelay()를 고려
 
 
🧠 마무리
Java에서 Executors 팩토리 메서드는 다양한 형태의 스레드 풀을 간단히 생성할 수 있게 도와줍니다. 하지만, 운영 환경에서는 ThreadPoolExecutor를 직접 생성하여 작업 큐, 최대 스레드 수, 거부 정책 등을 세밀하게 조절하는 것이 더욱 안전하고 확장성 있는 선택입니다.

이번 글에서는 Executors가 제공하는 대표적인 스레드 풀 4종류를 살펴보고, 각각의 사용 시나리오와 주의할 점을 예제 중심으로 정리해보겠습니다.&nbsp;newFixedThreadPool(int nThreads)이 메서드는 정해진 개수만큼의 스레드를 미리 생성하고, 그 스레드들이 재사용되며 작업을 처리합니다. 더 많은 작업이 들어오면 내부 큐에 쌓이고, 기존 스레드들이 작업을 처리하면 순차적으로 소비됩니다.<pre ><code class="language-java">ExecutorService executor = Executors.newFixedThreadPool(4);&nbsp;</code></pre>✅ 사용 시점<ul ><li>처리할 작업량은 많지만, 동시에 처리해야 하는 작업 수를 제한하고 싶은 경우</li><li>CPU 자원을 고르게 사용하며, 안정적인 처리량을 원하는 경우</li></ul>🧪 예시<pre ><code class="language-java">for (int i = 0; i &lt; 10; i++) {
 final int taskId = i;
 executor.submit(() -&gt; {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 Thread.sleep(1000); // 모의 작업
 });
}</code></pre>⚠️ 주의<ul ><li>과도하게 큰 작업 큐가 쌓일 수 있음 → 메모리 사용량 증가</li><li>스레드 수는 CPU 코어 수나 애플리케이션 특성에 맞게 설정해야 함</li></ul>&nbsp;newCachedThreadPool()이 스레드 풀은 요청이 많으면 새로운 스레드를 계속 생성하고, 특정 기간&nbsp;동안 사용되지 않으면 제거합니다. 캐시된 스레드를 재사용하므로 빠르고 유연합니다.<pre ><code class="language-java">ExecutorService executor = Executors.newCachedThreadPool();</code></pre>✅ 사용 시점<ul ><li>작업이 짧고 빠르게 끝나는 I/O 중심의 작업일 때</li><li>짧은 burst가 자주 발생하는 상황에서 유용</li></ul>🧪 예시<pre ><code class="language-java">for (int i = 0; i &lt; 100; i++) {
 final int taskId = i;
 executor.submit(() -&gt; {
 System.out.println("Task " + taskId + " executed by " + Thread.currentThread().getName());
 });
}&nbsp;</code></pre>⚠️ 주의<ul ><li>요청이 많을 경우 스레드가 무제한으로 늘어나 과부하가 될 수 있음 → 실제 운영에서는 ThreadPoolExecutor로 커스텀 제어 필요</li></ul>&nbsp;newSingleThreadExecutor()항상 단 하나의 스레드만 사용하여 작업을 처리합니다. 작업은 FIFO 순서로 실행되며, 순서가 중요한 로직에 적합합니다.<pre ><code class="language-java">ExecutorService executor = Executors.newSingleThreadExecutor();</code></pre>✅ 사용 시점<ul ><li>작업 순서가 중요할 때</li><li>하나의 리소스(DB, 파일 등)에 대해 직렬화된 접근이 필요할 때</li></ul>🧪 예시<pre ><code class="language-java">for (int i = 0; i &lt; 5; i++) {
 final int taskId = i;
 executor.submit(() -&gt; {
 System.out.println("Processing task " + taskId);
 Thread.sleep(500);
 });
}&nbsp;</code></pre>⚠️ 주의<ul ><li>하나의 스레드에 의존하기 때문에 처리량은 낮음</li><li>스레드가 죽으면 새로운 스레드로 대체되므로 중단되지는 않음</li></ul>&nbsp;newScheduledThreadPoool(int corePoolSize)지연 실행(delay)이나 주기적인 작업(interval) 실행에 특화된 스레드 풀입니다. ScheduledExecutorService를 반환하며, Java의 타이머 역할도 수행할 수 있습니다.<pre ><code class="language-java">ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);</code></pre>✅ 사용 시점<ul ><li>주기적인 백업 작업, 모니터링, 알림 전송 등</li><li>특정 시간 후 작업을 실행하고 싶을 때</li></ul>🧪 예시<pre ><code class="language-java">scheduler.scheduleAtFixedRate(() -&gt; {
 System.out.println("Heartbeat sent by " + Thread.currentThread().getName());
}, 1, 5, TimeUnit.SECONDS); // 1초 후 시작, 5초마다 반복</code></pre>⚠️ 주의<ul ><li>작업이 너무 오래 걸리면 다음 주기 작업이 지연될 수 있음 → 처리 시간이 일정하지 않다면 scheduleWithFixedDelay()를 고려</li></ul>&nbsp;&nbsp;🧠 마무리Java에서 Executors 팩토리 메서드는 다양한 형태의 스레드 풀을 간단히 생성할 수 있게 도와줍니다. 하지만, 운영 환경에서는 ThreadPoolExecutor를 직접 생성하여 작업 큐, 최대 스레드 수, 거부 정책 등을 세밀하게 조절하는 것이 더욱 안전하고 확장성 있는 선택입니다.

덕토피아

🕊️ Java의 ExecutorService 스레드 풀 정복하기

누구나 쉽게 이해할 수 있는 MCP 가이드 : AI 에이전트와 도구 연동의 새로운 표준

이 자료는 AI 에이전트가 Google Calendar, Salesforce와 같은 다양한 외부 도구(API)를 사용하는 데 어려움을 겪는 현재의 문제를 지적합니다. 이를 해결하기 위한 새로운 표준 프로토콜인 MCP(Model Context Protocol)를 소개하며, MCP가 어떻게 AI 에이전트와 도구 간의 '공통 언어' 역할을 하여 상호작용을 원활하게 하는지 설명합니다. 또한, 개발자와 SaaS 기업이 MCP 생태계에 참여하여 더 강력하고 확장 가능한 AI 에이전트를 구축하는 방법을 안내합니다.

(참고) 가이드 전체 내용은 Gemini 2.5 Pro로 작성되었으며, 이미지 정리본은 GPT-4o 를 이용하여 생성하였습니다.

======================================
📘 1. 왜 에이전트에게 새로운 표준이 필요한가 – MCP 소개
======================================

🚀 미래는 에이전트 중심입니다 (The Future Is Agentic)
ChatGPT 시대를 맞아, 우리 모두는 AI가 얼마나 강력할 수 있는지 엿볼 수 있었습니다. 하지만 진정한 생산성은 단순히 AI와 대화하는 것에서 오는 것이 아니라, AI가 우리를 위해 실제로 일을 처리할 수 있을 때 발휘됩니다.
바로 이 지점에서 에이전트가 필요합니다.

에이전트는 단순한 챗봇이 아닙니다. 회의 예약, 보고서 작성, 데이터 분석과 같이 실제 도구(Google Calendar, Salesforce, Notion 등)를 사용하여 행동을 취하는 AI입니다.
하지만 여기에 문제가 있습니다.

❗️ 오늘날의 에이전트는 여전히 제한적입니다.
AI에게 이렇게 요청한다고 상상해 보세요.

“이번 주 나의 모든 1:1 미팅을 찾아서, 논의 내용을 요약하고, 후속 이메일 초안을 작성해 줄 수 있니?”
오늘날 대부분의 AI 에이전트는 아마 멈춰버릴 것입니다.
왜일까요? 그들이 사용하는 도구, 즉 여러 서비스의 API들이 마치 수백 개의 다른 방언처럼 제각각이기 때문입니다.

모든 도구 (Tools) 는 다음을 가지고 있습니다.

- 자체 인증 규칙
- 고유한 데이터 형식
- 다른 기능 및 엔드포인트
개발자들은 모든 도구에 대해 맞춤 코드를 작성해야 하는 문제를 당면하게 됩니다. 이는 느리고, 불안정하며, 확장 가능하지 않습니다.

🧩 빠진 조각: 도구를 위한 공통 언어
만약 이 모든 도구들이 AI 에이전트와 소통할 수 있는 표준적인 방법이 있다면 어떨까요?
마치 HTML이 웹을 표준화하고, REST가 API를 표준화했듯이 이제 AI 에이전트를 위한 표준이 필요합니다.

이것이 바로 MCP (Model Context Protocol)입니다.

AI 에이전트가 실제 도구를 쉽게 이해하고 상호작용할 수 있도록 설계된 새로운 프로토콜입니다.
시작해 봅시다.

============================
📘 2. MCP란 무엇이며 어떻게 작동하는가?
============================
🧠 큰 그림부터 시작해 봅시다.
MCP (Model Context Protocol)는 AI 에이전트(LLM 기반)와 그들이 사용해야 하는 도구(Google Calendar, Salesforce, Notion 등) 사이에서 번역가 역할을 하는 새로운 표준입니다.

MCP를 에이전트가 다음을 이해하는 데 도움이 되는 "만능 리모컨"이라고 생각하세요.

- 어떤 도구를 사용할 수 있는지
- 그 도구들이 무엇을 할 수 있는지
- 어떻게 안전하고 효율적으로 사용할 수 있는지

🔍 주요 개념

- MCP 클라이언트: LLM을 사용하는 AI 에이전트 또는 앱입니다. 다음과 같은 요청을 보냅니다:
ㄴ “이 도구는 무엇을 할 수 있나요?”
ㄴ “이 함수를 실행해 주세요.”

- MCP 서버: SaaS 도구와의 다리 역할을 합니다. 다음을 설명합니다:
ㄴ 사용 가능한 기능 (예: "회의 생성", "노트 가져오기")
ㄴ 관련 데이터를 일관된 형식으로
ㄴ LLM이 이해할 수 있는 방식으로 지침 제공

- 컨텍스트 스키마: 도구의 기능을 LLM이 읽을 수 있도록 구조화되고 통합된 형식입니다. 마치 모든 도구를 쉽게 탐색할 수 있는 API 플레이그라운드로 바꾸는 것과 같습니다.

🔁 이것이 왜 중요한가
- MCP가 없다면: AI 에이전트는 모든 도구를 사용하기 위해 수작업으로 코딩해야 합니다 = 느리고 비용이 많이 듭니다.
- MCP가 있다면: 도구는 에이전트에게 플러그 앤 플레이 방식이 됩니다 = 빠르고 확장 가능합니다.

✅ 실제 예시
에이전트가 다음 작업을 수행하기를 원하십니까?

“Asana에서 모든 높은 우선순위 작업을 찾고, 프로젝트 상태를 요약하고, 팀에 알림 보내기”

MCP를 사용하면,
1. Asana MCP 서버가 그 기능을 설명합니다 (list_projects, get_tasks 등).
2. 에이전트는 이러한 작업을 탐색, 호출 및 결합할 수 있습니다.
3. 그 결과 맞춤 코드 없이 완전히 자동화된 워크플로우가 가능해집니다.

=================================
📘 3. 도구가 어떻게 에이전트의 능력을 결정하는가
=================================

🛠 모든 도구가 동일하지는 않습니다
인간 조수가 일을 처리하기 위해 적절한 기술 세트가 필요한 것처럼,
AI 에이전트의 성능은 사용할 수 있는 도구에 따라 달라집니다.

도구에는 두 가지 주요 유형이 있습니다.

1️⃣ 다기능 도구 (Multi-Function Tools) : 하나의 도구, 여러 작업 – 스위스 아미 나이프처럼
이 도구들은 여러 관련 작업을 하나의 강력한 인터페이스로 묶습니다.
단일 단계가 아닌 전체 워크플로우를 수행하도록 설계되었습니다.

🧠 예시
다기능 도구를 사용하는 Calendar Agent는 다음을 처리할 수 있습니다.
- 모든 미팅 찾기 (유형별 필터링 = 1:1)
- 메타데이터 추출 (제목, 참석자, 시간)
- 미팅 노트 읽기
- 주간 요약 생성
이 모든 것을 한 번에 처리합니다 – 5개의 다른 도구를 호출할 필요가 없습니다.

📌 중요한 이유
도구 수가 적을수록 = 오케스트레이션이 단순해짐 = 더 빠르고 스마트한 에이전트.

2️⃣ 다중 도구 에이전트 (Multi-Tool Agents) - 함께 작동하는 에이전트 – 전문가 팀처럼
때로는 단일 도구만으로는 모든 것을 할 수 없습니다.
대신, 마치 팀 내의 사람들처럼 각기 다른 도구를 사용하는 에이전트들이 협업합니다.

🧠 예시
목표: 주요 고객에게 맞춤형 이메일 캠페인 보내기.
🧑‍💼 에이전트 1: Salesforce에서 고객 데이터 가져오기
📊 에이전트 2: Google Sheets에서 데이터 분석하기
📬 에이전트 3: Mailchimp를 통해 이메일 보내기
이를 에이전트 시스템(System of Agents) 또는 MAS (Multi-Agent System)라고 합니다.

📌 중요한 이유
에이전트는 강점을 결합하고 더 넓은 범위를 커버할 수 있습니다 – 마치 회사의 마이크로서비스처럼.

🤖 왜 ChatGPT만으로는 충분하지 않은가
오늘날 대부분의 맞춤형 GPT는 너무 단순합니다

- 제한된 작업
- 메모리 없음
- 다른 에이전트와 협업 불가
- "단일 도구" 사일로에 갇혀 있음

이것이 바로 AutoGen, CrewAI, LangGraph와 같은 강력한 프레임워크가 등장한 이유입니다 – 다기능 및 다중 에이전트 기능을 잠금 해제하기 위해.

🧭 도구 = 에이전트 뒤의 진정한 엔진
단순히 어떤 LLM을 사용하는지에 대한 문제가 아닙니다.
어떤 도구를 제공하고, 그것들이 어떻게 연결되어 있는지에 대한 문제입니다.

=========================
📘 4. MCP의 현실적인 과제와 한계점
=========================

MCP는 AI 에이전트와 도구 연동의 방식을 혁신할 잠재력을 지니고 있지만, 새로운 표준으로서 현실적인 과제와 잠재적 한계점 또한 고려해야 합니다.

😫 넘어야 할 현실적인 장벽들
MCP가 이상적인 솔루션처럼 보일 수 있지만, 성공적인 정착과 확산을 위해서는 다음과 같은 현실적인 문제들을 해결해야 합니다.

느린 채택 속도 (Slow Adoption Rate)
- 가장 큰 허들: 새로운 표준의 성공은 얼마나 많은 플레이어가 참여하느냐에 달려있습니다. SaaS 기업들이 MCP 서버 구축에 투자하고, 에이전트 개발자들이 이를 적극적으로 사용해야만 생태계가 활성화됩니다. 초기에는 '닭과 달걀' 문제에 직면할 수 있습니다.
- 모든 도구 제공자가 표준화된 단일 인터페이스를 선호하지 않을 수 있으며, 자체 API 생태계를 강화하는 것을 우선시할 수 있습니다.

구현 및 유지보수의 복잡성 (Complexity of Implementation & Maintenance)
- 서버 측 부담: MCP가 에이전트 클라이언트 개발을 단순화할 수 있지만, SaaS 도구 제공자 입장에서는 자사의 복잡한 API 기능과 데이터 모델을 MCP 표준 스키마에 정확하게 매핑하고, 안전하며 효율적인 MCP 서버를 구축 및 유지보수하는 것이 상당한 기술적, 비용적 부담이 될 수 있습니다.
- 지속적 업데이트: 기반이 되는 도구의 API가 변경되거나 MCP 표준 자체가 발전함에 따라 지속적인 업데이트와 버전 관리가 필요합니다.

표준화의 명암 (Pros and Cons of Standardization)
- 기능 제약 가능성: 모든 도구의 고유하고 세분화된 기능을 단일 표준으로 완벽하게 포괄하기는 어렵습니다. 초기 표준은 '최소 공통분모'에 집중하게 되어, 특정 도구의 고급 기능이나 특수 기능을 MCP를 통해 활용하는 데 제약이 따를 수 있습니다. 때로는 여전히 직접적인 API 호출이 필요할 수 있습니다.
- 표준의 경직성: 표준이 한번 자리 잡으면 변경하기 어려울 수 있으며, 빠르게 변화하는 AI 및 API 기술 발전을 민첩하게 따라가지 못할 수 있습니다.

성능 및 보안 문제 (Performance & Security Concerns)
- 잠재적 성능 저하: MCP라는 중개 계층(layer)이 추가되면서, 이론적으로는 직접 API를 호출하는 것보다 약간의 지연 시간(latency)이 발생할 수 있습니다. 대부분의 경우 무시할 만한 수준일 수 있으나, 실시간성이 중요한 애플리케이션에서는 고려 사항이 될 수 있습니다.
- 보안 책임: 표준화된 인터페이스는 잠재적인 공격 표면(attack surface)도 표준화할 수 있습니다. MCP 서버와 클라이언트 간의 인증, 권한 부여, 데이터 암호화 등 보안 메커니즘을 철저히 구현하는 것이 매우 중요하며, 이에 대한 책임은 각 서버 구현 주체에게 있습니다.

기술 성숙도 및 생태계 지원 (Maturity & Ecosystem Support)
- 초기 단계: MCP는 비교적 새로운 개념이므로, 관련 개발 도구, 디버깅 툴, 테스트 프레임워크, 풍부한 문서, 커뮤니티 지원 등이 아직 부족할 수 있습니다. 이는 초기 도입 및 문제 해결을 어렵게 만들 수 있습니다.

💡 결론: 균형 잡힌 시각 필요
MCP는 에이전트 기반 자동화의 중요한 발전을 약속하지만, 위와 같은 현실적인 과제들을 간과해서는 안 됩니다. 이러한 문제들은 대부분의 신기술 표준화 과정에서 나타나는 현상이며, MCP 생태계 참여자들의 지속적인 노력, 피드백, 협력을 통해 점진적으로 해결될 수 있을 것입니다. MCP의 성공 여부는 이러한 과제들을 얼마나 효과적으로 극복하느냐에 달려있습니다.

=======================
📘 5. MCP 생태계에 참여하는 방법
=======================

🎯 왜 관심을 가져야 하는가
만약 당신의 제품이 SaaS 도구이고, AI 에이전트가 사용하기를 원한다면, 지금이 MCP 생태계에 진입하기에 완벽한 시기입니다.
- LLM 기반 에이전트에게 발견될 수 있습니다.
- 맞춤 통합 없이 에이전트가 당신의 도구를 사용하게 할 수 있습니다.
- 기업 IT부터 소비자 AI까지 성장하는 에이전트 앱 시장에 진입할 수 있습니다.

🚪 참여 방법: 3가지 방법

1️⃣ MCP 서버 구축하기
당신의 도구 기능을 MCP 호환 인터페이스로 전환하세요.

🔧 필요한 것
- 도구의 기능(call_tool, list_tools) 설명하기
- call_resource, list_resources를 통해 데이터 노출하기
- 표준 컨텍스트 스키마 따르기
마치 공개 API를 구축하는 것과 같지만, LLM을 위한 것입니다.

💡 팁: 기존 에이전트 프레임워크(예: LangGraph, AutoGen)를 사용하여 개발 속도를 높이세요.

2️⃣ 마켓플레이스에 호스팅 또는 등록하기
MCP 서버가 활성화되면 MCP 레지스트리나 마켓플레이스에 게시하세요.
- 당신의 도구를 모든 MCP 호환 클라이언트가 발견할 수 있도록 만드세요.
- AI 에이전트가 당신의 제품을 찾고, 이해하고, 사용하도록 하세요.
- 일부 플랫폼(예: Claude, MySnap)은 이미 이 플러그 앤 플레이 모델을 지원합니다.

3️⃣ MCP를 클라이언트로 사용하기
MCP를 통해 도구에 연결하는 자체 AI 에이전트나 LLM 앱을 구축할 수도 있습니다.
- 더 이상 각 API에 대한 맞춤 래퍼를 작성할 필요가 없습니다.
- 기존 MCP 서버에 연결하고 워크플로우를 더 빠르게 구축하세요.
- 내부 자동화 도구나 고객 대면 AI 앱에 적합합니다.

🌱 선도자 = 큰 이점 (Early Movers = Huge Advantage)
MCP는 아직 초기 단계이지만, 기반은 현실적이고 작동하고 있습니다.
지금 참여함으로써 다음을 할 수 있습니다

✅ 떠오르는 표준에 영향을 미치기
✅ 다른 이들보다 먼저 당신의 도구의 LLM 인터페이스 형성하기
✅ 생태계가 확장됨에 따라 함께 성장하기

📌 결론
만약 REST가 웹 시대의 API 표준이었다면, MCP는 에이전트 시대의 프로토콜 표준이 될 수 있습니다. 지금이 준비할 황금 같은 기회입니다.

🧭 구축할 준비가 되셨나요?
핵심 도구 기능을 식별하고 MCP 형식으로 구조화하는 것부터 시작하세요.
모든 것을 지원할 필요는 없습니다 – 에이전트가 시작할 수 있을 만큼만 지원하면 됩니다.

에이전트의 시대(Agentic era)가 오고 있습니다. 늦지 마세요.

도움이 되셨다면 좋아요 부탁드립니다.

누구나 쉽게 이해할 수 있는 MCP 가이드 : AI 에이전트와 도구 연동의 새로운 표준 이 자료는 AI 에이전트가 Google Calendar, Salesforce와 같은 다양한 외부 도구(API)를 사용하는 데 어려움을 겪는 현재의 문제를 지적합니다. 이를 해결하기 위한 새로운 표준 프로토콜인 MCP(Model Context Protocol)를 소개하며, MCP가 어떻게 AI 에이전트와 도구 간의 '공통 언어' 역할을 하여 상호작용을 원활하게 하는지 설명합니다. 또한, 개발자와 SaaS 기업이 MCP 생태계에 참여하여 더 강력하고 확장 가능한 AI 에이전트를 구축하는 방법을 안내합니다. (참고) 가이드 전체 내용은 Gemini 2.5 Pro로 작성되었으며, 이미지 정리본은 GPT-4o 를 이용하여 생성하였습니다. ====================================== 📘 1. 왜 에이전트에게 새로운 표준이 필요한가 – MCP 소개 ====================================== 🚀 미래는 에이전트 중심입니다 (The Future Is Agentic) ChatGPT 시대를 맞아, 우리 모두는 AI가 얼마나 강력할 수 있는지 엿볼 수 있었습니다. 하지만 진정한 생산성은 단순히 AI와 대화하는 것에서 오는 것이 아니라, AI가 우리를 위해 실제로 일을 처리할 수 있을 때 발휘됩니다. 바로 이 지점에서 에이전트가 필요합니다. 에이전트는 단순한 챗봇이 아닙니다. 회의 예약, 보고서 작성, 데이터 분석과 같이 실제 도구(Google Calendar, Salesforce, Notion 등)를 사용하여 행동을 취하는 AI입니다. 하지만 여기에 문제가 있습니다. ❗️ 오늘날의 에이전트는 여전히 제한적입니다. AI에게 이렇게 요청한다고 상상해 보세요. “이번 주 나의 모든 1:1 미팅을 찾아서, 논의 내용을 요약하고, 후속 이메일 초안을 작성해 줄 수 있니?” 오늘날 대부분의 AI 에이전트는 아마 멈춰버릴 것입니다. 왜일까요? 그들이 사용하는 도구, 즉 여러 서비스의 API들이 마치 수백 개의 다른 방언처럼 제각각이기 때문입니다. 모든 도구 (Tools) 는 다음을 가지고 있습니다. - 자체 인증 규칙 - 고유한 데이터 형식 - 다른 기능 및 엔드포인트 개발자들은 모든 도구에 대해 맞춤 코드를 작성해야 하는 문제를 당면하게 됩니다. 이는 느리고, 불안정하며, 확장 가능하지 않습니다. 🧩 빠진 조각: 도구를 위한 공통 언어 만약 이 모든 도구들이 AI 에이전트와 소통할 수 있는 표준적인 방법이 있다면 어떨까요? 마치 HTML이 웹을 표준화하고, REST가 API를 표준화했듯이 이제 AI 에이전트를 위한 표준이 필요합니다. 이것이 바로 MCP (Model Context Protocol)입니다. AI 에이전트가 실제 도구를 쉽게 이해하고 상호작용할 수 있도록 설계된 새로운 프로토콜입니다. 시작해 봅시다. ============================ 📘 2. MCP란 무엇이며 어떻게 작동하는가? ============================ 🧠 큰 그림부터 시작해 봅시다. MCP (Model Context Protocol)는 AI 에이전트(LLM 기반)와 그들이 사용해야 하는 도구(Google Calendar, Salesforce, Notion 등) 사이에서 번역가 역할을 하는 새로운 표준입니다. MCP를 에이전트가 다음을 이해하는 데 도움이 되는 "만능 리모컨"이라고 생각하세요. - 어떤 도구를 사용할 수 있는지 - 그 도구들이 무엇을 할 수 있는지 - 어떻게 안전하고 효율적으로 사용할 수 있는지 🔍 주요 개념 - MCP 클라이언트: LLM을 사용하는 AI 에이전트 또는 앱입니다. 다음과 같은 요청을 보냅니다: ㄴ “이 도구는 무엇을 할 수 있나요?” ㄴ “이 함수를 실행해 주세요.” - MCP 서버: SaaS 도구와의 다리 역할을 합니다. 다음을 설명합니다: ㄴ 사용 가능한 기능 (예: "회의 생성", "노트 가져오기") ㄴ 관련 데이터를 일관된 형식으로 ㄴ LLM이 이해할 수 있는 방식으로 지침 제공 - 컨텍스트 스키마: 도구의 기능을 LLM이 읽을 수 있도록 구조화되고 통합된 형식입니다. 마치 모든 도구를 쉽게 탐색할 수 있는 API 플레이그라운드로 바꾸는 것과 같습니다. 🔁 이것이 왜 중요한가 - MCP가 없다면: AI 에이전트는 모든 도구를 사용하기 위해 수작업으로 코딩해야 합니다 = 느리고 비용이 많이 듭니다. - MCP가 있다면: 도구는 에이전트에게 플러그 앤 플레이 방식이 됩니다 = 빠르고 확장 가능합니다. ✅ 실제 예시 에이전트가 다음 작업을 수행하기를 원하십니까? “Asana에서 모든 높은 우선순위 작업을 찾고, 프로젝트 상태를 요약하고, 팀에 알림 보내기” MCP를 사용하면, 1. Asana MCP 서버가 그 기능을 설명합니다 (list_projects, get_tasks 등). 2. 에이전트는 이러한 작업을 탐색, 호출 및 결합할 수 있습니다. 3. 그 결과 맞춤 코드 없이 완전히 자동화된 워크플로우가 가능해집니다. ================================= 📘 3. 도구가 어떻게 에이전트의 능력을 결정하는가 ================================= 🛠 모든 도구가 동일하지는 않습니다 인간 조수가 일을 처리하기 위해 적절한 기술 세트가 필요한 것처럼, AI 에이전트의 성능은 사용할 수 있는 도구에 따라 달라집니다. 도구에는 두 가지 주요 유형이 있습니다. 1️⃣ 다기능 도구 (Multi-Function Tools) : 하나의 도구, 여러 작업 – 스위스 아미 나이프처럼 이 도구들은 여러 관련 작업을 하나의 강력한 인터페이스로 묶습니다. 단일 단계가 아닌 전체 워크플로우를 수행하도록 설계되었습니다. 🧠 예시 다기능 도구를 사용하는 Calendar Agent는 다음을 처리할 수 있습니다. - 모든 미팅 찾기 (유형별 필터링 = 1:1) - 메타데이터 추출 (제목, 참석자, 시간) - 미팅 노트 읽기 - 주간 요약 생성 이 모든 것을 한 번에 처리합니다 – 5개의 다른 도구를 호출할 필요가 없습니다. 📌 중요한 이유 도구 수가 적을수록 = 오케스트레이션이 단순해짐 = 더 빠르고 스마트한 에이전트. 2️⃣ 다중 도구 에이전트 (Multi-Tool Agents) - 함께 작동하는 에이전트 – 전문가 팀처럼 때로는 단일 도구만으로는 모든 것을 할 수 없습니다. 대신, 마치 팀 내의 사람들처럼 각기 다른 도구를 사용하는 에이전트들이 협업합니다. 🧠 예시 목표: 주요 고객에게 맞춤형 이메일 캠페인 보내기. 🧑‍💼 에이전트 1: Salesforce에서 고객 데이터 가져오기 📊 에이전트 2: Google Sheets에서 데이터 분석하기 📬 에이전트 3: Mailchimp를 통해 이메일 보내기 이를 에이전트 시스템(System of Agents) 또는 MAS (Multi-Agent System)라고 합니다. 📌 중요한 이유 에이전트는 강점을 결합하고 더 넓은 범위를 커버할 수 있습니다 – 마치 회사의 마이크로서비스처럼. 🤖 왜 ChatGPT만으로는 충분하지 않은가 오늘날 대부분의 맞춤형 GPT는 너무 단순합니다 - 제한된 작업 - 메모리 없음 - 다른 에이전트와 협업 불가 - "단일 도구" 사일로에 갇혀 있음 이것이 바로 AutoGen, CrewAI, LangGraph와 같은 강력한 프레임워크가 등장한 이유입니다 – 다기능 및 다중 에이전트 기능을 잠금 해제하기 위해. 🧭 도구 = 에이전트 뒤의 진정한 엔진 단순히 어떤 LLM을 사용하는지에 대한 문제가 아닙니다. 어떤 도구를 제공하고, 그것들이 어떻게 연결되어 있는지에 대한 문제입니다. ========================= 📘 4. MCP의 현실적인 과제와 한계점 ========================= MCP는 AI 에이전트와 도구 연동의 방식을 혁신할 잠재력을 지니고 있지만, 새로운 표준으로서 현실적인 과제와 잠재적 한계점 또한 고려해야 합니다. 😫 넘어야 할 현실적인 장벽들 MCP가 이상적인 솔루션처럼 보일 수 있지만, 성공적인 정착과 확산을 위해서는 다음과 같은 현실적인 문제들을 해결해야 합니다. 느린 채택 속도 (Slow Adoption Rate) - 가장 큰 허들: 새로운 표준의 성공은 얼마나 많은 플레이어가 참여하느냐에 달려있습니다. SaaS 기업들이 MCP 서버 구축에 투자하고, 에이전트 개발자들이 이를 적극적으로 사용해야만 생태계가 활성화됩니다. 초기에는 '닭과 달걀' 문제에 직면할 수 있습니다. - 모든 도구 제공자가 표준화된 단일 인터페이스를 선호하지 않을 수 있으며, 자체 API 생태계를 강화하는 것을 우선시할 수 있습니다. 구현 및 유지보수의 복잡성 (Complexity of Implementation &amp; Maintenance) - 서버 측 부담: MCP가 에이전트 클라이언트 개발을 단순화할 수 있지만, SaaS 도구 제공자 입장에서는 자사의 복잡한 API 기능과 데이터 모델을 MCP 표준 스키마에 정확하게 매핑하고, 안전하며 효율적인 MCP 서버를 구축 및 유지보수하는 것이 상당한 기술적, 비용적 부담이 될 수 있습니다. - 지속적 업데이트: 기반이 되는 도구의 API가 변경되거나 MCP 표준 자체가 발전함에 따라 지속적인 업데이트와 버전 관리가 필요합니다. 표준화의 명암 (Pros and Cons of Standardization) - 기능 제약 가능성: 모든 도구의 고유하고 세분화된 기능을 단일 표준으로 완벽하게 포괄하기는 어렵습니다. 초기 표준은 '최소 공통분모'에 집중하게 되어, 특정 도구의 고급 기능이나 특수 기능을 MCP를 통해 활용하는 데 제약이 따를 수 있습니다. 때로는 여전히 직접적인 API 호출이 필요할 수 있습니다. - 표준의 경직성: 표준이 한번 자리 잡으면 변경하기 어려울 수 있으며, 빠르게 변화하는 AI 및 API 기술 발전을 민첩하게 따라가지 못할 수 있습니다. 성능 및 보안 문제 (Performance &amp; Security Concerns) - 잠재적 성능 저하: MCP라는 중개 계층(layer)이 추가되면서, 이론적으로는 직접 API를 호출하는 것보다 약간의 지연 시간(latency)이 발생할 수 있습니다. 대부분의 경우 무시할 만한 수준일 수 있으나, 실시간성이 중요한 애플리케이션에서는 고려 사항이 될 수 있습니다. - 보안 책임: 표준화된 인터페이스는 잠재적인 공격 표면(attack surface)도 표준화할 수 있습니다. MCP 서버와 클라이언트 간의 인증, 권한 부여, 데이터 암호화 등 보안 메커니즘을 철저히 구현하는 것이 매우 중요하며, 이에 대한 책임은 각 서버 구현 주체에게 있습니다. 기술 성숙도 및 생태계 지원 (Maturity &amp; Ecosystem Support) - 초기 단계: MCP는 비교적 새로운 개념이므로, 관련 개발 도구, 디버깅 툴, 테스트 프레임워크, 풍부한 문서, 커뮤니티 지원 등이 아직 부족할 수 있습니다. 이는 초기 도입 및 문제 해결을 어렵게 만들 수 있습니다. 💡 결론: 균형 잡힌 시각 필요 MCP는 에이전트 기반 자동화의 중요한 발전을 약속하지만, 위와 같은 현실적인 과제들을 간과해서는 안 됩니다. 이러한 문제들은 대부분의 신기술 표준화 과정에서 나타나는 현상이며, MCP 생태계 참여자들의 지속적인 노력, 피드백, 협력을 통해 점진적으로 해결될 수 있을 것입니다. MCP의 성공 여부는 이러한 과제들을 얼마나 효과적으로 극복하느냐에 달려있습니다. ======================= 📘 5. MCP 생태계에 참여하는 방법 ======================= 🎯 왜 관심을 가져야 하는가 만약 당신의 제품이 SaaS 도구이고, AI 에이전트가 사용하기를 원한다면, 지금이 MCP 생태계에 진입하기에 완벽한 시기입니다. - LLM 기반 에이전트에게 발견될 수 있습니다. - 맞춤 통합 없이 에이전트가 당신의 도구를 사용하게 할 수 있습니다. - 기업 IT부터 소비자 AI까지 성장하는 에이전트 앱 시장에 진입할 수 있습니다. 🚪 참여 방법: 3가지 방법 1️⃣ MCP 서버 구축하기 당신의 도구 기능을 MCP 호환 인터페이스로 전환하세요. 🔧 필요한 것 - 도구의 기능(call_tool, list_tools) 설명하기 - call_resource, list_resources를 통해 데이터 노출하기 - 표준 컨텍스트 스키마 따르기 마치 공개 API를 구축하는 것과 같지만, LLM을 위한 것입니다. 💡 팁: 기존 에이전트 프레임워크(예: LangGraph, AutoGen)를 사용하여 개발 속도를 높이세요. 2️⃣ 마켓플레이스에 호스팅 또는 등록하기 MCP 서버가 활성화되면 MCP 레지스트리나 마켓플레이스에 게시하세요. - 당신의 도구를 모든 MCP 호환 클라이언트가 발견할 수 있도록 만드세요. - AI 에이전트가 당신의 제품을 찾고, 이해하고, 사용하도록 하세요. - 일부 플랫폼(예: Claude, MySnap)은 이미 이 플러그 앤 플레이 모델을 지원합니다. 3️⃣ MCP를 클라이언트로 사용하기 MCP를 통해 도구에 연결하는 자체 AI 에이전트나 LLM 앱을 구축할 수도 있습니다. - 더 이상 각 API에 대한 맞춤 래퍼를 작성할 필요가 없습니다. - 기존 MCP 서버에 연결하고 워크플로우를 더 빠르게 구축하세요. - 내부 자동화 도구나 고객 대면 AI 앱에 적합합니다. 🌱 선도자 = 큰 이점 (Early Movers = Huge Advantage) MCP는 아직 초기 단계이지만, 기반은 현실적이고 작동하고 있습니다. 지금 참여함으로써 다음을 할 수 있습니다 ✅ 떠오르는 표준에 영향을 미치기 ✅ 다른 이들보다 먼저 당신의 도구의 LLM 인터페이스 형성하기 ✅ 생태계가 확장됨에 따라 함께 성장하기 📌 결론 만약 REST가 웹 시대의 API 표준이었다면, MCP는 에이전트 시대의 프로토콜 표준이 될 수 있습니다. 지금이 준비할 황금 같은 기회입니다. 🧭 구축할 준비가 되셨나요? 핵심 도구 기능을 식별하고 MCP 형식으로 구조화하는 것부터 시작하세요. 모든 것을 지원할 필요는 없습니다 – 에이전트가 시작할 수 있을 만큼만 지원하면 됩니다. 에이전트의 시대(Agentic era)가 오고 있습니다. 늦지 마세요. 도움이 되셨다면 좋아요 부탁드립니다.

누구나 쉽게 이해할 수 있는 MCP 가이드

﻿
공교롭게 둘 중 하나만 선택해야 하는 기로에 놓인 경우가 있습니다. 이것 아니면 저것 중에 오직 하나만 선택할 수 있습니다. 이런 선택의 순간이 괴롭고 혼란스러운 것은 이것도 좋고, 저것도 좋아 보이기 때문입니다. 가혹하게 우리는 둘 모두를 선택할 수 없습니다. 반드시 둘 중 하나를 선택해야 하는 물리적인 환경에서 살고 있습니다.

대표적으로 중국요리 가게에 가면 혼돈의 카오스를 경험하게 됩니다. 짜장면과 짬뽕 사이에 갈등이 시작됩니다. 돈도 있고, 대식가라면 둘 다 먹어도 됩니다. 하지만 보통의 위를 가지고 있고, 한 끼를 때우는데 한 그릇에 만 원이 넘는 메뉴 두 개를 주문하는 용감한 K-직장인은 별로 없을 것입니다. 그래서 당신은 짜장입니까, 짬뽕입니까? 이와 같은 선택에 볶음밥 녀석까지 합세하는 날에는 울고 싶은 지경입니다.

둘 중 하나를 선택해야 하는 순간은 음식 메뉴를 결정하는 것 외에도 훨씬 다양하게 많습니다. 생일 선물로 전자기기를 사달라고 할까, 자전거를 사달라고 할까? 친구와의 약속이 겹치는데 철수를 만날까, 영희를 만날까? 입사 지원 결과로 덜컥 두 회사에 합격했는데 A 회사로 갈까, B 회사로 갈까? 우리는 한정된 시간과 자원으로 어쩔 수 없이 둘 중 하나를 선택하며 살아갑니다.

양자택일이 어렵게 느껴지는 이유는 둘 다 좋아 보이기 때문입니다. 하나를 포기하는 것이 하나를 선택하여 얻게 되는 것보다 약간 더 큰 손실로 느껴집니다. 욕심이죠. 얻은 것보다 갖지 못하는 것에 대한 미련이 더 많이 남습니다. 그리곤 마음으로 ‘만일 내가 부자로 태어났다면 모두 다 선택할 수 있었을 텐데’ ‘만일 내가 초능력자라면 하고 싶은 일을 모두 다 하고 살 수 있었을 텐데’ 신세를 한탄합니다. 

세상은 우리에게 둘 중 하나를 선택하도록 강요합니다. 그러나 여러분 속지 마시기 바랍니다. 우리가 반드시 그 둘 중 하나만 선택해야 하는 것은 아닙니다. 반드시 A 대학에 가거나 B 대학에 가야만 하는 것은 아닙니다. 대학을 가지 않는 선택도 있습니다. 반드시 C 회사를 가거나 D 회사에 가야만 하는 것은 아닙니다. 회사를 선택하지 않고 혼자서 잘 먹고 잘 살 수 있는 방법이 많습니다.

그러니까 앞선 사람들이 자신이 해본 경험의 선택지를 제시하는 것만 바라볼 필요는 없습니다. 그것이 정답도 아니고 최선의 선택도 아니요, 가장 좋은 결과도 아닙니다. 양자택일 순간에 한 발짝 물러서서 상황을 바라보면 두 가지 선택보다 더 좋은 옵션을 깨닫게 됩니다. 짜장, 짬뽕에 매몰되지 않고 한 걸음 물러나 메뉴판을 보면 비로소 짬짜면을 발견하게 됩니다.

상황을 벗어나는 것이 지혜롭게 선택할 수 있는 비결입니다. 갖고 싶다는 욕망에 사로잡히면 어리석은 선택 밖에 할 수 없습니다. 욕심을 내려놓고 한 걸음 물러나서 상황을 바라보면 본질을 깨달을 수 있습니다. 본질을 깨닫고 나면 선택 자체를 하지 않아도 되거나 더 좋은 다른 선택지가 있었다는 것을 발견할 수 있습니다.

우리가 지금 어떤 일 때문에 괴로운 이유는 마치 다른 선택지가 없는 것 같아 보이기 때문입니다. 그러나 한 걸음 물러나 잘 생각해 보세요. 과연 눈앞에 놓인 상황에 양자택일만 있는 것은 아닐 겁니다. 세상의 요구에 흔들리지 말아야 합니다. 당장 둘 중 하나를 선택하고 강요하는 말에 억지로 하나를 골라 나중에 후회할 선택을 거부하세요.

당당하게 자신이 진짜 원하는 삶을 선택하세요. 누구도 당신의 선택에 관여하지 못하게 만드세요. 정해진 틀에 자신을 맞추지 말고, 틀 안과 밖에서 자신이 진정으로 하고 싶은 선택을 용기 있게 하세요. 그래야 후회가 없습니다. 그래야 선택이 만족스럽게 느껴집니다.

선택이 불편한 상황에 오히려 현실을 더 똑바로 바라보세요. 이 선택이 왜 어려운지 더 깊게 생각해 보세요. 도망칠 수 없는 막다른 골목까지 생각을 몰아가세요. 이윽고 깨닫게 되는 자신의 진짜 욕구를 발견하세요. 그 욕구가 정당하다면 어떤 선택을 하든 좋습니다. 그러나 정당하지 못하다면, 차라리 선택하지 않는 것이 낫습니다. 때를 기다리세요. 지금 당장 크게 마음에 들지 않는 둘 중 하나를 선택하는 것보다 더 좋은 기회가 미래에 당신을 기다리고 있습니다.

﻿공교롭게 둘 중 하나만 선택해야 하는 기로에 놓인 경우가 있습니다. 이것 아니면 저것 중에 오직 하나만 선택할 수 있습니다. 이런 선택의 순간이 괴롭고 혼란스러운 것은 이것도 좋고, 저것도 좋아 보이기 때문입니다. 가혹하게 우리는 둘 모두를 선택할 수 없습니다. 반드시 둘 중 하나를 선택해야 하는 물리적인 환경에서 살고 있습니다. 대표적으로 중국요리 가게에 가면 혼돈의 카오스를 경험하게 됩니다. 짜장면과 짬뽕 사이에 갈등이 시작됩니다. 돈도 있고, 대식가라면 둘 다 먹어도 됩니다. 하지만 보통의 위를 가지고 있고, 한 끼를 때우는데 한 그릇에 만 원이 넘는 메뉴 두 개를 주문하는 용감한 K-직장인은 별로 없을 것입니다. 그래서 당신은 짜장입니까, 짬뽕입니까? 이와 같은 선택에 볶음밥 녀석까지 합세하는 날에는 울고 싶은 지경입니다. 둘 중 하나를 선택해야 하는 순간은 음식 메뉴를 결정하는 것 외에도 훨씬 다양하게 많습니다. 생일 선물로 전자기기를 사달라고 할까, 자전거를 사달라고 할까? 친구와의 약속이 겹치는데 철수를 만날까, 영희를 만날까? 입사 지원 결과로 덜컥 두 회사에 합격했는데 A 회사로 갈까, B 회사로 갈까? 우리는 한정된 시간과 자원으로 어쩔 수 없이 둘 중 하나를 선택하며 살아갑니다. 양자택일이 어렵게 느껴지는 이유는 둘 다 좋아 보이기 때문입니다. 하나를 포기하는 것이 하나를 선택하여 얻게 되는 것보다 약간 더 큰 손실로 느껴집니다. 욕심이죠. 얻은 것보다 갖지 못하는 것에 대한 미련이 더 많이 남습니다. 그리곤 마음으로 ‘만일 내가 부자로 태어났다면 모두 다 선택할 수 있었을 텐데’ ‘만일 내가 초능력자라면 하고 싶은 일을 모두 다 하고 살 수 있었을 텐데’ 신세를 한탄합니다.&nbsp; 세상은 우리에게 둘 중 하나를 선택하도록 강요합니다. 그러나 여러분 속지 마시기 바랍니다. 우리가 반드시 그 둘 중 하나만 선택해야 하는 것은 아닙니다. 반드시 A 대학에 가거나 B 대학에 가야만 하는 것은 아닙니다. 대학을 가지 않는 선택도 있습니다. 반드시 C 회사를 가거나 D 회사에 가야만 하는 것은 아닙니다. 회사를 선택하지 않고 혼자서 잘 먹고 잘 살 수 있는 방법이 많습니다. 그러니까 앞선 사람들이 자신이 해본 경험의 선택지를 제시하는 것만 바라볼 필요는 없습니다. 그것이 정답도 아니고 최선의 선택도 아니요, 가장 좋은 결과도 아닙니다. 양자택일 순간에 한 발짝 물러서서 상황을 바라보면 두 가지 선택보다 더 좋은 옵션을 깨닫게 됩니다. 짜장, 짬뽕에 매몰되지 않고 한 걸음 물러나 메뉴판을 보면 비로소 짬짜면을 발견하게 됩니다. 상황을 벗어나는 것이 지혜롭게 선택할 수 있는 비결입니다. 갖고 싶다는 욕망에 사로잡히면 어리석은 선택 밖에 할 수 없습니다. 욕심을 내려놓고 한 걸음 물러나서 상황을 바라보면 본질을 깨달을 수 있습니다. 본질을 깨닫고 나면 선택 자체를 하지 않아도 되거나 더 좋은 다른 선택지가 있었다는 것을 발견할 수 있습니다. 우리가 지금 어떤 일 때문에 괴로운 이유는 마치 다른 선택지가 없는 것 같아 보이기 때문입니다. 그러나 한 걸음 물러나 잘 생각해 보세요. 과연 눈앞에 놓인 상황에 양자택일만 있는 것은 아닐 겁니다. 세상의 요구에 흔들리지 말아야 합니다. 당장 둘 중 하나를 선택하고 강요하는 말에 억지로 하나를 골라 나중에 후회할 선택을 거부하세요. 당당하게 자신이 진짜 원하는 삶을 선택하세요. 누구도 당신의 선택에 관여하지 못하게 만드세요. 정해진 틀에 자신을 맞추지 말고, 틀 안과 밖에서 자신이 진정으로 하고 싶은 선택을 용기 있게 하세요. 그래야 후회가 없습니다. 그래야 선택이 만족스럽게 느껴집니다. 선택이 불편한 상황에 오히려 현실을 더 똑바로 바라보세요. 이 선택이 왜 어려운지 더 깊게 생각해 보세요. 도망칠 수 없는 막다른 골목까지 생각을 몰아가세요. 이윽고 깨닫게 되는 자신의 진짜 욕구를 발견하세요. 그 욕구가 정당하다면 어떤 선택을 하든 좋습니다. 그러나 정당하지 못하다면, 차라리 선택하지 않는 것이 낫습니다. 때를 기다리세요. 지금 당장 크게 마음에 들지 않는 둘 중 하나를 선택하는 것보다 더 좋은 기회가 미래에 당신을 기다리고 있습니다.﻿

양자택일

코딩 인터뷰를 하던 중 지원자로부터 AI를 써도 되겠냐는 질문을 받았습니다. 인터넷 검색을 해도 되냐고 물어보는 지원자는 종종 만나는데, AI를 써도 되느냐는 질문은 처음 받아봐서 좀 당황스럽더군요. 어떤 용도로 AI를 사용하시려는지 물어보았고, 익숙치 않은 프로그래밍 언어의 사용법을 찾기 위해서라는 답변을 들었습니다. 지원자가 대학생이어서 특정 언어를 능숙하게 다룰 거라는 기대는 없었습니다. 그래서 화면을 공유하는 전제 하에 AI를 사용하도록 허락하였죠.

지원자는 ChatGPT를 열고 해당 언어에서 어떻게 힙(heap) 자료구조를 사용하는지 물어보았습니다. 언제나 그렇듯 ChatGPT는 어떻게 힙을 생성하고, 원소를 추가/삭제하는지에 대해서 아주 상세하게 적어주기 시작했습니다. 그러나 너무나 친절한 나머지 ChatGPT는 힙을 활용할 수 있는 대표적인 사례까지 나열해줬는데, 그 중에 인터뷰에서 출제한 문제가 포함되어 있었습니다. (Co-op 채용이라서 아주 기초 수준의 문제였거든요 😅)

당황한 기색이 역력한 지원자는 급하게 화면을 전환하였습니다. 하지만 그 이후부터는 계속해서 신경이 쓰이는지 인터뷰에 집중을 하지 못하는 모습이었습니다. 결국은 시간 내에 답안을 완성하지 못했고, 본인이 작성한 코드에 대해서도 명확히 설명하지 못했습니다. 아무래도 스스로 망했다고 생각하고 이미 인터뷰를 포기한 느낌을 받았습니다. 첫 번째 문제는 잘 푸셨기 때문에, 오히려 두 번째 문제에서 AI를 쓰지 않으셨다면 합격하실 수도 있으셨을 것 같아서 참 안타까웠습니다.

인터뷰가 끝나고 많은 생각이 들었습니다. 이미 AI가 대학생들의 삶에 깊숙히 스며든 것 같고, 현직 개발자들도 AI의 도움을 받아 업무를 수행하고 있는 상황이죠. 코딩 인터뷰라고 해서 AI를 쓰지 못하게 할 이유가 있을까요? 과연 저처럼 불완전한 인간이 면접관으로서 AI로 인해 거의 신급의 지능을 갖게 된 지원자들을 평가할 수 있을까요? 어디까지가 AI의 버프이고 어디까지가 지원자의 순수한 능력인지 어떻게 판단할 수 있을까요?

코딩 인터뷰를 하던 중 지원자로부터 AI를 써도 되겠냐는 질문을 받았습니다. 인터넷 검색을 해도 되냐고 물어보는 지원자는 종종 만나는데, AI를 써도 되느냐는 질문은 처음 받아봐서 좀 당황스럽더군요. 어떤 용도로 AI를 사용하시려는지 물어보았고, 익숙치 않은 프로그래밍 언어의 사용법을 찾기 위해서라는 답변을 들었습니다. 지원자가 대학생이어서 특정 언어를 능숙하게 다룰 거라는 기대는 없었습니다. 그래서 화면을 공유하는 전제 하에 AI를 사용하도록 허락하였죠. 지원자는 ChatGPT를 열고 해당 언어에서 어떻게 힙(heap) 자료구조를 사용하는지 물어보았습니다. 언제나 그렇듯 ChatGPT는 어떻게 힙을 생성하고, 원소를 추가/삭제하는지에 대해서 아주 상세하게 적어주기 시작했습니다. 그러나 너무나 친절한 나머지 ChatGPT는 힙을 활용할 수 있는 대표적인 사례까지 나열해줬는데, 그 중에 인터뷰에서 출제한 문제가 포함되어 있었습니다. (Co-op 채용이라서 아주 기초 수준의 문제였거든요 😅) 당황한 기색이 역력한 지원자는 급하게 화면을 전환하였습니다. 하지만 그 이후부터는 계속해서 신경이 쓰이는지 인터뷰에 집중을 하지 못하는 모습이었습니다. 결국은 시간 내에 답안을 완성하지 못했고, 본인이 작성한 코드에 대해서도 명확히 설명하지 못했습니다. 아무래도 스스로 망했다고 생각하고 이미 인터뷰를 포기한 느낌을 받았습니다. 첫 번째 문제는 잘 푸셨기 때문에, 오히려 두 번째 문제에서 AI를 쓰지 않으셨다면 합격하실 수도 있으셨을 것 같아서 참 안타까웠습니다. 인터뷰가 끝나고 많은 생각이 들었습니다. 이미 AI가 대학생들의 삶에 깊숙히 스며든 것 같고, 현직 개발자들도 AI의 도움을 받아 업무를 수행하고 있는 상황이죠. 코딩 인터뷰라고 해서 AI를 쓰지 못하게 할 이유가 있을까요? 과연 저처럼 불완전한 인간이 면접관으로서 AI로 인해 거의 신급의 지능을 갖게 된 지원자들을 평가할 수 있을까요? 어디까지가 AI의 버프이고 어디까지가 지원자의 순수한 능력인지 어떻게 판단할 수 있을까요?

코딩 인터뷰 중 AI를 사용해도 될까요...? 🤔

얼마전에 sorting 이라는 함수를, 파라미터로 주는 배열의 요소의 값을 delay로 삼아 setTimeout으로 만든 코드 이미지를 본 기억이 나네요. 그것도 면접에서 나온 코드라고 하더군요. 굉장히 창의적인 발상이어서 인상적이었는데요.

면접의 목적이 지시사항을 이행하여 문제를 해결할 수 있는 수행 능력을 보는 것이라면 AI를 이용하는 것이 설령 그게 뭐 신의 지식 수준이 된다한들 채용에 유해할까요. 

평가 대상이 수행 능력이라면 with AI는 지원자의 레벨을 신으로 격상시킨다고 해도 무방하고, 평가가 창의성이라면 지원자가 AI를 그렇게까지 유용하게 쓸 수 없을 겁니다. 만약 그런 순간마저도 AI를 유용하게 쓴다면 더 채용해야 할 이유가 되지 않을까요. 개발 언어나 AI나 모두 개발자가 다루어야 할 도구라는 관점에서 보면요. 

무엇보다 "순수 능력"이라는 것 자체를 정량화, 정성화시키려는 시도, 혹은 그 개념 자체가 현 세대의 모던한 사고가 아닐지 그 부분을 고민하는 게 좋지 않을까 하네요. 인간의 인텔리전스를 평가하는 방법론이 이전 시대와 달라지는 걸 체감하고 있으니까요. 

﻿
퉁쳐서 계산하지 말아야 합니다. 정확하게 하나하나 따져보고 계산해야 합니다. 제 나쁜 습관 중 하나는 대충 어림잡아 예상하고 일을 하는 것입니다. 까짓것 대충 이렇게 하면 되겠지 하고 시작했다가 낭패를 본 경험이 많습니다. 겉으로 보이는 몇 가지 정보로 좋아 보이면 선택하고, 괜찮아 보이면 덥석 무는 낚기 쉬운 물고기인 편입니다.

그래서 조금만 더 꼼꼼하게 따져 보았더라면 좋았을걸, 후회하는 경우가 종종 있습니다. 대표적으로 물건을 살 때 그렇습니다. 자전거를 사고 싶다는 충동이 들면, 인터넷을 검색합니다. 그러다가 번쩍번쩍 빛나는 광고에 현혹되어 특정 상품에 퐁당 빠져듭니다. 한 번 빠지면 잘 헤어 나오지 못합니다. 여간 더 반짝거리는 다른 상품을 만나지 않는다면, 웬만하면 처음에 빠졌던 상품으로 구매했습니다. 

문제는 알고 보니 더 저렴하고 좋은 제품이 존재했던 사실입니다. 더 가볍고 더 잘나가고 가격도 저렴한 자전거가 있다는 사실을 알게 된 순간, 마치 사기라도 당한 듯 망연자실해집니다. 그리곤 새로 산 자전거에게 마음속으로 이별을 통보합니다. 아마도 저에게 사기를 치지 않았습니다. 혼자 북 치고 장구 치고 다 한 것입니다. 꼼꼼하게 따져보지 않고 그냥 좋아 보이는 몇 가지 정보만 가지고 홀랑 구매한 것입니다. 

물론 그런 선택 중에 계속 좋았던 경우도 있습니다. 다만, 확률적으로 좋지 못했던 경우가 더 많았습니다. 그래서 매번 후회하고 매번 다짐합니다. 앞으로 결정을 하기 전에 꼼꼼하게 따져보리라, 신중하게 선택하겠다고 굳은 다짐을 합니다. 그러나 망각의 동물인 저는 오늘도 까먹고 쉽게 판단하고 쉽게 결정합니다. 좋게 이야기하면 심플, 현실적으로 이야기하면 단순 무식한 사람입니다.

저는 왜 이렇게 퉁쳐서 계산하고 판단하는 걸까요? 자문자답해 보면, 모든 것이 귀찮은 것입니다. 하나하나 탐색하는 것도 귀찮고 비교하여 장점과 단점을 파악하는 것도 귀찮고 합리적인 결론을 도출하는 과정도 귀찮아하는 것입니다. 만사가 귀찮으니 그저 대충 얼추 괜찮아 보이면 모든 것이 다 좋다고 자기 암시를 걸어 의사결정이라는 선택을 내립니다. 그리곤 빠르게 잘 결정하여 좋았다고 스스로를 칭찬합니다.

그래서 여러분은 제가 매일 겪는 시행착오를 겪지 않았으면 좋겠습니다. 퉁쳐서 보지 말고, 하나하나 계산해 보면 좋겠습니다. 선택해야 하는 조건을 하나하나 차분하게 읽어보고 생각해 보세요. 더 나은 옵션은 없는지 찾아보는 일을 게을리하지 말고 열심히 탐색해 보세요. 과정을 기록하여 생각이 어떻게 변화하고 있는지 스스로를 돌아보세요. 그렇게 신중한 생각이 무르익었을 때 의사결정하는 것입니다.

표면적으로 비슷하게 생겨 보이는 것도 자세히 들여다보면 아주 작은 차이를 가지고 있습니다. 특히 대단한 특징을 갖기 어려운 공산품이 그렇습니다. 손톱깎이가 그놈이 그놈 같고, 머리빗도 그 녀석이 그 녀석 같습니다. 그런데 자세히 보면 아주 작은 차이가 있습니다. 디테일이 살아있다는 칭찬을 받는 제품들이 있습니다. 그게 아주 작은 차이를 만드는 장인의 손길에서 태어나는 것입니다. 아니면 반대로 모조품을 찍어내는 공장에서 대충 만든 것도 얼핏 보기에 장인이 만든 것과 비슷해 보이기도 합니다.

회사를 선택하는 순간에도 자세히 들여다보아야 합니다. 문화, 복지, 일을 하는 방식 등 하나하나 꼼꼼하게 따져보는 것입니다. 대충 좋아 보여서 입사하면 100% 반품 또는 중고거래하게 되어 있습니다. 1년도 안 돼서 이직하고 싶은 마음이 드는 이유는 입사를 선택하는 과정이 신중하지 않았기 때문입니다.

회사가 인재를 선택하는 것도 마찬가지입니다. 성격, 역량, 경험, 관심 등을 하나하나 꼼꼼하게 따져 보아야 합니다. 명문 대학교를 졸업하고, 브랜드 인지도 높은 회사 경험이 있는 사람이 좋아 보여서 덥석 채용하면, 후회할 가능성이 58000%입니다. 화려한 스펙을 가진 사람이 훌륭하지 않다는 것이 아니라 회사에 맞는 인재를 고려하지 않고 보이는 것으로 대충 판단하면 안 됩니다.

건강을 유지하려면 우리 몸 하나하나를 들여다보아야 합니다. 손과 발, 얼굴, 몸과 같이 눈으로 확인할 수 있는 것도 중요합니다. 우리가 정기적으로 건강검진을 받으러 가서 눈으로 직접 볼 수 없는 장기를 사진 찍고 두드려보는 이유는 꼼꼼하게 확인하기 위해서입니다. 전신사진을 한 번에 찍어서 건강한지 판단할 수 있다면 좋으련만 뇌 따라 폐 따로 콩팥 따로 하나하나 살펴봐야 비로소 건강한지 알 수 있습니다.

귀찮음을 극복하고 꼼꼼하게 확인하는 우리가 되길 진심으로 응원합니다.

﻿퉁쳐서 계산하지 말아야 합니다. 정확하게 하나하나 따져보고 계산해야 합니다. 제 나쁜 습관 중 하나는 대충 어림잡아 예상하고 일을 하는 것입니다. 까짓것 대충 이렇게 하면 되겠지 하고 시작했다가 낭패를 본 경험이 많습니다. 겉으로 보이는 몇 가지 정보로 좋아 보이면 선택하고, 괜찮아 보이면 덥석 무는 낚기 쉬운 물고기인 편입니다. 그래서 조금만 더 꼼꼼하게 따져 보았더라면 좋았을걸, 후회하는 경우가 종종 있습니다. 대표적으로 물건을 살 때 그렇습니다. 자전거를 사고 싶다는 충동이 들면, 인터넷을 검색합니다. 그러다가 번쩍번쩍 빛나는 광고에 현혹되어 특정 상품에 퐁당 빠져듭니다. 한 번 빠지면 잘 헤어 나오지 못합니다. 여간 더 반짝거리는 다른 상품을 만나지 않는다면, 웬만하면 처음에 빠졌던 상품으로 구매했습니다.&nbsp; 문제는 알고 보니 더 저렴하고 좋은 제품이 존재했던 사실입니다. 더 가볍고 더 잘나가고 가격도 저렴한 자전거가 있다는 사실을 알게 된 순간, 마치 사기라도 당한 듯 망연자실해집니다. 그리곤 새로 산 자전거에게 마음속으로 이별을 통보합니다. 아마도 저에게 사기를 치지 않았습니다. 혼자 북 치고 장구 치고 다 한 것입니다. 꼼꼼하게 따져보지 않고 그냥 좋아 보이는 몇 가지 정보만 가지고 홀랑 구매한 것입니다.&nbsp; 물론 그런 선택 중에 계속 좋았던 경우도 있습니다. 다만, 확률적으로 좋지 못했던 경우가 더 많았습니다. 그래서 매번 후회하고 매번 다짐합니다. 앞으로 결정을 하기 전에 꼼꼼하게 따져보리라, 신중하게 선택하겠다고 굳은 다짐을 합니다. 그러나 망각의 동물인 저는 오늘도 까먹고 쉽게 판단하고 쉽게 결정합니다. 좋게 이야기하면 심플, 현실적으로 이야기하면 단순 무식한 사람입니다. 저는 왜 이렇게 퉁쳐서 계산하고 판단하는 걸까요? 자문자답해 보면, 모든 것이 귀찮은 것입니다. 하나하나 탐색하는 것도 귀찮고 비교하여 장점과 단점을 파악하는 것도 귀찮고 합리적인 결론을 도출하는 과정도 귀찮아하는 것입니다. 만사가 귀찮으니 그저 대충 얼추 괜찮아 보이면 모든 것이 다 좋다고 자기 암시를 걸어 의사결정이라는 선택을 내립니다. 그리곤 빠르게 잘 결정하여 좋았다고 스스로를 칭찬합니다. 그래서 여러분은 제가 매일 겪는 시행착오를 겪지 않았으면 좋겠습니다. 퉁쳐서 보지 말고, 하나하나 계산해 보면 좋겠습니다. 선택해야 하는 조건을 하나하나 차분하게 읽어보고 생각해 보세요. 더 나은 옵션은 없는지 찾아보는 일을 게을리하지 말고 열심히 탐색해 보세요. 과정을 기록하여 생각이 어떻게 변화하고 있는지 스스로를 돌아보세요. 그렇게 신중한 생각이 무르익었을 때 의사결정하는 것입니다. 표면적으로 비슷하게 생겨 보이는 것도 자세히 들여다보면 아주 작은 차이를 가지고 있습니다. 특히 대단한 특징을 갖기 어려운 공산품이 그렇습니다. 손톱깎이가 그놈이 그놈 같고, 머리빗도 그 녀석이 그 녀석 같습니다. 그런데 자세히 보면 아주 작은 차이가 있습니다. 디테일이 살아있다는 칭찬을 받는 제품들이 있습니다. 그게 아주 작은 차이를 만드는 장인의 손길에서 태어나는 것입니다. 아니면 반대로 모조품을 찍어내는 공장에서 대충 만든 것도 얼핏 보기에 장인이 만든 것과 비슷해 보이기도 합니다. 회사를 선택하는 순간에도 자세히 들여다보아야 합니다. 문화, 복지, 일을 하는 방식 등 하나하나 꼼꼼하게 따져보는 것입니다. 대충 좋아 보여서 입사하면 100% 반품 또는 중고거래하게 되어 있습니다. 1년도 안 돼서 이직하고 싶은 마음이 드는 이유는 입사를 선택하는 과정이 신중하지 않았기 때문입니다. 회사가 인재를 선택하는 것도 마찬가지입니다. 성격, 역량, 경험, 관심 등을 하나하나 꼼꼼하게 따져 보아야 합니다. 명문 대학교를 졸업하고, 브랜드 인지도 높은 회사 경험이 있는 사람이 좋아 보여서 덥석 채용하면, 후회할 가능성이 58000%입니다. 화려한 스펙을 가진 사람이 훌륭하지 않다는 것이 아니라 회사에 맞는 인재를 고려하지 않고 보이는 것으로 대충 판단하면 안 됩니다. 건강을 유지하려면 우리 몸 하나하나를 들여다보아야 합니다. 손과 발, 얼굴, 몸과 같이 눈으로 확인할 수 있는 것도 중요합니다. 우리가 정기적으로 건강검진을 받으러 가서 눈으로 직접 볼 수 없는 장기를 사진 찍고 두드려보는 이유는 꼼꼼하게 확인하기 위해서입니다. 전신사진을 한 번에 찍어서 건강한지 판단할 수 있다면 좋으련만 뇌 따라 폐 따로 콩팥 따로 하나하나 살펴봐야 비로소 건강한지 알 수 있습니다. 귀찮음을 극복하고 꼼꼼하게 확인하는 우리가 되길 진심으로 응원합니다.﻿

퉁치기

Testing Library는 웹 프론트엔드 테스트에서 사실 상 표준으로 자리잡은 라이브러리입니다. React 뿐만 아니라 Vue, Svelte, Angular 등 거의 대부분의 자바스크립트 프레임워크를 지원하고 있죠.

이번 영상에서는 Testing Library를 사용해서 React 컴포넌트에 대한 테스트 코드를 어떻게 작성하는지 함께 알아보겠습니다.

📺 동영상: https://youtu.be/TBFogFU7cls
📝 포스팅: https://www.daleseo.com/react-testing-library/

Testing Library는 웹 프론트엔드 테스트에서 사실 상 표준으로 자리잡은 라이브러리입니다. React 뿐만 아니라 Vue, Svelte, Angular 등 거의 대부분의 자바스크립트 프레임워크를 지원하고 있죠. 이번 영상에서는 Testing Library를 사용해서 React 컴포넌트에 대한 테스트 코드를 어떻게 작성하는지 함께 알아보겠습니다. 📺 동영상: https://youtu.be/TBFogFU7cls📝 포스팅: https://www.daleseo.com/react-testing-library/

React Testing Library 사용법

AI로 인해 영어는 이제 진짜 말하기만이 답 입니다. 그리고 말만 할 줄 알면 기회가 정말 크게 넓어질거구요.

이제는 모두가 체감하고 있듯이 앞으로 영어로 읽기 쓰기는 큰 의미가 없어지겠지만, 말하기는 더욱 중요해질 것이거든요.

아무리 통역이 발달해도 사람간의 의사결정은 결국 면대면의 대화를 통해서 이뤄질 것이 분명하니까요. 게다가 읽기쓰기의 제약이 없어진 이상 글로벌로 일 할 기회는 더욱 커질 것이고요.

하지만, 최근에 ㅅㅍ이라든가 녹생 부엉이도 그렇고 다양한 말하기 연습 앱들이 우후죽순 나오고 있지만, 사실 거의 모두가 턴제로 자막을 읽는 사실상 읽기 쓰기 연습일 뿐이더라고요. 그래서 아무리해도 실제로는 듣기와 말하기가 늘지 않았습니다(!!)

아미고(Ameego)는 그래서 만든건데요. 실제와 같은 대화 경험으로, 다양한 발음과 말투, 어휘와 주제로 대화하는 경험을 줘서 영어 듣기와 말하기에 금방 익숙해지도록 만들어줍니다.

무엇보다, 대부분 영어 초보라서 시도도 안하시는데, 사실 우리나라 사람들의 거의 대부분은 대화를 할 수 있는 상태입니다. 설문을 해 봤는데, 자기가 완전 초보라고 생각하시는 분도 약간 어려워요 정도였거든요.

한두달만해도 확실히 영어 말하기가 편해졌다는 걸 체감하게 될겁니다. 한 달만 지나면 듣기도 편해지고 말하는 시간이 진짜 금방 늘어요. 다른 앱들은 이런 경험을 전혀 할 수가 없었거든요. 제 경험상 전화영어만이 이런 경험을 줄 수 있었습니다. 하지만 전화영어는 제약이 좀 크죠.

아무튼 아직 초기 버전이라 부족한 점이 많지만, 지금 경험으로써도 분명히 큰 도움이 될거라 자신합니다. 일단 만들면서 제가 많이 늘었거든요! 😁

앱 다운로드: https://ameego.club

AI로 인해 영어는 이제 진짜 말하기만이 답 입니다. 그리고 말만 할 줄 알면 기회가 정말 크게 넓어질거구요. 이제는 모두가 체감하고 있듯이 앞으로 영어로 읽기 쓰기는 큰 의미가 없어지겠지만, 말하기는 더욱 중요해질 것이거든요. 아무리 통역이 발달해도 사람간의 의사결정은 결국 면대면의 대화를 통해서 이뤄질 것이 분명하니까요. 게다가 읽기쓰기의 제약이 없어진 이상 글로벌로 일 할 기회는 더욱 커질 것이고요. 하지만, 최근에 ㅅㅍ이라든가 녹생 부엉이도 그렇고 다양한 말하기 연습 앱들이 우후죽순 나오고 있지만, 사실 거의 모두가 턴제로 자막을 읽는 사실상 읽기 쓰기 연습일 뿐이더라고요. 그래서 아무리해도 실제로는 듣기와 말하기가 늘지 않았습니다(!!) 아미고(Ameego)는 그래서 만든건데요. 실제와 같은 대화 경험으로, 다양한 발음과 말투, 어휘와 주제로 대화하는 경험을 줘서 영어 듣기와 말하기에 금방 익숙해지도록 만들어줍니다. 무엇보다, 대부분 영어 초보라서 시도도 안하시는데, 사실 우리나라 사람들의 거의 대부분은 대화를 할 수 있는 상태입니다. 설문을 해 봤는데, 자기가 완전 초보라고 생각하시는 분도 약간 어려워요 정도였거든요. 한두달만해도 확실히 영어 말하기가 편해졌다는 걸 체감하게 될겁니다. 한 달만 지나면 듣기도 편해지고 말하는 시간이 진짜 금방 늘어요. 다른 앱들은 이런 경험을 전혀 할 수가 없었거든요. 제 경험상 전화영어만이 이런 경험을 줄 수 있었습니다. 하지만 전화영어는 제약이 좀 크죠. 아무튼 아직 초기 버전이라 부족한 점이 많지만, 지금 경험으로써도 분명히 큰 도움이 될거라 자신합니다. 일단 만들면서 제가 많이 늘었거든요! 😁 앱 다운로드: https://ameego.club

In this paper, we revisit one of the simplest problems in data structures: the task of inserting elements into an open-addressed hash table so that elements can later be retrieved with as few probes as possible. We show that, even without reordering elements over time, it is possible to construct a hash table that achieves far better expected search complexities (both amortized and worst-case) than were previously thought possible. Along the way, we disprove the central conjecture left by Yao in his seminal paper ``Uniform Hashing is Optimal''. All of our results come with matching lower bounds.

Optimal Bounds for Open Addressing Without Reordering

📰 대학생이 40년만에 해시테이블의 성능 향상을 이뤄냈다고

해시테이블 알고리즘은 워낙 오래된 연구라서 아무도 그 이상 최적화하기 어렵다고 생각했는데, Andrew Krapivin이라는 학부생이 그 틀을 깨고 알고리즘을 발명했다는 것이 재미난 포인트입니다.

역시 아직 미해결 문제는 많고, 상식이라는 고정관념에 쩌들지 않은 ㅎㅎ 새로운 세대만이 해결할 수 있는 문제도 많지 않나 싶네요.

논문: https://arxiv.org/abs/2501.02305

기사: https://www.wired.com/story/undergraduate-upends-a-40-year-old-data-science-conjecture/

📰 대학생이 40년만에 해시테이블의 성능 향상을 이뤄냈다고 해시테이블 알고리즘은 워낙 오래된 연구라서 아무도 그 이상 최적화하기 어렵다고 생각했는데, Andrew Krapivin이라는 학부생이 그 틀을 깨고 알고리즘을 발명했다는 것이 재미난 포인트입니다. 역시 아직 미해결 문제는 많고, 상식이라는 고정관념에 쩌들지 않은 ㅎㅎ 새로운 세대만이 해결할 수 있는 문제도 많지 않나 싶네요. 논문: https://arxiv.org/abs/2501.02305 기사: https://www.wired.com/story/undergraduate-upends-a-40-year-old-data-science-conjecture/

arXiv.org

First and foremost, thank you to everyone who has contributed to styled-components over the years. Open Source is hard work, and many of the larger feature and/or refactoring drives probably would never have shipped without your support! As...

Thank you - styled-components

Styled Components가 공식적으로 개발을 중단하고 후원도 그만 받는다고 합니다. CSS-in-JS 분야에 선구자적인 역할을 했던 라이브러리라고 생각합니다. Emotion, Stitches, Vanilla Extract 등 그 이후에 나온 수많은 CSS-in-JS 라이브러리에 영감을 주었죠.

Styled Components의 시장 점유율이 워낙 높아서 예전에 jQuery가 그랬던 것처럼 실제 사용량은 수년에 걸쳐 서서히 줄어들거라고 생각합니다. 하지만 신규 프로젝트에서는 Styled Components를 선택하지 않도록 주의해야할 것 같습니다.

React 생태계가 RSC로 넘어가면서 빌드 타임에 스타일링을 하는 Panda CSS나 StyleX과 같은 차세대 라이브러리가 대체제로 주목받고 있으니 참고하세요.

Styled Components가 공식적으로 개발을 중단하고 후원도 그만 받는다고 합니다. CSS-in-JS 분야에 선구자적인 역할을 했던 라이브러리라고 생각합니다. Emotion, Stitches, Vanilla Extract 등 그 이후에 나온 수많은 CSS-in-JS 라이브러리에 영감을 주었죠. Styled Components의 시장 점유율이 워낙 높아서 예전에 jQuery가 그랬던 것처럼 실제 사용량은 수년에 걸쳐 서서히 줄어들거라고 생각합니다. 하지만 신규 프로젝트에서는 Styled Components를 선택하지 않도록 주의해야할 것 같습니다. React 생태계가 RSC로 넘어가면서 빌드 타임에 스타일링을 하는 Panda CSS나 StyleX과 같은 차세대 라이브러리가 대체제로 주목받고 있으니 참고하세요.

opencollective.com

👋 굿바이 Styled Components 🥹

1. 혼자 열심히 하는 건 별로 안 중요합니다. 다른 사람에게 기여해야, 다시 말해 다른 사람이 여러분으로 인해 더 나은 성과를 얻었다고 느껴야 커리어가 성장합니다.

2. 충성이 밥 먹여주지 않습니다. 기업은 이익을 중요시 합니다. 회사에 이익이 되어야 커리어가 발전할 수 있습니다.

3. 직함도 별로 안 중요합니다. 특히 스타트업에선 직함은 아무런 의미가 없어요. 직함보다 중요한 게 실력이고, 결과입니다. 그러니 타이틀에 신경쓰지 말고, 실력과 결과를 보여주세요.

4. 리더가 항상 옳은 건 아니고, 리더 역시 잘못된 판단과 실수를 합니다. 그때 진실을 발견할 수 있도록 도우세요.

5. 네트워킹에서 중요한 건 많이 아는 게 아니라, 누구를 아느냐입니다. 그러니 여기저기 행사에 다니지 말고, 진정한 관계를 쌓으세요.

6. 번아웃은 자랑거리가 아닙니다. 번아웃이 올 때까지 마냥 열심히 일하는 게 중요한 게 아니라, 영리하게 자기 에너지를 잘 관리하는 것이 중요합니다.

7. 편하고 괜찮다고 느끼는 순간, 성장은 파괴됩니다. 불편함과 위험을 감수하지 않고서, 성장할 수는 없습니다.

8. 피드백은 그 자체로 선물입니다. 심지어 악독한 비판까지도 시간이 지나면 도움이 됩니다. 그러니 피드백은 격렬하게 환영하세요.

9. 당신이 대체불가능하다는 착각은 절대 하지 마세요. 비즈니스에서는 어떤 일이든, 어떤 사람이든, 대체 가능하고, 시장은 진공 상태를 허용하지 않습니다. 그러니 자신이 대체불가능하다는 생각은 하지 말고, 지금 이 순간 다른 사람에 더 긍정적인 영향을 미치는 데 집중하세요.

10. 완벽주의는 성장을 늦추는 독입니다. 완벽함을 추구한다고 망설이고 주저하는 순간, 그만큼 성장 속도는 더뎌집니다. 그러니 완벽함을 버리고, 초라한 상태에서 출발해 계속해서 발전하고 진화하는 것을 추구하세요.

11. 모든 경험은 연결됩니다. 지금 하기 싫은 일, 지금의 실패, 지금의 부끄러움이 훗날 큰 승리의 밑거름이 되기도 합니다. 그러니 장기적 관점에서 바라보세요. 순탄치 않은 길이 오히려 지나고 나면 당신의 커리어를 더욱 풍성하게 만들어줄 겁니다.

12. 커리어에서는 날로 먹으려고 하다간 오히려 낭패를 봅니다. 그 누구도 당신의 성장을 대신 이끌어주지 않기 때문입니다. 그러니 안주하려는 자기 자신을 더 잘 통제하고, 기회와 리스크를 추구하세요. 누군가가 내 커리어를 대신 끌어줄 것이라고 믿는 순간, 오히려 커리어는 망가집니다.

1. 혼자 열심히 하는 건 별로 안 중요합니다. 다른 사람에게 기여해야, 다시 말해 다른 사람이 여러분으로 인해 더 나은 성과를 얻었다고 느껴야 커리어가 성장합니다. 2. 충성이 밥 먹여주지 않습니다. 기업은 이익을 중요시 합니다. 회사에 이익이 되어야 커리어가 발전할 수 있습니다. 3. 직함도 별로 안 중요합니다. 특히 스타트업에선 직함은 아무런 의미가 없어요. 직함보다 중요한 게 실력이고, 결과입니다. 그러니 타이틀에 신경쓰지 말고, 실력과 결과를 보여주세요. 4. 리더가 항상 옳은 건 아니고, 리더 역시 잘못된 판단과 실수를 합니다. 그때 진실을 발견할 수 있도록 도우세요. 5. 네트워킹에서 중요한 건 많이 아는 게 아니라, 누구를 아느냐입니다. 그러니 여기저기 행사에 다니지 말고, 진정한 관계를 쌓으세요. 6. 번아웃은 자랑거리가 아닙니다. 번아웃이 올 때까지 마냥 열심히 일하는 게 중요한 게 아니라, 영리하게 자기 에너지를 잘 관리하는 것이 중요합니다. 7. 편하고 괜찮다고 느끼는 순간, 성장은 파괴됩니다. 불편함과 위험을 감수하지 않고서, 성장할 수는 없습니다. 8. 피드백은 그 자체로 선물입니다. 심지어 악독한 비판까지도 시간이 지나면 도움이 됩니다. 그러니 피드백은 격렬하게 환영하세요. 9. 당신이 대체불가능하다는 착각은 절대 하지 마세요. 비즈니스에서는 어떤 일이든, 어떤 사람이든, 대체 가능하고, 시장은 진공 상태를 허용하지 않습니다. 그러니 자신이 대체불가능하다는 생각은 하지 말고, 지금 이 순간 다른 사람에 더 긍정적인 영향을 미치는 데 집중하세요. 10. 완벽주의는 성장을 늦추는 독입니다. 완벽함을 추구한다고 망설이고 주저하는 순간, 그만큼 성장 속도는 더뎌집니다. 그러니 완벽함을 버리고, 초라한 상태에서 출발해 계속해서 발전하고 진화하는 것을 추구하세요. 11. 모든 경험은 연결됩니다. 지금 하기 싫은 일, 지금의 실패, 지금의 부끄러움이 훗날 큰 승리의 밑거름이 되기도 합니다. 그러니 장기적 관점에서 바라보세요. 순탄치 않은 길이 오히려 지나고 나면 당신의 커리어를 더욱 풍성하게 만들어줄 겁니다. 12. 커리어에서는 날로 먹으려고 하다간 오히려 낭패를 봅니다. 그 누구도 당신의 성장을 대신 이끌어주지 않기 때문입니다. 그러니 안주하려는 자기 자신을 더 잘 통제하고, 기회와 리스크를 추구하세요. 누군가가 내 커리어를 대신 끌어줄 것이라고 믿는 순간, 오히려 커리어는 망가집니다.

커리어를 쌓아야 할 때 알아야 하는 잔인한 사실들

🗞️ 간밤에 구글이 Gemini 2.5 Pro를 출시했는데요. 벤치마크 상으로는 GPT-4.5와 Claude 3.7 의 성능을 크게 뛰어넘는 결과를 보여줍니다. 특히 코딩능력이 매우 크게 향상되었는데요.

그.런.데, 이번에도 역시 OpenAI가 크게 초를 칩니다 ㅋㅋ 간밤에 GPT-4o 네이티브 이미지 생성 능력을 크게 향상시켜 ChatGPT와 Sora에서 사용할 수 있게 공개했습니다.

이미지 생성은 OpenAI가 꽤 뒤쳐지는 분야였고, 최근 Gemini가 이미지 생성 편집 능력으로 꽤 각광을 받고 있었는데요. 생성 성능이 특히 편집 성능이 정말 미쳤습니다. 진짜 이젠 AI로 생성한 것인지 거의 모를 정도네요.

암튼 오늘도 이렇게 OpenAI가 뒤통수(?)를 크게 치네요. ㅋㅋ OpenAI의 다음 팝콘 드라마는 어떤 것일지 궁금합니다. 😎🍿🥤

🗞️ 간밤에 구글이 Gemini 2.5 Pro를 출시했는데요. 벤치마크 상으로는 GPT-4.5와 Claude 3.7 의 성능을 크게 뛰어넘는 결과를 보여줍니다. 특히 코딩능력이 매우 크게 향상되었는데요. 그.런.데, 이번에도 역시 OpenAI가 크게 초를 칩니다 ㅋㅋ 간밤에 GPT-4o 네이티브 이미지 생성 능력을 크게 향상시켜 ChatGPT와 Sora에서 사용할 수 있게 공개했습니다. 이미지 생성은 OpenAI가 꽤 뒤쳐지는 분야였고, 최근 Gemini가 이미지 생성 편집 능력으로 꽤 각광을 받고 있었는데요. 생성 성능이 특히 편집 성능이 정말 미쳤습니다. 진짜 이젠 AI로 생성한 것인지 거의 모를 정도네요. 암튼 오늘도 이렇게 OpenAI가 뒤통수(?)를 크게 치네요. ㅋㅋ OpenAI의 다음 팝콘 드라마는 어떤 것일지 궁금합니다. 😎🍿🥤

🗞️ 간밤에 구글이 Gemini 2.5 Pro를 출시했는데요. 벤

실패에 대한 잘못된 생각 | 진행 중인 강의 보러 가기 : https://litt.ly/lbyd   "기획자가 시장을 제대로 이해하지 못했어요""개발자가 구현을 제대로 못했어요""디자이너가 사용자 경험을 고려하지 않았어요"...  우리가 제품을 만들 때 가장 많이 듣는 실패 이유는 무엇일까요? 이야기를 나누다보면 대부분 특정 직무 혹은 남 탓을 해요. 이런 생각은 근본적으로 잘못되었어

'혼자'가 아닌 '함께'

"기획자가 시장을 제대로 이해하지 못했어요"
"개발자가 구현을 제대로 못했어요"
"디자이너가 사용자 경험을 고려하지 않았어요"
...

제품의 지표가 안 올라오는 이유는 고객 이해 부족과 사일로 현상이 많아요. 그렇기 때문에 제품을 만들 때는 항상 혼자가 아닌 함께 하는 것이 무엇보다 중요해요!

우리가 제품을 만들 때 가장 많이 듣는 실패 이유는 무엇일까요? 이야기를 나누다보면 대부분 특정 직무 혹은 남 탓을 해요. 이런 생각은 근본적으로 잘못되었어요. 왜냐하면 성공적인 제품은 '한 사람'의 노력이 아닌 '모두의 협업'에서 나오기 때문이에요.
 
 
왜 실패하나요?
특정 기능을 만들고 나서 지표가 오르지 않는 진짜 이유는 2가지로 분류할 수 있어요.
 
1️⃣ 고객 이해 부족
가장 큰 실패 이유라고 해도 무방해요. 우리가 아무리 좋은 기능을 만든다고 해도, 사용할 사람이 필요가 없으면 의미가 없어요. 그렇기 때문에 고객을 이해한다는 것인 정말 중요해요. 제품을 만드는 모두가 고객을 이해하지 못하면 결국 아무도 고객을 이해하지 못해요.
 
2️⃣ 사일로(Silo) 현상
대부분 초기 창업 혹은 부서화가 집중된 회사에 나오는 현상이에요. "이건 기획자의 일이야", "이건 개발자의 일이야"라고 경계를 긋는 현상이죠. 해야하는 업무에 대해서는 기준이 필요하지만, 고객을 이해하는 일에 대해 경계를 긋는 것은 지양해야 해요. 제품이 성장하기 위해서는 정말 다양한 관점이 모여서 리스크를 줄여야 해요.
 
이렇게 사일로 현상이 심화되면 결국 단절된 커뮤니케이션만 하게 돼요. 자기 영역만 고수하는 것은 어떻게 보면 일하기에는 편해져요. 소위 효율성이라는 측면은 극강으로 올라가게 되는 것이지만 전체 그림을 볼 수 없어요. 그래서 아무도 사용하지 않는 기능을 만들게 되는 것이죠.
 
 
더보기 : https://brunch.co.kr/@lbyd-hj/26

 * 진행 중인 강의 보러 가기 : https://litt.ly/lbyd
 * PM/PO/제품 개발에 대한 인사이트를 얻고 싶다면, 오픈채팅방에 참여해 주세요!
   https://open.kakao.com/o/g7XO1A5g 참여코드 : til2025
 * Threads : https://www.threads.net/@lbyd_learning.by.doing
 * 뉴스레터 구독하기 : https://maily.so/marcus.lee
 * 유튜브 구독하기 : www.youtube.com/@LbyD_HJ?sub_confirmation=1
 * 커피챗 및 멘토링 신청하기 : https://inf.run/GRTee
 * 팀 코칭 신청하기 : https://open.kakao.com/o/sh47Hq4g

"기획자가 시장을 제대로 이해하지 못했어요" "개발자가 구현을 제대로 못했어요" "디자이너가 사용자 경험을 고려하지 않았어요" ... 제품의 지표가 안 올라오는 이유는 고객 이해 부족과 사일로 현상이 많아요. 그렇기 때문에 제품을 만들 때는 항상 혼자가 아닌 함께 하는 것이 무엇보다 중요해요! 우리가 제품을 만들 때 가장 많이 듣는 실패 이유는 무엇일까요? 이야기를 나누다보면 대부분 특정 직무 혹은 남 탓을 해요. 이런 생각은 근본적으로 잘못되었어요. 왜냐하면 성공적인 제품은 '한 사람'의 노력이 아닌 '모두의 협업'에서 나오기 때문이에요.&nbsp;&nbsp;왜 실패하나요?특정 기능을 만들고 나서 지표가 오르지 않는 진짜 이유는 2가지로 분류할 수 있어요.&nbsp;1️⃣ 고객 이해 부족가장 큰 실패 이유라고 해도 무방해요. 우리가 아무리 좋은 기능을 만든다고 해도, 사용할 사람이 필요가 없으면 의미가 없어요. 그렇기 때문에 고객을 이해한다는 것인 정말 중요해요. 제품을 만드는 모두가 고객을 이해하지 못하면 결국 아무도 고객을 이해하지 못해요.&nbsp;2️⃣ 사일로(Silo) 현상대부분 초기 창업 혹은 부서화가 집중된 회사에 나오는 현상이에요. "이건 기획자의 일이야", "이건 개발자의 일이야"라고 경계를 긋는 현상이죠. 해야하는 업무에 대해서는 기준이 필요하지만, 고객을 이해하는 일에 대해 경계를 긋는 것은 지양해야 해요. 제품이 성장하기 위해서는 정말 다양한 관점이 모여서 리스크를 줄여야 해요.&nbsp;이렇게 사일로 현상이 심화되면 결국 단절된 커뮤니케이션만 하게 돼요. 자기 영역만 고수하는 것은 어떻게 보면 일하기에는 편해져요. 소위 효율성이라는 측면은 극강으로 올라가게 되는 것이지만 전체 그림을 볼 수 없어요. 그래서 아무도 사용하지 않는 기능을 만들게 되는 것이죠.&nbsp;&nbsp;더보기 : https://brunch.co.kr/@lbyd-hj/26 <ul ><li>진행 중인 강의 보러 가기 : https://litt.ly/lbyd</li><li>PM/PO/제품 개발에 대한 인사이트를 얻고 싶다면, 오픈채팅방에 참여해 주세요! https://open.kakao.com/o/g7XO1A5g&nbsp;참여코드 : til2025</li><li>Threads :&nbsp;https://www.threads.net/@lbyd_learning.by.doing</li><li>뉴스레터 구독하기 :&nbsp;https://maily.so/marcus.lee</li><li>유튜브 구독하기 :&nbsp;www.youtube.com/@LbyD_HJ?sub_confirmation=1</li><li>커피챗 및 멘토링 신청하기 :&nbsp;https://inf.run/GRTee</li><li>팀 코칭 신청하기 :&nbsp;https://open.kakao.com/o/sh47Hq4g</li></ul>

Brunch Story

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

 - YouTube

router.refresh 와 window.location.reload 의 차이점을 아시나요?
이름만 보면 둘은 비슷한 역할을 할 것 같은데
호출해보니, Next.js 가 내부적으로 관리하는 router state 에 대해
router.refresh 는 새로고침 해주지 않더라고요.

어떠한 차이점이 있는지 조금 더 자세히 알고 싶어서
Next.js 소스코드를 까보며 공부해 보았습니다.

https://youtu.be/Sc9O1hILOEU

router.refresh 와 window.location.reload 의 차이점을 아시나요? 이름만 보면 둘은 비슷한 역할을 할 것 같은데 호출해보니, Next.js 가 내부적으로 관리하는 router state 에 대해 router.refresh 는 새로고침 해주지 않더라고요. 어떠한 차이점이 있는지 조금 더 자세히 알고 싶어서 Next.js 소스코드를 까보며 공부해 보았습니다. https://youtu.be/Sc9O1hILOEU

youtu.be

router.refresh 와 window.location.rel

갭타임(Gap time)은
하루에 발생하는 큰 이벤트들 사이에 발생하는
상대적으로 짧은 빈 시간을 의미합니다.

예를 들어, 하루에 운동하는 스케쥴 이후에 남는 시간이나,
한 회의에서 다른 회의로 이동하기 전 비는 시간이나,
또는 다른 사람들과의 약속 전 10분 정도
남는 시간을 갭 타임이라고 부릅니다.

저는 이런 갭타임(Gap Time)에
저만의 메모를 하는 습관을 들이고 있어요.

노트북을 가지고 있는 상황에는 주로 Notion에,
핸드폰을 가지고 있는 상황에는 메모장에
그리고 전자기기가 없는 상황에는 제 수첩에
그날 제 머리속에 남았던 생각이나,
또는 중요한 스케쥴을 정리하는 용도로 사용합니다.

이 짧은 시간을 활용하면,
얼마나 활용하겠냐는 생각이 드실수 있습니다.
하지만 짜투리 시간에 이런 작은 습관들을 만들면,
의외로 높은 집중력을 활용해
필요한 일들을 빠르게 처리할 수 있습니다.

특히 이메일을 보내거나,
아님 기획을 해야하는 상황들이 발생했을 때,
갭 타임의 짧고 높은 집중력을 발휘하면,
평소에 30분 걸리던 일들이 5분안에 해결되는
놀라운 상황도 종종 일어납니다.

그리고 가장 좋은 점은 하루의 성취감이 달라진다는 점이에요.
계획한 일이 짧은 시간 동안 내 의지로 해결했다는
그 기분은 하루의 강렬한 도파민으로 작용되기도 합니다.

제가 주로 하는 갭 타임 포커싱 방법을 알려드릴게요.
위에서 말한 메모 방법을 사용해서 이렇게 적을수 있어요.

- 짧은 문장으로 하루의 스케쥴 정리하기
- 예시) 12:30 000과 화상미팅
- 중요한 생각이나, 아이디어가 떠오르면 메모하기
- 예시) 한 시간의 계획이 열 시간의 일을 절약한다.
- 좋은 글이나, 포스트를 보면 링크 저장하기
- 예시) 갭타임 포커싱을 잘 하는 3가지 방법

여러분들의 갭타임(Gap Time)을 활용하는 방법은
어떤 것들이 있나요?

갭타임(Gap time)은 하루에 발생하는 큰 이벤트들 사이에 발생하는 상대적으로 짧은 빈 시간을 의미합니다. 예를 들어, 하루에 운동하는 스케쥴 이후에 남는 시간이나, 한 회의에서 다른 회의로 이동하기 전 비는 시간이나, 또는 다른 사람들과의 약속 전 10분 정도 남는 시간을 갭 타임이라고 부릅니다. 저는 이런 갭타임(Gap Time)에 저만의 메모를 하는 습관을 들이고 있어요. 노트북을 가지고 있는 상황에는 주로 Notion에, 핸드폰을 가지고 있는 상황에는 메모장에 그리고 전자기기가 없는 상황에는 제 수첩에 그날 제 머리속에 남았던 생각이나, 또는 중요한 스케쥴을 정리하는 용도로 사용합니다. 이 짧은 시간을 활용하면, 얼마나 활용하겠냐는 생각이 드실수 있습니다. 하지만 짜투리 시간에 이런 작은 습관들을 만들면, 의외로 높은 집중력을 활용해 필요한 일들을 빠르게 처리할 수 있습니다. 특히 이메일을 보내거나, 아님 기획을 해야하는 상황들이 발생했을 때, 갭 타임의 짧고 높은 집중력을 발휘하면, 평소에 30분 걸리던 일들이 5분안에 해결되는 놀라운 상황도 종종 일어납니다. 그리고 가장 좋은 점은 하루의 성취감이 달라진다는 점이에요. 계획한 일이 짧은 시간 동안 내 의지로 해결했다는 그 기분은 하루의 강렬한 도파민으로 작용되기도 합니다. 제가 주로 하는 갭 타임 포커싱 방법을 알려드릴게요. 위에서 말한 메모 방법을 사용해서 이렇게 적을수 있어요. - 짧은 문장으로 하루의 스케쥴 정리하기 - 예시) 12:30 000과 화상미팅 - 중요한 생각이나, 아이디어가 떠오르면 메모하기 - 예시) 한 시간의 계획이 열 시간의 일을 절약한다. - 좋은 글이나, 포스트를 보면 링크 저장하기 - 예시) 갭타임 포커싱을 잘 하는 3가지 방법 여러분들의 갭타임(Gap Time)을 활용하는 방법은 어떤 것들이 있나요?

갭타임 포커싱 (Gap Time Focusing) 활용하기

얼마전 경기 침체 대비 일환 노후 대책 점검을 했다. 국민연금 수령 나이가 65세니 65세 이후 생활을 수입 측면에서 현재 상황을 기준으로 예상해보았다.

일단 국민연금을 제대로 받으려면 (국민연금을 믿어서가 아니라 학교 졸업하고 사회생활, 즉 직장생활을 시작하면서 내 의지와 상관없이 가입이 되어버렸고 이미 20여년이 되었고 여전히 내야만 하는 상황이라 싫던 좋던 포기할 수 없으니 눈물을 머금고) 60세까지 더 내야 하기 때문에 수단과 방법을 가리지 않고 최소한 65세까지는 일해야만 한다는 전제다. 국민연금은 60세까지 내야만 하고 받는건 65세니 5년의 공백을 더 몸빵해야만 한다. 아무튼...

65세 이후 일을 전혀 안한다면,

1) 60세까지 국민연금 완납하고 65세부터 받게 되는 국민연금이 현재가치 기준으로 세후 110만원이다. 기초연금 대상도 아니니 이걸로 끝. 제길..

2-1) 65세에 주택연금에 가입 가능한 최대치 주택에 맞춰 이사하고 그 집을 맡기고 가입해서 연금을 수령하면 현시점 기준 월 218만원을 수령할 수 있다. 양도세 대상이 아니니 이사후 차액만큼 현금으로 OO원 남게 된다.

2-2) 현금으로 남은 차액을 수익율 4.5%로 투자하면 대략 매월 120만원 수입이 예상된다.

3) 현재 보유하고 있는 남은 자산을 현금화하면 OO원이니 이를 비상금으로 가지고 있거나 2-2)번처럼 투자해서 매월 수입으로 전환할 수 있다. (현재 보유중인 비상장주식과 스타트업 지분 가치는 Zero, 즉 없다고 생각하고 자산에 포함하지 않았다) 전환시 매월 80만원 정도를 추가 수입으로 더할 수 있겠다.

본 시나리오는 주택연금 가업 조건에 맞춰 더 작은 집으로 가거나 현재 동네보다 집값이 더 싼 동네로 가서 현재 평수를 유지하거나 더 큰 곳으로 가야만 한다는 전제가 깔린다.

지금 가진 집이랑 자산 뜯어먹으면서 살면 1)+2)로 450만원, 여기에 3)까지 더하면 530만원이 가능하겠다. 65세 이후 미래 수령시점에 화폐개혁이나 국가부도만 나지 않으면 화폐가치가 어떻게 변해도 입에 풀칠은 할 수 있겠다.

이렇게 정리하고 나니 불안했던 마음도 조금 편해지고 앞으로 더 열심히 살아야겠다는 다짐도 하게 된다. 이를 위한 전제 조건 중 하나가 일단 60세까지 국민연금 내야 하고 65세까진 일을 해야 하니 말이다.

최고는 이렇게 머리 굴리지 않고 그냥 막 살아도 먹고 살기 위해 돈 걱정 안할만큼 조금이라도 젊었을 때 돈을 많이 버는 것이다. 무일푼에서 시작해서 이렇게 준비하는데 딱 10년 걸렸으니 앞으로 10년만 더 이렇게 준비하고 살면 그렇게 될 수 있지 않을까 희망을 가져본다. 저 시나리오로도 어차피 10년 훌쩍 넘어 일해야만 하는데 이왕 하는거 그렇게 해보자! 가진거 이 비루한 몸뚱이 하나 밖에 없으니 건강을 최우선으로 관리하고 돈도 더 아껴쓰고.

그런 의미에서 이제 다시 현실에 집중하자! 당장 내일 심사 일과 금요일 고객사 성과보고회, 다음주 월요일 강연 준비에 집중하자! 공상하는 거 멈추고 일해라! 😊

얼마전 경기 침체 대비 일환 노후 대책 점검을 했다. 국민연금 수령 나이가 65세니 65세 이후 생활을 수입 측면에서 현재 상황을 기준으로 예상해보았다. 일단 국민연금을 제대로 받으려면 (국민연금을 믿어서가 아니라 학교 졸업하고 사회생활, 즉 직장생활을 시작하면서 내 의지와 상관없이 가입이 되어버렸고 이미 20여년이 되었고 여전히 내야만 하는 상황이라 싫던 좋던 포기할 수 없으니 눈물을 머금고) 60세까지 더 내야 하기 때문에 수단과 방법을 가리지 않고 최소한 65세까지는 일해야만 한다는 전제다. 국민연금은 60세까지 내야만 하고 받는건 65세니 5년의 공백을 더 몸빵해야만 한다. 아무튼... 65세 이후 일을 전혀 안한다면, 1) 60세까지 국민연금 완납하고 65세부터 받게 되는 국민연금이 현재가치 기준으로 세후 110만원이다. 기초연금 대상도 아니니 이걸로 끝. 제길.. 2-1) 65세에 주택연금에 가입 가능한 최대치 주택에 맞춰 이사하고 그 집을 맡기고 가입해서 연금을 수령하면 현시점 기준 월 218만원을 수령할 수 있다. 양도세 대상이 아니니 이사후 차액만큼 현금으로 OO원 남게 된다. 2-2) 현금으로 남은 차액을 수익율 4.5%로 투자하면 대략 매월 120만원 수입이 예상된다. 3) 현재 보유하고 있는 남은 자산을 현금화하면 OO원이니 이를 비상금으로 가지고 있거나 2-2)번처럼 투자해서 매월 수입으로 전환할 수 있다. (현재 보유중인 비상장주식과 스타트업 지분 가치는 Zero, 즉 없다고 생각하고 자산에 포함하지 않았다) 전환시 매월 80만원 정도를 추가 수입으로 더할 수 있겠다. 본 시나리오는 주택연금 가업 조건에 맞춰 더 작은 집으로 가거나 현재 동네보다 집값이 더 싼 동네로 가서 현재 평수를 유지하거나 더 큰 곳으로 가야만 한다는 전제가 깔린다. 지금 가진 집이랑 자산 뜯어먹으면서 살면 1)+2)로 450만원, 여기에 3)까지 더하면 530만원이 가능하겠다. 65세 이후 미래 수령시점에 화폐개혁이나 국가부도만 나지 않으면 화폐가치가 어떻게 변해도 입에 풀칠은 할 수 있겠다. 이렇게 정리하고 나니 불안했던 마음도 조금 편해지고 앞으로 더 열심히 살아야겠다는 다짐도 하게 된다. 이를 위한 전제 조건 중 하나가 일단 60세까지 국민연금 내야 하고 65세까진 일을 해야 하니 말이다. 최고는 이렇게 머리 굴리지 않고 그냥 막 살아도 먹고 살기 위해 돈 걱정 안할만큼 조금이라도 젊었을 때 돈을 많이 버는 것이다. 무일푼에서 시작해서 이렇게 준비하는데 딱 10년 걸렸으니 앞으로 10년만 더 이렇게 준비하고 살면 그렇게 될 수 있지 않을까 희망을 가져본다. 저 시나리오로도 어차피 10년 훌쩍 넘어 일해야만 하는데 이왕 하는거 그렇게 해보자! 가진거 이 비루한 몸뚱이 하나 밖에 없으니 건강을 최우선으로 관리하고 돈도 더 아껴쓰고. 그런 의미에서 이제 다시 현실에 집중하자! 당장 내일 심사 일과 금요일 고객사 성과보고회, 다음주 월요일 강연 준비에 집중하자! 공상하는 거 멈추고 일해라! 😊

노후 준비 상황 점검

대학교에 입학하기 전

2024년 12월, 개강을 한참 앞두고 에브리타임을 구경하다 우연히 동아리 홍보글 하나를 발견했다. 교내 IT 플랫폼 탐구·개발 동아리 'AIIA' 의 홍보글이었다. 아직 입학도 하지 않은 상태였지만 새내기부터 어떤 분야든 열심히 해보고 싶어 

프로젝트 회고록: 앱 개발을 처음 접하고, 출시까지 걸어온 경험 

플러터를 잘 다루지 못하지만 플러터로 앱을 개발하고 출시하기까지의 여정이 담겨있네요.

https://velog.io/@yongjun0702/프로젝트-회고록-앱-개발을-처음-접하고-출시까지-걸어온-경험

플러터를 잘 다루지 못하지만 플러터로 앱을 개발하고 출시하기까지의 여정이 담겨있네요. https://velog.io/@yongjun0702/프로젝트-회고록-앱-개발을-처음-접하고-출시까지-걸어온-경험

velog.io

VinTeum 앱 출시기

많은 조직에서, 실험을 ‘revenue 지표 향상시키는 아이디어 찾아내기’ 내지는 ‘기획안 통과시키기 위한 근거찾기’ 정도로 여기곤 합니다. 그리고 그런 숫자들을 어떻게든 찾아내는 일을 데이터 분석이라고 부르려 하죠. 적어도 제가 리딩하는 팀에서 하고자 하는 실험과 분석은, 그런 것이 아닙니다.

1. 실험의 실패율이 높은 것은 지극히 당연하고 정상적입니다. 실험 실패(실패라기보단 가설이 입증되지 않았다고 말하는 것이 정확하겠습니다만)의 원인을 분석하는 과정에서 고객의 행태와 니즈를 이해하게 되고, 이것이 분석이며 이런 과정이 반복되어야 비로소 실험 성공율이 조금씩 향상됩니다.

2. 실험 결과(성공과 실패)로부터 얻어야 하는 것은 실험의 가설이 입증되었는가를 밝히는 것이며, 이를 인과적으로(원인과 결과를 분리하여) 설명하는 것입니다. 이것이 저희팀이 해야 하는 분석이라 생각하고, 조직의 실험 문화를 이렇게 바꿔가야 한다고 봅니다.

많은 조직에서, 실험을 ‘revenue 지표 향상시키는 아이디어 찾아내기’ 내지는 ‘기획안 통과시키기 위한 근거찾기’ 정도로 여기곤 합니다. 그리고 그런 숫자들을 어떻게든 찾아내는 일을 데이터 분석이라고 부르려 하죠. 적어도 제가 리딩하는 팀에서 하고자 하는 실험과 분석은, 그런 것이 아닙니다. 1. 실험의 실패율이 높은 것은 지극히 당연하고 정상적입니다. 실험 실패(실패라기보단 가설이 입증되지 않았다고 말하는 것이 정확하겠습니다만)의 원인을 분석하는 과정에서 고객의 행태와 니즈를 이해하게 되고, 이것이 분석이며 이런 과정이 반복되어야 비로소 실험 성공율이 조금씩 향상됩니다. 2. 실험 결과(성공과 실패)로부터 얻어야 하는 것은 실험의 가설이 입증되었는가를 밝히는 것이며, 이를 인과적으로(원인과 결과를 분리하여) 설명하는 것입니다. 이것이 저희팀이 해야 하는 분석이라 생각하고, 조직의 실험 문화를 이렇게 바꿔가야 한다고 봅니다.

많은 조직에서, 실험을 ‘revenue 지표 향상시키는 아이디어 

계속하던 대로만 하지 않습니다. 도구에 매몰되지 않고 목적에 집중합니다. 모르는 것은 가능한 한 빨리 "모릅니다", "알려주세요"라고 말합니다. 의견을 자주 바꿔도 괜찮습니다. 틀렸다고 생각하면 인정하고 의견도 편안하게 바꿉니다. 의식적으로 나와 의견이 다른 사람에게 의견을 구합니다. 다른 사람이 의견을 구할 때 진지하게 고민하고 의견을 전합니다. 실수하고 나면 기록합니다. 기록하지 않으면 종종 기억되지 않습니다. 감정이 태도가 되지 않도록 의식합니다. 하루에 1번은 30분 이상 신선한 공기를 마십니다. 소비로 자존감을 채우지 않습니다. 소비로 자존감을 채우지 않습니다.

계속하던 대로만 하지 않습니다. 도구에 매몰되지 않고 목적에 집중합니다. 모르는 것은 가능한 한 빨리 "모릅니다", "알려주세요"라고 말합니다. 의견을 자주 바꿔도 괜찮습니다. 틀렸다고 생각하면 인정하고 의견도 편안하게 바꿉니다. 의식적으로 나와 의견이 다른 사람에게 의견을 구합니다. 다른 사람이 의견을 구할 때 진지하게 고민하고 의견을 전합니다. 실수하고 나면 기록합니다. 기록하지 않으면 종종 기억되지 않습니다. 감정이 태도가 되지 않도록 의식합니다. 하루에 1번은 30분 이상 신선한 공기를 마십니다. 소비로 자존감을 채우지 않습니다. 소비로 자존감을 채우지 않습니다.

《일을 하면서 의식해야 하는 10가지》

We're on a journey to advance and democratize artificial intelligence through open source and open science.

Models - Hugging Face

Meta에서 크기 대비 엄청난 성능의 Llama 3를 발표한지 얼마 안됐는데,
MS에서도 Phi 3를 발표했네요.
 * phi-3-mini (3.8B)
 * phi-3-small (7B)
 * phi-3-medium (14B)

크기에 따라 3가지로 나뉘는데, 가장 작은 모델을 발표했고, GPT-3.5에 준하는 성능이라고 합니다.
(phi-3-mini achieves 69% on MMLU and 8.38 on MT-bench)

학습데이터도 phi-2에 사용하던 것의 확장 버전이라는데, 어떻게 가능했던걸까요?

한편, 자체적인 safety post-training을 통해 유해한 응답율도 획기적으로 줄일 수 있었다고 합니다.

 * https://huggingface.co/models?other=phi3&sort=trending&search=microsoft
 * https://arxiv.org/abs/2404.14219

Meta에서 크기 대비 엄청난 성능의 Llama 3를 발표한지 얼마 안됐는데,MS에서도 Phi 3를 발표했네요.<ul><li>phi-3-mini (3.8B)</li><li>phi-3-small (7B)</li><li>phi-3-medium (14B)</li></ul> 크기에 따라 3가지로 나뉘는데, 가장 작은 모델을 발표했고, GPT-3.5에 준하는 성능이라고 합니다.(phi-3-mini achieves 69% on MMLU and 8.38 on MT-bench) 학습데이터도 phi-2에 사용하던 것의 확장 버전이라는데, 어떻게 가능했던걸까요? 한편, 자체적인 safety post-training을 통해 유해한 응답율도 획기적으로 줄일 수 있었다고 합니다. <ul><li>https://huggingface.co/models?other=phi3&amp;sort=trending&amp;search=microsoft</li><li>https://arxiv.org/abs/2404.14219</li></ul>

huggingface.co

Software Engineer

이아름 Lia

온라인 광고솔루션을 다루는 회사에서 서버 개발자로 근무하고있습니다.
SSAFY 1기를 수료하였습니다.
#개발자 #끊임없이배우기 #독서 #백엔드 #파이썬디벨로퍼

커피와 당으로 돌아가는 개발자

백상일

https://bit.ly/gentledot-portfolio

💡일하면서 중요하게 생각하는 것!
1. 유지보수가 용이한 코드를 추구한다.
2. 도메인 문제의 효과적인 해결 방안을 찾아 성장을 추구한다.
3. 팀의 일원으로 함께 나아갈 수 있는 문화조성에 기여한다.

개발자

이현준

이원형

👨‍🎓무선 통신 분야 석사를 마치고 💾반도체 펌웨어를 개발하다가
지금은 💻메신저를 개발하고 있습니다.

❗ 본 계정에서 작성되는 모든 의견은 특정 회사와는 무관합니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필