And by "all," I mean everything: core product, failed pivots, miscellaneous

After 3 Years, I Failed. Here's All My Startup's Code. | Dylan Huang

스타트업을 시작하는 것은 많은 개발자들의 꿈이지만, 현실은 항상 녹록지 않습니다. 최근 3년간 API 통합을 간소화하는 개발 도구를 개발한 스타트업 'Konfig'의 창업자 Dylan Huang이 자신의 경험을 공유하며, 실패의 과정을 상세히 기록했습니다. 그는 자신들의 코드베이스를 모두 공개하며, 다른 개발자들에게 도움이 되기를 바라고 있습니다.

 * 스타트업 배경: Konfig는 2022년 말에 시작된 개발 도구 스타트업으로, API 통합을 쉽게 만드는 것을 목표로 했다.
 * 주요 제품:
   * SDK 생성기: OpenAPI 사양을 기반으로 다양한 프로그래밍 언어의 고품질 클라이언트 라이브러리를 생성하는 도구.
   * 문서화 도구: Markdown 및 OpenAPI 기반의 문서 생성.
   * API 데모: Markdown 기반의 Jupyter 노트북 형태로 제공.
   * 공개 API용 SDK: 다양한 공개 API에 대한 SDK 제공.
 * 기타 개발 항목:
   * 콜드 아웃바운드 메시지 생성을 위한 쉘 스크립트.
   * 프로그램적 SEO 스크립팅.
   * 마케팅 웹사이트 및 제품 문서화.
   * 커스텀 모노레포 설정을 지원하는 Changeset Bot 수정.
   * Earthly를 사용한 SDK 생성기 통합 테스트.
   * AI 피벗 실험 및 Notion 데이터베이스 통합.

실패의 원인과 배운 점
 * 시장 적합성 부족: 일부 스타트업과의 협업에도 불구하고, 하이퍼 성장 비즈니스를 구축하는 데 어려움을 겪음.
 * 가격 책정 문제: ROI가 명확함에도 불구하고, 잠재 고객과의 계약 체결이 어려웠으며, 가격이 너무 낮게 책정됨.
 * AI 제품으로의 피벗 실패: 생성형 AI를 활용한 B2B SaaS AI 제품으로 전환을 시도했지만, 충분한 시장 반응을 얻지 못함.

여러분이 스타트업을 시작하거나 새로운 프로젝트를 진행할 때, 시장의 요구와 제품의 적합성을 어떻게 평가하시나요? 실패를 통해 얻은 교훈을 다음 도전에 어떻게 적용할 수 있을까요?

https://dylanhuang.com/blog/closing-my-startup

스타트업을 시작하는 것은 많은 개발자들의 꿈이지만, 현실은 항상 녹록지 않습니다. 최근 3년간 API 통합을 간소화하는 개발 도구를 개발한 스타트업 'Konfig'의 창업자 Dylan Huang이 자신의 경험을 공유하며, 실패의 과정을 상세히 기록했습니다. 그는 자신들의 코드베이스를 모두 공개하며, 다른 개발자들에게 도움이 되기를 바라고 있습니다. <ul ><li>스타트업 배경: Konfig는 2022년 말에 시작된 개발 도구 스타트업으로, API 통합을 쉽게 만드는 것을 목표로 했다.</li><li>주요 제품:<ul ><li>SDK 생성기: OpenAPI 사양을 기반으로 다양한 프로그래밍 언어의 고품질 클라이언트 라이브러리를 생성하는 도구.</li><li>문서화 도구: Markdown 및 OpenAPI 기반의 문서 생성.</li><li>API 데모: Markdown 기반의 Jupyter 노트북 형태로 제공.</li><li>공개 API용 SDK: 다양한 공개 API에 대한 SDK 제공.</li></ul></li><li>기타 개발 항목:<ul ><li>콜드 아웃바운드 메시지 생성을 위한 쉘 스크립트.</li><li>프로그램적 SEO 스크립팅.</li><li>마케팅 웹사이트 및 제품 문서화.</li><li>커스텀 모노레포 설정을 지원하는 Changeset Bot 수정.</li><li>Earthly를 사용한 SDK 생성기 통합 테스트.</li><li>AI 피벗 실험 및 Notion 데이터베이스 통합.</li></ul></li></ul> 실패의 원인과 배운 점<ul ><li>시장 적합성 부족: 일부 스타트업과의 협업에도 불구하고, 하이퍼 성장 비즈니스를 구축하는 데 어려움을 겪음.</li><li>가격 책정 문제: ROI가 명확함에도 불구하고, 잠재 고객과의 계약 체결이 어려웠으며, 가격이 너무 낮게 책정됨.</li><li>AI 제품으로의 피벗 실패: 생성형 AI를 활용한 B2B SaaS AI 제품으로 전환을 시도했지만, 충분한 시장 반응을 얻지 못함.</li></ul> 여러분이 스타트업을 시작하거나 새로운 프로젝트를 진행할 때, 시장의 요구와 제품의 적합성을 어떻게 평가하시나요? 실패를 통해 얻은 교훈을 다음 도전에 어떻게 적용할 수 있을까요? https://dylanhuang.com/blog/closing-my-startup

dylanhuang.com

스타트업 3년, 실패했지만 코드를 공개합니다

Do developers only care about higher salary? Is it more to motivation that just money? Read the article with insights from Matteo Baccan.

A Higher Salary Alone Is Not Enough to Motivate Change

높은 연봉이 매력적인 요소로 작용할 수 있지만, 그것만으로는 직업을 바꿀 동기부여가 충분하지 않다는 사실이 점점 더 많은 연구와 사례를 통해 밝혀지고 있습니다. 이 글에서는 개발자 채용 및 유지 관리에서 연봉 외의 요인이 얼마나 중요한지와, 이들 요인을 통해 동기를 강화할 수 있는 방법을 심도 있게 다룹니다.

변화를 주저하는 심리적 요인
 1. 안정성과 익숙함에 대한 집착
    * 사람들이 현재 직업에 머무르는 주요 이유 중 하나는 변화의 불확실성에 대한 두려움입니다.
    * 예를 들어, 자신이 새로운 직장에서 팀과의 관계를 잘 형성하지 못할 것을 걱정하거나, 업무 문화에 적응하지 못할 것을 우려할 수 있습니다.
 2. 위험 회피 성향
    * 높은 연봉을 제안받아도 현재 직장에서의 직업 안정성을 포기하기 어려워하는 경우가 많습니다.
    * 특히, 스타트업과 같은 불안정한 환경은 직업 안정성을 선호하는 사람들에게 큰 부담으로 다가옵니다.
 3. 역량에 대한 의심
    * 새롭게 요구되는 기술이나 도구에 대한 자신감 부족이 변화를 가로막습니다.
    * 개발자들이 최신 기술 트렌드에 뒤처지지 않으려는 스트레스를 받는 경우도 있습니다.

연봉 외에 개발자가 중요하게 생각하는 것
 1. 조직 문화
    * 개발자들은 단순히 좋은 급여가 아니라 건강하고 포용적인 조직 문화를 중시합니다.
    * 좋은 조직 문화는 심리적 안정감을 주고, 팀워크와 개인 성장을 촉진합니다.
 2. 성장과 학습 기회
    * 기술 스택의 현대화와 지속적인 학습 기회는 연봉보다 더 큰 동기를 부여할 수 있습니다.
    * 많은 개발자들은 최신 기술을 활용하고 혁신적인 프로젝트에 참여하는 기회를 중요하게 여깁니다.
 3. 유연한 근무 환경
    * 원격 근무, 하이브리드 근무, 유연한 스케줄 등은 연봉 이상의 가치를 제공합니다.
    * 특히 팬데믹 이후, 많은 개발자들은 일과 삶의 균형을 중요하게 생각합니다.
 4. 업무의 의의
    * 자신이 하는 일이 사회적으로 의미 있는 결과를 만들어내는지에 대한 관심이 증가하고 있습니다.
    * 예를 들어, 환경 문제를 해결하는 기술 개발 프로젝트나 비영리 단체와 협업하는 일은 개발자에게 깊은 동기를 제공합니다.

조직이 활용할 수 있는 동기부여 전략
 1. 개인의 가치를 인정
    * 직원들의 성과를 구체적으로 인정하고 칭찬하며, 회사 내에서의 가치를 느낄 수 있도록 돕습니다.
    * 예를 들어, 팀 미팅에서 특정 개발자의 성과를 강조하거나, 스포트라이트를 제공할 수 있습니다.
 2. 의미 있는 프로젝트 배정
    * 단순한 유지보수 작업이 아니라 창의적이고 혁신적인 프로젝트에 참여할 기회를 제공합니다.
    * 예를 들어, 조직 내 새로운 기술 도입 프로젝트를 주도하게 하는 방법이 있습니다.
 3. 지속적인 기술 개발 지원
    * 교육비 지원, 기술 세미나 참여, 온라인 강의 수강 기회를 제공하여, 개발자들이 지속적으로 배우고 성장할 수 있도록 돕습니다.
    * 이는 개발자가 회사에 남아 있고 싶게 만드는 중요한 요인입니다.
 4. 개인의 의견 존중
    * 프로젝트 방향이나 기술 선택에서 개발자들이 직접 참여하여 의견을 낼 기회를 주는 것도 효과적입니다.

https://www.codemotion.com/magazine/dev-life/a-higher-salary-alone-is-not-enough-to-motivate-change

높은 연봉이 매력적인 요소로 작용할 수 있지만, 그것만으로는 직업을 바꿀 동기부여가 충분하지 않다는 사실이 점점 더 많은 연구와 사례를 통해 밝혀지고 있습니다. 이 글에서는 개발자 채용 및 유지 관리에서 연봉 외의 요인이 얼마나 중요한지와, 이들 요인을 통해 동기를 강화할 수 있는 방법을 심도 있게 다룹니다. 변화를 주저하는 심리적 요인<ol ><li>안정성과 익숙함에 대한 집착<ul ><li>사람들이 현재 직업에 머무르는 주요 이유 중 하나는 변화의 불확실성에 대한 두려움입니다.</li><li>예를 들어, 자신이 새로운 직장에서 팀과의 관계를 잘 형성하지 못할 것을 걱정하거나, 업무 문화에 적응하지 못할 것을 우려할 수 있습니다.</li></ul></li><li>위험 회피 성향<ul ><li>높은 연봉을 제안받아도 현재 직장에서의 직업 안정성을 포기하기 어려워하는 경우가 많습니다.</li><li>특히, 스타트업과 같은 불안정한 환경은 직업 안정성을 선호하는 사람들에게 큰 부담으로 다가옵니다.</li></ul></li><li>역량에 대한 의심<ul ><li>새롭게 요구되는 기술이나 도구에 대한 자신감 부족이 변화를 가로막습니다.</li><li>개발자들이 최신 기술 트렌드에 뒤처지지 않으려는 스트레스를 받는 경우도 있습니다.</li></ul></li></ol> 연봉 외에 개발자가 중요하게 생각하는 것<ol ><li>조직 문화<ul ><li>개발자들은 단순히 좋은 급여가 아니라 건강하고 포용적인 조직 문화를 중시합니다.</li><li>좋은 조직 문화는 심리적 안정감을 주고, 팀워크와 개인 성장을 촉진합니다.</li></ul></li><li>성장과 학습 기회<ul ><li>기술 스택의 현대화와 지속적인 학습 기회는 연봉보다 더 큰 동기를 부여할 수 있습니다.</li><li>많은 개발자들은 최신 기술을 활용하고 혁신적인 프로젝트에 참여하는 기회를 중요하게 여깁니다.</li></ul></li><li>유연한 근무 환경<ul ><li>원격 근무, 하이브리드 근무, 유연한 스케줄 등은 연봉 이상의 가치를 제공합니다.</li><li>특히 팬데믹 이후, 많은 개발자들은 일과 삶의 균형을 중요하게 생각합니다.</li></ul></li><li>업무의 의의<ul ><li>자신이 하는 일이 사회적으로 의미 있는 결과를 만들어내는지에 대한 관심이 증가하고 있습니다.</li><li>예를 들어, 환경 문제를 해결하는 기술 개발 프로젝트나 비영리 단체와 협업하는 일은 개발자에게 깊은 동기를 제공합니다.</li></ul></li></ol> 조직이 활용할 수 있는 동기부여 전략<ol ><li>개인의 가치를 인정<ul ><li>직원들의 성과를 구체적으로 인정하고 칭찬하며, 회사 내에서의 가치를 느낄 수 있도록 돕습니다.</li><li>예를 들어, 팀 미팅에서 특정 개발자의 성과를 강조하거나, 스포트라이트를 제공할 수 있습니다.</li></ul></li><li>의미 있는 프로젝트 배정<ul ><li>단순한 유지보수 작업이 아니라 창의적이고 혁신적인 프로젝트에 참여할 기회를 제공합니다.</li><li>예를 들어, 조직 내 새로운 기술 도입 프로젝트를 주도하게 하는 방법이 있습니다.</li></ul></li><li>지속적인 기술 개발 지원<ul ><li>교육비 지원, 기술 세미나 참여, 온라인 강의 수강 기회를 제공하여, 개발자들이 지속적으로 배우고 성장할 수 있도록 돕습니다.</li><li>이는 개발자가 회사에 남아 있고 싶게 만드는 중요한 요인입니다.</li></ul></li><li>개인의 의견 존중<ul ><li>프로젝트 방향이나 기술 선택에서 개발자들이 직접 참여하여 의견을 낼 기회를 주는 것도 효과적입니다.</li></ul></li></ol> https://www.codemotion.com/magazine/dev-life/a-higher-salary-alone-is-not-enough-to-motivate-change

Codemotion Magazine

높은 연봉 만이 다가 아니다

My name is Idan Koch, I’ve been working in high tech in various roles for over 2 decades. During this period I had the great pleasure of…

The ultimate checklist to becoming a development team leader

개발 팀 리더로 성장하기 위해서는 단순한 기술적 지식을 넘어 다양한 역량들이 필요할텐데요. 팀의 성과와 조직의 목표를 동시에 이끄는 책임을 지며, 팀원들에게 방향성을 제시하고, 협력을 조율하며, 기술적 해결책을 제안하는 다각적 역할을 맡게됩니다. 구체적으로 어떠한 역량과 전문성을 키워야 하는지 , 그리고 어떻게 실천해 수 있는지 알아봅니다.

1. 기술적 전문성
 * 팀원들에게 신뢰를 주고, 기술적인 논의에서 중심 역할을 하기 위해 여전히 손을 더럽히며 코딩할 줄 알아야 합니다.
 * 최신 기술 트렌드와 도구를 학습하고, 이를 실무에 적용해 팀의 생산성을 높일 방법을 모색합니다.
 * 실천 방안: 매주 시간을 정해 기술 블로그나 논문을 읽고, 간단한 프로젝트를 통해 학습한 내용을 실습합니다.
2. 효과적인 커뮤니케이션
 * 팀원들과 클라이언트, 그리고 이해관계자들 간의 요구를 명확히 전달하는 능력이 필수적입니다.
 * 경청과 공감을 통해 팀원들의 의견을 수용하고, 문제를 함께 해결하려는 태도를 보여야 합니다.
 * 실천 방안: 정기적으로 1:1 미팅을 가지며, 팀원들의 어려움과 의견을 경청하고 해결 방안을 논의합니다.
3. 프로젝트 관리
 * 작업 우선순위 설정, 타임라인 관리, 그리고 팀 리소스를 최적화하는 것은 프로젝트 성공의 핵심입니다.
 * 위험 요소를 사전에 식별하고 이를 완화하는 전략을 구사해야 합니다.
 * 실천 방안: Jira, Trello 같은 툴을 활용하여 작업 상태를 가시화하고, 매주 팀과 함께 진행 상황을 리뷰합니다.
4. 조직 문화 구축
 * 팀의 협력적이고 긍정적인 문화를 조성하고, 각 팀원이 자신의 역할에 자부심을 가질 수 있도록 환경을 만들어야 합니다.
 * 실패를 학습의 기회로 삼고, 팀원들이 새로운 도전을 두려워하지 않게 지원합니다.
 * 실천 방안: 팀 빌딩 이벤트나 스프린트 종료 후 회고(Retrospective)를 통해 협력과 피드백 문화를 강화합니다.
5. 문제 해결 및 의사 결정
 * 팀의 진행을 방해하는 장애물을 제거하고, 명확하고 근거에 기반한 의사결정을 내려야 합니다.
 * 문제의 핵심을 빠르게 파악하고, 팀원들이 해결 과정에 참여할 수 있도록 독려합니다.
 * 실천 방안: 문제 발생 시 팀원들에게 원인 분석과 해결 방안을 제안하도록 요청하고, 이를 협력적으로 평가합니다.
6. 멘토링 및 코칭
 * 팀원의 성장을 지원하는 것은 팀 리더의 중요한 역할입니다. 팀원이 직면한 기술적 또는 심리적 장애물을 극복하도록 돕는 것이 중요합니다.
 * 동료의 성과를 인정하고, 개인별 경력 목표를 설정할 수 있도록 지원합니다.
 * 실천 방안: 매 분기 개인별 피드백 세션을 통해, 성과를 논의하고 성장 기회를 제공합니다.
7. 자기 개발
 * 리더는 팀에게 모범이 되어야 하며, 스스로도 성장에 대한 열정을 보여야 합니다.
 * 자신의 약점에 대해 정직하며, 이를 개선하기 위한 지속적인 노력이 필요합니다.
 * 실천 방안: 전문 서적이나 리더십 워크샵에 참여하며, 자신에게 부족한 부분을 보완합니다.

팀 리더로서 직면할 수 있는 도전과 해결 방안
 1. 팀 내 갈등 해결
    * 도전: 팀원들 간의 의견 충돌이나 불만은 생산성을 저하시킬 수 있습니다.
    * 해결: 중립적 입장에서 경청하고, 객관적 근거를 바탕으로 갈등의 원인을 분석하여 조율합니다.
 2. 성과와 팀 사기 관리
    * 도전: 장기 프로젝트에서는 팀원이 동기를 잃기 쉽습니다.
    * 해결: 중간 목표를 설정하고, 이를 달성했을 때 팀원들을 공개적으로 칭찬하며 성취감을 강화합니다.
 3. 높은 기대와 리더십 압박
    * 도전: 팀의 모든 책임이 리더에게 집중될 때 압박을 느낄 수 있습니다.
    * 해결: 신뢰를 바탕으로 팀원들에게 업무를 위임하며, 스스로 모든 문제를 해결하려는 태도를 지양합니다.

https://medium.com/@idankoch_32247/the-ultimate-checklist-to-becoming-a-development-team-leader-77faf921208d

개발 팀 리더로 성장하기 위해서는 단순한 기술적 지식을 넘어 다양한 역량들이 필요할텐데요. 팀의 성과와 조직의 목표를 동시에 이끄는 책임을 지며, 팀원들에게 방향성을 제시하고, 협력을 조율하며, 기술적 해결책을 제안하는 다각적 역할을 맡게됩니다. 구체적으로 어떠한 역량과 전문성을 키워야 하는지 , 그리고 어떻게 실천해 수 있는지 알아봅니다. 1. 기술적 전문성<ul ><li>팀원들에게 신뢰를 주고, 기술적인 논의에서 중심 역할을 하기 위해 여전히 손을 더럽히며 코딩할 줄 알아야 합니다.</li><li>최신 기술 트렌드와 도구를 학습하고, 이를 실무에 적용해 팀의 생산성을 높일 방법을 모색합니다.</li><li>실천 방안: 매주 시간을 정해 기술 블로그나 논문을 읽고, 간단한 프로젝트를 통해 학습한 내용을 실습합니다.</li></ul>2. 효과적인 커뮤니케이션<ul ><li>팀원들과 클라이언트, 그리고 이해관계자들 간의 요구를 명확히 전달하는 능력이 필수적입니다.</li><li>경청과 공감을 통해 팀원들의 의견을 수용하고, 문제를 함께 해결하려는 태도를 보여야 합니다.</li><li>실천 방안: 정기적으로 1:1 미팅을 가지며, 팀원들의 어려움과 의견을 경청하고 해결 방안을 논의합니다.</li></ul>3. 프로젝트 관리<ul ><li>작업 우선순위 설정, 타임라인 관리, 그리고 팀 리소스를 최적화하는 것은 프로젝트 성공의 핵심입니다.</li><li>위험 요소를 사전에 식별하고 이를 완화하는 전략을 구사해야 합니다.</li><li>실천 방안: Jira, Trello 같은 툴을 활용하여 작업 상태를 가시화하고, 매주 팀과 함께 진행 상황을 리뷰합니다.</li></ul>4. 조직 문화 구축<ul ><li>팀의 협력적이고 긍정적인 문화를 조성하고, 각 팀원이 자신의 역할에 자부심을 가질 수 있도록 환경을 만들어야 합니다.</li><li>실패를 학습의 기회로 삼고, 팀원들이 새로운 도전을 두려워하지 않게 지원합니다.</li><li>실천 방안: 팀 빌딩 이벤트나 스프린트 종료 후 회고(Retrospective)를 통해 협력과 피드백 문화를 강화합니다.</li></ul>5. 문제 해결 및 의사 결정<ul ><li>팀의 진행을 방해하는 장애물을 제거하고, 명확하고 근거에 기반한 의사결정을 내려야 합니다.</li><li>문제의 핵심을 빠르게 파악하고, 팀원들이 해결 과정에 참여할 수 있도록 독려합니다.</li><li>실천 방안: 문제 발생 시 팀원들에게 원인 분석과 해결 방안을 제안하도록 요청하고, 이를 협력적으로 평가합니다.</li></ul>6. 멘토링 및 코칭<ul ><li>팀원의 성장을 지원하는 것은 팀 리더의 중요한 역할입니다. 팀원이 직면한 기술적 또는 심리적 장애물을 극복하도록 돕는 것이 중요합니다.</li><li>동료의 성과를 인정하고, 개인별 경력 목표를 설정할 수 있도록 지원합니다.</li><li>실천 방안: 매 분기 개인별 피드백 세션을 통해, 성과를 논의하고 성장 기회를 제공합니다.</li></ul>7. 자기 개발<ul ><li>리더는 팀에게 모범이 되어야 하며, 스스로도 성장에 대한 열정을 보여야 합니다.</li><li>자신의 약점에 대해 정직하며, 이를 개선하기 위한 지속적인 노력이 필요합니다.</li><li>실천 방안: 전문 서적이나 리더십 워크샵에 참여하며, 자신에게 부족한 부분을 보완합니다.</li></ul> 팀 리더로서 직면할 수 있는 도전과 해결 방안<ol ><li>팀 내 갈등 해결<ul ><li>도전: 팀원들 간의 의견 충돌이나 불만은 생산성을 저하시킬 수 있습니다.</li><li>해결: 중립적 입장에서 경청하고, 객관적 근거를 바탕으로 갈등의 원인을 분석하여 조율합니다.</li></ul></li><li>성과와 팀 사기 관리<ul ><li>도전: 장기 프로젝트에서는 팀원이 동기를 잃기 쉽습니다.</li><li>해결: 중간 목표를 설정하고, 이를 달성했을 때 팀원들을 공개적으로 칭찬하며 성취감을 강화합니다.</li></ul></li><li>높은 기대와 리더십 압박<ul ><li>도전: 팀의 모든 책임이 리더에게 집중될 때 압박을 느낄 수 있습니다.</li><li>해결: 신뢰를 바탕으로 팀원들에게 업무를 위임하며, 스스로 모든 문제를 해결하려는 태도를 지양합니다.</li></ul></li></ol> https://medium.com/@idankoch_32247/the-ultimate-checklist-to-becoming-a-development-team-leader-77faf921208d

Medium

개발팀 리더가 되기 위한 체크리스트

YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

로그는 애플리케이션의 문제를 파악하고 해결하는 데 필수적입니다. 하지만 비효율적이고 구조화되지 않은 로깅은 문제를 더 복잡하게 만들 수 있습니다. 이 영상에서는 효율적이고 효과적인 로깅을 위한 12가지 베스트 프랙티스를 다룹니다.

 1.  목표를 가진 로깅
     * 무작위로 로그를 남기기보다는, 애플리케이션의 목표, 중요 작업, KPI를 기준으로 로그를 작성해야 합니다.
     * 예: 단순히 "에러 발생"이 아닌, 충분한 컨텍스트를 포함한 메시지를 남깁니다.
 2.  로깅 레벨 사용
     * Info: 일반적인 상태(성공적인 로그인, 트랜잭션 완료).
     * Warning: 경고 상태(지연된 프로세스).
     * Error: 주요 문제(데이터베이스 연결 실패).
     * Fatal: 치명적인 문제(시스템 다운).
 3.  구조화된 로깅
     * 단순 텍스트 로그 대신 JSON 형식과 같은 구조화된 형식을 사용합니다.
     * 구조화된 로그는 검색, 필터링, 분석에 더 효과적입니다.
 4.  유용한 정보 포함
     * 로그에는 누가, 무엇을, 어디서, 왜를 포함합니다.
     * 예: 사용자 ID, 요청 ID, 시스템 상태, 에러 스택 트레이스.
 5.  로그 샘플링
     * 높은 트래픽 시스템에서는 모든 로그를 저장하지 말고 샘플링을 통해 비용을 절감합니다.
     * 예: 성공 로그는 20%만 저장하고, 에러 로그는 모두 저장.
 6.  Canonical 로그라인 사용
     * 단일 로그에 모든 주요 정보를 요약하여 기록합니다.
     * 예: 요청 시작부터 종료까지의 흐름을 한 줄로 요약.
 7.  중앙집중형 로깅
     * 로그를 한 곳으로 집계하여, 여러 서비스의 로그를 한눈에 볼 수 있도록 설정합니다.
     * 문제의 상호 영향을 빠르게 파악 가능.
 8.  로그 보존 정책 설정
     * 최근 로그는 빠르게 접근할 수 있도록 유지하고, 오래된 로그는 저비용 스토리지로 이전합니다.
     * 예: 디버그 로그는 7일, 에러 로그는 90일, 보안 로그는 1년 보관.
 9.  보안 유지
     * 로그에는 민감한 정보(비밀번호, 신용카드 번호 등)를 남기지 않도록 필터링과 암호화를 적용합니다.
     * 암호화: 전송 중 및 저장 시.
     * 접근 제어: 권한에 따라 로그 접근 제한.
 10. 효율적인 로그 관리
 * 성능에 영향을 최소화하려면 효율적인 로깅 라이브러리 사용, 샘플링, 별도 디스크에 로그 저장 등을 고려합니다.
 * 예: 최신 로깅 도구를 사용해 성능 저하를 줄임.
 11. 로그와 메트릭 구분
 * 로그는 디버깅용, 메트릭은 실시간 모니터링용으로 사용합니다.
 * 메트릭을 통해 에러 발생 빈도를 파악하고 알림을 설정.
 12. 정기적 검토와 개선
 * 로그 전략은 고정적이지 않습니다. 애플리케이션과 팀의 변화에 따라 로깅 방식을 주기적으로 검토하고 개선해야 합니다.

https://www.youtube.com/watch?v=I2mWnh66Bkg

로그는 애플리케이션의 문제를 파악하고 해결하는 데 필수적입니다. 하지만 비효율적이고 구조화되지 않은 로깅은 문제를 더 복잡하게 만들 수 있습니다. 이 영상에서는 효율적이고 효과적인 로깅을 위한 12가지 베스트 프랙티스를 다룹니다. <ol ><li>목표를 가진 로깅<ul ><li>무작위로 로그를 남기기보다는, 애플리케이션의 목표, 중요 작업, KPI를 기준으로 로그를 작성해야 합니다.</li><li>예: 단순히 "에러 발생"이 아닌, 충분한 컨텍스트를 포함한 메시지를 남깁니다.</li></ul></li><li>로깅 레벨 사용<ul ><li>Info: 일반적인 상태(성공적인 로그인, 트랜잭션 완료).</li><li>Warning: 경고 상태(지연된 프로세스).</li><li>Error: 주요 문제(데이터베이스 연결 실패).</li><li>Fatal: 치명적인 문제(시스템 다운).</li></ul></li><li>구조화된 로깅<ul ><li>단순 텍스트 로그 대신 JSON 형식과 같은 구조화된 형식을 사용합니다.</li><li>구조화된 로그는 검색, 필터링, 분석에 더 효과적입니다.</li></ul></li><li>유용한 정보 포함<ul ><li>로그에는 누가, 무엇을, 어디서, 왜를 포함합니다.</li><li>예: 사용자 ID, 요청 ID, 시스템 상태, 에러 스택 트레이스.</li></ul></li><li>로그 샘플링<ul ><li>높은 트래픽 시스템에서는 모든 로그를 저장하지 말고 샘플링을 통해 비용을 절감합니다.</li><li>예: 성공 로그는 20%만 저장하고, 에러 로그는 모두 저장.</li></ul></li><li>Canonical 로그라인 사용<ul ><li>단일 로그에 모든 주요 정보를 요약하여 기록합니다.</li><li>예: 요청 시작부터 종료까지의 흐름을 한 줄로 요약.</li></ul></li><li>중앙집중형 로깅<ul ><li>로그를 한 곳으로 집계하여, 여러 서비스의 로그를 한눈에 볼 수 있도록 설정합니다.</li><li>문제의 상호 영향을 빠르게 파악 가능.</li></ul></li><li>로그 보존 정책 설정<ul ><li>최근 로그는 빠르게 접근할 수 있도록 유지하고, 오래된 로그는 저비용 스토리지로 이전합니다.</li><li>예: 디버그 로그는 7일, 에러 로그는 90일, 보안 로그는 1년 보관.</li></ul></li><li>보안 유지<ul ><li>로그에는 민감한 정보(비밀번호, 신용카드 번호 등)를 남기지 않도록 필터링과 암호화를 적용합니다.</li><li>암호화: 전송 중 및 저장 시.</li><li>접근 제어: 권한에 따라 로그 접근 제한.</li></ul></li><li>효율적인 로그 관리</li></ol><ul ><li>성능에 영향을 최소화하려면 효율적인 로깅 라이브러리 사용, 샘플링, 별도 디스크에 로그 저장 등을 고려합니다.</li><li>예: 최신 로깅 도구를 사용해 성능 저하를 줄임.</li></ul><ol start="11"><li>로그와 메트릭 구분</li></ol><ul ><li>로그는 디버깅용, 메트릭은 실시간 모니터링용으로 사용합니다.</li><li>메트릭을 통해 에러 발생 빈도를 파악하고 알림을 설정.</li></ul><ol start="12"><li>정기적 검토와 개선</li></ol><ul ><li>로그 전략은 고정적이지 않습니다. 애플리케이션과 팀의 변화에 따라 로깅 방식을 주기적으로 검토하고 개선해야 합니다.</li></ul> https://www.youtube.com/watch?v=I2mWnh66Bkg

www.youtube.com

12 Logging BEST Practices in 12 minutes

&lt; 핵심인재의 기준이 잘못정해져 있다?...&gt;핵심인재를 선정할 때 가장 잘...

스타트업에서 핵심인재는 떠나게 되어 있다.

조직문화나 스타트업 관련된 글을 찾아볼때면 심심치 않게 '핵심인재'에 대한 글들을 볼 수 있는데요. 개인적으로는 유독 '핵심인재' 관련된 글은 중복된 글이 많고 너무나 뻔한 글이기에 공감 한 적이 많이 없었는데 최근 유일하게 공감과 깨달음을 얻었던 글이라 공유드립니다.

핵심인재를 선정할 때 가장 잘못평가되는 척도
'히스토리'와 '업무독점' 에 대한 부분입니다.
이 선정 기준에는 C-level, 초기멤버, 오래 일한 사람들이 포함되는 경우가 많습니다.
물론 서비스에 대해 애정을 가지고 노래를 틀어주는 주크박스 급으로 툭툭 튀어나오는 사람이 있다면 핵심인재가 맞지만, 단순히 겉 핥기 식으로 히스토리를 꿰고 있다고 해서는 핵심인재라고 볼 수 없습니다.
그리고 정보를 독점하여 과식하는 사람 역시 잘 풀어 나가며 공유하는 사람이 아닌 이상에는 정보의 독식으로 정보를 차단하고 있기에 오히려 핵심인재라고 할 수 없습니다.

그럼 핵심인재의 기준은 ?
 * 아이디어에서 그치지 않고 그것을 실행해 성과를 만들어 내는 사람
 * 조직에 대해 건강한 네거티브 할 수 있는 사람
스타트업은 투자를 받을수록, 조직이 커질수록 자신들만의 영역을 생성하는데 이때부터 정치라는 것이 시작됩니다.
이 정치라는 것을 박살 내기 위해서는 실행해 성과를 만들어 내는 함양은 기본이고, 건강한 네거티브를 하는 사람은 정말 조직에 모든 융합을 이끌어 낼 수 있는 키맨으로서의 인재입니다.

핵심인재를 붙잡는 방법
 * 핵심인재가 하고 있는 일에 대해서 책임과 소명을 가지고 일할만큼의 전권을 가지고 있는가?
 * 성과를 냈을 때 핵심인재가 원하는 만큼의 보상을 타 업체보다 줄 수 있는가?
 * 회사의 성장 그리고 개인도 끊임없이 성장을 추구할 수 있는가?
 * 몰입할 수 있는 조직문화와 환경을 제공하고 있는가?

그럼에도 떠난다면 이유는 무엇인가?
'개별화'와 '비전 및 가치' 에 초점을 맞추지 못하고 있을 가능성이 큽니다.
끝없는 성장을 이야기하지만 '성장'이라는 단어에 전혀 부합하지 않는 일을 하고 있거나, 기업과 내가 성장이 멈춰있는 공간에서 일을하고 있다면 이탈할 수 밖에 없습니다.
'성장'과 '비전' 은 정말 끝없이 경영진이 고민하고 투여해 줘야만 사명감을 가지고 회사에 투여할 수 있습니다.

C-Level들이 간과하는 것
개발자를 제외한 나머지 인원은 무조건 대체가 가능하다고 생각하는 부분입니다. 특히 서비스 운영은 언제든지 대체할 수 있고 시장에도 널려있다고 생각하는데요. 서비스를 실질적으로 설계하는 사람도 중요하지만 이를 운영하여 효율적 관점을 전달해주는 '운영' 인원은 정말 중요한 인재라고 할 수 있습니다.
한명, 한명의 인재는 누구도 대체할 수 없으며, 그 인재는 회사에 발을 들이기 이전부터 회사에 많은 정보를 취득하고 준비를 통해 입사한 인원이라는 것을 명심해야 합니다.

스타트업이 망하는 이유는
BM 증명 불가와 자금부족인 경우도 있지만, 핵심인재의 이탈로부터 이어지는 경우도 허다합니다. 이탈은 조직의 파열음을 내고 회사의 성장을 더디게 할 수도 있으며 업계는 좁기에 핵심인재의 이탈의 소문은 회사의 이미지를 훼손해 추가 인재를 확보하는데 큰 어려움을 겪을 수 밖에 없습니다.
스타트업의 핵심은 늘 '인재'라고 생각하고, '어쩔 수 없지'가 아니라 무슨 짓을 해서라도 핵심인재라면 어떻게 해야 남길 수 있을지 고민하시길 바랍니다.

조직문화나 스타트업 관련된 글을 찾아볼때면 심심치 않게 '핵심인재'에 대한 글들을 볼 수 있는데요. 개인적으로는 유독 '핵심인재' 관련된 글은 중복된 글이 많고 너무나 뻔한 글이기에 공감 한 적이 많이 없었는데 최근 유일하게 공감과 깨달음을 얻었던 글이라 공유드립니다. 핵심인재를 선정할 때 가장 잘못평가되는 척도'히스토리'와 '업무독점' 에 대한 부분입니다. 이 선정 기준에는 C-level, 초기멤버, 오래 일한 사람들이 포함되는 경우가 많습니다.물론 서비스에 대해 애정을 가지고 노래를 틀어주는 주크박스 급으로 툭툭 튀어나오는 사람이 있다면 핵심인재가 맞지만, 단순히 겉 핥기 식으로 히스토리를 꿰고 있다고 해서는 핵심인재라고 볼 수 없습니다. 그리고 정보를 독점하여 과식하는 사람 역시 잘 풀어 나가며 공유하는 사람이 아닌 이상에는 정보의 독식으로 정보를 차단하고 있기에 오히려 핵심인재라고 할 수 없습니다. 그럼 핵심인재의 기준은 ?<ul ><li>아이디어에서 그치지 않고 그것을 실행해 성과를 만들어 내는 사람</li><li>조직에 대해 건강한 네거티브 할 수 있는 사람</li></ul>스타트업은 투자를 받을수록, 조직이 커질수록 자신들만의 영역을 생성하는데 이때부터 정치라는 것이 시작됩니다.이 정치라는 것을 박살 내기 위해서는 실행해 성과를 만들어 내는 함양은 기본이고, 건강한 네거티브를 하는 사람은 정말 조직에 모든 융합을 이끌어 낼 수 있는 키맨으로서의 인재입니다. 핵심인재를 붙잡는 방법<ul ><li>핵심인재가 하고 있는 일에 대해서 책임과 소명을 가지고 일할만큼의 전권을 가지고 있는가?</li><li>성과를 냈을 때 핵심인재가 원하는 만큼의 보상을 타 업체보다 줄 수 있는가?</li><li>회사의 성장 그리고 개인도 끊임없이 성장을 추구할 수 있는가?</li><li>몰입할 수 있는 조직문화와 환경을 제공하고 있는가?</li></ul> 그럼에도 떠난다면 이유는 무엇인가?'개별화'와 '비전 및 가치' 에 초점을 맞추지 못하고 있을 가능성이 큽니다. 끝없는 성장을 이야기하지만 '성장'이라는 단어에 전혀 부합하지 않는 일을 하고 있거나, 기업과 내가 성장이 멈춰있는 공간에서 일을하고 있다면 이탈할 수 밖에 없습니다.'성장'과 '비전' 은 정말 끝없이 경영진이 고민하고 투여해 줘야만 사명감을 가지고 회사에 투여할 수 있습니다. C-Level들이 간과하는 것개발자를 제외한 나머지 인원은 무조건 대체가 가능하다고 생각하는 부분입니다. 특히 서비스 운영은 언제든지 대체할 수 있고 시장에도 널려있다고 생각하는데요. 서비스를 실질적으로 설계하는 사람도 중요하지만 이를 운영하여 효율적 관점을 전달해주는 '운영' 인원은 정말 중요한 인재라고 할 수 있습니다.한명, 한명의 인재는 누구도 대체할 수 없으며, 그 인재는 회사에 발을 들이기 이전부터 회사에 많은 정보를 취득하고 준비를 통해 입사한 인원이라는 것을 명심해야 합니다. 스타트업이 망하는 이유는BM 증명 불가와 자금부족인 경우도 있지만, 핵심인재의 이탈로부터 이어지는 경우도 허다합니다. 이탈은 조직의 파열음을 내고 회사의 성장을 더디게 할 수도 있으며 업계는 좁기에 핵심인재의 이탈의 소문은 회사의 이미지를 훼손해 추가 인재를 확보하는데 큰 어려움을 겪을 수 밖에 없습니다.스타트업의 핵심은 늘 '인재'라고 생각하고, '어쩔 수 없지'가 아니라 무슨 짓을 해서라도 핵심인재라면 어떻게 해야 남길 수 있을지 고민하시길 바랍니다.

핵심인재의 기준은 잘못 정해져있다.

2024년도 끝나가네요. 매년 하던 것처럼 올해도 회고를 작성해봅니다 과거 회고 글 모음 데이터 사이언티스트가 되기 위해 진행한 다양한 노력들 2017년 회고, 2018년 계획 2018년 회고, 2019년 다짐 Gap Year 및 쏘카 이직 이야기 2019년 상반기 회고 및 글또 3기 시작 초보 개발 팀장의 1년 회고 - 좋은 팀장이 되기 위한...

2024년 회고 - 기억하고 싶은 것과 요즘 생각들

2024년도 이제 끝나가네요. 곧 2025년이 다가와요.

여러분들은 2024년을 어떻게 보내셨나요? 저는 2024년 회고 글을 작성했어요.
매년 회고를 하니까, 나의 기록을 저장할 수 있고 방향성을 설정할 수 있어 좋더라구요

여러분들도 회고 한번 해보시는 것을 추천드려요.

https://zzsza.github.io/diary/2024/12/28/2024-retrospective/

2024년도 이제 끝나가네요. 곧 2025년이 다가와요. 여러분들은 2024년을 어떻게 보내셨나요? 저는 2024년 회고 글을 작성했어요.매년 회고를 하니까, 나의 기록을 저장할 수 있고 방향성을 설정할 수 있어 좋더라구요 여러분들도 회고 한번 해보시는 것을 추천드려요. https://zzsza.github.io/diary/2024/12/28/2024-retrospective/

zzsza.github.io

2024년 회고

GitHub Pages를 통해 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 간편하게 웹사이트를 호스팅할 수 있습니다. 하지만 요즘 웹 개발에서 HTML, CSS, JavaScript를 직접 작성하는 일은 드물죠? 대부분 React와 같은 프론트엔드 라이브러리와 Vite와 같은 빌드 도구를 사용하여 HTML, CSS, JavaScript를 생성해낼 것입니다.

이번 시간에는 웹 프로젝트를 GitHub Actions를 사용하여 빌드하고, 빌드 결과물을 바로 GitHub Pages에 배포하는 방법에 대해서 알아보겠습니다.

📺 동영상: https://youtu.be/bGCIWIP_skg
📝 포스팅: https://www.daleseo.com/github-pages-actions/

GitHub Pages에 웹사이트를 호스팅하는 기본적인 방법은 아래 게시물을 참고바랍니다.

📕 GitHub Pages에 웹사이트 배포하기: https://careerly.co.kr/comments/115041
📗 GitHub Pages에 커스텀 도메인 연결하기: https://careerly.co.kr/comments/115256

GitHub Pages를 통해 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 간편하게 웹사이트를 호스팅할 수 있습니다. 하지만 요즘 웹 개발에서 HTML, CSS, JavaScript를 직접 작성하는 일은 드물죠? 대부분 React와 같은 프론트엔드 라이브러리와 Vite와 같은 빌드 도구를 사용하여 HTML, CSS, JavaScript를 생성해낼 것입니다. 이번 시간에는 웹 프로젝트를 GitHub Actions를 사용하여 빌드하고, 빌드 결과물을 바로 GitHub Pages에 배포하는 방법에 대해서 알아보겠습니다. 📺 동영상: https://youtu.be/bGCIWIP_skg📝 포스팅: https://www.daleseo.com/github-pages-actions/ GitHub Pages에 웹사이트를 호스팅하는 기본적인 방법은 아래 게시물을 참고바랍니다. 📕 GitHub Pages에 웹사이트 배포하기: https://careerly.co.kr/comments/115041📗 GitHub Pages에 커스텀 도메인 연결하기: https://careerly.co.kr/comments/115256

GitHub Actions로 빌드 후 GitHub Pages에 배포하기

유니코드의 정규화 방법 4가지의 차이점을 알고 이를 JavaScript에서 사용하는 방법에 대해 알아봅니다.

normalize 메서드를 이용해 유니코드 문자열 정규화하기 - 재그지그의 개발 블로그

- 유니코드의 정규화 방법 4가지의 차이점을 알고 이를 JavaScript에서 사용하는 방법에 대해 알아봅니다.

---

최근 회사 업무 중 국가 이름을 알파벳 첫 글자에 따라 그루핑하는 작업을 맡게 되었습니다. 단순히 알파벳 별로 국가들을 묶으면 되는 일이라 쉽게 생각했지만, 예상치 못한 난관에 부딪혔습니다. 그 이유는 바로 올란드 제도(Åland Islands) 때문이었습니다.

올란드 제도의 영어 이름은 알파벳 A 에 고리 모양의 기호 ˚ 가 결합 문자로 붙은 Å 로 시작하는 것이 그 이유였습니다. 기획에 따르면 올란드 제도는 알파벳 A 로 시작하는 국가들과 함께 그루핑 되어야 했습니다.

이 문제를 해결하기 위해 결합 문자가 포함된 문자열을 어떻게 처리해야 할지 고민하게 되었는데요.  다행히 ChatGPT의 도움을 받아 해결책을 얻을 수 있었습니다.

하지만 normalize 메서드를 직접 사용해 본 경험은 이번이 처음이라, 메서드 인자에 들어가는 값인  "NFD" 의 의미에 대해 정확히 이해하지 못한 채 사용하게 되었습니다. 그래서 이번 기회에 이 부분을 본격적으로 정리해보자는 생각이 들었고, 그 결과 이번 글을 작성하게 되었습니다.

https://wormwlrm.github.io/2024/12/30/String-Normalize.html

- 유니코드의 정규화 방법 4가지의 차이점을 알고 이를 JavaScript에서 사용하는 방법에 대해 알아봅니다. --- 최근 회사 업무 중 국가 이름을 알파벳 첫 글자에 따라 그루핑하는 작업을 맡게 되었습니다. 단순히 알파벳 별로 국가들을 묶으면 되는 일이라 쉽게 생각했지만, 예상치 못한 난관에 부딪혔습니다. 그 이유는 바로&nbsp;올란드 제도(Åland Islands)&nbsp;때문이었습니다. 올란드 제도의 영어 이름은 알파벳&nbsp;A&nbsp;에 고리 모양의&nbsp;기호 ˚&nbsp;가 결합 문자로 붙은&nbsp;Å&nbsp;로 시작하는 것이 그 이유였습니다. 기획에 따르면 올란드 제도는 알파벳&nbsp;A&nbsp;로 시작하는 국가들과 함께 그루핑 되어야 했습니다. 이 문제를 해결하기 위해 결합 문자가 포함된 문자열을 어떻게 처리해야 할지 고민하게 되었는데요.&nbsp; 다행히 ChatGPT의 도움을 받아 해결책을 얻을 수 있었습니다. 하지만&nbsp;normalize&nbsp;메서드를 직접 사용해 본 경험은 이번이 처음이라, 메서드 인자에 들어가는 값인&nbsp; "NFD"&nbsp;의 의미에 대해 정확히 이해하지 못한 채 사용하게 되었습니다. 그래서 이번 기회에 이 부분을 본격적으로 정리해보자는 생각이 들었고, 그 결과 이번 글을 작성하게 되었습니다. https://wormwlrm.github.io/2024/12/30/String-Normalize.html

재그지그의 개발 블로그

🔠 normalize 메서드를 이용해 유니코드 문자열 정규화하기

제주항공 여객기 참사로 인해 고통을 겪고 계신 유가족 여러분께 깊은 애도의 마음을 전합니다.

제주항공 여객기 참사로 인해 고통을 겪고 계신 유가족 여러분께 깊은 애도의 마음을 전합니다.

이번 연말 회고를 작성하기 전에 먼저 생각 한 번 정리해 볼 겸 이전에 작성했던 회고들을 한번씩 다 읽어봤습니다.

반성의 연말 회고

올 한해 마무리 하면서 회고를 또 작성해보았습니다.

보통 저는 프로젝트 회고, 이직 회고, 연말 회고를 작성할 때에는
"나 올해 이런 일들을 해봤고 이런 성과를 냈어, 내년엔 좀 더 잘해야지!" 를 기준으로 작성하는데,

올해는 돌이켜보니 반성 할 게 많은 한 해 였던 거 같아서
"나 올해 이런 일들을 해봤고 이런 성과를 냈지만, 이런 부분은 하지말았어야 했어" 에 대한 기준으로 회고를 해봤습니다.

올 한해 마무리 하면서 회고를 또 작성해보았습니다. 보통 저는 프로젝트 회고, 이직 회고, 연말 회고를 작성할 때에는 "나 올해 이런 일들을 해봤고 이런 성과를 냈어, 내년엔 좀 더 잘해야지!" 를 기준으로 작성하는데, 올해는 돌이켜보니 반성 할 게 많은 한 해 였던 거 같아서 "나 올해 이런 일들을 해봤고 이런 성과를 냈지만, 이런 부분은 하지말았어야 했어" 에 대한 기준으로 회고를 해봤습니다.

반성의 연말회고

한 유튜버의 면접자가 실제로 썼던 코드라네요ㅋㅋ 창의성으로 통과시켜주고 싶었으나 hiring committee에서 탈락시켰다고...
😵‍💫😵‍💫

한 유튜버의 면접자가 실제로 썼던 코드라네요ㅋㅋ 창의성으로 통과시켜주고 싶었으나 hiring committee에서 탈락시켰다고...😵‍💫😵‍💫

Sleep Sort를 아세요??

매년 이맘때면 연락이 와요. 회사는 어떤지, 하는 일은 마음에 드는지 안부를 묻죠. 헤드헌터예요.

이직 생각이 없더라도 헤드헌터와 알고 지내는 건 제법 괜찮은 선택이에요. '정보의 비대칭성'을 해소할 수 있으니까요.

구체적으론 세 가지 좋은 점이 있었어요.

1. 채용 시장의 분위기를 파악할 수 있어요
2. 서류 전형에 대한 부담이 낮아져요
3. 연봉 계약도 혼자 하는 것보단 유리해져요

여러분이 생각하는 헤드헌터를 알고 지내면 좋은 이유는 무엇인가요? 혹시 단점도 있었나요?

매년 이맘때면 연락이 와요. 회사는 어떤지, 하는 일은 마음에 드는지 안부를 묻죠. 헤드헌터예요. 이직 생각이 없더라도 헤드헌터와 알고 지내는 건 제법 괜찮은 선택이에요. '정보의 비대칭성'을 해소할 수 있으니까요. 구체적으론 세 가지 좋은 점이 있었어요. 1. 채용 시장의 분위기를 파악할 수 있어요2. 서류 전형에 대한 부담이 낮아져요3. 연봉 계약도 혼자 하는 것보단 유리해져요 여러분이 생각하는 헤드헌터를 알고 지내면 좋은 이유는 무엇인가요? 혹시 단점도 있었나요?&nbsp;

헤드헌터와 알고 지내면 좋은 점

저는 멘토링을 할 때 개발뿐만 아니라 문제 정의부터 시작해 기획, 커뮤니케이션, 팀 문화, PPT, 발표 등 사이드 프로젝트를 만드는데 도움을 줄 수 있는 전과정에 관한 피드백을 드립니다.

특히, 개발자분들만 모여 있는 경우 발표와 관련된 부분을 굉장히 어려워하는 것을 많이 봤습니다.
발표 자료 구성, 전달력 있는 말하기 방법, 톤, 말할 때의 습관 등 다양한 부분에 피드백을 드리는 것이 중요하다고 생각합니다.

오늘은 사이드 프로젝트 발표에서 PPT를 어떻게 구성하는지에 대한 피드백을 공유해보겠습니다.
기초적인 내용이 많지만, 실제로 도움을 드렸던 부분을 중심으로 정리해봤습니다.

---
1. 발표는 설득이 목적입니다

- 여러분은 프로젝트의 기능과 목적 등 모든 것을 이미 알고 있지만, 발표를 듣는 분들은 대부분 처음 프로젝트를 접하는 분들입니다.

- 따라서 발표 자료는 매우 친절하게 구성하고, 설득을 목적으로 만들어야 합니다.

- "왜 이 서비스를 만들었지?" "왜 해당 기능을 넣었을까?"와 같은 질문에 충분히 답할 수 있도록 자료를 준비하세요.

- 문제 정의 - 기획 소개 - 기능 소개 - 시연 - 마무리로 이어지는 흐름을 방해받지 않도록 구성하세요.

---
2. '3의 법칙'

- 문제 정의, 특징, 기능 등을 소개할 때 숫자 3을 기억하세요.

- 정보를 제시하거나 설득의 근거를 제시할 때 3개로 구성하면 효과적입니다.

- 1~2개의 경우 부족하다는 느낌을 주고, 4개 이상은 복잡하다는 인상을 줄 수 있습니다.

- 기획 및 컨설팅 업계에서는 숫자 3을 적음의 끝이자 많음의 시작이라고 표현합니다. (출처 - 시선의 발견)

- PPT에서도 숫자 3을 적절히 활용하세요.

---
3. 너무 많은 텍스트를 자료에 넣지 마세요

- 발표 자료는 발표자를 돕는 도구입니다.

- 발표 중 청중의 시선은 발표 자료가 아니라 발표자에게 머물러야 합니다.

- 하지만 PPT를 만드는 입장에서는 최대한 많은 정보를 담고 싶어 하죠.

- 이로 인해 가독성이 떨어지고, 청중이 장문의 텍스트를 읽느라 시선이 분산될 수 있습니다.

- PPT에는 중요하고 수치적인 텍스트만 간결하게 정리하고, 부연 설명은 발표자가 직접 하는 것이 좋습니다.

---
4. 최종 시연은 영상으로 진행하세요

- 시연 방법은 크게 두 가지가 있습니다.
1. 직접 웹이나 앱을 띄워놓고 시연하는 방법
2. 미리 녹화한 영상을 PPT에 삽입해 진행하는 방법

- 저는 필수가 아닌 이상 두 번째 방법을 추천합니다.

- 라이브 시연은 생생함과 어필력을 제공하지만, 시간 조절이 어렵고 실수의 가능성이 있으며, 발표 흐름이 끊길 수 있는 단점이 있습니다.

- 미리 녹화한 영상은 시간 활용이 정확하고 편집이 가능해 청중이 이해하기 쉽습니다.

- 때문에 가능하면 녹화된 시연 영상을 활용하시기를 권장합니다.

저는 멘토링을 할 때 개발뿐만 아니라 문제 정의부터 시작해 기획, 커뮤니케이션, 팀 문화, PPT, 발표 등 사이드 프로젝트를 만드는데 도움을 줄 수 있는 전과정에 관한 피드백을 드립니다. 특히, 개발자분들만 모여 있는 경우 발표와 관련된 부분을 굉장히 어려워하는 것을 많이 봤습니다.발표 자료 구성, 전달력 있는 말하기 방법, 톤, 말할 때의 습관 등 다양한 부분에 피드백을 드리는 것이 중요하다고 생각합니다. 오늘은 사이드 프로젝트 발표에서 PPT를 어떻게 구성하는지에 대한 피드백을 공유해보겠습니다.기초적인 내용이 많지만, 실제로 도움을 드렸던 부분을 중심으로 정리해봤습니다. ---1. 발표는 설득이 목적입니다 - 여러분은 프로젝트의 기능과 목적 등 모든 것을 이미 알고 있지만, 발표를 듣는 분들은 대부분 처음 프로젝트를 접하는 분들입니다. - 따라서 발표 자료는 매우 친절하게 구성하고, 설득을 목적으로 만들어야 합니다. - "왜 이 서비스를 만들었지?" "왜 해당 기능을 넣었을까?"와 같은 질문에 충분히 답할 수 있도록 자료를 준비하세요. - 문제 정의 - 기획 소개 - 기능 소개 - 시연 - 마무리로 이어지는 흐름을 방해받지 않도록 구성하세요. ---2. '3의 법칙' - 문제 정의, 특징, 기능 등을 소개할 때 숫자 3을 기억하세요. - 정보를 제시하거나 설득의 근거를 제시할 때 3개로 구성하면 효과적입니다. - 1~2개의 경우 부족하다는 느낌을 주고, 4개 이상은 복잡하다는 인상을 줄 수 있습니다. - 기획 및 컨설팅 업계에서는 숫자 3을 적음의 끝이자 많음의 시작이라고 표현합니다. (출처 - 시선의 발견) - PPT에서도 숫자 3을 적절히 활용하세요. ---3. 너무 많은 텍스트를 자료에 넣지 마세요 - 발표 자료는 발표자를 돕는 도구입니다. - 발표 중 청중의 시선은 발표 자료가 아니라 발표자에게 머물러야 합니다. - 하지만 PPT를 만드는 입장에서는 최대한 많은 정보를 담고 싶어 하죠. - 이로 인해 가독성이 떨어지고, 청중이 장문의 텍스트를 읽느라 시선이 분산될 수 있습니다. - PPT에는 중요하고 수치적인 텍스트만 간결하게 정리하고, 부연 설명은 발표자가 직접 하는 것이 좋습니다. ---4. 최종 시연은 영상으로 진행하세요 - 시연 방법은 크게 두 가지가 있습니다.1. 직접 웹이나 앱을 띄워놓고 시연하는 방법2. 미리 녹화한 영상을 PPT에 삽입해 진행하는 방법 - 저는 필수가 아닌 이상 두 번째 방법을 추천합니다. - 라이브 시연은 생생함과 어필력을 제공하지만, 시간 조절이 어렵고 실수의 가능성이 있으며, 발표 흐름이 끊길 수 있는 단점이 있습니다. - 미리 녹화한 영상은 시간 활용이 정확하고 편집이 가능해 청중이 이해하기 쉽습니다. - 때문에 가능하면 녹화된 시연 영상을 활용하시기를 권장합니다.

사이드 프로젝트 발표 피드백

최근 프론트엔드 개발에서 API 모킹의 중요성이 점점 커지고 있습니다. 서버 개발이 완료되지 않은 상태에서도 Mock 데이터를 이용해 프론트엔드 개발을 진행하고, 독립적인 테스트를 수행할 수 있기 때문인데요. 이와 관련하여, 개인적으로 우아한형제들이 개발한 MSG(Mock Service GUI)관련 소프트웨어를 관심있게 지켜보고 있습니다.

MSG(Mock Service GUI)란?
MSG는 기존의 모킹 방식처럼 코드를 수정하는 번거로움 없이, 브라우저에 표시되는 UI를 통해 모킹 데이터를 제어할 수 있는 도구입니다. MSW(Mock Service Worker)를 기반으로 개발되었으며, 브라우저 확장 프로그램이 아닌 프로젝트에 디펜던시로 설치해 사용합니다.

MSG의 주요 기능
 * UI 기반 제어: API 모킹 데이터를 코딩하지 않고 UI에서 직접 선택 및 수정할 수 있습니다. 이를 통해 API 응답 데이터를 실시간으로 변경하며 화면 전환 결과를 바로 확인할 수 있습니다.
 * 로컬스토리지 활용: 각자의 브라우저 로컬스토리지에 개인 맞춤형 API 모킹 설정을 저장하고 관리할 수 있습니다. 팀원 간 설정 충돌을 방지하며 작업 효율성을 높입니다.
 * 프로젝트 통합성: MSG는 API 모킹 데이터를 프로젝트 내 여러 API와 쉽게 매핑할 수 있어, 신규 프로젝트 셋업 시에도 빠르고 효과적으로 활용할 수 있습니다.
MSG의 활용 사례
 * 우아한형제들은 MSG를 주문, 결제, 회원 도메인 프로젝트에 적용했으며, 특히 배민클럽 구독 서비스 프로젝트에서는 초기 셋업부터 MSG를 적극적으로 활용해 다량의 모킹 데이터를 효율적으로 관리했습니다.
 * 최신 버전인 MSG 2.0은 기능이 더욱 강화되어, 팀 내 다양한 프로젝트에서 사용 사례가 점차 확대되고 있다고 합니다.

현재 MSG는 오픈소스 전환을 목표로 개발되고 있습니다. 만약 공개된다면, QA, 기획자, 개발자 모두가 실시간으로 데이터를 확인하고 테스트하면서 더욱 원활하고 신속한 협업이 가능해질 것으로 보입니다. 오픈소스로 공개된다면 안쓸 이유가 없어보이고 여러 부서와 팀에 긍정적인 변화를 가져올 것으로 보이는만큼 빨리 공개되었으면 좋겠네요 :)

https://www.youtube.com/watch?v=dDAfG4fe4do
https://techblog.woowahan.com/20154/

최근 프론트엔드 개발에서 API 모킹의 중요성이 점점 커지고 있습니다. 서버 개발이 완료되지 않은 상태에서도 Mock 데이터를 이용해 프론트엔드 개발을 진행하고, 독립적인 테스트를 수행할 수 있기 때문인데요. 이와 관련하여, 개인적으로 우아한형제들이 개발한 MSG(Mock Service GUI)관련 소프트웨어를 관심있게 지켜보고 있습니다. MSG(Mock Service GUI)란?MSG는 기존의 모킹 방식처럼 코드를 수정하는 번거로움 없이, 브라우저에 표시되는 UI를 통해 모킹 데이터를 제어할 수 있는 도구입니다. MSW(Mock Service Worker)를 기반으로 개발되었으며, 브라우저 확장 프로그램이 아닌 프로젝트에 디펜던시로 설치해 사용합니다. MSG의 주요 기능<ul ><li>UI 기반 제어: API 모킹 데이터를 코딩하지 않고 UI에서 직접 선택 및 수정할 수 있습니다. 이를 통해 API 응답 데이터를 실시간으로 변경하며 화면 전환 결과를 바로 확인할 수 있습니다.</li><li>로컬스토리지 활용: 각자의 브라우저 로컬스토리지에 개인 맞춤형 API 모킹 설정을 저장하고 관리할 수 있습니다. 팀원 간 설정 충돌을 방지하며 작업 효율성을 높입니다.</li><li>프로젝트 통합성: MSG는 API 모킹 데이터를 프로젝트 내 여러 API와 쉽게 매핑할 수 있어, 신규 프로젝트 셋업 시에도 빠르고 효과적으로 활용할 수 있습니다.</li></ul>MSG의 활용 사례<ul ><li>우아한형제들은 MSG를 주문, 결제, 회원 도메인 프로젝트에 적용했으며, 특히 배민클럽 구독 서비스 프로젝트에서는 초기 셋업부터 MSG를 적극적으로 활용해 다량의 모킹 데이터를 효율적으로 관리했습니다.</li><li>최신 버전인 MSG 2.0은 기능이 더욱 강화되어, 팀 내 다양한 프로젝트에서 사용 사례가 점차 확대되고 있다고 합니다.</li></ul> 현재 MSG는 오픈소스 전환을 목표로 개발되고 있습니다. 만약 공개된다면, QA, 기획자, 개발자 모두가 실시간으로 데이터를 확인하고 테스트하면서 더욱 원활하고 신속한 협업이 가능해질 것으로 보입니다. 오픈소스로 공개된다면 안쓸 이유가 없어보이고 여러 부서와 팀에 긍정적인 변화를 가져올 것으로 보이는만큼 빨리 공개되었으면 좋겠네요 :) https://www.youtube.com/watch?v=dDAfG4fe4dohttps://techblog.woowahan.com/20154/

API 모킹 환경의 진화, MSG(Mock Service GUI)

2024 was insane, and many things happened around AI and software development in general. I believe...

25 top open-source tools for building web apps you can't afford to miss in 2025🎉 🚀

여기 2024년에 가능성을 보여주었고, 2025년에 더욱 빛날 것으로 보이는 25개의 오픈소스 웹앱개발도구를 소개합니다. 보다 상세한 사용법과 내용은 원문을 참고해주시기 바랍니다~^^

1. AI 및 LLM 도구
 * Composio
   * https://composio.dev/
   * AI 에이전트 통합 플랫폼
   * 250개 이상의 애플리케이션을 지원하며, GitHub, Jira, Salesforce, Gmail 등 다수의 SaaS 앱 연결 지원
 * Vercel AI SDK
   * https://sdk.vercel.ai/
   * TypeScript로 AI 웹 앱 빌드
   * React, Next.js, Vue, SvelteKit 등을 지원하며, 반복적인 설정을 단순화하고 대화형 UI 기반 구축
 * LangGraph JS
   * https://www.langchain.com/langgraph
   * 그래프 기반 에이전트 워크플로우 구축
   * 상태 머신 개념을 사용하여 복잡한 AI 워크플로우를 그래프 방식으로 쉽게 구축
 * CopilotKit
   * https://www.copilotkit.ai/
   * 웹 앱에 AI 코파일럿 추가, GitHub Copilot과 같은 기능을 앱에 쉽게 추가
 * LanceDB
   * https://lancedb.com/
   * AI 앱을 위한 고성능 벡터 데이터베이스
   * 벡터 임베딩을 효율적으로 저장하고 쿼리할 수 있는 SQLite와 유사한 빠른 데이터베이스

2. 프레임워크 및 빌드 도구
 * Encore
   * https://encore.dev/
   * 자동화된 인프라가 포함된 백엔드 프레임워크
   * 클라우드 서비스를 단순화하여 일관된 API와 DevOps 자동화 제공
 * HTMX
   * https://htmx.org/
   * JavaScript 없이 동적 웹 앱 개발
   * HTML만으로도 모던한 웹 앱을 구축
 * Val Town
   * https://www.val.town/
   * 서버리스 JavaScript 실행 플랫폼
   * GitHub Gist와 서버리스 함수의 결합처럼 작동하며 JavaScript 코드 공유와 실행 방식 혁신
 * Deno 2
   * https://deno.com/
   * TypeScript 지원을 내장한 안전한 런타임
   * Node.js의 창시자인 Ryan Dahl의 새로운 프로젝트로, 현대적인 기능과 내장된 보안 제공
 * Turborepo
   * https://turbo.build/
   * 고성능 JS 모노레포 빌드 시스템
   * 지능형 캐싱과 병렬 실행을 통해 모노레포 관리의 빌드 시간 단축

3. 실시간 및 이벤트 기반 시스템
 * Socket.io
   * https://socket.io/
   * 웹 앱용 양방향 실시간 통신 라이브러리
   * 실시간 기능을 추가할 때 복잡한 통신 문제를 손쉽게 처리
 * Feather.js
   * https://feathersjs.com/
   * 실시간 API 프레임워크
   * REST API와 실시간 업데이트를 모두 지원하는 프레임워크
 * Deepstream.io
   * https://deepstream.io/
   * 확장 가능한 실시간 데이터 동기화 엔진
   * 협업 편집기나 멀티플레이어 게임 구축에 적합
 * Serverless Framework
   * https://www.serverless.com/
   * 클라우드 애그노스틱 서버리스 앱 개발
   * AWS, Azure, Google Cloud 등 다양한 클라우드 환경에서 서버리스 애플리케이션을 배포
 * RabbitMQ
   * https://www.rabbitmq.com/
   * 분산 시스템을 위한 강력한 메시지 브로커
   * 신뢰할 수 있는 메시지 전달을 지원하며 Node.js 애플리케이션에 필수

4. 개발자 경험 및 테스트 도구
 * Vitest
   * https://vitest.dev/
   * Vite 통합 차세대 테스트 프레임워크
   * 빠른 속도로 테스트를 실행하며, 개발 서버의 성능을 테스트 환경에서도 제공
 * Playwright
   * https://playwright.dev/
   * AI 기반 E2E 테스트 생성 도구
   * 믿을 수 있는 QA 엔지니어처럼 작동하며, 앱을 클릭하면 테스트 코드 자동 생성
 * Prettier
   * https://prettier.io/
   * 코드 포맷터
   * 세미콜론이나 줄바꿈과 같은 논쟁을 끝내주는 일관된 코드 포맷터
 * Jest
   * https://jestjs.io/
   * 스냅샷 지원을 갖춘 JavaScript 테스트 프레임워크
   * 단위 테스트부터 스냅샷까지 모두 지원하는 만능 도구
 * Puppeteer
   * https://pptr.dev/
   * 모던 웹 테스트를 위한 헤드리스 Chrome 자동화
   * 크롬 자동화, 웹 스크래핑, PDF 생성 등 다양한 작업 수행

5. 디자인 컴포넌트 및 UI
 * Shadcn-UI
   * https://ui.shadcn.com/
   * 복사-붙여넣기 구현을 지원하는 접근성 컴포넌트 라이브러리
   * 스타일링 제한 없이 컴포넌트를 완전 제어할 수 있는 접근 방식 제공
 * Radix Themes
   * https://www.radix-ui.com/themes/docs/components/theme
   * Radix Primitives를 위한 프로덕션 준비 테마 시스템
   * Radix Primitives의 장점을 테마 시스템에 통합하여 쉽게 활용
 * Daisy UI
   * https://daisyui.com/
   * Tailwind 기반 컴포넌트 라이브러리
   * Tailwind의 클래스를 간소화하여 코드가 더 깔끔하게 유지
 * Vanilla Extract
   * https://vanilla-extract.style/
   * 실행 시간 없는 타입이 적용된 CSS-in-JS 솔루션
   * TypeScript의 강력함과 실행 시간 없이 순수 CSS 제공
 * Ark UI
   * https://ark-ui.com/
   * 프레임워크에 구애받지 않는 헤드리스 UI 컴포넌트
   * React, Vue, Solid에서 일관된 컴포넌트 제공

 * 원문: https://dev.to/composiodev/25-top-open-source-tools-for-building-web-apps-you-cant-afford-to-miss-in-2025-5005

여기 2024년에 가능성을 보여주었고, 2025년에 더욱 빛날 것으로 보이는 25개의 오픈소스 웹앱개발도구를 소개합니다. 보다 상세한 사용법과 내용은 원문을 참고해주시기 바랍니다~^^ 1. AI 및 LLM 도구<ul ><li>Composio<ul ><li>https://composio.dev/</li><li>AI 에이전트 통합 플랫폼</li><li>250개 이상의 애플리케이션을 지원하며, GitHub, Jira, Salesforce, Gmail 등 다수의 SaaS 앱 연결 지원</li></ul></li><li>Vercel AI SDK<ul ><li>https://sdk.vercel.ai/</li><li>TypeScript로 AI 웹 앱 빌드</li><li>React, Next.js, Vue, SvelteKit 등을 지원하며, 반복적인 설정을 단순화하고 대화형 UI 기반 구축 </li></ul></li><li>LangGraph JS<ul ><li>https://www.langchain.com/langgraph</li><li>그래프 기반 에이전트 워크플로우 구축</li><li>상태 머신 개념을 사용하여 복잡한 AI 워크플로우를 그래프 방식으로 쉽게 구축</li></ul></li><li>CopilotKit<ul ><li>https://www.copilotkit.ai/</li><li>웹 앱에 AI 코파일럿 추가, GitHub Copilot과 같은 기능을 앱에 쉽게 추가</li></ul></li><li>LanceDB<ul ><li>https://lancedb.com/</li><li>AI 앱을 위한 고성능 벡터 데이터베이스</li><li>벡터 임베딩을 효율적으로 저장하고 쿼리할 수 있는 SQLite와 유사한 빠른 데이터베이스</li></ul></li></ul> 2. 프레임워크 및 빌드 도구<ul ><li>Encore<ul ><li>https://encore.dev/</li><li>자동화된 인프라가 포함된 백엔드 프레임워크</li><li>클라우드 서비스를 단순화하여 일관된 API와 DevOps 자동화 제공</li></ul></li><li>HTMX<ul ><li>https://htmx.org/</li><li>JavaScript 없이 동적 웹 앱 개발</li><li>HTML만으로도 모던한 웹 앱을 구축</li></ul></li><li>Val Town<ul ><li>https://www.val.town/</li><li>서버리스 JavaScript 실행 플랫폼</li><li>GitHub Gist와 서버리스 함수의 결합처럼 작동하며 JavaScript 코드 공유와 실행 방식 혁신</li></ul></li><li>Deno 2<ul ><li>https://deno.com/</li><li>TypeScript 지원을 내장한 안전한 런타임</li><li>Node.js의 창시자인 Ryan Dahl의 새로운 프로젝트로, 현대적인 기능과 내장된 보안 제공</li></ul></li><li>Turborepo<ul ><li>https://turbo.build/</li><li>고성능 JS 모노레포 빌드 시스템</li><li>지능형 캐싱과 병렬 실행을 통해 모노레포 관리의 빌드 시간 단축</li></ul></li></ul> 3. 실시간 및 이벤트 기반 시스템<ul ><li>Socket.io<ul ><li>https://socket.io/</li><li>웹 앱용 양방향 실시간 통신 라이브러리</li><li>실시간 기능을 추가할 때 복잡한 통신 문제를 손쉽게 처리</li></ul></li><li>Feather.js<ul ><li>https://feathersjs.com/</li><li>실시간 API 프레임워크</li><li>REST API와 실시간 업데이트를 모두 지원하는 프레임워크</li></ul></li><li>Deepstream.io<ul ><li>https://deepstream.io/</li><li>확장 가능한 실시간 데이터 동기화 엔진</li><li>협업 편집기나 멀티플레이어 게임 구축에 적합</li></ul></li><li>Serverless Framework<ul ><li>https://www.serverless.com/</li><li>클라우드 애그노스틱 서버리스 앱 개발</li><li>AWS, Azure, Google Cloud 등 다양한 클라우드 환경에서 서버리스 애플리케이션을 배포</li></ul></li><li>RabbitMQ<ul ><li>https://www.rabbitmq.com/</li><li>분산 시스템을 위한 강력한 메시지 브로커</li><li>신뢰할 수 있는 메시지 전달을 지원하며 Node.js 애플리케이션에 필수</li></ul></li></ul> 4. 개발자 경험 및 테스트 도구<ul ><li>Vitest<ul ><li>https://vitest.dev/</li><li>Vite 통합 차세대 테스트 프레임워크</li><li>빠른 속도로 테스트를 실행하며, 개발 서버의 성능을 테스트 환경에서도 제공</li></ul></li><li>Playwright<ul ><li>https://playwright.dev/</li><li>AI 기반 E2E 테스트 생성 도구</li><li>믿을 수 있는 QA 엔지니어처럼 작동하며, 앱을 클릭하면 테스트 코드 자동 생성</li></ul></li><li>Prettier<ul ><li>https://prettier.io/</li><li>코드 포맷터</li><li>세미콜론이나 줄바꿈과 같은 논쟁을 끝내주는 일관된 코드 포맷터</li></ul></li><li>Jest<ul ><li>https://jestjs.io/</li><li>스냅샷 지원을 갖춘 JavaScript 테스트 프레임워크</li><li>단위 테스트부터 스냅샷까지 모두 지원하는 만능 도구</li></ul></li><li>Puppeteer<ul ><li>https://pptr.dev/</li><li>모던 웹 테스트를 위한 헤드리스 Chrome 자동화</li><li>크롬 자동화, 웹 스크래핑, PDF 생성 등 다양한 작업 수행</li></ul></li></ul> 5. 디자인 컴포넌트 및 UI<ul ><li>Shadcn-UI<ul ><li>https://ui.shadcn.com/</li><li>복사-붙여넣기 구현을 지원하는 접근성 컴포넌트 라이브러리</li><li>스타일링 제한 없이 컴포넌트를 완전 제어할 수 있는 접근 방식 제공</li></ul></li><li>Radix Themes<ul ><li>https://www.radix-ui.com/themes/docs/components/theme</li><li>Radix Primitives를 위한 프로덕션 준비 테마 시스템</li><li>Radix Primitives의 장점을 테마 시스템에 통합하여 쉽게 활용</li></ul></li><li>Daisy UI<ul ><li>https://daisyui.com/</li><li>Tailwind 기반 컴포넌트 라이브러리</li><li>Tailwind의 클래스를 간소화하여 코드가 더 깔끔하게 유지</li></ul></li><li>Vanilla Extract<ul ><li>https://vanilla-extract.style/</li><li>실행 시간 없는 타입이 적용된 CSS-in-JS 솔루션</li><li>TypeScript의 강력함과 실행 시간 없이 순수 CSS 제공</li></ul></li><li>Ark UI<ul ><li>https://ark-ui.com/</li><li>프레임워크에 구애받지 않는 헤드리스 UI 컴포넌트</li><li>React, Vue, Solid에서 일관된 컴포넌트 제공</li></ul></li></ul> <ul ><li>원문: https://dev.to/composiodev/25-top-open-source-tools-for-building-web-apps-you-cant-afford-to-miss-in-2025-5005</li></ul>

DEV Community

[Dev] 2025년에 놓쳐선 안 될 25가지 오픈소스 웹 앱 개

우아콘에 나온 데이터분석 챗봇 '물어보새!'
이거 보고 저도 만들고 있어요!
(재밌는데 AI 엔지니어로 전향을...)

연휴에 널널한데 재밌게 좋네요 :) 다들 업무에 적용해보세요!

https://youtu.be/_QPhoKItI2k?si=X7-bDz4IGqJx0NDc

우아콘에 나온 데이터분석 챗봇 '물어보새!'이거 보고 저도 만들고 있어요!(재밌는데 AI 엔지니어로 전향을...) 연휴에 널널한데 재밌게 좋네요 :) 다들 업무에 적용해보세요! https://youtu.be/_QPhoKItI2k?si=X7-bDz4IGqJx0NDc

youtu.be

랭체인+RAG으로 text to SQL 만들기

React 19가 얼마 전 정식 버전으로 출시되었는데요, 혹시 React 19 업그레이드를 고려하고 계신가요? 공식 문서의 업그레이드 가이드를 한글로 번역해두었으니 참고하시면 도움이 될 것 같습니다 😊

[번역] 리액트 19 업그레이드 가이드

오늘은 라인플러스의 김은빈님이 번역해주신 글입니다.

리액트 19가 정식 버전으로 출시되면서 많은 변화와 개선사항들이 있었습니다. 특히 메이저 업데이트인 만큼 호환성이 깨지는 변경사항들이 있어 업그레이드 시 주의가 필요한데요.

이 가이드에서는 설치부터 시작해 코드 자동 변환(Codemods), 호환성 이슈, 지원 중단되는 기능들까지 상세히 다루고 있습니다. 특히 실제 마이그레이션 과정에서 발생할 수 있는 이슈들과 해결 방법에 대해 자세히 설명하고 있으니, 리액트 19 업그레이드를 계획하고 계신 분들에게 꼭 필요한 내용이 될 것 같습니다.

업그레이드 과정에서 어려움을 겪지 않도록, 목차에 있는 내용들을 차근차근 살펴보시는 것을 추천드립니다! 😊

글 링크: https://velog.io/@eunbinn/react-19-upgrade-guide

오늘은 라인플러스의 김은빈님이 번역해주신 글입니다. 리액트 19가 정식 버전으로 출시되면서 많은 변화와 개선사항들이 있었습니다. 특히 메이저 업데이트인 만큼 호환성이 깨지는 변경사항들이 있어 업그레이드 시 주의가 필요한데요. 이 가이드에서는 설치부터 시작해 코드 자동 변환(Codemods), 호환성 이슈, 지원 중단되는 기능들까지 상세히 다루고 있습니다. 특히 실제 마이그레이션 과정에서 발생할 수 있는 이슈들과 해결 방법에 대해 자세히 설명하고 있으니, 리액트 19 업그레이드를 계획하고 계신 분들에게 꼭 필요한 내용이 될 것 같습니다. 업그레이드 과정에서 어려움을 겪지 않도록, 목차에 있는 내용들을 차근차근 살펴보시는 것을 추천드립니다! 😊 글 링크: https://velog.io/@eunbinn/react-19-upgrade-guide

velog.io

리액트 19 업그레이드 가이드

내 커리어 30년을 돌이켜보면 초반에 많이 했던 실수 중의 하나가 내가 있는 현재 환경에 대한 부정적인 시각을 갖고 있었던 것이었다. 좋은 점은 눈에 안 들어오고 나쁜 점만 부각되는 형태였는데 그러면서 왠지 다른 회사나 경쟁사는 우리보다 훨씬 더 완벽한 환경이란 착각을 하는 모양새였다.

큰 기대를 가지고 다른 환경에 가서 일하면서 여기는 여기대로 또 다른 문제점들이 존재한다는 것을 깨닫는데 오랜 시간이 걸리지는 않았다. 중요한 포인트는 안 좋은 점 하나에 꽂혀 버리는 것이 아니라 균형 잡힌 시각을 갖는 것이다.

 1. 긍정적인 부분의 합이 부정적인 부분의 합보다 크다면 괜찮은 환경이다. 여기서 합을 할 때 중요한 포인트는 가중치를 분명하게 주어야 한다는 점이다. 사람이 좋은 곳인지 특히 내 상사가 좋은 사람인지 여부에는 높은 가중치를 주어야 한다. 회사의 비전과 미션이 내 개인적인 관심사와 일치하는지도 중요한 포인트다.
 2. 다른 환경은 완벽할 것이라는 기대는 충족될 수 없는 기대다. 다른 환경으로 이동할 때 기대 수준 관리를 할 필요가 있다. 기대가 크면 실망도 크다.

완벽한 환경은 존재하지 않지만, 균형 잡힌 시각을 바탕으로 긍정적인 부분의 합이 부정적인 부분의 합보다 큰지를 바라봄으로써 계속 있는 것이 맞는지 아니면 다른 환경을 찾아가는 것이 맞는지 결정할 수 있었다. 그리고 어디에 있건 언젠가는 떠나겠지만 현재에 최선을 다하는 모습을 보이는 것은 중요하다. 이게 평판에 영향을 끼치며 좋은 평판 없이 커리어 후반기 이직은 쉽지 않다.

내 커리어 30년을 돌이켜보면 초반에 많이 했던 실수 중의 하나가 내가 있는 현재 환경에 대한 부정적인 시각을 갖고 있었던 것이었다. 좋은 점은 눈에 안 들어오고 나쁜 점만 부각되는 형태였는데 그러면서 왠지 다른 회사나 경쟁사는 우리보다 훨씬 더 완벽한 환경이란 착각을 하는 모양새였다. 큰 기대를 가지고 다른 환경에 가서 일하면서 여기는 여기대로 또 다른 문제점들이 존재한다는 것을 깨닫는데 오랜 시간이 걸리지는 않았다. 중요한 포인트는 안 좋은 점 하나에 꽂혀 버리는 것이 아니라 균형 잡힌 시각을 갖는 것이다. <ol ><li>긍정적인 부분의 합이 부정적인 부분의 합보다 크다면 괜찮은 환경이다. 여기서 합을 할 때 중요한 포인트는 가중치를 분명하게 주어야 한다는 점이다. 사람이 좋은 곳인지 특히 내 상사가 좋은 사람인지 여부에는 높은 가중치를 주어야 한다. 회사의 비전과 미션이 내 개인적인 관심사와 일치하는지도 중요한 포인트다.</li><li>다른 환경은 완벽할 것이라는 기대는 충족될 수 없는 기대다. 다른 환경으로 이동할 때 기대 수준 관리를 할 필요가 있다. 기대가 크면 실망도 크다.</li></ol> 완벽한 환경은 존재하지 않지만, 균형 잡힌 시각을 바탕으로 긍정적인 부분의 합이 부정적인 부분의 합보다 큰지를 바라봄으로써 계속 있는 것이 맞는지 아니면 다른 환경을 찾아가는 것이 맞는지 결정할 수 있었다. 그리고 어디에 있건 언젠가는 떠나겠지만 현재에 최선을 다하는 모습을 보이는 것은 중요하다. 이게 평판에 영향을 끼치며 좋은 평판 없이 커리어 후반기 이직은 쉽지 않다.

모든 일에는 명암이 있다

A few points that I want to mention after working in Coupang for 6 months as a Recommender system software engineer

Review - 6 Months in Coupang

쿠팡에서 추천 시스템 백엔드 엔지니어로 조인한지 6개월 차가 되었습니다.
다음 분기를, 내년을 준비하고자 지난 기간을 되돌아봅니다.

문화
자신의 상황에 따라 많이 차이가 있을 수 있으나, 제가 경험하고 느낀 바는 아래와 같습니다.

 * 사용자 문제에 기반
대부분의 주요 프로젝트는 사용자 문제에 기반하여 주도됩니다. 여러 데이터를 참조하여 문제를 정의하고, 해결하고자 하는 바를 기술하며, 성공과 실패(롤백)은 어떤 기준일지를 작성한 1-pager를 통해 변경 프로젝트가 시작되고 팀이 구성됩니다.

 * 실험 주도
문제 정의부터 성공과 실패의 정의 및 판단까지 모든 것은 데이터와 A/B 테스트를 기반으로 진행됩니다. 고도화되어 구현에 큰 비용이 발생하지 않는 A/B 테스트 플랫폼과 프로세스는 중요 핵심 자산으로 보이며, 그렇기에 모든 변경은 검증되어 개선이 인정될 때만 반영되고 그렇지 않다면 폐기됩니다.
(관련해 좋은 책, Ron Kohavi의 Trustworthy Online Controlled Experiments)

 * 문제를 소유하지, 도메인을 점유하지 않음
주로는 도메인 오너가 도메인에 대한 변경을 진행하게 되지만, 리소스가 없다면 도메인 오너의 가이드 하에 특정 문제를 해결하기 위해 도메인 오너가 아닌 컨트리뷰터가 기여하기도 합니다. 물론, 특정 도메인 서비스에 대한 운영, oncall 등은 도메인 오너가 진행합니다.

하지만, 어떤 문제를 어떤 구성원이 P0로 해결하는 중이라면 그 문제를 위한 변경은 도메인에 구애받지 않고 '급한 구성원'이 해결할 수 있는 기회가 비교적 열려 있습니다.

Self AAR (Review)
추천 시스템은 다른 백엔드 시스템과는 조금 다르게 내부적으로 헤비한 데이터(Data-Intensive) 처리가 존재하고, 그 데이터 처리에 기반한 모델을 서빙한다는 특징이 있습니다. 유사한 도메인으로는 검색, ML 서빙 플랫폼와 같은 것들이 생각되는데요.

그렇기에 엔지니어로 관여하는 부분은 모델링, 파이프라이닝, 서빙, 그리고 기본적인 운영과 같은 4가지로 구분할 수 있습니다.

저는 지난 160일간 대략적으로 파이프라이닝, 서빙, 그리고 운영에 관여하였습니다.

 * 파이프라이닝
특정 유저에 대해 특정 추천상품이라는 후보군들을 뽑아내기 위해 Offline으로 준비되는 데이터에 해당됩니다. Java, Scala, Python 등에 기반한 Spark으로 되어 있어, 일부 데이터를 추가하는 작업을 진행하였습니다.

 * 서빙
실시간으로 추천 위젯과 위젯의 상품 리스트를 응답하는 서비스입니다. 주로 다양한 업스트림을 Aggregate하는 패턴으로 다양한 아규먼트를 받을 수 잇는 GRPC 엔드포인트를 제공합니다.

 * 운영
모델링, 파이프라이닝, 서빙에 대한 유지와 모니터링이 해당됩니다. Spark 버젼을 마이그레이션하거나, AWS LB와 내부 클러스터 설정 구조를 변경하거나, CICD에 사용되는 서비스를 전사 정책에 따라 마이그레이션 하는 등의 작업을 진행합니다.

특징적으로는 Oncall이 일주일씩 로테이션이 되기에, Grafana alert에 따라 전화가 오면 핸들링하는 Oncall 프로세스를 진행하기도 합니다.

(원본: https://kadensungbincho.com/blog/backend/review-6-months-in-coupang)

쿠팡에서 추천 시스템 백엔드 엔지니어로 조인한지 6개월 차가 되었습니다. 다음 분기를, 내년을 준비하고자 지난 기간을 되돌아봅니다. 문화자신의 상황에 따라 많이 차이가 있을 수 있으나, 제가 경험하고 느낀 바는 아래와 같습니다. <ul ><li>사용자 문제에 기반</li></ul>대부분의 주요 프로젝트는 사용자 문제에 기반하여 주도됩니다. 여러 데이터를 참조하여 문제를 정의하고, 해결하고자 하는 바를 기술하며, 성공과 실패(롤백)은 어떤 기준일지를 작성한 1-pager를 통해 변경 프로젝트가 시작되고 팀이 구성됩니다. <ul ><li>실험 주도</li></ul>문제 정의부터 성공과 실패의 정의 및 판단까지 모든 것은 데이터와 A/B 테스트를 기반으로 진행됩니다. 고도화되어 구현에 큰 비용이 발생하지 않는 A/B 테스트 플랫폼과 프로세스는 중요 핵심 자산으로 보이며, 그렇기에 모든 변경은 검증되어 개선이 인정될 때만 반영되고 그렇지 않다면 폐기됩니다. (관련해 좋은 책, Ron Kohavi의 Trustworthy Online Controlled Experiments) <ul ><li>문제를 소유하지, 도메인을 점유하지 않음</li></ul>주로는 도메인 오너가 도메인에 대한 변경을 진행하게 되지만, 리소스가 없다면 도메인 오너의 가이드 하에 특정 문제를 해결하기 위해 도메인 오너가 아닌 컨트리뷰터가 기여하기도 합니다. 물론, 특정 도메인 서비스에 대한 운영, oncall 등은 도메인 오너가 진행합니다. 하지만, 어떤 문제를 어떤 구성원이 P0로 해결하는 중이라면 그 문제를 위한 변경은 도메인에 구애받지 않고 '급한 구성원'이 해결할 수 있는 기회가 비교적 열려 있습니다. Self AAR (Review)추천 시스템은 다른 백엔드 시스템과는 조금 다르게 내부적으로 헤비한 데이터(Data-Intensive) 처리가 존재하고, 그 데이터 처리에 기반한 모델을 서빙한다는 특징이 있습니다. 유사한 도메인으로는 검색, ML 서빙 플랫폼와 같은 것들이 생각되는데요. 그렇기에 엔지니어로 관여하는 부분은 모델링, 파이프라이닝, 서빙, 그리고 기본적인 운영과 같은 4가지로 구분할 수 있습니다. 저는 지난 160일간 대략적으로 파이프라이닝, 서빙, 그리고 운영에 관여하였습니다. <ul ><li>파이프라이닝</li></ul>특정 유저에 대해 특정 추천상품이라는 후보군들을 뽑아내기 위해 Offline으로 준비되는 데이터에 해당됩니다. Java, Scala, Python 등에 기반한 Spark으로 되어 있어, 일부 데이터를 추가하는 작업을 진행하였습니다. <ul ><li> 서빙</li></ul>실시간으로 추천 위젯과 위젯의 상품 리스트를 응답하는 서비스입니다. 주로 다양한 업스트림을 Aggregate하는 패턴으로 다양한 아규먼트를 받을 수 잇는 GRPC 엔드포인트를 제공합니다. <ul ><li>운영</li></ul>모델링, 파이프라이닝, 서빙에 대한 유지와 모니터링이 해당됩니다. Spark 버젼을 마이그레이션하거나, AWS LB와 내부 클러스터 설정 구조를 변경하거나, CICD에 사용되는 서비스를 전사 정책에 따라 마이그레이션 하는 등의 작업을 진행합니다. 특징적으로는 Oncall이 일주일씩 로테이션이 되기에, Grafana alert에 따라 전화가 오면 핸들링하는 Oncall 프로세스를 진행하기도 합니다. (원본: https://kadensungbincho.com/blog/backend/review-6-months-in-coupang)

Kaden Sungbin Cho

쿠팡에서의 6개월 회고

남이 짠 코드를 읽는 건 재미없는 일입니다. 가끔 잘 짜인 코드를 볼 때면 기분이 좋았지만… 그런 일이 많지는 않았습니다. 잘 짠 코드라 하더라도 코드 타래를 끝도 없이 따라가며 의도를 파악하기까지의 순간은 고통 그 자체였습니다. 내가 코딩할 때나 재미를 느끼는 것입니다.

코드를 짜는 재미

남이 짠 코드를 읽는 건 재미없는 일입니다.
가끔 잘 짜인 코드를 볼 때면 기분이 좋았지만… 그런 일이 많지는 않았습니다.
잘 짠 코드라 하더라도 코드 타래를 끝도 없이 따라가며 의도를 파악하기까지의 순간은 고통 그 자체였습니다.
내가 코딩할 때나 재미를 느끼는 것입니다.

남의 코드를 많이 읽어야 실력이 빨리 향상된다고 합니다. 동의합니다.
저도 공부를 위해 가끔 오픈 소스 코드를 다운로드해서 읽어 보려 시도했지만…
번번이 포기했습니다. 너무 어렵고 재미없고 고통스러워서.
20년 동안 코딩을 했지만 실력이 이 모양인 건 남의 코드를 많이 안 읽어서 아닐까?

요즘 다시 남의 코드를 읽고 있습니다.
다 Cursor 덕분입니다.
Cursor에게 부탁하고 Accept를 누르다 보면 코드를 하나도 모른 채 프로그램이 동작하게 됩니다.
분명 내 프로젝트인데 어떤 파일에 어떤 코드들이 있는 건지 나도 모르겠어.

할 수 없이 잠시 멈추고 꾸역꾸역 코드를 읽습니다.
남이 짠 코드. 역시나 재미없고 스트레스를 받습니다.
그래도 읽어 나갈 수밖에 없습니다. 내 프로젝트니까.

이렇게라도 남의 코드를 읽으며 배울 수 있으니 좋은 거 아닐까?
그런 생각이 들면서도 이게 뭐 하는 짓인가 현타가 오는 건 어쩔 수 없습니다. 코딩을 하는 재미를 빼앗기고 있는 것 같습니다.

바둑을 두던 사람들도 이런 기분이었을까요?

https://jeho.page/essay/2024/12/23/writing-code.html

남이 짠 코드를 읽는 건 재미없는 일입니다. 가끔 잘 짜인 코드를 볼 때면 기분이 좋았지만… 그런 일이 많지는 않았습니다. 잘 짠 코드라 하더라도 코드 타래를 끝도 없이 따라가며 의도를 파악하기까지의 순간은 고통 그 자체였습니다. 내가 코딩할 때나 재미를 느끼는 것입니다. 남의 코드를 많이 읽어야 실력이 빨리 향상된다고 합니다. 동의합니다. 저도 공부를 위해 가끔 오픈 소스 코드를 다운로드해서 읽어 보려 시도했지만… 번번이 포기했습니다. 너무 어렵고 재미없고 고통스러워서. 20년 동안 코딩을 했지만 실력이 이 모양인 건 남의 코드를 많이 안 읽어서 아닐까? 요즘 다시 남의 코드를 읽고 있습니다. 다 Cursor 덕분입니다. Cursor에게 부탁하고 Accept를 누르다 보면 코드를 하나도 모른 채 프로그램이 동작하게 됩니다. 분명 내 프로젝트인데 어떤 파일에 어떤 코드들이 있는 건지 나도 모르겠어. 할 수 없이 잠시 멈추고 꾸역꾸역 코드를 읽습니다. 남이 짠 코드. 역시나 재미없고 스트레스를 받습니다. 그래도 읽어 나갈 수밖에 없습니다. 내 프로젝트니까. 이렇게라도 남의 코드를 읽으며 배울 수 있으니 좋은 거 아닐까? 그런 생각이 들면서도 이게 뭐 하는 짓인가 현타가 오는 건 어쩔 수 없습니다. 코딩을 하는 재미를 빼앗기고 있는 것 같습니다. 바둑을 두던 사람들도 이런 기분이었을까요? https://jeho.page/essay/2024/12/23/writing-code.html

K리그 프로그래머

[커닝단 2기] UX디자인 강의 1주차 : 네이버 블로그

커닝단 2기 UX디자인을 시작했다.
UX에 대해 제대로 알지 못했지만 이번 시간을 통해 많은 것들을 새롭게 알게 되었다.

현 직장에서 매번 기획 및 운영을 해오며 어떻게 하면 사용자들이 더 나은 경험을 하게 할 수 있을지, 수혜자가 어떻게 하면 더 나은 수혜를 받게 할 수 있을지 매번 고민을 해왔는데 UX 강의를 통해 많은 것을 적용할 수 있겠다라는 생각이 들었고 확신이 들었다.

최근 UX에 대한 관심도 많아지고 있는거 같은데 여러 방면에서도 적용이 가능하지 않을까 싶다. 남은 시간동안도 차근차근히 배워 지금보다 더 발전하고 성장하고 싶다.

blog.naver.com

기획

천성진

김포시자원봉사센터 자원봉사활동 기획 및 운영, 관리하고 있습니다.

자원봉사활동 기획 및 관리, 운영

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필