‎나만의 대한민국 여행 지도를 만들어보세요!

내가 가본 우리나라는 여러분이 방문한 한국의 모든 지역을 색칠하는 여행 기록 앱이에요.
제가 쓰려고 만들었어요. 죽기 전에 다 색칠하는 게 제 소원이에요. 광고나 결제 따윈 없으니 안심하고 사용하세요.

* 지역별 색칠 기능
- 방문한 시/군/구를 터치 한 번으로 색칠
- 직관적인 터치 인터페이스

* 여행 통계 한눈에
- 전국 방문율 실시간 확인
- 지역별 방문 현황 통계

* 도전 과제, 성취감
- 전국 완주 도전
- 지역별 컬렉션 완성
- 특별한 여행 기록 달성

* 간편한 사용
-…

‎색칠 지도 - 내가 가본 우리나라

내가 가본 우리나라.
웹서비스에 이어... 아이폰 앱과 안드로이드 앱까지 모두 출시했습니다.

여행 중에 짬짬히 작업해서 웹, 안드로이드, 아이폰까지 출시하다니...
AI 코딩 시대가 좋긴 좋습니다.


기술 스택은 Ruby on Rails + Flutter 로 만들었습니다.
Rails 의 기본 기능을 활용해 거의 90% 를 만들었고, Flutter 로 감싸는 부분이 나머지 10% 정도 인 것 같네요.


AI 때문에 좋아진 것도 맞지만, 웹/앱 만드는 기술들이 예전보다 훨씬 좋아져서 이렇게 혼자서도 웹과 앱을 뚝딱 낼 수 있는 세상이 된 것 같아요.

광고도 없고, 완전히 무료로 사용할 수 있게 만들었어요.
국내 여행 좋아하시는 분들이라면 아마 좋아하실 겁니다.


https://apps.apple.com/kr/app/%EC%83%89%EC%B9%A0-%EC%A7%80%EB%8F%84-%EB%82%B4%EA%B0%80-%EA%B0%80%EB%B3%B8-%EC%9A%B0%EB%A6%AC%EB%82%98%EB%9D%BC/id6749817480

내가 가본 우리나라.웹서비스에 이어... 아이폰 앱과 안드로이드 앱까지 모두 출시했습니다. 여행 중에 짬짬히 작업해서 웹, 안드로이드, 아이폰까지 출시하다니... AI 코딩 시대가 좋긴 좋습니다. 기술 스택은 Ruby on Rails + Flutter 로 만들었습니다.Rails 의 기본 기능을 활용해 거의 90% 를 만들었고, Flutter 로 감싸는 부분이 나머지 10% 정도 인 것 같네요. AI 때문에 좋아진 것도 맞지만, 웹/앱 만드는 기술들이 예전보다 훨씬 좋아져서 이렇게 혼자서도 웹과 앱을 뚝딱 낼 수 있는 세상이 된 것 같아요. 광고도 없고, 완전히 무료로 사용할 수 있게 만들었어요. 국내 여행 좋아하시는 분들이라면 아마 좋아하실 겁니다. https://apps.apple.com/kr/app/%EC%83%89%EC%B9%A0-%EC%A7%80%EB%8F%84-%EB%82%B4%EA%B0%80-%EA%B0%80%EB%B3%B8-%EC%9A%B0%EB%A6%AC%EB%82%98%EB%9D%BC/id6749817480

App Store

내가 가본 우리나라

며칠 전 공개했던 내가 가본 우리나라 웹사이트를 앱으로도 만들어봤습니다. 안드로이드, 아이폰 그리고 맥 앱까지. (맥은 아직 심사 중이에요)

내가 가본 우리나라 앱 개발 뒷 이야기

며칠 전 공개했던 내가 가본 우리나라 웹사이트를 앱으로도 만들어봤습니다.
안드로이드, 아이폰 그리고 맥 앱까지. (맥은 아직 심사 중이에요)

간단한 아이디어였고 제가 쓰고 싶은 마음에 만들기도 했지만,
레일즈 8을 좀 더 알아보고자 하는 마음.
제 기술 스택을 정돈해 보고 싶은 마음이 있었어요.

루비 온 레일즈, Vue.js, React
플러터, React Native, Universal Windows Platform

계속 이렇게 공부만 하면서 왔다 갔다 해야 하나?
좀 잘 정리해서 내 주력 스택을 확정시킬 순 없을까?

루비 온 레일즈 8의 기본 기능을 최대한 활용해 보고 싶었습니다.

* Hotwire, Stimulus, Turbo, importmap을 통한 외부 종속성 없는 자바스크립트 환경.
* Kamal 을 통한 배포.
* Solid Queue를 통한 백그라운드 작업.
* Solid Cache 캐싱.
* sqlite와 홈서버로 프로덕션 환경 운영해 보기.
* Hotwire Native를 통한 모바일 앱 개발까지.

웹사이트를 다 만들고 나서 아주 홀가분했습니다. Hotwire에 대해 거의 아는 게 없었지만 AI 덕분에 수월했어요.
React 같은 걸 쓸 필요가 있나? 하는 생각을 많이 했습니다. Webpack이나 Vite 같은 피곤한 도구들 안 봐도 되는 것도 정말 좋았고요.

모바일 앱을 만들기 위해 Hotwire Native와 이틀 정도 씨름하다가…
이건 도저히 안 되겠다. 더러워서 못 해먹겠다 하고 포기했습니다.

결국 플러터를 선택해서 안드로이드, 아이폰, 맥 앱을 만들었습니다.
총 코드는 90% 정도가 레일즈이고 10% 정도가 플러터.

클로드 코드로만 작업했고, 제가 직접 코드에 관여한 부분은 없었던 것 같아요.
클로드 코드를 사용할 때는 여러 작업을 병렬로 안 하고 최대한 순차적으로 진행하려고 노력했습니다.
다른 프로젝트도 신경 쓰지 않고요. 안 그러면 제 머리가 따라갈 수 없어서.
여담이지만 저는 클로드 코드에 mcp도 하나도 연결하지 않았고, 남들이 만든 agents.md 같은 것들도 잘 보지 않습니다. 노땅이 다 된 것 같아요.

규모가 작은 앱이긴 하지만, 이번 작업으로 이 스택에 자신감이 생겼습니다.
앞으로도 새로운 서비스 만들 땐 이렇게 만들지 않을까 싶습니다. 😁


https://jeho.page/essay/2025/08/27/my-korea-map.html

며칠 전 공개했던 내가 가본 우리나라 웹사이트를 앱으로도 만들어봤습니다. 안드로이드, 아이폰 그리고 맥 앱까지. (맥은 아직 심사 중이에요) 간단한 아이디어였고 제가 쓰고 싶은 마음에 만들기도 했지만, 레일즈 8을 좀 더 알아보고자 하는 마음. 제 기술 스택을 정돈해 보고 싶은 마음이 있었어요. 루비 온 레일즈, Vue.js, React 플러터, React Native, Universal Windows Platform 계속 이렇게 공부만 하면서 왔다 갔다 해야 하나? 좀 잘 정리해서 내 주력 스택을 확정시킬 순 없을까? 루비 온 레일즈 8의 기본 기능을 최대한 활용해 보고 싶었습니다. * Hotwire, Stimulus, Turbo, importmap을 통한 외부 종속성 없는 자바스크립트 환경. * Kamal 을 통한 배포. * Solid Queue를 통한 백그라운드 작업. * Solid Cache 캐싱. * sqlite와 홈서버로 프로덕션 환경 운영해 보기. * Hotwire Native를 통한 모바일 앱 개발까지. 웹사이트를 다 만들고 나서 아주 홀가분했습니다. Hotwire에 대해 거의 아는 게 없었지만 AI 덕분에 수월했어요. React 같은 걸 쓸 필요가 있나? 하는 생각을 많이 했습니다. Webpack이나 Vite 같은 피곤한 도구들 안 봐도 되는 것도 정말 좋았고요. 모바일 앱을 만들기 위해 Hotwire Native와 이틀 정도 씨름하다가… 이건 도저히 안 되겠다. 더러워서 못 해먹겠다 하고 포기했습니다. 결국 플러터를 선택해서 안드로이드, 아이폰, 맥 앱을 만들었습니다. 총 코드는 90% 정도가 레일즈이고 10% 정도가 플러터. 클로드 코드로만 작업했고, 제가 직접 코드에 관여한 부분은 없었던 것 같아요. 클로드 코드를 사용할 때는 여러 작업을 병렬로 안 하고 최대한 순차적으로 진행하려고 노력했습니다. 다른 프로젝트도 신경 쓰지 않고요. 안 그러면 제 머리가 따라갈 수 없어서. 여담이지만 저는 클로드 코드에 mcp도 하나도 연결하지 않았고, 남들이 만든 agents.md 같은 것들도 잘 보지 않습니다. 노땅이 다 된 것 같아요. 규모가 작은 앱이긴 하지만, 이번 작업으로 이 스택에 자신감이 생겼습니다. 앞으로도 새로운 서비스 만들 땐 이렇게 만들지 않을까 싶습니다. 😁 https://jeho.page/essay/2025/08/27/my-korea-map.html

K리그 프로그래머

국내 최대 프론트엔드 개발 컨퍼런스, FECONF 2025가 8월 23일 오프라인으로 찾아옵니다.

FEConf 2025

오늘 FEConf 2025( https://2025.feconf.kr/ )에 다녀왔다. 오랜만에 느껴보는 콘퍼런스의 활기찬 공기가 좋았다. 전반부에는 흥미로운 세션들을 찾아다니고, 후반부에는 여러 참가자와 이야기를 나누며 업계의 생생한 이야기를 들을 수 있었다.

들었던 세션 중에서도 유독 리액트 컴파일러에 대한 이야기가 기억에 남는다. 처음 접하는 주제였지만, 연사께서 얼마나 깊이 고민하고 준비했는지가 느껴져서인지 푹 빠져서 들을 수 있었다.

리액트의 기본 동작 모델은 상태(state)가 변하면 해당 컴포넌트와 그 자식들까지 전부 다시 렌더링하는 것이다. 이 모델은 UI를 상태의 함수로 보는 선언적 프로그래밍을 가능하게 했지만, 때로는 불필요한 리렌더링을 일으켜 성능 문제를 낳기도 했다.

이를 해결하기 위해 리액트는 useMemo나 useCallback 같은 API를 이용한 메모이제이션 기법을 제공한다. 하지만 솔직히 말해 이 작업은 꽤나 지루하고, 실수하기 쉬우며, 관리해야 할 코드만 늘리는 귀찮은 일이기도 했다. 리액트 컴파일러는 바로 이 귀찮은 메모이제이션을 자동화하여, 개발자가 더 단순한 코드를 작성하면서도 뛰어난 성능을 얻을 수 있도록 돕는 도구라고 이해했다.

처음에는 (타입스크립트/자바스크립트)/JSX 코드를 최적화된 자바스크립트 코드로 바꾸는 것이니 트랜스파일러를 왜 컴파일러라고 이름을 붙인거지라는 의문이 들었다. 하지만 독자적인 중간 표현(HIR)을 통해 코드의 의미를 깊이 분석하고 최적화하는 과정을 듣고 나니, 컴파일러라고 부를만 하다는 생각도 들었다. 사실 이 도구를 뭐라고 부르든 본질은 변하지 않는다. 덕분에 리액트 사용자들은 성능 최적화라는 공짜 점심을 먹을 수 있게 되었다는 점이다.

세션 종료 후 다음은 목적지를 찾아보려고, 세션 목록을 둘러보니 의외로 리액트에 대한 세션이 많지 않다는 점을 알았다. 국내 최대 프론트엔드 콘퍼런스이고, 리액트가 사실상 업계 표준처럼 쓰이는 것과 리액트 19가 24년 연말에 출시된 것을 고려하면 조금 의외였다. 하지만 이내 고개를 끄덕였다. FEConf는 리액트 콘퍼런스가 아니니, 오히려 다양한 주제가 다뤄지는 것이 더 건강하고 올바른 방향이라는 생각이 들었다.

올해로 벌써 세 번째 참여하는 FEConf였다. 이번에도 많은 것을 배우고, 즐겁게 네트워킹하며 좋은 기운을 얻어 간다. 매년 이런 멋진 행사를 준비하고 운영하는 모든 분에게 진심으로 감사와 응원의 마음을 전한다.

오늘 FEConf 2025( https://2025.feconf.kr/ )에 다녀왔다. 오랜만에 느껴보는 콘퍼런스의 활기찬 공기가 좋았다. 전반부에는 흥미로운 세션들을 찾아다니고, 후반부에는 여러 참가자와 이야기를 나누며 업계의 생생한 이야기를 들을 수 있었다. 들었던 세션 중에서도 유독 리액트 컴파일러에 대한 이야기가 기억에 남는다. 처음 접하는 주제였지만, 연사께서 얼마나 깊이 고민하고 준비했는지가 느껴져서인지 푹 빠져서 들을 수 있었다. 리액트의 기본 동작 모델은 상태(state)가 변하면 해당 컴포넌트와 그 자식들까지 전부 다시 렌더링하는 것이다. 이 모델은 UI를 상태의 함수로 보는 선언적 프로그래밍을 가능하게 했지만, 때로는 불필요한 리렌더링을 일으켜 성능 문제를 낳기도 했다. 이를 해결하기 위해 리액트는 useMemo나 useCallback 같은 API를 이용한 메모이제이션 기법을 제공한다. 하지만 솔직히 말해 이 작업은 꽤나 지루하고, 실수하기 쉬우며, 관리해야 할 코드만 늘리는 귀찮은 일이기도 했다. 리액트 컴파일러는 바로 이 귀찮은 메모이제이션을 자동화하여, 개발자가 더 단순한 코드를 작성하면서도 뛰어난 성능을 얻을 수 있도록 돕는 도구라고 이해했다. 처음에는 (타입스크립트/자바스크립트)/JSX 코드를 최적화된 자바스크립트 코드로 바꾸는 것이니 트랜스파일러를 왜 컴파일러라고 이름을 붙인거지라는 의문이 들었다. 하지만 독자적인 중간 표현(HIR)을 통해 코드의 의미를 깊이 분석하고 최적화하는 과정을 듣고 나니, 컴파일러라고 부를만 하다는 생각도 들었다. 사실 이 도구를 뭐라고 부르든 본질은 변하지 않는다. 덕분에 리액트 사용자들은 성능 최적화라는 공짜 점심을 먹을 수 있게 되었다는 점이다. 세션 종료 후 다음은 목적지를 찾아보려고, 세션 목록을 둘러보니 의외로 리액트에 대한 세션이 많지 않다는 점을 알았다. 국내 최대 프론트엔드 콘퍼런스이고, 리액트가 사실상 업계 표준처럼 쓰이는 것과 리액트 19가 24년 연말에 출시된 것을 고려하면 조금 의외였다. 하지만 이내 고개를 끄덕였다. FEConf는 리액트 콘퍼런스가 아니니, 오히려 다양한 주제가 다뤄지는 것이 더 건강하고 올바른 방향이라는 생각이 들었다. 올해로 벌써 세 번째 참여하는 FEConf였다. 이번에도 많은 것을 배우고, 즐겁게 네트워킹하며 좋은 기운을 얻어 간다. 매년 이런 멋진 행사를 준비하고 운영하는 모든 분에게 진심으로 감사와 응원의 마음을 전한다.

2025.feconf.kr

FEConf 2025를 다녀오다

요 며칠 GPT-5 Reasoning - High 를 사용해서 진지한 개발을 몇가지 해보고 있는데 진짜 레벨이 다르네요.

Claude가 잘한다고 생각하는 분들이 많은데, 뭐랄까, 좀 단순한 일을 Claude가 잘해서 그런 착시가 있는 것 같아요. GPT-5가 어려운 걸 진짜 잘합니다.

조금 전에 Codex랑 같이 심심풀이로 서버 코드 최적화를 진행했는데요. 생각지 못했던 방법으로 높은 수준의 최적화를 달성했습니다.

스타트업 시간 약 2.9배 속도 향상, 메모리 약 46.6% 절감이라는 엄청난 결과를..😳

저는 진짜 코드 한 줄을 안썼어요. 물론 휴먼 코드 리뷰를 한 번 하고 코드 정리는 해야겠지만, 직접 했으면 최소 며칠은 걸렸을 일..이 아니라 다른 일을 하느라 최적화는 생각도 못했을겁니다.

어느정도 최적화를 해두기도 했었고, 뭔가 더 최적화 할 수 있는 여지가 있을 것 같았지만, 기존에도 나쁘지는 않아서 그냥 냅두고 있었던거였거든요.

게다가 시간을 좀 써서 총 1,300만개 정도의 토큰을 썼는데, 비용이 약 $3.24 밖에 안합니다. 이정도 개선에 든 비용이 겨우 5천원..?! 😳

내년 정도가 되면 이런 최적화는 그냥 무한 루프로 돌려두면 알아서 계속 최적화하고 계선하겠죠? 비용도 거의 무료에 가까울테고요.

개발을 잘 한다는 것이 무엇인지를 개인과 회사 차원에서 진지하게 다시 고민해봐야 할 것 같습니다.

요 며칠 GPT-5 Reasoning - High 를 사용해서 진지한 개발을 몇가지 해보고 있는데 진짜 레벨이 다르네요. Claude가 잘한다고 생각하는 분들이 많은데, 뭐랄까, 좀 단순한 일을 Claude가 잘해서 그런 착시가 있는 것 같아요. GPT-5가 어려운 걸 진짜 잘합니다. 조금 전에 Codex랑 같이 심심풀이로 서버 코드 최적화를 진행했는데요. 생각지 못했던 방법으로 높은 수준의 최적화를 달성했습니다. 스타트업 시간 약 2.9배 속도 향상, 메모리 약 46.6% 절감이라는 엄청난 결과를..😳 저는 진짜 코드 한 줄을 안썼어요. 물론 휴먼 코드 리뷰를 한 번 하고 코드 정리는 해야겠지만, 직접 했으면 최소 며칠은 걸렸을 일..이 아니라 다른 일을 하느라 최적화는 생각도 못했을겁니다. 어느정도 최적화를 해두기도 했었고, 뭔가 더 최적화 할 수 있는 여지가 있을 것 같았지만, 기존에도 나쁘지는 않아서 그냥 냅두고 있었던거였거든요. 게다가 시간을 좀 써서 총 1,300만개 정도의 토큰을 썼는데, 비용이 약 $3.24 밖에 안합니다. 이정도 개선에 든 비용이 겨우 5천원..?! 😳 내년 정도가 되면 이런 최적화는 그냥 무한 루프로 돌려두면 알아서 계속 최적화하고 계선하겠죠? 비용도 거의 무료에 가까울테고요. 개발을 잘 한다는 것이 무엇인지를 개인과 회사 차원에서 진지하게 다시 고민해봐야 할 것 같습니다.

요즘 직업과 돈에 대해 깊이 생각하게 됩니다. 회사를 떠나 홀로서기를 했을 때 과연 생계를 유지할 수 있을지 고민되기 때문입니다. 안타까운 것은 아무리 고민해도 명확한 답이 나오지 않는다는 점입니다. 시뮬레이션은 가정에 불과하고, 현실과 미래는 예측할 수 없으니까요. 저와 같은 생각을 하는 많은 분들이 비슷한 딜레마에 빠져 있을 것입니다. 나가야 할까, 머물러야 할까. 마치 죽느냐 사느냐의 기로에 선 것 같습니다.


생계는 곧 생명입니다. 특히 가정이 있는 사람들에게 생계는 가족의 생명과 직결됩니다. 그래서 자연스럽게 더 많은 돈을 벌 수 있는 직업을 떠올리게 됩니다. 돈을 벌 수 없는 일은 선택하기 어렵죠. 최소한 먹고살 만큼은 벌어야 직업으로서 의미가 있으니까요.
결국 행복하지 않더라도 돈을 벌기 위해 일을 선택해야 합니다. 행복해지려고 사는데, 이보다 큰 아이러니가 또 있을까요?


어쩌면 우리에게 필요한 것은 확신이라는 생각이 듭니다. 알 수 없는 미래를 향한 확신만 있다면 무엇이든 과감하게 도전할 수 있을 테니까요.
 * 먹고살 만큼 돈을 벌 수 있다면
 * 진짜 행복한 나날을 보낼 수 있다면
 * 일을 통해 세상에 선한 영향력을 줄 수 있다면
이런 확신이 있다면 과감히 도전할 수 있을 것입니다. 하지만 믿음이 어렵습니다. 자신에 대한 확신과 미래에 대한 믿음을 갖기가 쉽지 않습니다.


그래서 현재를 기준으로 열심히 계산해봅니다. 이렇게 하면 얼마, 저렇게 하면 어떤 결과가 나올지, 지금 가진 것을 포기하면 얼마나 힘들어질지 따져봅니다. 당연히 해야 하는 생각이고, 충분히 고려해야 할 부분입니다.
하지만 그런 계산으로는 결국 선택할 수 없다는 것도 알고 있습니다. 미래는 계산으로 도전하는 것이 아니라, 해보지 않은 일에 더 열심히 부딪혀 돌파해 나가는 것임을 잘 알고 있으니까요.


어쩌면 지금보다 더 열심히 살 자신이 없는 것일 수도 있습니다. 어쩌면 지금보다 더 힘든 도전이 두려워 망설이는 것일 수도 있고요. 힘든 것은 싫으니까, 지금처럼 고정적으로 수입이 나오고 매일 출근할 곳이 있다는 안도감에 머무르고 싶은 것이겠죠.
언제 그만둬도 이상하지 않을, 내가 아니어도 충분히 잘 돌아갈 그런 곳에서 편안히 머물고 싶은 마음일 수도 있습니다.


무엇이 내 삶에 확신이 되는지 자신에게 물어봅시다. 그리고 과연 나는 행복하기 위해 어떤 노력을 하고 있는지 확인해봅시다. 행복하려고 노력하지 않고 있다면, 어떤 방해 요소가 있는지 찾아봅시다. 그리고 오늘 그 장애물을 빠르게 치워봅시다.
돈과 명예는 진정한 확신의 근거가 될 수 없습니다. 오직 행복하기 위한 조건만이 진정한 확신의 바탕이 될 수 있다는 것을 깨닫는 우리가 되길 진심으로 응원합니다.

﻿요즘 직업과 돈에 대해 깊이 생각하게 됩니다. 회사를 떠나 홀로서기를 했을 때 과연 생계를 유지할 수 있을지 고민되기 때문입니다. 안타까운 것은 아무리 고민해도 명확한 답이 나오지 않는다는 점입니다. 시뮬레이션은 가정에 불과하고, 현실과 미래는 예측할 수 없으니까요. 저와 같은 생각을 하는 많은 분들이 비슷한 딜레마에 빠져 있을 것입니다. 나가야 할까, 머물러야 할까. 마치 죽느냐 사느냐의 기로에 선 것 같습니다. 생계는 곧 생명입니다. 특히 가정이 있는 사람들에게 생계는 가족의 생명과 직결됩니다. 그래서 자연스럽게 더 많은 돈을 벌 수 있는 직업을 떠올리게 됩니다. 돈을 벌 수 없는 일은 선택하기 어렵죠. 최소한 먹고살 만큼은 벌어야 직업으로서 의미가 있으니까요.결국 행복하지 않더라도 돈을 벌기 위해 일을 선택해야 합니다. 행복해지려고 사는데, 이보다 큰 아이러니가 또 있을까요? 어쩌면 우리에게 필요한 것은 확신이라는 생각이 듭니다. 알 수 없는 미래를 향한 확신만 있다면 무엇이든 과감하게 도전할 수 있을 테니까요.<ul ><li>먹고살 만큼 돈을 벌 수 있다면</li><li>진짜 행복한 나날을 보낼 수 있다면</li><li>일을 통해 세상에 선한 영향력을 줄 수 있다면</li></ul>이런 확신이 있다면 과감히 도전할 수 있을 것입니다. 하지만 믿음이 어렵습니다. 자신에 대한 확신과 미래에 대한 믿음을 갖기가 쉽지 않습니다. 그래서 현재를 기준으로 열심히 계산해봅니다. 이렇게 하면 얼마, 저렇게 하면 어떤 결과가 나올지, 지금 가진 것을 포기하면 얼마나 힘들어질지 따져봅니다. 당연히 해야 하는 생각이고, 충분히 고려해야 할 부분입니다.하지만 그런 계산으로는 결국 선택할 수 없다는 것도 알고 있습니다. 미래는 계산으로 도전하는 것이 아니라, 해보지 않은 일에 더 열심히 부딪혀 돌파해 나가는 것임을 잘 알고 있으니까요. 어쩌면 지금보다 더 열심히 살 자신이 없는 것일 수도 있습니다. 어쩌면 지금보다 더 힘든 도전이 두려워 망설이는 것일 수도 있고요. 힘든 것은 싫으니까, 지금처럼 고정적으로 수입이 나오고 매일 출근할 곳이 있다는 안도감에 머무르고 싶은 것이겠죠.언제 그만둬도 이상하지 않을, 내가 아니어도 충분히 잘 돌아갈 그런 곳에서 편안히 머물고 싶은 마음일 수도 있습니다. 무엇이 내 삶에 확신이 되는지 자신에게 물어봅시다. 그리고 과연 나는 행복하기 위해 어떤 노력을 하고 있는지 확인해봅시다. 행복하려고 노력하지 않고 있다면, 어떤 방해 요소가 있는지 찾아봅시다. 그리고 오늘 그 장애물을 빠르게 치워봅시다.돈과 명예는 진정한 확신의 근거가 될 수 없습니다. 오직 행복하기 위한 조건만이 진정한 확신의 바탕이 될 수 있다는 것을 깨닫는 우리가 되길 진심으로 응원합니다.﻿

확신은 어디에서 오는가?

이 글은 직업과 행복, 미래 선택에 대해 깊이 생각하게 만드는 글이네요. 돈과 명예보다 진정한 행복을 추구하는 메시지가 특히 인상적입니다.
https://slopegame.net

취업/이직 시 처음에는 여러가지 방법으로 이력서를 찾아보고 적게 된다. 그리고 서류, 면접에서 몇 번 떨어지다 보면, 점점 이도저도 아닌 이력서가 되어가는 경우가 있다.왜 이런 경우가 발생하는 걸까?먼저 이력서의 경우, 불합격으로 인해 주변의 피드백을 받는 경우가 많다주변의 피드백이 면접관으로써 실력있는 한 사람이라면 괜찮지만, 주로 비슷한 연차거나, 면접관으로써의 실력이 없는 사람들 여러명에게 받는 경우이다. 이력서는 "채용공고에 맞는 역량"을 "내가 경험해온 것"으로 녹여내야하는데, 사람마다 어필하는 방식이나 표현이 다르고 중요하게 생각하는 부분이 다르다.예를 들어 기술적인 역량이 중요한 회사에 다니는 경우, 자신의 이력서는 기술적인 역량으로 합격했기에 기술적인 역량을 어필하라고 한다. 협업 실패를 ..

내 이력서와 면접이 산으로 가는 이유

내 이력서, 면접이 피드백을 받을 수록 산으로 간다고 느낀적 없으신가요? 좋은 회사에 간 사람들의 피드백을 듣고 이력서를 고쳤는데, 점점 서류 합격률이 떨어지는 느낌이 들고, 겨우 겨우 면접에 갔더니 왜 이런걸 묻냐며 핀잔을 듣는 경험 하나 쯤은 있으셨을거라고 생각합니다. 이런 상황이 발생하는 이유나, 이로 인해 발생하는 문제, 그리고 해결할 방법 등을 글로 적어봤습니다. https://softycho.co/72

내 이력서, 면접이 피드백을 받을 수록 산으로 간다고 느낀적 없으신가요?

좋은 회사에 간 사람들의 피드백을 듣고 이력서를 고쳤는데, 점점 서류 합격률이 떨어지는 느낌이 들고, 겨우 겨우 면접에 갔더니 왜 이런걸 묻냐며 핀잔을 듣는 경험 하나 쯤은 있으셨을거라고 생각합니다.

이런 상황이 발생하는 이유나, 이로 인해 발생하는 문제, 그리고 해결할 방법 등을 글로 적어봤습니다.

https://softycho.co/72

@SoftyChoco Blog

혹시, 설명한 내용과 다른 문제라면?
개발자 취업/이직/성장 오픈채팅방에서 함께 이야기해봐요!

https://open.kakao.com/o/g1kyqPIh

자바 사용자에게 NullPointerException(NPE)은 정말이지 지긋지긋한 예외입니다. 우리 모두는 이로 인한 운영 장애를 수없이 겪으며 디버깅으로 밤을 지새운 경험이 있을 겁니다.

JSpecify로 끝내는 NPE 전쟁

Optional, @Nullable, 다양한 정적 분석 도구.. 그동안 자바의 널 안전성을 지키기 위해 많은 꼼수를 써야 했다. 이제 곧 판이 뒤집힌다. JSpecify가 그 파편화된 규칙을 하나로 통일하고 있기 때문이다.

이 글을 통해 JSpecify가 어떤 배경에서 태어났고, 왜 스프링이 이를 전면 채택했는지, 그리고 실무에서 우리에게 어떤 변화를 가져올지 알아본다.

https://www.linkedin.com/pulse/jspecify%EB%A1%9C-%EB%81%9D%EB%82%B4%EB%8A%94-npe-%EC%A0%84%EC%9F%81-springrunner-kythc?utm_source=share&utm_medium=member_ios&utm_campaign=share_via

Optional, @Nullable, 다양한 정적 분석 도구.. 그동안 자바의 널 안전성을 지키기 위해 많은 꼼수를 써야 했다. 이제 곧 판이 뒤집힌다. JSpecify가 그 파편화된 규칙을 하나로 통일하고 있기 때문이다. 이 글을 통해 JSpecify가 어떤 배경에서 태어났고, 왜 스프링이 이를 전면 채택했는지, 그리고 실무에서 우리에게 어떤 변화를 가져올지 알아본다. https://www.linkedin.com/pulse/jspecify%EB%A1%9C-%EB%81%9D%EB%82%B4%EB%8A%94-npe-%EC%A0%84%EC%9F%81-springrunner-kythc?utm_source=share&amp;utm_medium=member_ios&amp;utm_campaign=share_via

www.linkedin.com

직장인을 위한 이솝우화 | 어느 날, 지나가던 사람이 채소에 물을 주는 정원사를 보고 말했다. “심지도 않고 돌보지도 않은 야생 식물들은 계절마다 쑥쑥 자라는데, 당신이 정원에 직접 심은 식물들은 왜 종종 물 부족으로 시드는 것인가요?” 그러자 정원사가 말했다. “야생 식물들은 신에 섭리에 따르고 그 자체로 충분하지요. 하지만, 우리 식물들은 사람의 손에 지나치게 의존하거든요.”  

채소와 잡초

"AI가 주는 결과물을 받기만 할 것이 아니라, AI가 어떻게 그런 결과물을 만들어 내는지 이해하고, AI와 대화하면서 해당 작업에 관한 통찰을 키워야 한다. 그래서 AI와 동등한 눈높이에서 의견을 나눌 수 있는 ‘동료’가 되어야 한다. 그렇지 않으면 머지않아 AI가 시키는 일만 하는 ‘AI의 피고용자’ 신세가 될 수 있다."
- 본문 중
#직장인 #에세이 #역량 #성장


https://brunch.co.kr/@drunkensky/790

"AI가 주는 결과물을 받기만 할 것이 아니라, AI가 어떻게 그런 결과물을 만들어 내는지 이해하고, AI와 대화하면서 해당 작업에 관한 통찰을 키워야 한다. 그래서 AI와 동등한 눈높이에서 의견을 나눌 수 있는 ‘동료’가 되어야 한다. 그렇지 않으면 머지않아 AI가 시키는 일만 하는 ‘AI의 피고용자’ 신세가 될 수 있다." - 본문 중 #직장인 #에세이 #역량 #성장 https://brunch.co.kr/@drunkensky/790

브런치스토리

[직장인을 위한 이솝우화] 채소와 잡초

프로그래밍에서 정말 중요한 개념이라고 생각하는 함수에 대해서 에릭이에게 알려주었습니다.

평소에 개발을 하면서는 몰랐는데 함수에 대한 어려운 용어가 참 많더라고요? 선언, 호출, 매개변수, 반환... 이런 말들을 7살 아이가 이해할 리가 만무하죠.

그래서 복잡한 설명은 생략하고, 무작정 그냥 같이 코드를 짜보기로 했습니다. 다행히도 아이가 금방 흥미를 느끼고 따라오더라고요.

그동안 아무렇지 않게 쓰던
print()
나
range()
가 사실 다 파이썬에 내장된 함수라는 걸 알게 되자, 눈이 동그래지고 입을 떡 벌리며 신기해하네요.

특히 마지막에는 뭔가 깨달았다는듯이 스스로 "Everything is a function!"이라고 외치는데, 저도 괜히 전율이 느껴졌습니다. 😆

📱 짧게 보기: https://youtube.com/shorts/_zKml5PB--Q
📺 전체 영상: https://youtu.be/tgBXKj0Tl00

프로그래밍에서 정말 중요한 개념이라고 생각하는 함수에 대해서 에릭이에게 알려주었습니다. 평소에 개발을 하면서는 몰랐는데 함수에 대한 어려운 용어가 참 많더라고요? 선언, 호출, 매개변수, 반환... 이런 말들을 7살 아이가 이해할 리가 만무하죠. 그래서 복잡한 설명은 생략하고, 무작정 그냥 같이 코드를 짜보기로 했습니다. 다행히도 아이가 금방 흥미를 느끼고 따라오더라고요. 그동안 아무렇지 않게 쓰던 <code>print()</code>나 <code>range()</code>가 사실 다 파이썬에 내장된 함수라는 걸 알게 되자, 눈이 동그래지고 입을 떡 벌리며 신기해하네요. 특히 마지막에는 뭔가 깨달았다는듯이 스스로 "Everything is a function!"이라고 외치는데, 저도 괜히 전율이 느껴졌습니다. 😆 📱 짧게 보기: https://youtube.com/shorts/_zKml5PB--Q📺 전체 영상: https://youtu.be/tgBXKj0Tl00

재미있는 함수에 대해 배워볼까요! 😄

시작만큼 마무리도 중요합니다. 모든 만남에는 언젠가 헤어짐이 따르기 마련입니다. 반갑게 만났다면, 헤어짐 또한 기분 좋게 마무리되어야 하지 않을까요. 헤어지는 이유가 무엇이든 마무리는 아름답게 하는 것이 바람직합니다. 비록 헤어지는 이유가 아쉬움이라 할지라도, 작별의 순간까지 그 아쉬움으로 얼룩질 필요는 없다고 생각합니다. '아쉬움을 뒤로하고 헤어지는 순간만큼은 기분 좋게 마무리하자'는 것이 제 생각입니다.


"정직하고 솔직해야 하는 거 아니냐, 그렇지 않으면 거짓말이다"라고 반문할 수 있습니다. 하지만 세상을 살아가면서 항상 정직하고 솔직하게만 표현하는 것이 과연 좋은 일일까요?
언젠가 아들이 이런 이야기를 했습니다. "사람들은 살면서 하루에 수십 번의 거짓말을 한대요." 사람들이 무의식적으로 거짓말을 하는 이유는 남을 속이려는 악의가 아니라, 자신의 감정과 마음을 온전히 드러내지 않으려는 배려심 때문이라고 믿습니다. 이는 정직하고 솔직한 표현이 항상 건강한 의사소통 방식은 아니라는 것을 우리가 직관적으로 알고 있다는 반증이 아닐까요?
면접 코칭을 하다 보면 답변하기 곤란한 질문에 대해 어떻게 말하면 좋을지 도움을 구하는 경우가 많습니다. 그런 질문을 받으면 먼저 솔직한 심정에 대해 물어봅니다. 정직하고 솔직하게 답변한다면 어떤 생각과 마음인지 들어보고, 제3자의 객관적인 시각으로 피드백을 제공합니다.
물론 제 피드백이 정답은 아닙니다. 이야기는 듣는 사람마다 해석하는 수준과 느끼는 감정이 다르기 때문입니다. 다만 내용을 듣고 조직에서 근무하는 보편적인 사람의 관점에서 채용에 치명적인 요소는 아닌지 점검하는 것입니다. 그리고 필요하다면 답변 내용을 조금 가공할 것을 권합니다. 거짓말을 하자는 것이 아니라, 민감하게 받아들일 수 있는 내용을 생략하거나 표현을 완화하자는 의도입니다.


같은 내용의 메시지를 전달해도 듣는 사람의 기분을 배려하는 말이 있고, 심기를 거스르는 표현이 있습니다. 심기를 거스르는 내용은 대부분 지나치게 직설적인 표현으로 전달되는 메시지입니다. 또는 전후 맥락에 대한 설명 없이 본론만 간단히 이야기하는 경우, 듣는 사람을 당혹스럽게 만들기도 합니다.
알면서도 그러는 건지, 시종일관 자신만의 의사소통 스타일을 고수하는 사람들이 있습니다. 개인적으로 저는 이런 부류의 사람들과 소통하는 것을 가급적 피합니다. 일이 진행되는 효율성보다 사람 간의 관계를 더 중요하게 생각하기 때문입니다. 일이 조금 덜 완벽하고 허술하더라도, 날카롭게 소통하여 날선 관계를 만드는 것보다는 부드럽게 소통하여 편안한 관계를 맺는 것을 더 선호합니다.
무엇이 더 좋고 더 옳은지 시비를 가리자는 것은 아닙니다. 다만 기왕 사람 사는 사이라면 부드러운 것이 더 좋지 않겠냐고 묻고 싶을 뿐입니다.


요즘 여기저기서 회사를 그만두고 싶다고 이야기하는 사람들을 많이 봅니다. 계절적 요인도 작용하는 듯합니다. "더러워서 못해먹겠다"는 이유부터 "이럴 거면 차라리 밖에서 혼자 일해도 먹고 살 수 있겠다"는 의견까지, 회사를 그만두고 싶은 이유는 각양각색입니다.
사실 저 또한 가슴 한켠에 사표를 숨기고 다니며 삽니다. 아마 대한민국에는 마음속으로 사표 여러 장을 품고 회사를 다니는 분들이 많을 것입니다. 그러나 막상 과감하게 사표를 던지고 회사를 박차고 나올 수 있는 사람은 많지 않습니다. 회사 안에서 벌어지는 불합리한 현실보다 회사 밖의 막막한 미래가 더 불안하고 두렵기 때문일 것입니다.


그럼에도 어느 날 회사를 떠나게 된다면, 지금까지 쌓인 감정을 폭발시키기보다는 조용히 지나온 날들을 돌이켜보는 시간을 갖는 것이 더 좋다고 생각합니다. 지난날 좋지 않았던 순간도 있었지만, 기분 좋고 감사했던 기억도 제법 많았을 것입니다. 기분 좋게 출근했던 첫날, 처음 미션을 완수했던 순간, 동료에게 고맙다는 인사를 받던 기억 등 생각해보면 행복하고 감사한 일들도 많았을 것입니다.
비록 퇴사가 조직에 대한 아쉬움으로 일어나는 사건이라 할지라도, 떠나는 순간까지 아쉬워할 필요는 없다고 생각합니다. 아쉬움은 묻어두고 좋았던 기억만 떠올리며 떠나는 것이 더 건강한 이별이라고 생각합니다.
이별 노래 가사에는 "널 위해서 그러는 거야"라는 말이 자주 등장합니다. 생각만 해도 소름 돋는 표현입니다. 그런데 생각해보면, 만났던 사람을 떠나는 입장에서 상대방에게 마음에 들지 않았던 점을 시시콜콜 이야기하며 이별을 통보하는 것이 더 잔인한 방식이라는 생각이 듭니다. 소름 돋지만 "다 너를 위한 거야"라고 변명하며 떠나는 것이 듣는 입장에서는 답답하지만 덜 서운하지 않을까요?
이와 같은 관점에서 보면, 지원한 회사에서 불합격을 통보할 때 합격할 수 없는 이유를 사실 그대로 알리는 것이 꼭 좋은 메시지는 아닐 수도 있다는 생각이 듭니다.
아무튼 이별은 쉽지 않습니다.

﻿시작만큼 마무리도 중요합니다. 모든 만남에는 언젠가 헤어짐이 따르기 마련입니다. 반갑게 만났다면, 헤어짐 또한 기분 좋게 마무리되어야 하지 않을까요. 헤어지는 이유가 무엇이든 마무리는 아름답게 하는 것이 바람직합니다. 비록 헤어지는 이유가 아쉬움이라 할지라도, 작별의 순간까지 그 아쉬움으로 얼룩질 필요는 없다고 생각합니다. '아쉬움을 뒤로하고 헤어지는 순간만큼은 기분 좋게 마무리하자'는 것이 제 생각입니다. "정직하고 솔직해야 하는 거 아니냐, 그렇지 않으면 거짓말이다"라고 반문할 수 있습니다. 하지만 세상을 살아가면서 항상 정직하고 솔직하게만 표현하는 것이 과연 좋은 일일까요?언젠가 아들이 이런 이야기를 했습니다. "사람들은 살면서 하루에 수십 번의 거짓말을 한대요." 사람들이 무의식적으로 거짓말을 하는 이유는 남을 속이려는 악의가 아니라, 자신의 감정과 마음을 온전히 드러내지 않으려는 배려심 때문이라고 믿습니다. 이는 정직하고 솔직한 표현이 항상 건강한 의사소통 방식은 아니라는 것을 우리가 직관적으로 알고 있다는 반증이 아닐까요?면접 코칭을 하다 보면 답변하기 곤란한 질문에 대해 어떻게 말하면 좋을지 도움을 구하는 경우가 많습니다. 그런 질문을 받으면 먼저 솔직한 심정에 대해 물어봅니다. 정직하고 솔직하게 답변한다면 어떤 생각과 마음인지 들어보고, 제3자의 객관적인 시각으로 피드백을 제공합니다.물론 제 피드백이 정답은 아닙니다. 이야기는 듣는 사람마다 해석하는 수준과 느끼는 감정이 다르기 때문입니다. 다만 내용을 듣고 조직에서 근무하는 보편적인 사람의 관점에서 채용에 치명적인 요소는 아닌지 점검하는 것입니다. 그리고 필요하다면 답변 내용을 조금 가공할 것을 권합니다. 거짓말을 하자는 것이 아니라, 민감하게 받아들일 수 있는 내용을 생략하거나 표현을 완화하자는 의도입니다. 같은 내용의 메시지를 전달해도 듣는 사람의 기분을 배려하는 말이 있고, 심기를 거스르는 표현이 있습니다. 심기를 거스르는 내용은 대부분 지나치게 직설적인 표현으로 전달되는 메시지입니다. 또는 전후 맥락에 대한 설명 없이 본론만 간단히 이야기하는 경우, 듣는 사람을 당혹스럽게 만들기도 합니다.알면서도 그러는 건지, 시종일관 자신만의 의사소통 스타일을 고수하는 사람들이 있습니다. 개인적으로 저는 이런 부류의 사람들과 소통하는 것을 가급적 피합니다. 일이 진행되는 효율성보다 사람 간의 관계를 더 중요하게 생각하기 때문입니다. 일이 조금 덜 완벽하고 허술하더라도, 날카롭게 소통하여 날선 관계를 만드는 것보다는 부드럽게 소통하여 편안한 관계를 맺는 것을 더 선호합니다.무엇이 더 좋고 더 옳은지 시비를 가리자는 것은 아닙니다. 다만 기왕 사람 사는 사이라면 부드러운 것이 더 좋지 않겠냐고 묻고 싶을 뿐입니다. 요즘 여기저기서 회사를 그만두고 싶다고 이야기하는 사람들을 많이 봅니다. 계절적 요인도 작용하는 듯합니다. "더러워서 못해먹겠다"는 이유부터 "이럴 거면 차라리 밖에서 혼자 일해도 먹고 살 수 있겠다"는 의견까지, 회사를 그만두고 싶은 이유는 각양각색입니다.사실 저 또한 가슴 한켠에 사표를 숨기고 다니며 삽니다. 아마 대한민국에는 마음속으로 사표 여러 장을 품고 회사를 다니는 분들이 많을 것입니다. 그러나 막상 과감하게 사표를 던지고 회사를 박차고 나올 수 있는 사람은 많지 않습니다. 회사 안에서 벌어지는 불합리한 현실보다 회사 밖의 막막한 미래가 더 불안하고 두렵기 때문일 것입니다. 그럼에도 어느 날 회사를 떠나게 된다면, 지금까지 쌓인 감정을 폭발시키기보다는 조용히 지나온 날들을 돌이켜보는 시간을 갖는 것이 더 좋다고 생각합니다. 지난날 좋지 않았던 순간도 있었지만, 기분 좋고 감사했던 기억도 제법 많았을 것입니다. 기분 좋게 출근했던 첫날, 처음 미션을 완수했던 순간, 동료에게 고맙다는 인사를 받던 기억 등 생각해보면 행복하고 감사한 일들도 많았을 것입니다.비록 퇴사가 조직에 대한 아쉬움으로 일어나는 사건이라 할지라도, 떠나는 순간까지 아쉬워할 필요는 없다고 생각합니다. 아쉬움은 묻어두고 좋았던 기억만 떠올리며 떠나는 것이 더 건강한 이별이라고 생각합니다.이별 노래 가사에는 "널 위해서 그러는 거야"라는 말이 자주 등장합니다. 생각만 해도 소름 돋는 표현입니다. 그런데 생각해보면, 만났던 사람을 떠나는 입장에서 상대방에게 마음에 들지 않았던 점을 시시콜콜 이야기하며 이별을 통보하는 것이 더 잔인한 방식이라는 생각이 듭니다. 소름 돋지만 "다 너를 위한 거야"라고 변명하며 떠나는 것이 듣는 입장에서는 답답하지만 덜 서운하지 않을까요?이와 같은 관점에서 보면, 지원한 회사에서 불합격을 통보할 때 합격할 수 없는 이유를 사실 그대로 알리는 것이 꼭 좋은 메시지는 아닐 수도 있다는 생각이 듭니다.아무튼 이별은 쉽지 않습니다.﻿

이별은 어렵다

요 며칠 GPT-5 Reasoning - High 를 사용해서 진

90%의 기획자들이 빠져있는 문제 

필터 프로블럼(Filter problem)은 무엇인가

매우 공감하는 글. 좀 더 첨언해보자면,

- 문제가 뭔지 정의하고 그에 대한 솔루션을 만들기보다, 머릿속 솔루션(이라기보단 개발 아이디어)을 꺼낸다음 문제를 역으로 정의해서 끼워 맞추려는 경우도 자주 발견할 수 있음

- 문제가 무엇인지 발견하고 정의하는 일이 어려울 때 가장 많이 선택하는 가설 패턴은, ‘OO의 부재로 GMV가 낮다‘ -> ’OO 하면 GMV가 상승할 것‘

- OO 를 런칭한 후 GMV가 상승하지 않으면 기획이 실패한 것이 되므로(가설 입증 여부는 이미 관심이 없는 상태), 성공해야만 함

- 실패했다면 실패한대로, 성공했다면 성공한대로 GMV 올려줄 것 같은 다음 솔루션을 머릿속에서 또 꺼낸 다음, GMV가 상승하는지 또 실험함

이쯤 되면, ‘문제’나 ’가설‘은 온데간데 없고 GMV 상승 아이디어 맞추기 게임이 되어버림. 모든 실험의 성공지표는 GMV로 통일되고, 가설입증을 위한 지표를 살펴야 한다는 의견은 무시당해버림 - GMV 가 오르면 되지, 다른 지표가 왜 중요한데! 라는 태도로 나타남.

비즈니스에서 GMV는 당연히 중요하지만, 그 GMV 를 ‘어떻게’ 확보할 것인지에 대한 전략이 부재한 기업 또는 이를 이해하지 못하는 사람들에게서 나타나는 특징.

매우 공감하는 글. 좀 더 첨언해보자면, - 문제가 뭔지 정의하고 그에 대한 솔루션을 만들기보다, 머릿속 솔루션(이라기보단 개발 아이디어)을 꺼낸다음 문제를 역으로 정의해서 끼워 맞추려는 경우도 자주 발견할 수 있음 - 문제가 무엇인지 발견하고 정의하는 일이 어려울 때 가장 많이 선택하는 가설 패턴은, ‘OO의 부재로 GMV가 낮다‘ -&gt; ’OO 하면 GMV가 상승할 것‘ - OO 를 런칭한 후 GMV가 상승하지 않으면 기획이 실패한 것이 되므로(가설 입증 여부는 이미 관심이 없는 상태), 성공해야만 함 - 실패했다면 실패한대로, 성공했다면 성공한대로 GMV 올려줄 것 같은 다음 솔루션을 머릿속에서 또 꺼낸 다음, GMV가 상승하는지 또 실험함 이쯤 되면, ‘문제’나 ’가설‘은 온데간데 없고 GMV 상승 아이디어 맞추기 게임이 되어버림. 모든 실험의 성공지표는 GMV로 통일되고, 가설입증을 위한 지표를 살펴야 한다는 의견은 무시당해버림 - GMV 가 오르면 되지, 다른 지표가 왜 중요한데! 라는 태도로 나타남. 비즈니스에서 GMV는 당연히 중요하지만, 그 GMV 를 ‘어떻게’ 확보할 것인지에 대한 전략이 부재한 기업 또는 이를 이해하지 못하는 사람들에게서 나타나는 특징.

takyoh.com

매우 공감하는 글. 좀 더 첨언해보자면,

- 문제가 뭔지 정의하

1. 모른다는 말은 알려고 노력하지 않기 위한 구실이자 핑계다.

2. 문제에서 당장 답을 찾고 지름길로 가려고 하지마라. 이런 손쉬운 길은 각자의 잠재력을 방해한다.

3. ’모른다‘라는 말이 입 밖에 나올 때 무슨 일이 벌어지는지 아는가? 뇌가 더 알려고 하지 않는다.

4. 인간은 본래 알아채고 적응하고 행동하고 반복하는 존재다. 무언가를 알아채도록 타고났는데 답을 찾으려고 애쓰지 않는다면, 삶을 변화시킬 중요한 순간을 스스로 가로막는 일이다.

5. 따라서 이런 중요한 순간에 마음을 열어두려면, ”모른다“라고 말할 때마다 깨닫고 당장 다른 말로 바꿔야 한다.

6. 디즈니랜드의 신입 직원은 손님들에게 ”모른다“라고 답하지 않고 대신 ”제가 알아보겠습니다“라고 답한 뒤 실제로 알아보도록 교육받는다.


#예술가의해법

1. 모른다는 말은 알려고 노력하지 않기 위한 구실이자 핑계다. ​2. 문제에서 당장 답을 찾고 지름길로 가려고 하지마라. 이런 손쉬운 길은 각자의 잠재력을 방해한다. ​3. ’모른다‘라는 말이 입 밖에 나올 때 무슨 일이 벌어지는지 아는가? 뇌가 더 알려고 하지 않는다. ​4. 인간은 본래 알아채고 적응하고 행동하고 반복하는 존재다. 무언가를 알아채도록 타고났는데 답을 찾으려고 애쓰지 않는다면, 삶을 변화시킬 중요한 순간을 스스로 가로막는 일이다. ​5. 따라서 이런 중요한 순간에 마음을 열어두려면, ”모른다“라고 말할 때마다 깨닫고 당장 다른 말로 바꿔야 한다. ​6. 디즈니랜드의 신입 직원은 손님들에게 ”모른다“라고 답하지 않고 대신 ”제가 알아보겠습니다“라고 답한 뒤 실제로 알아보도록 교육받는다. #예술가의해법

< 모른다고 말하는 순간, 뇌도 멈춘다 >

나의 소중한 시간과 에너지를 들여
매일의 순간들을 이 두가지 질문에 집중하며 살아간다.


1. 어떻게 살아가야 할 것인가?
2. 어떻게 더 나은 내가 될 수 있을까?


어떤 곳들에서는 타인을 긁고, 깎아내리고,
타인을 평가하느라 소중한 시간과 에너지를 할애한다.
그럴수록 독이 되어 자기 자신에게 돌아온다.
안타깝다.


남들을 평가하느라 남은 생애를 바치기보다는
남들의 평가를 받기 위해 에너지를 쏟아내기보다는
내 남은 생애를 더 나은 세계로 만들기로 결심을 했다.


그렇게 나는 나를 평가하는 평가자로 살아간다.
나를 평가하고 키우는 평가자가 될 것인가
타인을 평가하고 깎는 평가자가 될 것인가


오늘 마음에 새기는 초인의 이야기

나의 소중한 시간과 에너지를 들여매일의 순간들을 이 두가지 질문에 집중하며 살아간다. 1. 어떻게 살아가야 할 것인가?2. 어떻게 더 나은 내가 될 수 있을까? 어떤 곳들에서는 타인을 긁고, 깎아내리고, 타인을 평가하느라 소중한 시간과 에너지를 할애한다.그럴수록 독이 되어 자기 자신에게 돌아온다.안타깝다. 남들을 평가하느라 남은 생애를 바치기보다는남들의 평가를 받기 위해 에너지를 쏟아내기보다는내 남은 생애를 더 나은 세계로 만들기로 결심을 했다. 그렇게 나는 나를 평가하는 평가자로 살아간다.나를 평가하고 키우는 평가자가 될 것인가타인을 평가하고 깎는 평가자가 될 것인가 오늘 마음에 새기는 초인의 이야기

타인의 평가자가 되어 삶을 허비하지 않기로 하였다

일과 사랑, 그리고 인생을 위한 명언 1697개

Books to Read as a Developer

📰  개발자로서 읽어야 할 책 8권

✍️ dev.to에 올라온 개발자 도서 추천글을 번역해보았습니다. 추천된 8권 중 7권이 한글 번역이 되어있으니, 한 권씩 차근 차근 읽어나가보면 좋을것 같아요! 특정 프로그래밍 기술 혹은 언어에 대한 것이 아닌 큰 맥락으로서의 개발 서적들이니 도메인과 분야를 막론하고 한번 도전해보시길 추천합니다. :)  

저는 목록 중에 '코드 컴플리트' 한번 도서관에서 빌려서 앞에 조금 펼쳐보다가 그대로 반납한 기억이 있네요 ^^.. 궁금하시다면! 실물 한번 찾아보시면 바로 끄덕끄덕 하실꺼에요 ㅎㅎ 

--- 

# 실용주의 프로그래머 
- http://www.yes24.com/product/goods/107077663
- 프로그래밍 언어가 아닌 논리 관점에서의 언어 지혜를 다루고 있습니다. 코드 작성, 우수한 팀 구성, 관리, 도구 등 더 나은 프로그래밍을 하기 위한 여러 방법에 대한 이야기를 하고 있습니다. 
- https://pragprog.com/tips/

# 리팩토링 
- http://www.yes24.com/Product/Goods/89649360
- 왜 그리고 언제 리팩토링을 해야할까요? 클래스나 메서드는 어떻게 구성해야 하나요? 유닛 테스트란 뭔가요? 이 책에서 리팩토링에 대한 모든 답을 찾아 볼 수 있습니다. 

# 코드 컴플리트2 
- http://www.yes24.com/product/goods/44130507
- 무려 960 페이지!!! 이 책은 코드 구조, 형식, 변수, 메서드, 팀 관리 등 소프트웨어 개발의 모든 면들을 다 다루고 있어요. 이 엄청난 지식의 양에 감사한 마음이 절로 들지도 모릅니다. 

# 피플웨어 
- http://www.yes24.com/Product/Goods/13657193 
- 프로그래머 관리와 동기부여에 관한 책입니다. 개발 프로세스는 그저 벽돌 쌓기가 아닌 창의적인 과정이니까요! 

# 헤드 퍼스트 디자인 패턴 
- http://www.yes24.com/Product/Goods/108192370 
- 13개의 필수 디자인 패턴를 풍부한 예시와 재밌는 삽화와 함께 설명하는 책입니다. 그저 텍스트만 있는 것이 아니라 손으로 그린 다이어그램과 그림을 통해 개념을 학습하고 몰입할 수 있게 해줍니다. 
- https://longbiao.spatial-crowdsensing.com/courses/scad/files/head-first-design-patterns-compressed.pdf 

# 클린 코드
- http://www.yes24.com/Product/Goods/11681152
- 사람이 읽고 이해하고 유지하기 쉬운 코드를 작성하는 방법에 대한 책입니다. 

# 레거시 코드 활용 전략 
- http://www.yes24.com/Product/Goods/64586851
- 레거시 코드를 가지고 작업하는 건 많은 개발자들이 크게 선호하는 것은 아니지만 피할 수 없는 것이기도 합니다. 이 책은 레거시 코드를 어떻게 올바르게 접근 할 것인지, 그리고 어떻게 안정화 시킬 수 있는지에 대해 이야기 하고 있습니다. 
- https://understandlegacycode.com/blog/key-points-of-working-effectively-with-legacy-code/ 

# A Philosophy of Software Design 
- https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201
- 한글 번역본은 없는것 같네요 ㅠ.ㅠ 
- 특정 프로그래밍 언어에 종속 되지 않는 디자인 설계 측면에서 시간을 넘어 통용되는 프로그래밍 원칙에 대한 내용, 그리고 개념 설명을 하고 있습니다.

DEV Community

📰  개발자로서 읽어야 할 책 8권

✍️ dev.to에 올라온 

단일한 어플리케이션에서 전체 시스템을 구성하는 전통적인 모놀리스 아키텍처와 배포 단위를 기준으로 여러 서비스로 분산하여 시스템을 구성하는 마이크로서비스 아키텍처의 딜레마는 꽤나 긴 시간동안 지속되고 있습니다. '마이크로서비스 패턴'의 저자이자 microservices.io 를 운영하고 있는 크리스 리처드슨은 시스템이 확장되면서 거대한 모놀리스 구조가...

Modular Monolith Architecture와 Spring Modulith

모놀리스(Monolith) 아키텍처는 꽤 오랜 시간 사용되왔던 시스템 설계 방식이었습니다. 하지만 이에 따른 스파게티 코드, 빌드 및 배포의 어려움, 제한적인 스케일링 등의 문제가 발생하였고 커다란 진흙 덩어리(big ball of mud)의 형상이 되었습니다.

이를 해결하기 위한 방법이 마이크로서비스(Microservices) 아키텍처이었습니다. 모놀리스의 많은 단점을 해결해줄 수 있었지만 리소스 비용, 시스템의 복잡성 등 높은 장벽에 의해 많은 개발팀들이 어려움을 겪었습니다.

둘의 딜레마를 해결하기 위해 등장한 그 중간의 선택지 모듈러 모놀리스(Modular Monolith)를 알아보고 이를 구현한 스프링 프로젝트인 모듈리스(Modulith)에 대해 학습하는 튜토리얼 글을 소개합니다.

모놀리스(Monolith) 아키텍처는 꽤 오랜 시간 사용되왔던 시스템 설계 방식이었습니다. 하지만 이에 따른 스파게티 코드, 빌드 및 배포의 어려움, 제한적인 스케일링 등의 문제가 발생하였고 커다란 진흙 덩어리(big ball of mud)의 형상이 되었습니다. 이를 해결하기 위한 방법이 마이크로서비스(Microservices) 아키텍처이었습니다. 모놀리스의 많은 단점을 해결해줄 수 있었지만 리소스 비용, 시스템의 복잡성 등 높은 장벽에 의해 많은 개발팀들이 어려움을 겪었습니다. 둘의 딜레마를 해결하기 위해 등장한 그 중간의 선택지 모듈러 모놀리스(Modular Monolith)를 알아보고 이를 구현한 스프링 프로젝트인 모듈리스(Modulith)에 대해 학습하는 튜토리얼 글을 소개합니다.

Modular Monolithic과 Spring Modulith

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필