AI 시대에 신입/주니어가 유리할까, 시니어가 유리할까라는 질문이 계속 화두가 되고 있는데, 나는 신입/주니어가 유리할거라는 입장이다. (일단 소프트웨어 개발업 한정)

이유는 경험적인 측면에서 봤을 때, 시니어는 경험에 집착해 새로운 기술을 잘 받아들이지 못하는 경향이 있었기 때문이다.

예를들면, 사용자 관리 시스템에 그룹 기능이 없는데 이걸 만들어야하는 상황을 생각해보자.

관련 경험이 있는 시니어는 머릿속에 그림이 촤좌작 나올 것이다. 그리고 그걸 AI에게 물어보는 것 보다 직접 구현하는 것이 더 빠를 것이다.

그리고 AI한테 물어보더라도 자기 머릿속에 그림이 이미 있기 때문에, 원하는 답을 못얻어서 불필요한 삽질을 했다고 생각할 것이다.

신입/주니어는 처음부터 AI에게 물어보고 구현시킬 것이다. 다양한 예외 상황을 고려하지 못해 완성도가 낮거나 반대로 오버엔지니어링을 할 가능성이 높지만, 구현 기간은 아마도 시니어와 비슷하거나 더 빠를 수 있다.

그런데, 여기서 중요한 질문이 있다.

“내년이 되면 완성도 차이가 얼마나 날까?”

소프트웨어 개발은 구현에 있어서는 대체로 명백한 답이 없는 분야이기 때문에 이 질문은 이를 판단하는데 매우 중요하다.

다만, 최근에 몇몇 경험을 통해 그게 아닐수도 있겠다는 생각을 했다. 오히려 반대인 경우가 꽤 있었기 때문이다.

내 주변만 그런지 소프트웨어 개발자만 그런지는 모르겠지만, 시니어리티가 높아질 수록 답이 정해져 있지 않다는 생각을하는 반면, 주니어일수록 하나의 답을 찾으려하거나 자신이 배운 좁은 범위로만 생각을 한정하려는 경향이 있었다.

처음에 전제했던 말과 반대되는 말이지만, 만일 이게 일반적이라면 AI 시대에 유리한 것은 시니어일 것이다.

갑작스런 논리의 도약이긴하지만, 이를보면 AI 경쟁력 강화에 있어 0순위는 교육의 패러다임을 바꾸는 것이다.

AI 시대의 대비는 국가적으로 AI 기술을 내재화하는 것만이 중요한 것이 아니다. 오히려 교육 시스템을 모조리 바꾸는 것이야말로 다음 시대를 준비하기위해 가장 시급하고 중요한 일이 아닐까싶다.

AI 시대에 신입/주니어가 유리할까, 시니어가 유리할까라는 질문이 계속 화두가 되고 있는데, 나는 신입/주니어가 유리할거라는 입장이다. (일단 소프트웨어 개발업 한정) 이유는 경험적인 측면에서 봤을 때, 시니어는 경험에 집착해 새로운 기술을 잘 받아들이지 못하는 경향이 있었기 때문이다. 예를들면, 사용자 관리 시스템에 그룹 기능이 없는데 이걸 만들어야하는 상황을 생각해보자. 관련 경험이 있는 시니어는 머릿속에 그림이 촤좌작 나올 것이다. 그리고 그걸 AI에게 물어보는 것 보다 직접 구현하는 것이 더 빠를 것이다. 그리고 AI한테 물어보더라도 자기 머릿속에 그림이 이미 있기 때문에, 원하는 답을 못얻어서 불필요한 삽질을 했다고 생각할 것이다. 신입/주니어는 처음부터 AI에게 물어보고 구현시킬 것이다. 다양한 예외 상황을 고려하지 못해 완성도가 낮거나 반대로 오버엔지니어링을 할 가능성이 높지만, 구현 기간은 아마도 시니어와 비슷하거나 더 빠를 수 있다. 그런데, 여기서 중요한 질문이 있다. “내년이 되면 완성도 차이가 얼마나 날까?” 소프트웨어 개발은 구현에 있어서는 대체로 명백한 답이 없는 분야이기 때문에 이 질문은 이를 판단하는데 매우 중요하다. 다만, 최근에 몇몇 경험을 통해 그게 아닐수도 있겠다는 생각을 했다. 오히려 반대인 경우가 꽤 있었기 때문이다. 내 주변만 그런지 소프트웨어 개발자만 그런지는 모르겠지만, 시니어리티가 높아질 수록 답이 정해져 있지 않다는 생각을하는 반면, 주니어일수록 하나의 답을 찾으려하거나 자신이 배운 좁은 범위로만 생각을 한정하려는 경향이 있었다. 처음에 전제했던 말과 반대되는 말이지만, 만일 이게 일반적이라면 AI 시대에 유리한 것은 시니어일 것이다. 갑작스런 논리의 도약이긴하지만, 이를보면 AI 경쟁력 강화에 있어 0순위는 교육의 패러다임을 바꾸는 것이다. AI 시대의 대비는 국가적으로 AI 기술을 내재화하는 것만이 중요한 것이 아니다. 오히려 교육 시스템을 모조리 바꾸는 것이야말로 다음 시대를 준비하기위해 가장 시급하고 중요한 일이 아닐까싶다.

역시 속도/메모리 최적화가 제일 재미나다. 결과가 한 눈에 바로 보이니 도파민이 바로 촥~. 다만, 이 이상 쥐어짜려면 결국은 직접 만들어야 하는데.. 그게 젤 재미난데.. 가성비 생각 안하면 직접 만드는게 젤 재미난데.. 🥹

역시 속도/메모리 최적화가 제일 재미나다. 결과가 한 눈에 바로 보이니 도파민이 바로 촥~. 다만, 이 이상 쥐어짜려면 결국은 직접 만들어야 하는데.. 그게 젤 재미난데.. 가성비 생각 안하면 직접 만드는게 젤 재미난데.. 🥹

이제 처음 개발에 뛰어드는 사람들이 AI를 통해 뭔가를 만들 때 버셀, 수파베이스 같은 걸로 서비스 하는 사람들이 대부분 아닐까요?

호구 개발자를 위한 비즈니스

이제 처음 개발에 뛰어드는 사람들이 AI를 통해 뭔가를 만들 때 버셀, 수파베이스 같은 걸로 서비스 하는 사람들이 대부분 아닐까요?

하지만 서비스가 커지기 시작했을 때 이들에게 지불해야 하는 가격은 잘 계산해보지 않는 것 같습니다.
그건 그때가서 생각해보자는 마음으로.

버셀이나 수파베이스 창업자는 “맞아 맞아, 그때가서 생각해보면 돼!” 하고 함박웃음을 지으며 맞장구를 쳐줄 것 같네요.

물론 그때가서 생각해봐도 됩니다. 빨리 빠져나올 수 있는 실력이 있다면요.
하지만 컴퓨터공학에 대한 지식 없이는 쉽지 않을 겁니다.
겨우 벌기 시작한 돈을 그들에게 다 갖다 바치는 꼴이 될 수 있습니다.

사실 이게 지금 일어나고 있는 일들입니다.
그러니깐… 컴퓨터공학을 하나도 모르고 뛰어드는 뉴비들의 돈을 받아 먹는 커다란 비즈니스가 열리고 있습니다.

계속 컴퓨터 공학을 깊이 파고 들어야 하는 이유가 여기있습니다.
어떤 사람은 겨우 수익이 나기 시작한 서비스에 월 100만 원을 쓰는데, 어떤 사람은 돈을 전혀 내지 않고 서비스를 운영합니다.
운영 비용을 절감하는 것도 실력입니다. 엄청난 경쟁 우위 아닌가요?
AI로 코딩을 하면서 뭔가를 만들어 보고 즐거움을 느끼는 것은 좋지만, 더 깊숙한 곳으로 들어가려고 노력하지 않는다면 결국에는 차이를 만들어 낼 수 없습니다.


https://jeho.page/essay/2025/09/08/sucker-developer.html

이제 처음 개발에 뛰어드는 사람들이 AI를 통해 뭔가를 만들 때 버셀, 수파베이스 같은 걸로 서비스 하는 사람들이 대부분 아닐까요? 하지만 서비스가 커지기 시작했을 때 이들에게 지불해야 하는 가격은 잘 계산해보지 않는 것 같습니다. 그건 그때가서 생각해보자는 마음으로. 버셀이나 수파베이스 창업자는 “맞아 맞아, 그때가서 생각해보면 돼!” 하고 함박웃음을 지으며 맞장구를 쳐줄 것 같네요. 물론 그때가서 생각해봐도 됩니다. 빨리 빠져나올 수 있는 실력이 있다면요. 하지만 컴퓨터공학에 대한 지식 없이는 쉽지 않을 겁니다. 겨우 벌기 시작한 돈을 그들에게 다 갖다 바치는 꼴이 될 수 있습니다. 사실 이게 지금 일어나고 있는 일들입니다. 그러니깐… 컴퓨터공학을 하나도 모르고 뛰어드는 뉴비들의 돈을 받아 먹는 커다란 비즈니스가 열리고 있습니다. 계속 컴퓨터 공학을 깊이 파고 들어야 하는 이유가 여기있습니다. 어떤 사람은 겨우 수익이 나기 시작한 서비스에 월 100만 원을 쓰는데, 어떤 사람은 돈을 전혀 내지 않고 서비스를 운영합니다. 운영 비용을 절감하는 것도 실력입니다. 엄청난 경쟁 우위 아닌가요? AI로 코딩을 하면서 뭔가를 만들어 보고 즐거움을 느끼는 것은 좋지만, 더 깊숙한 곳으로 들어가려고 노력하지 않는다면 결국에는 차이를 만들어 낼 수 없습니다. https://jeho.page/essay/2025/09/08/sucker-developer.html

K리그 프로그래머

AI시대에도 컴퓨터 공학을 공부해야 하는 이유

1 자기소개는 생략하세요
포트폴리오가 곧 자기소개입니다. 바로 프로젝트 얘기 들어가세요

2 면접관은 정답 몰라요
데이터와 맥락으로 설득하는 게 훨씬 먹힙니다

3 UI 스샷 덜어내세요
결과물보다 과정이 보여야 포트폴리오입니다

4 “왜”를 준비하세요
열 질문 중 일곱은 “왜 그렇게 했나요?”입니다

5 성과=수치+맥락
숫자만 말하지 말고 스토리까지 붙여야 기억에 남습니다

6 협업은 숨기지 마세요
혼자 다 했다, 실무에선 마이너스입니다

7 AI는 치트키가 아니라 부스터
“썼다”보다 “시간 50% 줄였다”가 훨씬 설득력 있어요

8 디자인 시스템=룰
툴 자랑 말고 실제 협업, 운영 경험을 강조하세요

9 지원시 저자세는 금물
“내가 기여할 문제”로 지원 동기를 말하세요

10 불합격=피드백
루프 돌리면 확률은 결국 올라갑니다

1 자기소개는 생략하세요포트폴리오가 곧 자기소개입니다. 바로 프로젝트 얘기 들어가세요 2 면접관은 정답 몰라요데이터와 맥락으로 설득하는 게 훨씬 먹힙니다 3 UI 스샷 덜어내세요결과물보다 과정이 보여야 포트폴리오입니다 4 “왜”를 준비하세요열 질문 중 일곱은 “왜 그렇게 했나요?”입니다 5 성과=수치+맥락숫자만 말하지 말고 스토리까지 붙여야 기억에 남습니다 6 협업은 숨기지 마세요혼자 다 했다, 실무에선 마이너스입니다 7 AI는 치트키가 아니라 부스터“썼다”보다 “시간 50% 줄였다”가 훨씬 설득력 있어요 8 디자인 시스템=룰툴 자랑 말고 실제 협업, 운영 경험을 강조하세요 9 지원시 저자세는 금물“내가 기여할 문제”로 지원 동기를 말하세요 10 불합격=피드백루프 돌리면 확률은 결국 올라갑니다

UX 취업 치트키 10

1. 아직 큰 성과를 거두기 전인 넥스트에서 일하던 시절, 스티브 잡스는 한 인터뷰에서 이렇게 말했다.

2. 단순한 사실 한 가지만 깨달으면 인생의 폭이 훨씬 넓어질 수 있다. 그건 바로 우리가 '일상'이라고 부르는 건 모두 우리보다 별로 똑똑할 것 없는 사람들이 만들어낸 것이라는 사실이다.

3. 그리고 우리는 그걸 바꾸거나, 거기에 영향을 미치거나, 자신만의 뭔가를 만들어 타인이 좀 더 지혜롭고 편하게 사용하도록 할 수 있다.

4. 이 사실을 깨닫고 나면 다시는 세상이 예전 같지 않을 것이다.


#타이탄의도구들

1. 아직 큰 성과를 거두기 전인 넥스트에서 일하던 시절, 스티브 잡스는 한 인터뷰에서 이렇게 말했다. ​2. 단순한 사실 한 가지만 깨달으면 인생의 폭이 훨씬 넓어질 수 있다. 그건 바로 우리가 '일상'이라고 부르는 건 모두 우리보다 별로 똑똑할 것 없는 사람들이 만들어낸 것이라는 사실이다. ​3. 그리고 우리는 그걸 바꾸거나, 거기에 영향을 미치거나, 자신만의 뭔가를 만들어 타인이 좀 더 지혜롭고 편하게 사용하도록 할 수 있다. ​4. 이 사실을 깨닫고 나면 다시는 세상이 예전 같지 않을 것이다. ​ #타이탄의도구들

< 스티브 잡스가 알려준 ‘세상이 예전 같지 않게 되는 순간’ >

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

실리콘밸리에서 가장 영향력 있는 VC 중 하나인 Andreessen Horowitz(줄여서 a16z)에서 2025년 8월 기준 Top 100 Gen AI Consumer Apps 보고서를 발표했습니다.

이번 리스트에서 가장 눈에 띄는 건 뭐니뭐니 해도 구글의 약진인데요. 대표 LLM 어시스턴트인 Gemini가 ChatGPT에 이어 2위에 올라섰고, AI Studio는 Top 10에 진입했으며, NotebookLM(13위)과 Google Labs(39위)도 새롭게 이름을 올렸습니다.

반면 얼마 전까지만 해도 뜨거운 관심을 받았던 DeepSeek은 최고점 대비 40% 이상 하락하며 추락세를 보이고, 그 자리를 후발 주자인 Grok과 Meta AI가 조용히 메우는 분위기입니다.

저는 소프트웨어 엔지니어로서 바이브 코딩 관련 앱들의 부상이 참 흥미로웠습니다. 기존 강자인 Claude와 Cursor 외에도 Lovable이 22위로 급상승했고 Replit도 메인 리스트에 진입했네요. 특히 이러한 흐름과 맞물려 바이브 코딩과 궁합이 좋기로 소문난 Supabase가 완전히 떡상했다고 합니다. 📈

AI 생태계가 점차 안정화되는 듯하면서도, 여전히 새로운 플레이어들이 등장하여 기존 강자들이 위협하는 모습이 공존하고 있네요. 여러분은 이 중 어떤 생성형 AI 앱을 가장 자주 사용하고 계신가요?

🔗 원문 보기: https://a16z.com/100-gen-ai-apps-5/

실리콘밸리에서 가장 영향력 있는 VC 중 하나인 Andreessen Horowitz(줄여서 a16z)에서 2025년 8월 기준 Top 100 Gen AI Consumer Apps 보고서를 발표했습니다. 이번 리스트에서 가장 눈에 띄는 건 뭐니뭐니 해도 구글의 약진인데요. 대표 LLM 어시스턴트인 Gemini가 ChatGPT에 이어 2위에 올라섰고, AI Studio는 Top 10에 진입했으며, NotebookLM(13위)과 Google Labs(39위)도 새롭게 이름을 올렸습니다. 반면 얼마 전까지만 해도 뜨거운 관심을 받았던 DeepSeek은 최고점 대비 40% 이상 하락하며 추락세를 보이고, 그 자리를 후발 주자인 Grok과 Meta AI가 조용히 메우는 분위기입니다. 저는 소프트웨어 엔지니어로서 바이브 코딩 관련 앱들의 부상이 참 흥미로웠습니다.&nbsp;기존 강자인 Claude와 Cursor 외에도 Lovable이 22위로 급상승했고 Replit도 메인 리스트에 진입했네요. 특히 이러한 흐름과 맞물려 바이브 코딩과 궁합이 좋기로 소문난 Supabase가 완전히 떡상했다고 합니다. 📈 AI 생태계가 점차 안정화되는 듯하면서도, 여전히 새로운 플레이어들이 등장하여 기존 강자들이 위협하는 모습이 공존하고 있네요. 여러분은 이 중 어떤 생성형 AI 앱을 가장 자주 사용하고 계신가요? 🔗 원문 보기: https://a16z.com/100-gen-ai-apps-5/

🏆 가장 인기 있는 생성형 AI 소비자 앱 100개

I didn't expect Google to make such a strong move, especially Gemini has risen to the top 2. It feels like they have been "silent" to focus on development and now the results are very clear. Click https://geometrydash22.com

해외 기업들의 ‘그로스 전략’을 집중 분석했습니다. 퍼플렉시티, 노션, 듀오링고, 몬조, 링크트리 5곳은 마케팅 낭비 없이 성장 엔진을 구축해 지속 가능한 성장을 달성했습니다. 각 기업 사례를 통해 진짜 성장을 만드는 전략을 배워보세요. | 전략 인사이트

퍼플렉시티, 듀오링고…해외 기업 5곳의 그로스 전략 - 그로스메이커 블로그

퍼플렉시티, 듀오링고, 노션, 몬조, 링크트리가 어떻게 성장했는지 살펴봤습니다. 그저 간단하게 정리한 예시고, 회사마다 적용할 수 있는 전략이 다르겠지만 각자 회사들이 어떻게 했는지 알아보고 제품 성격이나 외부 환경에 따라 어떻게 지속적으로 이터레이션했는지 참고로 보시면 좋겠네요.

https://blog.growthmaker.kr/growth-strategies-of-overseas-companies

퍼플렉시티, 듀오링고, 노션, 몬조, 링크트리가 어떻게 성장했는지 살펴봤습니다. 그저 간단하게 정리한 예시고, 회사마다 적용할 수 있는 전략이 다르겠지만 각자 회사들이 어떻게 했는지 알아보고 제품 성격이나 외부 환경에 따라 어떻게 지속적으로 이터레이션했는지 참고로 보시면 좋겠네요. https://blog.growthmaker.kr/growth-strategies-of-overseas-companies

blog.growthmaker.kr

회사 3분기 업데이트. 작은 계약, 중간 계약, 큰 계약건이 각각 하나씩 있고, 셋 다 80%까지 왔다. 중요하게 생각해왔던 업데이트도 마무리지었고, 아미고의 방향도 어느정도 분명해짐. 패밀리 앱을 계획하고 있고, 특허도 두 개째 출원중. 지표는 아직 대화 품질 지표만 올리고 있는데, 한달에 3,000시간씩 쓰는 분이 몇 분 생겨서 고민중. 디자이너, 개발자 한 명씩 채용. 대충 이래 슬렁슬렁 가고있어유..

회사 3분기 업데이트. 작은 계약, 중간 계약, 큰 계약건이 각각 하나씩 있고, 셋 다 80%까지 왔다. 중요하게 생각해왔던 업데이트도 마무리지었고, 아미고의 방향도 어느정도 분명해짐. 패밀리 앱을 계획하고 있고, 특허도 두 개째 출원중. 지표는 아직 대화 품질 지표만 올리고 있는데, 한달에 3,000시간씩 쓰는 분이 몇 분 생겨서 고민중. 디자이너, 개발자 한 명씩 채용. 대충 이래 슬렁슬렁 가고있어유..

1.●핑계될 시간에 시작해라.
2.●모든 결정은 내가 정하는 것이다.
3.무엇이든 해보지 않고서는 알수 없다.
4.●내안의 화를 다스려야 한다.
5.디테일이 분위기를 좌우한다.
6.●지옥길은 멈추지 말고 나아가라.
7.●너 자신을 불태우지 않으면 절대로 빛날수없다
8.불가능은 사실이 아니다.
9.●포기하지 마라 위대한 일은 시간이 걸린다.
10.●쉬고 싶을때는 조금만 더해라.그게 차이다.

1.●핑계될 시간에 시작해라. 2.●모든 결정은 내가 정하는 것이다. 3.무엇이든 해보지 않고서는 알수 없다. 4.●내안의 화를 다스려야 한다. 5.디테일이 분위기를 좌우한다. 6.●지옥길은 멈추지 말고 나아가라. 7.●너 자신을 불태우지 않으면 절대로 빛날수없다 8.불가능은 사실이 아니다. 9.●포기하지 마라 위대한 일은 시간이 걸린다. 10.●쉬고 싶을때는 조금만 더해라.그게 차이다.

쉬고싶을때 더해라...250909

최근에 누군가 내게 "기술을 어떻게 학습하시나요?"라는 질문을 한 적이 있다. 머릿속에는 정말 다양한 생각들이 스쳤지만, 나는 그중에서도 가장 중요하다고 생각하는 한 가지를 답했다. 기술을 배우는 데 필요한 것은 딱 하나, 충분한 관심이라고 생각한다. 여기서 말하는 관심은 그저 흥미로 끝나는 것이 아니라, 끊임없이 관찰하고 확인하고 왜를 고민해보는 적극적인 호기심을 의미한다.


내 경험상 어떤 기술을 깊이 있게 배우기 위해서는 그 대상에 대한 충분한 관심이 있어야 했다. 관심은 단순한 흥미를 넘어서 지속적인 탐구심과 동기부여로 이어진다. 내가 어떤 주제에 강한 관심을 갖게 되면, 문제를 끝까지 풀어보고자 하는 인내심이 생기고, 모르는 것을 즐겁게 파고들 수 있는 열의가 생겨났다. 결국 관심이 커야 기술 지식을 깊게 파고들 수 있는 힘이 생긴다. 진정으로 관심이 있을 때 비로소 새로운 개념을 찾아보고 배우는 과정 자체를 즐기게 되었다.


관찰은 내 학습의 첫걸음이었다. 주변의 좋은 코드나 뛰어난 동료의 작업 방식을 유심히 살펴보는 것만으로도 많은 것을 배울 수 있다. 나 역시 과거 스프링 프레임워크의 코드를 한 줄 한 줄 따라 읽으며, 책으로는 얻기 어려웠던 객체 지향 설계의 살아있는 지혜를 얻었던 경험이 있다. 코드 리뷰를 할 때도 마찬가지다. 단순히 코드를 훑어보는 것을 넘어, 이 코드가 왜 이렇게 작성되었을지 그 의도를 헤아려보며 관찰하고, 궁금한 점은 동료에게 직접 물어보며 내가 놓쳤던 배경과 맥락을 배운다.


확인은 배움의 깊이를 더하는 필수적인 과정이다. 나는 어설픈 짐작으로 아는 척 넘어가는 것을 경계한다. 새로운 API를 공부할 때면, 문서만 읽고 끝내는 대신 작은 테스트 코드를 작성해 내 예상이 맞는지 직접 확인해 본다. 이 간단한 검증 과정이 내가 무엇을 알고 무엇을 모르는지를 명확하게 해준다. 직접 확인하는 습관을 가진 개발자와 그렇지 않은 개발자 사이의 실력 차이는 시간이 지날수록 크게 벌어질 수밖에 없다.


마지막으로 '왜?'라는 질문을 던지는 습관은 얕은 지식을 깊은 지혜로 바꾸는 비결이다. 어떤 기술을 접할 때 그저 사용법만 익히는 것이 아니라, "왜 이런 구조를 선택했을까?", "다른 방식이 아닌 이 방법의 장점은 무엇일까?" 하고 근본적인 이유를 파고드는 것이다. 이런 질문은 기술의 철학을 이해하게 하고, 실무에서 마주하는 문제의 본질을 꿰뚫어 볼 수 있는 힘을 길러준다. 또한, 동료들과 '왜?'라는 질문을 주고받는 문화는 개인을 넘어 팀 전체의 기술적 깊이를 더하는 가장 좋은 방법이기도 하다.


돌아보면, 기술은 시대에 따라 계속 변했지만 그것을 배우는 나의 자세는 아직 그대로다. 오늘도 충분한 관심을 바탕으로 관찰하고, 확인하고, 끊임없이 '왜'를 묻는 내가 있다면, 내일 어떤 새로운 기술이 나타나더라도 단단해진 실력으로 그것을 온전히 내 것으로 만들 수 있으리라 믿는다.

최근에 누군가 내게 "기술을 어떻게 학습하시나요?"라는 질문을 한 적이 있다. 머릿속에는 정말 다양한 생각들이 스쳤지만, 나는 그중에서도 가장 중요하다고 생각하는 한 가지를 답했다. 기술을 배우는 데 필요한 것은 딱 하나, 충분한 관심이라고 생각한다. 여기서 말하는 관심은 그저 흥미로 끝나는 것이 아니라, 끊임없이 관찰하고 확인하고 왜를 고민해보는 적극적인 호기심을 의미한다. 내 경험상 어떤 기술을 깊이 있게 배우기 위해서는 그 대상에 대한 충분한 관심이 있어야 했다. 관심은 단순한 흥미를 넘어서 지속적인 탐구심과 동기부여로 이어진다. 내가 어떤 주제에 강한 관심을 갖게 되면, 문제를 끝까지 풀어보고자 하는 인내심이 생기고, 모르는 것을 즐겁게 파고들 수 있는 열의가 생겨났다. 결국 관심이 커야 기술 지식을 깊게 파고들 수 있는 힘이 생긴다. 진정으로 관심이 있을 때 비로소 새로운 개념을 찾아보고 배우는 과정 자체를 즐기게 되었다. 관찰은 내 학습의 첫걸음이었다. 주변의 좋은 코드나 뛰어난 동료의 작업 방식을 유심히 살펴보는 것만으로도 많은 것을 배울 수 있다. 나 역시 과거 스프링 프레임워크의 코드를 한 줄 한 줄 따라 읽으며, 책으로는 얻기 어려웠던 객체 지향 설계의 살아있는 지혜를 얻었던 경험이 있다. 코드 리뷰를 할 때도 마찬가지다. 단순히 코드를 훑어보는 것을 넘어, 이 코드가 왜 이렇게 작성되었을지 그 의도를 헤아려보며 관찰하고, 궁금한 점은 동료에게 직접 물어보며 내가 놓쳤던 배경과 맥락을 배운다. 확인은 배움의 깊이를 더하는 필수적인 과정이다. 나는 어설픈 짐작으로 아는 척 넘어가는 것을 경계한다. 새로운 API를 공부할 때면, 문서만 읽고 끝내는 대신 작은 테스트 코드를 작성해 내 예상이 맞는지 직접 확인해 본다. 이 간단한 검증 과정이 내가 무엇을 알고 무엇을 모르는지를 명확하게 해준다. 직접 확인하는 습관을 가진 개발자와 그렇지 않은 개발자 사이의 실력 차이는 시간이 지날수록 크게 벌어질 수밖에 없다. 마지막으로 '왜?'라는 질문을 던지는 습관은 얕은 지식을 깊은 지혜로 바꾸는 비결이다. 어떤 기술을 접할 때 그저 사용법만 익히는 것이 아니라, "왜 이런 구조를 선택했을까?", "다른 방식이 아닌 이 방법의 장점은 무엇일까?" 하고 근본적인 이유를 파고드는 것이다. 이런 질문은 기술의 철학을 이해하게 하고, 실무에서 마주하는 문제의 본질을 꿰뚫어 볼 수 있는 힘을 길러준다. 또한, 동료들과 '왜?'라는 질문을 주고받는 문화는 개인을 넘어 팀 전체의 기술적 깊이를 더하는 가장 좋은 방법이기도 하다. 돌아보면, 기술은 시대에 따라 계속 변했지만 그것을 배우는 나의 자세는 아직 그대로다. 오늘도 충분한 관심을 바탕으로 관찰하고, 확인하고, 끊임없이 '왜'를 묻는 내가 있다면, 내일 어떤 새로운 기술이 나타나더라도 단단해진 실력으로 그것을 온전히 내 것으로 만들 수 있으리라 믿는다.

기술을 어떻게 학습하시나요?

나머지 책들도 알려달라고 하셔서 적어봅니다.

소프트웨어 개발자 필독서 Top 3

1️⃣ The C Programming Language

컴퓨터 프로그래밍의 근본 (주니어)

2️⃣ Code Complete

소프트웨어 개발의 모든 것 (주니어, 미드)

3️⃣ 구글 엔지니어는 이렇게 일한다

개발 협업에 대한 모든 것 (미드, 시니어)

—

자매품, 소프트웨어 개발자를 위한 AI 필독서

📘 3분 딥러닝 텐서플로맛

📕 최고의 프롬프트 엔지니어링 강의

이상한 것이 끼어있는 것 같지만 착각입니다.

나머지 책들도 알려달라고 하셔서 적어봅니다. 소프트웨어 개발자 필독서 Top 3 1️⃣ The C Programming Language 컴퓨터 프로그래밍의 근본 (주니어) 2️⃣ Code Complete 소프트웨어 개발의 모든 것 (주니어, 미드) 3️⃣ 구글 엔지니어는 이렇게 일한다 개발 협업에 대한 모든 것 (미드, 시니어) — 자매품, 소프트웨어 개발자를 위한 AI 필독서 📘 3분 딥러닝 텐서플로맛 📕 최고의 프롬프트 엔지니어링 강의 이상한 것이 끼어있는 것 같지만 착각입니다.

나머지 책들도 알려달라고 하셔서 적어봅니다.

소프트웨어 개발자 

건축가들이 쾌적한 환경을 창조하지 못하는 것은 우리가 우리 생활의 다른 영역에서 행복을 찾지 못하는 현실의 반영이기도 하다. 나쁜 건축이란 결국 설계의 실패인 동시에 심리 파악의 실채이기도 하다. 건축에서는 이런 경향이 물질로 표현되지만, 다른 영역으로 가면 엉뚱한 사람과 결혼을 한다거나, 어울리지 않는 일자리를 고른다거나, 재미없는 휴가 예약을 하는 것으로 나타나기도 한다. 그 경향이란 우리가 누구인지, 무엇에 만족하는지 이해하지 못하는 경향이다.
⠀
다른 분야에서도 마찬가지이지만 건축에서도 우리는 우리의 고통을 설명해줄 것을 찾아서 주위를 두리번거리다가 진부한 목표물에 눈길을 고정한다. 우리는 슬프다는 것을 깨달아야 하는 상황에서 화를 낸다. 적당한 위생시설과 가로등을 도입해야 하는 상황에서 오래된 거리를 그냥 부수고 만다. 우리는 만족의 근원을 이해하려고 헛된 노력을 하다가, 슬픔으로부터 그릇된 교훈을 배운다.
⠀
알랭 드 보통, 행복의 건축

건축가들이 쾌적한 환경을 창조하지 못하는 것은 우리가 우리 생활의 다른 영역에서 행복을 찾지 못하는 현실의 반영이기도 하다. 나쁜 건축이란 결국 설계의 실패인 동시에 심리 파악의 실채이기도 하다. 건축에서는 이런 경향이 물질로 표현되지만, 다른 영역으로 가면 엉뚱한 사람과 결혼을 한다거나, 어울리지 않는 일자리를 고른다거나, 재미없는 휴가 예약을 하는 것으로 나타나기도 한다. 그 경향이란 우리가 누구인지, 무엇에 만족하는지 이해하지 못하는 경향이다.⠀다른 분야에서도 마찬가지이지만 건축에서도 우리는 우리의 고통을 설명해줄 것을 찾아서 주위를 두리번거리다가 진부한 목표물에 눈길을 고정한다. 우리는 슬프다는 것을 깨달아야 하는 상황에서 화를 낸다. 적당한 위생시설과 가로등을 도입해야 하는 상황에서 오래된 거리를 그냥 부수고 만다. 우리는 만족의 근원을 이해하려고 헛된 노력을 하다가, 슬픔으로부터 그릇된 교훈을 배운다.⠀알랭 드 보통, 행복의 건축

《심리 파악의 실채》

롱블랙 프렌즈 L 구독료를 안 받는데 디지털 신문으로 연 5190억원(2억7500만 파운드)을 버는 언론사가 있어. 영국의 대표 일간지 가디언The Guardia

가디언의 UX : 구독 대신 후원, 뉴욕타임스와는 다른 영국 일간지의 설득법

Ep9과의 즐거운 협업에 이어 롱블랙과 함께 UX 콘텐츠를 이어갑니다. 미디어에도 UX라는 개념이 있을까? 싶은 의문에 대해 살펴보기 위해 '뉴욕타임스'와 상반되는 사용자 경험으로 시장에서 잔잔하지만 단단한 후원 모델을 만든 가디언(The Guardian)에 대해 분석했습니다. "지속 가능하지 않으면, 독립성도 없다"라는 선언은 제게 강력한 메시지였습니다. 좋은 파트너와의 협업은 생각의 틀을 확장하게 해 준다는 믿음을 다시 경험하게 해 준 에디터, 진영 님께 감사드립니다.

첫째, 가디언은 누구나 무료로 가디언 콘텐츠를 읽을 수 있도록 합니다.

둘째, 가디언은 기사마다 '누가, 어디서 썼는지'를 빠짐없이 밝힙니다.

셋째, 가디언은 도박 광고에 대해 전면 거부 선언을 하며 도박 기사에 대한 비판 기사와 행동을 같이 했습니다.

넷째, 가디언은 미디어의 본질이 '무엇'에만 있지 않고 '어떻게'에 있다고 보고 어려운 용어를 사용하지 않습니다.

다섯째, 가디언은 '완벽할 수 없다'는 걸 인정하고 1997년부터 '정정과 설명' 코너를 만들어 오류를 공개하고 사과합니다.

아래 링크를 이용하면 24시간 동안 롱블랙 아티클을 살펴보실 수 있습니다. 혹시 24시간이 지나 접속이 안 되면 제게 메시지를 보내주세요. 기쁜 마음으로 새로운 링크를 전달드리겠습니다.

"독자와 직접 소통해야 하는 모든 순간, 우리는 업계 전문 용어나 어려운 단어를 피하려 합니다. 더 정확하고 쉽게 표현하려 노력하죠. 동시에 어려운 용어까지 알고 싶어하는 사람을 위해, 각주로 이를 자세히 설명해요." - 엘리자베스 리반스, 가디언 기자, 2023년 기사 '뉴스룸 밖에서 저널리스트 전문 용어를 쓰는 것의 위험성'에서

https://www.longblack.co/note/1722?ticket=NT253636ec380026d3518e62d8f87d56f73581

Ep9과의 즐거운 협업에 이어 롱블랙과 함께 UX 콘텐츠를 이어갑니다. 미디어에도 UX라는 개념이 있을까? 싶은 의문에 대해 살펴보기 위해 '뉴욕타임스'와 상반되는 사용자 경험으로 시장에서 잔잔하지만 단단한 후원 모델을 만든 가디언(The Guardian)에 대해 분석했습니다. "지속 가능하지 않으면, 독립성도 없다"라는 선언은 제게 강력한 메시지였습니다. 좋은 파트너와의 협업은 생각의 틀을 확장하게 해 준다는 믿음을 다시 경험하게 해 준 에디터, 진영 님께 감사드립니다. 첫째, 가디언은 누구나 무료로 가디언 콘텐츠를 읽을 수 있도록 합니다. 둘째, 가디언은 기사마다 '누가, 어디서 썼는지'를 빠짐없이 밝힙니다. 셋째, 가디언은 도박 광고에 대해 전면 거부 선언을 하며 도박 기사에 대한 비판 기사와 행동을 같이 했습니다. 넷째, 가디언은 미디어의 본질이 '무엇'에만 있지 않고 '어떻게'에 있다고 보고 어려운 용어를 사용하지 않습니다. 다섯째, 가디언은 '완벽할 수 없다'는 걸 인정하고 1997년부터 '정정과 설명' 코너를 만들어 오류를 공개하고 사과합니다. 아래 링크를 이용하면 24시간 동안 롱블랙 아티클을 살펴보실 수 있습니다. 혹시 24시간이 지나 접속이 안 되면 제게 메시지를 보내주세요. 기쁜 마음으로 새로운 링크를 전달드리겠습니다. "독자와 직접 소통해야 하는 모든 순간, 우리는 업계 전문 용어나 어려운 단어를 피하려 합니다. 더 정확하고 쉽게 표현하려 노력하죠. 동시에 어려운 용어까지 알고 싶어하는 사람을 위해, 각주로 이를 자세히 설명해요." - 엘리자베스 리반스, 가디언 기자, 2023년 기사 '뉴스룸 밖에서 저널리스트 전문 용어를 쓰는 것의 위험성'에서 https://www.longblack.co/note/1722?ticket=NT253636ec380026d3518e62d8f87d56f73581

LongBlack

⟪가디언의 UX : 구독 대신 후원⟫

일 하다 눈이 가는 소식을 큐레이션해서 공유합니다

TREND REPORT "2025년 8월에 본 것"

8월 21일(목) 저녁, 에피소드 신촌 캠퍼스에서 디자인하우스 '프로퍼티 브랜딩 여름학교' 수강생 대상으로 공간에서의 UX 리서치에 대해 발표하는 기회가 있었습니다. 아직도 한국에서는 생소한 기업형 임대주택 그 안에서 쉐어하우징을 만드는 사람의 고민과 그 고민의 단서를 발견하기 위한 UX 리서치. 이때 제가 쓴 타이틀은 '애씀 총량의 법칙'이었습니다.


만드는 사람이 애쓰지 않으면, 쓰는 사람이 결국 수고스럽다


복잡도 총량 보존의 법칙, 테슬러의 법칙 등으로 이 개념은 많은 분들에게 익숙할 겁니다. 복잡도는 관찰자 시점에서 바라볼 때 대상화 된 객채로서의 개념이라면 애씀은 주관적입니다. 어쩌면 눈치게임을 닮았습니다. 우리는 매일 많은 과제들을 낯선 사람들과 함께 하면서 프리라이더, 체리피커들을 경험했고 앞으로도 경험할 수 있습니다.


부동산개발사업의 특성을 고려하면 공정은 매우 길고, 이해관계자는 많으며, 규정에 얽혀 있는 요소가 많습니다. 복잡성이 굉장히 높은 비즈니스이고 그 복잡성을 다루는 주체 간의 역할은 MECE하게 정리되지 않을 때가 많죠. 잘 정리한다고 해도 소송과 하자보수, 일정지연이 (그러면 안 되지만) 기본값이 되어 있습니다. 그 안에서 이 일을 지속하려면 애씀 총량의 법칙을 믿으며 서로의 애씀을 알아주는 동료가 필요합니다. 저는 그런 동료들을 만나 작년엔 에피소드 용산 241을, 올해는 에피소드에 처음으로 '캠퍼스'라는 이름을 붙인 상품을 선보였습니다. 애씀을 알아준 그들에게 뒤늦은 고마움을 전합니다.


[목차] 


1️⃣ Ep9을 다시 롱블랙에서
2️⃣ 롱블랙과 첫 번째 협업, 가디언의 UX
3️⃣ 스페셜리스트와 제너럴리스트 사이
4️⃣ 무던한 사람을 좋아하는 이유
5️⃣ 우리가 예술을 필요로 하는 이유

https://maily.so/redbusbagman/posts/mjz636kwzwk

8월 21일(목) 저녁, 에피소드 신촌 캠퍼스에서 디자인하우스 '프로퍼티 브랜딩 여름학교' 수강생 대상으로 공간에서의 UX 리서치에 대해 발표하는 기회가 있었습니다. 아직도 한국에서는 생소한 기업형 임대주택 그 안에서 쉐어하우징을 만드는 사람의 고민과 그 고민의 단서를 발견하기 위한 UX 리서치. 이때 제가 쓴 타이틀은 '애씀 총량의 법칙'이었습니다. 만드는 사람이 애쓰지 않으면, 쓰는 사람이 결국 수고스럽다 복잡도 총량 보존의 법칙, 테슬러의 법칙 등으로 이 개념은 많은 분들에게 익숙할 겁니다. 복잡도는 관찰자 시점에서 바라볼 때 대상화 된 객채로서의 개념이라면 애씀은 주관적입니다. 어쩌면 눈치게임을 닮았습니다. 우리는 매일 많은 과제들을 낯선 사람들과 함께 하면서 프리라이더, 체리피커들을 경험했고 앞으로도 경험할 수 있습니다. 부동산개발사업의 특성을 고려하면 공정은 매우 길고, 이해관계자는 많으며, 규정에 얽혀 있는 요소가 많습니다. 복잡성이 굉장히 높은 비즈니스이고 그 복잡성을 다루는 주체 간의 역할은 MECE하게 정리되지 않을 때가 많죠. 잘 정리한다고 해도 소송과 하자보수, 일정지연이 (그러면 안 되지만) 기본값이 되어 있습니다. 그 안에서 이 일을 지속하려면 애씀 총량의 법칙을 믿으며 서로의 애씀을 알아주는 동료가 필요합니다. 저는 그런 동료들을 만나 작년엔 에피소드 용산 241을, 올해는 에피소드에 처음으로 '캠퍼스'라는 이름을 붙인 상품을 선보였습니다. 애씀을 알아준 그들에게 뒤늦은 고마움을 전합니다. [목차]&nbsp; 1️⃣ Ep9을 다시 롱블랙에서2️⃣ 롱블랙과 첫 번째 협업, 가디언의 UX3️⃣ 스페셜리스트와 제너럴리스트 사이4️⃣ 무던한 사람을 좋아하는 이유5️⃣ 우리가 예술을 필요로 하는 이유 https://maily.so/redbusbagman/posts/mjz636kwzwk

앤디의 마음챙김 레터

⟪TREND REPORT "2025년 8월에 본 것"⟫

우리는 환경이 우리가 존중하는 분위기와 관념을 구현하고, 우리에게 그것을 일깨워주기를 은근히 기대한다. 건물이 일종의 심리학적 틀처럼 우리를 지탱하여, 우리에게 도움이 되는 우리 자신의 모습을 유지해 주기를 기대한다. 우리 내부에 필요한 것 - 그러나 필요하다는 사실 자체를 잊을 위험이 있는 것 - 을 표현해 주는 물질적 형태들을 주위에 배치한다. 벽지, 베치, 그림, 거리가 우리의 진정한 자아의 실종을 막아주기를 기대한다.
⠀
알랭 드 보통, 행복의 건축

우리는 환경이 우리가 존중하는 분위기와 관념을 구현하고, 우리에게 그것을 일깨워주기를 은근히 기대한다. 건물이 일종의 심리학적 틀처럼 우리를 지탱하여, 우리에게 도움이 되는 우리 자신의 모습을 유지해 주기를 기대한다. 우리 내부에 필요한 것 - 그러나 필요하다는 사실 자체를 잊을 위험이 있는 것 - 을 표현해 주는 물질적 형태들을 주위에 배치한다. 벽지, 베치, 그림, 거리가 우리의 진정한 자아의 실종을 막아주기를 기대한다.⠀알랭 드 보통, 행복의 건축

《건축에 기대는 마음》

퍼플렉시티, 듀오링고, 노션, 몬조, 링크트리가 어떻게 성장했는지

Example Domain

오래전 HTTP 프로토콜을 공부하다가 느꼈던 기쁜 감정이 떠올랐습니다.
텔넷을 통해 웹서버에 접속해 HTTP 메시지를 보내고 응답을 받던 순간.

텔넷으로 웹서버에 접속한 뒤
telnet example.com 80


HTTP 메시지를 스스로 한땀한땀 입력해 봅니다.
한 글자씩 타이핑하면서 줄바꿈도 해봐야 합니다.

GET /index.html HTTP/1.1
Host: example.com
User-Agent: jeho



마지막에 빈 줄을 꼭 넣어야 서버가 “아, 요청이 끝났구나” 하고 응답을 줍니다.
서버에서 200 OK 와 함께 응답이 내려오는 순간 아하 모먼트를 느꼈습니다. 바로 이런 거였구나!

마찬가지로 POST 요청도 보내보면서 어떻게 파라메터가 전달되는지도 관찰하고…
SMTP(이메일) 또한 프로토콜도 텔넷으로 경험할 수 있습니다.
검은 텔넷 화면에서 그저 몇 글자 타이핑했을 뿐인데 그게 실제 이메일로 발송되는 순간 ‘아하!’ 하며 깨달음을 얻게 됩니다.

이렇게 기반 프로토콜의 이해를 높여가면 라이브러리도 쉽게 사용할 수 있고 트러블 슈팅도 잘할 수 있게 됩니다.


https://jeho.page/programming/2025/09/01/http-smtp.html

오래전 HTTP 프로토콜을 공부하다가 느꼈던 기쁜 감정이 떠올랐습니다. 텔넷을 통해 웹서버에 접속해 HTTP 메시지를 보내고 응답을 받던 순간. 텔넷으로 웹서버에 접속한 뒤<pre ><code>telnet example.com 80</code></pre> HTTP 메시지를 스스로 한땀한땀 입력해 봅니다. 한 글자씩 타이핑하면서 줄바꿈도 해봐야 합니다. <pre ><code>GET /index.html HTTP/1.1
Host: example.com
User-Agent: jeho
</code></pre> 마지막에 빈 줄을 꼭 넣어야 서버가 “아, 요청이 끝났구나” 하고 응답을 줍니다. 서버에서 200 OK 와 함께 응답이 내려오는 순간 아하 모먼트를 느꼈습니다. 바로 이런 거였구나! 마찬가지로 POST 요청도 보내보면서 어떻게 파라메터가 전달되는지도 관찰하고… SMTP(이메일) 또한 프로토콜도 텔넷으로 경험할 수 있습니다. 검은 텔넷 화면에서 그저 몇 글자 타이핑했을 뿐인데 그게 실제 이메일로 발송되는 순간 ‘아하!’ 하며 깨달음을 얻게 됩니다. 이렇게 기반 프로토콜의 이해를 높여가면 라이브러리도 쉽게 사용할 수 있고 트러블 슈팅도 잘할 수 있게 됩니다. https://jeho.page/programming/2025/09/01/http-smtp.html

example.com

HTTP에 대해 처음 아하 모먼트를 느꼈던 순간

1. 성공을 하기 위해 꼭 관리자가 되어야 하는 건 아닙니다 : 많은 사람들이 (직장 생활에서) 더 많은 돈을 벌고, 지위도 올라는 길은 승진해서 관리자가 되는 것, 하나뿐이라고 생각합니다. 하지만 비슷한 연봉을 받고, 비슷한 영향력을 행사하고, 또 그러면서도 전반적으로 더 행복해질 수 있는 대안들이 있습니다. 물론 사람들을 관리하는 일이 자신에게 잘 맞아서 관리자가 되고 싶은 것이라면 그렇게 되도록 노력해야 합니다. 하지만 설사 그런 경우여도 평생 관리자로만 지내야 하는 건 아닙니다. 팀장이었다가, 다시 개별 직원으로 돌아가는 사람들도 있습니다. (팀장으로의 승진이 비가역적 변화라고 생각하지 말란 말입니다)


2. 관리자가 되면, 당신을 성공하게 만들어준 일을 더 이상 못하게 된다는 사실을 절대 잊지 마세요 : 안타깝지만, 관리자가 되면 당신이 정말 잘하는 일들을 더 이상 못하게 될 수 있습니다. 대신, 다른 사람들이 그 일을 어떻게 하는지 지켜보고 더 잘할 수 있도록 도와주는 역할을 맡아야 합니다. 이제 당신이 해야 하는 일은 다른 사람을 도와주는 겁니다. 따라서 당신이 최우선적으로 해야 할 일은, 다른 사람들과의 커뮤니케이션, 커뮤니케이션, 커뮤니케이션입니다. 그리고 사람을 채용하고, 해고하고, 예산을 짜고, 모든 걸 검토하고, 1:1 면담을 하고, 회의를 하고, 사람들이 목표를 향해 가도록 감독하고, 갈등을 해소하고, 풀기 어려운 문제들에 대한 창의적 해결책을 찾도록 도움을 주는 겁니다. 정치적인 문제들도 해결해야 하고, 팀원들에게도 멘토 역할을 해줘야 합니다. 또한 일을 하는 내내 팀원들에게 “무엇을 도와줄까요?”라고 물어야 합니다. (관리자는 자기가 잘 하는 일을 하는 사람이 아니라, 팀원들이 잘할 수 있도록 이끄는 사람입니다)


3. (따라서) 관리자가 되는 것은 일종의 자기 수련입니다 : 매니징은 타고난 재능이 아니라, 학습을 통해 습득하는 기술입니다. 당신은 많은 커뮤니케이션 기술을 익혀야 하고, 각종 웹사이트, 팟캐스트, 책, 강의를 통해, 혹은 멘토나 이미 많은 경험을 한 다른 관리자들에게 도움을 받으며, 스스로를 단련시키고 훈련시켜야 합니다.


4. 관리는 마이크로 매니지먼트와 다릅니다 : 당신이 해야 할 일은 팀원들이 (스스로) 질적으로 훌륭한 일을 해낼 수 있도록 지원하는 겁니다. 당신이 업무의 모든 과정을 일일이 다 지시해 팀원들이 결과를 내는 데 집중하지 못하고, 당신의 지시를 이행하는 데만 급급하다면 그건 제대로 된 관리가 아닙니다. 마이크로 매니지먼트일 뿐입니다.


5. 스타일보다는 솔직한 게 더 중요합니다 : 그게 내성적이든, 감성적이든, 분석적이든, 흥분을 잘 하든, 모든 사람에게는 자기 고유의 스타일이 있습니다. 하지만 어떤 스타일이든, 아무리 불편하고 받아들이기 힘든 진실이더라도, 팀원들에게 솔직하게 말할 수 있어야 합니다. 그렇게 해야 성공할 수 있습니다.


6. 당신 팀이 당신보다 더 빛난다 해도 신경 쓰지 마세요 : 아니, 그게 당신의 목표가 되어야 합니다. 관리자는 팀원을 훈련시켜 당신이 해야 할 일을 대신 하고, 더 빛나도록 만들어야 합니다. 팀원이 잘 해야, 당신은 그만큼 더 승진하기 쉬워집니다.


- 토니 퍼델, <빌드 : 창조의 과정>

1.&nbsp;성공을 하기 위해 꼭 관리자가 되어야 하는 건 아닙니다&nbsp;: 많은 사람들이 (직장 생활에서) 더 많은 돈을 벌고, 지위도 올라는 길은 승진해서 관리자가 되는 것, 하나뿐이라고 생각합니다. 하지만 비슷한 연봉을 받고, 비슷한 영향력을 행사하고, 또 그러면서도 전반적으로 더 행복해질 수 있는 대안들이 있습니다. 물론 사람들을 관리하는 일이 자신에게 잘 맞아서 관리자가 되고 싶은 것이라면 그렇게 되도록 노력해야 합니다. 하지만 설사 그런 경우여도 평생 관리자로만 지내야 하는 건 아닙니다. 팀장이었다가, 다시 개별 직원으로 돌아가는 사람들도 있습니다. (팀장으로의 승진이 비가역적 변화라고 생각하지 말란 말입니다) 2.&nbsp;관리자가 되면, 당신을 성공하게 만들어준 일을 더 이상 못하게 된다는 사실을 절대 잊지 마세요&nbsp;:&nbsp;안타깝지만, 관리자가 되면 당신이 정말 잘하는 일들을 더 이상 못하게 될 수 있습니다. 대신, 다른 사람들이 그 일을 어떻게 하는지 지켜보고 더 잘할 수 있도록 도와주는 역할을 맡아야 합니다. 이제 당신이 해야 하는 일은 다른 사람을 도와주는 겁니다. 따라서 당신이 최우선적으로 해야 할 일은, 다른 사람들과의 커뮤니케이션, 커뮤니케이션, 커뮤니케이션입니다. 그리고 사람을 채용하고, 해고하고, 예산을 짜고, 모든 걸 검토하고, 1:1 면담을 하고, 회의를 하고, 사람들이 목표를 향해 가도록 감독하고, 갈등을 해소하고, 풀기 어려운 문제들에 대한 창의적 해결책을 찾도록 도움을 주는 겁니다. 정치적인 문제들도 해결해야 하고, 팀원들에게도 멘토 역할을 해줘야 합니다. 또한 일을 하는 내내 팀원들에게 “무엇을 도와줄까요?”라고 물어야 합니다. (관리자는 자기가 잘 하는 일을 하는 사람이 아니라, 팀원들이 잘할 수 있도록 이끄는 사람입니다) 3.&nbsp;(따라서) 관리자가 되는 것은 일종의 자기 수련입니다&nbsp;: 매니징은 타고난 재능이 아니라, 학습을 통해 습득하는 기술입니다. 당신은 많은 커뮤니케이션 기술을 익혀야 하고, 각종 웹사이트, 팟캐스트, 책, 강의를 통해, 혹은 멘토나 이미 많은 경험을 한 다른 관리자들에게 도움을 받으며, 스스로를 단련시키고 훈련시켜야 합니다. 4.&nbsp;관리는 마이크로 매니지먼트와 다릅니다&nbsp;: 당신이 해야 할 일은 팀원들이 (스스로) 질적으로 훌륭한 일을 해낼 수 있도록 지원하는 겁니다. 당신이 업무의 모든 과정을 일일이 다 지시해 팀원들이 결과를 내는 데 집중하지 못하고, 당신의 지시를 이행하는 데만 급급하다면 그건 제대로 된 관리가 아닙니다. 마이크로 매니지먼트일 뿐입니다. 5.&nbsp;스타일보다는 솔직한 게 더 중요합니다&nbsp;: 그게 내성적이든, 감성적이든, 분석적이든, 흥분을 잘 하든, 모든 사람에게는 자기 고유의 스타일이 있습니다. 하지만 어떤 스타일이든, 아무리 불편하고 받아들이기 힘든 진실이더라도, 팀원들에게 솔직하게 말할 수 있어야 합니다. 그렇게 해야 성공할 수 있습니다. 6.&nbsp;당신 팀이 당신보다 더 빛난다 해도 신경 쓰지 마세요&nbsp;: 아니, 그게 당신의 목표가 되어야 합니다. 관리자는 팀원을 훈련시켜 당신이 해야 할 일을 대신 하고, 더 빛나도록 만들어야 합니다. 팀원이 잘 해야, 당신은 그만큼 더 승진하기 쉬워집니다. - 토니 퍼델, &lt;빌드 : 창조의 과정&gt;

팀장으로 승진하는 사람들이 현실적으로 꼭 알아야 하는 6가지

1. 훌륭한 이야기는 모두 ‘생존’에 관한 것이다. 그게 어떤 종류의 생존이든 말이다.

2. 스토리가 그 외의 다른 것을 이야기한다면 듣는 이의 마음을 사로잡지 못할 것이다. 그런 내용에는 아무도 관심이 없다.

3. 그렇다면 앞으로 제품이나 서비스의 포지셔닝을 이런 식으로 해보면 어떨 까?

4. 사람들이 생존하고, 사랑을 찾고, 열망하는 정체성을 완성하고, 나를 물리적 • 사회적으로 지켜줄 집단을 형성하는데 도움이 되는 어떤 것이라고 말이다.

5. 그렇게 한다면 모든 이들에게 어떤 것이든 팔 수 있을 것이다. 사람들이 관심을 갖는 것은 오직 이런 것들뿐이다. 이 말은 절대적으로 믿어도 좋다.


#무기기되는스토리

1. 훌륭한 이야기는 모두 ‘생존’에 관한 것이다. 그게 어떤 종류의 생존이든 말이다. ​2. 스토리가 그 외의 다른 것을 이야기한다면 듣는 이의 마음을 사로잡지 못할 것이다. 그런 내용에는 아무도 관심이 없다. ​3. 그렇다면 앞으로 제품이나 서비스의 포지셔닝을 이런 식으로 해보면 어떨 까? ​4. 사람들이 생존하고, 사랑을 찾고, 열망하는 정체성을 완성하고, 나를 물리적 • 사회적으로 지켜줄 집단을 형성하는데 도움이 되는 어떤 것이라고 말이다. ​5. 그렇게 한다면 모든 이들에게 어떤 것이든 팔 수 있을 것이다. 사람들이 관심을 갖는 것은 오직 이런 것들뿐이다. 이 말은 절대적으로 믿어도 좋다. ​ #무기기되는스토리

< 스토리는 본능을 건드릴 때 힘을 가진다 >

Feature flags solutions are pretty established by now, but I feel like there are some key features missing that would make me switch vendors. I mainly have two problems with current solutions: It can

Feature flags spaghetti // FFs missing features

Eliran Turgeman의 블로그를 의역/요약한 글입니다

---
피쳐 플래그는 요즘 많이 도입하는 기능입니다. 다만, 대부분의 피쳐 플래그를 제공하는 벤더가 몇 몇 핵심 기능을 빼먹었다고 생각합니다.

저는 현재 솔루션에서 두 개의 문제점을 발견했습니다.
 1. 여러 FF (피쳐 플래그)가 있으면 관리하기 어렵습니다
 2. FF 관련 코드를 제때 제거하지 않으면 코드 베이스는 사용하지 않는 코드가 엄청나게 많아집니다.
    
    
위 문제를 풀기 위해 해결안을 생각하보자면:
 1. FF 트리
 2. 사용되지 않는 / 완전 배포 된 FF에 대한 알림

FF 트리
FF를 트리 형태로 관리하면 좋을 것 같습니다. 메인 FF가 있고 아래 여러 FF를 두어 메인 FF를 끄면 아래 연결된 FF들도 모두 꺼지는 것입니다. 이렇게 하면 “아 UI 관련 FF 하나 끄는 걸 깜빡했네”와 같은 사례를 방지 할 수 있을 겁니다.
좀 극단적이긴 하지만 최근에 FF 네 다섯 개를 꺼야지 e2e 테스트를 할 수 있는 기능을 배포한 적 있습니다.

사용되지 않는 / 완전 배포 된 FF에 대한 알림
FF 끄고 켜는 것 때문에 지라 티켓을 만들기 싫습니다. 코드 베이스에 죽은 코드와 브랜치를 유지하고 있는 게 짜증나고 디버깅을 어렵게 만듭니다. 언제 관련 코드를 지울 수 있는지 웹 훅 같은 걸 연결해서 슬랙이나 이메일로 알림 오게 할 수 있으면 좋겠습니다.
제가 지우고 싶은 FF는:
 1. 사용되지 않는 - 최근 X 일 동안 요청 된 적 없는 것
 2. 완전 배포 된 - 기능이 완전히 배포되었고 배포 된지 X 일이 지남

현재는 이렇게 두 가지 문제점과 해결 방안이 떠오릅니다.
---

원글: https://www.16elt.com/2024/02/03/feature-flags-missing-features/

Eliran Turgeman의 블로그를 의역/요약한 글입니다 ---피쳐 플래그는 요즘 많이 도입하는 기능입니다. 다만, 대부분의 피쳐 플래그를 제공하는 벤더가 몇 몇 핵심 기능을 빼먹었다고 생각합니다. 저는 현재 솔루션에서 두 개의 문제점을 발견했습니다.<ol><li>여러 FF (피쳐 플래그)가 있으면 관리하기 어렵습니다</li><li>FF 관련 코드를 제때 제거하지 않으면 코드 베이스는 사용하지 않는 코드가 엄청나게 많아집니다. </li></ol>위 문제를 풀기 위해 해결안을 생각하보자면:<ol><li>FF 트리</li><li>사용되지 않는 / 완전 배포 된 FF에 대한 알림</li></ol> FF 트리FF를 트리 형태로 관리하면 좋을 것 같습니다. 메인 FF가 있고 아래 여러 FF를 두어 메인 FF를 끄면 아래 연결된 FF들도 모두 꺼지는 것입니다. 이렇게 하면 “아 UI 관련 FF 하나 끄는 걸 깜빡했네”와 같은 사례를 방지 할 수 있을 겁니다.좀 극단적이긴 하지만 최근에 FF 네 다섯 개를 꺼야지 e2e 테스트를 할 수 있는 기능을 배포한 적 있습니다. 사용되지 않는 / 완전 배포 된 FF에 대한 알림FF 끄고 켜는 것 때문에 지라 티켓을 만들기 싫습니다. 코드 베이스에 죽은 코드와 브랜치를 유지하고 있는 게 짜증나고 디버깅을 어렵게 만듭니다. 언제 관련 코드를 지울 수 있는지 웹 훅 같은 걸 연결해서 슬랙이나 이메일로 알림 오게 할 수 있으면 좋겠습니다.제가 지우고 싶은 FF는:<ol><li>사용되지 않는 - 최근 X 일 동안 요청 된 적 없는 것</li><li>완전 배포 된 - 기능이 완전히 배포되었고 배포 된지 X 일이 지남</li></ol> 현재는 이렇게 두 가지 문제점과 해결 방안이 떠오릅니다.--- 원글: https://www.16elt.com/2024/02/03/feature-flags-missing-features/

Eliran Turgeman

소프트웨어 엔지니어

김지섭

프론트엔드 개발자

#개발자 #디자이너 #웹디자인 #프론트엔드 #React #끊임없이배우기

김지민

피쳐 플래그 스파게티 - 피쳐 플래그에 없는 기능 🚩

손현우

안녕하세요, 퍼블리에서 엔지니어로 일하고 있는 손현우입니다. 

피쳐 플래그 스파게티 - 피쳐 플래그에 없는 기능 🚩

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필