안녕하세요. 월급쟁이부자들(이하 ‘월부’)에서 프론트엔드 챕터 리드를 맡고 있는 염승엽, 닉네임 카일입니다.
월부는 “월급쟁이에게 내 집 마련과 행복한 노후를 돕는다”는 미션 아래,
더 나은 삶을 고민하는 분들에게 실질적인 도움이 되는 서비스를…

모던 데이터 파이프라인 구축기: 레거시를 넘어

오래된 집에서 배관 누수가 발생하면 배관공이 필요하듯,
오래된 소프트웨어에도 레거시가 발생하면
엔지니어링이 필요합니다.

현대 사회의 많은 소프트웨어는
마치 하나의 기계와 같은
복합적이고 체계적인 구조를 가지고 있습니다.

이런 구조를 이해하고 필요한 구성요소를 개선하거나 새롭게 만드는 일을
’레거시 모더나이제이션 (Legacy Modernization)’이라고 부릅니다.

해당 아티클은 클라우드 인프라인 AWS와 GCP를 결합하여
더 쉽게 이해 가능하고,
더 관리가 수월하며,
필요시 확장 가능한 구조를 만드는 과정을 보여주고 있습니다.

클라우드 시스템을 하나의 시스템만 사용하는 것이 아닌,
두 가지 이상을 결합하는 하이브리드형 구조를
만든 것이 인상적이였습니다.

AWS의 마이크로 서비스와 GCP의 마이크로 서비스들이
파이프라인 내에서 각자
어떤 역할을 하는지를 알아보는 재미도 있었구요.

데이터 엔지니어/분석형 엔지니어를 꿈꾸는 분들에게
현대적인 데이터 파이프라인이란 어떤 것이고,
전체적인 데이터 플로우를 파악할 수 있게 도와주는 아티클이니
꼭 한번 읽어보시길 추천드립니다 :)

오래된 집에서 배관 누수가 발생하면 배관공이 필요하듯, 오래된 소프트웨어에도 레거시가 발생하면 엔지니어링이 필요합니다. 현대 사회의 많은 소프트웨어는 마치 하나의 기계와 같은 복합적이고 체계적인 구조를 가지고 있습니다. 이런 구조를 이해하고 필요한 구성요소를 개선하거나 새롭게 만드는 일을 ’레거시 모더나이제이션 (Legacy Modernization)’이라고 부릅니다. 해당 아티클은 클라우드 인프라인 AWS와 GCP를 결합하여 더 쉽게 이해 가능하고, 더 관리가 수월하며, 필요시 확장 가능한 구조를 만드는 과정을 보여주고 있습니다. 클라우드 시스템을 하나의 시스템만 사용하는 것이 아닌, 두 가지 이상을 결합하는 하이브리드형 구조를 만든 것이 인상적이였습니다. AWS의 마이크로 서비스와 GCP의 마이크로 서비스들이 파이프라인 내에서 각자 어떤 역할을 하는지를 알아보는 재미도 있었구요. 데이터 엔지니어/분석형 엔지니어를 꿈꾸는 분들에게 현대적인 데이터 파이프라인이란 어떤 것이고, 전체적인 데이터 플로우를 파악할 수 있게 도와주는 아티클이니 꼭 한번 읽어보시길 추천드립니다 :)

Medium

엔지니어링의 핵심, 유지 보수가 가능한 파이프라인 구성하기

WWDC 2025 감상. 애플은 여전히 진짜 필요한 걸 잘 만드는구나. 엄청난게 아니라, 별거 아닌 것 같지만 사람들이 매일 필요로 하는 걸 정말 잘 찾아서 제대로 만든다. 스티브 잡스가 떠난지 강산이 한 번 바뀐 시간 이후에도 계속 이렇게 하는게 대단하다는 생각도 들고, 뭔가 좌절스럽기도 하고.. 🫠

WWDC 2025 감상. 애플은 여전히 진짜 필요한 걸 잘 만드는구나. 엄청난게 아니라, 별거 아닌 것 같지만 사람들이 매일 필요로 하는 걸 정말 잘 찾아서 제대로 만든다. 스티브 잡스가 떠난지 강산이 한 번 바뀐 시간 이후에도 계속 이렇게 하는게 대단하다는 생각도 들고, 뭔가 좌절스럽기도 하고.. 🫠

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

발이 닿지 않는 바다에서

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

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

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

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

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

hajoeun.com

디자이너의 바이브 코딩 도전기 – 산다가계부 제작기 | 코딩을 전혀 모르는 디자이너가 정말 앱을 출시할 수 있을까?  이 질문에 답하기 위해 한 달 반 동안 Cursor AI와 함께 앱을 개발해봤다. 결과는? 내가 매일 쓸 만한 수준의 가계부 앱을 만들 수 있었고, 지금은 앱스토어에서 누구나 다운로드할 수 있다.   ➜ 산다가계부 플랫폼: iOS (React Native+ expo)개발 기간: 6주 (실험 1주

디자이너도 앱을 만들 수 있을까?

이 궁금증에서 시작해,한 달반 동안 Cursor AI와 함께 입을 개발해본 결과는? 매일 사용할 만큼 쓸만한 가계부 입을 만들고 배포까지 가능했어요.

기획부터 디자인, 개발까지 모두 혼자 진행했고, 개발은 Cursor AI와 ChatGPT의 도움을 받았어요. 개발부터 출시까지의 과정을 정리한 글이에요.

이 궁금증에서 시작해,한 달반 동안 Cursor AI와 함께 입을 개발해본 결과는? 매일 사용할 만큼 쓸만한 가계부 입을 만들고 배포까지 가능했어요. 기획부터 디자인, 개발까지 모두 혼자 진행했고, 개발은 Cursor AI와 ChatGPT의 도움을 받았어요. 개발부터 출시까지의 과정을 정리한 글이에요.

Brunch Story

👋 디자이너도 앱을 만들 수 있을까?

* 이 글은  "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

‘윌라슨의 엔지니어링 리더십’은 엔지니어링 조직의 리더, 즉 CTO, VP of Engineering, Director 등 초보(?) 기술 임원 리더들을 위한 안내서이다. 개인적으로는 국내의 개발자/엔지니어 출신의 임원들이 쓴 책을 더 선호하는 편인데, 미국의 사례라서 국내 상황과는 다소 맥락상 차이가 있는 부분들도 분명 있어 보인다. 그럼에도 불구하고,  단순한 기술 관리서가 아니라, 엔지니어링 조직의 리더가 반드시 알아야 할 실질적 리더십, 문화, 전략, 인사, 변화 관리까지 폭넓게 다루는 실전 지침서이다.

또한, 조직 구조 설계, 문화 조성, 성과 측정, 리더십 스타일 등 다양한 주제를 체계적으로 다루며, 엔지니어링 리더뿐만 아니라 모든 테크 조직의 리더에게 통찰을 제시한다.  특히, “문제를 해결하는 조직을 만드는 것”이라는 리더십의 본질, 불완전함을 인정하고 소통과 학습을 중시하는 태도, 상황에 맞는 유연한 리더십의 중요성 등은 오늘날 빠르게 성장하는 기술 조직에 꼭 필요한 메시지이다. 

특히, 좋았던 부분은 저자가 경험했던 여러 회사들 - 우버, 스트라이프, 캄등에서의 경험뿐만 아니라 아마존,  와이컴비네이터등의 다양한 회사에서 적용한 사례들이나 지침, 가이드등을 제시해주어서 보다 더 현실적으로 이해할 수 있도록 해준다.

이 책은 초보 기술임원이 면접시에는 어떤 것을 고려해야하며, 면접 프로세스는 어떻게 시작하는지로  시작해서 기술 임원으로 온보딩을 거쳐 기술조직의 미션과 전략을 세우고, 내부 소통 및 조직의 브랜딩을 어떻게 해야하며, 어느 시기에 퇴사를 결정하고 어떤 방식으로 진행해야하는지 아래와 같이총 24개의 목차로 구성되어 있다.
 * Chapter 01. 임원직을 향한 여정
 * Chapter 02.엔지니어링 임원의 첫 90일
 * Chapter 03.엔지니어링 전략 세우기
 * Chapter 04.계획하는 방법
 * Chapter 05.유용한 조직 가치 창출하기
 * Chapter 06.엔지니어링 조직 평가하기
 * Chapter 07.인수 합병에 참여하기
 * Chapter 08.리더십 스타일 개발하기
 * Chapter 09.우선순위와 에너지 관리하기
 * Chapter 10.효과적인 엔지니어링 조직을 위한 회의
 * Chapter 11.내부 소통
 * Chapter 12.개인 및 조직의 브랜드 구축하기
 * Chapter 13.CEO, 동료 및 엔지니어링 조직과 협력하기
 * Chapter 14.엔지니어링 리더십 팀 결속시키기
 * Chapter 15.네트워크 구축하기
 * Chapter 16.동료 임원 온보딩 프로그램
 * Chapter 17.신뢰 검증하기
 * Chapter 18.자신만의 기준 정하기
 * Chapter 19.엔지니어링 프로세스의 종류와 실행 방법
 * Chapter 20.채용
 * Chapter 21.엔지니어링 조직 온보딩
 * Chapter 22.성과 및 보상
 * Chapter 23.조직 문화 설문 조사 데이터 활용하기
 * Chapter 24.퇴사하기

내용이 상당히 방대(?)한 편이라서 내용 중 공감되었던 부분들과 나의 경험을 비교해 볼 수 있었다.

우선, 보통 온보딩 기간이라고 하는 입사해서 3개월, 90일,안에 기술임원으로 다음과 같은 내용들을 파악하고 준비할 필요가 있다는 부분은 매우 공감하면서도 현실적으로 국내회사에서 실제 해 볼 수 있을까 궁금하기도 하다.
 * CEO나 CTO같은 관리자에게 본인에게 기대하는 역할을 문서로 명확히 작성해 달라고 하세요 > 과연 새로 입사한 초보 임원 입장에서 이런 요청을 하기가 쉬울까? 아쉽지만 글로벌 스타일(?)일 일거 같다. 그런데, 정말 필요하다고 생각한다.
 * 구성원들의 목소리를 들으세요 > 매우 공감하는 영역이다. 특히, 30명 미만의 구성원이라면 모두를 개별적으로 만다는 것을 목표로 할 필요가 있다는 것이다.
 * 임원 코치를 고용하세요 > 굉장히 바람직하고 좋은 내용중이 하나라고 생각하는데, 시스템 체계와 재무적인 여유가 있어 인재들의 성장을 지원하는 기업들이라면 가능할 것 같기는 한다.
 * 업무수행 체계 측면에서 엔지니어링 작업속도의 내부 측정 기준 설정과 외부 측정 기준 설정의 예제나 참고할 만한 사례를 제시했다면 더 좋았을거 같다.

전략 부문에 있어서 전략 초안 작성을 위해서 회사의 재무 관련 사항들 - 현금 흐름 목표, 투자 논리, 인수 합병 목적 -과 현재의 유통 메커니즘은 무엇인지, 현재 전략에서 작동하지 않는 부분은 무엇인지까지 고려하는 부문은 상당히 인상적이었다. 이 정도의 내용까지 고려한 전략을 만들 수 있는 기술임원을 둔 회사는 정말 잘 나갈것이라고 생각한다 🙂

또한, 엔지니어링 비용을 자본화하는 방법에 있어 다음의 세가지 접근 방식을 사용해 볼 수 있다는 부분 또한 굉장히 인상적이었다.

또하나 인상적인 부분중에 하나는 ‘Chatper07의 인수합병에 참여하기’였었다. 다른 부서들과 달리 엔지니어링 조직은 인수가 완료된 후에도 인수된 제품의 통합과 운영을 주도해야하기에 더 많은 고려사항들과 계획, 인센티브등의 보상등이 고려되어야 한다는 것이다. 인수가 확정된 이후 엔지니어링 평가 템플리셍서 다뤄야 할 항목은 매우 흥미롭다.
 * 제품 구현
 * 지식 재산권
 * 보안
 * 규정 준수
 * 기술 스랙 및 인프라 통합 불일치
 * 비용 및 확장성
 * 엔지니어링 조직 문화: 인수합병시에 가장 힘든부분이 이것이 아닐까 싶다. 어째튼 인수합병의 기술수장으로써 가장 신경써야할 부분중에 하나일 것이다.

그리고,  보통 리더십 관련하여 Boss가 과거의 전형적인 형태의 리더십이었다면, 지금의 리더는 솔선수범하고, 고통과 업무를 함께하는 리더십을 선호하는게 사실이다. 
 그런데, Boss 스타일이 무조건적으로 나쁘고, 고루하다고만 볼 수는 없다. 짧은 시간내에 불확실한 상황하에서 빠른 의사결정이 필요한 경우 명확한 목표를 제시하고 진행해야 하는 경우는 이런 카리스마적인 보스 스타일의 리더십이 필요하기도 하다. 실제 IMF나 금융경제위기 상황에서 많은 기업들의 리더들의 스타일이 이런 카리스마를 가진 보스 스타일의 임원들에 의한 기업 경영을 한 경우를 많이 볼 수 있었다. 

 다른 한편으로는 회사의 목표와 개인의 성과 목표를 제시하고 결부시키면서 개인의 성장과 발전을 함께 도모하는 민주적인 코치형 리더를 많이 선호하기도 하다. 물론, 이런 경우의 리더는 해당 분야에 대한 전문성과 많은 경험을 가지고 있을수록 이러한 선도형 리더로써 충분한 역량과 경험을 보여 줄 수 있다. 

그래서, 윌 라슨의 말처럼 “리더십은 정답이 아니라, 맥락 속에서 최선의 답을 찾는 과정이다.”라는게 정답일수 있을거 같다.

그리고, 이 책에서는 조직내 많은 사람들이 일관되게 내려야 하는 반복적인 의사결정에 적합한 정책기반 리더십과 여러 이해관계자가 얽혀 있는 상황에서 가끔 내리는 의사결정에 적합한 합의기반 리더십, 그리고 관련된 사람들이 명확한 제안 없이 서로 심하게 대립하거나 조직에 장기적이고 큰 영향을 미치는 의사결정에 적합한 확신기반 리더십의 세가지 리더십을 다양한 상황에서 적절하게 모두 사용해야함을 제시한다.

가장 관심이 많은 분야이기도 했던 성과와 보상 중 강등에 대한 제시는 새로웠다. 가능하면, 모든 직원들이나 팀원들에 대한 좋은 평가와 승진을 시켜주고 싶은 것이 모든 리더들의 희망일 것이다. 그러나, 현실에는 어째튼 상대적인 평가와 이에 따른 보상과 승진등이 이루어지고 있는 것이 사실이다. 그리고, 필요에 따라서는 강등이 이루어지기도 하지만, 이를 결정해야하는 임원이나 리더 임장에서는 심적인 고뇌와 번민이 되는 것도 사실이다. 이러한 강등이나 PIP가 이루어지는 경우 대개 해당 직원은 퇴사를 하는 경우가 많은게 현실이다. 어째튼 여기에서는 세가지 형태의 강등을 제시한다.
 * 보상도 같이 조정이 있는 강등
 * 직급이 내려가면 주식보상등도 조정이 필요하나 조정하는 과정이 쉽지는 않다
 * 보상 조정이 없는 강등
 * 직급이 내려가지만 보상은 기존 수준을 유지하는 경우이다.
 * 레벨 조정 없이 직급만 강등
 * 직급은 내려가지만 레벨은 유지되고, 보상도 그래도 유지되는 경우이다.

마지막으로 퇴사와 관련하여, 기술임원이 정체성과 불만의 교차로에서서 퇴사 여부를 결정하는데 다음과 같은 네가지 질문이 있다고 한다. 물론, 아래의 질문 이외에도 사실 퇴사를 자의반 타의반으로 하는게 임원들의 현실이기도 하다. 특히, 국내에서는 CEO 또는 CFO와의 갈등, 새로운 CEO가 본인과 코드가 맞는 임원을 데려오기 위해 무리한 요구사항들을 던지는 경우, 회사의 급작스런 정책이나 비지니스 방향성 변경에 따른 조직 해체/축소등의 경우에 더 많은  퇴사를 하는 것을 보아온 나로써는 아래와 같은 관점은 매우 약한 퇴사 동기질문으로 보여서 아쉬웠다. 
 * 배움의 속도가 현저히 줄어들었는가?
 * 일이 지속적으로 에너지를 소진시키는가?
 * 팀에 합류할 후보자를 진정성 있게 설득할 수 있는가?
 * 6개월 후에 떠나는 것이 지금 떠나는 것보다 더 큰 피해를 주는가?

주요 내용 이외에도 Appendix로 임운 기초지식이나 엔지니어링 임원 인터뷰 관련 사항들, 손익계산서 읽기, 엔지니어링 허브 만들기, 기술 탐색의 규모, 그리고, 특별부록으로써 국내 9인의 CTO이야기 또한 흥미롭게 볼 수 있는 부분이었다. 국내 CTO 몇분은 같이 근무하거나 함께 업무를 하셨던 분들도 있었는데, 이런 얘기는 별로 못해봤었는데, 그분들을 새롭게 보는 계기가 되기도 하였다.

요컨대, 이 책은 기술임원을 목표로 하는데 어떻게 해야하는지 주위에 선배나 멘토가 없거나 가이드가 필요한 중간관리자들뿐만 아니라 기술과 경영의 접점에서 고민하는 모든 이들에게 자신있게 추천할만한 책이다.

* 이 글은&nbsp; "한빛미디어 &lt;나는 리뷰어다&gt; 활동을 위해서 책을 제공받아 작성된 서평입니다." ‘윌라슨의 엔지니어링 리더십’은 엔지니어링 조직의 리더, 즉 CTO, VP of Engineering, Director 등 초보(?) 기술 임원 리더들을 위한 안내서이다. 개인적으로는 국내의 개발자/엔지니어 출신의 임원들이 쓴 책을 더 선호하는 편인데, 미국의 사례라서 국내 상황과는 다소 맥락상 차이가 있는 부분들도 분명 있어 보인다. 그럼에도 불구하고,&nbsp; 단순한 기술 관리서가 아니라, 엔지니어링 조직의 리더가 반드시 알아야 할 실질적 리더십, 문화, 전략, 인사, 변화 관리까지 폭넓게 다루는 실전 지침서이다. 또한, 조직 구조 설계, 문화 조성, 성과 측정, 리더십 스타일 등 다양한 주제를 체계적으로 다루며, 엔지니어링 리더뿐만 아니라 모든 테크 조직의 리더에게 통찰을 제시한다.&nbsp; 특히, “문제를 해결하는 조직을 만드는 것”이라는 리더십의 본질, 불완전함을 인정하고 소통과 학습을 중시하는 태도, 상황에 맞는 유연한 리더십의 중요성 등은 오늘날 빠르게 성장하는 기술 조직에 꼭 필요한 메시지이다.&nbsp; 특히, 좋았던 부분은 저자가 경험했던 여러 회사들 - 우버, 스트라이프, 캄등에서의 경험뿐만 아니라 아마존,&nbsp; 와이컴비네이터등의 다양한 회사에서 적용한 사례들이나 지침, 가이드등을 제시해주어서 보다 더 현실적으로 이해할 수 있도록 해준다. 이 책은 초보 기술임원이 면접시에는 어떤 것을 고려해야하며, 면접 프로세스는 어떻게 시작하는지로&nbsp; 시작해서 기술 임원으로 온보딩을 거쳐 기술조직의 미션과 전략을 세우고, 내부 소통 및 조직의 브랜딩을 어떻게 해야하며, 어느 시기에 퇴사를 결정하고 어떤 방식으로 진행해야하는지 아래와 같이총 24개의 목차로 구성되어 있다.<ul ><li>Chapter 01. 임원직을 향한 여정</li><li>Chapter 02.엔지니어링 임원의 첫 90일</li><li>Chapter 03.엔지니어링 전략 세우기</li><li>Chapter 04.계획하는 방법</li><li>Chapter 05.유용한 조직 가치 창출하기</li><li>Chapter 06.엔지니어링 조직 평가하기</li><li>Chapter 07.인수 합병에 참여하기</li><li>Chapter 08.리더십 스타일 개발하기</li><li>Chapter 09.우선순위와 에너지 관리하기</li><li>Chapter 10.효과적인 엔지니어링 조직을 위한 회의</li><li>Chapter 11.내부 소통</li><li>Chapter 12.개인 및 조직의 브랜드 구축하기</li><li>Chapter 13.CEO, 동료 및 엔지니어링 조직과 협력하기</li><li>Chapter 14.엔지니어링 리더십 팀 결속시키기</li><li>Chapter 15.네트워크 구축하기</li><li>Chapter 16.동료 임원 온보딩 프로그램</li><li>Chapter 17.신뢰 검증하기</li><li>Chapter 18.자신만의 기준 정하기</li><li>Chapter 19.엔지니어링 프로세스의 종류와 실행 방법</li><li>Chapter 20.채용</li><li>Chapter 21.엔지니어링 조직 온보딩</li><li>Chapter 22.성과 및 보상</li><li>Chapter 23.조직 문화 설문 조사 데이터 활용하기</li><li>Chapter 24.퇴사하기</li></ul> 내용이 상당히 방대(?)한 편이라서 내용 중 공감되었던 부분들과 나의 경험을 비교해 볼 수 있었다. 우선, 보통 온보딩 기간이라고 하는 입사해서 3개월, 90일,안에 기술임원으로 다음과 같은 내용들을 파악하고 준비할 필요가 있다는 부분은 매우 공감하면서도 현실적으로 국내회사에서 실제 해 볼 수 있을까 궁금하기도 하다.<ul ><li>CEO나 CTO같은 관리자에게 본인에게 기대하는 역할을 문서로 명확히 작성해 달라고 하세요 &gt; 과연 새로 입사한 초보 임원 입장에서 이런 요청을 하기가 쉬울까? 아쉽지만 글로벌 스타일(?)일 일거 같다. 그런데, 정말 필요하다고 생각한다.</li><li>구성원들의 목소리를 들으세요 &gt; 매우 공감하는 영역이다. 특히, 30명 미만의 구성원이라면 모두를 개별적으로 만다는 것을 목표로 할 필요가 있다는 것이다.</li><li>임원 코치를 고용하세요 &gt; 굉장히 바람직하고 좋은 내용중이 하나라고 생각하는데, 시스템 체계와 재무적인 여유가 있어 인재들의 성장을 지원하는 기업들이라면 가능할 것 같기는 한다.</li><li>업무수행 체계 측면에서 엔지니어링 작업속도의 내부 측정 기준 설정과 외부 측정 기준 설정의 예제나 참고할 만한 사례를 제시했다면 더 좋았을거 같다.</li></ul> 전략 부문에 있어서 전략 초안 작성을 위해서 회사의 재무 관련 사항들 - 현금 흐름 목표, 투자 논리, 인수 합병 목적 -과 현재의 유통 메커니즘은 무엇인지, 현재 전략에서 작동하지 않는 부분은 무엇인지까지 고려하는 부문은 상당히 인상적이었다. 이 정도의 내용까지 고려한 전략을 만들 수 있는 기술임원을 둔 회사는 정말 잘 나갈것이라고 생각한다 🙂 또한, 엔지니어링 비용을 자본화하는 방법에 있어 다음의 세가지 접근 방식을 사용해 볼 수 있다는 부분 또한 굉장히 인상적이었다. 또하나 인상적인 부분중에 하나는 ‘Chatper07의 인수합병에 참여하기’였었다. 다른 부서들과 달리 엔지니어링 조직은 인수가 완료된 후에도 인수된 제품의 통합과 운영을 주도해야하기에 더 많은 고려사항들과 계획, 인센티브등의 보상등이 고려되어야 한다는 것이다. 인수가 확정된 이후 엔지니어링 평가 템플리셍서 다뤄야 할 항목은 매우 흥미롭다.<ul ><li>제품 구현</li><li>지식 재산권</li><li>보안</li><li>규정 준수</li><li>기술 스랙 및 인프라 통합 불일치</li><li>비용 및 확장성</li><li>엔지니어링 조직 문화: 인수합병시에 가장 힘든부분이 이것이 아닐까 싶다. 어째튼 인수합병의 기술수장으로써 가장 신경써야할 부분중에 하나일 것이다.</li></ul> 그리고,&nbsp; 보통 리더십 관련하여 Boss가 과거의 전형적인 형태의 리더십이었다면, 지금의 리더는 솔선수범하고, 고통과 업무를 함께하는 리더십을 선호하는게 사실이다.&nbsp;&nbsp;그런데, Boss 스타일이 무조건적으로 나쁘고, 고루하다고만 볼 수는 없다. 짧은 시간내에 불확실한 상황하에서 빠른 의사결정이 필요한 경우 명확한 목표를 제시하고 진행해야 하는 경우는 이런 카리스마적인 보스 스타일의 리더십이 필요하기도 하다. 실제 IMF나 금융경제위기 상황에서 많은 기업들의 리더들의 스타일이 이런 카리스마를 가진 보스 스타일의 임원들에 의한 기업 경영을 한 경우를 많이 볼 수 있었다.&nbsp; &nbsp;다른 한편으로는 회사의 목표와 개인의 성과 목표를 제시하고 결부시키면서 개인의 성장과 발전을 함께 도모하는 민주적인 코치형 리더를 많이 선호하기도 하다. 물론, 이런 경우의 리더는 해당 분야에 대한 전문성과 많은 경험을 가지고 있을수록 이러한 선도형 리더로써 충분한 역량과 경험을 보여 줄 수 있다.&nbsp; 그래서, 윌 라슨의 말처럼 “리더십은 정답이 아니라, 맥락 속에서 최선의 답을 찾는 과정이다.”라는게 정답일수 있을거 같다. 그리고, 이 책에서는 조직내 많은 사람들이 일관되게 내려야 하는 반복적인 의사결정에 적합한 정책기반 리더십과 여러 이해관계자가 얽혀 있는 상황에서 가끔 내리는 의사결정에 적합한 합의기반 리더십, 그리고 관련된 사람들이 명확한 제안 없이 서로 심하게 대립하거나 조직에 장기적이고 큰 영향을 미치는 의사결정에 적합한 확신기반 리더십의 세가지 리더십을 다양한 상황에서 적절하게 모두 사용해야함을 제시한다. 가장 관심이 많은 분야이기도 했던 성과와 보상 중 강등에 대한 제시는 새로웠다. 가능하면, 모든 직원들이나 팀원들에 대한 좋은 평가와 승진을 시켜주고 싶은 것이 모든 리더들의 희망일 것이다. 그러나, 현실에는 어째튼 상대적인 평가와 이에 따른 보상과 승진등이 이루어지고 있는 것이 사실이다. 그리고, 필요에 따라서는 강등이 이루어지기도 하지만, 이를 결정해야하는 임원이나 리더 임장에서는 심적인 고뇌와 번민이 되는 것도 사실이다. 이러한 강등이나 PIP가 이루어지는 경우 대개 해당 직원은 퇴사를 하는 경우가 많은게 현실이다. 어째튼 여기에서는 세가지 형태의 강등을 제시한다.<ul ><li>보상도 같이 조정이 있는 강등<ul ><li>직급이 내려가면 주식보상등도 조정이 필요하나 조정하는 과정이 쉽지는 않다</li></ul></li><li>보상 조정이 없는 강등<ul ><li>직급이 내려가지만 보상은 기존 수준을 유지하는 경우이다.</li></ul></li><li>레벨 조정 없이 직급만 강등<ul ><li>직급은 내려가지만 레벨은 유지되고, 보상도 그래도 유지되는 경우이다.</li></ul></li></ul> 마지막으로 퇴사와 관련하여, 기술임원이 정체성과 불만의 교차로에서서 퇴사 여부를 결정하는데 다음과 같은 네가지 질문이 있다고 한다. 물론, 아래의 질문 이외에도 사실 퇴사를 자의반 타의반으로 하는게 임원들의 현실이기도 하다. 특히, 국내에서는 CEO 또는 CFO와의 갈등, 새로운 CEO가 본인과 코드가 맞는 임원을 데려오기 위해 무리한 요구사항들을 던지는 경우, 회사의 급작스런 정책이나 비지니스 방향성 변경에 따른 조직 해체/축소등의 경우에 더 많은&nbsp; 퇴사를 하는 것을 보아온 나로써는 아래와 같은 관점은 매우 약한 퇴사 동기질문으로 보여서 아쉬웠다.&nbsp;<ul ><li>배움의 속도가 현저히 줄어들었는가?</li><li>일이 지속적으로 에너지를 소진시키는가?</li><li>팀에 합류할 후보자를 진정성 있게 설득할 수 있는가?</li><li>6개월 후에 떠나는 것이 지금 떠나는 것보다 더 큰 피해를 주는가?</li></ul> 주요 내용 이외에도 Appendix로 임운 기초지식이나 엔지니어링 임원 인터뷰 관련 사항들, 손익계산서 읽기, 엔지니어링 허브 만들기, 기술 탐색의 규모, 그리고, 특별부록으로써 국내 9인의 CTO이야기 또한 흥미롭게 볼 수 있는 부분이었다. 국내 CTO 몇분은 같이 근무하거나 함께 업무를 하셨던 분들도 있었는데, 이런 얘기는 별로 못해봤었는데, 그분들을 새롭게 보는 계기가 되기도 하였다. 요컨대, 이 책은 기술임원을 목표로 하는데 어떻게 해야하는지 주위에 선배나 멘토가 없거나 가이드가 필요한 중간관리자들뿐만 아니라 기술과 경영의 접점에서 고민하는 모든 이들에게 자신있게 추천할만한 책이다.

[서평] 윌라슨의 엔지니어링 리더십

최신 GA4 설정을 반영하여 새롭게 업데이트 된 GA4 캠프, 개강을 기다려주신 분들이 많아서 30% 할인 연장 이벤트를 진행하고 있어요.

고객 여정을 정확하게 파악하고, 캠페인 성과를 분석하면서 실험하고, 개선하고, 성장하는 ‘일잘러’가 되고 싶다면, 이번 기회에 30% 할인된 금액으로 캠프 등록하고 GA4를 마스터해 보세요.

✅ 새로워진 GA4 캠프, 주목할 점 3가지

1. 최신 GA4 업데이트를 반영했어요.
사용자 획득 분석, 퍼널 분석, 마케팅 성과 분석 실습은 물론, 구글 시트, 서치 콘솔, 루커 스튜디오, 빅쿼리와 GA4를 연동하는 방법도 가장 최신 버전으로 업데이트 되었어요.

2. Google Merchandise Store 웹사이트의 실제 데이터로 실습해요.
구글에서 직접 운영하는 웹사이트 데이터를 이용해 프로덕트 분석, 마케팅 성과 분석을 진행합니다. 실무와 가까운 분석 시나리오로 직접 분석해 보세요.

3. 탐색 분석 보고서로 마케팅 성과를 분석해요.
CAC, CPA, ROAS, LTR 등 실무에서 마케팅 성과 분석할 때 꼭 필요한 다양한 지표를 GA4로 계산하는 방법을 알아보아요. 탐색 분석 보고서 사용법도 마스터할 수 있어요.

🔥 GA4 캠프 리뉴얼 기념 30% 할인 이벤트 바로가기
https://dub.sh/VKJY1lq

📌 수강생 후기가 궁금하다면 네이버에서 '데이터리안 GA4 캠프 후기'를 검색해 보세요

최신 GA4 설정을 반영하여 새롭게 업데이트 된 GA4 캠프, 개강을 기다려주신 분들이 많아서 30% 할인 연장 이벤트를 진행하고 있어요. 고객 여정을 정확하게 파악하고, 캠페인 성과를 분석하면서 실험하고, 개선하고, 성장하는 ‘일잘러’가 되고 싶다면, 이번 기회에 30% 할인된 금액으로 캠프 등록하고 GA4를 마스터해 보세요. ✅ 새로워진 GA4 캠프, 주목할 점 3가지 1. 최신 GA4 업데이트를 반영했어요.사용자 획득 분석, 퍼널 분석, 마케팅 성과 분석 실습은 물론, 구글 시트, 서치 콘솔, 루커 스튜디오, 빅쿼리와 GA4를 연동하는 방법도 가장 최신 버전으로 업데이트 되었어요. 2. Google Merchandise Store 웹사이트의 실제 데이터로 실습해요.구글에서 직접 운영하는 웹사이트 데이터를 이용해 프로덕트 분석, 마케팅 성과 분석을 진행합니다. 실무와 가까운 분석 시나리오로 직접 분석해 보세요. 3. 탐색 분석 보고서로 마케팅 성과를 분석해요.CAC, CPA, ROAS, LTR 등 실무에서 마케팅 성과 분석할 때 꼭 필요한 다양한 지표를 GA4로 계산하는 방법을 알아보아요. 탐색 분석 보고서 사용법도 마스터할 수 있어요. 🔥 GA4 캠프 리뉴얼 기념 30% 할인 이벤트 바로가기https://dub.sh/VKJY1lq 📌 수강생 후기가 궁금하다면 네이버에서 '데이터리안 GA4 캠프 후기'를 검색해 보세요

새로워진 GA4 캠프 30% 할인 연장 이벤트, 이번 주 마감 ⏰

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

- 프러덕트/사업 기획 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. 습관 형성 상품은 사용자의 머릿속에서 연상작용을 일으키고 사용자들은 당신의 상품에서 고통에 대한 해결책을 발견하게 될지도 모른다. #훅 📚

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

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 디자이너가 사라지고 있다⟫

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

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

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

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

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

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

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

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

뉴스 댓글, 여론 잘 반영할까?...1억 9천만 댓글 분석 / SBS

뉴스 댓글, 여론 잘 반영할까?…1억 9천만 댓글 분석 / SBS

SBS가 네이버와 다음의 뉴스 댓글을 빅데이터 분석. 기사당 평균 댓글수가 다음이 네이버의 3배. 네이버뉴스 이용자가 다음보다 8배 이상. 댓글을 많이 쓰는 상위 10%가 전체 댓글의 70%이상을 쓰고 있음.

www.youtube.com

SBS가 네이버와 다음의 뉴스 댓글을 빅데이터 분석한 결과를 보면, 다음의 기사당 평균 댓글 수가 네이버의 3배임을 확인할 수 있습니다. 또한, 네이버 뉴스를 이용하는 이용자가 다음보다 8배 이상인 것으로 나타났습니다. 댓글을 많이 쓰는 상위 10%의 사용자들이 전체 댓글의 70% 이상을 쓰고 있는 것으로 조사되었습니다. 이러한 분석 결과는 뉴스 댓글이 여론을 반영하는 데 중요한 역할을 할 수 있음을 시사합니다. 특히 상위 10%의 댓글 작성자들이 다수의 댓글을 작성하고 있는 점은 해당 사용자들의 의견이 여론 형성에 큰 영향을 미칠 수 있음을 나타냅니다. https://drift-hunters.com

Apple 백엔드 개발자

bekeanloinse

SBS의 네이버와 다음 뉴스 댓글 빅데이터 분석 기사 잘 읽었습니다. 기사당 평균 댓글 수에서 다음이 네이버의 3배인 점, 그리고 네이버 뉴스 이용자가 다음보다 8배 이상 많은 점이 흥미롭네요. 특히, 댓글을 많이 쓰는 상위 10%가 전체 댓글의 70% 이상을 작성하고 있다는 점에서 댓글이 여론을 잘 반영하는지에 대한 의문이 드네요. https://leveldevildash.com/


Bluffoods 백엔드 개발자

broilcorn

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

한주현

서동환

이로운 제품을 만들고 싶었고 다년간 국내외 다양한 조직에서 커리어를 쌓았습니다. 현재는 퍼블리의 Lead Product Designer로서 세상과 사람들에게 가치를 줄 수 있는 제품을 만들고자 고민하고 있습니다. 생각한 대로 말하게 되고, 말하는 대로 행동한다고 믿기에, 불가능해 보이는 것도 계속 생각하고, 말하고, 행동하면 이뤄낼 수 있다고 믿습니다. 사진을 취미로 찍었었고, 주말에는 주로 책을 읽거나 개인적인 기록을 합니다. 초록색 식물을 가까이 하고 있습니다.

Product Designer

김미연

팀 스포츠를 좋아합니다. 일도 삶도 혼자보다 동료와 함께할 때 더 큰 성장과 성과를 낼 수 있다고 믿습니다. 
사고의 폭을 넓히기 위해 다양한 경험을 중시하고, 떠다니는 생각을 정돈하기 위해 명상을 합니다.

임정욱

호기심 많은 관찰자입니다. 매일 아침 조간 신문 뉴스와 IT뉴스를 챙겨보고 흥미로운 내용을 SNS에 메모해 두는 습관을 10년 넘게 유지하고 있습니다. 독서보다 넷플릭스와 유튜브를 너무 많이 보는 것 같아서 걱정입니다. 막 벤처투자자로 커리어를 바꾸는 참입니다.

댓글 2

비슷한 게시물

주간 인기 TOP 10

추천 프로필