유지보수성과 확장성을 동시에 잡는 설계 원칙
많은 프로젝트가 초반에는 잘 돌아갑니다.
하지만 몇 달만 지나도 코드가 복잡해지고,
작은 수정 하나에도 전체가 흔들리기 시작합니다.

왜 그럴까요?
유지보수성과 확장성 사이에는
트레이드 오프가 숨어있기 때문입니다.

유지보수만 고려하면
때로는 과도한 설계가 필요 없어지고
간단하게 만드는게 좋습니다.
다만 이후 기능 추가시에는
점점더 복잡도가 올라가게 됩니다.

반대로 확장성만 고려하면
처음부터 과도한 설계를 할 확률이 커집니다.

Product Engineer는 이 균형을 잡아야 합니다.
제가 중요하게 생각하는 원칙은 세 가지입니다.

1. 경계를 먼저 설계하기
읽기와 쓰기, 서버와 클라이언트, 도메인과 인프라.
경계가 명확해야 유지보수성과 확장성 사이
균형을 잡을 수 있습니다.

2. 의도를 코드 구조에 드러내기
“이 컴포넌트는 절대 상태를 갖지 않는다”
“여기는 반드시 사용자 이벤트를 포함한다”
이런 설계 의도를 구조로 남겨야 수정이 쉽습니다.

3. 변경 가능성과 안정성을 분리하기
자주 바뀌는 영역과
절대 바뀌지 말아야 하는 영역을 구분하세요.
안정된 부분은 Entities로,
변경이 일어나는 부분을 mapper 로 감싸서
안정된 부분을 변경으로부터 격리합니다.

AI 시대에도 이 원칙은 그대로 유효합니다.
AI가 구현을 대신해줄수록,
우리는 설계의 균형을 잡는 일에 집중해야 합니다.

혹시 여러분은
지금 하고 있는 프로젝트가
유지보수성과 확장성 사이의 균형을
잘 잡고 있다고 느끼시나요?

유지보수성과 확장성을 동시에 잡는 설계 원칙 많은 프로젝트가 초반에는 잘 돌아갑니다. 하지만 몇 달만 지나도 코드가 복잡해지고, 작은 수정 하나에도 전체가 흔들리기 시작합니다. 왜 그럴까요? 유지보수성과 확장성 사이에는 트레이드 오프가 숨어있기 때문입니다. 유지보수만 고려하면 때로는 과도한 설계가 필요 없어지고 간단하게 만드는게 좋습니다. 다만 이후 기능 추가시에는 점점더 복잡도가 올라가게 됩니다. 반대로 확장성만 고려하면 처음부터 과도한 설계를 할 확률이 커집니다. Product Engineer는 이 균형을 잡아야 합니다. 제가 중요하게 생각하는 원칙은 세 가지입니다. 1. 경계를 먼저 설계하기 읽기와 쓰기, 서버와 클라이언트, 도메인과 인프라. 경계가 명확해야 유지보수성과 확장성 사이 균형을 잡을 수 있습니다. 2. 의도를 코드 구조에 드러내기 “이 컴포넌트는 절대 상태를 갖지 않는다” “여기는 반드시 사용자 이벤트를 포함한다” 이런 설계 의도를 구조로 남겨야 수정이 쉽습니다. 3. 변경 가능성과 안정성을 분리하기 자주 바뀌는 영역과 절대 바뀌지 말아야 하는 영역을 구분하세요. 안정된 부분은 Entities로, 변경이 일어나는 부분을 mapper 로 감싸서 안정된 부분을 변경으로부터 격리합니다. AI 시대에도 이 원칙은 그대로 유효합니다. AI가 구현을 대신해줄수록, 우리는 설계의 균형을 잡는 일에 집중해야 합니다. 혹시 여러분은 지금 하고 있는 프로젝트가 유지보수성과 확장성 사이의 균형을 잘 잡고 있다고 느끼시나요?

FSD(Feature-Sliced Design)와 Clean Architecture.
두 가지는 출발점이 달라 보이지만,
실제로는 같은 질문에서 시작합니다.

“어떻게 하면 코드가 복잡해지지 않으면서도,
변화에 유연하게 대응할 수 있을까?”

FSD는
기능(feature) 단위로 코드를 나누어
유저 중심의 개발 흐름을 강조합니다.

Clean Architecture는
의존성의 방향을 안쪽으로 제한해
도메인 로직을 지켜내는 데 집중합니다.

저는 이 둘을 결합해
Clean F.S.D라는 구조를 만들었습니다.

핵심은 간단합니다.
Entities = 읽기 전용 (Read)
→ 안정된 도메인 모델, Server Component 중심
Features = 쓰기 전용 (Write)
→ 사용자 이벤트, Server Action·상태 변경

읽기와 쓰기를 명확히 분리하면,
경계가 흐려질 때 오는 혼란을 줄일 수 있습니다.

이 방식은 단순히 구조를 깔끔하게 만드는 게 아니라,
AI 협업에 최적화된 설계 방식이기도 합니다.

AI에게 “Entities 안에서만 작업해”라고 하면
읽기 전용 규칙을 스스로 지킵니다.
“Features에서 Form을 만들어줘”라고 하면
자동으로 쓰기 맥락에서 코드를 생성합니다.

즉, 설계 철학이
AI에게도 일관된 제약 조건으로 전달되는 거죠.

Clean F.S.D는
단순한 폴더 구조가 아니라
AI 시대의 개발 협업을 위한 안전장치입니다.

혹시 여러분의 프로젝트 구조에서는
읽기와 쓰기가 얼마나 명확하게 구분되어 있나요?

FSD(Feature-Sliced Design)와 Clean Architecture. 두 가지는 출발점이 달라 보이지만, 실제로는 같은 질문에서 시작합니다. “어떻게 하면 코드가 복잡해지지 않으면서도, 변화에 유연하게 대응할 수 있을까?” FSD는 기능(feature) 단위로 코드를 나누어 유저 중심의 개발 흐름을 강조합니다. Clean Architecture는 의존성의 방향을 안쪽으로 제한해 도메인 로직을 지켜내는 데 집중합니다. 저는 이 둘을 결합해 Clean F.S.D라는 구조를 만들었습니다. 핵심은 간단합니다. Entities = 읽기 전용 (Read) → 안정된 도메인 모델, Server Component 중심 Features = 쓰기 전용 (Write) → 사용자 이벤트, Server Action·상태 변경 읽기와 쓰기를 명확히 분리하면, 경계가 흐려질 때 오는 혼란을 줄일 수 있습니다. 이 방식은 단순히 구조를 깔끔하게 만드는 게 아니라, AI 협업에 최적화된 설계 방식이기도 합니다. AI에게 “Entities 안에서만 작업해”라고 하면 읽기 전용 규칙을 스스로 지킵니다. “Features에서 Form을 만들어줘”라고 하면 자동으로 쓰기 맥락에서 코드를 생성합니다. 즉, 설계 철학이 AI에게도 일관된 제약 조건으로 전달되는 거죠. Clean F.S.D는 단순한 폴더 구조가 아니라 AI 시대의 개발 협업을 위한 안전장치입니다. 혹시 여러분의 프로젝트 구조에서는 읽기와 쓰기가 얼마나 명확하게 구분되어 있나요?

FSD와 Clean Architecture의 만남: Clean F.S.D

김대리. 내가 감히 조언 하고 싶은것이 있읍니다. 다른것이 아니고, 너무 git rebase? 사용 하지 마세요.

편리함이 있다면, 위험성은 증대하죠. 소를 잡는데는 그만한 칼날이 있고 닭잡는데는 칼이 필요 한가요? 쉬운것이 정답 일수 있읍니다.

변경사항 취합, 정리, 단순한 방법 있어요. 별, 시간도 필요 없고, diff로 patch 파일 만들어서 메일로 보내고 반영하면 tar.gz으로 배포하는 방법도 있죠.

김대리가 전쟁터에 장군이라 가정하죠. 전쟁에서 이겨야 하는것은 당연 한것 아닌가요? 그 상황에 맞는 전략? 지상군으로만 제압한다? 아니죠.

저의 의견은 터미널에서diff로 비교하는게 빠를수 있고, 물론 사람에 차이는 있지만, CVS가 좋을수 있죠. 기트허브는 소잡는 칼 아닌가 해서 의견 드립니다.

—

패러디로 써본건데..써놓고나니 요즘 코딩 AI는 레트로 CLI가 대유행인 시대라 힙하니 좋은데..?! 🤣🤪🤣

김대리. 내가 감히 조언 하고 싶은것이 있읍니다. 다른것이 아니고, 너무 git rebase? 사용 하지 마세요. 편리함이 있다면, 위험성은 증대하죠. 소를 잡는데는 그만한 칼날이 있고 닭잡는데는 칼이 필요 한가요? 쉬운것이 정답 일수 있읍니다. 변경사항 취합, 정리, 단순한 방법 있어요. 별, 시간도 필요 없고, diff로 patch 파일 만들어서 메일로 보내고 반영하면 tar.gz으로 배포하는 방법도 있죠. 김대리가 전쟁터에 장군이라 가정하죠. 전쟁에서 이겨야 하는것은 당연 한것 아닌가요? 그 상황에 맞는 전략? 지상군으로만 제압한다? 아니죠. 저의 의견은 터미널에서diff로 비교하는게 빠를수 있고, 물론 사람에 차이는 있지만, CVS가 좋을수 있죠. 기트허브는 소잡는 칼 아닌가 해서 의견 드립니다. — 패러디로 써본건데..써놓고나니 요즘 코딩 AI는 레트로 CLI가 대유행인 시대라 힙하니 좋은데..?! 🤣🤪🤣

혁신은 한 순간에 만들어지는 것이 아니라 만들면서 발전시키는 것이다.

혁신은 한 순간에 만들어지는 것이 아니라 만들면서 발전시키는 것이다.

요즘 Claude code 에서 codex 로 넘어가야할지
고민하는 분들 꽤 많으신 것으로 알고 있어요.
그래서 직접 비교 해봤습니다.

S.E.O(검색 엔진 최적화) 작업을 시켜봤어요.
Claude code 와 codex 에게 동일한 프롬프트로요.
(S.E.O 제대로 하려면 파일 전체를 읽어서
필요한 상수 값을 잘 넣어주어야 하고,
게다가 server component 와 client component
구분해야 해서 설계 규칙을 잘 지키는지도
볼 수 있어서요)

결과는 Claude code 는 구현 자체에 초점을 맞춰서
잘 해주는 편 같았어요. 다만
구현할 때, 뭔가 추측해서 값을 채워넣는 편이었어요.
(codex 는 정확히 아는 값만 넣었구요)

설계 규칙을 좀 더 잘 지키는 것은 codex 였어요
워낙 간단한 작업이라 더 많은 테스트가 필요하겠지만
그래도 client component 를 유지하면서
새롭게 server component 를 선언하는 방식으로
설계 의도를 잘 지켜서 codex 가 작업해주었어요.
Claude code 는 server component 로 바꾸는
효율성?을 선택했습니다.
(작업에 초점을 맞춰서 그런것 같아요)

더 자세한 이야기가 궁금하시다면 아래
댓글에 영상을 확인해주세요 🤗

요즘 Claude code 에서 codex 로 넘어가야할지 고민하는 분들 꽤 많으신 것으로 알고 있어요. 그래서 직접 비교 해봤습니다. S.E.O(검색 엔진 최적화) 작업을 시켜봤어요. Claude code 와 codex 에게 동일한 프롬프트로요. (S.E.O 제대로 하려면 파일 전체를 읽어서 필요한 상수 값을 잘 넣어주어야 하고, 게다가 server component 와 client component 구분해야 해서 설계 규칙을 잘 지키는지도 볼 수 있어서요) 결과는 Claude code 는 구현 자체에 초점을 맞춰서 잘 해주는 편 같았어요. 다만 구현할 때, 뭔가 추측해서 값을 채워넣는 편이었어요. (codex 는 정확히 아는 값만 넣었구요) 설계 규칙을 좀 더 잘 지키는 것은 codex 였어요 워낙 간단한 작업이라 더 많은 테스트가 필요하겠지만 그래도 client component 를 유지하면서 새롭게 server component 를 선언하는 방식으로 설계 의도를 잘 지켜서 codex 가 작업해주었어요. Claude code 는 server component 로 바꾸는 효율성?을 선택했습니다. (작업에 초점을 맞춰서 그런것 같아요) 더 자세한 이야기가 궁금하시다면 아래 댓글에 영상을 확인해주세요 🤗

서버 액션(Server Action)과 FSD 구조를 결합하는 이유
Next.js의 Server Action은
폼 데이터나 인터랙션을 서버에서 직접 처리할 수 있게 해줍니다.

덕분에 API 라우터를 따로 만들 필요 없이,
UI에서 발생한 이벤트를 곧바로 DB 변경과 연결할 수 있죠.
개발 경험과 성능 모두 좋아집니다.

그런데 문제는 여기서 발생합니다.
“어떤 코드가 읽기 전용이고, 어떤 코드가 쓰기 전용인지”
점점 구분이 흐려지기 시작하는 겁니다.

저는 그래서 Server Action을 사용할 때
Clean FSD 구조를 적용합니다.

Entities(읽기 전용)
→ Server Component 중심, 데이터 조회 전용
Features(쓰기 전용)
→ Server Action으로만 DB를 변경

이렇게 하면 경계가 명확해집니다.
“이건 Entities니까 절대 데이터를 바꾸지 않는다.”
“이건 Features니까 반드시 이벤트와 함께 동작한다.”

설계 의도가 코드 구조에 그대로 남으니,
팀원뿐 아니라 AI에게도 일관된 제약을 줄 수 있습니다.

Server Action은 빠른 구현을,
Clean FSD 구조는 설계 안정성을 줍니다.

이 둘을 적절하게 함께 가져가면
AI 시대에 흔들리지 않는 아키텍처가 완성됩니다.

혹시 여러분의 프로젝트에서는
Server Action을 어떤 기준으로 관리하고 계신가요?

서버 액션(Server Action)과 FSD 구조를 결합하는 이유 Next.js의 Server Action은 폼 데이터나 인터랙션을 서버에서 직접 처리할 수 있게 해줍니다. 덕분에 API 라우터를 따로 만들 필요 없이, UI에서 발생한 이벤트를 곧바로 DB 변경과 연결할 수 있죠. 개발 경험과 성능 모두 좋아집니다. 그런데 문제는 여기서 발생합니다. “어떤 코드가 읽기 전용이고, 어떤 코드가 쓰기 전용인지” 점점 구분이 흐려지기 시작하는 겁니다. 저는 그래서 Server Action을 사용할 때 Clean FSD 구조를 적용합니다. Entities(읽기 전용) → Server Component 중심, 데이터 조회 전용 Features(쓰기 전용) → Server Action으로만 DB를 변경 이렇게 하면 경계가 명확해집니다. “이건 Entities니까 절대 데이터를 바꾸지 않는다.” “이건 Features니까 반드시 이벤트와 함께 동작한다.” 설계 의도가 코드 구조에 그대로 남으니, 팀원뿐 아니라 AI에게도 일관된 제약을 줄 수 있습니다. Server Action은 빠른 구현을, Clean FSD 구조는 설계 안정성을 줍니다. 이 둘을 적절하게 함께 가져가면 AI 시대에 흔들리지 않는 아키텍처가 완성됩니다. 혹시 여러분의 프로젝트에서는 Server Action을 어떤 기준으로 관리하고 계신가요?

이제 처음 개발에 뛰어드는 사람들이 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시대에도 컴퓨터 공학을 공부해야 하는 이유

늘 "더 열심히 해라"라는 말을 들으면서 한국에서 직장 생활을 했습니다. 주변에 워낙 치열하게 일하는 분들이 많다 보니, 웬만큼 노력해서는 명함도 못 내미는 경우가 많았죠.

해외에서도 "난 열심히 해"라고 말하는 사람들이 많습니다. 그런데 막상 함께 일해보면, 한국에서 제가 생각했던 "열심히"와는 거리가 있는 경우가 많아요. 여기서 열심히 한다는 건 그냥 평소보다 조금 더 신경 쓰는 수준일 때가 많습니다. 그런데도 본인은 엄청 열심히 했다며 호들갑을 떱니다. 😅 (물론 이곳의 기준에서는 맞을 겁니다.)

그래서 세계 각지에서 커리어를 쌓고 계신 한국인 분들과 얘기하다 보면, "한국에서 하던 거 반도 안 했는데, 일 잘 한다고 칭찬받아서 놀랬어요!"라며 공감대가 형성되곤 합니다.

어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 앞으로 더 많은 분들이 이 글로벌 경쟁력을 국내에서만 썩히지 마시고 해외에서 마음껏 펼치셨으면 좋겠어요!

늘 "더 열심히 해라"라는 말을 들으면서 한국에서 직장 생활을 했습니다. 주변에 워낙 치열하게 일하는 분들이 많다 보니, 웬만큼 노력해서는 명함도 못 내미는 경우가 많았죠. 해외에서도 "난 열심히 해"라고 말하는 사람들이 많습니다. 그런데 막상 함께 일해보면, 한국에서 제가 생각했던 "열심히"와는 거리가 있는 경우가 많아요. 여기서 열심히 한다는 건 그냥 평소보다 조금 더 신경 쓰는 수준일 때가 많습니다. 그런데도 본인은 엄청 열심히 했다며 호들갑을 떱니다. 😅 (물론 이곳의 기준에서는 맞을 겁니다.) 그래서 세계 각지에서 커리어를 쌓고 계신 한국인 분들과 얘기하다 보면, "한국에서 하던 거 반도 안 했는데, 일 잘 한다고&nbsp;칭찬받아서 놀랬어요!"라며 공감대가 형성되곤 합니다. 어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 앞으로 더 많은 분들이 이 글로벌 경쟁력을 국내에서만 썩히지 마시고 해외에서 마음껏 펼치셨으면 좋겠어요!

해외에서는 덜 열심히 해도 인정받는 이유

‎챙겨콘은 회원가입 없이 누구나 간편하게 기프티콘을 등록하고, 만료일을 놓치지 않도록 자동으로 알림을 받을 수 있는 초간단 기프티콘 관리 앱입니다.

■ 사진 한 장으로 등록  
카메라나 갤러리에서 기프티콘 사진을 선택하면, 온디바이스 OCR이 만료일과 상품명을 자동으로 인식합니다. 필요하다면 직접 수정도 가능합니다.

■ 자동 만료 알림  
기프티콘 만료일 기준 30일, 7일, 1일 전에 푸시 알림을 보내드립니다. 알림 주기도 터치 한 번으로 손쉽게 바꿀 수 있습니다.

■ 스마트 분류와 간편 관리  
전체/유효/만료 기프티콘을 자…

‎챙겨콘

<아쉬워서 앱을 만들었습니다.>
얼마전 아쉬운 일이 있었어요.
집 인터넷을 바꾸면서
신세계 상품권 기프티콘을 받았어요.
유효기간이 꽤 넉넉 했는데,
갑자기 집안에 일이 터지는 바람에
어찌저찌 하다 유효기간이 지나버렸어요
무려 10만원 권 2장이었는데.. 🥹


고객센터에 문의해보니
기간 연장은 불가능하다고 하셨어요.
카톡이든, 문자든 알림이 왔다면
놓치지 않았을텐데.. 😭
왜 나는 알림 설정을 미리 해놓지 않았을까


이 모든 아쉬움을 꾹꾹 눌러 담아
앱을 만들었습니다. 🎉


iOS: https://apps.apple.com/kr/app/챙겨콘/id6751824571?l=en-GB


안드로이드: https://play.google.com/store/apps/details?id=com.david718.gifticonalarm


랜딩페이지: https://www.productengineer.info/camp/cgcon


저처럼 기프티콘 유효기간 놓친 분들
다음에는 절대 놓치는 일 없도록
갤러리에 기프티콘 이미지를 선택하면
자동 알람 설정 되는 앱이어요. 🤗


회원가입 없습니다.
서버저장 없습니다.
인터넷연결 필요 없습니다.


피드백 주시면 개선하는데
큰 도움이 될 것 같습니다.
다들 행복한 기프티콘 생활 되셔요 ㅎㅎ

&lt;아쉬워서 앱을 만들었습니다.&gt;얼마전 아쉬운 일이 있었어요.집 인터넷을 바꾸면서 신세계 상품권 기프티콘을 받았어요.유효기간이 꽤 넉넉 했는데, 갑자기 집안에 일이 터지는 바람에어찌저찌 하다 유효기간이 지나버렸어요 무려 10만원 권 2장이었는데.. 🥹 고객센터에 문의해보니 기간 연장은 불가능하다고 하셨어요.카톡이든, 문자든 알림이 왔다면놓치지 않았을텐데.. 😭왜 나는 알림 설정을 미리 해놓지 않았을까 이 모든 아쉬움을 꾹꾹 눌러 담아앱을 만들었습니다. 🎉 iOS: https://apps.apple.com/kr/app/챙겨콘/id6751824571?l=en-GB 안드로이드: https://play.google.com/store/apps/details?id=com.david718.gifticonalarm 랜딩페이지: https://www.productengineer.info/camp/cgcon 저처럼 기프티콘 유효기간 놓친 분들다음에는 절대 놓치는 일 없도록갤러리에 기프티콘 이미지를 선택하면 자동 알람 설정 되는 앱이어요. 🤗 회원가입 없습니다.서버저장 없습니다.인터넷연결 필요 없습니다. 피드백 주시면 개선하는데 큰 도움이 될 것 같습니다.다들 행복한 기프티콘 생활 되셔요 ㅎㅎ

App Store

안녕하세요. 한국 스프링 사용자 모임 (KSUG)에서 큰일꾼으로 활동하고 있는 김석현입니다. 😊

Spring Camp가 끝난 지 3개월이 되어가는 지금, 저는 10월 26일(일)에 있을 Spring AI Meetup을 준비하고 있습니다.

(행사를 기획하고 준비하는 과정이 저에게 즐거운 일일 줄은 몰랐는데, 한국 스프링 사용자 모임의 일꾼단에 지원했던 것이 정말 좋은 선택이었다고 생각합니다.)

Spring AI는 2025년 5월 20일 1.0.0 버전이 정식 릴리스된 지 4개월이 채 안 된 시점에서 스프링 팀과 커뮤니티의 활발한 기여에 힘입어 Streamable HTTP, MCP 관련 통합 및 각 모델별 지원 기능(e.g. Claude Prompt Caching) 등 다양한 개선 사항이 포함된 1.1.0-M1 버전이 (지난 9일) 공개되었습니다.
- https://lnkd.in/gSPx5dVg

이를 보면 Spring AI가 (아직 가야할 길은 남았지만) 빠른 속도로 발전하고 있다는 인상을 받습니다. 이런 흐름에 발맞춰 한국 스프링 사용자 모임에서 Spring AI를 집중적으로 다루는 자리를 마련하면 좋겠다고 생각하였고, 적극적으로 기여하시고 실무에서 사용하고 계신 연사님들을 모시고 실질적인 인사이트를 얻을 수 있는 자리를 마련하기 위해 열심히 준비하고 있습니다.

이번 행사는 선릉에서 진행될 예정이며, 홈페이지가 준비되는 대로 바로 공식 계정을 통해 공유해드리도록 하겠습니다. 

Spring AI Meetup에 많

Spring AI 1.1.0-M1 Available Now | SeokHyeon Kim

Spring AI는 스프링 생태계의 철학을 AI 도메인으로 확장하고자 등장한 프레임워크다. 그동안 AI 개발 도구와 라이브러리는 주로 파이썬 생태계를 중심으로 발전해왔다. 이 때문에 기업 환경에서 널리 쓰이는 자바는, 생성형 AI를 통합하기 위해 각 서비스의 SDK를 직접 사용하거나 원시적인 API 호출에 의존해야 하는 불편함이 있었다. Spring AI는 바로 이 지점에서, 스프링 사용자들이 기존의 친숙한 방식을 그대로 유지하면서 최신 AI 기능을 손쉽게 활용할 수 있도록 다리를 놓아준다.

Spring AI는 생성형 AI 통합의 복잡성을 단순화하고, 자주 사용되는 패턴들을 정립한다. 그 설계 철학의 핵심은 추상화와 이식성으로 보인다. ChatClient 나 VectorStore 같은 표준 인터페이스를 통해 OpenAI, Anthropic 등 각기 다른 LLM 제공자를 동일한 방식으로 다룰 수 있게 하고, 개발자가 특정 벤더의 세부사항에 얽매이지 않고 비즈니스 로직에 집중하도록 돕는다. 나아가, RAG(Retrieval-augmented generation)나 대화 메모리 같은 공통 기능을 Advisor 라는 개념으로 모듈화하여 횡단 관심사를 깔끔하게 처리한다.

특히 인상적인 부분은 AI에 익숙하지 않은 개발자를 위한 배려다. Spring AI 공식 문서에는 AI 모델의 작동 원리부터 다양한 모델 유형에 대한 설명까지, AI 입문자를 위한 내용이 충실하게 담겨 있다. 효과적인 프롬프트 작성법, 텍스트의 의미를 벡터로 표현하는 임베딩, 비용과 직결되는 토큰의 개념 등 AI 애플리케이션 개발에 필수적인 기초 지식을 체계적으로 안내한다. 더불어, AI 모델에서 구조화된 출력을 얻는 방법이나 RAG 및 도구 호출(Tool Calling)을 통해 외부 데이터와 기능을 연동하는 고급 기법까지 상세히 다룬다. AI 분야가 낯선 분들이라면 꼭 한번 읽어보길 권하고 싶다.

마침 한국 스프링 사용자 모임에서 Spring AI 밋업을 준비하고 있다. 이번 기회를 통해 많은 분들이 이 새로운 기술에 관심을 갖고 함께 이야기를 나눠보는 자리가 되었으면 한다.


https://www.linkedin.com/posts/seokhyeon-kim-6674501b2_spring-ai-110-m1-available-now-activity-7372620269003345920-glaB?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAABvezLwBBEWVnGUkIY_xxm2aE3-sGtVHt0g

Spring AI는 스프링 생태계의 철학을 AI 도메인으로 확장하고자 등장한 프레임워크다. 그동안 AI 개발 도구와 라이브러리는 주로 파이썬 생태계를 중심으로 발전해왔다. 이 때문에 기업 환경에서 널리 쓰이는 자바는, 생성형 AI를 통합하기 위해 각 서비스의 SDK를 직접 사용하거나 원시적인 API 호출에 의존해야 하는 불편함이 있었다. Spring AI는 바로 이 지점에서, 스프링 사용자들이 기존의 친숙한 방식을 그대로 유지하면서 최신 AI 기능을 손쉽게 활용할 수 있도록 다리를 놓아준다. Spring AI는 생성형 AI 통합의 복잡성을 단순화하고, 자주 사용되는 패턴들을 정립한다. 그 설계 철학의 핵심은 추상화와 이식성으로 보인다. ChatClient 나 VectorStore 같은 표준 인터페이스를 통해 OpenAI, Anthropic 등 각기 다른 LLM 제공자를 동일한 방식으로 다룰 수 있게 하고, 개발자가 특정 벤더의 세부사항에 얽매이지 않고 비즈니스 로직에 집중하도록 돕는다. 나아가, RAG(Retrieval-augmented generation)나 대화 메모리 같은 공통 기능을 Advisor 라는 개념으로 모듈화하여 횡단 관심사를 깔끔하게 처리한다. 특히 인상적인 부분은 AI에 익숙하지 않은 개발자를 위한 배려다. Spring AI 공식 문서에는 AI 모델의 작동 원리부터 다양한 모델 유형에 대한 설명까지, AI 입문자를 위한 내용이 충실하게 담겨 있다. 효과적인 프롬프트 작성법, 텍스트의 의미를 벡터로 표현하는 임베딩, 비용과 직결되는 토큰의 개념 등 AI 애플리케이션 개발에 필수적인 기초 지식을 체계적으로 안내한다. 더불어, AI 모델에서 구조화된 출력을 얻는 방법이나 RAG 및 도구 호출(Tool Calling)을 통해 외부 데이터와 기능을 연동하는 고급 기법까지 상세히 다룬다. AI 분야가 낯선 분들이라면 꼭 한번 읽어보길 권하고 싶다. 마침 한국 스프링 사용자 모임에서 Spring AI 밋업을 준비하고 있다. 이번 기회를 통해 많은 분들이 이 새로운 기술에 관심을 갖고 함께 이야기를 나눠보는 자리가 되었으면 한다. https://www.linkedin.com/posts/seokhyeon-kim-6674501b2_spring-ai-110-m1-available-now-activity-7372620269003345920-glaB?utm_source=social_share_send&amp;utm_medium=member_desktop_web&amp;rcm=ACoAABvezLwBBEWVnGUkIY_xxm2aE3-sGtVHt0g

kr.linkedin.com

Spring AI는 생성형 AI 통합을 단순화하고 패턴을 정립한다

실리콘밸리에서 가장 영향력 있는 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개

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

소프트웨어 개발자 필독서 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월에 본 것"⟫

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

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

《건축에 기대는 마음》

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

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

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

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

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

blog.growthmaker.kr

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

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. 그렇게 한다면 모든 이들에게 어떤 것이든 팔 수 있을 것이다. 사람들이 관심을 갖는 것은 오직 이런 것들뿐이다. 이 말은 절대적으로 믿어도 좋다. ​ #무기기되는스토리

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

최근 확정된 ES2023에서는 기존 배열이 아닌 복사본을 변경하여 연산을 수행하는 `toSorted`, `toReversed`, `toSpliced` 와 같은 새로운 메서드들이 추가되었습니다. 이들의 차이점과 프로젝트에서 어떻게 사용할 수 있을지 확인하실 수 있습니다.

[번역] ES2023에서 도입된 자바스크립트의 새로운 배열 복사 메서드

https://velog.io/@eunbinn/es2023-new-array-copying-methods-javascript

velog.io

@정서희 도움 되었다니 다행이에요 🤩👍

Senior Front-end Engineer

조용구

와 지금까지 lodash로 깊은 복사 후 원본배열 수정하는 메서드를 사용했었는데... 감사합니다!

금오공과대학교 컴퓨터소프트웨어공학과

정서희

SSAFY 10기 어둠의 프론트엔드 소모임의 수장 정서희 입니다.
멋진 프론트엔드 개발자가 되어가고 있습니다


댓글 2

비슷한 게시물

주간 인기 TOP 10

추천 프로필