험한 산속에 5명이 고립되어 있습니다. 생존하려면 어둡고 위험한 다리를 건너 구조대에게 가야 합니다. 그러나 다음과 같은 제약 조건이 있습니다.

1. 다리는 최대 두 사람까지만 동시에 건널 수 있습니다.
2. 반드시 등불이 있어야만 다리를 건널 수 있습니다. 등불은 단 하나뿐입니다.
3. 각 조난자가 다리를 건너는 속도는 다릅니다:
• A: 3분
• B: 5분
• C: 7분
• D, E: 각각 10분

가장 빨리 모두가 다리를 건너 구조대에게 도달할 수 있는 시간은 얼마일까요? 맞습니다. 이 질문은 최적화에 관한 질문입니다. 엔지니어 면접 질문으로 종종 묻던 것 중에 하나입니다.

모든 사람이 가장 빠르고 안전하게 다리를 건너기 위해서는 빠른 속도를 가진 A와 B가 주도적으로 움직여야 하며 그 과정에서 가장 빠른 사람(A)이 반복적으로 왕복하며 등불을 옮겨야 하는 부담을 지게 됩니다. 결국, 가장 빠른 사람의 헌신과 희생이 모두의 생존 가능성을 높이게 됩니다.

이 질문 속 진짜 숨은 의도는 단순히 최적화의 답을 구하는 것이 아니라, 조직 내 업무 최적화에 대해 많은 생각을 이끌어내는 데 있습니다.

조직에서도 이와 비슷하게 전체 업무의 효율성은 가장 느린 구성원에게 맞춰지며, 가장 뛰어난 인재가 전체의 효율을 극대화하기 위해 더 많은 역할과 책임을 짊어지게 됩니다. 뛰어난 인재가 지속적으로 성과를 내기 위해서는 그들의 기여를 인정하고 적절히 보상해야 하는 이유이기도 합니다. 경영의 신으로 불리우던 GE의 잭 웰치(Jack Welch)가 하위 성과 10% 그룹은 과감한 정리 해고, 상위 리더 그룹에는 파격적인 보상을 했는지 이해가 되는 지점이기도 합니다(물론 이후 잭 웰치는 주주가치 최우선에 대한 자신의 과거 생각을 일부 철회하기도 했다) 이와 같이 리더 그룹에 속하기 위해서는 단지 능력을 갖추는 것 뿐 아니라 구성원의 성장을 위해 기꺼이 자신을 희생하고 헌신할 수 있는 사람이어야 합니다.
⸻

참고로 이 문제의 답은 총 38분입니다. 문제를 풀어보며 조직 관리에 대해서도 한번 고민해봐도 좋을 것 같네요.

험한 산속에 5명이 고립되어 있습니다. 생존하려면 어둡고 위험한 다리를 건너 구조대에게 가야 합니다. 그러나 다음과 같은 제약 조건이 있습니다. 1. 다리는 최대 두 사람까지만 동시에 건널 수 있습니다.2. 반드시 등불이 있어야만 다리를 건널 수 있습니다. 등불은 단 하나뿐입니다.3. 각 조난자가 다리를 건너는 속도는 다릅니다:• A: 3분• B: 5분• C: 7분• D, E: 각각 10분 가장 빨리 모두가 다리를 건너 구조대에게 도달할 수 있는 시간은 얼마일까요? 맞습니다. 이 질문은 최적화에 관한 질문입니다. 엔지니어 면접 질문으로 종종 묻던 것 중에 하나입니다. 모든 사람이 가장 빠르고 안전하게 다리를 건너기 위해서는 빠른 속도를 가진 A와 B가 주도적으로 움직여야 하며 그 과정에서 가장 빠른 사람(A)이 반복적으로 왕복하며 등불을 옮겨야 하는 부담을 지게 됩니다. 결국, 가장 빠른 사람의 헌신과 희생이 모두의 생존 가능성을 높이게 됩니다. 이 질문 속 진짜 숨은 의도는 단순히 최적화의 답을 구하는 것이 아니라, 조직 내 업무 최적화에 대해 많은 생각을 이끌어내는 데 있습니다. 조직에서도 이와 비슷하게 전체 업무의 효율성은 가장 느린 구성원에게 맞춰지며, 가장 뛰어난 인재가 전체의 효율을 극대화하기 위해 더 많은 역할과 책임을 짊어지게 됩니다. 뛰어난 인재가 지속적으로 성과를 내기 위해서는 그들의 기여를 인정하고 적절히 보상해야 하는 이유이기도 합니다. 경영의 신으로 불리우던 GE의 잭 웰치(Jack Welch)가 하위 성과 10% 그룹은 과감한 정리 해고, 상위 리더 그룹에는 파격적인 보상을 했는지 이해가 되는 지점이기도 합니다(물론 이후 잭 웰치는 주주가치 최우선에 대한 자신의 과거 생각을 일부 철회하기도 했다) 이와 같이 리더 그룹에 속하기 위해서는 단지 능력을 갖추는 것 뿐 아니라 구성원의 성장을 위해 기꺼이 자신을 희생하고 헌신할 수 있는 사람이어야 합니다.⸻ 참고로 이 문제의 답은 총 38분입니다. 문제를 풀어보며 조직 관리에 대해서도 한번 고민해봐도 좋을 것 같네요.

최적화 문제 속에 숨은 의도

클라우드 환경에서의 Redis 라이센스 정책에 의해서 최근 io.valkey 에 대한 마이그레이션을 준비하고 있습니다. Valkey 는 Redis 7.4 미만 버전의 fork 서비스로 현재는 valkey 8.0 까지 release 되었지만, 저희는 아직 Valkey 7.2.x 로 테스트를 하고 있어요.

fork 버전이기 때문에 사용성에 있어서는 Redis 와 큰 차이가 없고, 가장 많이 사용되는 lettuce 에서의 호환 (하지만, 일부 기능은 사용할 수 없음) 으로 인하여 큰 무리 없이 하나씩 마이그레이션을 하고 있습니다.

하지만, Valkey 의 버전이 올라가면 올라갈수록 lettuce 를 사용이 안될 수도 있다는 점을 가정하여, io.valkey.glide 의 라이브러리를 테스트하고, 저희에 맞게 wrapping 을 하고 있는데요. valkey 서버와 다르게 Glide 라이브러리에 대한 지양점의 차이로 조금은 혼란스러운 상태가 있어서, 기록을 남겨둘까 해요.

 * MasterReplica 구조에서 Replica 노드 직접 연결
   * lettuce 와 다르게 Valkey 는 Replica Role 을 가지는 Node 에 직접 연결을 할 수 없어요.
   * Replica Role 은 항상 Master 와 함께 붙어 다니면서 읽기 전략을 수행해야 하는 관점때문에 그런거 같아요.
 * MasterReplica 에서의 pipeline 은 Primary 노드에 집중되요.
   * Pipeline 에 쓰기 명령을 할 수 있기에, 이와 같은 현상이 생겼을 것이라 생각해요.
   * 하지만, 이에 대한 설정을 사용자에게 맡긴다면 좀 더 좋은 환경을 제공할 것이라 생각하여, Github 에 이슈를 발행하였어요.
 * Cluster Topology 업데이트는 자동 수행이 되어요.
   * Cluster 노드 변경을 위해서 lettuce 는 Topology 업데이트 전략을 추가 해줘야 했다면 Glide 라이브러리는 이를 알아서 해결해요.
 * Transaction, Pipeline 명령을 위한 Connection 관리가 없어도 되요.
   * lettuce 는 Connection 에 직접 명령을 보내는 구조로, pipeline 을 위하여 autoFlush 를 끄고, 명령어를 모아 놓은 다음 flushCommands 를 해야 했거나.
   * transaction 의 multi 가 수행되면 connection 에 담기는 명령이 모두 multi 아래에서 수행되어야 하기에 Connection 을 별도로 만들거나 Pool 정책이 필요 했는데요.
   * 명령어 전달 방식이 channel 에 모이고 이를 Connection 에 flush 하는 방식으로 지원이 되면서 Pool 에 대한 신경을 쓰지 않아도 되요.
 * Cluster 환경에서 mget, hmget 과 같이 같은 Slot 에서만 동작해야 하는 명령들이. Glide 모듈 내에서는 좀더 쉽게 접근이 가능하게 되요.
   * 각 Key 의 HashSlot 을 모듈내에서 구하고, Key 가 저장되어 있는 node 를 찾아서 그룹핑하여 한번에 전달하는 구조에요.
   * 하지만, 이 경우 최악의 상황에서는 모든 Node 에 한번씩 연결을 해야 하기 때문에 좋지 못한 결과를 얻을 수는 있고, Valey Cluster 서버내에서는 해당 명령을 지원하지 않기 때문에 모듈에서 되는 것 가지고 Valkey 이는 이것이 수행되는 구나 등의 오해가 있을 수 있어요.

Spring Data Redis 를 사용하지 않고 Lettuce 을 직접사용하면서 모듈 마이그레이션 과정에서 작은 (?) 차이점들을 알게 되었는데요.

Server 가 아닌 모듈이 지향하는 Remote Cache Server 와의 차이를 이해 한다면 조금은 위와 같은 사항이 이해되긴 합니다.
 * lettuce : Server 와 1:1 로 맞추어서 기능을 만들고 서버에서 제공하지 않는 기능을 억지로 만들지 않아요.
 * io.valkey.glide: 사용자의 편의성을 우선시 하고, performane 에 우선을 두고 있어요. 즉, valkey 서버에서는 지원하지 않는 기능이지만 편의성으로 확장을 하고 있는거 같더라구요.

모듈을 Wrapping 을 하게 되면, 우리의 케이스에 맞춰서 다양한 생각을 하게 되는 경험을 하게 되는데요. 이때 단순이 소스 모듈이 지원을 하기 때문에 서버도 이런 기능을 제공하겠지? 라는 생각 보다는 서버의 상황과 맞추어서 생각을 좀 더 깊게 해야 하는 케이스가 항상 발생하는것 같아요.

단순히 되네? 라기 보다는 이 모듈은 이게 왜 되는것이지? 하는 생각이 좀더 필요하지 않을까 싶어요.

클라우드 환경에서의 Redis 라이센스 정책에 의해서 최근 io.valkey 에 대한 마이그레이션을 준비하고 있습니다. Valkey 는 Redis 7.4 미만 버전의 fork 서비스로 현재는 valkey 8.0 까지 release 되었지만, 저희는 아직 Valkey 7.2.x 로 테스트를 하고 있어요. fork 버전이기 때문에 사용성에 있어서는 Redis 와 큰 차이가 없고, 가장 많이 사용되는 lettuce 에서의 호환 (하지만, 일부 기능은 사용할 수 없음) 으로 인하여 큰 무리 없이 하나씩 마이그레이션을 하고 있습니다. 하지만, Valkey 의 버전이 올라가면 올라갈수록 lettuce 를 사용이 안될 수도 있다는 점을 가정하여, io.valkey.glide 의 라이브러리를 테스트하고, 저희에 맞게 wrapping 을 하고 있는데요. valkey 서버와 다르게 Glide 라이브러리에 대한 지양점의 차이로 조금은 혼란스러운 상태가 있어서, 기록을 남겨둘까 해요. <ul ><li>MasterReplica 구조에서 Replica 노드 직접 연결<ul ><li>lettuce 와 다르게 Valkey 는 Replica Role 을 가지는 Node 에 직접 연결을 할 수 없어요.</li><li>Replica Role 은 항상 Master 와 함께 붙어 다니면서 읽기 전략을 수행해야 하는 관점때문에 그런거 같아요.</li></ul></li><li>MasterReplica 에서의 pipeline 은 Primary 노드에 집중되요.<ul ><li>Pipeline 에 쓰기 명령을 할 수 있기에, 이와 같은 현상이 생겼을 것이라 생각해요.</li><li>하지만, 이에 대한 설정을 사용자에게 맡긴다면 좀 더 좋은 환경을 제공할 것이라 생각하여, Github 에 이슈를 발행하였어요.</li></ul></li><li>Cluster Topology 업데이트는 자동 수행이 되어요.<ul ><li>Cluster 노드 변경을 위해서 lettuce 는 Topology 업데이트 전략을 추가 해줘야 했다면 Glide 라이브러리는 이를 알아서 해결해요.</li></ul></li><li>Transaction, Pipeline 명령을 위한 Connection 관리가 없어도 되요.<ul ><li>lettuce 는 Connection 에 직접 명령을 보내는 구조로, pipeline 을 위하여 autoFlush 를 끄고, 명령어를 모아 놓은 다음 flushCommands 를 해야 했거나.</li><li>transaction 의 multi 가 수행되면 connection 에 담기는 명령이 모두 multi 아래에서 수행되어야 하기에 Connection 을 별도로 만들거나 Pool 정책이 필요 했는데요.</li><li>명령어 전달 방식이 channel 에 모이고 이를 Connection 에 flush 하는 방식으로 지원이 되면서 Pool 에 대한 신경을 쓰지 않아도 되요.</li></ul></li><li>Cluster 환경에서 mget, hmget 과 같이 같은 Slot 에서만 동작해야 하는 명령들이. Glide 모듈 내에서는 좀더 쉽게 접근이 가능하게 되요.<ul ><li>각 Key 의 HashSlot 을 모듈내에서 구하고, Key 가 저장되어 있는 node 를 찾아서 그룹핑하여 한번에 전달하는 구조에요.</li><li>하지만, 이 경우 최악의 상황에서는 모든 Node 에 한번씩 연결을 해야 하기 때문에 좋지 못한 결과를 얻을 수는 있고, Valey Cluster 서버내에서는 해당 명령을 지원하지 않기 때문에 모듈에서 되는 것 가지고 Valkey 이는 이것이 수행되는 구나 등의 오해가 있을 수 있어요.</li></ul></li></ul> Spring Data Redis 를 사용하지 않고 Lettuce 을 직접사용하면서 모듈 마이그레이션 과정에서 작은 (?) 차이점들을 알게 되었는데요. Server 가 아닌 모듈이 지향하는 Remote Cache Server 와의 차이를 이해 한다면 조금은 위와 같은 사항이 이해되긴 합니다.<ul ><li>lettuce : Server 와 1:1 로 맞추어서 기능을 만들고 서버에서 제공하지 않는 기능을 억지로 만들지 않아요.</li><li>io.valkey.glide: 사용자의 편의성을 우선시 하고, performane 에 우선을 두고 있어요. 즉, valkey 서버에서는 지원하지 않는 기능이지만 편의성으로 확장을 하고 있는거 같더라구요.</li></ul> 모듈을 Wrapping 을 하게 되면, 우리의 케이스에 맞춰서 다양한 생각을 하게 되는 경험을 하게 되는데요. 이때 단순이 소스 모듈이 지원을 하기 때문에 서버도 이런 기능을 제공하겠지? 라는 생각 보다는 서버의 상황과 맞추어서 생각을 좀 더 깊게 해야 하는 케이스가 항상 발생하는것 같아요. 단순히 되네? 라기 보다는 이 모듈은 이게 왜 되는것이지? 하는 생각이 좀더 필요하지 않을까 싶어요.

io.valkey.glide 의 장단...

AI들 코딩 스타일이, GPT는 구글같고, Claude는 메타같음. Gemini는 부트캠프..🫢

그래서 응용레벨 코딩에는 Claude가 낫고, 로우레벨 코딩에는 GPT가 나은 편.

* 당연하지만 개인적인 느낌일 뿐 입니다.

AI들 코딩 스타일이, GPT는 구글같고, Claude는 메타같음. Gemini는 부트캠프..🫢 그래서 응용레벨 코딩에는 Claude가 낫고, 로우레벨 코딩에는 GPT가 나은 편. * 당연하지만 개인적인 느낌일 뿐 입니다.

AI 시대를 맞이하면서 우리는 다양한
직무(Career)의 구조적인 변화를 맞이하고 있습니다.

특히 IT 업계에서 그 변화가 두드러지고 있는데요.

그 중 ‘데이터 분석’ 분야가 바뀌고 있는 구조적인 방향에
대해 크게 3가지 방향으로 나누어서 이야기해보고자 합니다.

1. AI를 단순한 ‘분석 도구’가 아닌 ‘분석 파트너’로 여기기

AI 시대 이전에는 데이터 분석가가 직접
데이터를 요약 및 전처리하고 시각화하는 부분에
가장 많은 시간을 사용했습니다.

하지만 지금는 AI를 활용하여,
데이터를 요약하고 시각화하고,
데이터 모델까지 생성하는 데 10배나 더 빠르게 수행할 수 있죠.

그렇다면 모든 데이터 분석의 영역이 AI에게 대체될까요?

저는 아니라고 생각합니다.

여전히 AI가 놓치기 쉬운 ‘분석의 맥락’과 ‘문제 정의’는
여전히 사람이 직접 해야합니다.

그리고 “처음부터 끝까지 직접 분석하는 것”이 아니라,
“AI와 함께 나누어 분담”하는 방식으로
분석 방식을 바꿔야 한다고 생각합니다.

2. 실무 역량보다 중요한 ‘질문력’과 ‘기획력’ 키우기

AI 시대 이전에는 분석 도구에 대한
실무 역량과 통계/실험 기법이 핵심 역량이었습니다.

주어진 데이터를 어떻게 효율적으로 다룰수 있는지에 대한 이해도와
데이터의 정확성을 높이는 통계 기법이 분석가의 주요 역량이였죠.

하지만 새로운 AI 시대에는 주어진 데이터를 통해
“무엇을 해결할 것인가” 와 "무엇을 개선할 것인가”를
파악하는 것이 더 중요해졌습니다.

즉 데이터 자체에 집중하기 보다,
‘문제’ 중심으로 데이터를 바라보는 ‘질문력’과 ‘기획력’이
핵심 스킬로 부상하게 된 것이죠.

3. AI의 능력이 증가할수록 중요해지는 ‘인사이트’의 차별성

ChatGPT, Power BI, Tableau, Google Sheets 등으로
복잡한 코드나 프로그래밍 지식 없이도
데이터 기반 시각화나 요약이 상대적으로 쉬워졌습니다.

즉, 도구를 얼마나 익숙하게 사용하는지는
상대적으로 크게 경쟁력을 갖추지 못하게 된 것이죠.

그 대신 같은 데이터를 분석해도
“어떤 인사이트를 끌어내느냐”가 진짜 경쟁력의 본질이 되었습니다.

이제 데이터 분석은 ‘데이터 전문가만의 영역’이 아닌,
모든 직무의 공통 언어가 되어가고 있습니다.

마케터, 기획자, 운영자, PM, HR 등 모든 직무가
데이터 기반 의사결정을 기본 역량으로 요구합니다.

AI에게 데이터 분석의 프로세스를 분담하고,
사람이 데이터 분석을 ‘’기획"하고 ‘해석’하는 능력이 더 중요해진 시대,

앞으로 데이터 분석 분야는 어떤 방향으로 더욱 발전하게 될까요?

AI 시대를 맞이하면서 우리는 다양한직무(Career)의 구조적인 변화를 맞이하고 있습니다. 특히 IT 업계에서 그 변화가 두드러지고 있는데요. 그 중 ‘데이터 분석’ 분야가 바뀌고 있는 구조적인 방향에대해 크게 3가지 방향으로 나누어서 이야기해보고자 합니다. 1. AI를 단순한 ‘분석 도구’가 아닌 ‘분석 파트너’로 여기기 AI 시대 이전에는 데이터 분석가가 직접데이터를 요약 및 전처리하고 시각화하는 부분에가장 많은 시간을 사용했습니다. 하지만 지금는 AI를 활용하여,데이터를 요약하고 시각화하고,데이터 모델까지 생성하는 데 10배나 더 빠르게 수행할 수 있죠. 그렇다면 모든 데이터 분석의 영역이 AI에게 대체될까요? 저는 아니라고 생각합니다. 여전히 AI가 놓치기 쉬운 ‘분석의 맥락’과 ‘문제 정의’는여전히 사람이 직접 해야합니다. 그리고 “처음부터 끝까지 직접 분석하는 것”이 아니라,“AI와 함께 나누어 분담”하는 방식으로분석 방식을 바꿔야 한다고 생각합니다. 2. 실무 역량보다 중요한 ‘질문력’과 ‘기획력’ 키우기 AI 시대 이전에는 분석 도구에 대한실무 역량과 통계/실험 기법이 핵심 역량이었습니다. 주어진 데이터를 어떻게 효율적으로 다룰수 있는지에 대한 이해도와데이터의 정확성을 높이는 통계 기법이 분석가의 주요 역량이였죠. 하지만 새로운 AI 시대에는 주어진 데이터를 통해“무엇을 해결할 것인가” 와 "무엇을 개선할 것인가”를파악하는 것이 더 중요해졌습니다. 즉 데이터 자체에 집중하기 보다,‘문제’ 중심으로 데이터를 바라보는 ‘질문력’과 ‘기획력’이핵심 스킬로 부상하게 된 것이죠. 3. AI의 능력이 증가할수록 중요해지는 ‘인사이트’의 차별성 ChatGPT, Power BI, Tableau, Google Sheets 등으로복잡한 코드나 프로그래밍 지식 없이도데이터 기반 시각화나 요약이 상대적으로 쉬워졌습니다. 즉, 도구를 얼마나 익숙하게 사용하는지는상대적으로 크게 경쟁력을 갖추지 못하게 된 것이죠. 그 대신&nbsp;같은 데이터를 분석해도“어떤 인사이트를 끌어내느냐”가 진짜 경쟁력의 본질이 되었습니다. 이제 데이터 분석은 ‘데이터 전문가만의 영역’이 아닌,모든 직무의 공통 언어가 되어가고 있습니다. 마케터, 기획자, 운영자, PM, HR 등 모든 직무가데이터 기반 의사결정을 기본 역량으로 요구합니다. AI에게 데이터 분석의 프로세스를 분담하고,사람이 데이터 분석을 ‘’기획"하고 ‘해석’하는 능력이 더 중요해진 시대, 앞으로 데이터 분석 분야는 어떤 방향으로 더욱 발전하게 될까요?

AI 시대, 데이터 분석에 대해 새롭게 정의해야 하는 이유

올봄, AI 시장을 강타한 키워드가 있습니다. 오늘의 주인공 “MCP”입니다. 무언가 단어의 생김새는 GPT하고 비스무리한데요. 프로토콜, 서버, 클라이언트처럼 또 눈에 익은 단어들과 붙어 다니지만, 그 개념은 손에 잘 안 잡힙니다. 그런데 또 여기저기 슬금슬금 “MCP로 생산성을 미친 듯 끌어올렸다”는 이야기가 돌고 있습니다. 혼자 밀려난 느낌도 듭니다. 그래서 알아봤습니다. 의미를 파헤치고, 사람들의 반응을 살피고, 직접 체험해 볼 겁니다. 특히 어디까지 이 친구와 가까워져야 할지, 선을 그어보려고 합니다. 그 끝에서 이 질문에 답해보겠습니다. MCP 모르면 대체 얼마나 손해 보는 걸까요?

MCP 모르면 대체 얼마나 손해 보는 걸까? | 요즘IT

올해 가장 핫한 기술을 꼽자면 단연 MCP 가 아닐까 싶습니다.

그만큼 많은 사람들의 관심이 집중되고 있고,
"이렇게 관심이 많은데 나도 한번 알아봐야 하지 않을까?" 하는 생각을 하신 분들도 계실것 같습니다.

요즘 올라오는 글들을 보면 대부분 MCP 의 개념과 원리를 설명하는 내용이 주를 이루는데요,
특이하게도 MCP 에 대한 개념과 원리뿐만 아니라 이걸 모르면 어떻게 될지, AI 기술 발전을 어떻게 따라가야할지에 대한 의견을 담은 아티클이 있어 공유드립니다.

머신러닝부터 시작된 인공지능 기술은 LLM 의 등장, 그리고 MCP 로의 진화에 이르기까지
점점 더 쉽고 빠르게 응용할 수 있는 방향으로 발전하고 있다고 느낍니다.
이런 기술들을 잘 익히고 유용하게 활용할 수 있다면 더없이 좋겠지만,
개인적인 생각으로 이걸 꼭 사용하지 않는다고 해서 도태되거나 문제가 생긴다고는 생각하지 않습니다.

다만 글의 말미에서도 언급되듯, 내가 비록 당장 MCP 등과 같은 AI 기술들을 사용하지 않더라도
AI 가 어떤 흐름으로 발전하고 있는지, MCP 가 왜 나오고 어떤 한계를 보완했는지 등만 미리 파악하면 추후 다른 기술이 새로 나오더라도 금방 이해하고 언제든 사용해 볼 수 있지 않을까 싶습니다.

그동안 MCP 에 대해 궁금했지만 이해가 안되었던 분들 혹은 AI 의 빠른 발전속도에 혼란스러우셨던 분들에게 도움이 될거라 생각하는데요
관심있으신 분들은 한번 읽어보시면 좋겠습니다.

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

올해 가장 핫한 기술을 꼽자면 단연 MCP 가 아닐까 싶습니다. 그만큼 많은 사람들의 관심이 집중되고 있고, "이렇게 관심이 많은데 나도 한번 알아봐야 하지 않을까?" 하는 생각을 하신 분들도 계실것 같습니다. 요즘 올라오는 글들을 보면 대부분 MCP 의 개념과 원리를 설명하는 내용이 주를 이루는데요,특이하게도 MCP 에 대한 개념과 원리뿐만 아니라 이걸 모르면 어떻게 될지, AI 기술 발전을 어떻게 따라가야할지에 대한 의견을 담은 아티클이 있어 공유드립니다. 머신러닝부터 시작된 인공지능 기술은 LLM 의 등장, 그리고 MCP 로의 진화에 이르기까지 점점 더 쉽고 빠르게 응용할 수 있는 방향으로 발전하고 있다고 느낍니다.이런 기술들을 잘 익히고 유용하게 활용할 수 있다면 더없이 좋겠지만, 개인적인 생각으로 이걸 꼭 사용하지 않는다고 해서 도태되거나 문제가 생긴다고는 생각하지 않습니다. 다만 글의 말미에서도 언급되듯, 내가 비록 당장 MCP 등과 같은 AI 기술들을 사용하지 않더라도 AI 가 어떤 흐름으로 발전하고 있는지, MCP 가 왜 나오고 어떤 한계를 보완했는지 등만 미리 파악하면 추후 다른 기술이 새로 나오더라도 금방 이해하고 언제든 사용해 볼 수 있지 않을까 싶습니다. 그동안 MCP 에 대해 궁금했지만 이해가 안되었던 분들 혹은 AI 의 빠른 발전속도에 혼란스러우셨던 분들에게 도움이 될거라 생각하는데요 관심있으신 분들은 한번 읽어보시면 좋겠습니다. 📚 원문<ul ><li>https://yozm.wishket.com/magazine/detail/3207/</li></ul>

요즘IT

MCP 모르면 대체 얼마나 손해 보는 걸까?🤔

원문: https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/

(번역)자바스크립트가 웹을 망가뜨렸습니다. (그리고 이를 진보라고 불렀습니다)

자극적인 글을 하나 읽었다.

'개발자들이 새로운 기술 도구로 ‘기술 놀이’를 하느라 복잡성과 비용을 키웠다.'

프론트엔드가 지금까지 발전하며 수 많은 고민과 개선이 있었겠지만, 그 결과 20년전 수십 kb로 구현할 수 있던 기능이 이제는 수 mb의 js 파일을 필요로 한다.

그렇다고 유지보수성이나 개발 생산성이 정말로 향상되었는가? Yes 이면서도 No 이다. 프레임워크와 툴체인은 초기 개발과 반복 작업을 빠르게 만들었지만, 그 대가로 가파르게 상승한 복잡도 속에서 사소한 수정조차 전방위적 사이드 이펙트를 일으키는 구조가 되었다. 생산성은 순간적으로 올라갔지만, 유지보수는 점점 더 전문성과 컨텍스트 의존도를 요구하게 된 것이다.

그리고 이제는 그 복잡도를 유지하면서 새로운 기능을 추가하기 위해 조직은 더 많은 인력과 인건비, 세분화된 포지션을 감당해야 한다. 하나의 기능을 구현하기 위해 프론트엔드, 백엔드, DevOps, QA, 기획이 머리를 맞대야 하고, 각 단계마다 파이프라인을 통과해야만 한다. (과거엔 '웹 마스터' 라는 1인 직책이 있었다는 것을 기억하는가?) 개발은 점점 더 느려지고, 사소한 변경도 일정과 리소스의 계산 대상이 된다. 결국 복잡성은 기술적 문제가 아니라 조직 전체의 민첩성과 효율성을 갉아먹는 구조적 비용으로 이어진다.

물론, 지금의 프론트엔드 스택이 만들어낸 복잡성이 전적으로 불필요하다고 말할 수는 없다. 웹이 더 이상 정적인 문서의 나열이 아닌, 복잡한 상호작용과 상태를 갖는 ‘애플리케이션’의 역할을 감당하게 되면서, 그만큼 체계화된 설계와 개발자 경험(DX)을 위한 도구가 필요해졌다는 주장도 충분히 설득력이 있다. 실제로 컴포넌트화, 타입 시스템, 상태 관리 패턴 등은 팀 규모가 커질수록 유지보수성과 협업 효율을 높여주는 도구이기도 하다. 문제는 이 도구들이 ‘필요한 곳’에 쓰이는 것이 아니라, ‘모든 곳’에 일괄적으로 적용되고 있다는 점이다.

2016년, 모 회사의 기술 면접 과제를 해결하기 위해 redux를 처음 익힐 때가 떠오른다. 단순히 버튼 하나 누를 때 값을 바꾸는 작업인데, 액션을 만들고, 타입을 정의하고, 리듀서를 작성하고, 디스패치를 연결해야 했다. '왜 이렇게 어렵고 복잡하게 상태를 관리해야 하지?' 하는 의문이 들었지만, 그땐 '원래 React 개발은 그런가 보다' 하고 넘겼다. 지금 돌이켜보면, 그 복잡함은 필수가 아니라 비판 없이 수용된 일종의 정답처럼 느껴졌다.

SSR도 마찬가지다. React 초기에는 SPA 기반 CSR로 인해 SEO조차 쉽지 않았던 기억이 난다. 백엔드 개발자로 몇 년을 보내고 어느 순간 프론트엔드 개발 트렌드를 보았을 때 Helmet과 같은 React SSR 방식이 유행을 타고 있었다. 그런데 원래 웹 개발은 모두 서버 사이드 렌더링이 아니었던가?

결국 모던 프론트엔드 프레임워크라 불리는 많은 것들이 구현하고 있던 것은 예전부터 기본값으로 주어졌던 기능들의 복잡하고 비효율적인 재현이었다. 라우팅, 메타태그, 템플릿 렌더링, 캐싱 같은 기본기를 다시 자바스크립트 생태계 안에서 어렵게 되살려내며 마치 그것이 혁신인 양 포장하고 있었을지도 모른다.

시간이 지날 수록 복잡한 빌드 파이프라인, 무거운 프레임워크, 과도한 추상화는 개발자에게는 익숙한 환경이 되었지만, 사용자에게는 점점 낯설고 느린 웹을 안겨주고 있다. 이제 마케터는 간단한 콘텐츠 수정조차 개발자에게 의존해야 하고, SEO 담당자는 개발자만이 읽을 수 있는 코드로 가려진 콘텐츠 탓에 검색 노출을 장담할 수 없다. 한 줄의 수정도 수차례 배포를 거쳐야 하며, 정작 페이지는 여전히 느리고 불안정하다.

정말 지금의 모습은 DX (Developer Experience) 를 위해 UX 를 해치고 있는걸까?

자극적인 글을 하나 읽었다. '개발자들이 새로운 기술 도구로 ‘기술 놀이’를 하느라 복잡성과 비용을 키웠다.' 프론트엔드가 지금까지 발전하며 수 많은 고민과 개선이 있었겠지만, 그 결과 20년전 수십 kb로 구현할 수 있던 기능이 이제는 수 mb의 js 파일을 필요로 한다. 그렇다고 유지보수성이나 개발 생산성이 정말로 향상되었는가? Yes 이면서도 No 이다. 프레임워크와 툴체인은 초기 개발과 반복 작업을 빠르게 만들었지만, 그 대가로 가파르게 상승한 복잡도 속에서 사소한 수정조차 전방위적 사이드 이펙트를 일으키는 구조가 되었다. 생산성은 순간적으로 올라갔지만, 유지보수는 점점 더 전문성과 컨텍스트 의존도를 요구하게 된 것이다. 그리고 이제는 그 복잡도를 유지하면서 새로운 기능을 추가하기 위해 조직은 더 많은 인력과 인건비, 세분화된 포지션을 감당해야 한다. 하나의 기능을 구현하기 위해 프론트엔드, 백엔드, DevOps, QA, 기획이 머리를 맞대야 하고, 각 단계마다 파이프라인을 통과해야만 한다. (과거엔 '웹 마스터' 라는 1인 직책이 있었다는 것을 기억하는가?) 개발은 점점 더 느려지고, 사소한 변경도 일정과 리소스의 계산 대상이 된다. 결국 복잡성은 기술적 문제가 아니라 조직 전체의 민첩성과 효율성을 갉아먹는 구조적 비용으로 이어진다. 물론, 지금의 프론트엔드 스택이 만들어낸 복잡성이 전적으로 불필요하다고 말할 수는 없다. 웹이 더 이상 정적인 문서의 나열이 아닌, 복잡한 상호작용과 상태를 갖는 ‘애플리케이션’의 역할을 감당하게 되면서, 그만큼 체계화된 설계와 개발자 경험(DX)을 위한 도구가 필요해졌다는 주장도 충분히 설득력이 있다. 실제로 컴포넌트화, 타입 시스템, 상태 관리 패턴 등은 팀 규모가 커질수록 유지보수성과 협업 효율을 높여주는 도구이기도 하다. 문제는 이 도구들이 ‘필요한 곳’에 쓰이는 것이 아니라, ‘모든 곳’에 일괄적으로 적용되고 있다는 점이다. 2016년, 모 회사의 기술 면접 과제를 해결하기 위해 redux를 처음 익힐 때가 떠오른다. 단순히 버튼 하나 누를 때 값을 바꾸는 작업인데, 액션을 만들고, 타입을 정의하고, 리듀서를 작성하고, 디스패치를 연결해야 했다. '왜 이렇게 어렵고 복잡하게 상태를 관리해야 하지?' 하는 의문이 들었지만, 그땐 '원래 React 개발은 그런가 보다' 하고 넘겼다. 지금 돌이켜보면, 그 복잡함은 필수가 아니라 비판 없이 수용된 일종의 정답처럼 느껴졌다. SSR도 마찬가지다. React 초기에는 SPA 기반 CSR로 인해 SEO조차 쉽지 않았던 기억이 난다. 백엔드 개발자로 몇 년을 보내고 어느 순간 프론트엔드 개발 트렌드를 보았을 때 Helmet과 같은 React SSR 방식이 유행을 타고 있었다. 그런데 원래 웹 개발은 모두 서버 사이드 렌더링이 아니었던가? 결국 모던 프론트엔드 프레임워크라 불리는 많은 것들이 구현하고 있던 것은 예전부터 기본값으로 주어졌던 기능들의 복잡하고 비효율적인 재현이었다. 라우팅, 메타태그, 템플릿 렌더링, 캐싱 같은 기본기를 다시 자바스크립트 생태계 안에서 어렵게 되살려내며 마치 그것이 혁신인 양 포장하고 있었을지도 모른다. 시간이 지날 수록 복잡한 빌드 파이프라인, 무거운 프레임워크, 과도한 추상화는 개발자에게는 익숙한 환경이 되었지만, 사용자에게는 점점 낯설고 느린 웹을 안겨주고 있다. 이제 마케터는 간단한 콘텐츠 수정조차 개발자에게 의존해야 하고, SEO 담당자는 개발자만이 읽을 수 있는 코드로 가려진 콘텐츠 탓에 검색 노출을 장담할 수 없다. 한 줄의 수정도 수차례 배포를 거쳐야 하며, 정작 페이지는 여전히 느리고 불안정하다. 정말 지금의 모습은 DX (Developer Experience) 를 위해 UX 를 해치고 있는걸까?

Medium

사용자가 아닌 개발자를 위한 웹 개발의 시대

WEBNORI

코프링기반 액터모델을 이용해 단방향 PUB/SUB푸시 시스템을 클루드 코드로 생성시도 , 다소 고급기법인 CQRS+리액티브+액터모델을 코딩을 클루드코드에서 가능한가? 를 알아보기위해 진행된 변종실험입니다.

https://wiki.webnori.com/x/sYGtBg

코프링기반 액터모델을 이용해 단방향 PUB/SUB푸시 시스템을 클루드 코드로 생성시도 , 다소 고급기법인 CQRS+리액티브+액터모델을 코딩을 클루드코드에서 가능한가? 를 알아보기위해 진행된 변종실험입니다. https://wiki.webnori.com/x/sYGtBg

wiki.webnori.com

코틀린 리액티브 SSE 푸시 By 클루드

Claude 너.. 아주 실망이야.. 😑 돈을 저렇게 처묵처묵하고는.. 에잉~

Codex랑 동일한 걸 항상 같이 시켜보는데, 코드베이스 규모가 좀 큰 프로젝트는 OpenAI Codex가 잘하네요.

그러고보니 Claude로 만족할만한 결과가 나온 적이 없는데.. 혹시 Claude 너.. 나 싫어하니.. 😥

Claude 너.. 아주 실망이야.. 😑 돈을 저렇게 처묵처묵하고는.. 에잉~ Codex랑 동일한 걸 항상 같이 시켜보는데, 코드베이스 규모가 좀 큰 프로젝트는 OpenAI Codex가 잘하네요. 그러고보니 Claude로 만족할만한 결과가 나온 적이 없는데.. 혹시 Claude 너.. 나 싫어하니.. 😥

2019년에 저희 팀에서 퍼블리싱한 CHI 논문. 음성 인터페이스 입코딩을 이용한 프로그래밍 교육.

나름 선구자였죠? ☺️

다시보니 자연어로 코딩, 음성 인터페이스, 에이전트 등등 요즘 핫한 키워드는 다 들어감 🫣😆🤭

https://dl.acm.org/doi/abs/10.1145/3290607.3312773

2019년에 저희 팀에서 퍼블리싱한 CHI 논문. 음성 인터페이스 입코딩을 이용한 프로그래밍 교육. 나름 선구자였죠? ☺️ 다시보니 자연어로 코딩, 음성 인터페이스, 에이전트 등등 요즘 핫한 키워드는 다 들어감 🫣😆🤭 https://dl.acm.org/doi/abs/10.1145/3290607.3312773

현업에서 디자인 시스템 프로젝트가 진행되다 보면 종종 이런 질문을 하게 됩니다. “처음엔 잘 가고 있었던 것 같은데, 왜 이게 점점 이상해지는 걸까?” 이유는 생각보다 단순합니다. 팀원들이 각자 다른 곳을 보고 있기 때문입니다. 서로 다른 우선순위, 엇갈리는 방향 디자인 시스템을 만들다 보면 이런 일이 자주 벌어집니다. 디자이너는 ‘예쁘게’ 디자인하는...

우리만의 디자인 시스템, 어디서부터 시작할까? · DaleStudy/daleui · Discussion #392

달레 스터디의 오픈소스 디자인 시스템 프로젝트인 달레UI는 기획부터 디자인, 개발까지의 전 과정을 투명하게 공유하며, 함께 성장하는 것을 목표로 하고 있습니다.

그 두 번째 이야기로, 디자인 시스템 팀의 디자인 리드이신 Mingu Kang 님께서 한국, 캐나다, 영국에서 각기 다른 환경과 경험을 가진 팀원들이 어떻게 하나의 방향을 향해 나아가게 되었는지를 공유해주셨습니다.

✔️ 우리 디자인 시스템의 핵심 가치는 뭘까?
✔️ 어떤 문제를 해결하고 싶은 걸까?
✔️ 그게 잘 되고 있는지는 어떻게 알 수 있을까?

이 질문들에 대한 고민을 바탕으로 워크숍을 통해 미션과 목표, 핵심 가치를 함께 정립해 나간 과정을 구체적이고 생생하게 담아낸 글입니다. 디자인 시스템은 물론 협업 문화나 원격 팀워크에 관심 있는 분들께도 진심으로 추천드리고 싶은 이야기입니다.

📝 글 보러가기: https://github.com/DaleStudy/daleui/discussions/392
(정식 블로그가 오픈되기 전까지는 GitHub Discussions를 통해 콘텐츠를 공유할 예정입니다.)

디자인 시스템에 관심 있는 디자이너, 개발자 여러분의 많은 관심과 피드백 부탁드립니다! 🙌

달레 스터디의 오픈소스 디자인 시스템 프로젝트인 달레UI는 기획부터 디자인, 개발까지의 전 과정을 투명하게 공유하며, 함께 성장하는 것을 목표로 하고 있습니다. 그 두 번째 이야기로, 디자인 시스템 팀의 디자인 리드이신 Mingu Kang 님께서 한국, 캐나다, 영국에서 각기 다른 환경과 경험을 가진 팀원들이 어떻게 하나의 방향을 향해 나아가게 되었는지를 공유해주셨습니다. ✔️ 우리 디자인 시스템의 핵심 가치는 뭘까? ✔️ 어떤 문제를 해결하고 싶은 걸까? ✔️ 그게 잘 되고 있는지는 어떻게 알 수 있을까? 이 질문들에 대한 고민을 바탕으로 워크숍을 통해 미션과 목표, 핵심 가치를 함께 정립해 나간 과정을 구체적이고 생생하게 담아낸 글입니다. 디자인 시스템은 물론 협업 문화나 원격 팀워크에 관심 있는 분들께도 진심으로 추천드리고 싶은 이야기입니다. 📝 글 보러가기: https://github.com/DaleStudy/daleui/discussions/392 (정식 블로그가 오픈되기 전까지는 GitHub Discussions를 통해 콘텐츠를 공유할 예정입니다.) 디자인 시스템에 관심 있는 디자이너, 개발자 여러분의 많은 관심과 피드백 부탁드립니다! 🙌

GitHub

🧭 우리만의 디자인 시스템, 어디서부터 시작할까?

　계속하던 것을 그만둔다는 건, 시작하는 것보다 더 어려운 결정을 요구할 때가 많다. ‘왜 그만둬야 할까?’라는 물음 앞에 서면 수많은 이유와 핑계가 머릿속에서 충돌하고, 그 과정에서 내면의 깊숙한 갈등과 마주하게 된다. 2018년부터 6년 동안 꾸준히 운영해온 기술 블로그 구독 서비스 …

6년간의 토이프로젝트 여정을 마무리하며 - 기술블로그 구독서비스 회고록

안녕하세요.
오랜만에 글을 올리게 되었는데, 이렇게 토이 프로젝트 종료 후기로 인사드리게 될 줄은 몰랐네요 ㅎ
무려 6년 가까이 운영해온 "기술 블로그 구독 서비스"를 최근 종료하게 되었습니다. 매일 아침, 다양한 기술 블로그를 모아 메일로 발송하던 이 작은 서비스는 어느새 수천 명의 개발자분들의 루틴이 되어 있던 것 같습니다.
시작은 단순했습니다. 내가 읽고 싶은 글을 정리하자는 마음에서 출발했죠. 그런데 그 불편함을 해결하고자 만든 도구가 누군가에겐 하루의 시작이 되었고, ‘잘 보고 있다’는 메시지 하나에 큰 보람을 느끼며 여기까지 달려올 수 있었습니다.
그래서일까요. 종료 버튼을 누르기까지, 꽤 오랜 시간 고민이 필요했습니다. 기술 환경도, 저의 역할도 변해가는 시점에서 더 이상 지속하기 어려웠지만, 그동안 함께해주신 모든 분들께 정말 감사한 마음뿐입니다.
마치 하나의 챕터를 덮는 기분이네요. 언젠가 또 다른 방식으로 여러분과 만나게 되길 기대하며, 그동안 함께해주신 모든 구독자분들께 진심으로 감사드립니다.
후기와 회고는 아래 블로그 글로 정리해 두었습니다.
https://taetaetae.github.io/posts/toy-project-retrospective-6-years-journey/

안녕하세요.오랜만에 글을 올리게 되었는데, 이렇게 토이 프로젝트 종료 후기로 인사드리게 될 줄은 몰랐네요 ㅎ무려 6년 가까이 운영해온 "기술 블로그 구독 서비스"를 최근 종료하게 되었습니다. 매일 아침, 다양한 기술 블로그를 모아 메일로 발송하던 이 작은 서비스는 어느새 수천 명의 개발자분들의 루틴이 되어 있던 것 같습니다.시작은 단순했습니다. 내가 읽고 싶은 글을 정리하자는 마음에서 출발했죠. 그런데 그 불편함을 해결하고자 만든 도구가 누군가에겐 하루의 시작이 되었고, ‘잘 보고 있다’는 메시지 하나에 큰 보람을 느끼며 여기까지 달려올 수 있었습니다.그래서일까요. 종료 버튼을 누르기까지, 꽤 오랜 시간 고민이 필요했습니다. 기술 환경도, 저의 역할도 변해가는 시점에서 더 이상 지속하기 어려웠지만, 그동안 함께해주신 모든 분들께 정말 감사한 마음뿐입니다.마치 하나의 챕터를 덮는 기분이네요. 언젠가 또 다른 방식으로 여러분과 만나게 되길 기대하며, 그동안 함께해주신 모든 구독자분들께 진심으로 감사드립니다.후기와 회고는 아래 블로그 글로 정리해 두었습니다.https://taetaetae.github.io/posts/toy-project-retrospective-6-years-journey/

taetaetae.github.io

6년간의 토이프로젝트 여정을 마무리하며 - 기술블로그 구독서비스 

🚀 DDD, 기술보다 사람을 중심에 둔 소프트웨어 전략
"도메인이 복잡한 이유는 기술 때문이 아니라 점점 복잡해지는 도메인 그자체에 있으며 이것을 중심에 두어야한다."
이것이 바로 DDD(Domain-Driven Design)의 핵심 철학입니다.
즉, 시스템이나 기술이 아닌 '도메인 전문가(사람)'를 중심에 두고 문제를 해결하자는 전략이죠.

🤖 그런데 최근 AI는 점점 더 똑똑해지며
사람의 역할을 줄이거나, 때로는 아예 대체하는 방향으로 나아가고 있습니다.
이 AI 시대에,
사람 중심의 문제 해결을 강조해 온 DDD는 어떤 변화를 맞이하게 될까요?

DDD 개념을 먼저 이해하고, DDD 창시자인 Eric Evans의 까지 담은 3종 영상 세트 요약본 입니다.

DDD 그거 그렇게하는거 아닌데 - 우아한형제들
- https://wiki.webnori.com/x/_ICtBg
DDD를 AI에 이용해 설계(Design) 가속화하기
- https://wiki.webnori.com/x/D4GtBg
DDD와 LLM - 에릭에반스(DDD의 창시자-2003년)
- https://wiki.webnori.com/x/CIGtBg

종합 : https://wiki.webnori.com/x/FoGtBg

🚀 DDD, 기술보다 사람을 중심에 둔 소프트웨어 전략 "도메인이 복잡한 이유는 기술 때문이 아니라 점점 복잡해지는 도메인 그자체에 있으며 이것을 중심에 두어야한다." 이것이 바로 DDD(Domain-Driven Design)의 핵심 철학입니다. 즉, 시스템이나 기술이 아닌 '도메인 전문가(사람)'를 중심에 두고 문제를 해결하자는 전략이죠. 🤖 그런데 최근 AI는 점점 더 똑똑해지며 사람의 역할을 줄이거나, 때로는 아예 대체하는 방향으로 나아가고 있습니다. 이 AI 시대에, 사람 중심의 문제 해결을 강조해 온 DDD는 어떤 변화를 맞이하게 될까요? DDD 개념을 먼저 이해하고, DDD 창시자인 Eric Evans의 까지 담은 3종 영상 세트 요약본 입니다. DDD 그거 그렇게하는거 아닌데 - 우아한형제들 - https://wiki.webnori.com/x/_ICtBg DDD를 AI에 이용해 설계(Design) 가속화하기 - https://wiki.webnori.com/x/D4GtBg DDD와 LLM - 에릭에반스(DDD의 창시자-2003년) - https://wiki.webnori.com/x/CIGtBg 종합 : https://wiki.webnori.com/x/FoGtBg

DDD와 AI

2005년 7월에 일을 시작했으니, 올해로 개발자 생활이 햇수로 20년째다. 중간에 공백이 조금씩 있었으니 꽉 채운 스무 해는 아니지만, 숫자가 주는 무게는 여전하다. 20년이라는 시간이 흘렀다는 사실이 새삼 신기하게 느껴진다.

개발에 대한 관심은 고교 시절, MUD 게임을 만들던 친구를 만나면서부터 시작됐다. 코드를 전혀 몰랐기에, 내 역할은 게임 세계관을 만드는 것이었다. 새로운 지역의 지도를 그리고, 아이템이나 기술 설정을 만들고, 짧은 이야기를 엮어 퀘스트를 구상했다. 친구가 코드로 그 상상을 현실로 만드는 과정을 어깨너머로 지켜보는 것은 꽤 흥미로운 경험이었다. 그 이끌림에 C++ 책을 사서 들춰보던 것이 내 첫걸음이었다.

대학 동아리 방에서의 시간은 열정으로 기억된다. 하루 서너 시간만 새우잠을 자며 무언가를 계속 만들었다. 코드가 생각대로 작동할 때의 희열, 풀리지 않는 로직 앞에서 느끼던 분노와 실망, 그리고 마침내 문제를 해결하고 터뜨리던 웃음. 그 모든 과정이 이상할 정도로 재미있었다. 그저 좋아하는 일에 빠져 살았을 뿐인데, 정신을 차리고 보니 나는 개발자라는 직업을 가진 사람이 되어 있었다.

직장에서 동료들과 함께 일하며, 재미의 의미는 조금씩 넓어졌다. 코드를 완성하는 즐거움을 넘어, 내가 만든 소프트웨어가 동료의 수고를 덜어줄 때 더 큰 재미를 느꼈다. 시간이 더 지나서는 코딩이라는 행위를 넘어, 동료들과 머리를 맞대고 더 나은 길을 찾아내며 문제를 해결하는 과정 자체에서 재미를 발견했다.

스무 해. 짧지 않은 시간 동안 이 일을 재미있다고 느끼며 해올 수 있었다는 사실이 큰 축복처럼 다가온다. 앞으로도 오랫동안 내 곁에 머물기를 조용히 바라본다.

2005년 7월에 일을 시작했으니, 올해로 개발자 생활이 햇수로 20년째다. 중간에 공백이 조금씩 있었으니 꽉 채운 스무 해는 아니지만, 숫자가 주는 무게는 여전하다. 20년이라는 시간이 흘렀다는 사실이 새삼 신기하게 느껴진다. 개발에 대한 관심은 고교 시절, MUD 게임을 만들던 친구를 만나면서부터 시작됐다. 코드를 전혀 몰랐기에, 내 역할은 게임 세계관을 만드는 것이었다. 새로운 지역의 지도를 그리고, 아이템이나 기술 설정을 만들고, 짧은 이야기를 엮어 퀘스트를 구상했다. 친구가 코드로 그 상상을 현실로 만드는 과정을 어깨너머로 지켜보는 것은 꽤 흥미로운 경험이었다. 그 이끌림에 C++ 책을 사서 들춰보던 것이 내 첫걸음이었다. 대학 동아리 방에서의 시간은 열정으로 기억된다. 하루 서너 시간만 새우잠을 자며 무언가를 계속 만들었다. 코드가 생각대로 작동할 때의 희열, 풀리지 않는 로직 앞에서 느끼던 분노와 실망, 그리고 마침내 문제를 해결하고 터뜨리던 웃음. 그 모든 과정이 이상할 정도로 재미있었다. 그저 좋아하는 일에 빠져 살았을 뿐인데, 정신을 차리고 보니 나는 개발자라는 직업을 가진 사람이 되어 있었다. 직장에서 동료들과 함께 일하며, 재미의 의미는 조금씩 넓어졌다. 코드를 완성하는 즐거움을 넘어, 내가 만든 소프트웨어가 동료의 수고를 덜어줄 때 더 큰 재미를 느꼈다. 시간이 더 지나서는 코딩이라는 행위를 넘어, 동료들과 머리를 맞대고 더 나은 길을 찾아내며 문제를 해결하는 과정 자체에서 재미를 발견했다. 스무 해. 짧지 않은 시간 동안 이 일을 재미있다고 느끼며 해올 수 있었다는 사실이 큰 축복처럼 다가온다. 앞으로도 오랫동안 내 곁에 머물기를 조용히 바라본다.

올해로 개발자 생활이 햇수로 20년째다

분당 5억의 매출이 발생하는 이벤트 시스템을 어떻게 구축하고 운영했는지 소개합니다.

무진장 힘들었지만 무진장 성장한 개발 이야기

간만에 재밌게 읽은 기술 포스트
여름 이벤트 관련 개발 회고와 높은 트래픽을 어떤 요소들로 잘 방어했는가에 대한 포스트
4월부터 네이버 쇼핑 내에서 트래픽이 높은 부서로 이동한터라 (그래서 드럽게 바쁨)
우리도 적용해 볼법 한 몇가지 내용들이 보여서 흥미로웠음
예전에 적용해봤거나 생각은 해봤던 것들도 있었는데, 결국에는 '아.. 언제하지' 로 귀결 😢

간만에 재밌게 읽은 기술 포스트여름 이벤트 관련 개발 회고와 높은 트래픽을 어떤 요소들로 잘 방어했는가에 대한 포스트4월부터 네이버 쇼핑 내에서 트래픽이 높은 부서로 이동한터라 (그래서 드럽게 바쁨)우리도 적용해 볼법 한 몇가지 내용들이 보여서 흥미로웠음예전에 적용해봤거나 생각은 해봤던 것들도 있었는데, 결국에는 '아.. 언제하지' 로 귀결 😢

간만에 재밌게 읽은 기술 포스트
여름 이벤트 관련 개발 회고와 높

고용노동부에서 주관하는 청년미래플러스 3기를 모집 중이라고 합니다.
구직자와 재직자 두 가지 트랙을 동시에 모집한다고 하네요.
 * 모집 기간: 6월 15일 ~ 8월 3일
 * 구직자 트랙: https://miraeplus.sw.or.kr/ko/o/155208
 * 재직자 트랙: https://miraeplus.sw.or.kr/ko/o/152138

공고에는 다음과 같은 활동 계획이 기재되어 있습니다.

📌 구직자 트랙
 * IT업계 현직자와 멘토링
 * 직무역량 강화 지원 (인프런 강의 15만원 이내)
 * 개별 맞춤형 취업 지원 (서류 첨삭, 모의면접 등)

📌 재직자 트랙
 * 개별 커리어 플랜 설계 지원
 * 커리어 진단 리포트
 * IT업계 현직자와 멘토링
 * 직무역량 강화 지원 (인프런 강의 15만원 이내)

이러한 활동 지원도 좋은 혜택이라고 생각하는데요,
업계 사람과 네트워크를 형성하는 것과 진로나 방향에 대해서 익명이 아닌 누군가(특히 업계 선배)와 면담을 하는 것이 특히 좋은 점인 것 같습니다.

고용노동부에서 주관하는 청년미래플러스 3기를 모집 중이라고 합니다.구직자와 재직자 두 가지 트랙을 동시에 모집한다고 하네요.<ul ><li>모집 기간: 6월 15일 ~ 8월 3일</li></ul><ul ><li>구직자 트랙: https://miraeplus.sw.or.kr/ko/o/155208</li><li>재직자 트랙: https://miraeplus.sw.or.kr/ko/o/152138</li></ul> 공고에는 다음과 같은 활동 계획이 기재되어 있습니다. 📌 구직자 트랙<ul ><li>IT업계 현직자와 멘토링</li><li>직무역량 강화 지원 (인프런 강의 15만원 이내)</li><li>개별 맞춤형 취업 지원 (서류 첨삭, 모의면접 등)</li></ul> 📌 재직자 트랙<ul ><li>개별 커리어 플랜 설계 지원</li><li>커리어 진단 리포트</li><li>IT업계 현직자와 멘토링</li><li>직무역량 강화 지원 (인프런 강의 15만원 이내)</li></ul> 이러한 활동 지원도 좋은 혜택이라고 생각하는데요,업계 사람과 네트워크를 형성하는 것과 진로나 방향에 대해서 익명이 아닌 누군가(특히 업계 선배)와 면담을 하는 것이 특히 좋은 점인 것 같습니다.

고용노동부에서 주관하는 청년미래플러스 3기를 모집 중이라고 합니다

1. 유명한 경제학자 케인스는 단기 투자 전략을 미인선발대회에 비유했다.

2. 이 대회의 규칙은 이렇다. 100명의 후보 사진을 신문에 공개하고 독자들에게 이 중 가장 미인이라고 생각하는 사람 6명에 투표하라고 한다.

3. 그 결과, 독자들로부터 가장 많은 표를 받은 사람이 최고의 미인으로 뽑히고 그 미인에 투표한 사람은 정해진 상금을 받는다.

4. 이 대회에서 선발될 미인을 맞추기 위해서는, 즉 상금을 받기 위해서는 자신이 판단하기에 가장 예쁜 사진을 선택하면 안 되고, 평균적으로 가장 예쁘다 고 생각하는 사진을 선택해서도 안 된다.

5. 참가자 대부분이 판단하기에 평균적 여론이 될 것이라고 기대하는 모습을 예측해야만 하는 것이다.

6. 케인스는 투자의 세계도 이와 비슷하므로 평균적인 여론을 예상해서 투자하라고 한다.

#이채원의가치투자 📚
#투자는심리게임이다

1. 유명한 경제학자 케인스는 단기 투자 전략을 미인선발대회에 비유했다. ​2. 이 대회의 규칙은 이렇다. 100명의 후보 사진을 신문에 공개하고 독자들에게 이 중 가장 미인이라고 생각하는 사람 6명에 투표하라고 한다. ​3. 그 결과, 독자들로부터 가장 많은 표를 받은 사람이 최고의 미인으로 뽑히고 그 미인에 투표한 사람은 정해진 상금을 받는다. 4. 이 대회에서 선발될 미인을 맞추기 위해서는, 즉 상금을 받기 위해서는 자신이 판단하기에 가장 예쁜 사진을 선택하면 안 되고, 평균적으로 가장 예쁘다 고 생각하는 사진을 선택해서도 안 된다. ​5. 참가자 대부분이 판단하기에 평균적 여론이 될 것이라고 기대하는 모습을 예측해야만 하는 것이다. ​6. 케인스는 투자의 세계도 이와 비슷하므로 평균적인 여론을 예상해서 투자하라고 한다. #이채원의가치투자 📚 #투자는심리게임이다

< 가장 예쁜 사람이 아니라, 1등 할 사람에게 투표하라 >

아직 나도 정립되지 않은 상태이긴한데, 실무에서의 바이브 코딩은 다르다.

비단 개발자 관점에서만이 아니라, 기획자, 디자이너도 마찬가지로 다른 방식을 써야한다.

지금의 바이브 코딩을 말하는 자, 가르치는 자는 거의 대부분(아마도 99.9%) 새로운 프로토타입을 만드는 것을 가르치는 것이다.

그런데, 실무에서 중요한 건 완전히 새로운 것이 아니라, 기존의 프로젝트를 수정/확장하는 것이다. 그것이 프로토타입이라도.

즉, 협업이 관건이다.

이를 고려하면 ChatGPT의 Codex가 한 발짝 앞서 나가 있는 상태라고 할 수 있다. 다만 실행하여 결과를 보여주지 못하는 것이 아직 비어있는 부분.

요즘 CLI 형태의 툴이 유행하는데, 이건 플러그인하기 쉽다는 장점이 있어서 기본 기술을 만드는데는 유리하지만, 결국 통합 시스템은 필요하다.

과연 누가 먼저 이 통합 시스템을 유의미한 수준으로 서비스하기 시작할지가 관전 포인트.

…말만하지말고 내가 만들어야하는데… 😒

아직 나도 정립되지 않은 상태이긴한데, 실무에서의 바이브 코딩은 다르다. 비단 개발자 관점에서만이 아니라, 기획자, 디자이너도 마찬가지로 다른 방식을 써야한다. 지금의 바이브 코딩을 말하는 자, 가르치는 자는 거의 대부분(아마도 99.9%) 새로운 프로토타입을 만드는 것을 가르치는 것이다. 그런데, 실무에서 중요한 건 완전히 새로운 것이 아니라, 기존의 프로젝트를 수정/확장하는 것이다. 그것이 프로토타입이라도. 즉, 협업이 관건이다. 이를 고려하면 ChatGPT의 Codex가 한 발짝 앞서 나가 있는 상태라고 할 수 있다. 다만 실행하여 결과를 보여주지 못하는 것이 아직 비어있는 부분. 요즘 CLI 형태의 툴이 유행하는데, 이건 플러그인하기 쉽다는 장점이 있어서 기본 기술을 만드는데는 유리하지만, 결국 통합 시스템은 필요하다. 과연 누가 먼저 이 통합 시스템을 유의미한 수준으로 서비스하기 시작할지가 관전 포인트. …말만하지말고 내가 만들어야하는데… 😒

아직 나도 정립되지 않은 상태이긴한데, 실무에서의 바이브 코딩은 

﻿
'이력서 - 잃었어 - 일없어'
어제 취업 지원 프로그램에서 이력서 준비의 중요성을 강조했더니, 한 구직자가 자신의 상황을 재치 있게 표현한 말입니다. 현재 이력서가 준비되어 있는지 물었더니 "잃어버렸다"고 답했습니다. 물론 정말 잃어버린 것은 아니었습니다. 다른 사람에게 보여주기 부끄러울 만큼 자신의 이력서가 변변치 않아서 숨기고 싶다는 의미였죠. 왜 보여주기 싫은지 물었을 때, 이력서에 써넣을 특별한 경험이 없어서라고 했습니다.

뻔뻔했던 신입 시절의 나
제가 처음 취업을 준비하던 시절을 떠올려봅니다. 당시 제 이력서는 그리 훌륭하지 않았습니다. 특별히 희망하는 직무가 없었기에 어디든 투척할 수 있는 범용 이력서였고, 어제 만난 구직자의 말처럼 특별한 경험이 없었습니다. 정확히 표현하면 직장생활을 대비한 경험이 전무했죠. 서류 전형 합격률이 낮았던 이유를 이제야 이해하게 되었습니다. 제가 채용 담당자라도 그런 신입은 뽑지 않았을 것입니다.
그러나 과거 신입 채용에 도전하던 저는 대단히 뻔뻔했습니다. 이력서는 촌스럽고 알맹이 없는 가벼운 내용이었지만, 다른 사람에게 보여주기를 주저하지 않았습니다. 빠르게 취업을 하고 싶었기 때문입니다.
특별한 이유는 없었습니다. 그저 남들이 취업하니까 저도 취업하고 싶었고, 남들이 취업해서 돈을 버니까 저도 제 힘으로 돈을 벌어 부모님 신세를 면하고 싶었습니다. 취업을 희망하는 대단한 목표는 없었지만, 취업하자는 확실한 동기가 있었기 때문에 형편없는 이력서였음에도 입사 지원하기를 주저하지 않았던 것입니다.

완벽한 준비의 함정
요즘 신입 구직자들은 완벽한 이력서 준비가 필요하다고 생각합니다. 완벽히 준비가 되기 전까지는 입사 지원할 수 없다고 이야기하죠. 준비를 꼼꼼하게 하고 싶다는 생각은 정말 훌륭합니다. 그러나 준비가 어느 정도 필요한지 판단은 스스로 내리기 어렵다고 생각합니다.
현재의 준비된 상태로 입사 지원을 해보며, 동시에 필요한 준비를 계속 갖추어 나가는 것이 좋습니다. 어차피 완벽한 이력서란 존재하지 않습니다. 이력서는 제품과 같아서 끊임없이 개선이 필요하기 때문입니다. 이력서는 발자취라는 개념을 담고 있기 때문에 매일 한 발자국씩 나아갈 수록 업데이트할 내용이 생겨납니다.

특별한 경험이란 무엇인가
"특별한 경험이 없다"는 이야기도 완벽한 준비와 비슷한 맥락으로 버려야 할 생각입니다. 세상에 어떤 경험이 특별하다고 이야기할 수 있을까요? 대단한 브랜드 가치를 지닌 회사에서 일한 경험이 특별한가요? 대단한 숫자로 성과를 만든 내용이 특별한가요? 대단한 사람과 협업한 경험이 특별한가요?
눈에 보이는 어떠한 요인이 특별한 경험이라고 생각한다면, 오해입니다. 특별한 경험은 경험의 주인인 내가 특별하게 생각하고, 그것을 특별하게 소개할 때 대단해진다고 믿습니다.
자신이 자신의 경험을 대단하고 특별하게 여기지 않는다면, 다른 어떤 사람이 대신 특별하고 대단하게 봐줄 수 있을까요? 먼저 자신의 경험을 소중하게 생각하는 마음이 필요합니다. 그 다음 자신의 경험을 특별하게 소개하는 내용으로 만드는 것입니다.

경험을 특별하게 만드는 구조
제가 정의하는 특별한 경험이란, 일을 시작하고 진행하는 과정에서 많은 고민이 담긴 내용입니다. 어떤 배경에서 일을 시작했고, 목적과 목표가 무엇이었으며, 목적과 목표를 달성하기 위해 노력한 내용과 결과를 소개하는 것입니다. 이러한 구조로 경험을 소개한다면, 우리의 어떤 경험도 특별해질 수 있다고 생각합니다.
무엇보다 중요한 것은 문제를 뾰족하게 정의하는 것입니다. 무엇을 문제로 생각하였기에 경험했던 일을 시작하게 된 것인지 설명을 잘 할 수 있다면, 우리의 경험이 더욱 특별해질 수 있다고 믿습니다.
그러나 이력서를 작성하는 많은 분들이 경험을 소개하는 내용에서 문제 정의, 즉 일을 시작하게 된 배경에 대해서 생략하는 경우가 많습니다. 문제를 정의하고 목표와 목적을 설명하는 내용이 없을 때, 성과가 대단하더라도 경험에 대한 소개를 읽는 사람이 경험의 성과를 특별하고 대단하다고 판단하지 못합니다.
경험의 시작을 논리적으로 설명하는 내용이 있을 때, 일을 진행한 과정을 흥미롭게 보게 되고, 성과가 크든 작든 공감과 납득을 하게 됩니다.

당당한 이력서를 위한 제안
이력서의 내용, 형식, 디자인, 가독성 등 채용 전형에서 당락을 좌우하는 중요한 요소가 많습니다. 오늘 이력서를 업데이트하려는 분이 계시다면, 꼭 경험을 잘 풀어서 설명해보는 시간을 가져보시기 바랍니다.
기존에 자신이 봤던 이력서 형식은 머릿속에서 지우고, 자신의 경험을 가장 잘 설명하고 자랑할 수 있는 구조로 만들어보세요. 합격하는 이력서의 모범 답안은 바로 여러분 머리와 마음 속에 있습니다.

당당하고 자신 있게 자신의 경험을 마음껏 담아낸 이력서를 뽑아내는 우리가 되길 진심으로 응원합니다.

﻿'이력서 - 잃었어 - 일없어'어제 취업 지원 프로그램에서 이력서 준비의 중요성을 강조했더니, 한 구직자가 자신의 상황을 재치 있게 표현한 말입니다. 현재 이력서가 준비되어 있는지 물었더니 "잃어버렸다"고 답했습니다. 물론 정말 잃어버린 것은 아니었습니다. 다른 사람에게 보여주기 부끄러울 만큼 자신의 이력서가 변변치 않아서 숨기고 싶다는 의미였죠. 왜 보여주기 싫은지 물었을 때, 이력서에 써넣을 특별한 경험이 없어서라고 했습니다. 뻔뻔했던 신입 시절의 나제가 처음 취업을 준비하던 시절을 떠올려봅니다. 당시 제 이력서는 그리 훌륭하지 않았습니다. 특별히 희망하는 직무가 없었기에 어디든 투척할 수 있는 범용 이력서였고, 어제 만난 구직자의 말처럼 특별한 경험이 없었습니다. 정확히 표현하면 직장생활을 대비한 경험이 전무했죠. 서류 전형 합격률이 낮았던 이유를 이제야 이해하게 되었습니다. 제가 채용 담당자라도 그런 신입은 뽑지 않았을 것입니다.그러나 과거 신입 채용에 도전하던 저는 대단히 뻔뻔했습니다. 이력서는 촌스럽고 알맹이 없는 가벼운 내용이었지만, 다른 사람에게 보여주기를 주저하지 않았습니다. 빠르게 취업을 하고 싶었기 때문입니다.특별한 이유는 없었습니다. 그저 남들이 취업하니까 저도 취업하고 싶었고, 남들이 취업해서 돈을 버니까 저도 제 힘으로 돈을 벌어 부모님 신세를 면하고 싶었습니다. 취업을 희망하는 대단한 목표는 없었지만, 취업하자는 확실한 동기가 있었기 때문에 형편없는 이력서였음에도 입사 지원하기를 주저하지 않았던 것입니다. 완벽한 준비의 함정요즘 신입 구직자들은 완벽한 이력서 준비가 필요하다고 생각합니다. 완벽히 준비가 되기 전까지는 입사 지원할 수 없다고 이야기하죠. 준비를 꼼꼼하게 하고 싶다는 생각은 정말 훌륭합니다. 그러나 준비가 어느 정도 필요한지 판단은 스스로 내리기 어렵다고 생각합니다.현재의 준비된 상태로 입사 지원을 해보며, 동시에 필요한 준비를 계속 갖추어 나가는 것이 좋습니다. 어차피 완벽한 이력서란 존재하지 않습니다. 이력서는 제품과 같아서 끊임없이 개선이 필요하기 때문입니다. 이력서는 발자취라는 개념을 담고 있기 때문에 매일 한 발자국씩 나아갈 수록 업데이트할 내용이 생겨납니다. 특별한 경험이란 무엇인가"특별한 경험이 없다"는 이야기도 완벽한 준비와 비슷한 맥락으로 버려야 할 생각입니다. 세상에 어떤 경험이 특별하다고 이야기할 수 있을까요? 대단한 브랜드 가치를 지닌 회사에서 일한 경험이 특별한가요? 대단한 숫자로 성과를 만든 내용이 특별한가요? 대단한 사람과 협업한 경험이 특별한가요?눈에 보이는 어떠한 요인이 특별한 경험이라고 생각한다면, 오해입니다. 특별한 경험은 경험의 주인인 내가 특별하게 생각하고, 그것을 특별하게 소개할 때 대단해진다고 믿습니다.자신이 자신의 경험을 대단하고 특별하게 여기지 않는다면, 다른 어떤 사람이 대신 특별하고 대단하게 봐줄 수 있을까요? 먼저 자신의 경험을 소중하게 생각하는 마음이 필요합니다. 그 다음 자신의 경험을 특별하게 소개하는 내용으로 만드는 것입니다. 경험을 특별하게 만드는 구조제가 정의하는 특별한 경험이란, 일을 시작하고 진행하는 과정에서 많은 고민이 담긴 내용입니다. 어떤 배경에서 일을 시작했고, 목적과 목표가 무엇이었으며, 목적과 목표를 달성하기 위해 노력한 내용과 결과를 소개하는 것입니다. 이러한 구조로 경험을 소개한다면, 우리의 어떤 경험도 특별해질 수 있다고 생각합니다.무엇보다 중요한 것은 문제를 뾰족하게 정의하는 것입니다. 무엇을 문제로 생각하였기에 경험했던 일을 시작하게 된 것인지 설명을 잘 할 수 있다면, 우리의 경험이 더욱 특별해질 수 있다고 믿습니다.그러나 이력서를 작성하는 많은 분들이 경험을 소개하는 내용에서 문제 정의, 즉 일을 시작하게 된 배경에 대해서 생략하는 경우가 많습니다. 문제를 정의하고 목표와 목적을 설명하는 내용이 없을 때, 성과가 대단하더라도 경험에 대한 소개를 읽는 사람이 경험의 성과를 특별하고 대단하다고 판단하지 못합니다.경험의 시작을 논리적으로 설명하는 내용이 있을 때, 일을 진행한 과정을 흥미롭게 보게 되고, 성과가 크든 작든 공감과 납득을 하게 됩니다. 당당한 이력서를 위한 제안이력서의 내용, 형식, 디자인, 가독성 등 채용 전형에서 당락을 좌우하는 중요한 요소가 많습니다. 오늘 이력서를 업데이트하려는 분이 계시다면, 꼭 경험을 잘 풀어서 설명해보는 시간을 가져보시기 바랍니다.기존에 자신이 봤던 이력서 형식은 머릿속에서 지우고, 자신의 경험을 가장 잘 설명하고 자랑할 수 있는 구조로 만들어보세요. 합격하는 이력서의 모범 답안은 바로 여러분 머리와 마음 속에 있습니다. 당당하고 자신 있게 자신의 경험을 마음껏 담아낸 이력서를 뽑아내는 우리가 되길 진심으로 응원합니다.﻿

길은 잃은 이력서

AI 100조 성공하려면 주 52시간 규제부터 풀어야 民生은 기업 경쟁력에 달렸다 김윤덕이 만난 사람 배틀 그라운드서 AI 기업으로 벤처신화 장병규 크래프톤 의장

‘AI 100조’ 성공하려면 주 52시간 규제부터 풀어야… 民生은 기업 경쟁력에 달렸다

“실리콘밸리의 힘은 개인의 자율과 책임을 극대화한 것에 있다. 이를 위해서는 회사에 무슨 일이 있는지 구성원들이 알아야 한다. 소수의 리더가 관리·감독하며 이끄는 조직은 관료화될 뿐, 숨는 사람이 많아지고, 더 크게 성장하지 못한다.”

“나는 일대일 미팅을 좋아하지 않는다. ‘한 사람을 오랫동안 속일 순 있어도 여러 사람을 오래 속일 순 없다’는 격언처럼 일대일 대화는 사기꾼이 오래 살아남는 구조를 만든다. 첫 창업 회사인 네오위즈 때 여러 다툼이 있었는데 원인 중 하나가 일대일 대화였다. 다 같이 모여서 얘기하면 서로 다른 의견을 명료히 알게 되고 곡해 없이 해법을 찾아갈 수 있다. 나와 생각이 다른 임원과 토론할 때도 그가 신뢰하는 이를 꼭 배석시키라고 요청한다.”

“창업 초기 꿈꿨던 바텀업(아래로부터의 의사 결정)이랄지, 360도 평가 같은 건 많이 타협했다. ‘우아한 형제들’ 김봉진님이 ‘관계는 수평적, 업무는 수직적’이란 표현을 했는데, 우리도 비슷하다.”

“시간도 경쟁력이란 뜻이다. 중국은 ‘996(오전 9시~오후 9시까지 주 6일 근무)’을 하는데 주 52시간 일하는 한국이 어떻게 이길 수 있나? 이기는 게 오히려 이상하지 않나?”

“주 52시간을 하는 이유는 충분히 이해한다. 문제는 획일적 적용이다. 다양성, 포용성, 창의성을 강조하면서 왜 노동의 다양성은 인정하지 않을까? 정치인들이 민생을 외치던데, 한국 민생은 기업의 글로벌 경쟁력에 달려 있다.”

https://www.chosun.com/opinion/2025/07/06/S6E5OB73EVHX5PJYHJZCGIDDY4/

“실리콘밸리의 힘은 개인의 자율과 책임을 극대화한 것에 있다. 이를 위해서는 회사에 무슨 일이 있는지 구성원들이 알아야 한다. 소수의 리더가 관리·감독하며 이끄는 조직은 관료화될 뿐, 숨는 사람이 많아지고, 더 크게 성장하지 못한다.” “나는 일대일 미팅을 좋아하지 않는다. ‘한 사람을 오랫동안 속일 순 있어도 여러 사람을 오래 속일 순 없다’는 격언처럼 일대일 대화는 사기꾼이 오래 살아남는 구조를 만든다. 첫 창업 회사인 네오위즈 때 여러 다툼이 있었는데 원인 중 하나가 일대일 대화였다. 다 같이 모여서 얘기하면 서로 다른 의견을 명료히 알게 되고 곡해 없이 해법을 찾아갈 수 있다. 나와 생각이 다른 임원과 토론할 때도 그가 신뢰하는 이를 꼭 배석시키라고 요청한다.” “창업 초기 꿈꿨던 바텀업(아래로부터의 의사 결정)이랄지, 360도 평가 같은 건 많이 타협했다. ‘우아한 형제들’ 김봉진님이 ‘관계는 수평적, 업무는 수직적’이란 표현을 했는데, 우리도 비슷하다.” “시간도 경쟁력이란 뜻이다. 중국은 ‘996(오전 9시~오후 9시까지 주 6일 근무)’을 하는데 주 52시간 일하는 한국이 어떻게 이길 수 있나? 이기는 게 오히려 이상하지 않나?” “주 52시간을 하는 이유는 충분히 이해한다. 문제는 획일적 적용이다. 다양성, 포용성, 창의성을 강조하면서 왜 노동의 다양성은 인정하지 않을까? 정치인들이 민생을 외치던데, 한국 민생은 기업의 글로벌 경쟁력에 달려 있다.” https://www.chosun.com/opinion/2025/07/06/S6E5OB73EVHX5PJYHJZCGIDDY4/

조선일보

“실리콘밸리의 힘은 개인의 자율과 책임을 극대화한 것에 있다. 이

점점 더 예측하기 힘들어지는 취업/채용 시장,

현재 2000명이 넘게 사용한 데이터 직무/ 커리어를 준비하는 취준생분들을 위한
데이터 이력서 작성 템플릿 + 작성법 가이드를 무료로 배포합니다.

✔ 노션으로 만든 이력서 3종 템플릿
✔ 매일 7일간 이메일로 도착하는 실전 노하우/맞춤형 가이드

두가지 혜택을 결합한 학습 패키지를 아래 댓글의 링크에서
이메일만 입력하시고 무료로 받아가세요.

데이터 이력서 템플릿 + 작성 가이드:
https://dchanlim.gumroad.com/l/datarichard_notion_template

점점 더 예측하기 힘들어지는 취업/채용 시장, 현재 2000명이 넘게 사용한 데이터 직무/ 커리어를 준비하는 취준생분들을 위한데이터 이력서 작성 템플릿 + 작성법 가이드를 무료로 배포합니다. ✔ 노션으로 만든 이력서 3종 템플릿 ✔ 매일 7일간 이메일로 도착하는 실전 노하우/맞춤형 가이드 두가지 혜택을 결합한 학습 패키지를 아래 댓글의 링크에서 이메일만 입력하시고 무료로 받아가세요. 데이터 이력서 템플릿 + 작성 가이드:https://dchanlim.gumroad.com/l/datarichard_notion_template

데이터 이력서 템플릿 + 작성 가이드를 사용해보세요.

지원자를 다시 보게 만드는 센스 있는 역질문

#퍼블리매일읽기챌린지 #퍼블리뷰 #퍼블리뷰8일차

구직/이직 면접 관련 질문들을 살펴보는 건 항상 흥미롭다. 
짬짬이 읽어두고 기억해 두면 언젠가 피가 되고 살이 되겠지.

댓글 0

함께 읽은 게시물

< 당신의 커리어를 바꿀 단 두 가지 능력 >

썸원의 아무말 글쓰기 클럽 모집 안내

< 답답한 팀원 때문에 잠 못 드는 리더에게 >

AI ML 개발자분들 주목!!🔥

[Datamation] AI 데이터 분류 마스터링: 궁극의 가이드

주간 인기 TOP 10

추천 프로필