6월 6일(금) 저녁엔 시즌5 세 번째 모임을 가졌습니다. 시간이 되는 멤버들끼리 먼저 모여 트레바리 강남 아지트 504호에 모여 각자 가져온 음식을 나누었습니다. 쿠키와 과자, 케이크와 닭강정, 크로플과 사케가 들어간 초콜릿까지. 생일파티 같은 시작이었습니다. 한 달과 두 달 동안의 근황을 나누고 『달리기를 말할 때 내가 하고 싶은 이야기』를 두고 지적 대화를 시작했습니다. 몸이 아파서,

트레바리 시즌5, 세 번째 모임을 마치고 – 안티클라이막스와 지속가능한 불완전함에 대하여

6월 6일(금) 저녁엔 <리서치 하는데요> 시즌5 세 번째 모임을 가졌습니다. 시간이 되는 멤버들끼리 먼저 모여 트레바리 강남 아지트 504호에 모여 각자 가져온 음식을 나누었습니다. 쿠키와 과자, 케이크와 닭강정, 크로플과 사케가 들어간 초콜릿까지. 생일파티 같은 시작이었습니다. 한 달과 두 달 동안의 근황을 나누고 『달리기를 말할 때 내가 하고 싶은 이야기』를 두고 지적 대화를 시작했습니다. 몸이 아파서, 갑작스러운 일정으로 독후감을 제출하고도 모임에 함께 못한 멤버들께 안부를 전하며, 다음 모임에서 더 반갑게 인사드리겠습니다.

먼저 이 책의 제목에 관하여 하루키가 밝히고 있는 내용이 있어 소개합니다. 저자가 왜 이 책을 스스로 회고록이라고 밝히는지에 대한 생각도 담겨있습니다. 이 책은 저자가 원고를 완성하는데 10년 이상 걸린 책으로 달리기에 대한 이야기라기보다는 스스로 연소하며 지속가능한 불완전함을 이야기하는 회고록에 가깝습니다.

"나의 경애하는 작가, 레이먼드 카버(Raymond Carver)의 단편집 타이틀 『사랑에 대해 말할 때 우리가 이야기하는 것』을 책 제목의 원형으로 쓸 수 있도록 흔쾌히 허락해 준 테스 갤러거(Tes Gallagher) 부인에게 깊이 감사드립니다. 또 10년 이상 원고가 완성되기를 죽 기다려준 인내심 강한 편집자 오카 미도리 씨에게도 김이 감사하고 싶다." - 무라카미 하루키, 『달리기를 말할 때 내가 하고 싶은 이야기』 후기 중에서

원문 링크를 통해 발제문과 북토크에서 나눈 지적 대화들을 살펴보실 수 있습니다.

https://redbusbagman.com/trevariseason53/

6월 6일(금) 저녁엔 &lt;리서치 하는데요&gt; 시즌5 세 번째 모임을 가졌습니다. 시간이 되는 멤버들끼리 먼저 모여 트레바리 강남 아지트 504호에 모여 각자 가져온 음식을 나누었습니다. 쿠키와 과자, 케이크와 닭강정, 크로플과 사케가 들어간 초콜릿까지. 생일파티 같은 시작이었습니다. 한 달과 두 달 동안의 근황을 나누고 『달리기를 말할 때 내가 하고 싶은 이야기』를 두고 지적 대화를 시작했습니다. 몸이 아파서, 갑작스러운 일정으로 독후감을 제출하고도 모임에 함께 못한 멤버들께 안부를 전하며, 다음 모임에서 더 반갑게 인사드리겠습니다. 먼저 이 책의 제목에 관하여 하루키가 밝히고 있는 내용이 있어 소개합니다. 저자가 왜 이 책을 스스로 회고록이라고 밝히는지에 대한 생각도 담겨있습니다. 이 책은 저자가 원고를 완성하는데 10년 이상 걸린 책으로 달리기에 대한 이야기라기보다는 스스로 연소하며 지속가능한 불완전함을 이야기하는 회고록에 가깝습니다. "나의 경애하는 작가, 레이먼드 카버(Raymond Carver)의 단편집 타이틀 『사랑에 대해 말할 때 우리가 이야기하는 것』을 책 제목의 원형으로 쓸 수 있도록 흔쾌히 허락해 준 테스 갤러거(Tes Gallagher) 부인에게 깊이 감사드립니다. 또 10년 이상 원고가 완성되기를 죽 기다려준 인내심 강한 편집자 오카 미도리 씨에게도 김이 감사하고 싶다." - 무라카미 하루키, 『달리기를 말할 때 내가 하고 싶은 이야기』 후기 중에서 원문 링크를 통해 발제문과 북토크에서 나눈 지적 대화들을 살펴보실 수 있습니다. https://redbusbagman.com/trevariseason53/

REDBUSBAGMAN | 빨간색 버스에 가방을 메고 탑니다

⟪안티클라이막스와 지속가능한 지속가능한 불완전함에 대하여⟫

우리가 만들고 있는 서비스의 근간을 이해해야 하는 이유

발이 닿지 않는 바다에서

우리는 서비스를 개발할 때 표면을 유영해요. 라이브러리, API처럼 잘 약속된 인터페이스를 사용하죠. 얕은 물에서 수영하는 것과 비슷해요.

평소에는 표면을 유영하듯 개발해도 문제가 없어요. 표면 아래, 서비스를 이루고 있는 근간을 이해하지 못해도 괜찮아요. 구현엔 어려움이 없으니까요.

하지만 장애를 마주하는 날엔 후회할지도 몰라요.

https://hajoeun.com/2025/below-surface?utm_source=careerly

우리는 서비스를 개발할 때 표면을 유영해요. 라이브러리, API처럼 잘 약속된 인터페이스를 사용하죠. 얕은 물에서 수영하는 것과 비슷해요. 평소에는 표면을 유영하듯 개발해도 문제가 없어요. 표면 아래, 서비스를 이루고 있는 근간을 이해하지 못해도 괜찮아요. 구현엔 어려움이 없으니까요. 하지만 장애를 마주하는 날엔 후회할지도 몰라요. https://hajoeun.com/2025/below-surface?utm_source=careerly

hajoeun.com

디자인으로 해결할 것과 기능으로 해결할 것에 대한 구분 | 화면 기획에 빠진 PM들 14년간 PM으로 일하면서 수십 개 회사의 기획 리뷰에 참여해봤어요. 그때마다 PM들에게 던지는 질문이 하나 있어요.  이 화면이 우리의 문제를 해결하나요?  놀랍게도 이 질문을 받은 PM 10명 중 7명이 당황하며 말을 잇지 못했어요. 특히 화면 기획을 PM의 핵심 업무로 보는 조직일수록 이런 현상이 두드러졌어요. 문제 정의는 완

이 화면이 우리의 문제를 해결하나요?

디자인으로 해결할 것과 기능으로 해결할 것에 대한 구분

PRD 작성하거나 기능 요구사항을 정리하다 보면, 어느새 머릿속에서 "아, 이 문제는 이렇게 화면 바꾸면 되겠네"라고 성급하게 결론 내리는 경우가 정말 많아요. 저도 초기 PM 시절에 이런 실수를 수없이 반복했거든요. 하지만 가장 먼저 해야 할 일은 해당 문제를 디자인으로 해결할지, 기능/기획으로 해결할지 냉정하게 판단하는 것이에요. 이 판단 능력이야말로 시니어 PM과 주니어 PM을 가르는 핵심 역량 중 하나라고 확신해요.

[디자인 vs 기능, 실무에서 판단하는 구체적인 기준]
1단계: 문제의 본질 파악
 * 사용자가 진짜로 불편해하는 지점이 어디인가?
 * 이 불편함이 '보는 것'의 문제인가, '하는 것'의 문제인가?
 * 현재 프로세스에서 불필요한 단계는 없는가?
2단계: 해결 방향성 결정
 * 화면을 바꾼다고 근본 문제가 해결될까?
 * 프로세스를 바꾸면 화면을 건드리지 않고도 해결될까?
 * 두 가지를 모두 해야 하는 문제일까?

https://brunch.co.kr/@lbyd-hj/39

---
비개발자도 Cursor AI로 결제 가능한 웹 서비스 만들기 🚀
6시간 동안 Supabase, MCP, Mixpanel, 결제 기능까지 정복하자! 🚀

단순히 사용 방법이 아닌 제가 없이도 Cursor AI를 잘 사용하실 수 있도록 개발지식도 같이 전달드리며 진행한 강의가 벌써 6차에 이르렀네요! 매 순간 더 쉽고 더 잘 이해하실 수 있도록 노력하고 있는데, 진심이 전해졌는지 후기도 4.8점(5점 만점)에 이르렀네요!

6월 21일과 28일 Cursor AI, Supabase, MCP, 결제 모듈을 배워보고자 하시는 분들은 많은 관심 부탁드려요!

https://www.latpeed.com/products/3qCN5

---
 * 진행 중인 강의 보러 가기 : 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

디자인으로 해결할 것과 기능으로 해결할 것에 대한 구분 PRD 작성하거나 기능 요구사항을 정리하다 보면, 어느새 머릿속에서 "아, 이 문제는 이렇게 화면 바꾸면 되겠네"라고 성급하게 결론 내리는 경우가 정말 많아요. 저도 초기 PM 시절에 이런 실수를 수없이 반복했거든요. 하지만 가장 먼저 해야 할 일은 해당 문제를 디자인으로 해결할지, 기능/기획으로 해결할지 냉정하게 판단하는 것이에요. 이 판단 능력이야말로 시니어 PM과 주니어 PM을 가르는 핵심 역량 중 하나라고 확신해요. [디자인 vs 기능, 실무에서 판단하는 구체적인 기준]1단계: 문제의 본질 파악<ul ><li>사용자가 진짜로 불편해하는 지점이 어디인가?</li><li>이 불편함이 '보는 것'의 문제인가, '하는 것'의 문제인가?</li><li>현재 프로세스에서 불필요한 단계는 없는가?</li></ul>2단계: 해결 방향성 결정<ul ><li>화면을 바꾼다고 근본 문제가 해결될까?</li><li>프로세스를 바꾸면 화면을 건드리지 않고도 해결될까?</li><li>두 가지를 모두 해야 하는 문제일까?</li></ul> https://brunch.co.kr/@lbyd-hj/39 ---비개발자도 Cursor AI로 결제 가능한 웹 서비스 만들기 🚀6시간 동안 Supabase, MCP, Mixpanel, 결제 기능까지 정복하자! 🚀 단순히 사용 방법이 아닌 제가 없이도 Cursor AI를 잘 사용하실 수 있도록 개발지식도 같이 전달드리며 진행한 강의가 벌써 6차에 이르렀네요! 매 순간 더 쉽고 더 잘 이해하실 수 있도록 노력하고 있는데, 진심이 전해졌는지 후기도 4.8점(5점 만점)에 이르렀네요! 6월 21일과 28일 Cursor AI, Supabase, MCP, 결제 모듈을 배워보고자 하시는 분들은 많은 관심 부탁드려요! https://www.latpeed.com/products/3qCN5 ---<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

소프트웨어 개발 방법론의 역사

소프트웨어 개발 방법론의 역사

Q. 회사가 또 혁신안을 내놓았습니다. 이번에도 조직개편 중심인 혁신안을 실행한다고 하지만 이전에도 시간이 지나면서 흐지부지된 적이 있습니다. 저도 혁신이 필요하지 않다고 생각하는 건 아닙니다. 제대로 혁신해서 회사가 발전하기를 간절히 바랍니다. 그런 길이 있다면 적극

과거의 성공체험이 혁신의 걸림돌이 되지 않으려면

❓회사가 또 혁신안을 내놓았습니다. 이번에도 조직개편 중심의 혁신안을 내놓았지만, 사실 예전에도 시간이 지나며 흐지부지 되었습니다. 혁신이 필요하지 않다고 생각하는 건 아닙니다. 제대로 혁신해서 회사가 발전하기를 간절히 바랍니다. 그런 길이 있다면 적극 동참하고 싶습니다. 혁신은 어떻게 해야 하는 걸까요?

❗️예, 이젠 ‘혁신’이란 말이 진부하게 느껴질 정도지요. 혁신(革新)이란 몸의 가죽과 피부를 새롭게 바꾼다는 뜻이니 사실은 보통 어려운 일이 아니지요. 손발에 2도 화상만 입어도 새살이 돋는 데는 엄청난 시간이 걸리지 않습니까.

그런데 근래에는 ‘개선’ 정도의 일에도 혁신이란 표현을 쓰는 것이 아닌가 하는 생각도 듭니다. 아무튼 어떤 조직이 혁신을 한다고 할 때는 지금 이대로 가다가는 조직의 존립이 위태로워진다는 위기의식에서 출발하게 됩니다.

그런데 혁신이 성공하기 위해서는 우선 최고경영자의 확고한 내적 확신과 더불어 그 리더십의 진정성이 확보되어야 합니다. 경영진이 자신의 안위를 위해서 하는 프로젝트가 아니라, 그 자신이 희생되더라도 조직의 미래와 후배들을 위해서 하는 것이라는 것이 느껴질 때 구성원들은 극단적인 신뢰를 보냅니다. 즉 진정성은 리더의 자기희생을 먹고 자랍니다.

다음으로는 조직 내부에서 위기의식이 공유되어야 합니다. 조직의 최상부 밀실에서만 논의되고 나머지 구성원들이 소외된 채로 시행되는 조치들은, 억지로 밀어붙일 수 있을지는 모르지만 자발적 참여와 실행 단계에서의 창의력이 확보되지 못해 효과를 보기 어려울 뿐 아니라 시간이 가면서 유야무야되기 십상입니다.

예를 들면, 경영혁신의 목표를 달성하기 위한 방책의 하나로 조직개편을 할 수는 있습니다. 그런데 개편 뒤 조직이 기대한 대로 작동하기 위해서는 구성원들의 적극적인 역할이 필요합니다. 이 단계에서 자발성과 창의성이 확보되지 못하면 결코 기대한 효과를 보기가 어렵지요.

또한 적지 않은 경우에 조직개편이 재무적 관점에서 추진되는 경우들이 있습니다. 물론 때로는 경비절감 그 자체를 위한 조직개편이 있을 수도 있지만, 잘못하면 업의 본질을 훼손하게 되는 결과를 가져올 수도 있습니다. 생존이 우선이지만 단지 생존만이 조직의 존재 목적일 수는 없습니다.

“우리 회사는 왜 존재하고 무엇을 이루려고 하는 것인가?” 이 질문에 경영진은 늘 답할 수 있어야 합니다. 그래서 조직개편도 ‘비용 얼마를 절감하기 위해’라는 접근보다는 ‘어떤 산출물을 만들어내기 위해’, 즉 재무적 관점을 넘어 전략적 관점에서 검토되고 시행되어야 합니다.

결국, 혁신이 실패하는 가장 큰 이유는 최고경영자가 머리로는 그것을 이해하지만 그것을 가슴으로까지 연결하여 체화하지 못했기 때문입니다. 머리에서 가슴까지의 거리는 참으로 멀 수도 있습니다.

또는 최고경영자를 포함한 경영진들의 과거의 성공 체험이 오히려 혁신을 저해할 수도 있습니다. 설혹 겉으로는 표현을 하지 않는다 하더라도 과거의 성공 방식에서 벗어나지 못하여 심리적으로 저항하고 거부함으로써 시간이 가면서 결국은 혁신 전략이 실행되지 못하게 할 수도 있습니다.

과거의 성공 체험이 혁신의 걸림돌이 아니라 촉진제가 되려면 어떻게 해야 할까요? 최고경영자와 경영진이 늘 깨어 있어야 합니다. 자신의 성공 체험이 전부가 아니고 변화와 위기는 늘 예상치 못한 곳에서 올 수 있다는 열린 자세를 가져야 합니다.

경영자는 회사의 현재와 미래를 고민하고 길을 찾으려 애써야 합니다. 자신을 희생하는 한이 있더라도 이후의 회사를 고민하고 준비하는 경영자에 대해 조직 구성원들은 진정성을 느낍니다. 그리고 그 진정성에 대한 극단적인 신뢰는 실질적인 혁신을 가능하게 하는 가장 큰 힘입니다.

혁신과 관련하여 리더가 하기 쉬운 실수가 한 가지 더 있습니다. 회사가 어려운 상황에서는 리더는 똑똑하면서 오만한 사람에게 끌리는 경향이 있습니다. 이런 사람들은 굉장히 일을 잘하며 특히 윗사람에게는 아주 잘할 가능성이 큽니다. 그런데 문제는 이런 사람 곁에는 다른 사람들이 모이지 않는다는 것입니다.

왜냐하면 오만하고 똑똑한 그는 무능함을 죄악으로 여기기 때문에 주변인들이 모멸감을 느끼게 만듭니다. 경영자는 다양한 장점을 가진 사람들을 품어야 하는데 그 사람 때문에 필요한 인재를 놓칠 위험이 있습니다. 성공 체험과 똑똑함은 미래를 위한 아주 긴요한 자산일 수도 있지만, 한편으론 독이 될 수도 있다는 사실을 잊지 말아야 합니다.

짐 콜린스는 <좋은 기업을 넘어 위대한 기업으로>에서 위대한 기업을 만든 경영자는 대개 리더십의 가장 높은 수준인 제5단계 리더십에 도달한 사람들이라고 말합니다. 이 단계의 리더는 인간적 겸허함(personal humility)과 프로다운 의지(professional will)를 융합하여 자신의 퇴임 이후에도 회사가 지속적으로 위대할 수 있도록 만드는 경영자라는 것이지요.

그런데 여기서 겸허함, 휴밀리티(humility)의 어원은 휴머스(humus)인데 유기질이 풍부한 짙은 색깔의 흙을 뜻한다고 합니다. 한편, 굴욕이라는 뜻의 휴밀리에이션(humiliation) 역시 땅, 흙, 아래, 낮음 등의 어원을 갖고 있다고 합니다. 겸허함이라는 건 굴욕을 참아내는 행동, 그 끝에서 얻어지는 것이 아닐까, 겸허함을 얻으려면 굴욕이라는 단련이 필요한 것이 아닌가 생각해봅니다.

조직을 위하는 마음이 누구보다도 크고 높은, 능력을 인정받고, 성과를 내는 중간 관리자가 간혹 회사 안에서 자존심이 상하고 또 굴욕적인 대접을 받는 경우가 있습니다. 이건 부당하다, 옳지 않다, 정의롭지 않다고 느끼면서 분노하고 또 좌절하기도 합니다.

그러나 어쩌면 그 사람에게는 이것이 굴욕이라는 단련 과정을 통해서 겸허함의 단계로 올라갈 수 있는 절호의 기회일지도 모른다는 생각을 해봅니다.

지식이 지혜가 되기 위해서는 반드시 머리가 가슴에 도달해야 합니다. 그런데 머리에서 가슴까지가 가장 먼 거리라고 합니다. 그리고 바로 갈 수는 없는 길이라서 머리의 생각이 땅으로 떨어져 흙 속에서 뒹굴고 나서야 드디어 가슴에 도달하는 경험을 하는, 즉 리더십의 도약의 기회이기도 하다는 것이지요.

❓회사가 또 혁신안을 내놓았습니다. 이번에도 조직개편 중심의 혁신안을 내놓았지만, 사실 예전에도 시간이 지나며 흐지부지 되었습니다. 혁신이 필요하지 않다고 생각하는 건 아닙니다. 제대로 혁신해서 회사가 발전하기를 간절히 바랍니다. 그런 길이 있다면 적극 동참하고 싶습니다. 혁신은 어떻게 해야 하는 걸까요? ❗️예, 이젠 ‘혁신’이란 말이 진부하게 느껴질 정도지요. 혁신(革新)이란 몸의 가죽과 피부를 새롭게 바꾼다는 뜻이니 사실은 보통 어려운 일이 아니지요. 손발에 2도 화상만 입어도 새살이 돋는 데는 엄청난 시간이 걸리지 않습니까. 그런데 근래에는 ‘개선’ 정도의 일에도 혁신이란 표현을 쓰는 것이 아닌가 하는 생각도 듭니다. 아무튼 어떤 조직이 혁신을 한다고 할 때는 지금 이대로 가다가는 조직의 존립이 위태로워진다는 위기의식에서 출발하게 됩니다. 그런데 혁신이 성공하기 위해서는 우선 최고경영자의 확고한 내적 확신과 더불어 그 리더십의 진정성이 확보되어야 합니다. 경영진이 자신의 안위를 위해서 하는 프로젝트가 아니라, 그 자신이 희생되더라도 조직의 미래와 후배들을 위해서 하는 것이라는 것이 느껴질 때 구성원들은 극단적인 신뢰를 보냅니다. 즉 진정성은 리더의 자기희생을 먹고 자랍니다. 다음으로는 조직 내부에서 위기의식이 공유되어야 합니다. 조직의 최상부 밀실에서만 논의되고 나머지 구성원들이 소외된 채로 시행되는 조치들은, 억지로 밀어붙일 수 있을지는 모르지만 자발적 참여와 실행 단계에서의 창의력이 확보되지 못해 효과를 보기 어려울 뿐 아니라 시간이 가면서 유야무야되기 십상입니다. 예를 들면, 경영혁신의 목표를 달성하기 위한 방책의 하나로 조직개편을 할 수는 있습니다. 그런데 개편 뒤 조직이 기대한 대로 작동하기 위해서는 구성원들의 적극적인 역할이 필요합니다. 이 단계에서 자발성과 창의성이 확보되지 못하면 결코 기대한 효과를 보기가 어렵지요. 또한 적지 않은 경우에 조직개편이 재무적 관점에서 추진되는 경우들이 있습니다. 물론 때로는 경비절감 그 자체를 위한 조직개편이 있을 수도 있지만, 잘못하면 업의 본질을 훼손하게 되는 결과를 가져올 수도 있습니다. 생존이 우선이지만 단지 생존만이 조직의 존재 목적일 수는 없습니다. “우리 회사는 왜 존재하고 무엇을 이루려고 하는 것인가?” 이 질문에 경영진은 늘 답할 수 있어야 합니다. 그래서 조직개편도 ‘비용 얼마를 절감하기 위해’라는 접근보다는 ‘어떤 산출물을 만들어내기 위해’, 즉 재무적 관점을 넘어 전략적 관점에서 검토되고 시행되어야 합니다. 결국, 혁신이 실패하는 가장 큰 이유는 최고경영자가 머리로는 그것을 이해하지만 그것을 가슴으로까지 연결하여 체화하지 못했기 때문입니다. 머리에서 가슴까지의 거리는 참으로 멀 수도 있습니다. 또는 최고경영자를 포함한 경영진들의 과거의 성공 체험이 오히려 혁신을 저해할 수도 있습니다. 설혹 겉으로는 표현을 하지 않는다 하더라도 과거의 성공 방식에서 벗어나지 못하여 심리적으로 저항하고 거부함으로써 시간이 가면서 결국은 혁신 전략이 실행되지 못하게 할 수도 있습니다. 과거의 성공 체험이 혁신의 걸림돌이 아니라 촉진제가 되려면 어떻게 해야 할까요? 최고경영자와 경영진이 늘 깨어 있어야 합니다. 자신의 성공 체험이 전부가 아니고 변화와 위기는 늘 예상치 못한 곳에서 올 수 있다는 열린 자세를 가져야 합니다. 경영자는 회사의 현재와 미래를 고민하고 길을 찾으려 애써야 합니다. 자신을 희생하는 한이 있더라도 이후의 회사를 고민하고 준비하는 경영자에 대해 조직 구성원들은 진정성을 느낍니다. 그리고 그 진정성에 대한 극단적인 신뢰는 실질적인 혁신을 가능하게 하는 가장 큰 힘입니다. 혁신과 관련하여 리더가 하기 쉬운 실수가 한 가지 더 있습니다. 회사가 어려운 상황에서는 리더는 똑똑하면서 오만한 사람에게 끌리는 경향이 있습니다. 이런 사람들은 굉장히 일을 잘하며 특히 윗사람에게는 아주 잘할 가능성이 큽니다. 그런데 문제는 이런 사람 곁에는 다른 사람들이 모이지 않는다는 것입니다. 왜냐하면 오만하고 똑똑한 그는 무능함을 죄악으로 여기기 때문에 주변인들이 모멸감을 느끼게 만듭니다. 경영자는 다양한 장점을 가진 사람들을 품어야 하는데 그 사람 때문에 필요한 인재를 놓칠 위험이 있습니다. 성공 체험과 똑똑함은 미래를 위한 아주 긴요한 자산일 수도 있지만, 한편으론 독이 될 수도 있다는 사실을 잊지 말아야 합니다. 짐 콜린스는 &lt;좋은 기업을 넘어 위대한 기업으로&gt;에서 위대한 기업을 만든 경영자는 대개 리더십의 가장 높은 수준인 제5단계 리더십에 도달한 사람들이라고 말합니다. 이 단계의 리더는 인간적 겸허함(personal humility)과 프로다운 의지(professional will)를 융합하여 자신의 퇴임 이후에도 회사가 지속적으로 위대할 수 있도록 만드는 경영자라는 것이지요. 그런데 여기서 겸허함, 휴밀리티(humility)의 어원은 휴머스(humus)인데 유기질이 풍부한 짙은 색깔의 흙을 뜻한다고 합니다. 한편, 굴욕이라는 뜻의 휴밀리에이션(humiliation) 역시 땅, 흙, 아래, 낮음 등의 어원을 갖고 있다고 합니다. 겸허함이라는 건 굴욕을 참아내는 행동, 그 끝에서 얻어지는 것이 아닐까, 겸허함을 얻으려면 굴욕이라는 단련이 필요한 것이 아닌가 생각해봅니다. 조직을 위하는 마음이 누구보다도 크고 높은, 능력을 인정받고, 성과를 내는 중간 관리자가 간혹 회사 안에서 자존심이 상하고 또 굴욕적인 대접을 받는 경우가 있습니다. 이건 부당하다, 옳지 않다, 정의롭지 않다고 느끼면서 분노하고 또 좌절하기도 합니다. 그러나 어쩌면 그 사람에게는 이것이 굴욕이라는 단련 과정을 통해서 겸허함의 단계로 올라갈 수 있는 절호의 기회일지도 모른다는 생각을 해봅니다. 지식이 지혜가 되기 위해서는 반드시 머리가 가슴에 도달해야 합니다. 그런데 머리에서 가슴까지가 가장 먼 거리라고 합니다. 그리고 바로 갈 수는 없는 길이라서 머리의 생각이 땅으로 떨어져 흙 속에서 뒹굴고 나서야 드디어 가슴에 도달하는 경험을 하는, 즉 리더십의 도약의 기회이기도 하다는 것이지요.

한겨레

﻿
어제 점심, 콩국수를 먹었습니다. 현충일과 주말이 이어진 연휴를 맞아 충청남도 서천군에 있는 처갓집을 찾았습니다. 이곳은 빌딩보다 산이 많고, 사람보다 나무가 많은, 전형적인 시골입니다.

차로 10분쯤 가면 읍내가 나옵니다. 슈퍼와 음식점 몇 곳, 그리고 약간의 편의시설이 있지만, '편의시설'이라기보다는 음식점이 대부분입니다. 그 읍내에 콩국수 맛집이 있다는 소문을 듣고, 어제 점심 메뉴로 정하게 되었습니다.

그런데 놀랍게도, 식당 앞에는 대기 인원이 5팀이 넘는 줄이 서 있었습니다. 평소 사람 구경하기도 어려운 한적한 동네에서, 그것도 시골 읍내에서 이런 북적거림은 믿기 어려운 광경이었습니다. 혼잣말로 중얼거렸습니다. "도대체 이 사람들은 어디서 온 거지?"

관광객일까, 명절처럼 친척 방문을 온 사람들일까? 별의별 상상을 다 하다가 결국 장인어른께 여쭈어봤습니다. 돌아온 답은 의외였습니다. 바로 "소문난 맛집이라 외지에서 콩국수를 먹으러 오는 사람들"이라는 것이었습니다. 30분 이상 걸리는 거리에서도 일부러 찾아오고, 기다리면서까지 이 시골 콩국수를 먹고 간다는 겁니다.

사실 제 기준으로는 쉽게 이해되지 않았지만, 생각해보니 요즘 사람들은 맛있는 음식을 먹기 위해 거리나 기다림쯤은 감수합니다. 더 놀라운 건, 이런 식당이 읍내에만 세 곳이나 있다는 겁니다. 고기집, 냉면집도 소문이 나서 외지 손님들이 많다고 합니다.

소문의 힘은 강력합니다. 온라인 시대의 입소문은 지역의 경계를 가볍게 넘나듭니다. 자동차라는 이동 수단 덕분에 맛집이 어디 있든 상관없고, 사람들은 그 경험을 '즐거움'으로 받아들입니다.

이런 소문의 메커니즘은 음식점에만 해당되지 않습니다. 커리어 코칭을 받은 사람이 친구를 소개하거나, 만족한 고객이 지인에게 서비스를 추천하는 것 역시 소문입니다. 수많은 서비스 중 선택받는 건 거의 기적에 가까운 확률입니다. 그래서 '소문'이 중요합니다. 기존 고객의 평가, 즉 리뷰는 가장 신뢰받는 마케팅 수단입니다.
그렇다면 좋은 소문은 어디서 나올까요? 바로 '실력'입니다. 진짜 실력자는 스스로 홍보하지 않아도 사람들이 알아보고 찾아옵니다. 은둔 고수를 찾아 도전하려는 사람들이 끊이지 않는 이유는, 누군가 그 고수의 실력을 먼저 경험하고 소문을 냈기 때문입니다.

실력이 있다면 마케팅은 덜 요란해도 됩니다. 오히려 검증된 실력을 경험한 사람들이 입소문을 내줄 것이고, 그 신뢰도는 여느 광고보다 높게 작용합니다. 저처럼 귀가 얇은 사람은 지인의 추천 하나에 다른 대안은 생각도 안 하고 곧장 선택해버리곤 합니다. 물론 항상 성공적이지는 않았습니다. '소문난 잔치에 먹을 것 없다'는 말이 실감나는 순간도 있었습니다.

여러분은 소문을 얼마나 믿으시나요? 맛집이라는 말만 듣고 먼 길을 달려간 적은 없으신가요? 혹시 여러분이 홍보하고 싶은 서비스가 있다면, 먼저 실력을 키우는 데 집중해 보세요. 실력만 있다면, 은둔 고수가 되는 것도 어렵지 않습니다. 번화가에 대형 간판을 내걸지 않아도, 진짜를 찾는 사람들은 외딴 시골이라도 찾아옵니다.
요란한 마케팅보다, 묵직한 실력으로 존재감을 드러내는 여러분이 되시길 응원합니다.

﻿어제 점심, 콩국수를 먹었습니다. 현충일과 주말이 이어진 연휴를 맞아 충청남도 서천군에 있는 처갓집을 찾았습니다. 이곳은 빌딩보다 산이 많고, 사람보다 나무가 많은, 전형적인 시골입니다. 차로 10분쯤 가면 읍내가 나옵니다. 슈퍼와 음식점 몇 곳, 그리고 약간의 편의시설이 있지만, '편의시설'이라기보다는 음식점이 대부분입니다. 그 읍내에 콩국수 맛집이 있다는 소문을 듣고, 어제 점심 메뉴로 정하게 되었습니다. 그런데 놀랍게도, 식당 앞에는 대기 인원이 5팀이 넘는 줄이 서 있었습니다. 평소 사람 구경하기도 어려운 한적한 동네에서, 그것도 시골 읍내에서 이런 북적거림은 믿기 어려운 광경이었습니다. 혼잣말로 중얼거렸습니다. "도대체 이 사람들은 어디서 온 거지?" 관광객일까, 명절처럼 친척 방문을 온 사람들일까? 별의별 상상을 다 하다가 결국 장인어른께 여쭈어봤습니다. 돌아온 답은 의외였습니다. 바로 "소문난 맛집이라 외지에서 콩국수를 먹으러 오는 사람들"이라는 것이었습니다. 30분 이상 걸리는 거리에서도 일부러 찾아오고, 기다리면서까지 이 시골 콩국수를 먹고 간다는 겁니다. 사실 제 기준으로는 쉽게 이해되지 않았지만, 생각해보니 요즘 사람들은 맛있는 음식을 먹기 위해 거리나 기다림쯤은 감수합니다. 더 놀라운 건, 이런 식당이 읍내에만 세 곳이나 있다는 겁니다. 고기집, 냉면집도 소문이 나서 외지 손님들이 많다고 합니다. 소문의 힘은 강력합니다. 온라인 시대의 입소문은 지역의 경계를 가볍게 넘나듭니다. 자동차라는 이동 수단 덕분에 맛집이 어디 있든 상관없고, 사람들은 그 경험을 '즐거움'으로 받아들입니다. 이런 소문의 메커니즘은 음식점에만 해당되지 않습니다. 커리어 코칭을 받은 사람이 친구를 소개하거나, 만족한 고객이 지인에게 서비스를 추천하는 것 역시 소문입니다. 수많은 서비스 중 선택받는 건 거의 기적에 가까운 확률입니다. 그래서 '소문'이 중요합니다. 기존 고객의 평가, 즉 리뷰는 가장 신뢰받는 마케팅 수단입니다.그렇다면 좋은 소문은 어디서 나올까요? 바로 '실력'입니다. 진짜 실력자는 스스로 홍보하지 않아도 사람들이 알아보고 찾아옵니다. 은둔 고수를 찾아 도전하려는 사람들이 끊이지 않는 이유는, 누군가 그 고수의 실력을 먼저 경험하고 소문을 냈기 때문입니다. 실력이 있다면 마케팅은 덜 요란해도 됩니다. 오히려 검증된 실력을 경험한 사람들이 입소문을 내줄 것이고, 그 신뢰도는 여느 광고보다 높게 작용합니다. 저처럼 귀가 얇은 사람은 지인의 추천 하나에 다른 대안은 생각도 안 하고 곧장 선택해버리곤 합니다. 물론 항상 성공적이지는 않았습니다. '소문난 잔치에 먹을 것 없다'는 말이 실감나는 순간도 있었습니다. 여러분은 소문을 얼마나 믿으시나요? 맛집이라는 말만 듣고 먼 길을 달려간 적은 없으신가요? 혹시 여러분이 홍보하고 싶은 서비스가 있다면, 먼저 실력을 키우는 데 집중해 보세요. 실력만 있다면, 은둔 고수가 되는 것도 어렵지 않습니다. 번화가에 대형 간판을 내걸지 않아도, 진짜를 찾는 사람들은 외딴 시골이라도 찾아옵니다.요란한 마케팅보다, 묵직한 실력으로 존재감을 드러내는 여러분이 되시길 응원합니다.﻿

콩국수를 먹다가

[💪 첫 팀원분의 인프런 강의 출시를 응원하기 위해 작성한 글]

여러분들은 첫 팀장 또는 첫 사수가 떠오르시나요? 회사를 다니면 여러 관계를 맺게 되는데, 전 과거의 관계들이 여전히 생생하네요. 처음 경험할 때는 특히 더 기억에 남는 것 같기도 해요.

저는 첫 팀원분들을 종종 떠올려요(사실 저랑 같이 일한 분들을 종종 떠올려요) 저도 팀장이 처음이였던 미숙한 시절부터 저를 보고, 저의 변화를 오래 본 사람들이라고 할 수 있겠죠. 저도 처음 팀장을 할 때는 우당탕탕하고, 감정의 기복도 많았는데 지금은 평온한 상태를 유지하고 있어요.

좋은 팀장이 되겠다는 다짐을 하면서 지표를 정했는데, &quot;좋은 일이나 슬픈 일이 있을 때 나에게 연락을 해주는가?&quot;를 지표로 삼았어요. 단, 기간에 대해서는 지정하진 않았어요. 1년이 되었든, 2년이 되었든 상관 없어요. 개념적으로는 Unbounded 리텐션이랑 유사하겠네요. 결혼식, 레퍼 체크, 사업적 고민 논의 등 어떤 이야기를 하더라도 많이 도와주려고 하고 있어요. 제가 도와드렸던 팀원분들이 종종 연락을 해주실 때(여러 이유로) 다 감사하게 생각하고 있어요. 부탁도 상관 없으니 편히 연락주셔도 된답니다. 카일타임(1:1 면담의 이름)이 그립다면 그냥 연락주셔도 괜찮아요.

첫 팀원분들은 타다 베이직 시절 같이 데이터 분석, 머신러닝 알고리즘 개발을 했던 3명이 떠오르는데, 지금 모두 다 다른 경험을 하고 있어요. 누군가는 창업을 해서 새로운 시장을 개척하고 있고, 누

노코드 자동화 입문부터 실전까지: n8n 완전정복 강의 | 데이터팝콘 - 인프런 | 변성윤

추천사 1: https://tinyurl.com/27czg5ab
추천사 2: https://tinyurl.com/2bo98tyt

안녕하세요. 노코드 AI 자동화 툴 n8n 강의가 출시되었습니다.

출시 한 달 만에 벌써 수강생 100여 명이 신청해 주셨고, 관련하여 유튜브 라이브 및 강의 업데이트도 꾸준히 진행할 예정입니다.

n8n 툴은 Make, Zapier, IFTTT처럼 자동화를 코드 없이 손쉽게 구현할 수 있도록 설계된 오픈소스 툴입니다. Langchain, CrewAI 등 다양한 도구들이 등장하며 LLM 사용이 쉬워졌다고는 하지만, 제대로 활용하려면 여전히 많은 학습이 필요합니다.

깊이 있는 공부 없이도 LLM 기반의 서비스나 시스템을 만들고 싶은 분들께 이 툴을 적극 추천드립니다.
n8n 툴의 가장 큰 장점은 두 가지입니다. 바로 1. 비용, 2. 편의성입니다.

첫째, API 비용을 제외하면 무료로 사용할 수 있습니다.
둘째, 약간의 개발 지식만 있다면 단 5분 만에 AI 챗봇을 만들 수 있습니다.

이 두 가지 장점을 살려, 자동화 워크플로우 기획부터 실제 유즈케이스까지 담은 강의를 업로드했습니다.

저는 현재 n8n 공식 앰배서더로 활동 중이며, 이 툴이 더 많은 분들께 쉽게 전달될 수 있도록 다양한 방식으로 소개하고 있습니다.
추가로, 마감되긴 했지만 오는 7월 7일 오프라인 밋업도 기획되었으며, 오픈 3일 만에 70장이 모두 판매되었습니다. (현재는 추가 티켓을 조금씩 늘려보고 있습니다.)
👉 https://www.latpeed.com/products/TFnua

강의 얼리버드 혜택이 하루밖에 남지 않았습니다!
이 글을 확인하신 분은 지금 바로 확인 후 구매해 주세요. 감사합니다.
👉 https://inf.run/ALcCu

추천사 1: https://tinyurl.com/27czg5ab추천사 2: https://tinyurl.com/2bo98tyt 안녕하세요. 노코드 AI 자동화 툴 n8n 강의가 출시되었습니다. 출시 한 달 만에 벌써 수강생 100여 명이 신청해 주셨고, 관련하여 유튜브 라이브 및 강의 업데이트도 꾸준히 진행할 예정입니다. n8n 툴은 Make, Zapier, IFTTT처럼 자동화를 코드 없이 손쉽게 구현할 수 있도록 설계된 오픈소스 툴입니다. Langchain, CrewAI 등 다양한 도구들이 등장하며 LLM 사용이 쉬워졌다고는 하지만, 제대로 활용하려면 여전히 많은 학습이 필요합니다. 깊이 있는 공부 없이도 LLM 기반의 서비스나 시스템을 만들고 싶은 분들께 이 툴을 적극 추천드립니다.n8n 툴의 가장 큰 장점은 두 가지입니다. 바로 1. 비용, 2. 편의성입니다. 첫째, API 비용을 제외하면 무료로 사용할 수 있습니다.둘째, 약간의 개발 지식만 있다면 단 5분 만에 AI 챗봇을 만들 수 있습니다. 이 두 가지 장점을 살려, 자동화 워크플로우 기획부터 실제 유즈케이스까지 담은 강의를 업로드했습니다. 저는 현재 n8n 공식 앰배서더로 활동 중이며, 이 툴이 더 많은 분들께 쉽게 전달될 수 있도록 다양한 방식으로 소개하고 있습니다.추가로, 마감되긴 했지만 오는 7월 7일 오프라인 밋업도 기획되었으며, 오픈 3일 만에 70장이 모두 판매되었습니다. (현재는 추가 티켓을 조금씩 늘려보고 있습니다.)👉 https://www.latpeed.com/products/TFnua 강의 얼리버드 혜택이 하루밖에 남지 않았습니다!이 글을 확인하신 분은 지금 바로 확인 후 구매해 주세요. 감사합니다.👉 https://inf.run/ALcCu

tinyurl.com

(홍보) 노코드 AI 자동화툴 n8n 강의 얼리버드 혜택 D-1

얼리버드 할인종료 D-1
https://inf.run/ALcCu

사고 파트너로서 AI가 가치를 보여주는 네 가지 의사결정 영역과 접근법 | 누군가와 대화를 나누다 보면, 직접적인 답이 아니더라도 상대방의 질문이나 반응만으로 내 생각이 깊어지고 넓어지는 경험을 하곤 합니다. 사고/생각 파트너(thought partner)란 개념은 최근 AI가 등장하면서 부각되는 키워드입니다. 내가 생각하지 못한 질문 하나로, 머릿속 깊이 있던 생각이 수면 위로 떠오르게 하는 존재가 좋은 사고 파트너의 본질인 것

사고 파트너(thought partner)로서 AI

누군가와 대화를 나누다 보면, 직접적인 답이 아니더라도 상대방의 질문이나 반응만으로 내 생각이 깊어지고 넓어지는 경험을 하곤 합니다. 사고/생각 파트너(thought partner)란 개념은 최근 AI가 등장하면서 부각되는 키워드입니다. 내가 생각하지 못한 질문 하나로, 머릿속 깊이 있던 생각이 수면 위로 떠오르게 하는 존재가 좋은 사고 파트너의 본질인 것 같습니다.

사고 파트너로서 AI
사고 파트너로서 AI는 큰 틀에서 네 가지 상황에서 가치를 보여준다고 생각합니다(대부분 이 범주에 포함될 것 같습니다).

1. 복잡한 결정
우리가 의사결정을 내릴 때 고려해야 할 선택지나 방향성이 다양하면 판단이 쉽지 않습니다. AI는 이러한 여러 시나리오를 빠르고 체계적으로 분석하여 평가 기준을 제공하는데 도움을 받을 수 있습니다.

2. 리스크가 높은 결정
조직에 중대한 영향을 미칠 수 있는 결정은 세밀한 평가가 필수적입니다. 보통 이러한 결정들은 사람이 직접하면 많은 시간, 그리고 깊은 사고력이 요구됩니다. 이러한 주제에 AI를 활용하면 리스크를 신속하고 깊이 있게 평가할 수 있습니다.

3. 명확한 답이 없는 결정
프로덕트 개발에 있어 매 순간 우리는 완벽한 해결책을 찾기 어렵습니다. 대부분의 어렵고 논쟁적인 문제들은 본질적으로 완벽한 해결책이 존재하지 않습니다. AI는 이런 모호한 문제를 명확하고 구조화된 질문으로 바꿔, 문제의 핵심을 진단하고 불완전하더라도 맥락과 이유를 담은 해결책을 제안하도록 돕습니다. 결국 중요한 것은 완벽한 답을 찾는 것이 아니라, 문제를 이해하고 불확실성을 탐색하며 가능한 경로를 밝혀내는 데 있습니다.

4. 전문 분야에서의 의사결정
자신이 전문성을 갖춘 분야에서는 AI가 제시한 결과를 단순히 수동적으로 받아들이는 것이 아니라, 개인의 경험과 맥락, 미묘한 관점을 결합하면 더욱 정교하고 신뢰할 수 있는 결과를 도출할 수 있습니다.

AI를 사고 파트너로 활용

AI를 사고 파트너로 활용할 때는 그 한계를 분명히 인지해야 합니다. AI는 비즈니스의 특수한 배경과 맥락, 조직 내부의 섬세한 워크플로우를 충분히 이해하지 못하기 때문입니다. 물론 최근 OpenAI의 커넥터나 레코딩 같은 제품을 통해 이런 한계를 보완하려는 시도가 이루어지고 있습니다. 하지만 여전히 중요한 것은 AI의 제안을 비판적으로 평가하고, 사람과 조직이 축적한 인사이트를 결합하는 과정입니다.

AI를 진정한 사고 파트너로 활용하려면, 우선 명확한 역할과 페르소나를 부여하는 것으로 시작할 수 있습니다. AI에게 'Head of Product' 또는 '프로덕트 마케터' 같은 역할을 주면 더 구체적이고 유용한 결과를 얻을 수 있습니다. 또한 많은 컨텍스트(예: 고객의 인터뷰, 사용자의 행동 데이터, 시장 리포트 등)을 제공하는 것이 중요합니다. 마지막으로 AI를 단순한 검색 엔진으로 활용하는 것이 아니라, 함께 아이디어를 고민하고 발전시키는 파트너로 여기고 적극적으로 대화를 이끌 수 있습니다. 이렇게 접근하면 AI의 활용이 단지 효율성 개선 이상으로 더 나은 인사이트로 연결될 수 있을 것입니다.

https://brunch.co.kr/@yongjinjinipln/227

누군가와 대화를 나누다 보면, 직접적인 답이 아니더라도 상대방의 질문이나 반응만으로 내 생각이 깊어지고 넓어지는 경험을 하곤 합니다. 사고/생각 파트너(thought partner)란 개념은 최근 AI가 등장하면서 부각되는 키워드입니다.&nbsp;내가 생각하지 못한 질문 하나로, 머릿속 깊이 있던 생각이 수면 위로 떠오르게 하는 존재가 좋은 사고 파트너의 본질인 것 같습니다. 사고 파트너로서 AI사고 파트너로서 AI는 큰 틀에서 네 가지 상황에서 가치를 보여준다고 생각합니다(대부분 이 범주에 포함될 것 같습니다). 1. 복잡한 결정 우리가 의사결정을 내릴 때 고려해야 할 선택지나 방향성이 다양하면 판단이 쉽지 않습니다. AI는 이러한 여러 시나리오를 빠르고 체계적으로 분석하여 평가 기준을 제공하는데 도움을 받을 수 있습니다. 2. 리스크가 높은 결정 조직에 중대한 영향을 미칠 수 있는 결정은 세밀한 평가가 필수적입니다. 보통 이러한 결정들은 사람이 직접하면 많은 시간, 그리고 깊은 사고력이 요구됩니다. 이러한 주제에 AI를 활용하면 리스크를 신속하고 깊이 있게 평가할 수 있습니다. 3. 명확한 답이 없는 결정 프로덕트 개발에 있어 매 순간 우리는 완벽한 해결책을 찾기 어렵습니다. 대부분의 어렵고 논쟁적인 문제들은 본질적으로 완벽한 해결책이 존재하지 않습니다.&nbsp;AI는 이런 모호한 문제를 명확하고 구조화된 질문으로 바꿔, 문제의 핵심을 진단하고 불완전하더라도 맥락과 이유를 담은 해결책을 제안하도록 돕습니다. 결국 중요한 것은 완벽한 답을 찾는 것이 아니라, 문제를 이해하고 불확실성을 탐색하며 가능한 경로를 밝혀내는 데 있습니다. 4. 전문 분야에서의 의사결정 자신이 전문성을 갖춘 분야에서는 AI가 제시한 결과를 단순히 수동적으로 받아들이는 것이 아니라, 개인의 경험과 맥락, 미묘한 관점을 결합하면 더욱 정교하고 신뢰할 수 있는 결과를 도출할 수 있습니다. AI를 사고 파트너로 활용 AI를 사고 파트너로 활용할 때는 그 한계를 분명히 인지해야 합니다.&nbsp;AI는 비즈니스의 특수한 배경과 맥락, 조직 내부의 섬세한 워크플로우를 충분히 이해하지 못하기 때문입니다. 물론 최근 OpenAI의 커넥터나 레코딩 같은 제품을 통해 이런 한계를 보완하려는 시도가 이루어지고 있습니다. 하지만 여전히 중요한 것은 AI의 제안을 비판적으로 평가하고, 사람과 조직이 축적한 인사이트를 결합하는 과정입니다. AI를 진정한 사고 파트너로 활용하려면, 우선 명확한 역할과 페르소나를 부여하는 것으로 시작할 수 있습니다. AI에게 'Head of Product' 또는 '프로덕트 마케터' 같은 역할을 주면 더 구체적이고 유용한 결과를 얻을 수 있습니다. 또한 많은 컨텍스트(예: 고객의 인터뷰, 사용자의 행동 데이터, 시장 리포트 등)을 제공하는 것이 중요합니다. 마지막으로 AI를 단순한 검색 엔진으로 활용하는 것이 아니라,&nbsp;함께 아이디어를 고민하고 발전시키는 파트너로 여기고 적극적으로 대화를 이끌 수 있습니다. 이렇게 접근하면 AI의 활용이&nbsp;단지 효율성 개선 이상으로 더 나은 인사이트로 연결될 수 있을 것입니다. https://brunch.co.kr/@yongjinjinipln/227

PM의 '사고 파트너(thought partner)'로서 AI

This link will take you to a page that’s not on LinkedIn

LinkedIn

가트너 리포트 'Predicts 2025: Navigating the Rise of AI in Software Engineering'를 읽고 요약했습니다.

1️⃣ UX 채용 시장의 변화 | UX 리서치 채용공고 71%, UX 디자인 채용공고 70% 감소 (2022년 대비 Indeed 조사)

2️⃣ AI 도구의 접근성 향상 | Maze, UserTesting, Figma 등이 비전문가도 기본적인 UX 업무를 수행할 수 있게 지원

3️⃣ 개인화 기술의 발전 | 고객 데이터를 기반으로 실시간 개인화 UI를 자동 생성하는 기술 등장

4️⃣ 팀 구성의 다변화 | 엔지니어, PM, 비즈니스 분석가가 교육을 통해 UX 업무를 병행할 수 있게 됨

5️⃣ 필연적인 UX 전문가 역할의 변화 | 깊이 있는 사용자 이해, 창의적 문제 해결, 윤리적 설계 판단, 전략적 UX 기획에 집중 필요

[ 큐레이터의 문장 🎒 ]

아래 첨부한 그래프는 AI에 대한 조직의 기대치와 현실적 효용, 그 사이의 간극을 잘 보여줍니다. 파랑색 선은 Gen AI에 대한 과대광고로 인해 가파르게 상승하는 기대치를 표현합니다. 주황색 선은 현실에서 실질적으로 효용을 주는 실현 가능한 가치로 파랑색 선과 비교하면 차이가 커집니다. 기대가 현실을 앞서는 상황입니다. 많은 조직이 AI를 도입하면 자연스럽게 혁신할 수 있다고 믿습니다. 도입하지 않으면 안 될 것 같은 부담은 개인이나 조직이나 마찬가지입니다. 그런데 왜 이런 현상이 나타날까요?

가트너 분석에 따르면 몇 가지 현실적인 이유들이 AI로 인한 성과 창출을 어렵게 만듭니다.

1️⃣ 조직 구조 자체가 AI를 활용할 수 있도록 바뀌어야 합니다.
2️⃣ AI를 현재 업무에 어떻게 적용하는 것이 효과적인지 교육해야 합니다.
3️⃣ 제품 개발 전 과정에 적용하는 대신 난이도는 낮고, 임팩트는 큰 영역에 선택적으로 적용해야 합니다.
4️⃣ AI로 인한 성과 창출이 가능한 도메인과 단계를 파악하고 적절한 지표를 설정해 관리해야 합니다.

UX 분야도 마찬가지입니다. 가트너 리포트에 따르면 2027년까지 제품팀 내 UX 디자이너 인력이 40% 줄어들 겁니다. Indeed 조사에 따르면 2022년 이후 UX 리서치 채용공고는 71%, 디자이너 채용공고는 70% 감소했습니다. 현재 UX 분야에서 AI 기술은 빠르게 업무의 진입장벽을 낮추고 있고 Figma도 적극적으로 AI 기능을 적용하고 있습니다.

무엇이 변하고 있는가?

1️⃣ UX 리서치 도구의 발전 | Maze, UserTesting 같은 플랫폼이 사용자 피드백을 분석하고 인사이트를 자동으로 생성합니다.
2️⃣ UX 디자인 도구의 지능화 | Figma, Uizard의 AI가 레이아웃을 제안하고, 개발자도 전문가 수준의 프로토타입을 제작할 수 있게 됐습니다.
3️⃣ 개인화 UI 자동 생성 | 고객 데이터를 기반으로 실시간 개인화 UI를 자동 생성하는 기술이 등장했습니다.

이런 변화로 인해 엔지니어, 데이터 분석가들도 최소한의 교육만으로 쉽게 UX 리서치, 라이팅, 디자인까지 수행할 수 있는 환경이 조성되었습니다.

그래서 UX하는 사람들은 점점 줄어들까요?

여전히 인간이 고민을 주도해야 하는 영역이 있고 (AI를 활용하며) 더 효과적으로 고민할 지점이 있습니다.

1️⃣ 깊이 있는 사용자 이해 | 사용자의 말 뒤에 숨은 진짜 니즈와 맥락을 파악하는 일
2️⃣ 창의적 문제 해결 | 데이터만으로는 나올 수 없는 혁신적 솔루션을 찾는 일
3️⃣ 윤리적 설계 판단 | 기술적으로 가능해도 적용할 것인지 판단하는 일
4️⃣ 전략적 UX 기획 | 비즈니스 목표와 사용자 가치 사이의 균형점을 찾는 일

그렇다면 AI 시대에 살아남을 UX 전문가는 이런 사람들일 겁니다.

1️⃣ AI를 도구로 삼아 더 높은 차원의 문제를 빠르게 해결하는 전문가
2️⃣ 데이터로 설명하기 어려운 인간적인 관점에서 출발하는 전문가
3️⃣ 개별 화면이나 UI가 아닌 전체 경험을 설계하는 전문가

https://lnkd.in/gP3g7P4i

가트너 리포트 'Predicts 2025: Navigating the Rise of AI in Software Engineering'를 읽고 요약했습니다. 1️⃣ UX 채용 시장의 변화 | UX 리서치 채용공고 71%, UX 디자인 채용공고 70% 감소 (2022년 대비 Indeed 조사) 2️⃣ AI 도구의 접근성 향상 | Maze, UserTesting, Figma 등이 비전문가도 기본적인 UX 업무를 수행할 수 있게 지원 3️⃣ 개인화 기술의 발전 | 고객 데이터를 기반으로 실시간 개인화 UI를 자동 생성하는 기술 등장 4️⃣ 팀 구성의 다변화 | 엔지니어, PM, 비즈니스 분석가가 교육을 통해 UX 업무를 병행할 수 있게 됨 5️⃣ 필연적인 UX 전문가 역할의 변화 | 깊이 있는 사용자 이해, 창의적 문제 해결, 윤리적 설계 판단, 전략적 UX 기획에 집중 필요 [ 큐레이터의 문장 🎒 ] 아래 첨부한 그래프는 AI에 대한 조직의 기대치와 현실적 효용, 그 사이의 간극을 잘 보여줍니다. 파랑색 선은 Gen AI에 대한 과대광고로 인해 가파르게 상승하는 기대치를 표현합니다. 주황색 선은 현실에서 실질적으로 효용을 주는 실현 가능한 가치로 파랑색 선과 비교하면 차이가 커집니다. 기대가 현실을 앞서는 상황입니다. 많은 조직이 AI를 도입하면 자연스럽게 혁신할 수 있다고 믿습니다. 도입하지 않으면 안 될 것 같은 부담은 개인이나 조직이나 마찬가지입니다. 그런데 왜 이런 현상이 나타날까요? 가트너 분석에 따르면 몇 가지 현실적인 이유들이 AI로 인한 성과 창출을 어렵게 만듭니다. 1️⃣ 조직 구조 자체가 AI를 활용할 수 있도록 바뀌어야 합니다. 2️⃣ AI를 현재 업무에 어떻게 적용하는 것이 효과적인지 교육해야 합니다. 3️⃣ 제품 개발 전 과정에 적용하는 대신 난이도는 낮고, 임팩트는 큰 영역에 선택적으로 적용해야 합니다. 4️⃣ AI로 인한 성과 창출이 가능한 도메인과 단계를 파악하고 적절한 지표를 설정해 관리해야 합니다. UX 분야도 마찬가지입니다. 가트너 리포트에 따르면 2027년까지 제품팀 내 UX 디자이너 인력이 40% 줄어들 겁니다. Indeed 조사에 따르면 2022년 이후 UX 리서치 채용공고는 71%, 디자이너 채용공고는 70% 감소했습니다. 현재 UX 분야에서 AI 기술은 빠르게 업무의 진입장벽을 낮추고 있고 Figma도 적극적으로 AI 기능을 적용하고 있습니다. 무엇이 변하고 있는가? 1️⃣ UX 리서치 도구의 발전 | Maze, UserTesting 같은 플랫폼이 사용자 피드백을 분석하고 인사이트를 자동으로 생성합니다. 2️⃣ UX 디자인 도구의 지능화 | Figma, Uizard의 AI가 레이아웃을 제안하고, 개발자도 전문가 수준의 프로토타입을 제작할 수 있게 됐습니다. 3️⃣ 개인화 UI 자동 생성 | 고객 데이터를 기반으로 실시간 개인화 UI를 자동 생성하는 기술이 등장했습니다. 이런 변화로 인해 엔지니어, 데이터 분석가들도 최소한의 교육만으로 쉽게 UX 리서치, 라이팅, 디자인까지 수행할 수 있는 환경이 조성되었습니다. 그래서 UX하는 사람들은 점점 줄어들까요? 여전히 인간이 고민을 주도해야 하는 영역이 있고 (AI를 활용하며) 더 효과적으로 고민할 지점이 있습니다. 1️⃣ 깊이 있는 사용자 이해 | 사용자의 말 뒤에 숨은 진짜 니즈와 맥락을 파악하는 일 2️⃣ 창의적 문제 해결 | 데이터만으로는 나올 수 없는 혁신적 솔루션을 찾는 일 3️⃣ 윤리적 설계 판단 | 기술적으로 가능해도 적용할 것인지 판단하는 일 4️⃣ 전략적 UX 기획 | 비즈니스 목표와 사용자 가치 사이의 균형점을 찾는 일 그렇다면 AI 시대에 살아남을 UX 전문가는 이런 사람들일 겁니다. 1️⃣ AI를 도구로 삼아 더 높은 차원의 문제를 빠르게 해결하는 전문가 2️⃣ 데이터로 설명하기 어려운 인간적인 관점에서 출발하는 전문가 3️⃣ 개별 화면이나 UI가 아닌 전체 경험을 설계하는 전문가 https://lnkd.in/gP3g7P4i

lnkd.in

⟪UX 디자이너가 사라지고 있다⟫

2000년 초반부터 온톨로지 연구를 해왔고, 관심을 갖고 있는 사람으로서 GraphRAG 에 대해 갖고 있는 생각을 적어봤습니다.

1.
GraphRAG는 전통적인 RAG 기법 대비 좋은 성능을 보인다는 연구들이 보고되고 있기는 합니다만, 일단 KG(knowledge graph) 자체가 잘 구축되어 있을 것을 1차적인 전제로 한다는 면에서 허들이 있습니다. 그럼에도 최근 이 기술이 각광을 받는 것은 일반적인 자연어에 비해 정보를 구조화해서 LLM에 전달할 때의 장점이 있기 때문이라 생각합니다.

2.
그러나, knowledge graph의 구축비용이 만만치 않습니다. 도메인 전문가가 직접 구축하는 것이 기본적인 접근인데 이 비용은 두말할 것 없을 겁니다. LLM을 활용해서 구축하는 방법도 있겠지만, 어차피 다시 LLM에 입력해서 활용할 정보인데 굳이 그래프 형태로 경유해야만 하는가에 대한 의문이 생길 수 있습니다.

제 생각엔(증명해보진 못했습니다만), 정보를 자연어 문장 형태로 나열하는 방식 대비, 동일한 용어나 정보를 사용하더라도 그래프 형태로 구성되었을 때 그 구조 자체가 주는 의미적인 정보가 더 명시적으로 표현될 수 있기에 (node 간 거리 등으로), LLM의 output을 graph로 구성만 해주더라도 답변에 더 도움이 될만한 여지가 있지 않을까 싶긴 합니다.

3.
하지만 GraphRAG에서의 허들은 KG 구축비용만이 아닙니다. KG로부터 sub graph를 추출할 때 사용자 질의에 필요한 지식의 편향이 오히려 오답을 유도할 수 있기에, KG 자체를 node를 균형있게 설계하고 실제 instance 레벨에서 일정한 수준의 밀도를 유지해야 하지만 query 할 때도 이를 고려한 튜닝을 해줘야 합니다.

예컨대 한 node는 edge가 많이 연결되고 다른 node는 적거나 없을 가능성이 다분하기에, 어떤 연구에서는 node 와 edge 의 비율이 1:2.5~3.5 수준으로 유지하는 것이 좋고, graph traversal도 5~7 수준으로 유지하는 것이 좋다라고 보고하기도 했습니다. 이 정도라도 할 수 있는 수준의 KG를 갖추기도 비용이 만만치 않다는 점도 현실이지만, 만일 있다고 하더라도 저 숫자가 정답은 아닐겁니다. 말그대로 케바케죠. query 를 케바케로 튜닝해야 한다는 건 결국 비용입니다.

4.
또한 sub graph 추출은 단순히 키워드 매칭을 하는 문제가 아니라, 그래프 탐색 전략, 랭킹 알고리즘 등을 조합해서 튜닝해야 하고, 불필요한 node는 필터링해야 할 수도 있습니다. 또 그렇게 추출한 결과에서 질문에 필요한 정보가 아닌 meta 성 property들은 제거해줘야 할 수도 있고, query 결과의 문법적 요소들을 정제해줘야 할 수도 있습니다 (LLM 입장에서 noise가 될 가능성도 있고, 불필요한 token을 소모하게 된다는 점 등을 고려하면).

5.
이런 복잡성과 튜닝비용을 감수하고서라도 GraphRAG의 성능이 전통적인 RAG나 이를 개선한 여러 방법론들 대비 장점이 있는지에 대한 것은, 프로젝트 성격에 따라 신중하게 검토해야 할 문제입니다. GraphRAG가 좋다고 하니 무작정 덤빌 문제가 아니라는 뜻이죠.

2000년 초반부터 온톨로지 연구를 해왔고, 관심을 갖고 있는 사람으로서 GraphRAG 에 대해 갖고 있는 생각을 적어봤습니다. 1. GraphRAG는 전통적인 RAG 기법 대비 좋은 성능을 보인다는 연구들이 보고되고 있기는 합니다만, 일단 KG(knowledge graph) 자체가 잘 구축되어 있을 것을 1차적인 전제로 한다는 면에서 허들이 있습니다. 그럼에도 최근 이 기술이 각광을 받는 것은 일반적인 자연어에 비해 정보를 구조화해서 LLM에 전달할 때의 장점이 있기 때문이라 생각합니다. 2.그러나, knowledge graph의 구축비용이 만만치 않습니다. 도메인 전문가가 직접 구축하는 것이 기본적인 접근인데 이 비용은 두말할 것 없을 겁니다. LLM을 활용해서 구축하는 방법도 있겠지만, 어차피 다시 LLM에 입력해서 활용할 정보인데 굳이 그래프 형태로 경유해야만 하는가에 대한 의문이 생길 수 있습니다. 제 생각엔(증명해보진 못했습니다만), 정보를 자연어 문장 형태로 나열하는 방식 대비, 동일한 용어나 정보를 사용하더라도 그래프 형태로 구성되었을 때 그 구조 자체가 주는 의미적인 정보가 더 명시적으로 표현될 수 있기에 (node 간 거리 등으로), LLM의 output을 graph로 구성만 해주더라도 답변에 더 도움이 될만한 여지가 있지 않을까 싶긴 합니다. 3.하지만 GraphRAG에서의 허들은 KG 구축비용만이 아닙니다. KG로부터 sub graph를 추출할 때 사용자 질의에 필요한 지식의 편향이 오히려 오답을 유도할 수 있기에, KG 자체를 node를 균형있게 설계하고 실제 instance 레벨에서 일정한 수준의 밀도를 유지해야 하지만 query 할 때도 이를 고려한 튜닝을 해줘야 합니다. 예컨대 한 node는 edge가 많이 연결되고 다른 node는 적거나 없을 가능성이 다분하기에, 어떤 연구에서는 node 와 edge 의 비율이 1:2.5~3.5 수준으로 유지하는 것이 좋고, graph traversal도 5~7 수준으로 유지하는 것이 좋다라고 보고하기도 했습니다. 이 정도라도 할 수 있는 수준의 KG를 갖추기도 비용이 만만치 않다는 점도 현실이지만, 만일 있다고 하더라도 저 숫자가 정답은 아닐겁니다. 말그대로 케바케죠. query 를 케바케로 튜닝해야 한다는 건 결국 비용입니다. 4.또한 sub graph 추출은 단순히 키워드 매칭을 하는 문제가 아니라, 그래프 탐색 전략, 랭킹 알고리즘 등을 조합해서 튜닝해야 하고, 불필요한 node는 필터링해야 할 수도 있습니다. 또 그렇게 추출한 결과에서 질문에 필요한 정보가 아닌 meta 성 property들은 제거해줘야 할 수도 있고, query 결과의 문법적 요소들을 정제해줘야 할 수도 있습니다 (LLM 입장에서 noise가 될 가능성도 있고, 불필요한 token을 소모하게 된다는 점 등을 고려하면). 5.이런 복잡성과 튜닝비용을 감수하고서라도 GraphRAG의 성능이 전통적인 RAG나 이를 개선한 여러 방법론들 대비 장점이 있는지에 대한 것은, 프로젝트 성격에 따라 신중하게 검토해야 할 문제입니다. GraphRAG가 좋다고 하니 무작정 덤빌 문제가 아니라는 뜻이죠.

GraphRAG 에 대한 생각

[광고] 다음 직무 채용 예정입니다.

- 프러덕트/사업 기획 1인
- 프러덕트 디자인 1인
- 풀스택 웹 or 앱(RN) 개발자 1인
- 백엔드(음성 AI 에이전트) 개발자 1인

연차 무관, 인턴, 정규 모두 고려하고 있습니다.

참고로, 이번달에 시드단계로썬 상당히 좋은 투자를 받았고, 조금이지만 매출도 내고 있습니다. 업무에 AI를 매우 적극적으로 활용합니다.

자세한 팀 소개와 채용 공고는 곧 올리겠습니다. 많관부입니다. 🙇🏻🙇🏻‍♀️

회사 홈페이지 👉 https://playmore.ai

[광고] 다음 직무 채용 예정입니다. - 프러덕트/사업 기획 1인- 프러덕트 디자인 1인- 풀스택 웹 or 앱(RN) 개발자 1인- 백엔드(음성 AI 에이전트) 개발자 1인 연차 무관, 인턴, 정규 모두 고려하고 있습니다. 참고로, 이번달에 시드단계로썬 상당히 좋은 투자를 받았고, 조금이지만 매출도 내고 있습니다. 업무에 AI를 매우 적극적으로 활용합니다. 자세한 팀 소개와 채용 공고는 곧 올리겠습니다. 많관부입니다. 🙇🏻🙇🏻‍♀️ 회사 홈페이지 👉 https://playmore.ai

[광고] 다음 직무 채용 예정입니다.

- 프러덕트/사업 기획 1

쿠버네티스를 활용한 클라우드 네이티브 데브옵스 | 데브옵스를 위한 쿠버네티스 완벽 활용 가이드쿠버네티스가 표준 플랫폼으로 자리 잡은 클라우드 네이티브 세계에서 데브옵스를 실천하는 방법을 다룬다. 쿠버네티스 ……

쿠버네티스를 활용한 클라우드 네이티브 데브옵스 | 존 어런들 - 교보문고

최근, Next.js 프로젝트를 AWS EKS(Elastic Kubernetes Service)에 배포하는 경험을 했습니다.
이 과정에서 『쿠버네티스를 활용한 클라우드 네이티브 데브옵스』라는 책을 참고하며, 인프라에 대해 배운 내용을 제 방식대로 정리해봤습니다.

👨‍💻🛠️ 모든 것은 소프트웨어며 우리는 모두 엔지니어
이제는 프론트엔드 개발과 운영의 경계가 경계가 점점 사라지고 있습니다. HTML, CSS, JavaScript만 잘 다루면 됐던 시대를 지나 이제는 SSR, API 연동, 배포자동화, 모니터링 까지 고민해야 하죠.
이제 인프라도 코드로 작성하고 관리합니다.
package.json 을 다루듯, deployment.yaml, Dockerfile을 작성합니다.
결국, 인프라를 구성하는 것도 우리가 다루는 ‘코드’입니다.
그리고 코드는 바로 개발자가 잘 다루는 도구 입니다.
빠르고 안정적인 제품 전달은 특정 역할의 몫이 아니라, 모든 개발자의 책임입니다.
AI 시대에 우리는 점점 더 ‘경계를 넘는 개발자’가 되어야 합니다.
“나는 프론트만 해”라는 말보다, “이 기능을 어떻게 빠르게 사용자에게 전달하지?”라는 시야가 중요해졌습니다.
우리는 모두 ‘엔지니어’이고, 세상은 점점 더 모든 것을 ‘코드’로 표현하는 방향으로 나아가고 있으니까요.

🤖 왜 쿠버네티스인가?
비즈니스 관점에서는 “더 적게 실행하는 소프트웨어”가 중요합니다.
이 말은 꼭 적게 개발하자는 게 아니라, 이미 검증된 표준 기술을 활용해 핵심 기능에 집중하자는 의미입니다.
쿠버네티스(Kubernetes)는 그런 관점에서 사실상 인프라 관리의 표준이 되었습니다.
다수의 컨테이너를 한 번에 배포하고, 필요에 따라 스케일을 자동으로 조절해주고, 문제가 생긴 컨테이너는 알아서 다시 띄워줍니다.
프론트 기준으로 비유하자면 Turborepo가 모노레포 내에서 빌드 의존성을 분석하고, 필요한 부분만 선택적으로 빌드해주는 것처럼 쿠버네티스는 수많은 애플리케이션 인스턴스를 효율적으로 실행하고 관리해줍니다.
게다가 오토스케일링, 로드밸런싱 같은 기능도 AWS 같은 특정 클라우드에 종속되지 않고,
쿠버네티스 자체에 내장되어 있어 어떤 환경에서도 일관되게 작동합니다.
결국 우리는 인프라에 시간을 쏟기보다, 비즈니스 로직과 사용자 경험에 더 집중할 수 있게 되는 것이죠.

🧱 쿠버네티스 구조, 핵심 리소스 이해하기
쿠버네티스에서는 애플리케이션을 구성하는 요소들이 계층적으로 관리됩니다. 프론트엔드 개발자에게 익숙한 컴포넌트 트리처럼, 각각의 리소스가 어떤 역할을 하는지 이해하면 전체 구조가 훨씬 명확해집니다.
Pod
하나의 프로그램(보통 하나의 컨테이너)을 실행시키는 가장 작은 단위입니다.
프론트 기준으로 보면, 브라우저에서 하나의 탭이 하나의 페이지 앱을 띄우는 것처럼, Pod는 컨테이너 하나를 띄우는 최소 실행 단위입니다.

ReplicaSet
Pod를 몇 개 띄울지, 언제 다시 띄울지를 관리하는 리소스입니다.
마치 React에서 상태 변화를 감지해서 필요한 컴포넌트만 다시 그리는 것처럼,
ReplicaSet은 애플리케이션이 항상 원하는 수만큼 실행되도록 유지시켜줍니다.

Deployment
선언적인 방식으로 Pod와 ReplicaSet을 관리하는 상위 리소스입니다.
구조로 보면 Deployment → ReplicaSet → Pod 순서입니다.
쉽게 말해, “이 앱을 3개 실행시켜줘” 같은 요청을 코드(yaml)로 정의하고, 이 상태를 자동으로 유지하게 해주는 역할을 합니다.
Deployment는 .yaml 매니페스트로 관리되며, 실제 클러스터의 상태를 원하는 상태와 일치시키도록 쿠버네티스가 지속적으로 조율합니다.

이처럼 쿠버네티스는 복잡한 인프라 구성도 마치 컴포넌트처럼 구조화하고 선언적으로 관리할 수 있게 도와줍니다.
덕분에 인프라 변경도 코드 리뷰와 버전 관리를 통해 안전하게 수행할 수 있게 되는 거죠.

🩺 쿠버네티스의 헬스 체크
헬스 체크(Health Check)는 인프라 전반에서 널리 사용되는 개념이지만, 쿠버네티스는 이 기능을 체계화하고 자가 복구까지 연결 해 놓은 것이 큰 특징입니다. 단순히 컨테이너를 실행하는 것에 그치지 않고, 서비스가 “정상적으로 동작하는지” 판단해서 자동Pod의 응답이 없다면 그 Pod를 죽이고 새로 띄웁니다. 상태에 따라 직접 재시작 하거나 트래픽 대상에서 제외시키고 복구를 시도합니다. 즉 강력한 자가 복구를 해줍니다.
따라서 Next.js 에서는 아래와 같은 API ROUTE를 만들어줄 수 있습니다
// /pages/api/health.ts
export function GET() {
return NextResponse.json({ status: "ok" }, { status: 200 });
}

🌩️ 클라우드 네이티브 개발자?
클라우드 네이티브 개발자는, 클라우드 환경에 최적화된 방식으로 설계, 개발, 배포, 운영까지 고려하는 개발자를 말합니다.
요즘 프론트엔드는 단순한 SPA를 넘어, SSR, CSR, ISR 등 다양한 렌더링 방식에 따라 배포 전략도 달라집니다.
즉, 단순히 앱을 만드는 것뿐 아니라 어디에, 어떻게 띄우느냐"도 이제 중요한 개발의 일부가 된 것이죠.
아무리 인프라 담당자가 따로 있더라도, 도커 이미지 빌드, GitHub Actions 설정, ArgoCD로 배포 확인 및 롤백 같은 과정은 결국 프론트엔드 개발자가 직접 다루게 되는 영역입니다.
그래서 이제 프론트엔드 개발자도 클라우드 네이티브 개발자처럼 시스템 전반을 이해하고, 능동적으로 대처할 수 있는 역량이 필요해졌습니다. 단순히 UI만 잘 만드는 개발자를 넘어서, 인프라, 배포, 모니터링까지 포함한 전체 흐름을 이해해야 복잡한 문제를 "기술로 해결할 수 있는" 좀 더 나은 개발자로 성장할 수 있습니다.
이 글이 누군가에게는 그 여정을 시작하는 좋은 출발점이 되기를 바랍니다. 🙌

https://product.kyobobook.co.kr/detail/S000001810211?utm_source=google&utm_medium=cpc&utm_campaign=googleSearch&gt_network=g&gt_keyword=&gt_target_id=dsa-435935280379&gt_campaign_id=9979905549&gt_adgroup_id=132556570510&gad_source=1

최근, Next.js 프로젝트를 AWS EKS(Elastic Kubernetes Service)에 배포하는 경험을 했습니다. 이 과정에서 『쿠버네티스를 활용한 클라우드 네이티브 데브옵스』라는 책을 참고하며, 인프라에 대해 배운 내용을 제 방식대로 정리해봤습니다. 👨‍💻🛠️ 모든 것은 소프트웨어며 우리는 모두 엔지니어 이제는 프론트엔드 개발과 운영의 경계가 경계가 점점 사라지고 있습니다. HTML, CSS, JavaScript만 잘 다루면 됐던 시대를 지나 이제는 SSR, API 연동, 배포자동화, 모니터링 까지 고민해야 하죠. 이제 인프라도 코드로 작성하고 관리합니다. package.json 을 다루듯, deployment.yaml, Dockerfile을 작성합니다. 결국, 인프라를 구성하는 것도 우리가 다루는 ‘코드’입니다. 그리고 코드는 바로 개발자가 잘 다루는 도구 입니다. 빠르고 안정적인 제품 전달은 특정 역할의 몫이 아니라, 모든 개발자의 책임입니다. AI 시대에 우리는 점점 더 ‘경계를 넘는 개발자’가 되어야 합니다. “나는 프론트만 해”라는 말보다, “이 기능을 어떻게 빠르게 사용자에게 전달하지?”라는 시야가 중요해졌습니다. 우리는 모두 ‘엔지니어’이고, 세상은 점점 더 모든 것을 ‘코드’로 표현하는 방향으로 나아가고 있으니까요. 🤖 왜 쿠버네티스인가? 비즈니스 관점에서는 “더 적게 실행하는 소프트웨어”가 중요합니다. 이 말은 꼭 적게 개발하자는 게 아니라, 이미 검증된 표준 기술을 활용해 핵심 기능에 집중하자는 의미입니다. 쿠버네티스(Kubernetes)는 그런 관점에서 사실상 인프라 관리의 표준이 되었습니다. 다수의 컨테이너를 한 번에 배포하고, 필요에 따라 스케일을 자동으로 조절해주고, 문제가 생긴 컨테이너는 알아서 다시 띄워줍니다. 프론트 기준으로 비유하자면 Turborepo가 모노레포 내에서 빌드 의존성을 분석하고, 필요한 부분만 선택적으로 빌드해주는 것처럼 쿠버네티스는 수많은 애플리케이션 인스턴스를 효율적으로 실행하고 관리해줍니다. 게다가 오토스케일링, 로드밸런싱 같은 기능도 AWS 같은 특정 클라우드에 종속되지 않고, 쿠버네티스 자체에 내장되어 있어 어떤 환경에서도 일관되게 작동합니다. 결국 우리는 인프라에 시간을 쏟기보다, 비즈니스 로직과 사용자 경험에 더 집중할 수 있게 되는 것이죠. 🧱 쿠버네티스 구조, 핵심 리소스 이해하기 쿠버네티스에서는 애플리케이션을 구성하는 요소들이 계층적으로 관리됩니다. 프론트엔드 개발자에게 익숙한 컴포넌트 트리처럼, 각각의 리소스가 어떤 역할을 하는지 이해하면 전체 구조가 훨씬 명확해집니다. Pod 하나의 프로그램(보통 하나의 컨테이너)을 실행시키는 가장 작은 단위입니다. 프론트 기준으로 보면, 브라우저에서 하나의 탭이 하나의 페이지 앱을 띄우는 것처럼, Pod는 컨테이너 하나를 띄우는 최소 실행 단위입니다. ReplicaSet Pod를 몇 개 띄울지, 언제 다시 띄울지를 관리하는 리소스입니다. 마치 React에서 상태 변화를 감지해서 필요한 컴포넌트만 다시 그리는 것처럼, ReplicaSet은 애플리케이션이 항상 원하는 수만큼 실행되도록 유지시켜줍니다. Deployment 선언적인 방식으로 Pod와 ReplicaSet을 관리하는 상위 리소스입니다. 구조로 보면 Deployment → ReplicaSet → Pod 순서입니다. 쉽게 말해, “이 앱을 3개 실행시켜줘” 같은 요청을 코드(yaml)로 정의하고, 이 상태를 자동으로 유지하게 해주는 역할을 합니다. Deployment는 .yaml 매니페스트로 관리되며, 실제 클러스터의 상태를 원하는 상태와 일치시키도록 쿠버네티스가 지속적으로 조율합니다. 이처럼 쿠버네티스는 복잡한 인프라 구성도 마치 컴포넌트처럼 구조화하고 선언적으로 관리할 수 있게 도와줍니다. 덕분에 인프라 변경도 코드 리뷰와 버전 관리를 통해 안전하게 수행할 수 있게 되는 거죠. 🩺 쿠버네티스의 헬스 체크 헬스 체크(Health Check)는 인프라 전반에서 널리 사용되는 개념이지만, 쿠버네티스는 이 기능을 체계화하고 자가 복구까지 연결 해 놓은 것이 큰 특징입니다. 단순히 컨테이너를 실행하는 것에 그치지 않고, 서비스가 “정상적으로 동작하는지” 판단해서 자동Pod의 응답이 없다면 그 Pod를 죽이고 새로 띄웁니다. 상태에 따라 직접 재시작 하거나 트래픽 대상에서 제외시키고 복구를 시도합니다. 즉 강력한 자가 복구를 해줍니다. 따라서 Next.js 에서는 아래와 같은 API ROUTE를 만들어줄 수 있습니다 // /pages/api/health.ts export function GET() { return NextResponse.json({ status: "ok" }, { status: 200 }); } 🌩️ 클라우드 네이티브 개발자? 클라우드 네이티브 개발자는, 클라우드 환경에 최적화된 방식으로 설계, 개발, 배포, 운영까지 고려하는 개발자를 말합니다. 요즘 프론트엔드는 단순한 SPA를 넘어, SSR, CSR, ISR 등 다양한 렌더링 방식에 따라 배포 전략도 달라집니다. 즉, 단순히 앱을 만드는 것뿐 아니라 어디에, 어떻게 띄우느냐"도 이제 중요한 개발의 일부가 된 것이죠. 아무리 인프라 담당자가 따로 있더라도, 도커 이미지 빌드, GitHub Actions 설정, ArgoCD로 배포 확인 및 롤백 같은 과정은 결국 프론트엔드 개발자가 직접 다루게 되는 영역입니다. 그래서 이제 프론트엔드 개발자도 클라우드 네이티브 개발자처럼 시스템 전반을 이해하고, 능동적으로 대처할 수 있는 역량이 필요해졌습니다. 단순히 UI만 잘 만드는 개발자를 넘어서, 인프라, 배포, 모니터링까지 포함한 전체 흐름을 이해해야 복잡한 문제를 "기술로 해결할 수 있는" 좀 더 나은 개발자로 성장할 수 있습니다. 이 글이 누군가에게는 그 여정을 시작하는 좋은 출발점이 되기를 바랍니다. 🙌 https://product.kyobobook.co.kr/detail/S000001810211?utm_source=google&amp;utm_medium=cpc&amp;utm_campaign=googleSearch&amp;gt_network=g&amp;gt_keyword=&amp;gt_target_id=dsa-435935280379&amp;gt_campaign_id=9979905549&amp;gt_adgroup_id=132556570510&amp;gad_source=1

product.kyobobook.co.kr

Next.js 프로젝트를 AWS EKS에 배포하며 배운 것들

외국어를 사용해서? 돈을 더 많이 벌어서? 새로운 기회가 많아서? 글로벌 경력을 쌓을 수 있어서?

실제로 한국에서 일하시다가 외국으로 이직을 하신 분들께 뭐가 제일 좋으시냐고 여쭤보면 이런 답변을 자주 들어요.

"제 할 일만 할 수 있어서 너무 좋아요!"💡

참 의외죠? 😯

돌아켜보면 저도 한국에서 직장을 다닐 때는 항상 제 직무에서 벗어나는 무언가를 하느라 바빴던 것 같아요. 신입 때는 회식, 단합 대회, 송년회 등 각종 행사를 챙기느라 정신이 없었고, 올라가니 뜬금없이 위에서 긴급으로 자료를 취합해 오라는 경우가 많아서 야근이 잦았습니다. 소프트웨어 개발자인데 하루 종일 코드 한 줄 못 쓰고 엑셀 작업만 하다가 현타가 왔던 기억이 있네요 ㅋㅋ

외국에 와서는 직장에서 이런 일에 쓰는 시간이 확 줄어든 느낌인데요. 왜 그런걸까 저도 궁금해서 해외에서 다양한 직종에 종사하고 계신 한국인 분들과 이 것에 대해서 많은 대화를 나누어 보았습니다.

그 중 공통적으로 나왔던 얘기는 해외 직장에서는 중간 관리직이 이런 잡무가 아래로 내려오지 않도록 진짜 헌신적으로 일한다는 것입니다. 반면에 한국 직장에서는 상사가 일을 제대로 안 하거나 (또는 무지하거나 능력이 안 되서) 부하 직원들에게 그냥 떠 넘기는 경우가 많았다고 하시네요. 과잉 충성 때문에 오히려 불필요한 일이 생겨나기도 하고요. 이런 환경에서는 실무자들만 죽어나는 것 같습니다. ㅠㅠ

이러한 차이는 결국 연공서열에 따라 무조건 중간 관리직으로 승진시키는 한국의 기업 문화와 관련이 있지 않을까 생각해보았어요. 외국에서는 단순히 연차가 높다고 관리직에 앉히지는 않습니다. 관리직에 관심이 없는 직원들에게는 애초에 관리 업무를 주지도 않으며, 관리 역량을 성공적으로 수행할 수 있는 능력을 증명해야 관리직 역할을 유지할 수 있죠. 그래서 상대적으로 전문성을 보유한 중간 관리자가 많다고 느껴집니다.

어찌보면 우리가 직장 생활에서 원하는 것은 사실 뭐 그리 대단한 것이 아닐 수 있다는 생각이 들었습니다. 각 구성원이 자신의 역할에 맞는 일만 하게 해줄 수 있어도 훨씬 더 행복한 직장 생활이 될 수 있지 않을까요?

외국어를 사용해서? 돈을 더 많이 벌어서? 새로운 기회가 많아서? 글로벌 경력을 쌓을 수 있어서? 실제로 한국에서 일하시다가 외국으로 이직을 하신 분들께 뭐가 제일 좋으시냐고 여쭤보면 이런 답변을 자주 들어요. "제 할 일만 할 수 있어서 너무 좋아요!"💡 참 의외죠? 😯 돌아켜보면 저도 한국에서 직장을 다닐 때는 항상 제 직무에서 벗어나는 무언가를 하느라 바빴던 것 같아요. 신입 때는 회식, 단합 대회, 송년회 등 각종 행사를 챙기느라 정신이 없었고, 올라가니 뜬금없이 위에서 긴급으로 자료를 취합해 오라는 경우가 많아서 야근이 잦았습니다. 소프트웨어 개발자인데 하루 종일 코드 한 줄 못 쓰고 엑셀 작업만 하다가 현타가 왔던 기억이 있네요 ㅋㅋ 외국에 와서는 직장에서 이런 일에 쓰는 시간이 확 줄어든 느낌인데요. 왜 그런걸까 저도 궁금해서 해외에서 다양한 직종에 종사하고 계신 한국인 분들과 이 것에 대해서 많은 대화를 나누어 보았습니다. 그 중 공통적으로 나왔던 얘기는 해외 직장에서는 중간 관리직이 이런 잡무가 아래로 내려오지 않도록 진짜 헌신적으로 일한다는 것입니다. 반면에 한국 직장에서는 상사가 일을 제대로 안 하거나 (또는 무지하거나 능력이 안 되서) 부하 직원들에게 그냥 떠 넘기는 경우가 많았다고 하시네요. 과잉 충성 때문에 오히려 불필요한 일이 생겨나기도 하고요. 이런 환경에서는 실무자들만 죽어나는 것 같습니다. ㅠㅠ 이러한 차이는 결국 연공서열에 따라 무조건 중간 관리직으로 승진시키는 한국의 기업 문화와 관련이 있지 않을까 생각해보았어요. 외국에서는 단순히 연차가 높다고 관리직에 앉히지는 않습니다. 관리직에 관심이 없는 직원들에게는 애초에 관리 업무를 주지도 않으며, 관리 역량을 성공적으로 수행할 수 있는 능력을 증명해야 관리직 역할을 유지할 수 있죠. 그래서 상대적으로 전문성을 보유한 중간 관리자가 많다고 느껴집니다. 어찌보면 우리가 직장 생활에서 원하는 것은 사실 뭐 그리 대단한 것이 아닐 수 있다는 생각이 들었습니다. 각 구성원이 자신의 역할에 맞는 일만 하게 해줄 수 있어도 훨씬 더 행복한 직장 생활이 될 수 있지 않을까요?

🌎 해외에서 일하면 뭐가 좋을까요❓

AI 시대에는 개발자가 유리한가? 디자이너에게 좋은건가? 기획자는? 마케터는?

앱 개발 개척시대

AI 시대에는 개발자가 유리한가?
디자이너에게 좋은건가? 기획자는? 마케터는?

다 똑같다고 생각합니다. 모두가 같은 출발선.

제가 공부한 모든 컴퓨터 공학 지식의 가치를 0으로 설정했습니다.
맘이 좀 아프지만 이렇게 생각하니 차라리 편하기도 합니다. (다른 직군도 마찬가지일 겁니다)

서부 개척시대에서 요이땅 하고 땅따먹기를 하러 가는 느낌입니다.
누구든 먼저 땅에다 깃발을 꼽으면 그 땅을 주었던 시대.
말 한 마리만으로 달려가던 사람도 있었고 전차를 만들어서 가기도 하고 연합을 하기도 했습니다.
마냥 좋지만은 않았을 겁니다. 옆에 달려가는 사람들을 죽이기도 하고, 미리 가서 기다리고 있다가 깃발을 꼽는 등 얍삽이가 수두룩했습니다. 그래도 기회의 시대였던 것은 분명합니다.

어쩌면 이게 제 개발자 경력의 마지막은 아닐까?
나이도 들었고 함께할 연합도 없지만 제가 가진 장점들이 분명히 있을 겁니다.
이 레이스를 즐겨보려 합니다. 😁

https://jeho.page/essay/2025/06/05/at-the-app-development-race.html

AI 시대에는 개발자가 유리한가? 디자이너에게 좋은건가? 기획자는? 마케터는? 다 똑같다고 생각합니다. 모두가 같은 출발선. 제가 공부한 모든 컴퓨터 공학 지식의 가치를 0으로 설정했습니다. 맘이 좀 아프지만 이렇게 생각하니 차라리 편하기도 합니다. (다른 직군도 마찬가지일 겁니다) 서부 개척시대에서 요이땅 하고 땅따먹기를 하러 가는 느낌입니다. 누구든 먼저 땅에다 깃발을 꼽으면 그 땅을 주었던 시대. 말 한 마리만으로 달려가던 사람도 있었고 전차를 만들어서 가기도 하고 연합을 하기도 했습니다. 마냥 좋지만은 않았을 겁니다. 옆에 달려가는 사람들을 죽이기도 하고, 미리 가서 기다리고 있다가 깃발을 꼽는 등 얍삽이가 수두룩했습니다. 그래도 기회의 시대였던 것은 분명합니다. 어쩌면 이게 제 개발자 경력의 마지막은 아닐까? 나이도 들었고 함께할 연합도 없지만 제가 가진 장점들이 분명히 있을 겁니다. 이 레이스를 즐겨보려 합니다. 😁 https://jeho.page/essay/2025/06/05/at-the-app-development-race.html

K리그 프로그래머

서버엔지니어의 시대적 고민변화 : 트래픽 증가대비 장애걱정 서버는 빵빵 -> 비용압박 인스턴스 다이어트하고 장애도 함께고민 -> 구축이던 아니던 LLM먹는 하마를 어딘에 둘지? + 장애안나고 비용도 최소화

다음은 실제 활용하고 적용된 서버엔지니어링을통한 비용절감사례고민 내용으로 이것이 실패하면 오버엔지니어링으로 불리기도합니다. - 커넥션수로 장사하는 사악한 클라우드 비용정책을 방지하는 팁 포함

https://chatgpt.com/share/6839d4bf-b270-8010-96a7-510b2ff63ec3

서버엔지니어의 시대적 고민변화 : 트래픽 증가대비 장애걱정 서버는 빵빵 -&gt; 비용압박 인스턴스 다이어트하고 장애도 함께고민 -&gt; 구축이던 아니던 LLM먹는 하마를 어딘에 둘지? + 장애안나고 비용도 최소화 다음은 실제 활용하고 적용된 서버엔지니어링을통한 비용절감사례고민 내용으로 이것이 실패하면 오버엔지니어링으로 불리기도합니다. - 커넥션수로 장사하는 사악한 클라우드 비용정책을 방지하는 팁 포함 https://chatgpt.com/share/6839d4bf-b270-8010-96a7-510b2ff63ec3

서버엔지니어의 시대적 고민

1. 진통제이면서 비타민이어야 한다.

2. ’비타민이냐, 진통제냐?‘라는 질문에 굳이 대답을 해야 한다면 습관을 형성시키는 상품은 두 가지 모두에 해당된다고 할 수 있다.

3. 이런 서비스들은, 처음에는 비타민처럼 꼭 먹어야 하는 것은 아니지만 먹으면 좋은 것이었다. 그러나 일단 습관으로 굳어져버리면 진통제처럼 꼭 필요한 것이 된다.

4. 모든 생명체에게는 즐거움을 추구하고 고통을 회피하려는 본능이 있기 때문에 이것이 어떤 행동의 주된 동기유발 요인으로 작용하는 경우가 많다.

5. 불편함을 느낄 때 우리는 그런 불편한 느낌에서 벗어나고 싶어한다.

6. 습관 형성 상품은 사용자의 머릿속에서 연상작용을 일으키고 사용자들은 당신의 상품에서 고통에 대한 해결책을 발견하게 될지도 모른다.

#훅 📚

1. 진통제이면서 비타민이어야 한다. ​2. ’비타민이냐, 진통제냐?‘라는 질문에 굳이 대답을 해야 한다면 습관을 형성시키는 상품은 두 가지 모두에 해당된다고 할 수 있다. ​3. 이런 서비스들은, 처음에는 비타민처럼 꼭 먹어야 하는 것은 아니지만 먹으면 좋은 것이었다. 그러나 일단 습관으로 굳어져버리면 진통제처럼 꼭 필요한 것이 된다. ​4. 모든 생명체에게는 즐거움을 추구하고 고통을 회피하려는 본능이 있기 때문에 이것이 어떤 행동의 주된 동기유발 요인으로 작용하는 경우가 많다. ​5. 불편함을 느낄 때 우리는 그런 불편한 느낌에서 벗어나고 싶어한다. ​6. 습관 형성 상품은 사용자의 머릿속에서 연상작용을 일으키고 사용자들은 당신의 상품에서 고통에 대한 해결책을 발견하게 될지도 모른다. #훅 📚

< 서비스를 중독성 있게 만드는 결정적 원리 >

하나부터 열까지 리더가 상세히 설명해 주길 바라는 구성원이 있습니다. 반대로 큰 얼개만 듣고 나머지는 ...

다양한 구성원을 하나로 모으고 싶다면 - 리더가 가져야 할 모순

하나부터 열까지 리더가 상세히 설명해 주기를 바라는 구성원이 있습니다. 반대로 큰 얼개만 듣고 나머지는 자율적으로 하고 싶어 하는 경우도 있죠. 회식에 참여하는 것을 너무나 힘겨워 하는 구성원이 있는 반면, 동료들과 함께 시간을 보내며 가까워지는 것을 원하는 구성원도 있습니다.

주기적인 회의를 통해 서로의 업무현황을 공유하고 파악하길 원하는 경우도, 굳이 모일 필요성을 느끼지 못하는 구성원도 있고요. 문제는 이렇게 제각각인 구성원을 리더가 하나로 모아야 한다는 것입니다. 누구 한쪽을 편들지 않으면서도 한 방향으로 이끌기 위해서는 리더가 ‘따뜻한 아이스 아메리카노’가 되어야 합니다. 이게 무슨 뜻일까요?

최근 필자는 뉴질랜드 여행을 다녀왔습니다. 이 나라는 섬의 고유한 자연환경 보전을 위해 농산물 등 식품 반입에 매우 엄격한데요, 그래서 그런지 공항 곳곳에 안내 및 경고 문구가 붙어있었습니다. 필자 역시 이것을 잘 알고 있었기에 충실하게 신고서를 작성했죠.

그런데 마지막 관문에서 적발되고 말았습니다. 아침에 아이의 비상식량으로 챙겨온 사과의 존재를 까맣게 잊고 있었던 것입니다. 가방 속 사과를 발견한 세관 직원은 우리 일행을 어디론가 데려갔습니다. 무슨 일이 벌어질까 불안과 초조함을 느끼고 있을 때, 친절한 미소를 띤 직원이 다가왔습니다.

“뉴질랜드에 휴가를 보내러 왔냐?”며 말을 건네네요. 생각보다 부드러운 분위기에 “아이가 사과를 좋아해서 가방에 넣어뒀는데 깜빡 잊었다”며 선처를 바라는 눈빛을 보냈습니다. 하지만 돌아온 반응은 “안타깝다. 많이 당황스러울테니 천천히 안내문을 읽어보고 어떻게 할 건지 알려달라”는 것 뿐이었습니다.

안내문은 심플했습니다. 세관에 메일을 보내서 사정을 설명하거나, 억울하면 소송을 해도 되고, 그렇지 않으면 벌금을 내라는 것이었습니다. 더불어 실수라고 해도 고려 대상은 아니라는 말도 적혀 있었죠. 결국 현장에서 벌금을 납부하는 것으로 약 20여 분의 해프닝을 마쳤습니다.

부끄러운 경험담을 이렇게나 구구절절하게 소개하는 이유는, 이들이 보여준 모습에서 리더가 갖춰야 할 2가지를 발견했기 때문입니다. 함께 살펴볼까요?

1️⃣원칙
신고되지 않거나 허가되지 않은 품목에 대해서는 어떠한 예외도 없습니다. 이것을 비행기를 타고 내릴 때는 물론, 공항에 도착해서도 ‘눈과 귀에 박히도록’ 알려줍니다.

다양한 개성과 사고방식을 지닌 구성원들을 이끌기 위해서는 리더도 이러한 원칙을 가져야 합니다. 우리 조직의 구성원이라면 예외 없이 지켜야 하는 것이 무엇인지 정리해보세요. 함께 일하는 방식일 수도 있고, 업무 정보 공유 형태에 대한 것일 수도 있습니다.

빠른 일 처리를 중시하는 직원은 전화 통화가 당연하다고 생각할 수 있습니다. 히스토리를 남기는 것이 중요하다 여기는 직원은 문자나 이메일 소통을 선호하죠. 이건 옳고 그름의 문제가 아닙니다. 우리 조직의 업무 속성에 맞는 공동의 규칙을 갖는 게 필요합니다.

그리고 이런 원칙은 구성원들과 ‘함께’ 만드는 것이 좋습니다. 우리 조직의 ‘어떤 특성’ 때문에 이런 일하는 방식, 소통하는 방식을 운영하는지 구성원들이 납득할 수 있어야 하기 때문입니다.

그리고 이렇게 정해진 내용은 리더가 지속적으로 알려야 합니다. 잘 지키는 직원에겐 어드밴티지를, 반대의 경우엔 페널티를 주는 등 함께 만든 ‘원칙’이 문서로만 남아있지 않도록, 행동으로 옮기려는 시도를 꾸준히 하는 게 필요합니다.

2️⃣친절함
뉴질랜드 세관 직원들이 가방을 하나하나 검사하는 것은 그들의 일이기에 냉정한 태도로 할 수밖에 없습니다. 하지만 문제가 발견된 후 처리 과정에선 전혀 ‘위압감’을 느끼지 못했습니다.

사실 그들 입장에서 필자는 ‘룰을 위반한 사람’이기에 차갑게 대한들 딱히 불평할 입장은 못 되는데요. 하지만 당황한 마음을 다스릴 수 있도록 미소와 함께 말을 건네고, 일행들과 함께 대응 방법을 상의하도록 시간을 충분히 줬던 것이 참 고마웠습니다.

규칙은 지키라고 있는 것이니 이를 어기는 사람을 처벌하는 것이 당연합니다. 하지만 이때의 태도가 어떨 때는 상대의 마음을 닫아 버리기도 합니다. 그래서 리더 또한 친절할 필요가 있습니다.

원칙에 예외를 두는 방식의 관용이 아닌, 이를 지적하고 피드백하는 모습에서의 따뜻함이 중요하다는 뜻입니다. 그런데 이게 말처럼 쉽진 않습니다. 잘못을 지적하다 보면 생각보다 말이 세게 나오거나 상대를 비난하는 투가 되기 때문입니다.

이를 들은 상대방은 어떨까요? ‘내가 잘못했으니 어쩔 수 없지’라고 생각할 수도 있지만, ‘이게 그렇게까지 잘못한 건가?’라는 억울함, ‘내가 일부러 그런 것도 아닌데 너무하네!’라는 서운함이 생길지도 모릅니다. 상대가 이렇게 느끼면 피드백의 목적인 ‘행동 개선’도 어려워집니다.

필자가 이 경험을 웃으며 얘기할 수 있는 이유도 마찬가지입니다. ‘뭘 이런 것까지 잡아내 벌금을 매길까?’라는 억울함보다는, 최선을 다해 자신의 역할을 수행하면서도 당황해하는 나의 마음을 읽어줬던 뉴질랜드 세관 직원에 대한 고마움이 더 컸기 때문이 아닐까 합니다.

구성원을 대하는 리더의 태도 역시 그랬으면 좋겠습니다. 리더는 모르는 구성원 만의 속사정이 있을지도 모릅니다. 본인도 룰을 어겼다는 것을 알고 누구보다 당황하고 있을 수도 있죠. 원칙에는 엄격하되 태도는 부드러운 것.

이것이 다양한 성향의 구성원을 이끌어야 하는 ‘좋은 리더’가 갖춰야 하는 태도 아닐까요? 기준에 대한 차가움과 사람에 대한 따뜻함을 함께 가진 ‘따뜻한 아이스 아메리카노’ 같은 리더가 되시기 바랍니다.

하나부터 열까지 리더가 상세히 설명해 주기를 바라는 구성원이 있습니다. 반대로 큰 얼개만 듣고 나머지는 자율적으로 하고 싶어 하는 경우도 있죠. 회식에 참여하는 것을 너무나 힘겨워 하는 구성원이 있는 반면, 동료들과 함께 시간을 보내며 가까워지는 것을 원하는 구성원도 있습니다. 주기적인 회의를 통해 서로의 업무현황을 공유하고 파악하길 원하는 경우도, 굳이 모일 필요성을 느끼지 못하는 구성원도 있고요. 문제는 이렇게 제각각인 구성원을 리더가 하나로 모아야 한다는 것입니다. 누구 한쪽을 편들지 않으면서도 한 방향으로 이끌기 위해서는 리더가 ‘따뜻한 아이스 아메리카노’가 되어야 합니다. 이게 무슨 뜻일까요? 최근 필자는 뉴질랜드 여행을 다녀왔습니다. 이 나라는 섬의 고유한 자연환경 보전을 위해 농산물 등 식품 반입에 매우 엄격한데요, 그래서 그런지 공항 곳곳에 안내 및 경고 문구가 붙어있었습니다. 필자 역시 이것을 잘 알고 있었기에 충실하게 신고서를 작성했죠. 그런데 마지막 관문에서 적발되고 말았습니다. 아침에 아이의 비상식량으로 챙겨온 사과의 존재를 까맣게 잊고 있었던 것입니다. 가방 속 사과를 발견한 세관 직원은 우리 일행을 어디론가 데려갔습니다. 무슨 일이 벌어질까 불안과 초조함을 느끼고 있을 때, 친절한 미소를 띤 직원이 다가왔습니다. “뉴질랜드에 휴가를 보내러 왔냐?”며 말을 건네네요. 생각보다 부드러운 분위기에 “아이가 사과를 좋아해서 가방에 넣어뒀는데 깜빡 잊었다”며 선처를 바라는 눈빛을 보냈습니다. 하지만 돌아온 반응은 “안타깝다. 많이 당황스러울테니 천천히 안내문을 읽어보고 어떻게 할 건지 알려달라”는 것 뿐이었습니다. 안내문은 심플했습니다. 세관에 메일을 보내서 사정을 설명하거나, 억울하면 소송을 해도 되고, 그렇지 않으면 벌금을 내라는 것이었습니다. 더불어 실수라고 해도 고려 대상은 아니라는 말도 적혀 있었죠. 결국 현장에서 벌금을 납부하는 것으로 약 20여 분의 해프닝을 마쳤습니다. 부끄러운 경험담을 이렇게나 구구절절하게 소개하는 이유는, 이들이 보여준 모습에서 리더가 갖춰야 할 2가지를 발견했기 때문입니다. 함께 살펴볼까요? 1️⃣원칙신고되지 않거나 허가되지 않은 품목에 대해서는 어떠한 예외도 없습니다. 이것을 비행기를 타고 내릴 때는 물론, 공항에 도착해서도 ‘눈과 귀에 박히도록’ 알려줍니다. 다양한 개성과 사고방식을 지닌 구성원들을 이끌기 위해서는 리더도 이러한 원칙을 가져야 합니다. 우리 조직의 구성원이라면 예외 없이 지켜야 하는 것이 무엇인지 정리해보세요. 함께 일하는 방식일 수도 있고, 업무 정보 공유 형태에 대한 것일 수도 있습니다. 빠른 일 처리를 중시하는 직원은 전화 통화가 당연하다고 생각할 수 있습니다. 히스토리를 남기는 것이 중요하다 여기는 직원은 문자나 이메일 소통을 선호하죠. 이건 옳고 그름의 문제가 아닙니다. 우리 조직의 업무 속성에 맞는 공동의 규칙을 갖는 게 필요합니다. 그리고 이런 원칙은 구성원들과 ‘함께’ 만드는 것이 좋습니다. 우리 조직의 ‘어떤 특성’ 때문에 이런 일하는 방식, 소통하는 방식을 운영하는지 구성원들이 납득할 수 있어야 하기 때문입니다. 그리고 이렇게 정해진 내용은 리더가 지속적으로 알려야 합니다. 잘 지키는 직원에겐 어드밴티지를, 반대의 경우엔 페널티를 주는 등 함께 만든 ‘원칙’이 문서로만 남아있지 않도록, 행동으로 옮기려는 시도를 꾸준히 하는 게 필요합니다. 2️⃣친절함뉴질랜드 세관 직원들이 가방을 하나하나 검사하는 것은 그들의 일이기에 냉정한 태도로 할 수밖에 없습니다. 하지만 문제가 발견된 후 처리 과정에선 전혀 ‘위압감’을 느끼지 못했습니다. 사실 그들 입장에서 필자는 ‘룰을 위반한 사람’이기에 차갑게 대한들 딱히 불평할 입장은 못 되는데요. 하지만 당황한 마음을 다스릴 수 있도록 미소와 함께 말을 건네고, 일행들과 함께 대응 방법을 상의하도록 시간을 충분히 줬던 것이 참 고마웠습니다. 규칙은 지키라고 있는 것이니 이를 어기는 사람을 처벌하는 것이 당연합니다. 하지만 이때의 태도가 어떨 때는 상대의 마음을 닫아 버리기도 합니다. 그래서 리더 또한 친절할 필요가 있습니다. 원칙에 예외를 두는 방식의 관용이 아닌, 이를 지적하고 피드백하는 모습에서의 따뜻함이 중요하다는 뜻입니다. 그런데 이게 말처럼 쉽진 않습니다. 잘못을 지적하다 보면 생각보다 말이 세게 나오거나 상대를 비난하는 투가 되기 때문입니다. 이를 들은 상대방은 어떨까요? ‘내가 잘못했으니 어쩔 수 없지’라고 생각할 수도 있지만, ‘이게 그렇게까지 잘못한 건가?’라는 억울함, ‘내가 일부러 그런 것도 아닌데 너무하네!’라는 서운함이 생길지도 모릅니다. 상대가 이렇게 느끼면 피드백의 목적인 ‘행동 개선’도 어려워집니다. 필자가 이 경험을 웃으며 얘기할 수 있는 이유도 마찬가지입니다. ‘뭘 이런 것까지 잡아내 벌금을 매길까?’라는 억울함보다는, 최선을 다해 자신의 역할을 수행하면서도 당황해하는 나의 마음을 읽어줬던 뉴질랜드 세관 직원에 대한 고마움이 더 컸기 때문이 아닐까 합니다. 구성원을 대하는 리더의 태도 역시 그랬으면 좋겠습니다. 리더는 모르는 구성원 만의 속사정이 있을지도 모릅니다. 본인도 룰을 어겼다는 것을 알고 누구보다 당황하고 있을 수도 있죠. 원칙에는 엄격하되 태도는 부드러운 것. 이것이 다양한 성향의 구성원을 이끌어야 하는 ‘좋은 리더’가 갖춰야 하는 태도 아닐까요? 기준에 대한 차가움과 사람에 대한 따뜻함을 함께 가진 ‘따뜻한 아이스 아메리카노’ 같은 리더가 되시기 바랍니다.

네이버 블로그 | HSG 휴먼솔루션그룹

하나부터 열까지 리더가 상세히 설명해 주기를 바라는 구성원이 있습

AWS는 어쩌다가 클라우드 서비스를 시작하게 되었을까
Git은 어떻게 만들어졌을까
19금 사이트 개발은 어떤 사람들이 하는 걸까

개발자로 살면서, 한번쯤 들었을 법한 의문들에 대해서 팟캐스트를 만들어서 올려보고 있습니다 (AI로...)

많은 관심 부탁드립니다! 🤗
https://www.youtube.com/@Beedio_pyeongbee

AWS는 어쩌다가 클라우드 서비스를 시작하게 되었을까 Git은 어떻게 만들어졌을까 19금 사이트 개발은 어떤 사람들이 하는 걸까 개발자로 살면서, 한번쯤 들었을 법한 의문들에 대해서 팟캐스트를 만들어서 올려보고 있습니다 (AI로...) 많은 관심 부탁드립니다! 🤗https://www.youtube.com/@Beedio_pyeongbee

개발자 교양 팟캐스트

With the design overhaul that's coming this year, Apple plans to rename all of its operating systems, reports Bloomberg. Going forward, iOS,...

No iOS 19: Apple Going Straight to iOS 26

매년 iOS 버전은 하나씩 업데이트 되고 있습니다.
그러다보니 현재는 iOS 18이 최신인데, 올해부터는 연도를 나타내는 iOS 26으로 바뀔거라는 소식이 있어요 😃

사실 연도를 따라가면 헷갈리지 않아서 좋긴한데, 조금 더 나아가서 Xcode, iPhone OS 버전들도 같이 통일해주면 더 헷갈리지 않을것 같습니다.
개발할 때 매번 이 세가지의 버전이 늘 헷갈리더라구요.

그러면, Xcode 몇 버전에서는 최신 iOS 몇 버전까지 지원되고 그런것들에서 해방될 수 있지 않을까 생각해봅니다 ☺️

매년 iOS 버전은 하나씩 업데이트 되고 있습니다.그러다보니 현재는 iOS 18이 최신인데, 올해부터는 연도를 나타내는 iOS 26으로 바뀔거라는 소식이 있어요 😃 사실 연도를 따라가면 헷갈리지 않아서 좋긴한데, 조금 더 나아가서 Xcode, iPhone OS 버전들도 같이 통일해주면 더 헷갈리지 않을것 같습니다.개발할 때 매번 이 세가지의 버전이 늘 헷갈리더라구요. 그러면, Xcode 몇 버전에서는 최신 iOS 몇 버전까지 지원되고 그런것들에서 해방될 수 있지 않을까 생각해봅니다 ☺️

MacRumors

iOS 19가 아니라 이제 iOS 26?

미국 하버드 대학교(Harvard University) 컴퓨터 사이언스 CS50 자격증 취득✌️ 취득후 엊그제 정식 증명서 받았다묘ㅎㅎ

미국 하버드 대학교(Harvard University) 컴퓨터 사이언스 CS50 자격증 취득✌️ 취득후 엊그제 정식 증명서 받았다묘ㅎㅎ

하버드 대학교(Harvard University) CS50 자격증취득✌️

코딩바비

👸🏻@sarangkang_
👩🏻‍💻iOS Developer 
👙Bikini Competitor 
🧘🏻‍♀️Pilates Instructor


하버드 대학교(Harvard University) CS50 자격증취득✌️

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필