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

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

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

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

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

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

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

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

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

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

안녕하세요 현재 코딩을 배운지 5년된 고등학생입니다.. 제 개인적인 생각으로는 저도 꽤 어린 나이에 코딩에 입문했지만 제 개인적으로 아직까지 후회하는 점이 쪼금 코딩 언어를 쉽고 재미있게 시작하는게 좋지 않았을까..?라는 생각이 듭니다. 당연히 전문가이신 선생님께서도 아시겠지만 코딩 언어는 달달 외운다라는 느낌보다도 활용하는 부분이 크다고 생각합니다. 또한 어린 나이에서 자녀분께서 현재 배우는 파이썬은 요즘 고등학생들이 배우는 과목입니다. 그래서 그런지 물론 개발 언어치고는 (자바나 시플플 같은) 언어보다는 쉽기에 입문용으로는 적합하다고 생각하지만 그래도 자녀분께서 배우시기엔 쪼금 난이도가 있다는 생각이 듭니다..     물론 전문가 분이시니까 저보다 많은 것을 알고 교육적인 측면에서도 훌용하시겠지만, 제가 쪼금 더 오지랖을 보려서 추천드리자면 엔트리라는 사이트를 활용해서 자녀분 교육을 한번 해보시는게 어떨까요..? 코딩 공부를 쉽게 시작할 수 있고 무엇보다도 자신이 직접 코딩을 하면서 결과를 쉽게 보여주거든요..! 정말 제가 오지랖이 넓어서 한번 이렇게 글을 써봅니다..!

클로드 코드 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리그 프로그래머

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

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

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

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

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

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

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

https://youtu.be/4j5kz9k_deQ

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

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

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

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

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

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

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

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

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

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

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

바이브 코딩 - 개발자들이 하는거

바이브 개발 - 일반사람이 하는거

이렇게 구분할 필요가 있고, 1~2년 이내에 바이브 개발로도 본격적인 소프트웨어 개발을 할 수 있다고 본다.

즉, 미래는 바이브 코딩이 아니라 바이브 개발에 있음. 폰 노이만에 따르면 코딩(프로그래밍)은 뇌 없이 하는 단순 업무일뿐이라..(제가 한 얘기 아닙니다. 😏)

하지만 개발자가 사라지느냐면 그건 아니고, 전문직으로써 개발자들은 지금의 플랫폼 엔지니어, SRE 같은 역할을 할 것이라고 본다.

바이브 코딩 - 개발자들이 하는거 바이브 개발 - 일반사람이 하는거 이렇게 구분할 필요가 있고, 1~2년 이내에 바이브 개발로도 본격적인 소프트웨어 개발을 할 수 있다고 본다. 즉, 미래는 바이브 코딩이 아니라 바이브 개발에 있음. 폰 노이만에 따르면 코딩(프로그래밍)은 뇌 없이 하는 단순 업무일뿐이라..(제가 한 얘기 아닙니다. 😏) 하지만 개발자가 사라지느냐면 그건 아니고, 전문직으로써 개발자들은 지금의 플랫폼 엔지니어, SRE 같은 역할을 할 것이라고 본다.

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

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

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

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

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

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

Achieving specific goals and legacies in BitLife is incredibly rewarding.

https://bitlife66.github.io/

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

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

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

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

www.55check.com공유하기게시하기웹에서 보기구독하기#오늘의 세계1. 레슬러 헐크 호건(71) 심장마비로 사망. 귀에 손을 대는 제스처를 처음 유행시킨 분.2. 태국-캄보디아 국경 충돌. 민간인 포함 14명 사망. 전투기도 뜨고 난리. 하지만 해당 지역을 제외하면 방문객 안전은 OK. 둘 다 관광으로 먹고사는 나라들이라 오래 싸우진 않을 듯.3. 프랑스, 강대국 중 처음으로 팔레스타인을 국가로 인정하기로. 9월 예정. 미국이 반대 중이라서 실행 여부는 가봐야 알 듯.4. 미국 주식 어제까지 계속 안정적 상승. 단 오늘 가상화폐들은 하락 중.5. 한미 관세협상 비상상황. 하긴 하는 건가? 미국은 한국 대표단 피하고, 주미대사와 주한대사도 모두 공석 중. 트럼프 vs. 한국 민주당 정권 양측이 서로를 불신하고 성의도 없음. 협상 빠그러져도 양쪽은 국내정치적 이득.트럼프, FED 공사장 찾아가 파월 등짝 스매시 어제 트럼프가 미국의 중앙은행인 연방준비위원회(Fed)를 찾아가 건물 리노베이션 공사현장을 둘러봄.방문 이유: Fed가 진행중인 본점 리노베이션 공사비가 3~4조원에서 계속 불어나는 중. 그래서 트럼프가 직접 체크하겠다는 것.물론 현장을 방문해 '너네 내 말대로 금리 안 낮추냐?' 압박하려는 의도가 큼.공사비 초과와 세금 낭비는 객관적으로 봐도 파월의 잘못이 확실하므로 파월은 잔뜩 위축된 느낌. 트럼프가 '다 좋은데, 금리를 낮추면 좋을텐데!'하면서 갑자기 등을 때리자 움찔. (하이라이트 영상)하지만 트럼프는 기

2025년 7월 25일 (금) 뉴스 클리핑 & 동동의 테크 타운 : 오호츠크 리포트

1. 트럼프가 어제 3개 AI 관련 행정명령에 서명. 원문은 여기.
    주요 내용: 
    * 반도체·AI 컴퓨팅 통제 강화: 반도체 제조 미 본토 복귀, 첨단 AI 컴퓨팅 자원이 적대국에 안 넘어가도록 수출 통제 대폭 강화. 
    * 자유로운 표현과 미국적 가치 보호: AI 시스템이 특정 이념에 치우치지 않도록 '다양성·형평성·포괄성', '기후변화' 관련 언급 삭제 권고. ESG 관련된 AI 규제도 없애겠다고. AI회사에 전력 공급하려던 신재생에너지 기업들에는 배드 뉴스. 
    * 국방 AI 최전선 배치: 국방부가 AI를 전쟁 수행과 후방 업무에 적극 통합. 
    * 악의적 딥페이크 대응: NIST가 '법의학 증거 수호자' 평가 프로그램 검토 중. 법무부는 사법기관용 딥페이크 대응 표준 마련 예정.
    이런 내용들이 정말 꼼꼼하게 담겼습니다. 꼭 한 번 자세히 읽어보시라고, 오호츠크 리포트에서 적절한 길이로 요약해서 번역했습니다. 


 2. 구글, AI로 돈 잘 벌어서 역대 최고 매출 찍었는데...
 3. ... 검색 링크 클릭은 줄어든다
 4. 마이크로소프트, 깃헙으로 바이브 코딩 시장 늦게 합류 🚀
 5. 저커버그가 인당 140억+ 준 AI 인재들, 중국계가 절반, 한국인은?!


https://55check.com/newsletters/?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&bmode=view&idx=167032584&t=board


여기에서 살펴보세요.

<ol ><li>트럼프가 어제 3개 AI 관련 행정명령에 서명. 원문은 여기.주요 내용:&nbsp;<ul ><li>반도체·AI 컴퓨팅 통제 강화: 반도체 제조 미 본토 복귀, 첨단 AI 컴퓨팅 자원이 적대국에 안 넘어가도록 수출 통제 대폭 강화.&nbsp;</li><li>자유로운 표현과 미국적 가치 보호:&nbsp;AI 시스템이 특정 이념에 치우치지 않도록 '다양성·형평성·포괄성', '기후변화' 관련 언급 삭제 권고. ESG 관련된 AI 규제도 없애겠다고. AI회사에 전력 공급하려던 신재생에너지 기업들에는 배드 뉴스.&nbsp;</li><li>국방 AI 최전선 배치:&nbsp;국방부가 AI를 전쟁 수행과 후방 업무에 적극 통합.&nbsp;</li><li>악의적 딥페이크 대응: NIST가 '법의학 증거 수호자' 평가 프로그램 검토 중. 법무부는 사법기관용 딥페이크 대응 표준 마련 예정.</li></ul>이런 내용들이 정말 꼼꼼하게 담겼습니다. 꼭 한 번 자세히 읽어보시라고, 오호츠크 리포트에서 적절한 길이로 요약해서 번역했습니다.&nbsp;</li></ol> <ol start="2"><li>구글, AI로 돈 잘 벌어서 역대 최고 매출 찍었는데...</li><li>... 검색 링크 클릭은 줄어든다</li><li>마이크로소프트, 깃헙으로 바이브 코딩 시장 늦게 합류 🚀 </li><li>저커버그가 인당 140억+ 준 AI 인재들, 중국계가 절반, 한국인은?! </li></ol> https://55check.com/newsletters/?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&amp;bmode=view&amp;idx=167032584&amp;t=board 여기에서 살펴보세요.

55check.com

7월 넷째주 : 트럼프 AI 액션플랜 발표, 미국이 AI 기술 가져간다.

안녕하세요. 그린입니다 🍏이번 포스팅은 Swift 컴파일러의 타입 추론 과정에 대해 깊이 있게 알아보겠습니다 🙋🏻Swift Type Inference Deep DiveSwift 개발을 하다 보면 한 번쯤 마주치는 상황이 있죠.let result = data .map { $0.someProperty } .flatMap { $0.transform() } .compactMap { $0.process() } 이런 코드를 작성하고 빌드를 돌렸는데...컴파일러가 몇 분씩 돌아가거나 아예 "expression was too complex" 에러를 뱉어내는 경우 말이에요 😅 왜 이런 일이 일어나는 걸까요?그 답은 Swift의 강력하지만 복잡한 타입 추론 시스템에 있습니다. Why Type Inf..

Swift 컴파일러의 타입 추론 파헤치기 (feat. 왜 이렇게 컴파일이 오래 걸릴까?)

Swift에서 한 줄로 멋지게 체이닝한 코드, 컴파일만 돌리면 한참 걸리거나 "expression was too complex" 에러... 경험 있으시죠? 😭

이유는 Swift의 타입 추론 시스템이 매우 강력하지만 동시에 매우 복잡하기 때문입니다.


Swift의 제약 기반 타입 체커가 어떻게 동작하는지, 어떤 코드가 지수적으로 컴파일 시간을 늘리는지, 그리고 이를 어떻게 개선할 수 있는지를 정리해봤습니다 🙋🏻

Swift에서 한 줄로 멋지게 체이닝한 코드, 컴파일만 돌리면 한참 걸리거나 "expression was too complex" 에러... 경험 있으시죠? 😭 이유는 Swift의 타입 추론 시스템이 매우 강력하지만 동시에 매우 복잡하기 때문입니다. Swift의 제약 기반 타입 체커가 어떻게 동작하는지, 어떤 코드가 지수적으로 컴파일 시간을 늘리는지, 그리고 이를 어떻게 개선할 수 있는지를 정리해봤습니다 🙋🏻

iOYES

Swift 컴파일이 느리다면?

　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% 개발자들의 멘토링

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

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

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

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

"배포했으면 스펙이지"

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


보통 포트폴리오라고 하면 대단히 업무적인 내용만 담긴 딱딱한 문서로 느껴집니다. 그런데 이 포트폴리오는 그 틀을 깨고 지극히 개인적인 과거의 역사 속 사례를 꺼내어 풀어낸 점이 신선했습니다. 파격적이라는 인상을 주는 동시에 실제 입사 지원 시에도 긍정적인 평가를 받을 수 있을 것이라고 생각합니다.
물론 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초가 걸립니다.”⠀경험의 멸종, 크리스틴 로젠

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

기다리던 이일민님의 시리즈 강의, "로드맵; 토비의 클린 스프링"의 첫 주제인
도메인 모델 패턴과 헥사고날 아키텍처 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> 에 대해 깊이 있는 이해와 함께 좋은 개발자의 태도를 배우고 싶다면, 주저 말고 이 강의를 수강해 보기를 강력히 권하고 싶다.

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

잡스는 한 인터뷰에서 다음과 같은 말을 했다고 합니다.
A급 인재는 A급 인재를 데려와 대단한 작품을 만들어 내지만,
B급 인재는 C급, D급 인재를 데려와 골목대장이나 하며 형편없는 것들을 만들어 낸다.
#스티브잡스

잡스는 한 인터뷰에서 다음과 같은 말을 했다고 합니다.A급 인재는 A급 인재를 데려와 대단한 작품을 만들어 내지만,B급 인재는 C급, D급 인재를 데려와 골목대장이나 하며 형편없는 것들을 만들어 낸다.#스티브잡스

퍼블리의 그로스 매니저로 커리어를 시작하여, 현재는 멤버십 사업을 총괄하고 있습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책과 교육, 경제에 관심을 가지고 있습니다.
일하는 것을 싫어하지만, 많이 하고 있습니다..

커리어리 Lead Product Manager

김광종

퍼블리 그로스매니저로 커리어를 시작하여, 프로덕트매니저와 사업총괄을 거쳐, 커리어리팀을 리드하였습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책/교육/경제에 관심이 있습니다.
자유로운 삶을 추구하지만, 지금은 일에 매여 있습니다..

A급인재

댓글 0

함께 읽은 게시물

비슷한 게시물

주간 인기 TOP 10

추천 프로필