From design tools, to our design process, to the user behaviors that will change the way we design — a list of what to expect for User Experience (UX) Design in the next year.

The State of UX in 2025

매년 이맘때쯤 살펴보는 UX Trends 2025년 전망에 제 생각을 더해 10가지로 정리해 봤습니다. 원문을 함께 소개해드리니 같이 살펴보시면 좋겠습니다. 크게 보면 산업구조가 AI 중심으로 바뀌면서 디자인 가치, 실무를 하는 환경, 의사결정 구조까지 직접적으로 변화할 것으로 전망하고 있습니다.

한국은 미국의 UX 업계 변화를 2년 정도 시차를 두고 따라가는 모양새였는데 그 시간차도 줄어들 것 같습니다. 비즈니스 성과 중심, 정성적 수치 보다 정략적 수치 기반으로 평가하는 것, 사용자 공감 대신 AI 통해 도출한 시뮬레이션 결과 등에 중점을 둔 디자인 의사결정이 UX 리서치 업계에도 변화를 만들 것으로 보입니다.

1️⃣ UX의 탈중심화 - UX가 비즈니스 목표의 부산물로 전락
2️⃣ 디자인 통제권의 이동 - 디자이너→AI/비즈니스 의사결정자로의 권한 이동
3️⃣ 전문성의 경계 붕괴 - AI 도구로 인한 디자인 민주화와 가치 평가 기준 변화
4️⃣ 정량적 성과 중심으로의 전환 - 사용자 공감에서 AI 활용한 수치 중심으로 변화
5️⃣ 디자이너 역할의 정체성 위기 - 디자인 작업보다 조직 정치에 집중
6️⃣ 의사결정 구조의 변화 - 인간의 직관에서 알고리즘 기반 결정으로
7️⃣ 디자인 담론의 질적 하락 - 깊이 있는 논의에서 알고리즘 최적화된 콘텐츠로
8️⃣ 커뮤니티 주도권의 상실 - 기업 주도 행사로의 전환과 독립성 약화
9️⃣ 지속가능한 UX 가치의 재정립 필요성 - 비즈니스와 사용자 경험 사이의 새로운 균형점 모색
🔟 디자이너의 새로운 정체성 모색 - 변화를 수용하면서도 전문성을 유지하는 방안

https://trends.uxdesign.cc/

매년 이맘때쯤 살펴보는 UX Trends 2025년 전망에 제 생각을 더해 10가지로 정리해 봤습니다. 원문을 함께 소개해드리니 같이 살펴보시면 좋겠습니다. 크게 보면 산업구조가 AI 중심으로 바뀌면서 디자인 가치, 실무를 하는 환경, 의사결정 구조까지 직접적으로 변화할 것으로 전망하고 있습니다. 한국은 미국의 UX 업계 변화를 2년 정도 시차를 두고 따라가는 모양새였는데 그 시간차도 줄어들 것 같습니다. 비즈니스 성과 중심, 정성적 수치 보다 정략적 수치 기반으로 평가하는 것, 사용자 공감 대신 AI 통해 도출한 시뮬레이션 결과 등에 중점을 둔 디자인 의사결정이 UX 리서치 업계에도 변화를 만들 것으로 보입니다. 1️⃣ UX의 탈중심화 - UX가 비즈니스 목표의 부산물로 전락2️⃣ 디자인 통제권의 이동 - 디자이너→AI/비즈니스 의사결정자로의 권한 이동3️⃣ 전문성의 경계 붕괴 - AI 도구로 인한 디자인 민주화와 가치 평가 기준 변화4️⃣ 정량적 성과 중심으로의 전환 - 사용자 공감에서 AI 활용한 수치 중심으로 변화5️⃣ 디자이너 역할의 정체성 위기 - 디자인 작업보다 조직 정치에 집중6️⃣ 의사결정 구조의 변화 - 인간의 직관에서 알고리즘 기반 결정으로7️⃣ 디자인 담론의 질적 하락 - 깊이 있는 논의에서 알고리즘 최적화된 콘텐츠로8️⃣ 커뮤니티 주도권의 상실 - 기업 주도 행사로의 전환과 독립성 약화9️⃣ 지속가능한 UX 가치의 재정립 필요성 - 비즈니스와 사용자 경험 사이의 새로운 균형점 모색🔟 디자이너의 새로운 정체성 모색 - 변화를 수용하면서도 전문성을 유지하는 방안 https://trends.uxdesign.cc/

UX Trends

《2025년 UX 업계의 변화 전망, 10가지》

この記事はNuco Advent Calendar 2024の16日目の記事です。Linuxネタコマンドの世界へ「日々のコマンドライン作業で脳みそが疲弊してる？」「毎日同じコマンドばかりでつまら…

【全エンジニア必見？】仕事で使えないLinuxネタコマンド大全 - Qiita

일본의 qiita 사이트에 올라온 네타(개그소재, 재미용도) 커맨드 관련 글입니다.
많은 이들이 알고 있는 cowsay로 시작하는데요.
이런 커맨드들만 깊게 파보는 굉장히 너드한 컨텐츠입니다.

일본어로 되어 있지만, 번역을 하면 매끄럽게 나오는 편이고, 명령어는 모두 영어라서 알기 쉽습니다.

cowsay에서 용이 나오게 하는 명령어가 있는건 처음알았네요..!
cowsay -f dragon-and-cow "드래곤이다~〜"

https://qiita.com/nuco_sat/items/6851ff4e04dc87882e37

재미로 한번 봐보세요~ 🙂

fortune 같은 경우는 의외로 일에도 도움되는 커맨드입니다..ㅎ

일본의 qiita 사이트에 올라온 네타(개그소재, 재미용도) 커맨드 관련 글입니다.많은 이들이 알고 있는 cowsay로 시작하는데요.이런 커맨드들만 깊게 파보는 굉장히 너드한 컨텐츠입니다. 일본어로 되어 있지만, 번역을 하면 매끄럽게 나오는 편이고, 명령어는 모두 영어라서 알기 쉽습니다. cowsay에서 용이 나오게 하는 명령어가 있는건 처음알았네요..!<pre ><code>cowsay -f dragon-and-cow "드래곤이다~〜"</code></pre> https://qiita.com/nuco_sat/items/6851ff4e04dc87882e37 재미로 한번 봐보세요~ 🙂 fortune 같은 경우는 의외로 일에도 도움되는 커맨드입니다..ㅎ

Qiita

재미로 보는 linux 커맨드

효과적인 FGI 조사를 위한 프로세스 4단계와 단계별 특징과 주의사항을 알아봅니다.

FGI 조사 프로세스 4단계 및 단계별 주의사항 - 오픈서베이 블로그

FGI 프로세스 4단계
FGI 조사 진행 프로세스는 디자인(Design), 리크루팅(Recruiting), 필드워크(Fieldwork), 신서시스(Synthesis) 4단계로 나눌 수 있습니다. 이번 글에서는 기업이 리서치사에 FGI 조사를 의뢰할 때 단계별로 꼭 알아야 할 사항과 유의해야 할 점을 중점적으로 살펴보겠습니다.
a. 디자인
FGI 조사의 첫 단계인 디자인 단계는 조사의 전체적인 틀을 만드는 과정입니다. 참가자 조건, 인원수, 그룹 구성 등 구체적인 프로젝트 설계가 이루어집니다. 이때 기업은 조사 결과를 통해 내리고 싶은 의사 결정, 필요한 정보, 예산 및 일정 등을 리서치 회사에 명확히 전달해야 합니다.
b. 리쿠르팅
리크루팅은 좌담회 참여자 모집 과정으로 크게 3단계로 진행됩니다. ① 스크리너 작성, ② 참석자 모집 및 선정, ③ 스케줄링을 통해 리서치 회사는 적절한 참석자를 가려냅니다.
스크리너 작성 단계에서는 대상자가 FGI 조사에 적합한지 파악하기 위해 질문지를 구성합니다. 관심도, 사용 제품, 태도 등을 묻는 다양한 문항을 포함해 참석자가 논의 주제에 적합한지를 판단합니다. 이후 확정된 대상자 조건에 따라 실제 참석자를 모집하고 선정합니다.
c. 필드워크
필드워크 단계에서는 실제 포커스 그룹 좌담회를 진행합니다. 이때 대면 또는 비대면 방식 중 하나를 선택할 수 있습니다. 팬데믹 이후 온라인을 통한 비대면 방식이 많이 활용되고 있지만, 각 방식에는 고유한 장단점이 있으므로 프로젝트 특성과 대상에 맞게 방식을 선택하는 것이 중요합니다.
d. 신서시스
신서시스 단계는 FGI 조사를 마친 후 비즈니스 목표 달성을 위한 결론을 도출하는 과정입니다. 이를 위해 알아야 할 핵심 개념은 Fact, Insight, So-What입니다.
Fact는 소비자의 행동, 인식, 제품 사용 패턴 등 관찰 가능한 사실 정보를 의미합니다. Insight는 이러한 Fact를 연결해 패턴을 발견하는 과정으로, 여러 정보를 종합적으로 사고할 때 얻을 수 있습니다.
So-What은 Fact와 Insight를 바탕으로 실행 가능한 결론을 도출하는 단계입니다. 조사 결과를 바탕으로 어떤 액션을 취할지 결정하며, 우선순위를 설정하고 구체적인 비즈니스 실행안을 마련합니다. 이때 결론은 기업의 목표와 역량을 충분히 이해한 상태에서 도출하는 것이 중요합니다.

본 게시글은 ‘오픈서베이’의 콘텐츠를 보고 영감을 받아 공유합니다. 자세한 내용은 아래 원문을 읽어보세요 🙏🏻

FGI 프로세스 4단계FGI 조사 진행 프로세스는 디자인(Design), 리크루팅(Recruiting), 필드워크(Fieldwork), 신서시스(Synthesis) 4단계로 나눌 수 있습니다. 이번 글에서는 기업이 리서치사에 FGI 조사를 의뢰할 때 단계별로 꼭 알아야 할 사항과 유의해야 할 점을 중점적으로 살펴보겠습니다.a. 디자인FGI 조사의 첫 단계인 디자인 단계는 조사의 전체적인 틀을 만드는 과정입니다. 참가자 조건, 인원수, 그룹 구성 등 구체적인 프로젝트 설계가 이루어집니다. 이때 기업은 조사 결과를 통해 내리고 싶은 의사 결정, 필요한 정보, 예산 및 일정 등을 리서치 회사에 명확히 전달해야 합니다.b. 리쿠르팅리크루팅은 좌담회 참여자 모집 과정으로 크게 3단계로 진행됩니다. ① 스크리너 작성, ② 참석자 모집 및 선정, ③ 스케줄링을 통해 리서치 회사는 적절한 참석자를 가려냅니다.스크리너 작성 단계에서는 대상자가 FGI 조사에 적합한지 파악하기 위해 질문지를 구성합니다. 관심도, 사용 제품, 태도 등을 묻는 다양한 문항을 포함해 참석자가 논의 주제에 적합한지를 판단합니다. 이후 확정된 대상자 조건에 따라 실제 참석자를 모집하고 선정합니다.c. 필드워크필드워크 단계에서는 실제 포커스 그룹 좌담회를 진행합니다. 이때 대면 또는 비대면 방식 중 하나를 선택할 수 있습니다. 팬데믹 이후 온라인을 통한 비대면 방식이 많이 활용되고 있지만, 각 방식에는 고유한 장단점이 있으므로 프로젝트 특성과 대상에 맞게 방식을 선택하는 것이 중요합니다.d. 신서시스신서시스 단계는 FGI 조사를 마친 후 비즈니스 목표 달성을 위한 결론을 도출하는 과정입니다. 이를 위해 알아야 할 핵심 개념은 Fact, Insight, So-What입니다.Fact는 소비자의 행동, 인식, 제품 사용 패턴 등 관찰 가능한 사실 정보를 의미합니다. Insight는 이러한 Fact를 연결해 패턴을 발견하는 과정으로, 여러 정보를 종합적으로 사고할 때 얻을 수 있습니다.So-What은 Fact와 Insight를 바탕으로 실행 가능한 결론을 도출하는 단계입니다. 조사 결과를 바탕으로 어떤 액션을 취할지 결정하며, 우선순위를 설정하고 구체적인 비즈니스 실행안을 마련합니다. 이때 결론은 기업의 목표와 역량을 충분히 이해한 상태에서 도출하는 것이 중요합니다. 본 게시글은 ‘오픈서베이’의 콘텐츠를 보고 영감을 받아 공유합니다. 자세한 내용은 아래 원문을 읽어보세요 🙏🏻

오픈서베이 블로그

FGI 조사 프로세스 4단계 및 단계별 주의사항

투두리스트는 누구나 한 번쯤 사용해 본 생산성 도구입니다. 하지만 단순히 "해야 할 일" 목록을 작성하는 것만으로는 복잡한 업무 환경에서 원하는 생산성을 달성하기 어렵습니다. 이번 글은 이전에 작성했던 4개의 투두리스트 관련 블로그에서 다룬 핵심 내용을 정리한 가이드로서, 투두리스트의 한계와 가능성, 그리고 이를 극복할 수 있는 새로운 접근법을 체계적으로 다룰 예정입니다.


1.

생산적인 투두리스트 가이드

효율적인 투두리스트 작성법은 단순히 목록을 나열하는 것이 아닙니다. 작성 과정에서 약간의 전략을 추가하면 더욱 효과적으로 사용할 수 있습니다.

 1. 구체적인 작업으로 쪼개기"보고서 작성" 대신 "보고서 초안 작성"처럼 명확한 작업 단위로 기록하세요. 이는 시작하기 쉽게 만들어 줍니다.
 2. 5~7개의 핵심 작업 선정하루에 처리할 수 있는 작업량을 현실적으로 정하세요. 중요한 작업을 우선적으로 나열하고, 부가적인 작업은 별도로 분류합니다.
 3. 목록을 정기적으로 검토작성한 투두리스트를 하루나 주 단위로 검토하며 완료된 항목과 남은 작업을 업데이트하세요.
    
    
투두리스트의 진정한 강점은 단순히 "할 일"을 나열하는 것이 아니라, 이를 통해 생산성과 효율성을 높이는 데 있습니다.

본 게시글은 ‘Ted lee’님의 콘텐츠를 보고 영감을 받아 공유합니다. 자세한 내용은 아래 원문을 읽어보세요 🙏🏻

효율적인 투두리스트 작성법은 단순히 목록을 나열하는 것이 아닙니다. 작성 과정에서 약간의 전략을 추가하면 더욱 효과적으로 사용할 수 있습니다. <ol ><li>구체적인 작업으로 쪼개기"보고서 작성" 대신 "보고서 초안 작성"처럼 명확한 작업 단위로 기록하세요. 이는 시작하기 쉽게 만들어 줍니다.</li><li>5~7개의 핵심 작업 선정하루에 처리할 수 있는 작업량을 현실적으로 정하세요. 중요한 작업을 우선적으로 나열하고, 부가적인 작업은 별도로 분류합니다.</li><li>목록을 정기적으로 검토작성한 투두리스트를 하루나 주 단위로 검토하며 완료된 항목과 남은 작업을 업데이트하세요. </li></ol>투두리스트의 진정한 강점은 단순히 "할 일"을 나열하는 것이 아니라, 이를 통해 생산성과 효율성을 높이는 데 있습니다. 본 게시글은 ‘Ted lee’님의 콘텐츠를 보고 영감을 받아 공유합니다. 자세한 내용은 아래 원문을 읽어보세요 🙏🏻

MOBA Blog

배경은 서비스 전체 소개가 아니라 해당 프로젝트가 왜 진행되었는지의 맥락을 소개해야 합니다.

안 좋은 배경 예시 🛑
“이 서비스는 다양한 카테고리의 상품을 제공하며, 트렌디한 고객 경험을 추구하는 글로벌 전자상거래 플랫폼입니다.”

좋은 배경 예시 ✅
“사용자가 원하는 상품을 찾는 데 시간이 오래 걸린다는 피드백이 많았습니다. 이를 해결하기 위해 탐색 경험 개선 프로젝트를 진행했습니다.”

배경은 서비스 전체 소개가 아니라 해당 프로젝트가 왜 진행되었는지의 맥락을 소개해야 합니다. 안 좋은 배경 예시 🛑“이 서비스는 다양한 카테고리의 상품을 제공하며, 트렌디한 고객 경험을 추구하는 글로벌 전자상거래 플랫폼입니다.” 좋은 배경 예시 ✅“사용자가 원하는 상품을 찾는 데 시간이 오래 걸린다는 피드백이 많았습니다. 이를 해결하기 위해 탐색 경험 개선 프로젝트를 진행했습니다.”

문제 해결형 UX 포트폴리오의 프로젝트 배경은?

🔗 <디자인 취업 고민> 오픈 채팅방을 운영 중입니다.

✋현재 정원이 다 찼습니다. 디자인 취업 고민이 있으신 분이 있다면 성함과 내용을 담아 아래 메일로 요청 부탁드립니다. 초대 코드를 보내드리겠습니다.

greenray541@gmail.com

매일 조금씩 좋아질 수 있을까? 출근하면서 질문할 때가 많았습니다. 올해 회사는 "우리는 판을 바꾼다"라고 기업문화 캠페인 슬로건을 정했고 오피스 곳곳에는 '날마다좋아지는우리', '따뜻한프로페셔널'이란 문구가 스며들었죠.

"날마다좋아지는우리, 따뜻한프로페셔널"

슬로건을 처음 접했을 때는 머리로 이해하기에 너무 개념적이고 선언적으로 느껴졌습니다.

가끔은 머리로 완전히 이해한 이후에 실행하는 것이 아니라, 실행을 하는 과정에서 조금씩 실체에 가까운 것들을 이해할 때가 있습니다. 조직문화, 핵심가치, Credo, Way of Working 등이 그러했습니다. 운이 좋게도 지금까지 다녔던 모든 회사에서 이런 슬로건을 정하거나 일방식을 정의할 때 참여했던 탓에 이런 인식이 강화된 것인지도 모르겠습니다. 머리로 완전히 이해하고 실행하려고 하면 어렵습니다. 지금은 어려운 문제를 쉽게 푸는 걸 좋아하는 편이라 어깨에 힘 좀 빼고 일단 해보면서 체득하는 중입니다.

연말엔 대표님이 발표할 자료를 만들거나 회사를 대표해 회사소식을 공유하는 날들이 있었습니다. 회사를 대표하는 자료의 스토리라인을 잡거나 직접 마이크를 들고 소식을 이야기하는 건 감사한 일이지만 부담이 됩니다. 내가 가장 잘할 수 있는 내 이야기를 하는 것과는 무게감이 다르니까요. 아직 회사에 대해 모르는 게 많을뿐더러 언제나 제 스타일이 최선이 아니라는 생각이 있으니까요.

그런데 이게 다 회사에선 결국 '일'이더라고요. 고민만 하고 제가 실행하지 않으면 누군가 그 틈을 더 채워야 하죠. 특히 정답이 없는 일이면 이게 가속도가 붙습니다. 빈 페이지를 펴놓고 고민을 해야 하는데 자기 프로젝트를 하면서 번외로 병행해야 하니 결국 개인시간을 더 쏟아야 합니다. 이런 생각을 갖고 나서야 그레이존을 채우려고 애써준 동료를 알아차릴 수 있었습니다. 동료의 애씀에 빚을 졌습니다.

내년에도 머리로 완벽히 이해하지 못하더라도 하면서 나아지는 방향을 선택할 생각입니다. 지금 저는 한창 여름인 멜버른에 머물며 한해를 회고하고 있습니다. 어수선한 시기가 선함으로 아물길 바라며, Merry Christmas! 🎄

매일 조금씩 좋아질 수 있을까? 출근하면서 질문할 때가 많았습니다. 올해 회사는 "우리는 판을 바꾼다"라고 기업문화 캠페인 슬로건을 정했고 오피스 곳곳에는 '날마다좋아지는우리', '따뜻한프로페셔널'이란 문구가 스며들었죠. "날마다좋아지는우리, 따뜻한프로페셔널" 슬로건을 처음 접했을 때는 머리로 이해하기에 너무 개념적이고 선언적으로 느껴졌습니다. 가끔은 머리로 완전히 이해한 이후에 실행하는 것이 아니라, 실행을 하는 과정에서 조금씩 실체에 가까운 것들을 이해할 때가 있습니다. 조직문화, 핵심가치, Credo, Way of Working 등이 그러했습니다. 운이 좋게도 지금까지 다녔던 모든 회사에서 이런 슬로건을 정하거나 일방식을 정의할 때 참여했던 탓에 이런 인식이 강화된 것인지도 모르겠습니다. 머리로 완전히 이해하고 실행하려고 하면 어렵습니다. 지금은 어려운 문제를 쉽게 푸는 걸 좋아하는 편이라 어깨에 힘 좀 빼고 일단 해보면서 체득하는 중입니다. 연말엔 대표님이 발표할 자료를 만들거나 회사를 대표해 회사소식을 공유하는 날들이 있었습니다. 회사를 대표하는 자료의 스토리라인을 잡거나 직접 마이크를 들고 소식을 이야기하는 건 감사한 일이지만 부담이 됩니다. 내가 가장 잘할 수 있는 내 이야기를 하는 것과는 무게감이 다르니까요. 아직 회사에 대해 모르는 게 많을뿐더러 언제나 제 스타일이 최선이 아니라는 생각이 있으니까요. 그런데 이게 다 회사에선 결국 '일'이더라고요. 고민만 하고 제가 실행하지 않으면 누군가 그 틈을 더 채워야 하죠. 특히 정답이 없는 일이면 이게 가속도가 붙습니다. 빈 페이지를 펴놓고 고민을 해야 하는데 자기 프로젝트를 하면서 번외로 병행해야 하니 결국 개인시간을 더 쏟아야 합니다. 이런 생각을 갖고 나서야 그레이존을 채우려고 애써준 동료를 알아차릴 수 있었습니다. 동료의 애씀에 빚을 졌습니다. 내년에도 머리로 완벽히 이해하지 못하더라도 하면서 나아지는 방향을 선택할 생각입니다. 지금 저는 한창 여름인 멜버른에 머물며 한해를 회고하고 있습니다. 어수선한 시기가 선함으로 아물길 바라며, Merry Christmas! 🎄

《동료의 애씀을 이해하기》

광고수익화를 시작할 때 가장 먼저 생각할 것

우리의 광고 상품이 광고주들에게 매력적으로 보여야 팔린다는 겁니다

[아티클 3문장 요약📑]

1️⃣ 광고 수익화하면 보통 eCPM, Impression 등의 성과 지표들을 떠올리게 되는데, 숫자로 표현되는 지표들이 직관적으로 이해가 쉬워서 활용도가 높지만, 결국 이 또한 결과값에 불과하다는 걸 잊어서는 안됩니다.

2️⃣ 수요와 공급 관점에서, 광고주들은 확실한 성과를 얻을 수 있어야 돈을 쓸 것이고, 1천회 노출당 평균 단가(eCPM)를 통해 이를 확인하는 것이 주류가 된 만큼, 유저에 눈에 잘 띄는, 즉 효율이 좋은 광고가 필요합니다.

3️⃣ 하지만 결국 효율이 좋은 광고일수록, 평균 단가가 높은 광고일수록 유저들의 사용성을 해치는 경우가 많기 때문에, 내 앱의 특성과 내 앱을 사용하는 유저의 성향을 잘 파악하여, 호의적인 반응 및 행동을 이끌어 낼 수 있어야 광고 수익화 전략을 설정할 수 있을 겁니다.

💡기묘한 관점➕
광고도 일종의 상품입니다. 당연히 수요와 공급의 원칙에 따라 가격과 매력도가 결정되는데요. 일반적으로 광고는 내 앱의 사용성을 저해시키기 때문에, 이를 어떤 식으로 구현하느냐는 상당히 중요해 집니다. 결국 이를 잘 하려면, 광고주와 유저들의 성향을 면밀히 파악하는 것이 필요할 거고요.

🥤트렌드라이트 구독하기
https://bit.ly/3iSbx4e

우리의 광고 상품이 광고주들에게 매력적으로 보여야 팔린다는 겁니다 [아티클 3문장 요약📑] 1️⃣ 광고 수익화하면 보통 eCPM, Impression 등의 성과 지표들을 떠올리게 되는데, 숫자로 표현되는 지표들이 직관적으로 이해가 쉬워서 활용도가 높지만, 결국 이 또한 결과값에 불과하다는 걸 잊어서는 안됩니다. 2️⃣ 수요와 공급 관점에서, 광고주들은 확실한 성과를 얻을 수 있어야 돈을 쓸 것이고, 1천회 노출당 평균 단가(eCPM)를 통해 이를 확인하는 것이 주류가 된 만큼, 유저에 눈에 잘 띄는, 즉 효율이 좋은 광고가 필요합니다. 3️⃣ 하지만 결국 효율이 좋은 광고일수록, 평균 단가가 높은 광고일수록 유저들의 사용성을 해치는 경우가 많기 때문에, 내 앱의 특성과 내 앱을 사용하는 유저의 성향을 잘 파악하여, 호의적인 반응 및 행동을 이끌어 낼 수 있어야 광고 수익화 전략을 설정할 수 있을 겁니다. 💡기묘한 관점➕광고도 일종의 상품입니다. 당연히 수요와 공급의 원칙에 따라 가격과 매력도가 결정되는데요. 일반적으로 광고는 내 앱의 사용성을 저해시키기 때문에, 이를 어떤 식으로 구현하느냐는 상당히 중요해 집니다. 결국 이를 잘 하려면, 광고주와 유저들의 성향을 면밀히 파악하는 것이 필요할 거고요. 🥤트렌드라이트 구독하기https://bit.ly/3iSbx4e

bit.ly

💰광고 수익화를 시작할 때 가장 먼저 생각해야 할 것은

커리어리 친구들, 새해 복 많이 받으세요~!! 동영상은 올리지 못해서 오픈 AI Sora로 만든 스틸컷 사진을 공유 드립니다.
가족 모두 늘 건강하시고 새해 성취하고자 하는 일 다 이루시기를!!

커리어리 친구들, 새해 복 많이 받으세요~!! 동영상은 올리지 못해서 오픈 AI Sora로 만든 스틸컷 사진을 공유 드립니다.가족 모두 늘 건강하시고 새해 성취하고자 하는 일 다 이루시기를!!

2025년, 새해 복 많이 받으세요~!!

크리에이터, 지식 공유자, 커뮤니티 빌더로 지냈던 2024년

회고/어쩌면 개발자가 아니었을지도?

누군가를 알고 싶다면 시간과 돈을 쓰는 곳을 살펴보면 돼요.

2024년의 저를 돌아보니 개발자라는 정체성 외에 다른 모습으로 보낸 시간이 길었더라고요. 크리에이터이자 지식 공유자, 커뮤니티 빌더로 많은 시간을 보냈어요. 또 테슬라 오너, 기부자, 독서가로 보내기도 했죠.

여러분의 2024년은 어땠나요? 마음 아픈 소식으로 힘든 연말, 좋았던 순간도 잠시 돌아보는 회고의 시간이 되길 바라요!

https://hajoeun.com/2024/retrospective?utm_medium=app&utm_campaign=241231&utm_source=careerly

누군가를 알고 싶다면 시간과 돈을 쓰는 곳을 살펴보면 돼요. 2024년의 저를 돌아보니 개발자라는 정체성 외에 다른 모습으로 보낸 시간이 길었더라고요. 크리에이터이자 지식 공유자, 커뮤니티 빌더로 많은 시간을 보냈어요. 또 테슬라 오너, 기부자, 독서가로 보내기도 했죠. 여러분의 2024년은 어땠나요? 마음 아픈 소식으로 힘든 연말, 좋았던 순간도 잠시 돌아보는 회고의 시간이 되길 바라요! https://hajoeun.com/2024/retrospective?utm_medium=app&amp;utm_campaign=241231&amp;utm_source=careerly

hajoeun.com

2024년 회고, 어쩌면 개발자가 아니었을지도?

현대적인 JavaScript를 쓰면서도 넓은 범위의 기기를 지원하기 위한 Polyfill을 어떻게 똑똑하게 설정할 수 있는지 소개합니다.

똑똑하게 브라우저 Polyfill 관리하기

프론트엔드 개발자에게 하위 브라우저 호환성 문제는 피할 수 없는 과제입니다. 모든 서비스에는 구형 브라우저를 사용하는 사용자가 존재하며, 이를 무시할 수 없기 때문인데요.

이런 문제를 해결하기 위해 Polyfill을 사용하지만 Polyfill을 사용하는 데도 단점이 있습니다. 불필요한 Polyfill 스크립트까지 다운로드하게 되는 경우가 생기며, 이는 JavaScript 코드의 크기를 증가시키고 사용자 경험(UX)에 영향을 미칠 수 있기 때문인데요. 특히 최신 브라우저를 사용하는 사용자에게도 필요 없는 Polyfill이 포함되어 로드 속도를 저하시킬 수 있습니다.

이러한 문제를 해결하기 위해, 토스 에서 동적으로 필요한 Polyfill만 제공하는 자체 Polyfill 서비스를 구축한 블로그 아티클을 재미있게 읽었습니다. 이 접근 방식은 브라우저 환경에 따라 꼭 필요한 Polyfill만 제공함으로써, 불필요한 스크립트 로드를 방지하고 성능을 극대화하는데요.

구현 방식
 1. User-Agent 기반 브라우저별 맞춤형 Polyfill 생성
    * 클라이언트(브라우저)가 Polyfill 서버에 요청을 보낼 때, 요청 헤더에 포함된 User-Agent 정보를 기반으로 브라우저 정보를 추출합니다.
    * 이 과정에서
      browserslist-useragent
      라이브러리를 사용해 브라우저와 필요한 기능을 매핑합니다.
 2. esbuild를 활용한 Polyfill 스크립트 생성
    * 생성된 Polyfill 목록을 기반으로
      core-js
      모듈에서 필요한 Polyfill을 가져와 JavaScript 코드를 생성합니다.
    * esbuild
      를 활용해 Polyfill 스크립트를 하나로 묶고, 크기를 줄이기 위해 압축 및 최적화를 수행합니다.
 3. Polyfill 서버 배포
    * 생성된 Polyfill 스크립트는 Node.js 서버 또는 AWS Lambda 같은 서버리스 환경에 배포됩니다.
    * 클라이언트가 서버에 요청을 보내면 해당 브라우저에 필요한 Polyfill만 포함된 최적화된 스크립트를 실시간으로 반환합니다.

사실 번들 크기의 최적화는 모든 프로젝트에서 최우선 과제가 아닐 수 있습니다. 그러나 저속 네트워크나 저사양 기기를 사용하는 환경에서는 번들 크기에 다라 사용자 경험에 직접적인 영향을 미칠 수 있습니다. 특히 이러한 환경일 경우 사용자들은 로딩 속도에 더욱 민감하게 반응하므로, 동적 Polyfill 서비스를 통한 최적화는 의미 있는 개선이 될 수 있습니다.

또한 이러한 접근 방식은 개발과 사용자 경험 모두에서 win-win 전략이 될수 있다고 느꼇습니다. 개발자는 최신 JavaScript 기능을 제약 없이 활용할 수 있고, 사용자는 자신의 브라우저 환경에 관계없이 항상 최적화된 성능과 안정적인 서비스를 경험할 수 있기 때문입니다.

https://toss.tech/article/smart-polyfills

프론트엔드 개발자에게 하위 브라우저 호환성 문제는 피할 수 없는 과제입니다. 모든 서비스에는 구형 브라우저를 사용하는 사용자가 존재하며, 이를 무시할 수 없기 때문인데요. 이런 문제를 해결하기 위해 Polyfill을 사용하지만 Polyfill을 사용하는 데도 단점이 있습니다. 불필요한 Polyfill 스크립트까지 다운로드하게 되는 경우가 생기며, 이는 JavaScript 코드의 크기를 증가시키고 사용자 경험(UX)에 영향을 미칠 수 있기 때문인데요. 특히 최신 브라우저를 사용하는 사용자에게도 필요 없는 Polyfill이 포함되어 로드 속도를 저하시킬 수 있습니다. 이러한 문제를 해결하기 위해, 토스 에서 동적으로 필요한 Polyfill만 제공하는 자체 Polyfill 서비스를 구축한 블로그 아티클을 재미있게 읽었습니다. 이 접근 방식은 브라우저 환경에 따라 꼭 필요한 Polyfill만 제공함으로써, 불필요한 스크립트 로드를 방지하고 성능을 극대화하는데요. 구현 방식<ol ><li>User-Agent 기반 브라우저별 맞춤형 Polyfill 생성<ul ><li>클라이언트(브라우저)가 Polyfill 서버에 요청을 보낼 때, 요청 헤더에 포함된 User-Agent 정보를 기반으로 브라우저 정보를 추출합니다.</li><li>이 과정에서 <code >browserslist-useragent</code> 라이브러리를 사용해 브라우저와 필요한 기능을 매핑합니다.</li></ul></li><li>esbuild를 활용한 Polyfill 스크립트 생성<ul ><li>생성된 Polyfill 목록을 기반으로 <code >core-js</code> 모듈에서 필요한 Polyfill을 가져와 JavaScript 코드를 생성합니다.</li><li><code >esbuild</code>를 활용해 Polyfill 스크립트를 하나로 묶고, 크기를 줄이기 위해 압축 및 최적화를 수행합니다.</li></ul></li><li>Polyfill 서버 배포<ul ><li>생성된 Polyfill 스크립트는 Node.js 서버 또는 AWS Lambda 같은 서버리스 환경에 배포됩니다.</li><li>클라이언트가 서버에 요청을 보내면 해당 브라우저에 필요한 Polyfill만 포함된 최적화된 스크립트를 실시간으로 반환합니다.</li></ul></li></ol> 사실 번들 크기의 최적화는 모든 프로젝트에서 최우선 과제가 아닐 수 있습니다. 그러나 저속 네트워크나 저사양 기기를 사용하는 환경에서는 번들 크기에 다라 사용자 경험에 직접적인 영향을 미칠 수 있습니다. 특히 이러한 환경일 경우 사용자들은 로딩 속도에 더욱 민감하게 반응하므로, 동적 Polyfill 서비스를 통한 최적화는 의미 있는 개선이 될 수 있습니다. 또한 이러한 접근 방식은 개발과 사용자 경험 모두에서 win-win 전략이 될수 있다고 느꼇습니다. 개발자는 최신 JavaScript 기능을 제약 없이 활용할 수 있고, 사용자는 자신의 브라우저 환경에 관계없이 항상 최적화된 성능과 안정적인 서비스를 경험할 수 있기 때문입니다. https://toss.tech/article/smart-polyfills

toss.tech

동적 Polyfill 서비스로 실현하는 토스의 브라우저 호환성

한 유튜버의 면접자가 실제로 썼던 코드라네요ㅋㅋ 창의성으로 통과시켜주고 싶었으나 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에 삽입해 진행하는 방법 - 저는 필수가 아닌 이상 두 번째 방법을 추천합니다. - 라이브 시연은 생생함과 어필력을 제공하지만, 시간 조절이 어렵고 실수의 가능성이 있으며, 발표 흐름이 끊길 수 있는 단점이 있습니다. - 미리 녹화한 영상은 시간 활용이 정확하고 편집이 가능해 청중이 이해하기 쉽습니다. - 때문에 가능하면 녹화된 시연 영상을 활용하시기를 권장합니다.

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

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

 - YouTube

최근 프론트엔드 개발에서 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/

www.youtube.com

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리그 프로그래머

이상인의 디지털 트랜스포메이션(17)

[포브스 기고 / 사용자 경험은 B2B에서도 재미있어야 한다]

디지털 세계에서는 일반 유저를 대상으로 하던 B2B 디자인이 B2C 영역으로까지 확대되고 있다. 클라우드 시대가 본격화되면서 사용자 경험이 갈수록 중요해지기 때문이다.

포브스 코리아

프로덕트 매니저/서비스 기획

한주현

Leehyerin

김진홍

Staff design lead / Design system 

Product designer

Design director

Principal design director

Graphic design

지금 미국 디지털 디자인 씬에서 가장 주목받는 한국인 디자이너.
글로벌 회계 컨설팅 그룹인 딜로이트 컨설팅(Deloitte Consulting) 뉴욕 스튜디오의 Design Director(디자인 총책임)을 거쳐 현재 Microsoft 클라우드+인공지능부서의 Creative Director로 디자인 랭귀지를 책임지고 있다.
디지털 트렌스포메이션과 경험 디자인(UX/UI), 브랜딩을 주로 하고 있으며, 유학생으로서 미국에서 디자이너로 데뷔하고 글로벌 기업 디자인팀의 총책임자가 되기까지 일, 생활, 디자이너로서의 관점을 기록한 글이 SNS 채널을 통해 3만 회 이상 공유되면서 6천여 명 이상의 팔로워들에게 꾸준히 읽히고 있다.

이상인

링크

디자이너의 생각법; 시프트 저자 / 현 구글의 유튜브 광고 디자인 시스템 리드. / Prev 마이크로소프트 클라우드 + 인공지능 부서 디자인 디렉터, 딜로이트 디지털 뉴욕 스튜디오 창립 멤버, R/GA 프로덕트 이노베이션 디자이너

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필