앞으로의 코테는 설명을 주고 코드를 짜라고 하는 것이 아니라, 코드를 주고 설명을 하라는 것이 유효할 것이다.

내 경우는 이미 그렇게 하고 있는데, 요구사항을 주고 개발을 요청. 결과물이 요구사항대로 개발이 잘 되었다면, 다음 단계로 제출한 코드를 리뷰하며 설명을 요청한다.

앞으로 어차피 코드는 AI가 짜 줄테고, 중요한 건 그걸 이해할수 있는지가 중요하기 때문. 다만 설명을 외워 올 수 있으니, 면접관 입장에서는 코드리뷰시 인뎁스 질문을 잘하는 능력이 필요할 것이다.

사실 나는 이런 방식을 이전에도 썼었는데, 이전에는 개발 시간이 너무 오래 걸려서 복잡한 과제는 내기 어려웠다. 그런데 이제는 복잡한 과제를 내는게 부담스럽지 않기 때문에 좀 더 역량을 판단하기 좋아졌다고 생각한다.

참고로, 안타깝게도, 대 AI 시대 이전에도 이후에도, 제출한 결과물을 제대로 이해하지 못하는 경우가 태반이었으며, 심지어 작동여부를 제대로 검증조차 못하는 경우도 많았다.

앞으로의 코테는 설명을 주고 코드를 짜라고 하는 것이 아니라, 코드를 주고 설명을 하라는 것이 유효할 것이다. 내 경우는 이미 그렇게 하고 있는데, 요구사항을 주고 개발을 요청. 결과물이 요구사항대로 개발이 잘 되었다면, 다음 단계로 제출한 코드를 리뷰하며 설명을 요청한다. 앞으로 어차피 코드는 AI가 짜 줄테고, 중요한 건 그걸 이해할수 있는지가 중요하기 때문. 다만 설명을 외워 올 수 있으니, 면접관 입장에서는 코드리뷰시 인뎁스 질문을 잘하는 능력이 필요할 것이다. 사실 나는 이런 방식을 이전에도 썼었는데, 이전에는 개발 시간이 너무 오래 걸려서 복잡한 과제는 내기 어려웠다. 그런데 이제는 복잡한 과제를 내는게 부담스럽지 않기 때문에 좀 더 역량을 판단하기 좋아졌다고 생각한다. 참고로, 안타깝게도, 대 AI 시대 이전에도 이후에도, 제출한 결과물을 제대로 이해하지 못하는 경우가 태반이었으며, 심지어 작동여부를 제대로 검증조차 못하는 경우도 많았다.

Achieving specific goals and legacies in BitLife is incredibly rewarding.

https://bitlife66.github.io/

PRD를 입력하면 DDD기법에의해 해석문서를 만드는 툴로 툴소개와 작동소스 오픈합니다. 실무에 적용가능한 수준의 문서를 만들기보다. 구현에 필요한 직전단계의 최소문서를 만드는 프로세스에 고민을 해본 생성툴입니다.

https://wiki.webnori.com/x/4oGtBg

PRD를 입력하면 DDD기법에의해 해석문서를 만드는 툴로 툴소개와 작동소스 오픈합니다. 실무에 적용가능한 수준의 문서를 만들기보다. 구현에 필요한 직전단계의 최소문서를 만드는 프로세스에 고민을 해본 생성툴입니다. https://wiki.webnori.com/x/4oGtBg

PRD분석 AI툴

며칠 전 재미삼아 아이와 함께 파이썬을 공부하는 영상을 올렸는데, "아빠, 우리 또 해보자!"라는 말에 바로 두 번째 영상을 찍었습니다! 예상과 달리 아이가 파이썬을 어려워하지 않고 재밌어 하더라고요? 유튜브에 아빠랑 자기 모습이 나오는 것도 참 신기해하네요.

이번엔 프로그래밍의 기본 중 기본인 변수와 데이터에 대해서 알려줘 봤어요. 사실 7살 아이에게 변수라는 개념을 어떻게 설명해야 할지 좀 막막했는데요. 직접 작성한 코드를 실행해보고, 그림까지 그려가며 설명해주니 의외로 잘 이해하더라고요.

📺 에릭과 달레의 코딩 일기 2편: https://youtu.be/Jx06T3hodhw

이번 영상에서도 에릭의 솔직한 리액션 덕분에 웃음이 끊이질 않았어요. 제가 실수로 버그를 내면 저를 때리려고 하기도 하고, 이해가 되었다고 갑자기 뽀뽀를 해줘서... 아들 바보 또 심쿵했네요 🥰

며칠 전 재미삼아 아이와 함께 파이썬을 공부하는 영상을 올렸는데, "아빠, 우리 또 해보자!"라는 말에 바로 두 번째 영상을 찍었습니다! 예상과 달리 아이가 파이썬을 어려워하지 않고 재밌어 하더라고요? 유튜브에 아빠랑 자기 모습이 나오는 것도 참 신기해하네요. 이번엔 프로그래밍의 기본 중 기본인 변수와 데이터에 대해서 알려줘 봤어요. 사실 7살 아이에게 변수라는 개념을 어떻게 설명해야 할지 좀 막막했는데요. 직접 작성한 코드를 실행해보고, 그림까지 그려가며 설명해주니 의외로 잘 이해하더라고요. 📺 에릭과 달레의 코딩 일기 2편: https://youtu.be/Jx06T3hodhw 이번 영상에서도 에릭의 솔직한 리액션 덕분에 웃음이 끊이질 않았어요. 제가 실수로 버그를 내면 저를 때리려고 하기도 하고, 이해가 되었다고 갑자기 뽀뽀를 해줘서... 아들 바보 또 심쿵했네요 🥰

😘🐍 어랏? 아이가 파이썬 재밌다네요 ㅋㅋ

슬랙을 커서와 연동하면 바이브 코딩을 할 수 있어요! 이번 영상에선 슬랙을 커서와 연결하면 할 수 있는 일에 대해 이야기해요.

https://youtu.be/4j5kz9k_deQ

슬랙을 커서와 연동하면 바이브 코딩을 할 수 있어요! 이번 영상에선 슬랙을 커서와 연결하면 할 수 있는 일에 대해 이야기해요. https://youtu.be/4j5kz9k_deQ

커서 AI를 슬랙과 연결하면 생기는 일

직장 생활을 하다보면
크고 작은 문제(Problem)들이
매일매일 발생합니다.

저는 과거 직장에서 발생하는
모든 문제들을 해결하기 위해,
매일 모든 에너지를 쏟아부었던
열정적인 신입 직장인이였어요.

내 눈 앞에서 발생하는 모든 문제는
빨리 해결해야 하는 시한폭탄이고,
이 문제를 지금 당장 해결해야만
다음 단계로 넘어갈 수 있다고 생각했습니다.

그래서 문제가 해결되지 않는 상황에
맞닥뜨리게 되면, 머리가 새하얘지고,
쉽게 긴장하는 성격이 되었어요.

이런 저를 보고서,
어떤 직장 동료분이 이런 말을 해주셨습니다.

"Do not solve it. Manage it Instead."

저는 이 해결(Solution)과 관리(Management),
이 두가지의 차이를 인지하는 단계가
주니어에서 시니어로 넘어가는 출발점이 될 수 있다고 생각해요.

문제를 당장 없애려는 강박에서 벗어나는 순간,
더 다양한 접근 방법,
더 크게 보는 자원 관리,
그리고 더 건강한 멘탈을 경험할 수 있어요.

문제 해결에서의 핵심은
때론 즉각적인 해결(Solution)이 아닐 수도 있습니다.
때론 지속 가능한 관리(Management)가
더 좋은 변화를 만들수 있다고 생각해요.

직장 생활을 하다보면 크고 작은 문제(Problem)들이 매일매일 발생합니다. 저는 과거 직장에서 발생하는 모든 문제들을 해결하기 위해, 매일 모든 에너지를 쏟아부었던 열정적인 신입 직장인이였어요. 내 눈 앞에서 발생하는 모든 문제는 빨리 해결해야 하는 시한폭탄이고, 이 문제를 지금 당장 해결해야만 다음 단계로 넘어갈 수 있다고 생각했습니다. 그래서 문제가 해결되지 않는 상황에 맞닥뜨리게 되면, 머리가 새하얘지고, 쉽게 긴장하는 성격이 되었어요. 이런 저를 보고서, 어떤 직장 동료분이 이런 말을 해주셨습니다. "Do not solve it. Manage it Instead." 저는 이 해결(Solution)과 관리(Management), 이 두가지의 차이를 인지하는 단계가 주니어에서 시니어로 넘어가는 출발점이 될 수 있다고 생각해요. 문제를 당장 없애려는 강박에서 벗어나는 순간, 더 다양한 접근 방법, 더 크게 보는 자원 관리, 그리고 더 건강한 멘탈을 경험할 수 있어요. 문제 해결에서의 핵심은 때론 즉각적인 해결(Solution)이 아닐 수도 있습니다. 때론 지속 가능한 관리(Management)가 더 좋은 변화를 만들수 있다고 생각해요.

Do not solve it. Manage it Instead.

클로드 코드 Max를 구독한 후로 조금이라도 더 쓰려는 마음이 앞섭니다. 안 그러면 돈 아까우니까.

컨텍스트 스위칭 - AI 코딩 부작용

클로드 코드 Max를 구독한 후로 조금이라도 더 쓰려는 마음이 앞섭니다.
안 그러면 돈 아까우니까.


뽕을 뽑기 위해서 여러 프로젝트를 함께 돌리게 됩니다.
하나만 가지고는 절대 뽕을 뽑을 수 없거든요.


잠시 내가 천재가 된 기분에 휩싸였다가…
며칠 하다 보면 이게 과연 제대로 하고 있는 게 맞나? 하는 생각이 듭니다.


솔직히 어제 뭘 코딩했는지도 기억이 나질 않습니다.
프로젝트 곳곳에 클로드 코드가 침투해서 엄청난 커밋을 해버리고, 내 머리 속은 도저히 따라갈 수 없는 상황.
이 프로젝트가 어디까지 진행됐었더라? 저 프로젝트는 왜 여기서 멈췄지?


컴퓨터 세상에서도 컨텍스트 스위칭은 엄청난 비용인데…
감히 인간 따위가 이런 컨텍스트 스위칭을 시도하다니. 니가 폰 노이만이냐?


포커스하지 않으면 아무 것도 하지 못한다.
이러다가 죽도 밥도 안 되겠다는 생각이 듭니다.


뽕 뽑으려는 생각은 집어치우고 한 프로젝트만 집중해서 하는 노력을 해보려 합니다.


https://jeho.page/essay/2025/07/23/context-swiching.html

클로드 코드 Max를 구독한 후로 조금이라도 더 쓰려는 마음이 앞섭니다.안 그러면 돈 아까우니까. 뽕을 뽑기 위해서 여러 프로젝트를 함께 돌리게 됩니다.하나만 가지고는 절대 뽕을 뽑을 수 없거든요. 잠시 내가 천재가 된 기분에 휩싸였다가…며칠 하다 보면 이게 과연 제대로 하고 있는 게 맞나? 하는 생각이 듭니다. 솔직히 어제 뭘 코딩했는지도 기억이 나질 않습니다.프로젝트 곳곳에 클로드 코드가 침투해서 엄청난 커밋을 해버리고, 내 머리 속은 도저히 따라갈 수 없는 상황.이 프로젝트가 어디까지 진행됐었더라? 저 프로젝트는 왜 여기서 멈췄지? 컴퓨터 세상에서도 컨텍스트 스위칭은 엄청난 비용인데…감히 인간 따위가 이런 컨텍스트 스위칭을 시도하다니. 니가 폰 노이만이냐? 포커스하지 않으면 아무 것도 하지 못한다.이러다가 죽도 밥도 안 되겠다는 생각이 듭니다. 뽕 뽑으려는 생각은 집어치우고 한 프로젝트만 집중해서 하는 노력을 해보려 합니다. https://jeho.page/essay/2025/07/23/context-swiching.html

K리그 프로그래머

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

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

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

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

즉, 협업이 관건이다.

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

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

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

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

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

경력 기술에서 가장 중요한 것은 정량적 성과입니다. 단순히 업무 내용을 나열하는 것만으로는 차별화된 지원자로 어필할 수 없습니다. 직무 관련 역할은 누구나 수행할 수 있는 일이기 때문에, 그 일을 통해 창출한 구체적인 성과를 수치로 표현해야 합니다.


많은 분들이 "루틴한 업무가 대부분인데 어떻게 정량적 성과로 표현하느냐"고 질문합니다. 제안서 작성, 회계 비용 정산, 교육 운영 등은 얼핏 정량적 성과와 무관해 보입니다.
하지만 모든 역할은 회사의 매출과 이익에 기여합니다. 비즈니스 모델을 가진 회사에서 근무했다면, 담당 직무에 관계없이 회사의 성장에 기여한 것입니다. 전년 대비 매출이나 이익이 성장했다면, 해당 지표를 자신의 성과로 표현할 수 있습니다.
일부 회사는 직무에 관계없이 모든 구성원에게 매출과 이익 목표를 부여하기도 합니다. 이는 모든 업무가 회사의 정량적 목표와 연결되어 있음을 보여줍니다.


회사에서 정량적 지표를 목표로 제시하지 않더라도, 우리는 능동적으로 매출과 이익 등 회사 성장에 기여한 바를 경력에 기술할 수 있습니다.
측정 가능한 핵심 결과 지표를 설정하고, 이를 달성하기 위한 액션 플랜을 수립하는 것이 개인과 조직 성장에 기여하는 방식입니다. 조직이 이런 방식으로 업무를 조정하지 않더라도, 우리는 스스로 정량적 목표를 세우고 구체적인 계획에 따라 일해야 합니다.


정량적 성과를 어필하는 것만큼 중요한 것은 성과를 만든 방법을 구체적으로 설명하는 것입니다. 단순히 "업무를 수행했더니 성과가 나왔다"고 설명한다면 설득력이 떨어집니다. 아무리 대단한 성과라도 그것을 만들어낸 핵심 역량이나 방법을 소개하지 않으면 임팩트가 약해집니다.
예를 들어:
 * 매출 00억 달성에 기여한 자신만의 업무 노하우
 * 사용자 수 00명 증가에 기여한 업무 역할의 특징
 * 전년 대비 주문 건수 00건 증가에 대한 구체적 기여 방식
이러한 업무 노하우와 특정 역할 설명이 바로 역량에 대한 증명입니다. 역량을 증명해야 정량적 성과를 일으킨 사람이라고 믿을 수 있고, 최소한 면접에서 만나보고 싶다는 피드백을 받을 수 있습니다.


효과적인 경력 기술은 역할 - 성과 - 역량의 구조로 이루어져야 합니다. 이 명칭은 '목적 - 역할 - 성과' 등으로 대체할 수도 있습니다. 중요한 것은 구조적으로 경험을 통해 역량을 증명하는 것입니다.
이전에 한 일과 그 일을 통해 발휘한 역량, 역량으로 만든 성과로 경력을 설명한다면 매력적인 인재로 어필할 수 있습니다.


경력이 있는 지원자는 경험을 잘 설명할 수 있다면, 다른 내용들은 과감히 생략해도 됩니다. 자격증, 대외활동 등 시선을 분산시키는 내용들은 오히려 생략하는 것이 좋습니다.
다만, 자기소개는 반드시 포함해야 합니다. 회사를 선택한 이유와 핵심 역량을 소개하는 내용이 필요합니다. 여기서 핵심 역량은 소통이나 협업 관련 소프트 스킬, 즉 보이지 않는 태도적 능력을 의미합니다.
이력서를 읽고 나면 지원자가 보유한 직무 기술과 지향하는 가치적 태도를 모두 파악할 수 있어야 합니다.


좋은 지식과 노하우를 갖고 있어도 자신에게 적용하는 것은 항상 어려운 법입니다. 하지만 오늘 이 내용에 공감하신다면 이력서에 반영해보시기 바랍니다. 분명 이전과는 확실히 다른 이력서로 변신할 수 있을 것입니다.

﻿경력 기술에서 가장 중요한 것은 정량적 성과입니다. 단순히 업무 내용을 나열하는 것만으로는 차별화된 지원자로 어필할 수 없습니다. 직무 관련 역할은 누구나 수행할 수 있는 일이기 때문에, 그 일을 통해 창출한 구체적인 성과를 수치로 표현해야 합니다. 많은 분들이 "루틴한 업무가 대부분인데 어떻게 정량적 성과로 표현하느냐"고 질문합니다. 제안서 작성, 회계 비용 정산, 교육 운영 등은 얼핏 정량적 성과와 무관해 보입니다.하지만 모든 역할은 회사의 매출과 이익에 기여합니다. 비즈니스 모델을 가진 회사에서 근무했다면, 담당 직무에 관계없이 회사의 성장에 기여한 것입니다. 전년 대비 매출이나 이익이 성장했다면, 해당 지표를 자신의 성과로 표현할 수 있습니다.일부 회사는 직무에 관계없이 모든 구성원에게 매출과 이익 목표를 부여하기도 합니다. 이는 모든 업무가 회사의 정량적 목표와 연결되어 있음을 보여줍니다. 회사에서 정량적 지표를 목표로 제시하지 않더라도, 우리는 능동적으로 매출과 이익 등 회사 성장에 기여한 바를 경력에 기술할 수 있습니다.측정 가능한 핵심 결과 지표를 설정하고, 이를 달성하기 위한 액션 플랜을 수립하는 것이 개인과 조직 성장에 기여하는 방식입니다. 조직이 이런 방식으로 업무를 조정하지 않더라도, 우리는 스스로 정량적 목표를 세우고 구체적인 계획에 따라 일해야 합니다. 정량적 성과를 어필하는 것만큼 중요한 것은 성과를 만든 방법을 구체적으로 설명하는 것입니다. 단순히 "업무를 수행했더니 성과가 나왔다"고 설명한다면 설득력이 떨어집니다. 아무리 대단한 성과라도 그것을 만들어낸 핵심 역량이나 방법을 소개하지 않으면 임팩트가 약해집니다.예를 들어:<ul ><li>매출 00억 달성에 기여한 자신만의 업무 노하우</li><li>사용자 수 00명 증가에 기여한 업무 역할의 특징</li><li>전년 대비 주문 건수 00건 증가에 대한 구체적 기여 방식</li></ul>이러한 업무 노하우와 특정 역할 설명이 바로 역량에 대한 증명입니다. 역량을 증명해야 정량적 성과를 일으킨 사람이라고 믿을 수 있고, 최소한 면접에서 만나보고 싶다는 피드백을 받을 수 있습니다. 효과적인 경력 기술은 역할 - 성과 - 역량의 구조로 이루어져야 합니다. 이 명칭은 '목적 - 역할 - 성과' 등으로 대체할 수도 있습니다. 중요한 것은 구조적으로 경험을 통해 역량을 증명하는 것입니다.이전에 한 일과 그 일을 통해 발휘한 역량, 역량으로 만든 성과로 경력을 설명한다면 매력적인 인재로 어필할 수 있습니다. 경력이 있는 지원자는 경험을 잘 설명할 수 있다면, 다른 내용들은 과감히 생략해도 됩니다. 자격증, 대외활동 등 시선을 분산시키는 내용들은 오히려 생략하는 것이 좋습니다.다만, 자기소개는 반드시 포함해야 합니다. 회사를 선택한 이유와 핵심 역량을 소개하는 내용이 필요합니다. 여기서 핵심 역량은 소통이나 협업 관련 소프트 스킬, 즉 보이지 않는 태도적 능력을 의미합니다.이력서를 읽고 나면 지원자가 보유한 직무 기술과 지향하는 가치적 태도를 모두 파악할 수 있어야 합니다. 좋은 지식과 노하우를 갖고 있어도 자신에게 적용하는 것은 항상 어려운 법입니다. 하지만 오늘 이 내용에 공감하신다면 이력서에 반영해보시기 바랍니다. 분명 이전과는 확실히 다른 이력서로 변신할 수 있을 것입니다.﻿

효과적인 경력 기술 가이드

정부가 추진하고 있는 “독자 AI 파운데이션 모델” 사업과 그에 참여하는 팀들에 대해 말이 많은데, 방법이 뭐가됐든 결국은 가장 좋은 성능을 내는 모델을 만들 수 있는지가 중요한거 아닌가.

사후학습으로 만들었다고 해도 그 성능이 세계 최고 수준이면 큰 의미가 있다. 사후학습으로 누구나 세계 수준의 모델을 만들 수 있다면 이런 사업은 애초에 발의조차 되지 않았을테다.

오히려 아무리 프롬-스크래치로 만들었다고해도 그것의 성능이 그저그렇거나 성능 수치조차 공개하지 못할 정도라면 그게 무슨 의미가 있나. 그저 아무도 사용하지 않는 죽은 기술이 될 뿐이다.

정부가 추진하고 있는 “독자 AI 파운데이션 모델” 사업과 그에 참여하는 팀들에 대해 말이 많은데, 방법이 뭐가됐든 결국은 가장 좋은 성능을 내는 모델을 만들 수 있는지가 중요한거 아닌가. 사후학습으로 만들었다고 해도 그 성능이 세계 최고 수준이면 큰 의미가 있다. 사후학습으로 누구나 세계 수준의 모델을 만들 수 있다면 이런 사업은 애초에 발의조차 되지 않았을테다. 오히려 아무리 프롬-스크래치로 만들었다고해도 그것의 성능이 그저그렇거나 성능 수치조차 공개하지 못할 정도라면 그게 무슨 의미가 있나. 그저 아무도 사용하지 않는 죽은 기술이 될 뿐이다.

스프링 팀의 주요 개발자들이 2025년 9월에 출시 예정된 자바 25로의 업그레이드를 강하게 권장하고 있습니다. 이러한 권고의 배경에는 클라우드 환경에서 자바가 겪어온 성능 문제를 해결하는 핵심적인 개선 사항들이 집약되어 있기 때문입니다.

곧 출시될 자바 25는 가능한 빨리 도입하세요

스프링 팀의 주요 개발자들이 2025년 9월에 출시 예정된 자바 25로의 업그레이드를 권장하고 있다. 이러한 권고의 배경에는 클라우드 환경에서 자바가 겪어온 성능 문제를 해결하는 핵심적인 개선 사항들이 집약되어 있기 때문이다.

자바가 마주했던 과제와 이를 해결하기 위한 자바 및 스프링 생태계의 기술적 발전을 정리해봤다.


https://www.linkedin.com/pulse/%EA%B3%A7-%EC%B6%9C%EC%8B%9C%EB%90%A0-%EC%9E%90%EB%B0%94-25%EB%8A%94-%EA%B0%80%EB%8A%A5%ED%95%9C-%EB%B9%A8%EB%A6%AC-%EB%8F%84%EC%9E%85%ED%95%98%EC%84%B8%EC%9A%94-springrunner-5017c

스프링 팀의 주요 개발자들이 2025년 9월에 출시 예정된 자바 25로의 업그레이드를 권장하고 있다. 이러한 권고의 배경에는 클라우드 환경에서 자바가 겪어온 성능 문제를 해결하는 핵심적인 개선 사항들이 집약되어 있기 때문이다. 자바가 마주했던 과제와 이를 해결하기 위한 자바 및 스프링 생태계의 기술적 발전을 정리해봤다. https://www.linkedin.com/pulse/%EA%B3%A7-%EC%B6%9C%EC%8B%9C%EB%90%A0-%EC%9E%90%EB%B0%94-25%EB%8A%94-%EA%B0%80%EB%8A%A5%ED%95%9C-%EB%B9%A8%EB%A6%AC-%EB%8F%84%EC%9E%85%ED%95%98%EC%84%B8%EC%9A%94-springrunner-5017c

kr.linkedin.com

자바 25를 사용해야 하는 이유

　12년 넘게 다닌 회사를 떠난다. 군대를 전역한 이후, 스스로의 선택으로 회사를 떠나는 것은 이번이 처음이다. 그래서인지 아직 실감이 나지 않는다. 첫 출근 날의 설렘이 아직도 손끝에 남아 있는데, 어느새 마지막 퇴근을 준비하고 있다. 하루에도 몇 번씩 아쉬움과 후련함, 설렘과 두려움 …

퇴사 부검 : 네이버를 떠나며

👋 12년의 여정을 돌아보며, 새로운 출발선에 섭니다.

웃고, 고민하고, 때로는 치열하게 싸워왔던 지난 12년의 시간들
네이버라는 큰 배에서 내려 새로운 바다로 나아가며, 그 여정을 조용히 되짚어보는 글을 써봤습니다. ‘퇴사’가 끝이 아니라 ‘나답게 살아가기’ 위한 선택이 되길 바라는 마음으로요.

이 글은 단순한 퇴사 후기가 아니라, ‘왜 나는 일을 하는가’, ‘무엇이 나를 움직이게 하는가’에 대한 긴 시간의 질문과 대답이 담겨 있습니다. 혹시 지금, 일과 삶 사이에서 고민하고 있다면 혹은 나의 가치를 다시 바라보고 싶다면 이 글이 작은 영감이 되기를 바랍니다.

https://taetaetae.github.io/posts/leaving-naver-resignation-review/

👋 12년의 여정을 돌아보며, 새로운 출발선에 섭니다. 웃고, 고민하고, 때로는 치열하게 싸워왔던 지난 12년의 시간들네이버라는 큰 배에서 내려 새로운 바다로 나아가며, 그 여정을 조용히 되짚어보는 글을 써봤습니다. ‘퇴사’가 끝이 아니라 ‘나답게 살아가기’ 위한 선택이 되길 바라는 마음으로요. 이 글은 단순한 퇴사 후기가 아니라, ‘왜 나는 일을 하는가’, ‘무엇이 나를 움직이게 하는가’에 대한 긴 시간의 질문과 대답이 담겨 있습니다. 혹시 지금, 일과 삶 사이에서 고민하고 있다면 혹은 나의 가치를 다시 바라보고 싶다면 이 글이 작은 영감이 되기를 바랍니다. https://taetaetae.github.io/posts/leaving-naver-resignation-review/

taetaetae.github.io

"어떻게 하면 유연하고 확장성 있는 설계를 할 수 있나요?"라는 멘티들의 단골 질문에 대한 답변

요구사항 변화에 따른 프로젝트 구조 확장_Bradley 멘토님

프로그램을 개발하면서 많이 듣는 용어중 하나가 확장성과 유연성이지 않을까 싶습니다.
그만큼 프로그램 개발에 있어 중요한 요소중 하나이고 이를 잘 고려한다면 시스템을 변경하거나 개선해야 할 때, 큰 비용 없이 쉽게 대응할 수 있습니다.


하지만 반대로 이 두 가지를 지나치게 의식하다 보면, 오히려 어떻게 설계해야 할지 결정하지 못하고 한참을 헤매게 되는 경우도 생깁니다.


오늘 소개해 드릴 글은 이런 경험을 한번쯤 해본 분들께 도움이 될 만한 내용인데요,


프로젝트를 시작할 때 복잡한 고민과 설계보다는 핵심 요구사항에 집중하고,
새로운 요구사항이 생길 때마다 점진적으로 구조를 확장해 나가는 과정을 다루고 있습니다.

이를 통해 확장성을 미리 계획하지 않았더라도, 핵심 기능을 잘 정리해 나가면 자연스럽게 확장성과 유연성을 갖춘 구조가 만들어질 수 있다는 걸 보여줍니다.


개인적으로 글에서 설명하는 프로젝트 구조를 만들려면, 다음과 같은 역량을 갖출 수 있도록 노력이 필요하다 생각합니다.


 * 요구사항 분석 및 핵심 기능 정리
 * 명확한 역할 분리를 통한 단일 책임 원칙(SRP) 준수
 * 기존 코드에 미치는 영향을 최소화하기 위한 캡슐화와 OCP 원칙 준수


또한 패키지나 코드를 분리하다 보면, 자연스럽게 Common 패키지나 공통 모듈이 생기기 마련인데요
이러한 Common 패키지, 공통 모듈을 잘못 정리하면 다양한 비즈니스 로직과 의존성이 뒤섞이면서 오히려 확장성과 유연성을 해치는 결과로 이어질 수 있어 주의해야 합니다.


확장성 있는 프로젝트 구조에 고민이 많으신 분들께 조금이나마 도움이 되길 바라겠습니다.


📚 원문
 * https://f-lab.kr/blog/article_20250717
   
📚 함께 읽으면 좋은 글
 * 멀티모듈 설계 이야기 with Spring, Gradle: https://careerly.co.kr/comments/102169?utm_campaign=self-share

프로그램을 개발하면서 많이 듣는 용어중 하나가 확장성과 유연성이지 않을까 싶습니다.그만큼 프로그램 개발에 있어 중요한 요소중 하나이고 이를 잘 고려한다면 시스템을 변경하거나 개선해야 할 때, 큰 비용 없이 쉽게 대응할 수 있습니다. 하지만 반대로 이 두 가지를 지나치게 의식하다 보면, 오히려 어떻게 설계해야 할지 결정하지 못하고 한참을 헤매게 되는 경우도 생깁니다. 오늘 소개해 드릴 글은 이런 경험을 한번쯤 해본 분들께 도움이 될 만한 내용인데요, 프로젝트를 시작할 때 복잡한 고민과 설계보다는 핵심 요구사항에 집중하고, 새로운 요구사항이 생길 때마다 점진적으로 구조를 확장해 나가는 과정을 다루고 있습니다. 이를 통해 확장성을 미리 계획하지 않았더라도, 핵심 기능을 잘 정리해 나가면 자연스럽게 확장성과 유연성을 갖춘 구조가 만들어질 수 있다는 걸 보여줍니다. 개인적으로 글에서 설명하는 프로젝트 구조를 만들려면, 다음과 같은 역량을 갖출 수 있도록 노력이 필요하다 생각합니다. <ul ><li>요구사항 분석 및 핵심 기능 정리</li><li>명확한 역할 분리를 통한 단일 책임 원칙(SRP) 준수</li><li>기존 코드에 미치는 영향을 최소화하기 위한 캡슐화와 OCP 원칙 준수</li></ul> 또한 패키지나 코드를 분리하다 보면, 자연스럽게 Common 패키지나 공통 모듈이 생기기 마련인데요 이러한 Common 패키지, 공통 모듈을 잘못 정리하면 다양한 비즈니스 로직과 의존성이 뒤섞이면서 오히려 확장성과 유연성을 해치는 결과로 이어질 수 있어 주의해야 합니다. 확장성 있는 프로젝트 구조에 고민이 많으신 분들께 조금이나마 도움이 되길 바라겠습니다. 📚 원문<ul ><li>https://f-lab.kr/blog/article_20250717 </li></ul>📚 함께 읽으면 좋은 글<ul ><li>멀티모듈 설계 이야기 with Spring, Gradle: https://careerly.co.kr/comments/102169?utm_campaign=self-share</li></ul>

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

요구사항 변화에 따른 프로젝트 구조 확장 ⛏

어떤 서비스가 버그를 가진채로 출시되었고, 사용자들이 그 버그를 전제로 기능을 사용하고 있다면, 그리고 그 위로 너무 많은 새로운 기능들이 쌓여있다면 그건 버그가 아니라 스펙(기능)이라는, 언젠가부터 들었던 업계의 유명한 블랙 유머다.

삶도 비슷한 것 같다. 분명 잘못된 일이었고, 바로잡지 못한 채 너무 많이 시간이 지나버렸다면 그건 그대로 살아온 삶의 흐름이 된다. 더 이상 잘못이라고 부르기엔, 너무 많은 것들이 그 위에 쌓여 있다.

어떤 서비스가 버그를 가진채로 출시되었고, 사용자들이 그 버그를 전제로 기능을 사용하고 있다면, 그리고 그 위로 너무 많은 새로운 기능들이 쌓여있다면 그건 버그가 아니라 스펙(기능)이라는, 언젠가부터 들었던 업계의 유명한 블랙 유머다. 삶도 비슷한 것 같다. 분명 잘못된 일이었고, 바로잡지 못한 채 너무 많이 시간이 지나버렸다면 그건 그대로 살아온 삶의 흐름이 된다. 더 이상 잘못이라고 부르기엔, 너무 많은 것들이 그 위에 쌓여 있다.

"배포했으면 스펙이지"

1. '바쁘다'는 건 열심히 많은 일을 하고 있다는 뜻이다.

2. '생산적'이라는 건 가장 중요한 일을 끝낸다는 뜻이다.

3. '효율적'이라는 건 최 단시간 내에 중요한 일을 끝낸다는 뜻이다.

4. 이런 차이를 알고, 자기 자신을 알면 덜 바빠지지만 효율성은 높아진다. 잘못된 일을 줄이고 가장 중요한 일을 조금 더 하면 효율성이 크게 높아진다.

5. 효율적으로 일하는 방법을 알기 위해서는 자신을 바쁘게 만들지만 생산성이 낮거나, 낭비를 야기하는 분야가 어디인지를 알아야 한다.

#결단 📚
#롭무어
#하루한문장

1. '바쁘다'는 건 열심히 많은 일을 하고 있다는 뜻이다. ​2. '생산적'이라는 건 가장 중요한 일을 끝낸다는 뜻이다. ​3. '효율적'이라는 건 최 단시간 내에 중요한 일을 끝낸다는 뜻이다. ​4. 이런 차이를 알고, 자기 자신을 알면 덜 바빠지지만 효율성은 높아진다. 잘못된 일을 줄이고 가장 중요한 일을 조금 더 하면 효율성이 크게 높아진다. ​5. 효율적으로 일하는 방법을 알기 위해서는 자신을 바쁘게 만들지만 생산성이 낮거나, 낭비를 야기하는 분야가 어디인지를 알아야 한다. #결단 📚 #롭무어 #하루한문장

< 당신이 바쁜데도 성과가 없는 이유 >

어제는 한 편의 드라마와 같은 인상적인 포트폴리오를 읽었습니다. 한 백엔드 개발자의 포트폴리오였는데, 문제 해결 역량을 강조한 내용으로 가득했습니다. 특별히 인상 깊었던 점은 어린 시절부터 문제를 발견하고 해결했던 사례를 과감하게 포트폴리오에 담아냈다는 것이었습니다.


보통 포트폴리오라고 하면 대단히 업무적인 내용만 담긴 딱딱한 문서로 느껴집니다. 그런데 이 포트폴리오는 그 틀을 깨고 지극히 개인적인 과거의 역사 속 사례를 꺼내어 풀어낸 점이 신선했습니다. 파격적이라는 인상을 주는 동시에 실제 입사 지원 시에도 긍정적인 평가를 받을 수 있을 것이라고 생각합니다.
물론 100명에게 포트폴리오를 보여준다고 해서 모두가 긍정적인 피드백을 주진 않을 것입니다. 세상에 그런 완벽한 포트폴리오는 존재하지 않습니다. 평가자의 주관적인 해석과 취향이 개입되기 때문입니다. 형식을 파괴한 자유로운 포트폴리오가 어떤 이에게는 신선하게 느껴질 수 있고, 다른 이에게는 말도 안 된다고 여겨질 수도 있습니다.


최근 많은 기업에서 인재에게 요구하는 역량은 단연코 문제 해결 능력입니다. 문제를 해결하는 능력을 증명하려면 문제를 명확히 정의하고, 참신하고 효과적인 해결 방법을 제시해야 합니다. 문제는 기업 내에서만 발생하지 않습니다. 오히려 우리의 일상에 더 많은 문제가 숨어 있습니다. 그리고 실제로 많은 기업은 사람들의 일상적인 문제를 해결하기 위해 제품이나 서비스를 만듭니다.


그렇기 때문에 우리도 포트폴리오에 일상에서 발견한 문제를 해결한 사례를 담아도 충분히 설득력이 있습니다. 단, 그 사례는 논리적이고 날카로운 문제 정의와 해결 방법이 담겨 있어야 합니다. 개인적으로 느낀 작은 문제보다는, 비슷한 문제를 겪고 있는 다수의 사람들이 있음을 밝혀낼 수 있다면 더욱 강력한 사례가 됩니다. 예를 들어, 내가 발견한 문제를 겪고 있는 사람들이 최소 50명, 100명쯤 된다는 근거를 제시할 수 있다면 충분히 규모 있는 문제로 해석될 수 있습니다.
해결 방법의 날카로움도 중요한 기준입니다. 시간과 비용 측면에서 효율적이며, 다수에게 유용하고 피드백도 좋았다면 논리적으로 설득력이 있는 해결책입니다. 단순히 "해결했다"는 결과보다는, 어떤 고민과 시도, 검증 과정을 거쳐 해결했는지를 풀어내야 공감과 납득을 이끌 수 있습니다.


지극히 개인적인 문제 해결 경험과 상업적으로도 활용 가능한 문제 해결 경험, 이 두 가지를 포트폴리오에 함께 담는다면 금상첨화입니다. 그렇게 되면 독자는 자연스럽게 "이 사람은 늘 문제에 안테나를 세우고 해결을 위해 움직이는 사람이구나"라는 인상을 받을 것입니다.
"저는 문제 해결 능력을 갖춘 사람입니다."라고 말하는 사람은 많습니다. 하지만 그걸 뚜렷하게 증명하는 사람은 드뭅니다. 이유는 간단합니다. 문제로 제시한 것이 독자에게는 문제로 느껴지지 않거나, 해결 방법이 납득되지 않기 때문입니다.


이력서나 포트폴리오에 담겨야 하는 것은 독자의 공감을 사는 역량 증명 사례입니다. 단순한 경험 나열로는 부족합니다. 역량이 생동감 있게 전달되어야 합니다. 그러려면 그 사례가 진짜 내 머리와 마음에서 우러나온 경험이어야 합니다. 누군가의 지시에 따라 행동한 결과는 마치 마트에서 포장된 회 한 접시 같습니다. 그보다는 수산시장처럼 신선하고, 더 나아가 직접 낚아 올린 회처럼 살아 있는 경험이어야 합니다.


지금까지의 포트폴리오에 그런 살아 있는 경험이 부족했다면, 이제는 진짜 내 생각과 마음이 담긴 사례로 바꾸어보세요. 아직 그런 경험이 없다면 지금부터 만들어도 늦지 않았습니다. 조급한 마음으로 아무 내용이나 넣는 것보다는 차분히 내 경험을 정리하고, 새롭게 시도해보는 것이 중요합니다.
살아 있는 경험은 우리의 포트폴리오를 크게 변화시켜줄 것입니다.

﻿어제는 한 편의 드라마와 같은 인상적인 포트폴리오를 읽었습니다. 한 백엔드 개발자의 포트폴리오였는데, 문제 해결 역량을 강조한 내용으로 가득했습니다. 특별히 인상 깊었던 점은 어린 시절부터 문제를 발견하고 해결했던 사례를 과감하게 포트폴리오에 담아냈다는 것이었습니다. 보통 포트폴리오라고 하면 대단히 업무적인 내용만 담긴 딱딱한 문서로 느껴집니다. 그런데 이 포트폴리오는 그 틀을 깨고 지극히 개인적인 과거의 역사 속 사례를 꺼내어 풀어낸 점이 신선했습니다. 파격적이라는 인상을 주는 동시에 실제 입사 지원 시에도 긍정적인 평가를 받을 수 있을 것이라고 생각합니다.물론 100명에게 포트폴리오를 보여준다고 해서 모두가 긍정적인 피드백을 주진 않을 것입니다. 세상에 그런 완벽한 포트폴리오는 존재하지 않습니다. 평가자의 주관적인 해석과 취향이 개입되기 때문입니다. 형식을 파괴한 자유로운 포트폴리오가 어떤 이에게는 신선하게 느껴질 수 있고, 다른 이에게는 말도 안 된다고 여겨질 수도 있습니다. 최근 많은 기업에서 인재에게 요구하는 역량은 단연코 문제 해결 능력입니다. 문제를 해결하는 능력을 증명하려면 문제를 명확히 정의하고, 참신하고 효과적인 해결 방법을 제시해야 합니다. 문제는 기업 내에서만 발생하지 않습니다. 오히려 우리의 일상에 더 많은 문제가 숨어 있습니다. 그리고 실제로 많은 기업은 사람들의 일상적인 문제를 해결하기 위해 제품이나 서비스를 만듭니다. 그렇기 때문에 우리도 포트폴리오에 일상에서 발견한 문제를 해결한 사례를 담아도 충분히 설득력이 있습니다. 단, 그 사례는 논리적이고 날카로운 문제 정의와 해결 방법이 담겨 있어야 합니다. 개인적으로 느낀 작은 문제보다는, 비슷한 문제를 겪고 있는 다수의 사람들이 있음을 밝혀낼 수 있다면 더욱 강력한 사례가 됩니다. 예를 들어, 내가 발견한 문제를 겪고 있는 사람들이 최소 50명, 100명쯤 된다는 근거를 제시할 수 있다면 충분히 규모 있는 문제로 해석될 수 있습니다.해결 방법의 날카로움도 중요한 기준입니다. 시간과 비용 측면에서 효율적이며, 다수에게 유용하고 피드백도 좋았다면 논리적으로 설득력이 있는 해결책입니다. 단순히 "해결했다"는 결과보다는, 어떤 고민과 시도, 검증 과정을 거쳐 해결했는지를 풀어내야 공감과 납득을 이끌 수 있습니다. 지극히 개인적인 문제 해결 경험과 상업적으로도 활용 가능한 문제 해결 경험, 이 두 가지를 포트폴리오에 함께 담는다면 금상첨화입니다. 그렇게 되면 독자는 자연스럽게 "이 사람은 늘 문제에 안테나를 세우고 해결을 위해 움직이는 사람이구나"라는 인상을 받을 것입니다."저는 문제 해결 능력을 갖춘 사람입니다."라고 말하는 사람은 많습니다. 하지만 그걸 뚜렷하게 증명하는 사람은 드뭅니다. 이유는 간단합니다. 문제로 제시한 것이 독자에게는 문제로 느껴지지 않거나, 해결 방법이 납득되지 않기 때문입니다. 이력서나 포트폴리오에 담겨야 하는 것은 독자의 공감을 사는 역량 증명 사례입니다. 단순한 경험 나열로는 부족합니다. 역량이 생동감 있게 전달되어야 합니다. 그러려면 그 사례가 진짜 내 머리와 마음에서 우러나온 경험이어야 합니다. 누군가의 지시에 따라 행동한 결과는 마치 마트에서 포장된 회 한 접시 같습니다. 그보다는 수산시장처럼 신선하고, 더 나아가 직접 낚아 올린 회처럼 살아 있는 경험이어야 합니다. 지금까지의 포트폴리오에 그런 살아 있는 경험이 부족했다면, 이제는 진짜 내 생각과 마음이 담긴 사례로 바꾸어보세요. 아직 그런 경험이 없다면 지금부터 만들어도 늦지 않았습니다. 조급한 마음으로 아무 내용이나 넣는 것보다는 차분히 내 경험을 정리하고, 새롭게 시도해보는 것이 중요합니다.살아 있는 경험은 우리의 포트폴리오를 크게 변화시켜줄 것입니다.﻿

살아있네

며칠 전 퇴근길 지하철에서였다. 중년 사내와 20대 후반으로 보이는 한 젊은이가 내 앞에 나란히 앉아 있었다. 자리가 사람을 만드는 법이지.” 중년 사내가 젊은이에게 건네는 말 한마디가 내 귀에 들려왔다. 그 순간 나는 묘한 추억에 빠져

[김인수 기자의 사람이니까 경영이다]자리가 무능한 사람을 만든다는데 - 매일경제

퇴근길 지하철에서 중년 사내와 20대 후반의 한 젊은이가 필자의 앞에 나란히 앉아 있었다. “자리가 사람을 만드는 법이지.” 중년 사내가 젊은이에게 건네는 말 한마디가 내 귀에 들려왔다. 그 순간 나는 묘한 추억에 빠져들었다.

대학생 때부터 흔하게 들은 말이었다. 자리를 맡으면 그 자리에 맞는 사람이 된다고 했다. 임원으로 승진하면 임원에 걸맞게 사람이 된다는 것이다. 당장은 자기 능력에 부치는 자리라도 일단 맡으면 그 자리에 맞게 성장한다고 했다. 그러니 조직에 들어가면 중요한 자리를 맡으라고 옛 선배들은 조언했다.

문득 한 가지 의문이 머릿속에 떠올랐다. 만약 사람들이 하찮다고 여기는 자리를 맡으면 어떻게 될까? 그 자리에 걸맞은 사람이 되는 걸까? 그렇다면 무능해진다는 뜻인가? 그 생각에는 근거가 있었다. 심리학자 앨런 랭어의 책 <마음챙김>의 한 단락이 기억났다.

“우리는 여행하는 사람들은 어느 정도 독립적이고 자신감이 있으리라는 가정 아래 공항에서 실험을 하기로 했다. 실험 중 하나는 다음과 같이 진행되었다. 1단계에서 우리는 피험자들에게 난이도가 낮은 산수 문제들을 풀게 했다.“

”2단계에서는 어떤 피험자들에게는 ‘조수’라는 칭호를, 다른 피험자들에게는 ‘감독자’라는 칭호를 주어 자신의 능력에 의문을 품도록 유도한 뒤 각자 자신의 역할에 맞게 과제를 수행하도록 지시했다.“

”3단계에서는, 모든 피험자가 1단계에서 풀었던 것과 같은 수준의 쉬운 산수 문제를 다시 풀었다. 그런데 ‘조수’가 되었던 피험자들은 1단계에서 받았던 점수의 절반밖에 받지 못했다. 실험을 시작할 땐 똑같은 능력을 가지고 있었지만 꼬리표를 받아들이자 수행능력이 저하된 것이다.“

필자는 이 실험 결과를 접하고 깜짝 놀랐다. ‘조수’라는 자리가 사람을 무능하게 만든 거라는 생각이 들었기 때문이었다. 과제 수행을 주도하는 감독자가 아니라 옆에서 보조하는 조수 역할을 맡았더니, 산수 문제를 푸는 능력이 절반으로 뚝 떨어졌다는 게 그 증거 같았다.

그러고 보니, 자리가 사람을 만드는 게 맞는 거 같았다. 단 사람을 무능하게 만드는 거였다. 물론 그렇게 되려면 한 가지 조건이 충족돼야 한다. 남들이 그 자리에 붙인 ‘꼬리표’, 즉 ‘하찮은 자리’라는 걸 마음으로 받아들인다는 것, 그래서 그 자리를 맡은 자신의 능력을 의심해야 한다는 것이다.

결국 이 실험 결과는 무서운 진실 하나를 우리에게 알려준다. 세상 사람들이 내가 맡은 자리를 하찮게 여긴다고 나 역시 그렇게 여기면, 결국 나라는 사람 자체가 무능해진다는 것이다.

그러나 종종 주변에서 정반대 사람들을 보게 된다. 독립적이고 창조적인 영혼의 소유자 가운데 이른바 ‘한직’을 좋아하는 사람들이 꽤 있다. 한직은 대체로 남들의 관심과 주목을 받지 않는다. 일에 쫓기지도 않는다. 시간 여유가 생긴다. 간섭과 관례에 얽매이지 않고 새로운 시도를 하기에 딱 좋다.

반면 ‘중요한 자리’라는 꼬리표가 달린 자리에는 윗사람들의 간섭이 심하다. 대개 윗사람들은 그 중요하다는 자리를 이미 거쳤다. 자기 방식으로 일해야 성과를 낸다고 믿는다. 그래서 그 방식을 후임자가 고수하기를 원한다. 후임자 입장에서는 새로운 시도를 하기가 쉽지 않다.

독립적이고 창조적인 영혼의 소유자 입장에서는 괴로운 상황이다. 결국 중요한 건 남들이 그 자리에 붙인 ‘꼬리표’가 아니다. 그 자리가 자석처럼 자신의 ‘열정’을 끌어당기느냐, 업무에 ‘자유’가 있느냐가 핵심이다. 존 고든의 책 <에너지 버스>의 한 구절이 기억난다.

“미국 대통령 린든 존슨이 미 항공우주국을 방문했을 때의 일이에요. 대통령이 로비를 지날 때 지저분해진 바닥을 닦고 있는 청소부를 보게 됐답니다. 청소부는 세상에서 가장 즐거운 일이라도 하는 듯 콧노래를 흥얼거리며 열심히 바닥을 닦고 있더랍니다.“

”대통령은 그에게 다가가 치하했죠. ‘여태껏 자신이 본 중에서 가장 훌륭한 청소부’라고 말이죠. 그런데 그 청소부가 뭐라고 대답했는지 아세요? ‘각하, 저는 일개 청소부가 아닙니다. 저는 인간을 달에 보내는 일을 돕고 있어요.’“

그 청소부는 청소일에서 자신의 사명과 열정을 찾은 것이다. 결국 하찮은 자리를 맡아 하찮은 사람이 되느냐는 우리 자신에게 달렸다. 우리는 그 일에서 새로운 가치를 창조할 수가 있다. 우리 자신의 능력을 키울 수 있다. 앞으로 나아갈 수 있다. 콧노래를 부르며 행복하게 일할 수 있다.

오히려 높은 자리가 사람을 무능하게 만들 수 있다는 점을 경계해야 한다. 로렌스 피터가 제시한 피터의 법칙이 딱 그런 내용이다. 이 법칙에 따르면 계층제 조직에서 직원들은 자신이 무능해지는 수준까지 승진하게 된다.

처음에는 능력을 발휘해 승진하지만 결국에는 자기 능력으로는 버거운 자리에 오르게 된다는 것이다. 그래서 결국 무능한 상사가 되고 만다. 피터의 법칙이 옳다면 ‘자리가 사람을 만든다’는 속담은 틀린 게 된다. 버거운 자리는 그냥 버거운 자리일 뿐이다. 사람만 무능해진다.

그런데 한 가지 의문이 든다. 피터의 법칙이 맞는다면, 무능한 사람들은 어떻게 높은 자리를 지킬 수 있는 것일까? 그 비결은 관료제의 속성에 있다. 관료제는 매뉴얼과 규칙, 규정으로 굴러가는 조직이다. 고위직 직원 역시 그 매뉴얼을 지킴으로써 자기 자리를 지킬 수 있다는 것이다.

다시금 앞에 앉은 중년 사내의 목소리가 들려왔다. 그는 젊은이에게 직장 생활에 대한 충고를 계속 늘어놓고 있었다. 아무래도 고향 또는 학교 선후배 사이 같았다. 필자는 그 젊은이에게 나이 든 직장인의 말에 귀 기울이지 말라고 말하고 싶었다. 급변하는 세상이고 미래는 불확실하다. 그러니 ‘자리가 사람을 만든다’는 그의 얕은 경험담은 무시하라고 말해주고 싶었다.

자리는 사람을 무능하게도 유능하게도 만들 수 있다. 중요한 건, 그 자리에서 자기만의 전진이 가능하느냐는 것. 그 전진이 자기 삶에 의미가 있느냐는 것이다. 전진과 의미가 없는 자리라면, 아무리 높은 자리인들 무슨 소용이 있겠는가. 남들이 하찮게 보는 자리라고 해도 전진과 의미가 있다면 그에게 소중한 자리다.

퇴근길 지하철에서 중년 사내와 20대 후반의 한 젊은이가 필자의 앞에 나란히 앉아 있었다. “자리가 사람을 만드는 법이지.” 중년 사내가 젊은이에게 건네는 말 한마디가 내 귀에 들려왔다. 그 순간 나는 묘한 추억에 빠져들었다. 대학생 때부터 흔하게 들은 말이었다. 자리를 맡으면 그 자리에 맞는 사람이 된다고 했다. 임원으로 승진하면 임원에 걸맞게 사람이 된다는 것이다. 당장은 자기 능력에 부치는 자리라도 일단 맡으면 그 자리에 맞게 성장한다고 했다. 그러니 조직에 들어가면 중요한 자리를 맡으라고 옛 선배들은 조언했다. 문득 한 가지 의문이 머릿속에 떠올랐다. 만약 사람들이 하찮다고 여기는 자리를 맡으면 어떻게 될까? 그 자리에 걸맞은 사람이 되는 걸까? 그렇다면 무능해진다는 뜻인가? 그 생각에는 근거가 있었다. 심리학자 앨런 랭어의 책 &lt;마음챙김&gt;의 한 단락이 기억났다. “우리는 여행하는 사람들은 어느 정도 독립적이고 자신감이 있으리라는 가정 아래 공항에서 실험을 하기로 했다. 실험 중 하나는 다음과 같이 진행되었다. 1단계에서 우리는 피험자들에게 난이도가 낮은 산수 문제들을 풀게 했다.“ ”2단계에서는 어떤 피험자들에게는 ‘조수’라는 칭호를, 다른 피험자들에게는 ‘감독자’라는 칭호를 주어 자신의 능력에 의문을 품도록 유도한 뒤 각자 자신의 역할에 맞게 과제를 수행하도록 지시했다.“ ”3단계에서는, 모든 피험자가 1단계에서 풀었던 것과 같은 수준의 쉬운 산수 문제를 다시 풀었다. 그런데 ‘조수’가 되었던 피험자들은 1단계에서 받았던 점수의 절반밖에 받지 못했다. 실험을 시작할 땐 똑같은 능력을 가지고 있었지만 꼬리표를 받아들이자 수행능력이 저하된 것이다.“ 필자는 이 실험 결과를 접하고 깜짝 놀랐다. ‘조수’라는 자리가 사람을 무능하게 만든 거라는 생각이 들었기 때문이었다. 과제 수행을 주도하는 감독자가 아니라 옆에서 보조하는 조수 역할을 맡았더니, 산수 문제를 푸는 능력이 절반으로 뚝 떨어졌다는 게 그 증거 같았다. 그러고 보니, 자리가 사람을 만드는 게 맞는 거 같았다. 단 사람을 무능하게 만드는 거였다. 물론 그렇게 되려면 한 가지 조건이 충족돼야 한다. 남들이 그 자리에 붙인 ‘꼬리표’, 즉 ‘하찮은 자리’라는 걸 마음으로 받아들인다는 것, 그래서 그 자리를 맡은 자신의 능력을 의심해야 한다는 것이다. 결국 이 실험 결과는 무서운 진실 하나를 우리에게 알려준다. 세상 사람들이 내가 맡은 자리를 하찮게 여긴다고 나 역시 그렇게 여기면, 결국 나라는 사람 자체가 무능해진다는 것이다. 그러나 종종 주변에서 정반대 사람들을 보게 된다. 독립적이고 창조적인 영혼의 소유자 가운데 이른바 ‘한직’을 좋아하는 사람들이 꽤 있다. 한직은 대체로 남들의 관심과 주목을 받지 않는다. 일에 쫓기지도 않는다. 시간 여유가 생긴다. 간섭과 관례에 얽매이지 않고 새로운 시도를 하기에 딱 좋다. 반면 ‘중요한 자리’라는 꼬리표가 달린 자리에는 윗사람들의 간섭이 심하다. 대개 윗사람들은 그 중요하다는 자리를 이미 거쳤다. 자기 방식으로 일해야 성과를 낸다고 믿는다. 그래서 그 방식을 후임자가 고수하기를 원한다. 후임자 입장에서는 새로운 시도를 하기가 쉽지 않다. 독립적이고 창조적인 영혼의 소유자 입장에서는 괴로운 상황이다. 결국 중요한 건 남들이 그 자리에 붙인 ‘꼬리표’가 아니다. 그 자리가 자석처럼 자신의 ‘열정’을 끌어당기느냐, 업무에 ‘자유’가 있느냐가 핵심이다. 존 고든의 책 &lt;에너지 버스&gt;의 한 구절이 기억난다. “미국 대통령 린든 존슨이 미 항공우주국을 방문했을 때의 일이에요. 대통령이 로비를 지날 때 지저분해진 바닥을 닦고 있는 청소부를 보게 됐답니다. 청소부는 세상에서 가장 즐거운 일이라도 하는 듯 콧노래를 흥얼거리며 열심히 바닥을 닦고 있더랍니다.“ ”대통령은 그에게 다가가 치하했죠. ‘여태껏 자신이 본 중에서 가장 훌륭한 청소부’라고 말이죠. 그런데 그 청소부가 뭐라고 대답했는지 아세요? ‘각하, 저는 일개 청소부가 아닙니다. 저는 인간을 달에 보내는 일을 돕고 있어요.’“ 그 청소부는 청소일에서 자신의 사명과 열정을 찾은 것이다. 결국 하찮은 자리를 맡아 하찮은 사람이 되느냐는 우리 자신에게 달렸다. 우리는 그 일에서 새로운 가치를 창조할 수가 있다. 우리 자신의 능력을 키울 수 있다. 앞으로 나아갈 수 있다. 콧노래를 부르며 행복하게 일할 수 있다. 오히려 높은 자리가 사람을 무능하게 만들 수 있다는 점을 경계해야 한다. 로렌스 피터가 제시한 피터의 법칙이 딱 그런 내용이다. 이 법칙에 따르면 계층제 조직에서 직원들은 자신이 무능해지는 수준까지 승진하게 된다. 처음에는 능력을 발휘해 승진하지만 결국에는 자기 능력으로는 버거운 자리에 오르게 된다는 것이다. 그래서 결국 무능한 상사가 되고 만다. 피터의 법칙이 옳다면 ‘자리가 사람을 만든다’는 속담은 틀린 게 된다. 버거운 자리는 그냥 버거운 자리일 뿐이다. 사람만 무능해진다. 그런데 한 가지 의문이 든다. 피터의 법칙이 맞는다면, 무능한 사람들은 어떻게 높은 자리를 지킬 수 있는 것일까? 그 비결은 관료제의 속성에 있다. 관료제는 매뉴얼과 규칙, 규정으로 굴러가는 조직이다. 고위직 직원 역시 그 매뉴얼을 지킴으로써 자기 자리를 지킬 수 있다는 것이다. 다시금 앞에 앉은 중년 사내의 목소리가 들려왔다. 그는 젊은이에게 직장 생활에 대한 충고를 계속 늘어놓고 있었다. 아무래도 고향 또는 학교 선후배 사이 같았다. 필자는 그 젊은이에게 나이 든 직장인의 말에 귀 기울이지 말라고 말하고 싶었다. 급변하는 세상이고 미래는 불확실하다. 그러니 ‘자리가 사람을 만든다’는 그의 얕은 경험담은 무시하라고 말해주고 싶었다. 자리는 사람을 무능하게도 유능하게도 만들 수 있다. 중요한 건, 그 자리에서 자기만의 전진이 가능하느냐는 것. 그 전진이 자기 삶에 의미가 있느냐는 것이다. 전진과 의미가 없는 자리라면, 아무리 높은 자리인들 무슨 소용이 있겠는가. 남들이 하찮게 보는 자리라고 해도 전진과 의미가 있다면 그에게 소중한 자리다.

매일경제

퇴근길 지하철에서 중년 사내와 20대 후반의 한 젊은이가 필자의 

우리는 QR(Quick Response) 코드의 시대를 살고 있다. 스마트폰으로 스캔할 수 있는 QR 코드가 식품 포장부터 버스 정류장의 시간표, 레스토랑의 메뉴에 이르기까지 모든 곳에 붙어 있다. 온라인 기사에는 독자가 그 글을 읽는 데 걸리는 예상 ‘독서 시간'이 표시되어 있다. 이 예상 시간은 책에도 표시되기 시작했다. 특정 주제에 너무 많은 시간을 낭비하지 않게 하려는 것이다. 아마존은 페이지 로딩 시간을 100밀리 초 단축할 때마다 매출이 1퍼센트 증가한다고 주장한다. 밀리 초는 1000분의 1초다.
⠀
구글의 엔지니어들은 그 밀리 초를 다투는 경쟁에 몰두하고 있다. 그들의 검색 결과를 기다리는 사람들에게는 400밀리 초(눈 깜빡이는 정도의 시간)의 지연도 길다는 것을 발견했다. 지금은 폐지된 구글 글래스 프로젝트의 수석 엔지니어는 웨어러블 기술의 주된 목표 중 하나가 원하는 것을 얻는 속도를 극적으로 높이는 것이라고 말했다. “휴대전화에서 30~60초가 걸릴 작업이 글래스에서는 2~4초가 걸립니다.”
⠀
경험의 멸종, 크리스틴 로젠

우리는 QR(Quick Response) 코드의 시대를 살고 있다. 스마트폰으로 스캔할 수 있는 QR 코드가 식품 포장부터 버스 정류장의 시간표, 레스토랑의 메뉴에 이르기까지 모든 곳에 붙어 있다. 온라인 기사에는 독자가 그 글을 읽는 데 걸리는 예상 ‘독서 시간'이 표시되어 있다. 이 예상 시간은 책에도 표시되기 시작했다. 특정 주제에 너무 많은 시간을 낭비하지 않게 하려는 것이다. 아마존은 페이지 로딩 시간을 100밀리 초 단축할 때마다 매출이 1퍼센트 증가한다고 주장한다. 밀리 초는 1000분의 1초다.⠀구글의 엔지니어들은 그 밀리 초를 다투는 경쟁에 몰두하고 있다. 그들의 검색 결과를 기다리는 사람들에게는 400밀리 초(눈 깜빡이는 정도의 시간)의 지연도 길다는 것을 발견했다. 지금은 폐지된 구글 글래스 프로젝트의 수석 엔지니어는 웨어러블 기술의 주된 목표 중 하나가 원하는 것을 얻는 속도를 극적으로 높이는 것이라고 말했다. “휴대전화에서 30~60초가 걸릴 작업이 글래스에서는 2~4초가 걸립니다.”⠀경험의 멸종, 크리스틴 로젠

《기다림이 허락되지 않는 시대》

아이의 여름 방학이 시작됐습니다. 아내가 요즘 한국에서는 유치원에서도 코딩을 배운다면서, 명색이 아빠가 개발자인데 아이한테 코딩 좀 가르쳐보라고 하더군요. 😅

어린아이들에게는 보통 스크래치 같은 그래픽 기반 언어로 블록 코딩을 가르친다던데, 저는 스크래치를 잘 모르기도 하고요... 생업으로 소프트웨어 개발을 하다 보니 아무래도 텍스트 기반 언어로 좀 더 실용적인 코딩을 알려주고 싶더라고요. 그냥 놀이로 끝나는 게 아니라, 나중에 아이 인생에 진짜 도움이 될 수 있는 뭔가가 되었으면 하는 바람이 있어서요.

그래서 방학 프로젝트로 제 아들 에릭과 함께 파이썬을 배우기로 했습니다! 7살 아이에게 파이썬을 어디서부터 어떻게 설명해야 할지 참 막막하더라고요... 저 잘 할 수 있을까요?

이왕이면 아이와 함께 코딩하는 과정을 추억으로 남기고 싶어서 영상으로 찍어 보았어요. 혹시 저처럼 자녀의 코딩 교육을 고민하고 계신 부모님들께 도움이 될 수 있지 않을까 싶기도 해서 유튜브에 올려봅니다.

📺 첫 영상: youtu.be/LtH7mv9n-vA

아들 녀석의 엉뚱한 질문과 돌발 행동 때문에 진땀을 뺐네요 ㅋㅋㅋ 아이가 괜히 저 때문에 코딩을 싫어하게 될까봐 걱정도 되지만, 아이랑 즐겁게 배우면서, 저도 같이 성장해보려 합니다.

코딩을 처음 접하는 아이와, 아이에게 처음 코딩을 가르쳐보는 아빠의 좌충우돌 도전기 💪
많이 응원해 주세요!

#달레의코드 #방학프로젝트 #아빠와코딩

아이의 여름 방학이 시작됐습니다. 아내가 요즘 한국에서는 유치원에서도 코딩을 배운다면서, 명색이 아빠가 개발자인데 아이한테 코딩 좀 가르쳐보라고 하더군요. 😅 어린아이들에게는 보통 스크래치 같은 그래픽 기반 언어로 블록 코딩을 가르친다던데, 저는 스크래치를 잘 모르기도 하고요... 생업으로 소프트웨어 개발을 하다 보니 아무래도 텍스트 기반 언어로 좀 더 실용적인 코딩을 알려주고 싶더라고요. 그냥 놀이로 끝나는 게 아니라, 나중에 아이 인생에 진짜 도움이 될 수 있는 뭔가가 되었으면 하는 바람이 있어서요. 그래서 방학 프로젝트로 제 아들 에릭과 함께 파이썬을 배우기로 했습니다! 7살 아이에게 파이썬을 어디서부터 어떻게 설명해야 할지 참 막막하더라고요... 저 잘 할 수 있을까요? 이왕이면 아이와 함께 코딩하는 과정을 추억으로 남기고 싶어서 영상으로 찍어 보았어요. 혹시 저처럼 자녀의 코딩 교육을 고민하고 계신 부모님들께 도움이 될 수 있지 않을까 싶기도 해서 유튜브에 올려봅니다. 📺 첫 영상:&nbsp;youtu.be/LtH7mv9n-vA 아들 녀석의 엉뚱한 질문과 돌발 행동 때문에 진땀을 뺐네요 ㅋㅋㅋ 아이가 괜히 저 때문에 코딩을 싫어하게 될까봐 걱정도 되지만, 아이랑 즐겁게 배우면서, 저도 같이 성장해보려 합니다. 코딩을 처음 접하는 아이와, 아이에게 처음 코딩을 가르쳐보는 아빠의 좌충우돌 도전기 💪많이 응원해 주세요! #달레의코드 #방학프로젝트 #아빠와코딩

👦🐍 7살 아이에게 파이썬을 가르칠 수 있을까요?

기다리던 이일민님의 시리즈 강의, "로드맵; 토비의 클린 스프링"의 첫 주제인
도메인 모델 패턴과 헥사고날 아키텍처 Part 1
이 얼마전 공개되었다. 재작년 말 로드맵이 공개되었을 때 가장 관심이 갔던 주제였기에, 출시 소식을 듣자마자 구매했다. 하지만 늘 그렇듯 집중해서 봐야지 하는 마음에 차일피일 미루고만 있었다. 그러다 최근 이일민님께 "강의 수강이나 하시죠"라는 다정한(?) 압박 메시지를 받고서야, 지난 한 주간 시간을 내어 완강했다.

강의는 언제나처럼 이일민님 특유의 사려 깊고 친절한 설명으로 가득했다. 특히 라이브 코딩을 진행하는 방식은 감탄을 자아냈다. 현재 어떤 생각을 하고 있고, 어떤 의도로 다음 코드를 작성하는지를 차분히 설명하며 진행하는 모습을 보고 있으면, 어떻게 이런 수준의 강의를 만들어낼 수 있는지 놀라울 따름이다. 그 과정을 찬찬히 따라가다 보면, 마치 내가 이일민님이 된 것처럼 그의 사고 흐름을 그대로 느끼며 자바와 스프링으로 애플리케이션을 개발할 때 도메인 모델 패턴과 헥사고날 아키텍처를 어떻게 적용할 수 있는지를 경험하게 된다. 시간이 지나면 누구나 자연스레 잊어버리는 초심자의 어려움을 어쩌면 이리도 잘 기억하고 정확히 짚어주는지, 그 깊은 공감 능력에 다시 한번 감탄했다.

하지만 이 강의에서 기술적인 내용보다 더 인상 깊었던 것은, 전문가로서 기술을 대하는 태도와 학습하는 방법을 온몸으로 보여준다는 점이었다.

첫째는
기술을 어떻게 학습해야 하는가
에 대한 모범 답안을 제시한다는 점이다. 헥사고날 아키텍처를 설명할 때, 헥사고날 아키텍처를 처음 제안한 앨리스터 코번의 원문과 핵심 주장을 기반으로 내용을 전개한다. 너무나 당연한 접근법 같지만, 생각보다 많은 이들이 원천 기술을 만든 사람이나 조직의 1차 자료가 아닌, 2차, 3차로 가공된 콘텐츠를 통해 기술을 학습한다. 물론 가공된 콘텐츠가 더 이해하기 쉬울 수는 있다. 하지만 그 과정에서 원저자의 의도는 희석되고 다른 사람의 해석이 덧붙여질 수밖에 없다. 이 때문에 기술의 본질을 오해하는 경우도 종종 발생한다. 내가 평소 구성원들에게 "어떤 기술을 익힐 때는 반드시 공식 문서를 먼저 보라"고 권하는 이유와 정확히 같은 맥락이다.

둘째는
자신만의 논리를 갖추는 것
이 왜 중요한지 보여준다는 점이다. "Entity vs DTO" 수업에서 프리젠테이션 계층에서 엔티티를 사용하는 것이 왜 문제가 되지 않는지에 대한 자신의 견해를 하나하나 논리적으로 증명해 나간다. 개발자라면 어떤 기술적 결정을 내렸을 때, 그 이유를 타인의 권위(책, 블로그 등)가 아닌 자신만의 논리로 설명할 수 있어야 한다. 이 또한 모두가 당연하게 여기지만 실제로 해내는 사람은 드물다. 이일민님은 그 당연한 것을 어떻게 하는지 명확히 보여준다.

이일민님의 저서나 강의를 접할 때면, 나는 개발 지식뿐만 아니라 한 분야의 전문가로서 가져야 할 태도와 자세에 대해 참 많이 배우게 된다. 이번 강의 역시 기술적인 깊이는 물론, 그 너머의 것들을 곱씹어볼 수 있는 귀중한 시간이었다.

글이 길어져 강의의 기술적인 부분에 대한 이야기는 다음 파트가 출시되면 다시 한번 기회를 만들어보려 한다. (과연 지킬 수 있을지는 모르겠지만 말이다) 다만
도메인 모델 패턴
과
애플리케이션 아키텍처
에 대해 깊이 있는 이해와 함께 좋은 개발자의 태도를 배우고 싶다면, 주저 말고 이 강의를 수강해 보기를 강력히 권하고 싶다.

기다리던 이일민님의 시리즈 강의, "로드맵; 토비의 클린 스프링"의 첫 주제인 <code>도메인 모델 패턴과 헥사고날 아키텍처 Part 1</code> 이 얼마전 공개되었다. 재작년 말 로드맵이 공개되었을 때 가장 관심이 갔던 주제였기에, 출시 소식을 듣자마자 구매했다. 하지만 늘 그렇듯 집중해서 봐야지 하는 마음에 차일피일 미루고만 있었다. 그러다 최근 이일민님께 "강의 수강이나 하시죠"라는 다정한(?) 압박 메시지를 받고서야, 지난 한 주간 시간을 내어 완강했다. 강의는 언제나처럼 이일민님 특유의 사려 깊고 친절한 설명으로 가득했다. 특히 라이브 코딩을 진행하는 방식은 감탄을 자아냈다. 현재 어떤 생각을 하고 있고, 어떤 의도로 다음 코드를 작성하는지를 차분히 설명하며 진행하는 모습을 보고 있으면, 어떻게 이런 수준의 강의를 만들어낼 수 있는지 놀라울 따름이다. 그 과정을 찬찬히 따라가다 보면, 마치 내가 이일민님이 된 것처럼 그의 사고 흐름을 그대로 느끼며 자바와 스프링으로 애플리케이션을 개발할 때 도메인 모델 패턴과 헥사고날 아키텍처를 어떻게 적용할 수 있는지를 경험하게 된다. 시간이 지나면 누구나 자연스레 잊어버리는 초심자의 어려움을 어쩌면 이리도 잘 기억하고 정확히 짚어주는지, 그 깊은 공감 능력에 다시 한번 감탄했다. 하지만 이 강의에서 기술적인 내용보다 더 인상 깊었던 것은, 전문가로서 기술을 대하는 태도와 학습하는 방법을 온몸으로 보여준다는 점이었다. 첫째는 <code>기술을 어떻게 학습해야 하는가</code>에 대한 모범 답안을 제시한다는 점이다. 헥사고날 아키텍처를 설명할 때, 헥사고날 아키텍처를 처음 제안한 앨리스터 코번의 원문과 핵심 주장을 기반으로 내용을 전개한다. 너무나 당연한 접근법 같지만, 생각보다 많은 이들이 원천 기술을 만든 사람이나 조직의 1차 자료가 아닌, 2차, 3차로 가공된 콘텐츠를 통해 기술을 학습한다. 물론 가공된 콘텐츠가 더 이해하기 쉬울 수는 있다. 하지만 그 과정에서 원저자의 의도는 희석되고 다른 사람의 해석이 덧붙여질 수밖에 없다. 이 때문에 기술의 본질을 오해하는 경우도 종종 발생한다. 내가 평소 구성원들에게 "어떤 기술을 익힐 때는 반드시 공식 문서를 먼저 보라"고 권하는 이유와 정확히 같은 맥락이다. 둘째는 <code>자신만의 논리를 갖추는 것</code>이 왜 중요한지 보여준다는 점이다. "Entity vs DTO" 수업에서 프리젠테이션 계층에서 엔티티를 사용하는 것이 왜 문제가 되지 않는지에 대한 자신의 견해를 하나하나 논리적으로 증명해 나간다. 개발자라면 어떤 기술적 결정을 내렸을 때, 그 이유를 타인의 권위(책, 블로그 등)가 아닌 자신만의 논리로 설명할 수 있어야 한다. 이 또한 모두가 당연하게 여기지만 실제로 해내는 사람은 드물다. 이일민님은 그 당연한 것을 어떻게 하는지 명확히 보여준다. 이일민님의 저서나 강의를 접할 때면, 나는 개발 지식뿐만 아니라 한 분야의 전문가로서 가져야 할 태도와 자세에 대해 참 많이 배우게 된다. 이번 강의 역시 기술적인 깊이는 물론, 그 너머의 것들을 곱씹어볼 수 있는 귀중한 시간이었다. 글이 길어져 강의의 기술적인 부분에 대한 이야기는 다음 파트가 출시되면 다시 한번 기회를 만들어보려 한다. (과연 지킬 수 있을지는 모르겠지만 말이다) 다만 <code>도메인 모델 패턴</code> 과 <code>애플리케이션 아키텍처</code> 에 대해 깊이 있는 이해와 함께 좋은 개발자의 태도를 배우고 싶다면, 주저 말고 이 강의를 수강해 보기를 강력히 권하고 싶다.

전문가의 태도를 배울 수 있는 강의

7월 27일부터 15주간 진행되는 리트코드 스터디 5기를 모집합니다! 본 스터디는 100% 비대면으로 리트코드에서 제공하는 blined 75 문제를 진행하며 GitHub과 디스코드에서 진행됩니다. 스터디 진행 방식에 대한 더 자세한 내용은 위키를 참조 바랍니다. 모집 기간 2025년 6/18(수) - 7/13(토) 진행 기간 2025년 7/20(일) ...

리트코드 스터디 5기 모집 공지 · DaleStudy/leetcode-study · Discussion #1599

코딩 테스트, 해외 취업 인터뷰, 그리고 꾸준한 알고리즘 실력 향상을 목표로 하시는 분들을 위한 리트코드 스터디가 돌아왔습니다.

이번 5기는 약 15주간 Blind 75 문제를 중심으로 진행됩니다. 혼자 하면 작심삼일, 함께 하면 꾸준한 성장의 시작입니다.

💡 어떤 스터디인가요?
- 본인 수준에 따라 매주 2~5문제씩 풀며 알고리즘 실력을 체계적으로 쌓습니다
- GitHub에서 답안 PR 제출과 상호 코드 리뷰를 통해 실전 감각을 기릅니다
- Discord을 통한 질문/답변과 교류로 혼자보다 더 빠르게 성장합니다

🗓️ 일정
- 모집 기간: 2025년 7월 7일(월) ~ 7월 13일(일)
- 스터디 기간: 2025년 7월 20일(일) ~ 11월 1일(토)

👥 이런 분께 추천합니다
- 코딩 테스트/인터뷰 준비가 막막하신 분
- 알고리즘 실력을 체계적으로 쌓고 싶은 분
- 동료 개발자들과 함께 성장하고 싶은 분

📍참여 방법
자세한 내용과 신청은 GitHub Discussion에서 확인해주세요:
https://github.com/DaleStudy/leetcode-study/discussions/1599

🧵 함께하는 힘을 믿습니다. 이번 여름, 여러분의 도전을 응원합니다!

코딩 테스트, 해외 취업 인터뷰, 그리고 꾸준한 알고리즘 실력 향상을 목표로 하시는 분들을 위한 리트코드 스터디가 돌아왔습니다. 이번 5기는 약 15주간 Blind 75 문제를 중심으로 진행됩니다. 혼자 하면 작심삼일, 함께 하면 꾸준한 성장의 시작입니다. 💡 어떤 스터디인가요? - 본인 수준에 따라 매주 2~5문제씩 풀며 알고리즘 실력을 체계적으로 쌓습니다 - GitHub에서 답안 PR 제출과 상호 코드 리뷰를 통해 실전 감각을 기릅니다 - Discord을 통한 질문/답변과 교류로 혼자보다 더 빠르게 성장합니다 🗓️ 일정 - 모집 기간: 2025년 7월 7일(월) ~ 7월 13일(일) - 스터디 기간: 2025년 7월 20일(일) ~ 11월 1일(토) 👥 이런 분께 추천합니다 - 코딩 테스트/인터뷰 준비가 막막하신 분 - 알고리즘 실력을 체계적으로 쌓고 싶은 분 - 동료 개발자들과 함께 성장하고 싶은 분 📍참여 방법 자세한 내용과 신청은 GitHub Discussion에서 확인해주세요: https://github.com/DaleStudy/leetcode-study/discussions/1599 🧵 함께하는 힘을 믿습니다. 이번 여름, 여러분의 도전을 응원합니다!

lnkd.in

프론트엔드 개발자

현지

#프론트엔드 #개발자 #끊임없이배우기

스타트업 프론트엔드 개발자

윤세희

소프트웨어 엔지니어

조혜린

📢 리트코드 스터디 5기 모집합니다!

달레

캐나다🇨🇦에 살면서 미국🇺🇸 회사에서 일하는 한국🇰🇷 개발자입니다. 🧑‍💻
블로그 쓰는 거에 진심이고 취미로 유튜브도 하고 있어요 :)
✍️ https://www.daleseo.com
📺 https://www.youtube.com/@DaleSeo

📢 리트코드 스터디 5기 모집합니다!

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필