험한 산속에 5명이 고립되어 있습니다. 생존하려면 어둡고 위험한 다리를 건너 구조대에게 가야 합니다. 그러나 다음과 같은 제약 조건이 있습니다.

1. 다리는 최대 두 사람까지만 동시에 건널 수 있습니다.
2. 반드시 등불이 있어야만 다리를 건널 수 있습니다. 등불은 단 하나뿐입니다.
3. 각 조난자가 다리를 건너는 속도는 다릅니다:
• A: 3분
• B: 5분
• C: 7분
• D, E: 각각 10분

가장 빨리 모두가 다리를 건너 구조대에게 도달할 수 있는 시간은 얼마일까요? 맞습니다. 이 질문은 최적화에 관한 질문입니다. 엔지니어 면접 질문으로 종종 묻던 것 중에 하나입니다.

모든 사람이 가장 빠르고 안전하게 다리를 건너기 위해서는 빠른 속도를 가진 A와 B가 주도적으로 움직여야 하며 그 과정에서 가장 빠른 사람(A)이 반복적으로 왕복하며 등불을 옮겨야 하는 부담을 지게 됩니다. 결국, 가장 빠른 사람의 헌신과 희생이 모두의 생존 가능성을 높이게 됩니다.

이 질문 속 진짜 숨은 의도는 단순히 최적화의 답을 구하는 것이 아니라, 조직 내 업무 최적화에 대해 많은 생각을 이끌어내는 데 있습니다.

조직에서도 이와 비슷하게 전체 업무의 효율성은 가장 느린 구성원에게 맞춰지며, 가장 뛰어난 인재가 전체의 효율을 극대화하기 위해 더 많은 역할과 책임을 짊어지게 됩니다. 뛰어난 인재가 지속적으로 성과를 내기 위해서는 그들의 기여를 인정하고 적절히 보상해야 하는 이유이기도 합니다. 경영의 신으로 불리우던 GE의 잭 웰치(Jack Welch)가 하위 성과 10% 그룹은 과감한 정리 해고, 상위 리더 그룹에는 파격적인 보상을 했는지 이해가 되는 지점이기도 합니다(물론 이후 잭 웰치는 주주가치 최우선에 대한 자신의 과거 생각을 일부 철회하기도 했다) 이와 같이 리더 그룹에 속하기 위해서는 단지 능력을 갖추는 것 뿐 아니라 구성원의 성장을 위해 기꺼이 자신을 희생하고 헌신할 수 있는 사람이어야 합니다.
⸻

참고로 이 문제의 답은 총 38분입니다. 문제를 풀어보며 조직 관리에 대해서도 한번 고민해봐도 좋을 것 같네요.

험한 산속에 5명이 고립되어 있습니다. 생존하려면 어둡고 위험한 다리를 건너 구조대에게 가야 합니다. 그러나 다음과 같은 제약 조건이 있습니다. 1. 다리는 최대 두 사람까지만 동시에 건널 수 있습니다.2. 반드시 등불이 있어야만 다리를 건널 수 있습니다. 등불은 단 하나뿐입니다.3. 각 조난자가 다리를 건너는 속도는 다릅니다:• A: 3분• B: 5분• C: 7분• D, E: 각각 10분 가장 빨리 모두가 다리를 건너 구조대에게 도달할 수 있는 시간은 얼마일까요? 맞습니다. 이 질문은 최적화에 관한 질문입니다. 엔지니어 면접 질문으로 종종 묻던 것 중에 하나입니다. 모든 사람이 가장 빠르고 안전하게 다리를 건너기 위해서는 빠른 속도를 가진 A와 B가 주도적으로 움직여야 하며 그 과정에서 가장 빠른 사람(A)이 반복적으로 왕복하며 등불을 옮겨야 하는 부담을 지게 됩니다. 결국, 가장 빠른 사람의 헌신과 희생이 모두의 생존 가능성을 높이게 됩니다. 이 질문 속 진짜 숨은 의도는 단순히 최적화의 답을 구하는 것이 아니라, 조직 내 업무 최적화에 대해 많은 생각을 이끌어내는 데 있습니다. 조직에서도 이와 비슷하게 전체 업무의 효율성은 가장 느린 구성원에게 맞춰지며, 가장 뛰어난 인재가 전체의 효율을 극대화하기 위해 더 많은 역할과 책임을 짊어지게 됩니다. 뛰어난 인재가 지속적으로 성과를 내기 위해서는 그들의 기여를 인정하고 적절히 보상해야 하는 이유이기도 합니다. 경영의 신으로 불리우던 GE의 잭 웰치(Jack Welch)가 하위 성과 10% 그룹은 과감한 정리 해고, 상위 리더 그룹에는 파격적인 보상을 했는지 이해가 되는 지점이기도 합니다(물론 이후 잭 웰치는 주주가치 최우선에 대한 자신의 과거 생각을 일부 철회하기도 했다) 이와 같이 리더 그룹에 속하기 위해서는 단지 능력을 갖추는 것 뿐 아니라 구성원의 성장을 위해 기꺼이 자신을 희생하고 헌신할 수 있는 사람이어야 합니다.⸻ 참고로 이 문제의 답은 총 38분입니다. 문제를 풀어보며 조직 관리에 대해서도 한번 고민해봐도 좋을 것 같네요.

최적화 문제 속에 숨은 의도

현업에서 디자인 시스템 프로젝트가 진행되다 보면 종종 이런 질문을 하게 됩니다. “처음엔 잘 가고 있었던 것 같은데, 왜 이게 점점 이상해지는 걸까?” 이유는 생각보다 단순합니다. 팀원들이 각자 다른 곳을 보고 있기 때문입니다. 서로 다른 우선순위, 엇갈리는 방향 디자인 시스템을 만들다 보면 이런 일이 자주 벌어집니다. 디자이너는 ‘예쁘게’ 디자인하는...

우리만의 디자인 시스템, 어디서부터 시작할까? · DaleStudy/daleui · Discussion #392

달레 스터디의 오픈소스 디자인 시스템 프로젝트인 달레UI는 기획부터 디자인, 개발까지의 전 과정을 투명하게 공유하며, 함께 성장하는 것을 목표로 하고 있습니다.

그 두 번째 이야기로, 디자인 시스템 팀의 디자인 리드이신 Mingu Kang 님께서 한국, 캐나다, 영국에서 각기 다른 환경과 경험을 가진 팀원들이 어떻게 하나의 방향을 향해 나아가게 되었는지를 공유해주셨습니다.

✔️ 우리 디자인 시스템의 핵심 가치는 뭘까?
✔️ 어떤 문제를 해결하고 싶은 걸까?
✔️ 그게 잘 되고 있는지는 어떻게 알 수 있을까?

이 질문들에 대한 고민을 바탕으로 워크숍을 통해 미션과 목표, 핵심 가치를 함께 정립해 나간 과정을 구체적이고 생생하게 담아낸 글입니다. 디자인 시스템은 물론 협업 문화나 원격 팀워크에 관심 있는 분들께도 진심으로 추천드리고 싶은 이야기입니다.

📝 글 보러가기: https://github.com/DaleStudy/daleui/discussions/392
(정식 블로그가 오픈되기 전까지는 GitHub Discussions를 통해 콘텐츠를 공유할 예정입니다.)

디자인 시스템에 관심 있는 디자이너, 개발자 여러분의 많은 관심과 피드백 부탁드립니다! 🙌

달레 스터디의 오픈소스 디자인 시스템 프로젝트인 달레UI는 기획부터 디자인, 개발까지의 전 과정을 투명하게 공유하며, 함께 성장하는 것을 목표로 하고 있습니다. 그 두 번째 이야기로, 디자인 시스템 팀의 디자인 리드이신 Mingu Kang 님께서 한국, 캐나다, 영국에서 각기 다른 환경과 경험을 가진 팀원들이 어떻게 하나의 방향을 향해 나아가게 되었는지를 공유해주셨습니다. ✔️ 우리 디자인 시스템의 핵심 가치는 뭘까? ✔️ 어떤 문제를 해결하고 싶은 걸까? ✔️ 그게 잘 되고 있는지는 어떻게 알 수 있을까? 이 질문들에 대한 고민을 바탕으로 워크숍을 통해 미션과 목표, 핵심 가치를 함께 정립해 나간 과정을 구체적이고 생생하게 담아낸 글입니다. 디자인 시스템은 물론 협업 문화나 원격 팀워크에 관심 있는 분들께도 진심으로 추천드리고 싶은 이야기입니다. 📝 글 보러가기: https://github.com/DaleStudy/daleui/discussions/392 (정식 블로그가 오픈되기 전까지는 GitHub Discussions를 통해 콘텐츠를 공유할 예정입니다.) 디자인 시스템에 관심 있는 디자이너, 개발자 여러분의 많은 관심과 피드백 부탁드립니다! 🙌

GitHub

🧭 우리만의 디자인 시스템, 어디서부터 시작할까?

원문: https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/

(번역)자바스크립트가 웹을 망가뜨렸습니다. (그리고 이를 진보라고 불렀습니다)

자극적인 글을 하나 읽었다.

'개발자들이 새로운 기술 도구로 ‘기술 놀이’를 하느라 복잡성과 비용을 키웠다.'

프론트엔드가 지금까지 발전하며 수 많은 고민과 개선이 있었겠지만, 그 결과 20년전 수십 kb로 구현할 수 있던 기능이 이제는 수 mb의 js 파일을 필요로 한다.

그렇다고 유지보수성이나 개발 생산성이 정말로 향상되었는가? Yes 이면서도 No 이다. 프레임워크와 툴체인은 초기 개발과 반복 작업을 빠르게 만들었지만, 그 대가로 가파르게 상승한 복잡도 속에서 사소한 수정조차 전방위적 사이드 이펙트를 일으키는 구조가 되었다. 생산성은 순간적으로 올라갔지만, 유지보수는 점점 더 전문성과 컨텍스트 의존도를 요구하게 된 것이다.

그리고 이제는 그 복잡도를 유지하면서 새로운 기능을 추가하기 위해 조직은 더 많은 인력과 인건비, 세분화된 포지션을 감당해야 한다. 하나의 기능을 구현하기 위해 프론트엔드, 백엔드, DevOps, QA, 기획이 머리를 맞대야 하고, 각 단계마다 파이프라인을 통과해야만 한다. (과거엔 '웹 마스터' 라는 1인 직책이 있었다는 것을 기억하는가?) 개발은 점점 더 느려지고, 사소한 변경도 일정과 리소스의 계산 대상이 된다. 결국 복잡성은 기술적 문제가 아니라 조직 전체의 민첩성과 효율성을 갉아먹는 구조적 비용으로 이어진다.

물론, 지금의 프론트엔드 스택이 만들어낸 복잡성이 전적으로 불필요하다고 말할 수는 없다. 웹이 더 이상 정적인 문서의 나열이 아닌, 복잡한 상호작용과 상태를 갖는 ‘애플리케이션’의 역할을 감당하게 되면서, 그만큼 체계화된 설계와 개발자 경험(DX)을 위한 도구가 필요해졌다는 주장도 충분히 설득력이 있다. 실제로 컴포넌트화, 타입 시스템, 상태 관리 패턴 등은 팀 규모가 커질수록 유지보수성과 협업 효율을 높여주는 도구이기도 하다. 문제는 이 도구들이 ‘필요한 곳’에 쓰이는 것이 아니라, ‘모든 곳’에 일괄적으로 적용되고 있다는 점이다.

2016년, 모 회사의 기술 면접 과제를 해결하기 위해 redux를 처음 익힐 때가 떠오른다. 단순히 버튼 하나 누를 때 값을 바꾸는 작업인데, 액션을 만들고, 타입을 정의하고, 리듀서를 작성하고, 디스패치를 연결해야 했다. '왜 이렇게 어렵고 복잡하게 상태를 관리해야 하지?' 하는 의문이 들었지만, 그땐 '원래 React 개발은 그런가 보다' 하고 넘겼다. 지금 돌이켜보면, 그 복잡함은 필수가 아니라 비판 없이 수용된 일종의 정답처럼 느껴졌다.

SSR도 마찬가지다. React 초기에는 SPA 기반 CSR로 인해 SEO조차 쉽지 않았던 기억이 난다. 백엔드 개발자로 몇 년을 보내고 어느 순간 프론트엔드 개발 트렌드를 보았을 때 Helmet과 같은 React SSR 방식이 유행을 타고 있었다. 그런데 원래 웹 개발은 모두 서버 사이드 렌더링이 아니었던가?

결국 모던 프론트엔드 프레임워크라 불리는 많은 것들이 구현하고 있던 것은 예전부터 기본값으로 주어졌던 기능들의 복잡하고 비효율적인 재현이었다. 라우팅, 메타태그, 템플릿 렌더링, 캐싱 같은 기본기를 다시 자바스크립트 생태계 안에서 어렵게 되살려내며 마치 그것이 혁신인 양 포장하고 있었을지도 모른다.

시간이 지날 수록 복잡한 빌드 파이프라인, 무거운 프레임워크, 과도한 추상화는 개발자에게는 익숙한 환경이 되었지만, 사용자에게는 점점 낯설고 느린 웹을 안겨주고 있다. 이제 마케터는 간단한 콘텐츠 수정조차 개발자에게 의존해야 하고, SEO 담당자는 개발자만이 읽을 수 있는 코드로 가려진 콘텐츠 탓에 검색 노출을 장담할 수 없다. 한 줄의 수정도 수차례 배포를 거쳐야 하며, 정작 페이지는 여전히 느리고 불안정하다.

정말 지금의 모습은 DX (Developer Experience) 를 위해 UX 를 해치고 있는걸까?

자극적인 글을 하나 읽었다. '개발자들이 새로운 기술 도구로 ‘기술 놀이’를 하느라 복잡성과 비용을 키웠다.' 프론트엔드가 지금까지 발전하며 수 많은 고민과 개선이 있었겠지만, 그 결과 20년전 수십 kb로 구현할 수 있던 기능이 이제는 수 mb의 js 파일을 필요로 한다. 그렇다고 유지보수성이나 개발 생산성이 정말로 향상되었는가? Yes 이면서도 No 이다. 프레임워크와 툴체인은 초기 개발과 반복 작업을 빠르게 만들었지만, 그 대가로 가파르게 상승한 복잡도 속에서 사소한 수정조차 전방위적 사이드 이펙트를 일으키는 구조가 되었다. 생산성은 순간적으로 올라갔지만, 유지보수는 점점 더 전문성과 컨텍스트 의존도를 요구하게 된 것이다. 그리고 이제는 그 복잡도를 유지하면서 새로운 기능을 추가하기 위해 조직은 더 많은 인력과 인건비, 세분화된 포지션을 감당해야 한다. 하나의 기능을 구현하기 위해 프론트엔드, 백엔드, DevOps, QA, 기획이 머리를 맞대야 하고, 각 단계마다 파이프라인을 통과해야만 한다. (과거엔 '웹 마스터' 라는 1인 직책이 있었다는 것을 기억하는가?) 개발은 점점 더 느려지고, 사소한 변경도 일정과 리소스의 계산 대상이 된다. 결국 복잡성은 기술적 문제가 아니라 조직 전체의 민첩성과 효율성을 갉아먹는 구조적 비용으로 이어진다. 물론, 지금의 프론트엔드 스택이 만들어낸 복잡성이 전적으로 불필요하다고 말할 수는 없다. 웹이 더 이상 정적인 문서의 나열이 아닌, 복잡한 상호작용과 상태를 갖는 ‘애플리케이션’의 역할을 감당하게 되면서, 그만큼 체계화된 설계와 개발자 경험(DX)을 위한 도구가 필요해졌다는 주장도 충분히 설득력이 있다. 실제로 컴포넌트화, 타입 시스템, 상태 관리 패턴 등은 팀 규모가 커질수록 유지보수성과 협업 효율을 높여주는 도구이기도 하다. 문제는 이 도구들이 ‘필요한 곳’에 쓰이는 것이 아니라, ‘모든 곳’에 일괄적으로 적용되고 있다는 점이다. 2016년, 모 회사의 기술 면접 과제를 해결하기 위해 redux를 처음 익힐 때가 떠오른다. 단순히 버튼 하나 누를 때 값을 바꾸는 작업인데, 액션을 만들고, 타입을 정의하고, 리듀서를 작성하고, 디스패치를 연결해야 했다. '왜 이렇게 어렵고 복잡하게 상태를 관리해야 하지?' 하는 의문이 들었지만, 그땐 '원래 React 개발은 그런가 보다' 하고 넘겼다. 지금 돌이켜보면, 그 복잡함은 필수가 아니라 비판 없이 수용된 일종의 정답처럼 느껴졌다. SSR도 마찬가지다. React 초기에는 SPA 기반 CSR로 인해 SEO조차 쉽지 않았던 기억이 난다. 백엔드 개발자로 몇 년을 보내고 어느 순간 프론트엔드 개발 트렌드를 보았을 때 Helmet과 같은 React SSR 방식이 유행을 타고 있었다. 그런데 원래 웹 개발은 모두 서버 사이드 렌더링이 아니었던가? 결국 모던 프론트엔드 프레임워크라 불리는 많은 것들이 구현하고 있던 것은 예전부터 기본값으로 주어졌던 기능들의 복잡하고 비효율적인 재현이었다. 라우팅, 메타태그, 템플릿 렌더링, 캐싱 같은 기본기를 다시 자바스크립트 생태계 안에서 어렵게 되살려내며 마치 그것이 혁신인 양 포장하고 있었을지도 모른다. 시간이 지날 수록 복잡한 빌드 파이프라인, 무거운 프레임워크, 과도한 추상화는 개발자에게는 익숙한 환경이 되었지만, 사용자에게는 점점 낯설고 느린 웹을 안겨주고 있다. 이제 마케터는 간단한 콘텐츠 수정조차 개발자에게 의존해야 하고, SEO 담당자는 개발자만이 읽을 수 있는 코드로 가려진 콘텐츠 탓에 검색 노출을 장담할 수 없다. 한 줄의 수정도 수차례 배포를 거쳐야 하며, 정작 페이지는 여전히 느리고 불안정하다. 정말 지금의 모습은 DX (Developer Experience) 를 위해 UX 를 해치고 있는걸까?

Medium

사용자가 아닌 개발자를 위한 웹 개발의 시대

”영리함보다 단순함을 선택하세요. 추상화보다 투명성을 선택하세요. 결과를 아키텍처보다 우선시하세요.“

좋은 글이네요. 어쩔때는 단순하게 문제에 임해도 된다는 것을 환기시켜주고, 진짜 그간 너무 생산성에 목맨거 같기도 하네요 ㅋㅋ

Claude 너.. 아주 실망이야.. 😑 돈을 저렇게 처묵처묵하고는.. 에잉~

Codex랑 동일한 걸 항상 같이 시켜보는데, 코드베이스 규모가 좀 큰 프로젝트는 OpenAI Codex가 잘하네요.

그러고보니 Claude로 만족할만한 결과가 나온 적이 없는데.. 혹시 Claude 너.. 나 싫어하니.. 😥

Claude 너.. 아주 실망이야.. 😑 돈을 저렇게 처묵처묵하고는.. 에잉~ Codex랑 동일한 걸 항상 같이 시켜보는데, 코드베이스 규모가 좀 큰 프로젝트는 OpenAI Codex가 잘하네요. 그러고보니 Claude로 만족할만한 결과가 나온 적이 없는데.. 혹시 Claude 너.. 나 싫어하니.. 😥

오늘은 키보드 이야기를 해봤어요!

9년간 개발자로 일하며 사용해본 키보드가 10개가 넘더라고요. 매직키보드부터 끝판왕인 리얼포스까지 다양한 키보드를 경험해본 이야기를 담았어요. 재미있게 봐주세요!

https://youtu.be/BXSZBz0YQuc

오늘은 키보드 이야기를 해봤어요! 9년간 개발자로 일하며 사용해본 키보드가 10개가 넘더라고요. 매직키보드부터 끝판왕인 리얼포스까지 다양한 키보드를 경험해본 이야기를 담았어요. 재미있게 봐주세요! https://youtu.be/BXSZBz0YQuc

개발자라면 키보드는 다양하게 써봐야죠

안녕하세요. 그린입니다 🍏이번 포스팅에서는 Bring Swift Charts to the third dimension이라는 WWDC 2025의 세션을 정리해보겠습니다 🙋🏻 Bring Swift Charts to the third dimensionIntroduction다들 아시는 Swift Charts를 3차원으로 가져오는것에 대한 세션이에요.Chart3D를 사용해서 2D Swift Cahrts를 3차원으로 가져오고 시각화하는 방법을 소개하고 있습니다. 알아볼까요? 우선 Swift Charts는 접근성이 뛰어나고 시각적인 차트를 만드는 프레임워크이죠.차트는 다양하게 애플 플랫폼에서 사용되고 있어요. 배터리 잔량이나 수학 함수 그래프 등 정말 다양하게 쓰일 수 있죠. Swift Charts에서는 사용..

Bring Swift Charts to the third dimension (feat. WWDC 2025)

이번 WWDC 2025 세션에서 기존 SwiftChart 프레임워크에 3D를 손쉽게 표현할 수 있는 Chart3D가 지원되었습니다 🙋🏻

Bring Swift Charts to the third dimension 세션에서 자세히 소개하고 있어요.

잘 사용한다면 사용자에게 훨씬 더 나은 몰입형 경험을 제공해줄 수 있게 됩니다.
특히 Vision Pro에서는 더 빛을 발할거라 생각해요.

세션 내용이 짧지만 그 속에서 쉽게 핵심을 이해할 수 있도록 정리해봤습니다.

이번 WWDC 2025 세션에서 기존 SwiftChart 프레임워크에 3D를 손쉽게 표현할 수 있는 Chart3D가 지원되었습니다 🙋🏻 Bring Swift Charts to the third dimension 세션에서 자세히 소개하고 있어요. 잘 사용한다면 사용자에게 훨씬 더 나은 몰입형 경험을 제공해줄 수 있게 됩니다.특히 Vision Pro에서는 더 빛을 발할거라 생각해요. 세션 내용이 짧지만 그 속에서 쉽게 핵심을 이해할 수 있도록 정리해봤습니다.

iOYES

3D Chart를 소개합니다 (feat. WWDC 2025)

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

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

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

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

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

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

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

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

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

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

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

내가 알고 있는 지식과 경험이 내일이면 쓸모없어질 수도 있는 시대가 되었다.

내가 알고 있는 지식과 경험이 내일이면 쓸모없어질 수도 있는 시대가 되었다.

클라우드 환경에서의 Redis 라이센스 정책에 의해서 최근 io.valkey 에 대한 마이그레이션을 준비하고 있습니다. Valkey 는 Redis 7.4 미만 버전의 fork 서비스로 현재는 valkey 8.0 까지 release 되었지만, 저희는 아직 Valkey 7.2.x 로 테스트를 하고 있어요.

fork 버전이기 때문에 사용성에 있어서는 Redis 와 큰 차이가 없고, 가장 많이 사용되는 lettuce 에서의 호환 (하지만, 일부 기능은 사용할 수 없음) 으로 인하여 큰 무리 없이 하나씩 마이그레이션을 하고 있습니다.

하지만, Valkey 의 버전이 올라가면 올라갈수록 lettuce 를 사용이 안될 수도 있다는 점을 가정하여, io.valkey.glide 의 라이브러리를 테스트하고, 저희에 맞게 wrapping 을 하고 있는데요. valkey 서버와 다르게 Glide 라이브러리에 대한 지양점의 차이로 조금은 혼란스러운 상태가 있어서, 기록을 남겨둘까 해요.

 * MasterReplica 구조에서 Replica 노드 직접 연결
   * lettuce 와 다르게 Valkey 는 Replica Role 을 가지는 Node 에 직접 연결을 할 수 없어요.
   * Replica Role 은 항상 Master 와 함께 붙어 다니면서 읽기 전략을 수행해야 하는 관점때문에 그런거 같아요.
 * MasterReplica 에서의 pipeline 은 Primary 노드에 집중되요.
   * Pipeline 에 쓰기 명령을 할 수 있기에, 이와 같은 현상이 생겼을 것이라 생각해요.
   * 하지만, 이에 대한 설정을 사용자에게 맡긴다면 좀 더 좋은 환경을 제공할 것이라 생각하여, Github 에 이슈를 발행하였어요.
 * Cluster Topology 업데이트는 자동 수행이 되어요.
   * Cluster 노드 변경을 위해서 lettuce 는 Topology 업데이트 전략을 추가 해줘야 했다면 Glide 라이브러리는 이를 알아서 해결해요.
 * Transaction, Pipeline 명령을 위한 Connection 관리가 없어도 되요.
   * lettuce 는 Connection 에 직접 명령을 보내는 구조로, pipeline 을 위하여 autoFlush 를 끄고, 명령어를 모아 놓은 다음 flushCommands 를 해야 했거나.
   * transaction 의 multi 가 수행되면 connection 에 담기는 명령이 모두 multi 아래에서 수행되어야 하기에 Connection 을 별도로 만들거나 Pool 정책이 필요 했는데요.
   * 명령어 전달 방식이 channel 에 모이고 이를 Connection 에 flush 하는 방식으로 지원이 되면서 Pool 에 대한 신경을 쓰지 않아도 되요.
 * Cluster 환경에서 mget, hmget 과 같이 같은 Slot 에서만 동작해야 하는 명령들이. Glide 모듈 내에서는 좀더 쉽게 접근이 가능하게 되요.
   * 각 Key 의 HashSlot 을 모듈내에서 구하고, Key 가 저장되어 있는 node 를 찾아서 그룹핑하여 한번에 전달하는 구조에요.
   * 하지만, 이 경우 최악의 상황에서는 모든 Node 에 한번씩 연결을 해야 하기 때문에 좋지 못한 결과를 얻을 수는 있고, Valey Cluster 서버내에서는 해당 명령을 지원하지 않기 때문에 모듈에서 되는 것 가지고 Valkey 이는 이것이 수행되는 구나 등의 오해가 있을 수 있어요.

Spring Data Redis 를 사용하지 않고 Lettuce 을 직접사용하면서 모듈 마이그레이션 과정에서 작은 (?) 차이점들을 알게 되었는데요.

Server 가 아닌 모듈이 지향하는 Remote Cache Server 와의 차이를 이해 한다면 조금은 위와 같은 사항이 이해되긴 합니다.
 * lettuce : Server 와 1:1 로 맞추어서 기능을 만들고 서버에서 제공하지 않는 기능을 억지로 만들지 않아요.
 * io.valkey.glide: 사용자의 편의성을 우선시 하고, performane 에 우선을 두고 있어요. 즉, valkey 서버에서는 지원하지 않는 기능이지만 편의성으로 확장을 하고 있는거 같더라구요.

모듈을 Wrapping 을 하게 되면, 우리의 케이스에 맞춰서 다양한 생각을 하게 되는 경험을 하게 되는데요. 이때 단순이 소스 모듈이 지원을 하기 때문에 서버도 이런 기능을 제공하겠지? 라는 생각 보다는 서버의 상황과 맞추어서 생각을 좀 더 깊게 해야 하는 케이스가 항상 발생하는것 같아요.

단순히 되네? 라기 보다는 이 모듈은 이게 왜 되는것이지? 하는 생각이 좀더 필요하지 않을까 싶어요.

클라우드 환경에서의 Redis 라이센스 정책에 의해서 최근 io.valkey 에 대한 마이그레이션을 준비하고 있습니다. Valkey 는 Redis 7.4 미만 버전의 fork 서비스로 현재는 valkey 8.0 까지 release 되었지만, 저희는 아직 Valkey 7.2.x 로 테스트를 하고 있어요. fork 버전이기 때문에 사용성에 있어서는 Redis 와 큰 차이가 없고, 가장 많이 사용되는 lettuce 에서의 호환 (하지만, 일부 기능은 사용할 수 없음) 으로 인하여 큰 무리 없이 하나씩 마이그레이션을 하고 있습니다. 하지만, Valkey 의 버전이 올라가면 올라갈수록 lettuce 를 사용이 안될 수도 있다는 점을 가정하여, io.valkey.glide 의 라이브러리를 테스트하고, 저희에 맞게 wrapping 을 하고 있는데요. valkey 서버와 다르게 Glide 라이브러리에 대한 지양점의 차이로 조금은 혼란스러운 상태가 있어서, 기록을 남겨둘까 해요. <ul ><li>MasterReplica 구조에서 Replica 노드 직접 연결<ul ><li>lettuce 와 다르게 Valkey 는 Replica Role 을 가지는 Node 에 직접 연결을 할 수 없어요.</li><li>Replica Role 은 항상 Master 와 함께 붙어 다니면서 읽기 전략을 수행해야 하는 관점때문에 그런거 같아요.</li></ul></li><li>MasterReplica 에서의 pipeline 은 Primary 노드에 집중되요.<ul ><li>Pipeline 에 쓰기 명령을 할 수 있기에, 이와 같은 현상이 생겼을 것이라 생각해요.</li><li>하지만, 이에 대한 설정을 사용자에게 맡긴다면 좀 더 좋은 환경을 제공할 것이라 생각하여, Github 에 이슈를 발행하였어요.</li></ul></li><li>Cluster Topology 업데이트는 자동 수행이 되어요.<ul ><li>Cluster 노드 변경을 위해서 lettuce 는 Topology 업데이트 전략을 추가 해줘야 했다면 Glide 라이브러리는 이를 알아서 해결해요.</li></ul></li><li>Transaction, Pipeline 명령을 위한 Connection 관리가 없어도 되요.<ul ><li>lettuce 는 Connection 에 직접 명령을 보내는 구조로, pipeline 을 위하여 autoFlush 를 끄고, 명령어를 모아 놓은 다음 flushCommands 를 해야 했거나.</li><li>transaction 의 multi 가 수행되면 connection 에 담기는 명령이 모두 multi 아래에서 수행되어야 하기에 Connection 을 별도로 만들거나 Pool 정책이 필요 했는데요.</li><li>명령어 전달 방식이 channel 에 모이고 이를 Connection 에 flush 하는 방식으로 지원이 되면서 Pool 에 대한 신경을 쓰지 않아도 되요.</li></ul></li><li>Cluster 환경에서 mget, hmget 과 같이 같은 Slot 에서만 동작해야 하는 명령들이. Glide 모듈 내에서는 좀더 쉽게 접근이 가능하게 되요.<ul ><li>각 Key 의 HashSlot 을 모듈내에서 구하고, Key 가 저장되어 있는 node 를 찾아서 그룹핑하여 한번에 전달하는 구조에요.</li><li>하지만, 이 경우 최악의 상황에서는 모든 Node 에 한번씩 연결을 해야 하기 때문에 좋지 못한 결과를 얻을 수는 있고, Valey Cluster 서버내에서는 해당 명령을 지원하지 않기 때문에 모듈에서 되는 것 가지고 Valkey 이는 이것이 수행되는 구나 등의 오해가 있을 수 있어요.</li></ul></li></ul> Spring Data Redis 를 사용하지 않고 Lettuce 을 직접사용하면서 모듈 마이그레이션 과정에서 작은 (?) 차이점들을 알게 되었는데요. Server 가 아닌 모듈이 지향하는 Remote Cache Server 와의 차이를 이해 한다면 조금은 위와 같은 사항이 이해되긴 합니다.<ul ><li>lettuce : Server 와 1:1 로 맞추어서 기능을 만들고 서버에서 제공하지 않는 기능을 억지로 만들지 않아요.</li><li>io.valkey.glide: 사용자의 편의성을 우선시 하고, performane 에 우선을 두고 있어요. 즉, valkey 서버에서는 지원하지 않는 기능이지만 편의성으로 확장을 하고 있는거 같더라구요.</li></ul> 모듈을 Wrapping 을 하게 되면, 우리의 케이스에 맞춰서 다양한 생각을 하게 되는 경험을 하게 되는데요. 이때 단순이 소스 모듈이 지원을 하기 때문에 서버도 이런 기능을 제공하겠지? 라는 생각 보다는 서버의 상황과 맞추어서 생각을 좀 더 깊게 해야 하는 케이스가 항상 발생하는것 같아요. 단순히 되네? 라기 보다는 이 모듈은 이게 왜 되는것이지? 하는 생각이 좀더 필요하지 않을까 싶어요.

io.valkey.glide 의 장단...

﻿
문서를 작성하다 보면 한 페이지를 넘기고 싶지 않아서 내용을 억지로 한 장에 넣는 경험을 하게 됩니다. 특히 비주얼을 중요하게 생각하는 사람일수록 공감할 만한 이야기입니다. 문서의 내용보다 문서가 보여지는 형태에 더 신경을 쓰다 보면, 하고 싶은 말을 생략하거나 지나치게 함축적으로 표현하게 됩니다.
다르게 생각하면, 페이지를 분리해서 하고 싶은 이야기를 넉넉하게 표현할 수 있습니다. 꼭 한 페이지를 텍스트로 빼곡하게 채우지 않아도 됩니다. 오히려 여백의 미를 살려 띄엄띄엄 작성하는 것이 더 효과적일 수 있습니다. 특히 슬라이드 형식의 포트폴리오 문서는 이런 구성이 더욱 적합합니다. 예전에 읽었던 아티클 중, 잘 만든 PPT의 조건으로 "한 슬라이드에 하나의 메시지만 담을 것"이란 조언이 떠오릅니다.

포트폴리오 피드백을 하다 보면, 하나의 슬라이드에 내용을 빼곡하게 작성한 경우를 자주 봅니다. 비어 보이는 페이지가 어색하고 불안해서 무언가 채워 넣고 싶은 마음 때문입니다. 하지만 읽는 사람은 그렇지 않습니다. 빽빽한 슬라이드를 보면 오히려 "이걸 어떻게 읽지?"라는 압박감을 느끼고 빠르게 넘겨버립니다. 그러면 머릿속에 남는 내용은 거의 없습니다. 당연히 서류 전형에서 긍정적인 평가를 받기 어렵습니다.
문서는 빠르게 읽히고, 이해하기 쉬워야 합니다. 그래야 처음부터 끝까지 읽는 이의 흥미가 유지되고, 핵심 메시지가 기억에 남습니다. 간결한 메시지, 시각적으로 명확한 구성은 그 자체로 설득력을 가집니다. 즉, 텍스트를 줄이고, 페이지 수는 늘리는 것이 포트폴리오 제작의 요령입니다.

슬라이드를 여러 장으로 나누고, 한 장마다 간단한 메시지를 담아 구성해 보세요. 마치 애니메이션이 한 장 한 장 움직이듯, 빠르게 넘기면서도 내용이 머릿속에 남는 구성을 만들어야 합니다. 요즘 사람들은 유튜브 숏츠, 인스타그램 릴스, 웹툰 같은 콘텐츠에 익숙합니다. 짧고 임팩트 있는 영상이나 이미지를 반복 소비하는 세대입니다. 그래서 텍스트보다 시각적이고 간결한 메시지 전달이 훨씬 효과적입니다.
포트폴리오도 마찬가지입니다. 재미있고 기억에 남는 문서가 되려면, 남들과 다른 구조와 내용을 담아야 합니다. 단순한 경험 나열이 아니라, 본인의 역량을 증명하는 방식으로 설계해야 합니다. 프로젝트 단위가 아닌 강점 중심으로 목차를 구성하는 것도 하나의 방법입니다. 예를 들어, '문제 해결력', '커뮤니케이션', '사용자 중심 사고'처럼 역량 키워드를 중심으로 사례를 엮어가는 것입니다.

많은 사람이 일반적인 모범답안을 따라 문서를 작성하려 합니다. 하지만 남과 다른 포트폴리오를 만들기 위해선, 자신만의 구조를 스케치하는 것이 중요합니다. 머릿속에 구상은 있지만, 아직 그것을 끄집어내는 경험이 부족할 뿐입니다. 천천히 전체 흐름을 스케치하고, 한 페이지씩 채워가다 보면 결국 완성됩니다.
포트폴리오 작성을 어렵게 느끼는 가장 큰 이유는 '처음부터 완벽해야 한다'는 압박 때문입니다. 어떤 전문가도 단번에 완성된 문서를 만들 수 없습니다. 초안을 만들고, 수정하고, 또 다듬는 과정을 반복하는 것이 정석입니다. 그 과정이 부담스럽더라도, 시작하지 않으면 끝도 없습니다.

연필을 들고 얼굴을 그리고, 눈을 그리고, 코를 그리고, 입을 그리고... 그렇게 하다 보면 하나의 인물이 탄생하듯, 페이지를 한 장씩 작성하다 보면 어느새 훌륭한 포트폴리오가 완성됩니다.
힘을 빼고 문서를 작성해보세요. 웹툰처럼 후루룩 읽히는 문서를 목표로 해보세요. 그리고 그 안에 ‘재미’라는 감정을 담아보세요. 우리도 포트폴리오를 통해 사람들의 기억에 남을 수 있습니다. 그 순간까지, 함께 고민하고, 수정해 갑시다.

﻿문서를 작성하다 보면 한 페이지를 넘기고 싶지 않아서 내용을 억지로 한 장에 넣는 경험을 하게 됩니다. 특히 비주얼을 중요하게 생각하는 사람일수록 공감할 만한 이야기입니다. 문서의 내용보다 문서가 보여지는 형태에 더 신경을 쓰다 보면, 하고 싶은 말을 생략하거나 지나치게 함축적으로 표현하게 됩니다.다르게 생각하면, 페이지를 분리해서 하고 싶은 이야기를 넉넉하게 표현할 수 있습니다. 꼭 한 페이지를 텍스트로 빼곡하게 채우지 않아도 됩니다. 오히려 여백의 미를 살려 띄엄띄엄 작성하는 것이 더 효과적일 수 있습니다. 특히 슬라이드 형식의 포트폴리오 문서는 이런 구성이 더욱 적합합니다. 예전에 읽었던 아티클 중, 잘 만든 PPT의 조건으로 "한 슬라이드에 하나의 메시지만 담을 것"이란 조언이 떠오릅니다. 포트폴리오 피드백을 하다 보면, 하나의 슬라이드에 내용을 빼곡하게 작성한 경우를 자주 봅니다. 비어 보이는 페이지가 어색하고 불안해서 무언가 채워 넣고 싶은 마음 때문입니다. 하지만 읽는 사람은 그렇지 않습니다. 빽빽한 슬라이드를 보면 오히려 "이걸 어떻게 읽지?"라는 압박감을 느끼고 빠르게 넘겨버립니다. 그러면 머릿속에 남는 내용은 거의 없습니다. 당연히 서류 전형에서 긍정적인 평가를 받기 어렵습니다.문서는 빠르게 읽히고, 이해하기 쉬워야 합니다. 그래야 처음부터 끝까지 읽는 이의 흥미가 유지되고, 핵심 메시지가 기억에 남습니다. 간결한 메시지, 시각적으로 명확한 구성은 그 자체로 설득력을 가집니다. 즉, 텍스트를 줄이고, 페이지 수는 늘리는 것이 포트폴리오 제작의 요령입니다. 슬라이드를 여러 장으로 나누고, 한 장마다 간단한 메시지를 담아 구성해 보세요. 마치 애니메이션이 한 장 한 장 움직이듯, 빠르게 넘기면서도 내용이 머릿속에 남는 구성을 만들어야 합니다. 요즘 사람들은 유튜브 숏츠, 인스타그램 릴스, 웹툰 같은 콘텐츠에 익숙합니다. 짧고 임팩트 있는 영상이나 이미지를 반복 소비하는 세대입니다. 그래서 텍스트보다 시각적이고 간결한 메시지 전달이 훨씬 효과적입니다.포트폴리오도 마찬가지입니다. 재미있고 기억에 남는 문서가 되려면, 남들과 다른 구조와 내용을 담아야 합니다. 단순한 경험 나열이 아니라, 본인의 역량을 증명하는 방식으로 설계해야 합니다. 프로젝트 단위가 아닌 강점 중심으로 목차를 구성하는 것도 하나의 방법입니다. 예를 들어, '문제 해결력', '커뮤니케이션', '사용자 중심 사고'처럼 역량 키워드를 중심으로 사례를 엮어가는 것입니다. 많은 사람이 일반적인 모범답안을 따라 문서를 작성하려 합니다. 하지만 남과 다른 포트폴리오를 만들기 위해선, 자신만의 구조를 스케치하는 것이 중요합니다. 머릿속에 구상은 있지만, 아직 그것을 끄집어내는 경험이 부족할 뿐입니다. 천천히 전체 흐름을 스케치하고, 한 페이지씩 채워가다 보면 결국 완성됩니다.포트폴리오 작성을 어렵게 느끼는 가장 큰 이유는 '처음부터 완벽해야 한다'는 압박 때문입니다. 어떤 전문가도 단번에 완성된 문서를 만들 수 없습니다. 초안을 만들고, 수정하고, 또 다듬는 과정을 반복하는 것이 정석입니다. 그 과정이 부담스럽더라도, 시작하지 않으면 끝도 없습니다. 연필을 들고 얼굴을 그리고, 눈을 그리고, 코를 그리고, 입을 그리고... 그렇게 하다 보면 하나의 인물이 탄생하듯, 페이지를 한 장씩 작성하다 보면 어느새 훌륭한 포트폴리오가 완성됩니다.힘을 빼고 문서를 작성해보세요. 웹툰처럼 후루룩 읽히는 문서를 목표로 해보세요. 그리고 그 안에 ‘재미’라는 감정을 담아보세요. 우리도 포트폴리오를 통해 사람들의 기억에 남을 수 있습니다. 그 순간까지, 함께 고민하고, 수정해 갑시다.﻿

한 장에 메시지 하나만

🟪 모임 소개 이번 모임은 직장인 이후의 커리어, 막연하게 창업을 고민하는 사람들을 위한 아이디어 구체화 모임입니다.총 4회의 모임을 통해 이런 것들을 얻을 수 있습니다.✅ 호스트가 제공하는 과제와 프레임을 통해 내 막연한 아이디어가 정말로 시장에 통하는지를 논리적으로 검증할 수 있습니다.✅ 로컬 비즈니스, 자영업, 스타트업 각 유형별 창업 장단점과 선택할 수 있는 지원제도에 관해 구체적으로 알 수 있습니다.✅ 성장 로드맵과 창업 이후 현실에서 마주칠 과제들, 사업계획서 작성법 등에 관해 구체적인 팁과 피드백을 얻을 수 있습니다. 🟪 일시 ... 

[B라운지] (직장인 이후의 삶을 위한) 사업 아이디어 선명하게 다듬기 : PBR

회사 때려치고 사업이나 한번 해볼까?

창업과 사업에 대해 막연한 환상을 갖고 계신가요? 혹은 관심이 있는데 어떻게 해야 할 지 모르겠어서 고민이신가요?

지난 10년간 창업과 사업에 관심이 있거나 초기 단계에서 고민하고 있는 창업가와 사업가들을 대상으로 주로 기업과 기관에서만 풀어놓았던 창업과 사업의 기초, 창업의 로드맵 AtoZ에 대한 이야기를 드디어 일반 성인분들도 배울 수 있도록 과정을 오픈했습니다. 저희의 경험과 노하우가 고스란히 담겨있으면서도 부담없이 편하게 들을 수 있는, 하지만 나의 창업과 사업에 대한 생각을 명확하게 정리할 수 있는 시간이 될 겁니다.

전체적으로 하단과 같은 순서로 진행되며 4주간 주 1회씩 함께 하게 되며, 제가 직접 진행합니다.

1. 창업 아이템 선정 : 고객이 가진 문제는 무엇일까? 고객 문제와 PMF (Product-Market-Fit)

2. 창업 아이템 선택 : 시장에서 필요할까? 어느 고객이 왜 돈을 낼까? KBF (Key Buying Factor)

3. 창업 과정과 절차, 지원 제도 : 스타트업을 할까? 가게를(소상공인) 차릴까? 창업할 때 누구에게 어떤 도움을 받을 수 있을까?

4. 창업 준비와 실행 : 사업계획은 어떻게 세우고 실행할 수 있을까?

보다 상세한 내용 확인과 신청은 하단 링크를 참고해주세요.

https://www.pbr.kr/shop_view/?idx=53

회사 때려치고 사업이나 한번 해볼까? 창업과 사업에 대해 막연한 환상을 갖고 계신가요? 혹은 관심이 있는데 어떻게 해야 할 지 모르겠어서 고민이신가요? 지난 10년간 창업과 사업에 관심이 있거나 초기 단계에서 고민하고 있는 창업가와 사업가들을 대상으로 주로 기업과 기관에서만 풀어놓았던 창업과 사업의 기초, 창업의 로드맵 AtoZ에 대한 이야기를 드디어 일반 성인분들도 배울 수 있도록 과정을 오픈했습니다. 저희의 경험과 노하우가 고스란히 담겨있으면서도 부담없이 편하게 들을 수 있는, 하지만 나의 창업과 사업에 대한 생각을 명확하게 정리할 수 있는 시간이 될 겁니다. 전체적으로 하단과 같은 순서로 진행되며 4주간 주 1회씩 함께 하게 되며, 제가 직접 진행합니다. 1. 창업 아이템 선정 : 고객이 가진 문제는 무엇일까? 고객 문제와 PMF (Product-Market-Fit) 2. 창업 아이템 선택 : 시장에서 필요할까? 어느 고객이 왜 돈을 낼까? KBF (Key Buying Factor) 3. 창업 과정과 절차, 지원 제도 : 스타트업을 할까? 가게를(소상공인) 차릴까? 창업할 때 누구에게 어떤 도움을 받을 수 있을까? 4. 창업 준비와 실행 : 사업계획은 어떻게 세우고 실행할 수 있을까? 보다 상세한 내용 확인과 신청은 하단 링크를 참고해주세요. https://www.pbr.kr/shop_view/?idx=53

www.pbr.kr

회사 때려치고 사업이나 한번 해볼까?

클로드 코드 Max 를 구독한지 한 달째가 되었습니다. 만족감이 대단합니다. 그동안 AI에게 원했던 것들을 드디어 충족을 시켜줍니다. 터미널에서만 사용해도 전혀 불편이 없을 정도로 아주 잘 만든 것 같습니다.

클로드 코드 한 달 사용 후기

클로드 코드 Max 를 구독한지 한 달째가 되었습니다.
만족감이 대단합니다. 그동안 AI에게 원했던 것들을 드디어 충족을 시켜줍니다.
터미널에서만 사용해도 전혀 불편이 없을 정도로 아주 잘 만든 것 같습니다.

클로드 코드 구독을 추천하는가?
클로드 코드 맥스는 한 달에 30만 원입니다. 저는 처음부터 30만 원짜리로 결제했습니다.
어차피 결국엔 이걸 쓰게 될 거라는 걸 알고 있었거든요.

하지만 한 달에 30만 원이라는 돈은 작은 돈이 아닙니다.
써보고 싶어도 부담스러워서 못 쓰는 사람들이 분명 있을 겁니다.

만약 클로드 코드보다 훨씬 더 좋은 AI가 나온다면 나는 쓸 것인지 생각해 보게 됩니다. 한 달에 500만 원이라도?
돈이 많은 사람들은 이걸 결제해서 훨씬 편하게 서비스를 만들고, 돈이 없는 사람들은 손으로 한땀한땀 고생하며 만들어야 하는 건가?
게임에서 고급 갑옷과 칼을 장착한 과금 유저와 단검 하나 든 비과금 유저가 떠오르기도 합니다.
시간이 지나면 가격이 전체적으로 내려가겠지만, 당분간은 더 좋은 모델을 무리하게 내면서 구독 가격이 오를 수도 있을 것 같습니다.

30만 원이 조금 비싸게 느껴지더라도 써보는 걸 추천합니다.
한 달 동안 아주 간단한 서비스 하나 완성한다고 해도 30만 원이면 싼 것 같거든요.
그런 간단한 서비스라도 30만 원주고 누군가에게 인수해 올 수는 없을 겁니다.

Max 를 결제하면 좋은 점도 있습니다.
돈을 낸 만큼 뽕을 뽑으려고 노력하게 됩니다.
하루에 300$ 이상 사용한 날은 기분이 정말 좋습니다.

아래 그림은 제 한 달 동안의 성과인데… 솔직히 영 맘에 들진 않네요.
뽕을 제대로 못 뽑았습니다. (그래도 결과물에 비하면 돈이 아깝진 않습니다)

제게는 항상 자극이 되는 동생이 있습니다. 제 열정을 불러일으켜주는 동생.
예전에 카카오에서 일할 때도 이 친구 옆자리에 앉아 젊음을 불사를 수 있었습니다.
블로그 글을 쓰며 이 친구에게도 보여달라 했습니다. 너의 한 달 동안의 사용량을.

하… 이 정도는 해야 뽕을 뽑았다고 말할 수 있는 것 아닌가?
이 동생의 열정은 어디로 사라지지 않았네요. 역시 저를 불타오르게 만듭니다.
다음 달에는 더 열심히 해봐야겠습니다.

https://jeho.page/essay/2025/07/15/claude-code.html

클로드 코드 Max 를 구독한지 한 달째가 되었습니다. 만족감이 대단합니다. 그동안 AI에게 원했던 것들을 드디어 충족을 시켜줍니다. 터미널에서만 사용해도 전혀 불편이 없을 정도로 아주 잘 만든 것 같습니다. 클로드 코드 구독을 추천하는가? 클로드 코드 맥스는 한 달에 30만 원입니다. 저는 처음부터 30만 원짜리로 결제했습니다. 어차피 결국엔 이걸 쓰게 될 거라는 걸 알고 있었거든요. 하지만 한 달에 30만 원이라는 돈은 작은 돈이 아닙니다. 써보고 싶어도 부담스러워서 못 쓰는 사람들이 분명 있을 겁니다. 만약 클로드 코드보다 훨씬 더 좋은 AI가 나온다면 나는 쓸 것인지 생각해 보게 됩니다. 한 달에 500만 원이라도? 돈이 많은 사람들은 이걸 결제해서 훨씬 편하게 서비스를 만들고, 돈이 없는 사람들은 손으로 한땀한땀 고생하며 만들어야 하는 건가? 게임에서 고급 갑옷과 칼을 장착한 과금 유저와 단검 하나 든 비과금 유저가 떠오르기도 합니다. 시간이 지나면 가격이 전체적으로 내려가겠지만, 당분간은 더 좋은 모델을 무리하게 내면서 구독 가격이 오를 수도 있을 것 같습니다. 30만 원이 조금 비싸게 느껴지더라도 써보는 걸 추천합니다. 한 달 동안 아주 간단한 서비스 하나 완성한다고 해도 30만 원이면 싼 것 같거든요. 그런 간단한 서비스라도 30만 원주고 누군가에게 인수해 올 수는 없을 겁니다. Max 를 결제하면 좋은 점도 있습니다. 돈을 낸 만큼 뽕을 뽑으려고 노력하게 됩니다. 하루에 300$ 이상 사용한 날은 기분이 정말 좋습니다. 아래 그림은 제 한 달 동안의 성과인데… 솔직히 영 맘에 들진 않네요. 뽕을 제대로 못 뽑았습니다. (그래도 결과물에 비하면 돈이 아깝진 않습니다) 제게는 항상 자극이 되는 동생이 있습니다. 제 열정을 불러일으켜주는 동생. 예전에 카카오에서 일할 때도 이 친구 옆자리에 앉아 젊음을 불사를 수 있었습니다.블로그 글을 쓰며 이 친구에게도 보여달라 했습니다. 너의 한 달 동안의 사용량을. 하… 이 정도는 해야 뽕을 뽑았다고 말할 수 있는 것 아닌가? 이 동생의 열정은 어디로 사라지지 않았네요. 역시 저를 불타오르게 만듭니다. 다음 달에는 더 열심히 해봐야겠습니다. https://jeho.page/essay/2025/07/15/claude-code.html

K리그 프로그래머

클로드 코드 Max 한 달 사용 후기

팀이나, 파트등의 조직에서의 생활을 하다 보면은 나의 의사와 다른 상황이 펼쳐지는 일이 꽤 많은 빈도로 발생이 되는거 같아요. 짧다면 짧고, 길다면 긴 조직 생황을 하였지만 가장 어려운 것이 나의 의사와 다른 생각을 가지는 일들이 생기는 것들 같아요.

꾹꾹 참으면서 생활을 하게 되면, 누적이 되어 정신적으로 물리적으로 힘들어지고, 방안을 찾고자 이야기를 하고자 하면 밉보이는게 아닐까 하는 두려움이 항상 고민의 고민을 만들어나가는거 같아요.

이러한 문제를 해결하기 위하여, 조직에서의 이탈도 고민을 할때도 있지만, 이또한 회피가 되기 떄문에, 다른곳에서 또 같은 문제가 생기는 경우 또 다시 회피를 결정하게 되고 이것이 습관이 될까 하는 두려움도 있습니다.

미사여구가 많았지만, 결국 도돌이표가 되는 이야기가 되고, 이러한 상황을 어떻게 풀어나가야 하나 하는 스트레스가 너무 심하게 오고 있어요.

힘들어도 참아야지, 이야기를 하면서 풀어나가야지. 라고 스스로 다잡을때도 있지만, 쉽게 하지 못하는 행동중에 하나 인것 같아요.

나름 경험은 쌓였고 이제 어른이 되었지만, 이러한 문제에 대해서는 아직 성숙하지 못한 사람이 되는 제 자신이 너무 밉기도 해요....

팀이나, 파트등의 조직에서의 생활을 하다 보면은 나의 의사와 다른 상황이 펼쳐지는 일이 꽤 많은 빈도로 발생이 되는거 같아요. 짧다면 짧고, 길다면 긴 조직 생황을 하였지만 가장 어려운 것이 나의 의사와 다른 생각을 가지는 일들이 생기는 것들 같아요. 꾹꾹 참으면서 생활을 하게 되면, 누적이 되어 정신적으로 물리적으로 힘들어지고, 방안을 찾고자 이야기를 하고자 하면 밉보이는게 아닐까 하는 두려움이 항상 고민의 고민을 만들어나가는거 같아요. 이러한 문제를 해결하기 위하여, 조직에서의 이탈도 고민을 할때도 있지만, 이또한 회피가 되기 떄문에, 다른곳에서 또 같은 문제가 생기는 경우 또 다시 회피를 결정하게 되고 이것이 습관이 될까 하는 두려움도 있습니다. 미사여구가 많았지만, 결국 도돌이표가 되는 이야기가 되고, 이러한 상황을 어떻게 풀어나가야 하나 하는 스트레스가 너무 심하게 오고 있어요. 힘들어도 참아야지, 이야기를 하면서 풀어나가야지. 라고 스스로 다잡을때도 있지만, 쉽게 하지 못하는 행동중에 하나 인것 같아요. 나름 경험은 쌓였고 이제 어른이 되었지만, 이러한 문제에 대해서는 아직 성숙하지 못한 사람이 되는 제 자신이 너무 밉기도 해요....

회피를 해야 할까요? 방안을 찾아야 할까요?

올봄, AI 시장을 강타한 키워드가 있습니다. 오늘의 주인공 “MCP”입니다. 무언가 단어의 생김새는 GPT하고 비스무리한데요. 프로토콜, 서버, 클라이언트처럼 또 눈에 익은 단어들과 붙어 다니지만, 그 개념은 손에 잘 안 잡힙니다. 그런데 또 여기저기 슬금슬금 “MCP로 생산성을 미친 듯 끌어올렸다”는 이야기가 돌고 있습니다. 혼자 밀려난 느낌도 듭니다. 그래서 알아봤습니다. 의미를 파헤치고, 사람들의 반응을 살피고, 직접 체험해 볼 겁니다. 특히 어디까지 이 친구와 가까워져야 할지, 선을 그어보려고 합니다. 그 끝에서 이 질문에 답해보겠습니다. MCP 모르면 대체 얼마나 손해 보는 걸까요?

MCP 모르면 대체 얼마나 손해 보는 걸까? | 요즘IT

올해 가장 핫한 기술을 꼽자면 단연 MCP 가 아닐까 싶습니다.

그만큼 많은 사람들의 관심이 집중되고 있고,
"이렇게 관심이 많은데 나도 한번 알아봐야 하지 않을까?" 하는 생각을 하신 분들도 계실것 같습니다.

요즘 올라오는 글들을 보면 대부분 MCP 의 개념과 원리를 설명하는 내용이 주를 이루는데요,
특이하게도 MCP 에 대한 개념과 원리뿐만 아니라 이걸 모르면 어떻게 될지, AI 기술 발전을 어떻게 따라가야할지에 대한 의견을 담은 아티클이 있어 공유드립니다.

머신러닝부터 시작된 인공지능 기술은 LLM 의 등장, 그리고 MCP 로의 진화에 이르기까지
점점 더 쉽고 빠르게 응용할 수 있는 방향으로 발전하고 있다고 느낍니다.
이런 기술들을 잘 익히고 유용하게 활용할 수 있다면 더없이 좋겠지만,
개인적인 생각으로 이걸 꼭 사용하지 않는다고 해서 도태되거나 문제가 생긴다고는 생각하지 않습니다.

다만 글의 말미에서도 언급되듯, 내가 비록 당장 MCP 등과 같은 AI 기술들을 사용하지 않더라도
AI 가 어떤 흐름으로 발전하고 있는지, MCP 가 왜 나오고 어떤 한계를 보완했는지 등만 미리 파악하면 추후 다른 기술이 새로 나오더라도 금방 이해하고 언제든 사용해 볼 수 있지 않을까 싶습니다.

그동안 MCP 에 대해 궁금했지만 이해가 안되었던 분들 혹은 AI 의 빠른 발전속도에 혼란스러우셨던 분들에게 도움이 될거라 생각하는데요
관심있으신 분들은 한번 읽어보시면 좋겠습니다.

📚 원문
 * https://yozm.wishket.com/magazine/detail/3207/

올해 가장 핫한 기술을 꼽자면 단연 MCP 가 아닐까 싶습니다. 그만큼 많은 사람들의 관심이 집중되고 있고, "이렇게 관심이 많은데 나도 한번 알아봐야 하지 않을까?" 하는 생각을 하신 분들도 계실것 같습니다. 요즘 올라오는 글들을 보면 대부분 MCP 의 개념과 원리를 설명하는 내용이 주를 이루는데요,특이하게도 MCP 에 대한 개념과 원리뿐만 아니라 이걸 모르면 어떻게 될지, AI 기술 발전을 어떻게 따라가야할지에 대한 의견을 담은 아티클이 있어 공유드립니다. 머신러닝부터 시작된 인공지능 기술은 LLM 의 등장, 그리고 MCP 로의 진화에 이르기까지 점점 더 쉽고 빠르게 응용할 수 있는 방향으로 발전하고 있다고 느낍니다.이런 기술들을 잘 익히고 유용하게 활용할 수 있다면 더없이 좋겠지만, 개인적인 생각으로 이걸 꼭 사용하지 않는다고 해서 도태되거나 문제가 생긴다고는 생각하지 않습니다. 다만 글의 말미에서도 언급되듯, 내가 비록 당장 MCP 등과 같은 AI 기술들을 사용하지 않더라도 AI 가 어떤 흐름으로 발전하고 있는지, MCP 가 왜 나오고 어떤 한계를 보완했는지 등만 미리 파악하면 추후 다른 기술이 새로 나오더라도 금방 이해하고 언제든 사용해 볼 수 있지 않을까 싶습니다. 그동안 MCP 에 대해 궁금했지만 이해가 안되었던 분들 혹은 AI 의 빠른 발전속도에 혼란스러우셨던 분들에게 도움이 될거라 생각하는데요 관심있으신 분들은 한번 읽어보시면 좋겠습니다. 📚 원문<ul ><li>https://yozm.wishket.com/magazine/detail/3207/</li></ul>

요즘IT

MCP 모르면 대체 얼마나 손해 보는 걸까?🤔

언젠가부터 프론트엔드 개발자의 세계는 브라우저라는 경계를 훌쩍 넘어섰습니다. HTML, CSS, 자바스크립트만으로 충분하던 시대는 지나갔고, 이제 우리는 서버사이드 렌더링(SSR), CI/CD 파이프라인, 그리고 컨테이너와 클라우드 인프라까지 고민해야 하는 시대를 맞이했습니다. 그렇게 인프라 관련 지식은 더는 선택이 아닌 성장을 위한 필수 역량이 되었습니다. 그 시작으로 사내 인프라 개발자와 협력해 도커(Docker)부터 EKS, ArgoCD까지 구축하고 운영하는 상황을 가정하고 정리해 보았습니다. 이 글이 여러분의 시야를 브라우저 너머로 확장하며, Next.js 애플리케이션을 쿠버네티스 환경에 자신 있게 배포하는 그날을 향한 여정에서 훌륭한 첫걸음으로 쓰이기를 바랍니다.

Next.js 앱을 쿠버네티스에 배포하기 (feat. ArgoCD) | 요즘IT

요즘IT에 글을 기고했습니다.
최근 프로젝트에서 인프라 개발자와 협업하며 Next.js 앱을 EKS에 배포하는 전체 파이프라인을 구축했기 때문인데요.

👉 Dockerfile 작성부터
👉 GitHub Actions 기반 CI 설정
👉 GitOps 방식의 ArgoCD 연동
👉 ECR 이미지 관리와 배포 후 ArgoCD 대시보드 모니터링까지

단순히 배포만 하는 것이 아니라, 실무에서 마주치는 다양한 이슈들과 해결 과정, 그리고 각 도구들의 연동 방법을 상세히 정리했습니다.
특히 프론트엔드 개발자 관점에서 DevOps 영역에 첫 발을 내딛는 분들께 실질적인 도움이 되도록 작성했는데요.
쿠버네티스나 GitOps에 관심 있으신 분들께 도움이 되었으면 좋겠습니다.

https://yozm.wishket.com/magazine/detail/3235/

요즘IT에 글을 기고했습니다.최근 프로젝트에서 인프라 개발자와 협업하며 Next.js 앱을 EKS에 배포하는 전체 파이프라인을 구축했기 때문인데요. 👉 Dockerfile 작성부터👉 GitHub Actions 기반 CI 설정👉 GitOps 방식의 ArgoCD 연동👉 ECR 이미지 관리와 배포 후 ArgoCD 대시보드 모니터링까지 단순히 배포만 하는 것이 아니라, 실무에서 마주치는 다양한 이슈들과 해결 과정, 그리고 각 도구들의 연동 방법을 상세히 정리했습니다.특히 프론트엔드 개발자 관점에서 DevOps 영역에 첫 발을 내딛는 분들께 실질적인 도움이 되도록 작성했는데요.쿠버네티스나 GitOps에 관심 있으신 분들께 도움이 되었으면 좋겠습니다. https://yozm.wishket.com/magazine/detail/3235/

Next.js 앱을 쿠버네티스에 배포하기 (feat. ArgoCD

사용자가 원하는 기능을 잘 찾는지, 정성적인 경험을 수치로 측정하는 툴 TNS. 전례없는 제품을 어떻게 제작했는지, TNS 길드원들의 이야기를 들려드릴게요.

토스가 특허 낸 리서치툴, TNS (Toss Navigation Score) 제작기 

토스는 자체적인 리서치 도구를 만들어 프로덕트에 적용했습니다. TNS(Toss Navigation Score)는 사용자가 원하는 기능을 얼마나 잘 찾아가는지를 수치로 측정하는 도구인데요. 앱 로그에 TNS ID를 심어, 어떤 경로로 사용자가 제품을 이용했는지 별도로 분리해서 살펴보는 방식입니다. 실험에 참가한 사용자가 실제 프로덕트를 쓰면서 어떤 행동을 했는지 확인할 수 있다는 것이 장점입니다. 이런 도구를 리서처, 디자이너, 개발자가 발제해서 직접 만들고 라이브 프로덕트에 적용한다는 것에서 토스의 대단함을 새삼 느낍니다.

[ 큐레이터의 문장 🎒 ]

몇 가지 생각해 볼 점도 있습니다.

1️⃣ 리서치하는 목적이 사용성과 유용성을 높이기 위한 것이라면, 제품을 사용하다 상단에서 문제지가 펼쳐지는 인터랙션과 기존 토스 화면에 블러처리되는 경험이 적절한 것인가?

2️⃣ 제품을 이용하다 갑자기 퀴즈를 풀게 하는 것이, 그 퀴즈에는 사용자보다 공급자가 궁금한 점을 해소하려는 의도가 담겨있다는 점에서 거슬리지 않고 눈에 띄지 않아야 한다는 좋은 디자인의 조건을 충족하는가?

https://toss.tech/article/Toss_Navigation_Score

토스는 자체적인 리서치 도구를 만들어 프로덕트에 적용했습니다. TNS(Toss Navigation Score)는 사용자가 원하는 기능을 얼마나 잘 찾아가는지를 수치로 측정하는 도구인데요. 앱 로그에 TNS ID를 심어, 어떤 경로로 사용자가 제품을 이용했는지 별도로 분리해서 살펴보는 방식입니다. 실험에 참가한 사용자가 실제 프로덕트를 쓰면서 어떤 행동을 했는지 확인할 수 있다는 것이 장점입니다. 이런 도구를 리서처, 디자이너, 개발자가 발제해서 직접 만들고 라이브 프로덕트에 적용한다는 것에서 토스의 대단함을 새삼 느낍니다. [ 큐레이터의 문장 🎒 ] 몇 가지 생각해 볼 점도 있습니다. 1️⃣ 리서치하는 목적이 사용성과 유용성을 높이기 위한 것이라면, 제품을 사용하다 상단에서 문제지가 펼쳐지는 인터랙션과 기존 토스 화면에 블러처리되는 경험이 적절한 것인가? 2️⃣ 제품을 이용하다 갑자기 퀴즈를 풀게 하는 것이, 그 퀴즈에는 사용자보다 공급자가 궁금한 점을 해소하려는 의도가 담겨있다는 점에서 거슬리지 않고 눈에 띄지 않아야 한다는 좋은 디자인의 조건을 충족하는가? https://toss.tech/article/Toss_Navigation_Score

toss.tech

⟪토스가 만든 리서치툴, TNS⟫

‪요 기능의 일부를 바이브 코딩으로 만들려다가 실패했는데요. 그 중에 하나로 타임존 문제가 있었습니다.‬

‪타임존 문제는 꽤나 보편적인(?) 문제라 잘 할 줄 알았는데 의외로(?) 헛점이 많더라고요. 초반엔 AI들이 아예 타임존 문제를 고려하지도 않았고요.‬

‪그래서 타임존 문제가 있을 수 있다는 것과, 이에따른 몇가지 고려사항을 상세하게 주고 또 결과를 꼼꼼히 검토해야했는데요. 시니어 개발자가 주니어 개발자보다 유리한 부분이 이런 엣지 케이스에 대한 경험적인 부분인 것 같습니다.‬

‪하지만 반면에 이런 사소한(?) 요소들 때문에 개발이 오래 걸리는데, 보통 당장은 필요 없는 것일 가능성이 높으니, 주니어가 이런 것 고려하지 않고 빠르고 단순하게 만드는게 더 큰 장점이 될 수도 있습니다. 특히 이런건 나중에 정말 많은 사람들이 쓰기 시작할 때 개선하는게 더 의도에 맞게 만들 수도 있으니까요.‬

‪그래서 저는 AI 개발 시대에 시니어만 유리하다는 말이 맞지는 않다고 생각합니다. 오히려 내년이 되면 주니어에 비해 경쟁력이 없어질까 불안할 정도에요.‬

‪요 기능의 일부를 바이브 코딩으로 만들려다가 실패했는데요. 그 중에 하나로 타임존 문제가 있었습니다.‬ ‪타임존 문제는 꽤나 보편적인(?) 문제라 잘 할 줄 알았는데 의외로(?) 헛점이 많더라고요. 초반엔 AI들이 아예 타임존 문제를 고려하지도 않았고요.‬ ‪그래서 타임존 문제가 있을 수 있다는 것과, 이에따른 몇가지 고려사항을 상세하게 주고 또 결과를 꼼꼼히 검토해야했는데요. 시니어 개발자가 주니어 개발자보다 유리한 부분이 이런 엣지 케이스에 대한 경험적인 부분인 것 같습니다.‬ ‪하지만 반면에 이런 사소한(?) 요소들 때문에 개발이 오래 걸리는데, 보통 당장은 필요 없는 것일 가능성이 높으니, 주니어가 이런 것 고려하지 않고 빠르고 단순하게 만드는게 더 큰 장점이 될 수도 있습니다. 특히 이런건 나중에 정말 많은 사람들이 쓰기 시작할 때 개선하는게 더 의도에 맞게 만들 수도 있으니까요.‬ ‪그래서 저는 AI 개발 시대에 시니어만 유리하다는 말이 맞지는 않다고 생각합니다. 오히려 내년이 되면 주니어에 비해 경쟁력이 없어질까 불안할 정도에요.‬

‪요 기능의 일부를 바이브 코딩으로 만들려다가 실패했는데요. 그 

이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.퀄리티 있는 프로덕트, 창업가, 비즈니...

월 8천만원을 벌던 개발자가 바이브코딩 도구를 만드는 이유

국내 바이브코딩 시장을 혼자 독점하고 계신 커서맛피아님을 인터뷰했어요.

제 기준, 국내 바이브코딩 1인자입니다. 교육분야라기보다는, 찐으로 만드는 메이커 중 1인자라고 해도 손색이 없다고 봐요.

만드시는 제품이 디테일도 살아있더라고요.

특히 비개발자가, 완성된 제품을 만드는 데 가장 필요한 내용과 팁을 다 들을 수 있어 좋았어요.
깊은 내용을 담았으니, 유심히 봐주세요. :)

https://eopla.net/magazines/32117

국내 바이브코딩 시장을 혼자 독점하고 계신 커서맛피아님을 인터뷰했어요. 제 기준, 국내 바이브코딩 1인자입니다. 교육분야라기보다는, 찐으로 만드는 메이커 중 1인자라고 해도 손색이 없다고 봐요. 만드시는 제품이 디테일도 살아있더라고요. 특히 비개발자가, 완성된 제품을 만드는 데 가장 필요한 내용과 팁을 다 들을 수 있어 좋았어요.깊은 내용을 담았으니, 유심히 봐주세요. :) https://eopla.net/magazines/32117

무자본으로 연 100억을 넘게 버는 연쇄 창업가의 시스템 설계 방법

국내 바이브코딩 시장을 혼자 독점하고 계신 커서맛피아님을 인터뷰했

As you settle into your work routine each morning, you might feel some inherent optimism. "Today will be different," you tell yourself. "This is the ...

Embracing Productivity Grace: Overcoming Shame for a Positive Work Mindset - RescueTime Blog

혹시 여러분도 가만히 누워 쉬거나 유튜브를 볼 때에 '아 이러면 안되는데...'하는 죄책감에 시달리시나요? 저 또한 생산적인 일을 하고 있지 않을 때 불안함과 죄책감을 느껴서 스트레스를 받는 편인데요. 😭 마침 이를 '생산성 수치심'으로 칭하는 글을 발견하여 공유합니다.

이 글은 생산성 수치심의 원인과 극복하는 법까지 구체적으로 다루고 있는데요. 글이 길어 2편으로 나눠서 공유드리려고 해요. 저와 비슷한 죄책감을 느낀 적 있는 분이라면 일독을 권합니다!

https://blog.rescuetime.com/embracing-productivity-grace-overcoming-shame-for-a-positive-work-mindset/

----------------------------------------

<생산성 수치심이란?>

▪️ 첫째, 생산성 수치심은 일에 투자한 시간이나 To-do 리스트에서 지워낸 업무의 수와 상관없이, 충분히 달성하지 못했다는 끊임없는 감정으로 나타납니다. 우리 모두가 자부심을 가지고 있는 그 끊임없는 탁월함의 추구는 양날의 칼이 됩니다.

▪️ 생산성 수치심의 두 번째 측면은 특정 활동이 완전히 "비생산적"이라는 생각에 뿌리를 두고 있으며, 그 활동은 강한 죄책감을 가져다 줍니다. 취미나 영화 감상 같은 여가 활동을 하거나, 단순히 잠시 휴식을 취하는 것은 내적 갈등을 일으킵니다. 항상 더 생산적인 일에 종사해야 한다는 이러한 지속적인 믿음은 여러분이 쉬려고 노력할 때마다 깊은 수치심을 유발합니다.

▪️ 자신의 업적을 진심으로 축하할 수 없다는 것과, 스스로를 유예상태로 두지 않고 일에 묶여 있어야 한다는 끊임없는 압박은 스트레스, 과로, 그리고 필연적으로 번아웃의 위험한 지형의 토대가 됩니다.

<생산성 수치심의 원인>

▪️ 원인 #1: 자신의 가치를 성과와 연관짓는 것
자아 가치가 생산성에 묶여 있을 때, 그 결과는 끊임없는 수치심과 함께 일상적인 투쟁이 됩니다. 노력과 상관없이, 끊임없이 부족한 느낌은 반복되어 어떤 성취감에도 그림자를 드리웁니다.

▪️ 원인 #2: 비현실적인 목표 설정
목표는 적절하게 조정될 때 강력한 동기부여 역할을 하지만, 야망이 현실을 능가할 때는 부정적으로 작용합니다. 특히 지나치게 야심이 많은 경우, 프로세스의 중요성을 무시하고 오직 최종 결과에만 관심을 두기 쉽습니다. 또한 수많은 거창한 목표를 야심차게 추구하는 것은 성취와 그에 따른 목표 설정의 주기를 영구화하여 성취와 수치심의 지속적인 순환을 만듭니다.

▪️ 원인 #3: 비교의 함정
다른 사람들은 무한한 생산성을 가지고 있는 것처럼 보이는 사례에 끊임없이 노출되면, 모두가 우리 자신의 노력을 능가하고 있다는 잘못된 믿음을 배양합니다.

혹시 여러분도 가만히 누워 쉬거나 유튜브를 볼 때에 '아 이러면 안되는데...'하는 죄책감에 시달리시나요? 저 또한 생산적인 일을 하고 있지 않을 때 불안함과 죄책감을 느껴서 스트레스를 받는 편인데요. 😭 마침 이를 '생산성 수치심'으로 칭하는 글을 발견하여 공유합니다. 이 글은 생산성 수치심의 원인과 극복하는 법까지 구체적으로 다루고 있는데요. 글이 길어 2편으로 나눠서 공유드리려고 해요. 저와 비슷한 죄책감을 느낀 적 있는 분이라면 일독을 권합니다! https://blog.rescuetime.com/embracing-productivity-grace-overcoming-shame-for-a-positive-work-mindset/ ---------------------------------------- &lt;생산성 수치심이란?&gt; ▪️ 첫째, 생산성 수치심은 일에 투자한 시간이나 To-do 리스트에서 지워낸 업무의 수와 상관없이, 충분히 달성하지 못했다는 끊임없는 감정으로 나타납니다. 우리 모두가 자부심을 가지고 있는 그 끊임없는 탁월함의 추구는 양날의 칼이 됩니다. ▪️ 생산성 수치심의 두 번째 측면은 특정 활동이 완전히 "비생산적"이라는 생각에 뿌리를 두고 있으며, 그 활동은 강한 죄책감을 가져다 줍니다. 취미나 영화 감상 같은 여가 활동을 하거나, 단순히 잠시 휴식을 취하는 것은 내적 갈등을 일으킵니다. 항상 더 생산적인 일에 종사해야 한다는 이러한 지속적인 믿음은 여러분이 쉬려고 노력할 때마다 깊은 수치심을 유발합니다. ▪️ 자신의 업적을 진심으로 축하할 수 없다는 것과, 스스로를 유예상태로 두지 않고 일에 묶여 있어야 한다는 끊임없는 압박은 스트레스, 과로, 그리고 필연적으로 번아웃의 위험한 지형의 토대가 됩니다. &lt;생산성 수치심의 원인&gt; ▪️ 원인 #1: 자신의 가치를 성과와 연관짓는 것자아 가치가 생산성에 묶여 있을 때, 그 결과는 끊임없는 수치심과 함께 일상적인 투쟁이 됩니다. 노력과 상관없이, 끊임없이 부족한 느낌은 반복되어 어떤 성취감에도 그림자를 드리웁니다. ▪️ 원인 #2: 비현실적인 목표 설정목표는 적절하게 조정될 때 강력한 동기부여 역할을 하지만, 야망이 현실을 능가할 때는 부정적으로 작용합니다. 특히 지나치게 야심이 많은 경우, 프로세스의 중요성을 무시하고 오직 최종 결과에만 관심을 두기 쉽습니다. 또한 수많은 거창한 목표를 야심차게 추구하는 것은 성취와 그에 따른 목표 설정의 주기를 영구화하여 성취와 수치심의 지속적인 순환을 만듭니다. ▪️ 원인 #3: 비교의 함정다른 사람들은 무한한 생산성을 가지고 있는 것처럼 보이는 사례에 끊임없이 노출되면, 모두가 우리 자신의 노력을 능가하고 있다는 잘못된 믿음을 배양합니다.

RescueTime Blog

생산성 수치심 (Productivity Shame) 극복하기 (1

The Installation Guide mentioned Xcode, however we created project with Tuist. Therefore I appended to packages. This will install 1.9.2 and upgrade if there is any fix. The installed package name is...

Setting up TCA for your existing project with Tuist

지난 글에서 Tuist가 준비되었습니다. 다음은 TCA 입니다. TCA 역시 유명한 도구죠.
만약 React나 React-Native에서 Redux를 사용하셨다면 개념을 이해하기 쉬울 것입니다.

왜냐면 TCA도 Reducer를 갖고 있기 때문이죠!

#swift #tca #macro #reducer #tuist

https://toyboy2.medium.com/setting-up-tca-for-your-existing-project-with-tuist-7d3443dde540

지난 글에서 Tuist가 준비되었습니다. 다음은 TCA 입니다. TCA 역시 유명한 도구죠.만약 React나 React-Native에서 Redux를 사용하셨다면 개념을 이해하기 쉬울 것입니다. 왜냐면 TCA도 Reducer를 갖고 있기 때문이죠! #swift #tca #macro #reducer #tuist https://toyboy2.medium.com/setting-up-tca-for-your-existing-project-with-tuist-7d3443dde540

Coupang Sr. iOS Engineer

조찬우

불확실성에 도전하는 개발과 삶을 지향합니다🏃🏻

부경대학교 컴퓨터공학과

RAFA

기존 프로젝트에 Tuist로 TCA 설치하기

이영준

KT 협력사 SI 그만 두고 집에서 혼자 개인 iOS 일년 동안 출시했고 시원스쿨의 iOS를 밑바닥 부터 개발 킥고잉에서 Mobile Tech Lead를 했다. 현재 프리랜서 SKT 대리점 관리/고객센터 iOS 앱 운영

#앱개발자 #iOS개발자 #SwiftUI

기존 프로젝트에 Tuist로 TCA 설치하기

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필