1️⃣ 아이디어의 가치는 실행했을 때 비로소 생긴다.

2️⃣ 고객이 정말 필요한 서비스를 만들어야 한다. 내가 고객인 서비스라면 더 수월하다.

3️⃣ 빠르게 만들고 빠르게 출시한다. 개발 기간이 길다고 더 좋은 서비스가 나오는 건 아니다.

4️⃣ 한 가지 핵심 기능에 집중하는 것이 좋다. 너무 많은 기능을 넣기보다 문제 해결에 초점을 맞춘다.

5️⃣ 나는 생각보다 고객의 마음을 생각보다 잘 모른다. 출시 후 피드백을 받아야 비로소 알게 되는 경우가 많았다.

6️⃣ 개발은 가장 비싼 검증 방법이다.
본격적으로 개발하기 전에 아이디어 검증이 가능하다면 반드시 검증부터 한다.

7️⃣ “시장의 크기 = 문제를 겪는 사람의 수 × 고통의 크기” 이다.
문제를 겪는 사람의 수는 적더라도 고통의 크기가 큰 문제를 해결하는 것이 유리하다.

8️⃣ 보일러플레이트(템플릿)를 만들어두면 멘탈 관리에 좋다.
로그인, 모달, 레이아웃 등 자주 쓰이는 기능을 미리 모듈화하면 개발이 훨씬 수월하다.

9️⃣ 사이드 프로젝트는 최소 1년은 유지해보는 것이 좋다.
언제 터질지 모르므로 Free Tier로 운영할 수 있는 1년 정도는 지켜본다.

🔟 결국, 대부분의 성공은 운이다.
기본적인 것을 지킨다는 전제하에, 성공 여부는 운에 의해 결정될 때가 많다.
그래서 꾸준히 만들고, 실패하며, 경험치를 쌓아가는 과정이 중요하다.

실행이 전부다. 만들고 배운다.

1️⃣ 아이디어의 가치는 실행했을 때 비로소 생긴다. 2️⃣ 고객이 정말 필요한 서비스를 만들어야 한다. 내가 고객인 서비스라면 더 수월하다. 3️⃣ 빠르게 만들고 빠르게 출시한다. 개발 기간이 길다고 더 좋은 서비스가 나오는 건 아니다. 4️⃣ 한 가지 핵심 기능에 집중하는 것이 좋다. 너무 많은 기능을 넣기보다 문제 해결에 초점을 맞춘다. 5️⃣ 나는 생각보다 고객의 마음을 생각보다 잘 모른다. 출시 후 피드백을 받아야 비로소 알게 되는 경우가 많았다. 6️⃣ 개발은 가장 비싼 검증 방법이다.본격적으로 개발하기 전에 아이디어 검증이 가능하다면 반드시 검증부터 한다. 7️⃣ “시장의 크기 = 문제를 겪는 사람의 수 × 고통의 크기” 이다.문제를 겪는 사람의 수는 적더라도 고통의 크기가 큰 문제를 해결하는 것이 유리하다. 8️⃣ 보일러플레이트(템플릿)를 만들어두면 멘탈 관리에 좋다.로그인, 모달, 레이아웃 등 자주 쓰이는 기능을 미리 모듈화하면 개발이 훨씬 수월하다. 9️⃣ 사이드 프로젝트는 최소 1년은 유지해보는 것이 좋다.언제 터질지 모르므로 Free Tier로 운영할 수 있는 1년 정도는 지켜본다. 🔟 결국, 대부분의 성공은 운이다.기본적인 것을 지킨다는 전제하에, 성공 여부는 운에 의해 결정될 때가 많다.그래서 꾸준히 만들고, 실패하며, 경험치를 쌓아가는 과정이 중요하다. 실행이 전부다. 만들고 배운다.

사이드 프로젝트 34개를 만들고 느낀점 10가지

오늘 행사 세션을 전부 영어로 해서 첨엔 통역기를 끼고 들었는데요. 귀가 아파서 잠깐 통역기를 뺐는데 영어가 전보다 수월하게 들려서 깜딱 놀랐네요. 😳 이후로는 통역기를 안쓰고 들었고요.

여러 아미고랑 대화를 매일 하니까 다양한 발음에 익숙해져서 그런지, 주어지는대로 하는 틀에 박힌 대화가 아닌 대화를 해서 그런지, 암튼 듣는게 수월해졌다는게 진짜 확실히 느껴져서 눈물흘렸네요.. 😭 이건 정말 도움이 된다라는 확신이 들었습니다.

진짜 하루에 10분씩 한두달만 해 보세요. 언어능력이 매우 떨어지는 제가 이정도면 진짜 효과 확실한겁니다. 츄라이츄라이~

아미고(Ameego) 다운로드: https://tosto.re/ameego

오늘 행사 세션을 전부 영어로 해서 첨엔 통역기를 끼고 들었는데요. 귀가 아파서 잠깐 통역기를 뺐는데 영어가 전보다 수월하게 들려서 깜딱 놀랐네요. 😳 이후로는 통역기를 안쓰고 들었고요. 여러 아미고랑 대화를 매일 하니까 다양한 발음에 익숙해져서 그런지, 주어지는대로 하는 틀에 박힌 대화가 아닌 대화를 해서 그런지, 암튼 듣는게 수월해졌다는게 진짜 확실히 느껴져서 눈물흘렸네요.. 😭 이건 정말 도움이 된다라는 확신이 들었습니다. 진짜 하루에 10분씩 한두달만 해 보세요. 언어능력이 매우 떨어지는 제가 이정도면 진짜 효과 확실한겁니다. 츄라이츄라이~ 아미고(Ameego) 다운로드: https://tosto.re/ameego

Q) 팀원들과의 협업에서 어떤 부분을 가장 신경 쓰셨나요? (우디)

A) 🙋‍♀️ 일정과 우선순위를 명확히 공유하는 것을 중시했습니다. 당시 MVP 단계라 디자인 시안이 자주 바뀌었습니다. 개발이나 마케팅 일정에 혼선이 생기지 않도록 커뮤니케이션 문서(노션)를 만들고 모두가 접근 가능하게 했습니다. 이후 디자인 변경 사항에 대한 로그와 이미지를 기록하고, 필요시 댓글로 소통 창구를 열었습니다. 덕분에 사소한 변경사항도 즉시 공유돼 실수나 중복 작업을 많이 줄일 수 있었습니다. (3년차 프디분)

*협업시 중간 커뮤니케이션 거점을 제시한다는 점이 좋습니다.

🔗 우디의 포트폴리오 컨설팅 운영중입니다(고정 댓글)

Q) 팀원들과의 협업에서 어떤 부분을 가장 신경 쓰셨나요? (우디) A) 🙋‍♀️ 일정과 우선순위를 명확히 공유하는 것을 중시했습니다. 당시 MVP 단계라 디자인 시안이 자주 바뀌었습니다. 개발이나 마케팅 일정에 혼선이 생기지 않도록 커뮤니케이션 문서(노션)를 만들고 모두가 접근 가능하게 했습니다. 이후 디자인 변경 사항에 대한 로그와 이미지를 기록하고, 필요시 댓글로 소통 창구를 열었습니다. 덕분에 사소한 변경사항도 즉시 공유돼 실수나 중복 작업을 많이 줄일 수 있었습니다. (3년차 프디분) *협업시 중간 커뮤니케이션 거점을 제시한다는 점이 좋습니다. 🔗 우디의 포트폴리오 컨설팅 운영중입니다(고정 댓글)

기억남는 디자이너 면접 답변 [12]

[🚨 3월· 80% 예약 마감] 모집 종료까지 얼마 남지 않았습니다!

https://www.latpeed.com/products/QkCkT

데이터 엔지니어링(Data Engineering)이
주방에서 식재료로 준비하는 요리 과정에 가깝다면,

데이터 사이언스(Data Science)는
레스토랑에서 준비한 요리를
어느정도의 양으로 어떻게 판매할 것인지를
과학적으로 연구하고 최적화하는 과정입니다.

어떤 가격에 언제 가장 고객이 많이 찾아오는 지,
그리고 레스토랑을 잘 운영하기 위한 비용과 매출을
최적화하는 역할을 맡게 됩니다.

데이터 엔지니어링(Data Engineering)이주방에서 식재료로 준비하는 요리 과정에 가깝다면, 데이터 사이언스(Data Science)는레스토랑에서 준비한 요리를어느정도의 양으로 어떻게 판매할 것인지를과학적으로 연구하고 최적화하는 과정입니다. 어떤 가격에 언제 가장 고객이 많이 찾아오는 지,그리고 레스토랑을 잘 운영하기 위한 비용과 매출을최적화하는 역할을 맡게 됩니다.

데이터 엔지니어링 vs 데이터 사이언스

Cursor AI 활용하여 직접 서비스를 만들며 배우는 IT 개발 지식 (4월 1:1 과정) 이런 고민 해보셨나요? 3시간씩 2번, 총 6시간 동안 
1:1로 Cursor AI로 운영 가능한 웹 서비스 제작하며 개발 지식을 배워요! 🚀 개발을 전혀 몰라도,  Cursor AI 라는 도구를 활용해 스스로 웹 서비스를 만들고 배포하는 법까지 배워보세요. 직접

Cursor AI 활용하여 직접 운영 가능한 웹 서비스를 만들며 배우는 IT 개발 지식 (4월 1:1 과정) - Learning by Doing

안녕하세요!

예전에 스타트업 JD에 항상 있었던 내용이 서비스 런칭 경험이었는데,
AI 등장으로 이제는 개발 지식은 필수인 것 같아요.

하지만 이론만 배워서는 개발자 분들의 말을 다 이해하기는 정말 어려운 것이 현실이에요.
그래서 내가 원하는 서비스를 직접 만들면서 개발 지식도 배울 수 있는 단기 1:1 과정을 오픈했습니다! (제가 진행하는 과정/강의를 들으신 분들은 30% 환급해드립니다.)

이론 그 이상을 배워보세요!

많은 관심 부탁드립니다.
감사합니다!!

https://www.latpeed.com/products/GafrE

안녕하세요! 예전에 스타트업 JD에 항상 있었던 내용이 서비스 런칭 경험이었는데, AI 등장으로 이제는 개발 지식은 필수인 것 같아요. 하지만 이론만 배워서는 개발자 분들의 말을 다 이해하기는 정말 어려운 것이 현실이에요.그래서 내가 원하는 서비스를 직접 만들면서 개발 지식도 배울 수 있는 단기 1:1 과정을 오픈했습니다! (제가 진행하는 과정/강의를 들으신 분들은 30% 환급해드립니다.) 이론 그 이상을 배워보세요! 많은 관심 부탁드립니다. 감사합니다!! https://www.latpeed.com/products/GafrE

Latpeed

직접 운영 가능한 웹 서비스를 만들면서 IT 개발 지식을 배우세요!

필자는 SI 프로젝트를 수행하는 회사에서 30년 넘게 근무하고 있다. 그동안  프로젝트를 수행하는 기술과 도구는 비약적으로 발전했다. 가장 큰 발전은 의사소통 도구의 혁신이다. 휴대폰이 등장으로 전화 통화가 쉬워졌고, 이메일/메신저/화상회의 도구는 보편화되었다. 30년 전에는 휴대폰, 메일, 메신저가 없이 고객이나 프로젝트 팀원과 소통하려면 유선 전화기와 대면소통 외에는 방법이 없었다.

개발 관점에서도 웹의 등장, 프로그램 형상관리 및 디자인 도구의 발전, 오늘날에는 AI가 초벌 코딩을 해주는 시대가 되었다. 또한 방법론도 30년 전 보다 크게 변화했다. 문서위주의 엄격한 관리를 중요하게 생각하는 폭포수 방법론 외에 이해관계자와의 협업과 실질적 가치를 중시하는 애자일 방법론이 등장했다. 

그렇다면 30년 전보다 SI 프로젝트의 실패비율은 크게 줄어들었고 팀원들이 이전보다 쾌적한 환경에서 프로젝트를 수행할까? 현실은 여전히 SI 프로젝트는 빡시고 이슈 프로젝트는 매년 발생한다. 그 이유는 예전보다 더 많은 일을 더 빨리하거나 더 작은 MM로 계약하기 때문일 수도 있고, SI 프로젝트의 성공이나 실패의 본질에 기술이나 방법론이 미치는 영향이 제한적이기 때문일 수도 있다. 

IT 및 소프트웨어 개발 프로젝트의 실패 원인을 분석한 1994년 Chaos Report에서는 프로젝트 결과를 성공, 부분적 실패, 완전 실패로 구분했다. 성공은 범위/일정/예산 목표를 달성, 부분실패는 세가지 목표중 한가지 이상을 달성 못함, 완전실패는 세가지 목표 모두 달성하지 못한 프로젝트이다.

1994년과 비교했을 때 2015년 성공 프로젝트 비율은 16%에서 29%로 증가했고, 완전 실패 비율은 31%에서 19%로 줄어들었지만, 부분적 실패 비율은 52%로 큰 변화를 보이지 않았다. SI 프로젝트에서 실패는 대부분 부분적 실패를 의미하므로, 계약 목표를 달성하지 못하는 비율은 크게 변하지 않았다고 볼 수 있다.   
 
1994년 Chaos Report에서 프로젝트 실패원인 10가지와 비중은  다음과 같다. 2015년까지 매년 공개적으로 발표했는데 그 내용은 크게 변하지 않았다.

• 명확하지 않은 요구사항 및 사양(13.1%)
• 사용자의 참여 부족(12.4%)
• 리소스 부족(10.6%)
• 비현실적인 계획(9.9%)
• 경영진 지원 부족(9.3%)
• 기술적 문제(8.7%)
• 프로젝트 계획 및 일정 관리 미흡(8.1%)
• 변화하는 요구사항 및 사양(7.5%)
• 비효율적인 커뮤니케이션(6.2%)
• 조직 문화, 정치적 이슈, 법적 문제 등 기타(14.2%)
 
프로젝트 수행사에서 크게 노력하지 않는다면 예전이나 지금이나 SI 프로젝트에서 이슈가 발생하는 비율은 비슷하고 그 원인은 유사할 것이다. 요구사항 변경, 고객의 참여부족, 고객관리의 어려움, 팀원과 파트너사의 역량 미흡, 예상하지 못했던 성능이슈, 달성하기 힘든 예산과 납기 등은 SI 프로젝트가 존재하는 한 크게 개선하기  힘들다. 그 이유는 다음과 같다. 

- SI 사업환경이 어려울 때 난이도 높은 프로젝트를 수주한다. 
SI 사업을 수행하는 회사는 안정적인 가동률을 유지하기 힘들고, 경쟁력 확보가 힘들기 때문에 사업환경이 힘들 때는 난이도 높은 프로젝트를 저가로 수주하는 경우가 발생한다. 

- 매번 새로운 프로젝트를 하기 때문에 불확실성이 높고 일정, MM 추정이 힘들다. 
SI 프로젝트는 업무, 팀원, 고객, 파트너사가 매번 달라지기 때문에 발생할 수 있는  이슈를 예측하기 힘들고 일정과 MM추정이 신뢰도가 낮기 때문에 프로젝트 목표를 달성하기 힘들다. 

- 프로젝트 이슈가 발생할 경우 ‘win lose’의 구도가 된다.  
조직내부에서 수행하는 프로젝트에서는 업무범위, MM, 일정 이슈 발생 시 최적의 가치를 확보하기 위해 합리적인 의사결정을 할 수 있지만 계약기반의 SI 프로젝트에서는 이슈가 발생하면 이해관계가 충돌하기 때문에 각자도생의 상황이 발생한다. 고객사는 계약서에 있는 기능은 모두 구현해야 한다고 주장하고, 납기 지연이 발생하면 페널티를 부과한다. 수행사는 고객사 귀책이 있기 때문에 페널티를 부담할 수 없다고 주장한다.  

여러분들이 수행하시는 프로젝트의 안녕을 기원합니다.

========================
제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 책 <슬기로운 PM 생활>을 출간한 소식을 공유합니다.
https://product.kyobobook.co.kr/detail/S000215148133

필자는 SI 프로젝트를 수행하는 회사에서 30년 넘게 근무하고 있다. 그동안 &nbsp;프로젝트를 수행하는 기술과 도구는 비약적으로 발전했다. 가장 큰 발전은 의사소통 도구의 혁신이다. 휴대폰이 등장으로 전화 통화가 쉬워졌고, 이메일/메신저/화상회의 도구는 보편화되었다. 30년 전에는 휴대폰, 메일, 메신저가 없이 고객이나 프로젝트 팀원과 소통하려면 유선 전화기와 대면소통 외에는 방법이 없었다. 개발 관점에서도 웹의 등장, 프로그램 형상관리 및 디자인 도구의 발전, 오늘날에는 AI가 초벌 코딩을 해주는 시대가 되었다. 또한 방법론도&nbsp;30년 전 보다 크게 변화했다. 문서위주의 엄격한 관리를 중요하게 생각하는 폭포수 방법론 외에 이해관계자와의 협업과 실질적 가치를 중시하는 애자일 방법론이 등장했다.&nbsp; 그렇다면&nbsp;30년 전보다&nbsp;SI 프로젝트의 실패비율은 크게 줄어들었고 팀원들이 이전보다 쾌적한 환경에서 프로젝트를 수행할까? 현실은 여전히 SI 프로젝트는 빡시고 이슈 프로젝트는 매년 발생한다. 그 이유는 예전보다 더 많은 일을 더 빨리하거나 더 작은 MM로 계약하기 때문일 수도 있고, SI 프로젝트의 성공이나 실패의 본질에 기술이나 방법론이 미치는 영향이 제한적이기 때문일 수도 있다.&nbsp; IT 및 소프트웨어 개발 프로젝트의 실패 원인을 분석한 1994년 Chaos Report에서는 프로젝트 결과를 성공, 부분적 실패, 완전 실패로 구분했다. 성공은 범위/일정/예산 목표를 달성, 부분실패는 세가지 목표중 한가지 이상을 달성 못함, 완전실패는 세가지 목표 모두 달성하지 못한 프로젝트이다. 1994년과 비교했을 때 2015년 성공 프로젝트 비율은 16%에서 29%로 증가했고, 완전 실패 비율은 31%에서 19%로 줄어들었지만, 부분적 실패 비율은 52%로 큰 변화를 보이지 않았다. SI 프로젝트에서 실패는 대부분 부분적 실패를 의미하므로, 계약 목표를 달성하지 못하는 비율은 크게 변하지 않았다고 볼 수 있다. &nbsp;&nbsp;&nbsp;1994년 Chaos Report에서 프로젝트 실패원인 10가지와 비중은 &nbsp;다음과 같다. 2015년까지 매년 공개적으로 발표했는데 그 내용은 크게 변하지 않았다. • 명확하지 않은 요구사항 및 사양(13.1%)• 사용자의 참여 부족(12.4%)• 리소스 부족(10.6%)• 비현실적인 계획(9.9%)• 경영진 지원 부족(9.3%)• 기술적 문제(8.7%)• 프로젝트 계획 및 일정 관리 미흡(8.1%)• 변화하는 요구사항 및 사양(7.5%)• 비효율적인 커뮤니케이션(6.2%)• 조직 문화, 정치적 이슈, 법적 문제 등 기타(14.2%)&nbsp;프로젝트 수행사에서 크게 노력하지 않는다면 예전이나 지금이나 SI 프로젝트에서 이슈가 발생하는 비율은 비슷하고 그 원인은 유사할 것이다.&nbsp;요구사항 변경, 고객의 참여부족, 고객관리의 어려움, 팀원과 파트너사의 역량 미흡, 예상하지 못했던 성능이슈, 달성하기 힘든 예산과 납기 등은 SI 프로젝트가 존재하는 한 크게 개선하기 &nbsp;힘들다. 그 이유는 다음과 같다.&nbsp; - SI&nbsp;사업환경이 어려울 때 난이도 높은 프로젝트를 수주한다.&nbsp;SI 사업을 수행하는 회사는 안정적인 가동률을 유지하기 힘들고, 경쟁력 확보가 힘들기 때문에 사업환경이 힘들 때는 난이도 높은 프로젝트를 저가로 수주하는 경우가 발생한다.&nbsp; -&nbsp;매번 새로운 프로젝트를 하기 때문에 불확실성이 높고 일정, MM 추정이 힘들다.&nbsp;SI 프로젝트는 업무, 팀원, 고객, 파트너사가 매번 달라지기 때문에 발생할 수 있는 &nbsp;이슈를 예측하기 힘들고 일정과 MM추정이 신뢰도가 낮기 때문에 프로젝트 목표를 달성하기 힘들다.&nbsp; -&nbsp;프로젝트 이슈가 발생할 경우 ‘win lose’의 구도가 된다. &nbsp;조직내부에서 수행하는 프로젝트에서는 업무범위, MM, 일정 이슈 발생 시 최적의 가치를 확보하기 위해 합리적인 의사결정을 할 수 있지만 계약기반의 SI 프로젝트에서는 이슈가 발생하면 이해관계가 충돌하기 때문에 각자도생의 상황이 발생한다. 고객사는 계약서에 있는 기능은 모두 구현해야 한다고 주장하고, 납기 지연이 발생하면 페널티를 부과한다.&nbsp;수행사는 고객사 귀책이 있기 때문에 페널티를 부담할 수 없다고 주장한다. &nbsp; 여러분들이 수행하시는 프로젝트의 안녕을 기원합니다. ======================== 제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 책 &lt;슬기로운 PM 생활&gt;을 출간한 소식을 공유합니다.https://product.kyobobook.co.kr/detail/S000215148133&nbsp;

SI 프로젝트 실패비율은 예전보다 줄어들었을까?

최근 ‘핑크펭귄‘이라는 책을 읽고 있습니다. 마케팅과 브랜드 이미지에 대한 내용입니다. 책 표지에 ‘핑크팽귄‘ 제목에 대한 의미를 한 마디로 정의하고 있습니다. ’평범하면 까인다‘ 얼굴의 생김새부터 몸매, 걸음걸이까지 모두 비슷한 펭귄들은 실제로 서로가 서로를 잘 구분하지 못한다고 합니다.

이 시대의 수많은 브랜드가 펭귄과 같습니다. 예를 들면, 짜장면을 판매하는 중국요리 전문점은 성의 이름만 다를 뿐 메뉴부터 음식이 담겨 나오는 접시와 직원분의 말투, 짜장면 두 그릇과 탕수육 작은 사이즈를 시키면 군만두를 서비스를 주는 것까지 비슷합니다. 이들을 구분할 수 있는 유일한 힌트는 자금성, 래리성, 만리장성과 같은 이름뿐인데 이마저도 기억하기 어렵습니다.

‘핑크팽귄’은 똑같아 보이는 펭귄들 사이에 유일하게 구분되는 핑크색 펭귄을 의미합니다. 그러니까 차별된 브랜드 전략으로 구분된 이미지를 뜻하는 것입니다. 아직 책을 삼분의 일 밖에 읽지 않아서 차별화 전략을 다 소개해 드리긴 어렵습니다. 다만, 책의 처음부터 내용이 전개되는 과정에서 시종일관 강조하고 있는 내용이 있으니, 그것은 바로 ‘고객’입니다.

우리는 비즈니스를 하며 고객보다 우리가 제공하려는 제품이나 서비스에 집중합니다. 우리가 제공하는 제품이나 서비스가 얼마나 대단한지 사람들에게 소개하는 일에 몰두합니다. 그러나 안타깝게도 고객은 우리의 제품이나 서비스에 관심이 없습니다. 고객이 관심을 가지고 있는 것은 그들의 문제입니다.

고객은 그들이 지금 불편을 겪고 있거나 어려운 상황에 처한 일을 해결하고 싶어 합니다. 불편과 고민을 해결하기 위해 제품 또는 서비스의 도움을 받고 싶어 합니다. 그런데 제품 또는 서비스를 제공하는 사람들은 고객의 불편과 고민에 관심을 기울이지 않습니다. 고객이 원하는 것을 알지 못한 채, 자신이 제공할 수 있는 최상의 제품 또는 서비스를 열심히 홍보하는 것입니다.

문제는 모두가 그렇게 일을 한다는 것입니다. 자신이 제공할 수 있는 제품 또는 서비스가 좋으니 고객에게 선택해 달라고 이야기합니다. 고객은 똑같이 생긴 수많은 펭귄들 사이 마음에 드는 친구를 고르는 것처럼 넘쳐나는 제품 또는 서비스 중에서 어렵게 하나를 고르지만, 선택한 이유에 대단한 차별점을 느낀 것은 아닙니다. 그냥 그나마 뭔가 좋아 보이거나 가격이 저렴해서 구매했을 뿐입니다.

어쩌다가 ‘핑크팽귄‘과 같이 완전히 다른 친구를 만나면, 고객은 쉽게 그것을 선택하게 됩니다. 그리고 이후에도 지속적으로 ‘핑크팽귄’을 기억하여 이용하게 됩니다. 그런 ‘핑크팽귄’의 특징은 바로 고객을 이해하고 있습니다. 고객이 겪고 있는 문제와 고객이 필요로 하는 것을 알고, 그것을 브랜드를 소개하는 메시지로 전달하는 것입니다. 브랜드 이미지의 차별화 전략은 고객에게 있다는 것이 이와 같은 의미였습니다.

허무하시죠? 너무 뻔한 이야기이고, 누구나 알고 있는 내용이라고 생각하시죠? 그런데 알고 있는 내용을 실천하고 계시나요? 저는 그렇게 일을 하고 있지 못했습니다. 책을 보며 반성을 하게 되었습니다. 훌륭한 인재와 건강한 기업을 연결하는 일을 하고 싶다고 생각하면서, 정작 제가 하는 일에 인재와 기업이라는 고객은 없었습니다. 항상 제가 할 수 있는 일과 제가 잘 하는 일만 나열하며, 그것을 고객이 선택해 주기를 바랐습니다.

요즘 많은 기업들이 채용 브랜드 이미지를 만들기 위해 노력합니다. 기업의 제품 브랜드와 별개로 인재를 영입하기 위해 기업이 차별된 장점을 가지고 있음을 소개하는 것입니다. 그래서 무수히 많은 기업들 가운데 인재에게 선택을 받고 싶은 직장으로 포장하려는 것이 채용 브랜드 이미지입니다. 그러나 안타깝게도 취업이나 이직을 하려는 인재들은 수많은 기업들의 채용 브랜드 이미지를 구분하지 못합니다. 대기업과 유니콘 스타트업, 그리고 평소 자신이 관심을 갖고 있는 제품을 만드는 브랜드 정도를 기억할 뿐입니다.

우리 채용 브랜드 이미지가 다른 회사와 차별된 점이 무엇인지 생각해 보면 좋겠습니다. 차별된 브랜드 이미지를 만들기 위해 어떤 전략으로 구사하고 있는지 회고해 보면 좋겠습니다. 혹시 전략 안에 고객이 되는 ’인재’에 대한 이해가 충분히 있는지 생각해 보아야 할 것입니다. 인재가 바라는 채용 공고, 채용 전형, 처우 협의, 입사 준비 등 고객에게 매력적인 서비스가 무엇인지 깨닫게 되는 기회가 되면 좋겠습니다.

최근 ‘핑크펭귄‘이라는 책을 읽고 있습니다. 마케팅과 브랜드 이미지에 대한 내용입니다. 책 표지에 ‘핑크팽귄‘ 제목에 대한 의미를 한 마디로 정의하고 있습니다. ’평범하면 까인다‘ 얼굴의 생김새부터 몸매, 걸음걸이까지 모두 비슷한 펭귄들은 실제로 서로가 서로를 잘 구분하지 못한다고 합니다. 이 시대의 수많은 브랜드가 펭귄과 같습니다. 예를 들면, 짜장면을 판매하는 중국요리 전문점은 성의 이름만 다를 뿐 메뉴부터 음식이 담겨 나오는 접시와 직원분의 말투, 짜장면 두 그릇과 탕수육 작은 사이즈를 시키면 군만두를 서비스를 주는 것까지 비슷합니다. 이들을 구분할 수 있는 유일한 힌트는 자금성, 래리성, 만리장성과 같은 이름뿐인데 이마저도 기억하기 어렵습니다. ‘핑크팽귄’은 똑같아 보이는 펭귄들 사이에 유일하게 구분되는 핑크색 펭귄을 의미합니다. 그러니까 차별된 브랜드 전략으로 구분된 이미지를 뜻하는 것입니다. 아직 책을 삼분의 일 밖에 읽지 않아서 차별화 전략을 다 소개해 드리긴 어렵습니다. 다만, 책의 처음부터 내용이 전개되는 과정에서 시종일관 강조하고 있는 내용이 있으니, 그것은 바로 ‘고객’입니다. 우리는 비즈니스를 하며 고객보다 우리가 제공하려는 제품이나 서비스에 집중합니다. 우리가 제공하는 제품이나 서비스가 얼마나 대단한지 사람들에게 소개하는 일에 몰두합니다. 그러나 안타깝게도 고객은 우리의 제품이나 서비스에 관심이 없습니다. 고객이 관심을 가지고 있는 것은 그들의 문제입니다. 고객은 그들이 지금 불편을 겪고 있거나 어려운 상황에 처한 일을 해결하고 싶어 합니다. 불편과 고민을 해결하기 위해 제품 또는 서비스의 도움을 받고 싶어 합니다. 그런데 제품 또는 서비스를 제공하는 사람들은 고객의 불편과 고민에 관심을 기울이지 않습니다. 고객이 원하는 것을 알지 못한 채, 자신이 제공할 수 있는 최상의 제품 또는 서비스를 열심히 홍보하는 것입니다. 문제는 모두가 그렇게 일을 한다는 것입니다. 자신이 제공할 수 있는 제품 또는 서비스가 좋으니 고객에게 선택해 달라고 이야기합니다. 고객은 똑같이 생긴 수많은 펭귄들 사이 마음에 드는 친구를 고르는 것처럼 넘쳐나는 제품 또는 서비스 중에서 어렵게 하나를 고르지만, 선택한 이유에 대단한 차별점을 느낀 것은 아닙니다. 그냥 그나마 뭔가 좋아 보이거나 가격이 저렴해서 구매했을 뿐입니다. 어쩌다가 ‘핑크팽귄‘과 같이 완전히 다른 친구를 만나면, 고객은 쉽게 그것을 선택하게 됩니다. 그리고 이후에도 지속적으로 ‘핑크팽귄’을 기억하여 이용하게 됩니다. 그런 ‘핑크팽귄’의 특징은 바로 고객을 이해하고 있습니다. 고객이 겪고 있는 문제와 고객이 필요로 하는 것을 알고, 그것을 브랜드를 소개하는 메시지로 전달하는 것입니다. 브랜드 이미지의 차별화 전략은 고객에게 있다는 것이 이와 같은 의미였습니다. 허무하시죠? 너무 뻔한 이야기이고, 누구나 알고 있는 내용이라고 생각하시죠? 그런데 알고 있는 내용을 실천하고 계시나요? 저는 그렇게 일을 하고 있지 못했습니다. 책을 보며 반성을 하게 되었습니다. 훌륭한 인재와 건강한 기업을 연결하는 일을 하고 싶다고 생각하면서, 정작 제가 하는 일에 인재와 기업이라는 고객은 없었습니다. 항상 제가 할 수 있는 일과 제가 잘 하는 일만 나열하며, 그것을 고객이 선택해 주기를 바랐습니다. 요즘 많은 기업들이 채용 브랜드 이미지를 만들기 위해 노력합니다. 기업의 제품 브랜드와 별개로 인재를 영입하기 위해 기업이 차별된 장점을 가지고 있음을 소개하는 것입니다. 그래서 무수히 많은 기업들 가운데 인재에게 선택을 받고 싶은 직장으로 포장하려는 것이 채용 브랜드 이미지입니다. 그러나 안타깝게도 취업이나 이직을 하려는 인재들은 수많은 기업들의 채용 브랜드 이미지를 구분하지 못합니다. 대기업과 유니콘 스타트업, 그리고 평소 자신이 관심을 갖고 있는 제품을 만드는 브랜드 정도를 기억할 뿐입니다. 우리 채용 브랜드 이미지가 다른 회사와 차별된 점이 무엇인지 생각해 보면 좋겠습니다. 차별된 브랜드 이미지를 만들기 위해 어떤 전략으로 구사하고 있는지 회고해 보면 좋겠습니다. 혹시 전략 안에 고객이 되는 ’인재’에 대한 이해가 충분히 있는지 생각해 보아야 할 것입니다. 인재가 바라는 채용 공고, 채용 전형, 처우 협의, 입사 준비 등 고객에게 매력적인 서비스가 무엇인지 깨닫게 되는 기회가 되면 좋겠습니다.

브랜드 이미지

Manus is a general AI agent that turns your thoughts into actions. It excels at various tasks in work and life, getting everything done while you rest.

스타트업 스닙팟 SEO 개선 실행 계획 - Manus

Manus AI 에게 http://snippod.com 에 대한 SEO 개선안을 만들어 보게 했습니다. 저는 이 결과를 보았을때 엄청 만족스러웠어요.. 이정도면 SEO 컨설턴트에게 맡기면 1주일 이상 걸려서 나올까 말까 한 퀄리티 아닌가요??

https://manus.im/share/t5vVEubVrICt1gAs4SfGWj?replay=1

Manus AI 에게 http://snippod.com 에 대한 SEO 개선안을 만들어 보게 했습니다. 저는 이 결과를 보았을때 엄청 만족스러웠어요.. 이정도면 SEO 컨설턴트에게 맡기면 1주일 이상 걸려서 나올까 말까 한 퀄리티 아닌가요?? https://manus.im/share/t5vVEubVrICt1gAs4SfGWj?replay=1

manus.im

각각의 해결안은 다음 문제의 근원이다. 문제를 이해할 때, 잘못될 수 있는 경우를 적어도 세 가지 이상 생각해내지 못 한다면 당신은 문제를 이해하지 못한 것이다.

우리는 부작용을 특정한 해결안에서 나온 자연스러운 결과로 간주하는 경향이 있다. ‘부작용들은 발생하지 않을 수도 있고 만약 발생한다 하더라도 항상 그것을 제거할 수 있는 해결책을 찾을 수 있다. 이런 순진한 생각이 얼마나 자주 우리를 곤경으로 몰아가는가?

<대체 뭐가 문제야>, 제럴드 M. 와인버그

https://www.instagram.com/p/DHXBa-3TLjT/?igsh=MXI5aWQ2NTQ5ajVu

각각의 해결안은 다음 문제의 근원이다. 문제를 이해할 때, 잘못될 수 있는 경우를 적어도 세 가지 이상 생각해내지 못 한다면 당신은 문제를 이해하지 못한 것이다. 우리는 부작용을 특정한 해결안에서 나온 자연스러운 결과로 간주하는 경향이 있다. ‘부작용들은 발생하지 않을 수도 있고 만약 발생한다 하더라도 항상 그것을 제거할 수 있는 해결책을 찾을 수 있다. 이런 순진한 생각이 얼마나 자주 우리를 곤경으로 몰아가는가? &lt;대체 뭐가 문제야&gt;, 제럴드 M. 와인버그 https://www.instagram.com/p/DHXBa-3TLjT/?igsh=MXI5aWQ2NTQ5ajVu

트레바리 <리서치 하는데요> 북클럽에서 꼽은 문장들

﻿
회사 내부에 채용 업무를 전담하는 담당자와 팀이 없거나 채용해야 하는 포지션이 너무 많거나 채용해야 하는 포지션을 감당할 여력이 없을 때, 회사는 이와 같은 고민을 해결해 줄 전문가를 찾게 됩니다. 채용 업무 관련 전문가 집단을 찾을 때 가장 먼저 떠오르는 사람이 바로 헤드헌터입니다.

헤드헌터는 회사가 필요로 하는 사람을 대신 찾아 줍니다. 그리고 회사의 채용 전형에 인재를 태워 줍니다. 또 인재를 설득해야 하는 순간에 적극적으로 대화를 나눠 줍니다. 헤드헌터는 채용 업무에 있어서 회사가 해야 할 일을 대신해 주는 역할입니다.

회사가 해야 할 역할을 대신하고 역할에 대한 보수를 받습니다. 어떻게 보면 채용 전문가를 고용하는 것이 헤드헌터에게 인재 영입 과제를 의뢰하는 일이라고 생각합니다. 한 명의 인재를 영입하는 일이 하나의 프로젝트가 되고, 인재를 채용하는 것으로 프로젝트가 완수되면 해당 프로젝트에 대한 비용 정산을 하는 시스템입니다.

헤드헌터는 회사 입장에서 완벽한 아군은 아닙니다. 헤드헌터는 프로젝트 성사 여부가 수익과 직결되기 때문입니다. 훌륭한 인재를 소개하는 것만으로 보수를 받지 못하고, 인재가 채용 전형을 모두 통과하여 입사했을 때 프로젝트 수행에 대한 보수를 받을 수 있습니다. 따라서 프로젝트 성사를 위해 헤드헌터는 회사를 설득하기도 합니다.

헤드헌터는 자신이 회사에 추천한 인재에게 정보를 제공합니다. 채용 전형을 통과하는 데 도움이 되는 회사와 관련된 정보, 이와 같은 정보를 이력서와 면접에서 유리하게 풀어낼 노하우 등 헤드헌터는 자신이 회사에 추천한 인재를 적극적으로 돕습니다. 단지 프로젝트 성사로 수익을 얻기 위한 행동은 아닐 것입니다. 인재라고 판단한 사람과 인재를 영입하기 원하는 회사가 서로 궁합이 잘 맞을 것으로 생각하여 둘이 행복한 성장을 만들면 좋겠다는 마음이 있다고 믿습니다.

인재 영입이 어렵듯이, 위와 같은 진정성을 가진 헤드헌터를 만나는 일도 쉽지 않습니다. 채용 직무를 이해하고, 회사의 비즈니스 모델과 기존 구성원의 특성까지 파악하여 인재를 추천하는 헤드헌터를 만나는 확률이 높지 않습니다. 그래서 채용 채널에 대한 데이터를 분석해 보면 헤드헌터 추천으로 영입된 인재 비중이 매우 낮습니다. 물론 예산에 대한 한계와 절약 차원에서 적극적으로 헤드헌터를 고용하지 않거나 헤드헌터 추천 인재를 더 팍팍하게 검증하는 신중하게 의사결정하는 배경도 작용합니다.

돈이라는 제약 조건을 떼고 보더라도 헤드헌터가 진짜 회사를 위하여 적합한 인재를 추천한다는 느낌을 받는 것이 중요합니다. 진심은 마음을 갖고 있는 것만으로 표현되지 않습니다. 진심은 노력으로 나타나는 것입니다. 예를 들면, 회사가 노출한 채용 공고 내용을 보고 이해를 하기 위해 노력해야 합니다. 눈에 보이는 내용뿐만 아니라 채용 공고에 노출하지 않은 회사의 요구를 파악해야 합니다. 궁예의 관심법을 동원하는 것이 아니라 채용 공고를 작성하고 노출한 회사 내부 구성원과 대화를 통해 숨은 요구를 확인해야 합니다.

인재에 대해서도 검증이 필요합니다. 이력서만 보고 채용 공고에서 요구하는 자격 요건에 얼추 부합하니 회사에 추천하는 것이 아니라 인재와 대화를 통해 역량과 경험을 확인해 보아야 합니다. 이력서에 텍스트로 나열된 내용이 실제 어떤 경험이었는지, 경험을 통해 어떤 역량을 획득하게 되었는지 알고 회사에 필요한 인재인지 판단하여 추천해야 합니다.

인재와 기업을 연결하는 비즈니스는 위와 같이 양면을 모두 깊이 이해해야 하는 과제를 수행하는 일입니다. 인재의 이력서와 기업의 채용 공고를 기술적으로 연결하는 것으로 채용 성사가 잘 일어나지 않는 이유가 여기에 있습니다. 눈에 보이지 않는 양면의 숨은 요구가 있기 때문입니다. 텍스트로 설명이 되지 않는 경험과 역량이 있기 때문입니다. 만나서 대화를 통해 이야기 들었을 때, 비로소 이해가 되는 영역이 있습니다. 만나서 느낌을 전달받았을 때, 비로소 공감이 되는 영역이 있습니다.

눈에 보이지 않는 경험과 역량을 선명하게 만들고, 만나야 비로소 이해하고 공감하게 되는 것을 편리한 논리구조로 만들 수 있다면 인재와 기업을 연결하는 비즈니스가 양면에 획기적인 변혁을 제공할 수 있다고 믿습니다.

﻿회사 내부에 채용 업무를 전담하는 담당자와 팀이 없거나 채용해야 하는 포지션이 너무 많거나 채용해야 하는 포지션을 감당할 여력이 없을 때, 회사는 이와 같은 고민을 해결해 줄 전문가를 찾게 됩니다. 채용 업무 관련 전문가 집단을 찾을 때 가장 먼저 떠오르는 사람이 바로 헤드헌터입니다. 헤드헌터는 회사가 필요로 하는 사람을 대신 찾아 줍니다. 그리고 회사의 채용 전형에 인재를 태워 줍니다. 또 인재를 설득해야 하는 순간에 적극적으로 대화를 나눠 줍니다. 헤드헌터는 채용 업무에 있어서 회사가 해야 할 일을 대신해 주는 역할입니다. 회사가 해야 할 역할을 대신하고 역할에 대한 보수를 받습니다. 어떻게 보면 채용 전문가를 고용하는 것이 헤드헌터에게 인재 영입 과제를 의뢰하는 일이라고 생각합니다. 한 명의 인재를 영입하는 일이 하나의 프로젝트가 되고, 인재를 채용하는 것으로 프로젝트가 완수되면 해당 프로젝트에 대한 비용 정산을 하는 시스템입니다. 헤드헌터는 회사 입장에서 완벽한 아군은 아닙니다. 헤드헌터는 프로젝트 성사 여부가 수익과 직결되기 때문입니다. 훌륭한 인재를 소개하는 것만으로 보수를 받지 못하고, 인재가 채용 전형을 모두 통과하여 입사했을 때 프로젝트 수행에 대한 보수를 받을 수 있습니다. 따라서 프로젝트 성사를 위해 헤드헌터는 회사를 설득하기도 합니다. 헤드헌터는 자신이 회사에 추천한 인재에게 정보를 제공합니다. 채용 전형을 통과하는 데 도움이 되는 회사와 관련된 정보, 이와 같은 정보를 이력서와 면접에서 유리하게 풀어낼 노하우 등 헤드헌터는 자신이 회사에 추천한 인재를 적극적으로 돕습니다. 단지 프로젝트 성사로 수익을 얻기 위한 행동은 아닐 것입니다. 인재라고 판단한 사람과 인재를 영입하기 원하는 회사가 서로 궁합이 잘 맞을 것으로 생각하여 둘이 행복한 성장을 만들면 좋겠다는 마음이 있다고 믿습니다. 인재 영입이 어렵듯이, 위와 같은 진정성을 가진 헤드헌터를 만나는 일도 쉽지 않습니다. 채용 직무를 이해하고, 회사의 비즈니스 모델과 기존 구성원의 특성까지 파악하여 인재를 추천하는 헤드헌터를 만나는 확률이 높지 않습니다. 그래서 채용 채널에 대한 데이터를 분석해 보면 헤드헌터 추천으로 영입된 인재 비중이 매우 낮습니다. 물론 예산에 대한 한계와 절약 차원에서 적극적으로 헤드헌터를 고용하지 않거나 헤드헌터 추천 인재를 더 팍팍하게 검증하는 신중하게 의사결정하는 배경도 작용합니다. 돈이라는 제약 조건을 떼고 보더라도 헤드헌터가 진짜 회사를 위하여 적합한 인재를 추천한다는 느낌을 받는 것이 중요합니다. 진심은 마음을 갖고 있는 것만으로 표현되지 않습니다. 진심은 노력으로 나타나는 것입니다. 예를 들면, 회사가 노출한 채용 공고 내용을 보고 이해를 하기 위해 노력해야 합니다. 눈에 보이는 내용뿐만 아니라 채용 공고에 노출하지 않은 회사의 요구를 파악해야 합니다. 궁예의 관심법을 동원하는 것이 아니라 채용 공고를 작성하고 노출한 회사 내부 구성원과 대화를 통해 숨은 요구를 확인해야 합니다. 인재에 대해서도 검증이 필요합니다. 이력서만 보고 채용 공고에서 요구하는 자격 요건에 얼추 부합하니 회사에 추천하는 것이 아니라 인재와 대화를 통해 역량과 경험을 확인해 보아야 합니다. 이력서에 텍스트로 나열된 내용이 실제 어떤 경험이었는지, 경험을 통해 어떤 역량을 획득하게 되었는지 알고 회사에 필요한 인재인지 판단하여 추천해야 합니다. 인재와 기업을 연결하는 비즈니스는 위와 같이 양면을 모두 깊이 이해해야 하는 과제를 수행하는 일입니다. 인재의 이력서와 기업의 채용 공고를 기술적으로 연결하는 것으로 채용 성사가 잘 일어나지 않는 이유가 여기에 있습니다. 눈에 보이지 않는 양면의 숨은 요구가 있기 때문입니다. 텍스트로 설명이 되지 않는 경험과 역량이 있기 때문입니다. 만나서 대화를 통해 이야기 들었을 때, 비로소 이해가 되는 영역이 있습니다. 만나서 느낌을 전달받았을 때, 비로소 공감이 되는 영역이 있습니다. 눈에 보이지 않는 경험과 역량을 선명하게 만들고, 만나야 비로소 이해하고 공감하게 되는 것을 편리한 논리구조로 만들 수 있다면 인재와 기업을 연결하는 비즈니스가 양면에 획기적인 변혁을 제공할 수 있다고 믿습니다.﻿

헤드헌터

면접관으로 들어가면 행동양식 질문으로 물어보는 두 가지 질문이 있다. 하나는 임팩트(Impact)에 관한 것이고 다른 하나는 협업(Collaboration)에 관한 것이다. 임팩트에는 관한 것으로 "커리어에서 가장 임팩트있는 프로젝트에 대해 이야기해달라"는 질문을 하고 협업에 관해서는 "같이 일해본 동료 중에 가장 힘들었던 사람이 누구였고 왜 힘들었지 이야기해달라"이다.

임팩트 질문은 전에 포스팅을 한 적이 있었는데 오늘은 협업 질문에 대해 더 이야기해보고자 한다. 어려운 동료에 관한 질문을 통해 알고자 하는 것은 이 사람이 완벽한 사람인지를 알고자 하는 것이 아니다. 얼마나 솔직한지 알고 싶고 어려운 동료를 통해 무엇을 배웠고 다음에 어떤 변화를 시도했는지 알고 싶은 거다. 즉 자신의 취약한 점을 솔직히 이야기할 줄 아는 사람인지 그리고 복기를 통해 발전을 꾀하는 사람인지 알고 싶은 건데 어떤 답변들은 너무나도 구체적이지 않고 피상적이다. 면접을 잘 하는 방법 중의 하나는 솔직하되 발전하는 모습에 대해 이야기하는 것이며 그렇게 커리어를 바라보는 것이 정말 좋지 않나 싶다.

이 이야기는 지난 주에 산호세 주립대 강의 도입부에 학생들에게 해준 면접 팁의 일부인데 매주 하나씩 공유할 계획이다.

면접관으로 들어가면 행동양식 질문으로 물어보는 두 가지 질문이 있다. 하나는 임팩트(Impact)에 관한 것이고 다른 하나는 협업(Collaboration)에 관한 것이다. 임팩트에는 관한 것으로 "커리어에서 가장 임팩트있는 프로젝트에 대해 이야기해달라"는 질문을 하고 협업에 관해서는 "같이 일해본 동료 중에 가장 힘들었던 사람이 누구였고 왜 힘들었지 이야기해달라"이다. 임팩트 질문은 전에 포스팅을 한 적이 있었는데 오늘은 협업 질문에 대해 더 이야기해보고자 한다. 어려운 동료에 관한 질문을 통해 알고자 하는 것은 이 사람이 완벽한 사람인지를 알고자 하는 것이 아니다. 얼마나 솔직한지 알고 싶고 어려운 동료를 통해 무엇을 배웠고 다음에 어떤 변화를 시도했는지 알고 싶은 거다. 즉 자신의 취약한 점을 솔직히 이야기할 줄 아는 사람인지 그리고 복기를 통해 발전을 꾀하는 사람인지 알고 싶은 건데 어떤 답변들은 너무나도 구체적이지 않고 피상적이다. 면접을 잘 하는 방법 중의 하나는 솔직하되 발전하는 모습에 대해 이야기하는 것이며 그렇게 커리어를 바라보는 것이 정말 좋지 않나 싶다. 이 이야기는 지난 주에 산호세 주립대 강의 도입부에 학생들에게 해준 면접 팁의 일부인데 매주 하나씩 공유할 계획이다.

면접 질문: 같이 일해본 동료 중에 가장 힘들었던 사람은 누구였나

저를 포함한 주변에서 자주 보이는, AI에 대해 공부하는 단계별 순서입니다.

1. ChatGPT 무료로 시작하기
2. GPTs 사용해보기
3. Claude, Google AI studio, Perplexity로 확장
4. 텍스트 기반 LLM에서 다른 모달(Modal)로 확장
(Ex. Midjourney, Genspark, PikaAI, Cursor)
5. LLM 무료 버전에서 유료 버전으로 전환하기
6. Prompt에 대해 공부하고 적용해보기
7. 새로 나오는 연구/논문 찾아보고 공부하기
8. Agent/Workflow에 대해 탐구하고 적용해보기
9. API로 연결해 직접 AI 도구 만들어보기

저를 포함한 주변에서 자주 보이는, AI에 대해 공부하는 단계별 순서입니다. 1. ChatGPT 무료로 시작하기2. GPTs 사용해보기3. Claude, Google AI studio, Perplexity로 확장4. 텍스트 기반 LLM에서 다른 모달(Modal)로 확장(Ex. Midjourney, Genspark, PikaAI, Cursor)5. LLM 무료 버전에서 유료 버전으로 전환하기6. Prompt에 대해 공부하고 적용해보기7. 새로 나오는 연구/논문 찾아보고 공부하기8. Agent/Workflow에 대해 탐구하고 적용해보기9. API로 연결해 직접 AI 도구 만들어보기&nbsp;

AI, 어디까지 써보셨나요?

‘매번 신경쓰지 않아도 API 요청 당 쿼리 호출 수가 임계치를 넘으면, 자동으로 알림이 오도록 만들 순 없을까?’ 라는 작은 고민을 시작으로 ‘모두가 쉽게 사용할 수 있게끔 라이브러리로 만들어보자!’ 까지 도달한 과정을 담은 이야기입니다. 실제로…

API 요청 당 쿼리 개수를 알고 싶어 라이브러리까지 만든 이야기 — 라이브러리 제작

‘매번 신경쓰지 않아도 API 요청 당 쿼리 호출 수가 임계치를 넘으면, 자동으로 알림이 오도록 만들 순 없을까?’ 라는 작은 고민을 시작으로 ‘모두가 쉽게 사용할 수 있게끔 라이브러리로 만들어보자!’ 까지 도달한 이야기
https://medium.com/@hyeon9mak/api-%EC%9A%94%EC%B2%AD-%EB%8B%B9-%EC%BF%BC%EB%A6%AC-%EA%B0%9C%EC%88%98%EB%A5%BC-%EC%95%8C%EA%B3%A0-%EC%8B%B6%EC%96%B4-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC%EA%B9%8C%EC%A7%80-%EB%A7%8C%EB%93%A0-%EC%9D%B4%EC%95%BC%EA%B8%B0-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EC%A0%9C%EC%9E%91-de39f0d27351

‘매번 신경쓰지 않아도 API 요청 당 쿼리 호출 수가 임계치를 넘으면, 자동으로 알림이 오도록 만들 순 없을까?’ 라는 작은 고민을 시작으로 ‘모두가 쉽게 사용할 수 있게끔 라이브러리로 만들어보자!’ 까지 도달한 이야기https://medium.com/@hyeon9mak/api-%EC%9A%94%EC%B2%AD-%EB%8B%B9-%EC%BF%BC%EB%A6%AC-%EA%B0%9C%EC%88%98%EB%A5%BC-%EC%95%8C%EA%B3%A0-%EC%8B%B6%EC%96%B4-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC%EA%B9%8C%EC%A7%80-%EB%A7%8C%EB%93%A0-%EC%9D%B4%EC%95%BC%EA%B8%B0-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EC%A0%9C%EC%9E%91-de39f0d27351

Medium

API 요청 당 쿼리 개수를 알고 싶어 라이브러리까지 만든 이야기

Embarking on a native port of the existing TypeScript compiler and toolset to achieve a 10x performance speed-up.

A 10x Faster TypeScript - TypeScript

타입스크립트가 컴파일러를 Go로 재작성하여 속도를 무려 10배 향상시킨다고 예고했습니다. 7.0 버전으로 출시 예정이고 올해 11월 즈음 베타 버전이 나올 것 같다고 하네요. 그동안 타입스크립트의 성능을 개선하기 위해서 오픈 소스로 여러 시도가 있었지만 모두 실패했는데 마이크로소프트에서 이렇게 직접 나서서 늦게라도 해결해주니 너무 좋은 것 같습니다. 덕분에 VSCode도 얼마나 빠릿빠릿해질지 벌써 기대가 되네요. 단지 Rust를 선택하지 않은 부분은 여러 커뮤니티에서 논쟁거리가 되고 있는 것 같습니다.

타입스크립트가 컴파일러를 Go로 재작성하여 속도를 무려 10배 향상시킨다고 예고했습니다. 7.0 버전으로 출시 예정이고 올해 11월 즈음 베타 버전이 나올 것 같다고 하네요. 그동안 타입스크립트의 성능을 개선하기 위해서 오픈 소스로 여러 시도가 있었지만 모두 실패했는데 마이크로소프트에서 이렇게 직접 나서서 늦게라도 해결해주니 너무 좋은 것 같습니다. 덕분에 VSCode도 얼마나 빠릿빠릿해질지 벌써 기대가 되네요. 단지 Rust를 선택하지 않은 부분은 여러 커뮤니티에서 논쟁거리가 되고 있는 것 같습니다.

TypeScript

🏎️ 타입스크립트가 10배나 빨라 진다구?! 😲

절대 죽지 않는 프로그램을 짜고 싶었습니다. 널 처리만 잘하면 된다고 생각했습니다. 프로그램이 죽는 이유의 대부분이 널 포인터를 건드리는 경우였으니까.

성급한 널 처리의 오류

절대 죽지 않는 프로그램을 짜고 싶었습니다. 널 처리만 잘하면 된다고 생각했습니다.
프로그램이 죽는 이유의 대부분이 널 포인터를 건드리는 경우였으니까.

회사에 처음 들어가서 윈도우 클라이언트 프로그램을 부여받았습니다.
맨티스라는 도구에 버그가 올라오면 내가 고칠 수 있는 게 있을까 신이 나서 찾아 고쳤습니다.
대부분 널 포인터만 감싸면 고쳐지는 에러였습니다.

26살의 신입사원답게 아주 재빨랐습니다.
재현 후 디버거를 붙여서 값이 널로 들어온다?
오케이, 찾았어. 바로 널 체크 코드를 추가했습니다.
if (pData == NULL)
  return;

그리고 다시 재현해 보고 재현이 안 되면 Fix로 변경.
아~ 코딩 참 쉽다.

저는 이걸 성급한 널 처리의 오류라고 부르고 싶습니다.

경험이 쌓이면서 이게 그리 쉬운 문제가 아니라는 걸 알았습니다.
이렇게 널과 널 체크를 남용하면 프로그램이 죽지는 않더라도 버그를 영영 감추는 꼴이 되어버리고 맙니다. 절대 죽지 않는 프로그램보다 문제가 생기면 곧장 죽는 프로그램이 오히려 낫다는 걸 시간이 지나고서야 깨달았습니다.
감춰진 버그는 나중에 결국 나에게 돌아온다는걸.
ASSERT(pData);

ASSERT 같은 코드를 왜 쓰는지도 그쯤에야 깨달았습니다. (학생 때는 도무지 이해가 되지 않았습니다)
알게 된 후로는 적극적으로 사용했습니다.

이후로는 변수가 널이어야 하는 경우와 절대 널이어선 안 되는 경우를 엄격하게 구분하기 시작했습니다. 애초에 널 상태를 만들지 않으려 애썼습니다.
변수를 처음 선언할 때부터.
DB 스키마를 만들 때부터.
서버에서 클라이언트에 데이터를 내려줄 때도 함부로 null 을 사용하지 않았습니다.
이렇게 하면 그걸 받아서 쓰는 애플리케이션 쪽에서 고민거리가 줄어들므로 코딩이 편해집니다.

C/C++처럼 낡은 언어와는 다르게 요즘 언어들은 nullable 혹은 optional 타입 기능을 제공하는 것 같습니다.
저는 C#에서 이걸 처음 봤는데, 최근 언어는 다 탑재하고 있더라고요.
가끔 귀찮다는 느낌이 들 때도 있긴 하지만… 귀찮다고 느껴질 때는 널을 다뤄야 할 때입니다.
애초에 널을 건네주는 곳이 없다면 귀찮을 일도 생기지 않습니다. 이 기능에 대해 호불호가 있지만 저는 선호하는 쪽입니다.

https://jeho.page/essay/2025/03/11/fallacy-of-hasty-null-handling.html

절대 죽지 않는 프로그램을 짜고 싶었습니다. 널 처리만 잘하면 된다고 생각했습니다. 프로그램이 죽는 이유의 대부분이 널 포인터를 건드리는 경우였으니까. 회사에 처음 들어가서 윈도우 클라이언트 프로그램을 부여받았습니다. 맨티스라는 도구에 버그가 올라오면 내가 고칠 수 있는 게 있을까 신이 나서 찾아 고쳤습니다.대부분 널 포인터만 감싸면 고쳐지는 에러였습니다. 26살의 신입사원답게 아주 재빨랐습니다. 재현 후 디버거를 붙여서 값이 널로 들어온다? 오케이, 찾았어. 바로 널 체크 코드를 추가했습니다.<pre ><code>if (pData == NULL)
 return;</code></pre>그리고 다시 재현해 보고 재현이 안 되면 Fix로 변경. 아~ 코딩 참 쉽다. 저는 이걸 성급한 널 처리의 오류라고 부르고 싶습니다. 경험이 쌓이면서 이게 그리 쉬운 문제가 아니라는 걸 알았습니다. 이렇게 널과 널 체크를 남용하면 프로그램이 죽지는 않더라도 버그를 영영 감추는 꼴이 되어버리고 맙니다. 절대 죽지 않는 프로그램보다 문제가 생기면 곧장 죽는 프로그램이 오히려 낫다는 걸 시간이 지나고서야 깨달았습니다. 감춰진 버그는 나중에 결국 나에게 돌아온다는걸.<pre ><code>ASSERT(pData);</code></pre>ASSERT 같은 코드를 왜 쓰는지도 그쯤에야 깨달았습니다. (학생 때는 도무지 이해가 되지 않았습니다) 알게 된 후로는 적극적으로 사용했습니다. 이후로는 변수가 널이어야 하는 경우와 절대 널이어선 안 되는 경우를 엄격하게 구분하기 시작했습니다. 애초에 널 상태를 만들지 않으려 애썼습니다. 변수를 처음 선언할 때부터. DB 스키마를 만들 때부터. 서버에서 클라이언트에 데이터를 내려줄 때도 함부로 null 을 사용하지 않았습니다. 이렇게 하면 그걸 받아서 쓰는 애플리케이션 쪽에서 고민거리가 줄어들므로 코딩이 편해집니다. C/C++처럼 낡은 언어와는 다르게 요즘 언어들은 nullable 혹은 optional 타입 기능을 제공하는 것 같습니다. 저는 C#에서 이걸 처음 봤는데, 최근 언어는 다 탑재하고 있더라고요. 가끔 귀찮다는 느낌이 들 때도 있긴 하지만… 귀찮다고 느껴질 때는 널을 다뤄야 할 때입니다. 애초에 널을 건네주는 곳이 없다면 귀찮을 일도 생기지 않습니다. 이 기능에 대해 호불호가 있지만 저는 선호하는 쪽입니다. https://jeho.page/essay/2025/03/11/fallacy-of-hasty-null-handling.html

K리그 프로그래머

학생 때는 회사 생활이 두려웠어요. 미디어에 비친 회사 생활은 수직적이고 권위적이었거든요.

회사에선 눈치 보는 야근을 해야 하고, 강요받는 회식 자리에 가야하며, 능력보다 관계가 중요한 곳이라고 느꼈어요.

그래서 도망쳤어요. 견뎌낼 자신 없는 문화를 가진 회사는 쳐다보지도 않았어요.

초봉이 중요하다며 조금 참고 돈 잘 주는 곳 가라는 말을 들었어요. 무시했어요. 적은 돈을 받더라도 괜찮았어요.

일이 좋아 출근이 기대되고, 동료들이 좋아 함께 여행도 떠날 수 있으면서, 능력으로 인정받을 수 있는 곳을 찾아다녔어요.

그렇게 9년이 흘렀어요. 저는 도망친 곳에서 낙원을 발견했고 지금의 제 삶을 즐기고 있어요.

학생 때는 회사 생활이 두려웠어요. 미디어에 비친 회사 생활은 수직적이고 권위적이었거든요. 회사에선 눈치 보는 야근을 해야 하고, 강요받는 회식 자리에 가야하며, 능력보다 관계가 중요한 곳이라고 느꼈어요. 그래서 도망쳤어요. 견뎌낼 자신 없는 문화를 가진 회사는 쳐다보지도 않았어요. 초봉이 중요하다며 조금 참고 돈 잘 주는 곳 가라는 말을 들었어요. 무시했어요. 적은 돈을 받더라도 괜찮았어요. 일이 좋아 출근이 기대되고, 동료들이 좋아 함께 여행도 떠날 수 있으면서, 능력으로 인정받을 수 있는 곳을 찾아다녔어요. 그렇게 9년이 흘렀어요. 저는 도망친 곳에서 낙원을 발견했고 지금의 제 삶을 즐기고 있어요.

도망친 곳에 낙원은… 있었다

Apache Kafka는 고성능의 분산 스트리밍 플랫폼으로, 프로듀서(Producer)와 컨슈머(Consumer) 간의 효율적인 데이터 전송을 지원합니다. 그러나 Kafka 자체는 데이터의 구조나 형식에 대한 검증을 수행하지 않으므로, 데이터 스키마의 관리와 호환성 유지에 어려움이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Schema Registry가 도입되었습니다.​ Schema Registry란 무엇인가?Schema Registry는 Kafka와 별도로 동작하는 독립적인 애플리케이션으로, Kafka에서 주고받는 메시지의 스키마를 중앙에서 관리하고 저장하는 역할을 합니다. 이를 통해 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 정의를 공유하며, 데이터의 일관성과 호환성을 보장합니다. 왜 ..

Kafka Schema Registry: 데이터 스키마의 중앙 집중 관리

 Apache Kafka는 고성능의 분산 스트리밍 플랫폼으로, 프로듀서(Producer)와 컨슈머(Consumer) 간의 효율적인 데이터 전송을 지원합니다. 그러나 Kafka 자체는 데이터의 구조나 형식에 대한 검증을 수행하지 않으므로, 데이터 스키마의 관리와 호환성 유지에 어려움이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Schema Registry가 도입되었습니다.
 
Schema Registry란 무엇인가?
Schema Registry는 Kafka와 별도로 동작하는 독립적인 애플리케이션으로, Kafka에서 주고받는 메시지의 스키마를 중앙에서 관리하고 저장하는 역할을 합니다. 이를 통해 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 정의를 공유하며, 데이터의 일관성과 호환성을 보장합니다.
 
왜 Schema Registry가 필요한가?
Kafka는 기본적으로 바이트 스트림으로 데이터를 처리하며, 데이터의 구조나 형식에 대한 제약이 없습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다:
 * 스키마 변경으로 인한 장애 발생: 프로듀서가 데이터 형식을 변경하면, 이를 알지 못한 컨슈머는 역직렬화 과정에서 오류가 발생할 수 있습니다.
 * 데이터 명세 관리의 어려움: 여러 프로듀서와 컨슈머가 존재하는 환경에서 데이터 구조에 대한 명확한 정의가 없으면, 시스템 전체의 안정성이 저하될 수 있습니다. 
Schema Registry는 이러한 문제를 해결하기 위해 다음과 같은 기능을 제공합니다:
 * 스키마 중앙 관리: 모든 스키마를 중앙에서 관리하여 데이터 구조의 일관성을 유지합니다.
 * 호환성 검증: 새로운 스키마 등록 시 기존 스키마와의 호환성을 검증하여, 스키마 진화로 인한 오류를 방지합니다.
 * 스키마 버전 관리: 스키마의 버전을 체계적으로 관리하여, 필요 시 이전 버전으로의 롤백을 가능하게 합니다.

Schema Registry의 작동 원리
Schema Registry는 다음과 같은 흐름으로 작동합니다:
 1. 스키마 등록: 프로듀서는 메시지를 Kafka에 전송하기 전에 해당 메시지의 스키마를 Schema Registry에 등록합니다. 
 2. 스키마 ID 부여: Schema Registry는 등록된 스키마에 고유한 ID를 부여하고, 프로듀서는 이 스키마 ID를 메시지에 포함시켜 Kafka에 전송합니다.
 3. 메시지 소비: 컨슈머는 Kafka에서 메시지를 읽어들인 후, 메시지에 포함된 스키마 ID를 사용하여 Schema Registry에서 스키마를 조회하고, 이를 통해 메시지를 역직렬화합니다.
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int"}
  ]
}

 
이러한 과정은 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 계약을 가능하게 하며, 시스템의 안정성과 데이터의 신뢰성을 향상시킵니다.
 
Schema Registry의 장단점
✅ 장점
 * 시스템 안정성 향상: 스키마 변경 시 발생할 수 있는 오류를 사전에 방지하여 시스템의 안정성을 높입니다.
 * 데이터 명세 관리 용이: 중앙에서 스키마를 관리함으로써 데이터 구조에 대한 명확한 정의를 제공하고, 운영의 효율성을 향상시킵니다.
 * 업무 효율성 증대: 스키마 관리로 인한 불필요한 커뮤니케이션을 줄여 개발자들이 본연의 업무에 집중할 수 있게 합니다.
❌ 단점
 * 관리 포인트 증가: Schema Registry 서버를 추가로 관리해야 하므로 운영 복잡성이 증가할 수 있습니다.
 * 스키마 관리 부담: 엄격한 스키마 검증으로 인해 스키마 변경 시 추가적인 관리 작업이 필요할 수 있습니다.
 
결론
Kafka Schema Registry는 데이터의 스키마를 중앙에서 관리하여 프로듀서와 컨슈머 간의 일관성을 보장하는 필수적인 컴포넌트입니다. 이를 통해 데이터의 신뢰성을 유지하고, 스키마 변경으로 인한 장애를 방지할 수 있습니다.
 
📌 기억할 점
 * Kafka 자체는 데이터 형식을 검증하지 않음 → Schema Registry가 필요함
 * 프로듀서는 메시지를 전송하기 전에 Schema Registry에 스키마를 등록해야 함
 * 컨슈머는 메시지를 소비할 때 Schema Registry에서 스키마를 조회하여 역직렬화함
 * JSON, Avro, Protobuf 등의 다양한 포맷을 지원함

&nbsp;Apache Kafka는 고성능의 분산 스트리밍 플랫폼으로, 프로듀서(Producer)와 컨슈머(Consumer) 간의 효율적인 데이터 전송을 지원합니다. 그러나 Kafka 자체는 데이터의 구조나 형식에 대한 검증을 수행하지 않으므로, 데이터 스키마의 관리와 호환성 유지에 어려움이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Schema Registry가 도입되었습니다.​&nbsp;Schema Registry란 무엇인가?Schema Registry는 Kafka와 별도로 동작하는 독립적인 애플리케이션으로, Kafka에서 주고받는 메시지의 스키마를 중앙에서 관리하고 저장하는 역할을 합니다. 이를 통해 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 정의를 공유하며, 데이터의 일관성과 호환성을 보장합니다.&nbsp;왜 Schema Registry가 필요한가?Kafka는 기본적으로 바이트 스트림으로 데이터를 처리하며, 데이터의 구조나 형식에 대한 제약이 없습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다:​<ul ><li>스키마 변경으로 인한 장애 발생: 프로듀서가 데이터 형식을 변경하면, 이를 알지 못한 컨슈머는 역직렬화 과정에서 오류가 발생할 수 있습니다. ​</li><li>데이터 명세 관리의 어려움: 여러 프로듀서와 컨슈머가 존재하는 환경에서 데이터 구조에 대한 명확한 정의가 없으면, 시스템 전체의 안정성이 저하될 수 있습니다.&nbsp;</li></ul>Schema Registry는 이러한 문제를 해결하기 위해 다음과 같은 기능을 제공합니다:​<ul ><li>스키마 중앙 관리: 모든 스키마를 중앙에서 관리하여 데이터 구조의 일관성을 유지합니다.​</li><li>호환성 검증: 새로운 스키마 등록 시 기존 스키마와의 호환성을 검증하여, 스키마 진화로 인한 오류를 방지합니다.​</li><li>스키마 버전 관리: 스키마의 버전을 체계적으로 관리하여, 필요 시 이전 버전으로의 롤백을 가능하게 합니다.</li></ul> Schema Registry의 작동 원리Schema Registry는 다음과 같은 흐름으로 작동합니다:​<ol ><li>스키마 등록: 프로듀서는 메시지를 Kafka에 전송하기 전에 해당 메시지의 스키마를 Schema Registry에 등록합니다.&nbsp;</li><li>스키마 ID 부여: Schema Registry는 등록된 스키마에 고유한 ID를 부여하고, 프로듀서는 이 스키마 ID를 메시지에 포함시켜 Kafka에 전송합니다.​</li><li>메시지 소비: 컨슈머는 Kafka에서 메시지를 읽어들인 후, 메시지에 포함된 스키마 ID를 사용하여 Schema Registry에서 스키마를 조회하고, 이를 통해 메시지를 역직렬화합니다.​</li></ol><pre ><code class="language-bash">{
 "type": "record",
 "name": "User",
 "fields": [
 {"name": "name", "type": "string"},
 {"name": "age", "type": "int"}
 ]
}</code></pre>&nbsp;이러한 과정은 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 계약을 가능하게 하며, 시스템의 안정성과 데이터의 신뢰성을 향상시킵니다.&nbsp;Schema Registry의 장단점✅ 장점<ul ><li>시스템 안정성 향상: 스키마 변경 시 발생할 수 있는 오류를 사전에 방지하여 시스템의 안정성을 높입니다.</li><li>데이터 명세 관리 용이: 중앙에서 스키마를 관리함으로써 데이터 구조에 대한 명확한 정의를 제공하고, 운영의 효율성을 향상시킵니다.​</li><li>업무 효율성 증대: 스키마 관리로 인한 불필요한 커뮤니케이션을 줄여 개발자들이 본연의 업무에 집중할 수 있게 합니다.</li></ul>❌ 단점<ul ><li>관리 포인트 증가: Schema Registry 서버를 추가로 관리해야 하므로 운영 복잡성이 증가할 수 있습니다.​</li><li>스키마 관리 부담: 엄격한 스키마 검증으로 인해 스키마 변경 시 추가적인 관리 작업이 필요할 수 있습니다.</li></ul>&nbsp;결론Kafka Schema Registry는 데이터의 스키마를 중앙에서 관리하여 프로듀서와 컨슈머 간의 일관성을 보장하는 필수적인 컴포넌트입니다. 이를 통해 데이터의 신뢰성을 유지하고, 스키마 변경으로 인한 장애를 방지할 수 있습니다.&nbsp;📌 기억할 점<ul ><li>Kafka 자체는 데이터 형식을 검증하지 않음 → Schema Registry가 필요함</li><li>프로듀서는 메시지를 전송하기 전에 Schema Registry에 스키마를 등록해야 함</li><li>컨슈머는 메시지를 소비할 때 Schema Registry에서 스키마를 조회하여 역직렬화함</li><li>JSON, Avro, Protobuf 등의 다양한 포맷을 지원함 </li></ul>

덕토피아

🕊️ Kafka Schema Registry: 데이터 스키마 관리

사용자가 공유한 콘텐츠

체력은 "하고 싶은 것과 할 수 있는 것 사이의 갭을 줄이는 거예요."라는 말에 밑줄을 그었습니다. 원문 제목은 "40대 이후엔 체력전이다"인데, 전체를 관통하는 내용은 '다정함은 체력에서 나오니까, 다정하려면 체력을 길러라'는 명제에 가까운 내용입니다. 전 구글 디렉터 정김경숙 님이 체력을 가꾸는 이유, 나노운동을 통해 "시간이 없다"라는 핑계를 멀리하는 이유에도 고개를 끄덕이게 됩니다.

사실 정김경숙 님이 유명해진 건 구글에서 17년 일하다 갑자기 해고당한 이후 주 80시간의 육체노동을 택하며 '트레이더조'에서 일하며 스몰토크를 하는 경험을 긍정적으로 이야기하면서부터였는데요. 점심시간 1시간을 활용해서는 리프트로 라이드헤일링을 하며 다리는 쉬면서 또 일을 했죠. 트레이더조 일이 끝나면 곧장 스타벅스 유니폼을 입었습니다. 즐겁게 일했다는 점을 생각하면 그녀는 스스로에게 다정했습니다.

낯선 사람에게 친절을 베풀면 그 의도를 의심하는 게 더 합리적인 것 같은 사회에 살고 있지만, 다정함은 누구나에게 필요합니다. 스스로에게 다정할 만큼 체력을 기르고 나면, 남는 체력으로는 이방인에게도 다정할 수 있지 않을까요? 오늘 이 아티클 덕분에 낯선 이에게 조금 더 친절할 수 있었고, 더 괜찮은 사람이 되겠다는 다짐을 했습니다.

https://www.folin.co/article/10337/gift/DghwhBThRk5eYf1Xrm2vYX7f6xiFZe6L

체력은 "하고 싶은 것과 할 수 있는 것 사이의 갭을 줄이는 거예요."라는 말에 밑줄을 그었습니다. 원문 제목은 "40대 이후엔 체력전이다"인데, 전체를 관통하는 내용은 '다정함은 체력에서 나오니까, 다정하려면 체력을 길러라'는 명제에 가까운 내용입니다. 전 구글 디렉터 정김경숙 님이 체력을 가꾸는 이유, 나노운동을 통해 "시간이 없다"라는 핑계를 멀리하는 이유에도 고개를 끄덕이게 됩니다. 사실 정김경숙 님이 유명해진 건 구글에서 17년 일하다 갑자기 해고당한 이후 주 80시간의 육체노동을 택하며 '트레이더조'에서 일하며 스몰토크를 하는 경험을 긍정적으로 이야기하면서부터였는데요. 점심시간 1시간을 활용해서는 리프트로 라이드헤일링을 하며 다리는 쉬면서 또 일을 했죠. 트레이더조 일이 끝나면 곧장 스타벅스 유니폼을 입었습니다. 즐겁게 일했다는 점을 생각하면 그녀는 스스로에게 다정했습니다. 낯선 사람에게 친절을 베풀면 그 의도를 의심하는 게 더 합리적인 것 같은 사회에 살고 있지만, 다정함은 누구나에게 필요합니다. 스스로에게 다정할 만큼 체력을 기르고 나면, 남는 체력으로는 이방인에게도 다정할 수 있지 않을까요? 오늘 이 아티클 덕분에 낯선 이에게 조금 더 친절할 수 있었고, 더 괜찮은 사람이 되겠다는 다짐을 했습니다. https://www.folin.co/article/10337/gift/DghwhBThRk5eYf1Xrm2vYX7f6xiFZe6L

www.folin.co

《다정함도 체력에서 나오니까》

최근 DeepSeek에 이어 중국발 AI에이전트 돌풍(?)을 일으키고 있는 마누스(Manus) AI 내용을 정리해봅니다.

🍏 Manus AI 개요
 * 개발사: 중국 스타트업 Monica
 * 출시: 2025년 3월 6일
 * 기반 모델: Anthropic의 Claude 3.5 Sonnet과 Alibaba의 Qwen 모델 기반
 * 특징
   * 세계 최초의 범용 자율 AI 에이전트
   * OpenAI Deep Research, Gemini Deep Research 등에서 볼 수 있는 딥 리서치 기능을 구현한 멀티 에이전트 협업 시스템
   * 기존의 챗봇이나 AI 모델과 달리, Manus는 단순한 답변 제공을 넘어 실제 결과물을 도출하는 데 초점
   * 계획, 실행, 검증을 담당하는 별도의 에이전트들로 구성된 멀티 에이전트 아키텍처
   * 대규모 작업을 수백개의 실행 가능한 하위 작업으로 나누는 동적 타겟 분해 기능
   * 여러 유형의 데이터를 동시에 처리하는 교차 모달 추론 기능
   * 강화학습을 통한 의사결정 효율성 지속적인 개선 및 오류율 최소화
   * 지시를 기다리지 않고 스스로 작업을 시작하고 새로운 정보를 평가하며 접근 방식으로 동적으로 조정하는 자기주도적 작업 수행

🍏 기술적 특징
 * 멀티 에이전트 아키텍처
   * 계획 에이전트(Planning Agent)
     * 작업 분석 및 단계별 계획 수립
     * 사용자 요청을 PDCA(Plan-Do-Check-Act) 사이클로 분해
     * Monte Carlo Tree Search(MCTS) 알고리즘 활용
     * Anthropic Qwen 모델 기반의 텍스트 분석 및 전략 세분화
   * 실행 에이전트(Execution Agent)
     * 웹 브라우저/데이터베이스 등 27개 외부 도구와 실시간 연동
     * Claude 3.5 Sonnet 모델을 주력으로 사용
     * 비동기적 클라우드 처리 아키텍처 지원
   * 검증 에이전트(Validation Agent)
     * 결과 검증 및 최적화
     * 3단계 검증 프로세스: 형식 검증 (표 구조/코드 문법), 내용 검증 (사실 관계 확인, 컨텍스트 검증 (사용자 의도 부합 여부)
 * 성능 향상 메커니즘
   * 동적 모델 로딩: 작업 요구사항에 따라 GPT-4, Gemini 등 제3자 모델 추가 호출
   * 실시간 피드백 루프: 오류 발생 시 자동 재계획 알고리즘 가동
   * 크로스 모달 퓨전: 텍스트-이미지 결합 분석을 위한 어텐션 메커니즘 적용
 * 혁신적인 기능
   * 비동기 처리: Celery 작업규 + Redis 캐시 - 오픈라인 작업 지속 가능
   * 메모리 시스템: 벡터 데이터베이스 기반 장기 기억 - 사용자 패턴 학습 최적화
   * 보안 프레임워크: 샌드박스 가상머신 격리 - 외부시스템 영향 제거
 * 외부 도구 통합: 웹 브라우저, 데이터베이스, 코드 편집기 등 다양한 소프트웨어와 통합
 * 클라우드 기반 운영: 비동기적 클라우드 처리를 지원하여 효율적인 작업 수행 가능

🍏 성능
 * Meta AI와 Hugging Face가 개발한 GAIA 테스트에서 OpenAI GPT-4o 대비 18% or 23% 높은 정확도

🍏 단점 및 한계
 * 초기 오류 빈도: 무한 루프 발생, 오류 메시지 출력 등 초기 사용자 경험에서 문제 보고
 * 사실 정확성 부족: 정보 누락 또는 부정확한 데이터 제공 사례 존재
 * API 의존성: API가 없는 애플리케이션과의 호환성이 제한적
 * 복제 가능성: 자체 모델 개발보다는 통합에 의존하기 때문에 경쟁사에 의해 복제될 위험

🍏 비즈니스 가능성
 * 기업용 솔루션: B2B 공급업체 발굴, 재무 보고서 분석 등
 * 개인 비서 역할: 여행 계획, 보험 비교, 교육 과정 개발 등
 * 자동화된 업무 처리: 온라인 스토어 운영 분석, 채용 인터뷰 준비 등

🍏 미래 전망
 * 오픈소스화 계획: Monica는 2025년 말까지 Manus AI를 오픈소스로 공개할 계획
 * 확장성: 개발자들이 맞춤형 플러그인을 구축하거나 틈새 응용 프로그램에 최적화할 수 있는 가능성 제공

최근 DeepSeek에 이어 중국발 AI에이전트 돌풍(?)을 일으키고 있는 마누스(Manus) AI 내용을 정리해봅니다. 🍏 Manus AI 개요<ul><li>개발사: 중국 스타트업 Monica</li><li>출시: 2025년 3월 6일</li><li>기반 모델: Anthropic의 Claude 3.5 Sonnet과 Alibaba의 Qwen 모델 기반</li><li>특징<ul><li>세계 최초의 범용 자율 AI 에이전트</li><li>OpenAI Deep Research, Gemini Deep Research 등에서 볼 수 있는 딥 리서치 기능을 구현한 멀티 에이전트 협업 시스템</li><li>기존의 챗봇이나 AI 모델과 달리, Manus는 단순한 답변 제공을 넘어 실제 결과물을 도출하는 데 초점</li><li>계획, 실행, 검증을 담당하는 별도의 에이전트들로 구성된 멀티 에이전트 아키텍처</li><li>대규모 작업을 수백개의 실행 가능한 하위 작업으로 나누는 동적 타겟 분해 기능</li><li>여러 유형의 데이터를 동시에 처리하는 교차 모달 추론 기능</li><li>강화학습을 통한 의사결정 효율성 지속적인 개선 및 오류율 최소화</li><li>지시를 기다리지 않고 스스로 작업을 시작하고 새로운 정보를 평가하며 접근 방식으로 동적으로 조정하는 자기주도적 작업 수행</li></ul></li></ul> 🍏 기술적 특징<ul><li>멀티 에이전트 아키텍처<ul><li>계획 에이전트(Planning Agent)<ul><li>작업 분석 및 단계별 계획 수립</li><li>사용자 요청을 PDCA(Plan-Do-Check-Act) 사이클로 분해</li><li>Monte Carlo Tree Search(MCTS) 알고리즘 활용</li><li>Anthropic Qwen 모델 기반의 텍스트 분석 및 전략 세분화</li></ul></li><li>실행 에이전트(Execution Agent)<ul><li>웹 브라우저/데이터베이스 등 27개 외부 도구와 실시간 연동</li><li>Claude 3.5 Sonnet 모델을 주력으로 사용</li><li>비동기적 클라우드 처리 아키텍처 지원</li></ul></li><li>검증 에이전트(Validation Agent)<ul><li>결과 검증 및 최적화</li><li>3단계 검증 프로세스: 형식 검증 (표 구조/코드 문법), 내용 검증 (사실 관계 확인, 컨텍스트 검증 (사용자 의도 부합 여부)</li></ul></li></ul></li><li>성능 향상 메커니즘<ul><li>동적 모델 로딩: 작업 요구사항에 따라 GPT-4, Gemini 등 제3자 모델 추가 호출</li><li>실시간 피드백 루프: 오류 발생 시 자동 재계획 알고리즘 가동</li><li>크로스 모달 퓨전: 텍스트-이미지 결합 분석을 위한 어텐션 메커니즘 적용</li></ul></li><li>혁신적인 기능<ul><li>비동기 처리: Celery 작업규 + Redis 캐시 - 오픈라인 작업 지속 가능</li><li>메모리 시스템: 벡터 데이터베이스 기반 장기 기억 - 사용자 패턴 학습 최적화</li><li>보안 프레임워크: 샌드박스 가상머신 격리 - 외부시스템 영향 제거</li></ul></li><li>외부 도구 통합: 웹 브라우저, 데이터베이스, 코드 편집기 등 다양한 소프트웨어와 통합</li><li>클라우드 기반 운영: 비동기적 클라우드 처리를 지원하여 효율적인 작업 수행 가능</li></ul> 🍏 성능<ul><li>Meta AI와 Hugging Face가 개발한 GAIA 테스트에서 OpenAI GPT-4o 대비 18% or 23% 높은 정확도</li></ul> 🍏 단점 및 한계<ul><li>초기 오류 빈도: 무한 루프 발생, 오류 메시지 출력 등 초기 사용자 경험에서 문제 보고</li><li>사실 정확성 부족: 정보 누락 또는 부정확한 데이터 제공 사례 존재</li><li>API 의존성: API가 없는 애플리케이션과의 호환성이 제한적</li><li>복제 가능성: 자체 모델 개발보다는 통합에 의존하기 때문에 경쟁사에 의해 복제될 위험</li></ul> 🍏 비즈니스 가능성<ul><li>기업용 솔루션: B2B 공급업체 발굴, 재무 보고서 분석 등</li><li>개인 비서 역할: 여행 계획, 보험 비교, 교육 과정 개발 등</li><li>자동화된 업무 처리: 온라인 스토어 운영 분석, 채용 인터뷰 준비 등</li></ul> 🍏 미래 전망<ul><li>오픈소스화 계획: Monica는 2025년 말까지 Manus AI를 오픈소스로 공개할 계획</li><li>확장성: 개발자들이 맞춤형 플러그인을 구축하거나 틈새 응용 프로그램에 최적화할 수 있는 가능성 제공</li></ul>

마누스(Manus) AI

우디의 컨설팅:  합격으로 가는 3가지 차별점 회사별 맞춤 포트폴리오,  합격을 부르는 비결입니다. 5회 코칭 진행 
 핀테크 프로덕트 디자이너로 최종 합격한 김** 님의 실제 리뷰입니다.  2회 코칭 진행 
 핀테크 프로덕트 디자이너로 최종 합격한 **호 님의 실제 리뷰입니다.  2회 코칭 진행 
 에이전시 → 스타트업 디자이너로 이직 성공한 **수 님의

[🚨3월·소수 정예!] 유니콘·빅테크 합격한 UX/UI 포트폴리오 컨설팅 - PO·디자인 리드 우디 - 우디디자인랩

Q) 🧑‍💻 평소 업무나 협업 시, 본인의 커뮤니케이션 스타일은 어떤 편인가요? (우디)

A) 🙋‍♀️ 저는 상대방이 궁금해하거나 필요로 할 수 있는 정보를 구체적으로 전달하려는 편이에요. 가령 프로젝트를 진행할 때도, “이건 왜 필요한가” “어떤 방식으로 진행될 것인가” 같은 구체적인 맥락을 먼저 짚어요. 특히 추가 설명이 필요할 것 같은 부분은 상세하게 적어서 미리 공유하고, 혹시 오해가 생기지 않도록 직접 확인하려고 노력합니다. 제가 조금 더 신경을 써야 의사소통 과정에서 불필요한 혼란을 줄일 수 있다고 생각해요. (5년차 UX/UI 디자이너분)

* 저맥락 커뮤니케이션을 통해 오해를 줄이는 커뮤니케이션 스타일이 느껴져 좋았습니다.

Q) 🧑‍💻 평소 업무나 협업 시, 본인의 커뮤니케이션 스타일은 어떤 편인가요? (우디) A) 🙋‍♀️ 저는 상대방이 궁금해하거나 필요로 할 수 있는 정보를 구체적으로 전달하려는 편이에요. 가령 프로젝트를 진행할 때도, “이건 왜 필요한가” “어떤 방식으로 진행될 것인가” 같은 구체적인 맥락을 먼저 짚어요. 특히 추가 설명이 필요할 것 같은 부분은 상세하게 적어서 미리 공유하고, 혹시 오해가 생기지 않도록 직접 확인하려고 노력합니다. 제가 조금 더 신경을 써야 의사소통 과정에서 불필요한 혼란을 줄일 수 있다고 생각해요. (5년차 UX/UI 디자이너분) * 저맥락 커뮤니케이션을 통해 오해를 줄이는 커뮤니케이션 스타일이 느껴져 좋았습니다.

기억에 남는 디자이너 면접 답변 [9]

오늘이 2024년 10월 5일이고 이 글을 처음 쓰기 시작한 게 2023년 8월 16일이니.. 글을 쓴 지 1년이 넘어버렸다. 관리자에 대한 내 생각이 정리가 되지 않아서 썼다 지웠다를 수도 없이 반복했다. 그 사이 아이도 출산하고 조직도 변경되고 많은 일이 있었다. 이 글을 더 이상 끌 수 없기에 아직도 정리되지 않은 부분은 모두 덜어내고 글을 마무리한다.  이 글은 개발자인 내가 왜 목적조직의 팀장을 하게 되었는지, 팀장은 어땠는지, 왜 그만두었지를 기록한 주관적인 경험기이다. 관리자가 되면 개발에서 멀어진다고 오래 전부터, 아마 처음 개발을 시작한 때부터 들어왔던 것 같다. 내가 목격한 몇몇의 개발자들도 관리자가 된 후 이전과는 다른 모습이 되었었다. 관리자가 되지 않고도 오래 개발을 하는 사람들..

개발자의 목적조직 팀장 경험

실무자로 일하다가 관리자가 되면서 갖게 되는 고민 중 하나는 실무 전문성에서부터 멀어진다는 점일 것 같은데요. 개발자와 TL로 일하던 저자가 목적조직의 리더가 되면서 고민했던 지점과 어려웠던 점들을 재미있는 시선으로 정리한 글입니다. 글 중간에 나오는 업무 영역에 대한 그림은 굉장히 독창적이고 인상적이었어요. 리더로서의 커리어를 쌓고 계시는 분들, 혹은 언젠가 관리자로 일하는 것에 대해 생각해보신 분들은 많은 참고가 될 것 같네요.

실무자로 일하다가 관리자가 되면서 갖게 되는 고민 중 하나는 실무 전문성에서부터 멀어진다는 점일 것 같은데요. 개발자와 TL로 일하던 저자가 목적조직의 리더가 되면서 고민했던 지점과 어려웠던 점들을 재미있는 시선으로 정리한 글입니다. 글 중간에 나오는 업무 영역에 대한 그림은 굉장히 독창적이고 인상적이었어요. 리더로서의 커리어를 쌓고 계시는 분들, 혹은 언젠가 관리자로 일하는 것에 대해 생각해보신 분들은 많은 참고가 될 것 같네요.

kingbbode

백엔드 엔지니어

운영팀 매니저

심건호

성장하고 싶어서 스타트업에 반걸음 내딛게 되었고
로앤굿에 합류해 세일즈➡운영 업무로 전환 후 빠르게 달려가고 있습니다.

제 나름의 방향과 속도로 성장하고 싶습니다. 
사람에게 관심을 갖고
솔직함과 공감을 바탕으로 경청하고자 합니다.
#끊임없이배우기 #문제를해결하는

[개발자의 목적조직 팀장 경험]

여행 스타트업 마이리얼트립의 Growth Lead로, 데이터 분석과 마케팅을 담당하고 있습니다. 데이터를 통해 서비스와 비즈니스가 마주한 문제를 해결하는 일에 관심이 많습니다. <그로스 해킹>이라는 책을 썼습니다.

양승화

딜라이트룸 Data Lead입니다. 데이터를 통해 서비스와 비즈니스가 마주한 문제를 해결하는 일에 관심이 많습니다. <그로스 해킹>이라는 책을 썼습니다.

https://bit.ly/leoyang6

[개발자의 목적조직 팀장 경험]

댓글 0

비슷한 게시물

주간 인기 TOP 10