MLOps에 대해서 알아보자

데브옵스는 많이 들어보셨죠? DevOps를 간략하게 설명하자면 development(개발)와 operations(운영)를 합친 용어로써, 개발과 운영을 보다 효과적이게 하는 관행이라고 할 수 있을 것 같습니다. 간단하게는 소프트웨어 개발 및 배포를 매끄럽게 해주는 거라고 생각하면 될 것 같습니다.

DevOps는 Dev + Ops를 의미하며 개발과 운영의 통합이라면, MLOps는 ML + Ops를 의미하며 머신러닝과 운영의 통합을 의미합니다. 머신러닝 시스템 + 자동화라고 할 수 있겠네요.

자세한 내용은 아래에서 확인해보세요!

https://monday9pm.com/mlops%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-40d372adc2ad

데브옵스는 많이 들어보셨죠? DevOps를 간략하게 설명하자면 development(개발)와 operations(운영)를 합친 용어로써, 개발과 운영을 보다 효과적이게 하는 관행이라고 할 수 있을 것 같습니다. 간단하게는 소프트웨어 개발 및 배포를 매끄럽게 해주는 거라고 생각하면 될 것 같습니다. DevOps는 Dev + Ops를 의미하며 개발과 운영의 통합이라면, MLOps는 ML + Ops를 의미하며 머신러닝과 운영의 통합을 의미합니다. 머신러닝 시스템 + 자동화라고 할 수 있겠네요. 자세한 내용은 아래에서 확인해보세요! https://monday9pm.com/mlops%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-40d372adc2ad

Medium

MLOps에 대해 알아보자!

Samsung Developer Conference Korea 2O24

SDC24 Korea에서 소프트웨어의 새롭고 다양한 지식과 경험을 배우고, 사전등록을 통해 온오프라인으로 다양한 이벤트에 참여하세요.

Samsung Softeware Developer Conference(SSDC)가 Samaung Developer Conference Korea(SDC Korea)로 명칭을 변경하였습니다.
 * 사전등록 : 10월29일 ~11월21일
 * 행사기간 : 11월21일
   
https://sdc-korea.com

SDC24 Korea에서 소프트웨어의 새롭고 다양한 지식과 경험을 배우고, 사전등록을 통해 온오프라인으로 다양한 이벤트에 참여하세요. Samsung Softeware Developer Conference(SSDC)가 Samaung Developer Conference Korea(SDC Korea)로 명칭을 변경하였습니다.<ul><li>사전등록 : 10월29일 ~11월21일</li><li>행사기간 : 11월21일 </li></ul>https://sdc-korea.com

sdc-korea.com

Samsung Developer Conference Korea 2024

퇴근 후에도 울리는 슬랙 메시지가 사라진 일상이 낯설다. 마음 편히 휴대폰을 두고 산책을 나가며 퇴사를 실감한다. 2024년 10월 29일. 4년 3개월을 몸 담았던 우아한형제들을 떠나며 글로 아쉬움을 달래본다. 우아한형제들에서 배운 것들 4년 전, 코로나로 세상은 변하고 있는데 나만 고요한 것 같아 변화가 필요하다고 생각했다. 평소 선망의 대상이었던 우아한형제들에 합류하게 된다. 코로나가 전국적으로 퍼지면서 길고 긴 재택근무에 돌입한다. 처음에는 친분이 없는 사람들과 재택근무로 하는 협업이 낯설어서 커뮤니케이션 방법에 대해 고민이 많았다. 이후 딜리버리 시장이 성장하면서 내가 담당하는 프로덕트도 늘어나는 사용자에 맞게 발맞춰 대응해야 했다. 수기로 처리하던 모든 가입단계를 앱에 내재화하고, 사용자 가입..

퇴사를 하며

4년3개월의 시간을 보내고 우아한형제들에서 졸업합니다. 모든 순간이 배움이었고 성장이었던, 그리고 '동료가 복지'였던 시간들을 정리합니다.

4년3개월의 시간을 보내고 우아한형제들에서 졸업합니다. 모든 순간이 배움이었고 성장이었던, 그리고 '동료가 복지'였던 시간들을 정리합니다.

기획이 체질

우아한형제들에서 퇴사하며

이력서, 채용 공고, 연봉 정보는 물론 프리랜서 프로젝트까지! 신입 취업 및 경력직 이직, 커리어 성장에 필요한 모든 것을 만나보세요.

2024 현대카드 Tech Talk | 원티드

오오 현대카드에서도 테크 컨퍼런스를 여는군요!
금융 데이터를 많이 가지고 있는 곳인 만큼 Data 그리고 AI 관련한 세션이 주로 진행되는 것으로 보입니다.

https://www.wanted.co.kr/events/2024hyundaicard_techtalk

오오 현대카드에서도 테크 컨퍼런스를 여는군요! 금융 데이터를 많이 가지고 있는 곳인 만큼 Data 그리고 AI 관련한 세션이 주로 진행되는 것으로 보입니다. https://www.wanted.co.kr/events/2024hyundaicard_techtalk

원티드

2024 현대카드 테크 톡

팀네이버 컨퍼런스 DAN 24는 네이버의 비즈니스 전략과 기술, 크리에이티브, 그리고 다양한 경험의 전문성을 유기적으로 연결하여 네이버가 앞으로 만들어나갈 비즈니스, 서비스의 변화 방향을 제시하는 자리입니다.

DAN 24

📌 네이버의 비즈니스 전략과 기술, 크리에이티브가 결합된 통합 컨퍼런스 DAN 24의 일반인 신청 오픈이 10/30-31 15:00에 진행됩니다.

이번 DAN 24는 'NEXT, N: 새로운 도약, 변화하는 네이버'라는 주제로 진행되며, 기존의 개발 컨퍼런스인 DEVIEW까지 합쳐진 진정한 의미의 통합 컨퍼런스입니다. 🙂

참가신청 및 주요 세션과 프로그램 정보는 아래 DAN 24 웹사이트에서 확인하실 수 있습니다.

📌 네이버의 비즈니스 전략과 기술, 크리에이티브가 결합된 통합 컨퍼런스 DAN 24의 일반인 신청 오픈이 10/30-31 15:00에 진행됩니다. 이번 DAN 24는 'NEXT, N: 새로운 도약, 변화하는 네이버'라는 주제로 진행되며, 기존의 개발 컨퍼런스인 DEVIEW까지 합쳐진 진정한 의미의 통합 컨퍼런스입니다. 🙂 참가신청 및 주요 세션과 프로그램 정보는 아래 DAN 24 웹사이트에서 확인하실 수 있습니다.

dan.naver.com

팀 네이버 컨퍼런스 DAN 24 신청이 곧 시작됩니다 : )

Write Down the Plan

엔지니어로서 일하면서 우리는 얼마나 자주 우리의 계획을 문서화하고 있을까요? 많은 경우 계획을 머릿속에만 담아두거나 구두로만 설명하고 끝내곤 합니다. 이 글에서는 "성장하는 엔지니어들"이나 "리더들"은 '계획을 글로 남기는' 습관을 가진 사람들이 많다고 합니다. 필자는 자신의 경험을 통해 이 습관이 프로모션과 성장을 가속화했다고 전하고 있습니다. 그렇다면, 계획을 문서화하는 습관이 우리에게 어떤 이점을 줄 수 있을까요?

 * 사고력 향상: 글로 생각을 정리하다 보면 논리적 서사로 전개되며 생각이 더 명확해집니다. 간결하게 쓰려는 과정에서 문제의 최적화나 추가적인 예외 상황을 발견하게 되는 경우도 많습니다.

 * 팀원 간의 정렬 (Alignment) 구축: 계획을 문서로 작성해 공유하면, 피드백을 받으면서 점차 팀원 모두가 같은 페이지에 있게 됩니다. 이를 통해 사전에 이견을 조율하고, 합의를 얻는 과정이 훨씬 수월해집니다.

 * 자신의 가시성 및 인지도 상승: 작성된 계획을 공유하면, 동료나 리더가 그 계획과 성과를 자연스럽게 연결지어 생각하게 됩니다. 덕분에 평가나 성과 회의에서도 미리 인지된 성과가 도움이 되어 보다 원활한 논의가 가능합니다.

이 블로그 글에서는 위와 같은 문서화 습관 덕분에 커리어의 여러 기회를 얻었다고 하는데요. 여러분들은 지금까지의 프로젝트에서 '글로 계획을 남기는' 습관을 얼마나 실천해 보셨나요? 다음 번 프로젝트에서는 이 습관을 도입해 보고 그 효과를 직접 경험해 보는 건 어떨까요?

https://www.developing.dev/p/write-down-the-plan

엔지니어로서 일하면서 우리는 얼마나 자주 우리의 계획을 문서화하고 있을까요? 많은 경우 계획을 머릿속에만 담아두거나 구두로만 설명하고 끝내곤 합니다. 이 글에서는 "성장하는 엔지니어들"이나 "리더들"은 '계획을 글로 남기는' 습관을 가진 사람들이 많다고 합니다. 필자는 자신의 경험을 통해 이 습관이 프로모션과 성장을 가속화했다고 전하고 있습니다. 그렇다면, 계획을 문서화하는 습관이 우리에게 어떤 이점을 줄 수 있을까요? <ul ><li>사고력 향상: 글로 생각을 정리하다 보면 논리적 서사로 전개되며 생각이 더 명확해집니다. 간결하게 쓰려는 과정에서 문제의 최적화나 추가적인 예외 상황을 발견하게 되는 경우도 많습니다.</li></ul> <ul ><li>팀원 간의 정렬 (Alignment) 구축: 계획을 문서로 작성해 공유하면, 피드백을 받으면서 점차 팀원 모두가 같은 페이지에 있게 됩니다. 이를 통해 사전에 이견을 조율하고, 합의를 얻는 과정이 훨씬 수월해집니다.</li></ul> <ul ><li>자신의 가시성 및 인지도 상승: 작성된 계획을 공유하면, 동료나 리더가 그 계획과 성과를 자연스럽게 연결지어 생각하게 됩니다. 덕분에 평가나 성과 회의에서도 미리 인지된 성과가 도움이 되어 보다 원활한 논의가 가능합니다.</li></ul> 이 블로그 글에서는 위와 같은 문서화 습관 덕분에 커리어의 여러 기회를 얻었다고 하는데요. 여러분들은 지금까지의 프로젝트에서 '글로 계획을 남기는' 습관을 얼마나 실천해 보셨나요? 다음 번 프로젝트에서는 이 습관을 도입해 보고 그 효과를 직접 경험해 보는 건 어떨까요? https://www.developing.dev/p/write-down-the-plan

www.developing.dev

계획을 글로 써보기

계란후라이 1101

같은 책을 읽고 다른 사람과 읽은 내용에 대해서 이야기를 나누는 것은 흥미롭습니다. 같은 활자를 읽고 다르게 해석할 수 있다는 점과 다른 해석을 통해 새로운 깨달음을 얻을 수 있는 점이 흥미롭습니다.
분명히 사물의 같은 면을 바라보았다면, 같은 해석을 내릴 것입니다. 그런데 사람에 따라 사물의 옆면과 뒷면을 들춰 보기도 합니다. 사물을 바라보는 시야에 따라서 같은 것을 보고도 다른 해석을 내리는 것입니다.
이와 같은 다른 사람의 시야를 읽으면 새로운 깨달음을 얻습니다. 전에 몰랐던 감춰진 보물을 발견한 느낌입니다. 정면만 있는 줄 알았는데, 옆면과 뒷면도 있었다는 사실과 그렇게 사물의 다른 면을 보려고 노력하는 사람도 있다는 점이 신기합니다. (노력하는 사람도 있겠지만, 태어날 때부터 남다른 시선을 가진 분도 있습니다)
아이언 맨이 슈트를 개발한 때 입체 화면을 띄워놓고 요리조리 돌려 보는 것처럼 이슈를 대할 때 표면만 훑어보지 않고, 안팎으로 꼼꼼히 따져 보아야 근본적인 내용을 이해할 수 있습니다.
단면을 놓고 판단을 하면 오해와 오류가 발생합니다. 전면을 놓고 사방으로 관찰해야 누락 없이, 오해 없이 제대로 이해할 수 있다고 믿습니다. 책을 읽을 때 단어에 집중하는 것이 아니라 지은이의 생각과 마음을 헤아려 보려고 노력합니다. 물론 어떻게 지은이의 생각을 다 헤아릴 수 있겠습니까? 그냥 그러려니 알기도 합니다.
대화가 어려운 이유도 비슷합니다. 아무리 자세히 설명해도 이해하기 어려운 내용이 있고 전달하기 어려운 내용도 있습니다. 최대한 풀어서 설명하지만 전달되기 어려운 내용은 듣는 이가 아무리 표현의 사방을 둘러보아도 말하는 사람의 뜻을 정확히 이해하기 어렵습니다.
이렇게 사람의 생각을 읽고 이해하는 것이 어렵지만, 재미있고 유익합니다. 대화를 통해서 서로 다른 생각을 교류하는 것이 새로운 일을 배우는 데 큰 도움이 됩니다.
우리 책 많이 읽고 가까운 사람과 대화를 많이 나눕시다. 책과 사람에게 지식과 노하우가 있습니다. 책과 사람을 통해 단면을 꿰뚫는 통찰력을 얻는 우리가 되길 진심으로 응원합니다.

계란후라이 1101 같은 책을 읽고 다른 사람과 읽은 내용에 대해서 이야기를 나누는 것은 흥미롭습니다. 같은 활자를 읽고 다르게 해석할 수 있다는 점과 다른 해석을 통해 새로운 깨달음을 얻을 수 있는 점이 흥미롭습니다.분명히 사물의 같은 면을 바라보았다면, 같은 해석을 내릴 것입니다. 그런데 사람에 따라 사물의 옆면과 뒷면을 들춰 보기도 합니다. 사물을 바라보는 시야에 따라서 같은 것을 보고도 다른 해석을 내리는 것입니다.이와 같은 다른 사람의 시야를 읽으면 새로운 깨달음을 얻습니다. 전에 몰랐던 감춰진 보물을 발견한 느낌입니다. 정면만 있는 줄 알았는데, 옆면과 뒷면도 있었다는 사실과 그렇게 사물의 다른 면을 보려고 노력하는 사람도 있다는 점이 신기합니다. (노력하는 사람도 있겠지만, 태어날 때부터 남다른 시선을 가진 분도 있습니다)아이언 맨이 슈트를 개발한 때 입체 화면을 띄워놓고 요리조리 돌려 보는 것처럼 이슈를 대할 때 표면만 훑어보지 않고, 안팎으로 꼼꼼히 따져 보아야 근본적인 내용을 이해할 수 있습니다.단면을 놓고 판단을 하면 오해와 오류가 발생합니다. 전면을 놓고 사방으로 관찰해야 누락 없이, 오해 없이 제대로 이해할 수 있다고 믿습니다. 책을 읽을 때 단어에 집중하는 것이 아니라 지은이의 생각과 마음을 헤아려 보려고 노력합니다. 물론 어떻게 지은이의 생각을 다 헤아릴 수 있겠습니까? 그냥 그러려니 알기도 합니다.대화가 어려운 이유도 비슷합니다. 아무리 자세히 설명해도 이해하기 어려운 내용이 있고 전달하기 어려운 내용도 있습니다. 최대한 풀어서 설명하지만 전달되기 어려운 내용은 듣는 이가 아무리 표현의 사방을 둘러보아도 말하는 사람의 뜻을 정확히 이해하기 어렵습니다.이렇게 사람의 생각을 읽고 이해하는 것이 어렵지만, 재미있고 유익합니다. 대화를 통해서 서로 다른 생각을 교류하는 것이 새로운 일을 배우는 데 큰 도움이 됩니다.우리 책 많이 읽고 가까운 사람과 대화를 많이 나눕시다. 책과 사람에게 지식과 노하우가 있습니다. 책과 사람을 통해 단면을 꿰뚫는 통찰력을 얻는 우리가 되길 진심으로 응원합니다.

꿈을 찾는 사람에게 보내는 289 번째 편지

스닙팟 (snippod.com) 내에서 개별 포스팅 (스닙) 검색 기능을 아직 구현하지 못해 안타까웠는데요.

ChatGPT search 가 출시되었길래... 바로 테스트.
"스닙팟에서 앤트로픽에 대한 스닙 링크를 모아줘" 라고 물어보니 완벽하게 대답을... 🤯

이렇게나 스닙팟 을 속속들이 크롤링 해갔다뉘. OpenAI, Thank you... 😅

스닙팟 (snippod.com) 내에서 개별 포스팅 (스닙) 검색 기능을 아직 구현하지 못해 안타까웠는데요. ChatGPT search 가 출시되었길래... 바로 테스트. "스닙팟에서 앤트로픽에 대한 스닙 링크를 모아줘" 라고 물어보니 완벽하게 대답을... 🤯 이렇게나 스닙팟 을 속속들이 크롤링 해갔다뉘. OpenAI, Thank you... 😅

1. 데이터 엔지니어와 데이터 사이언티스트 직군은 + 30%의 성장세를 보입니다.
2. 데이터베이스 및 데이터 엔트리와 같은 직군은 데이터 엔지니어에 의해 대체되거나 감소하는 경향을 보입니다.
3. 데이터 분석가는 AI에 의해 대체된다는 말이 많았지만 여전히 성장세를 보이고 있습니다.
4. 단순 데이터 직군뿐만 아니라 세일즈, 마케팅, 기획, 그리고 CX까지 모두 데이터 역량을 요구하는 경우가 많아지고 있습니다.

Credit by: Live Data Technologies

1. 데이터 엔지니어와 데이터 사이언티스트 직군은 + 30%의 성장세를 보입니다. 2. 데이터베이스 및 데이터 엔트리와 같은 직군은 데이터 엔지니어에 의해 대체되거나 감소하는 경향을 보입니다. 3. 데이터 분석가는 AI에 의해 대체된다는 말이 많았지만 여전히 성장세를 보이고 있습니다. 4. 단순 데이터 직군뿐만 아니라 세일즈, 마케팅, 기획, 그리고 CX까지 모두 데이터 역량을 요구하는 경우가 많아지고 있습니다. Credit by: Live Data Technologies

5년간 데이터 직군의 성장률 분석

계란후라이 1100

대화는 두 명 이상이 팀을 이뤄 목표를 달성해 가는 과정에서 반드시 필요한 것입니다. 같은 목표를 향해 각자 맡은 일을 수행하며 때때로 중간 성과를 공유하며 서로를 동기 부여할 수 있습니다.
리더는 팀원과 수시로 대화하며 프로젝트의 상태를 체크하는 것이 완성된 결과의 품질을 높이는 방법입니다. 마이크로 매니징이 아니라 팀원이 어려움을 겪고 있어서 도움이 필요하거나 최초 목표와 같은 방향으로 프로젝트가 흘러가고 있는지 확인하는 것이 대화의 순기능입니다.
어려움도 어렵지 않게 이야기할 수 있는 관계는 신뢰와 존중에서 비롯된다고 생각합니다. 리더는 팀원을, 팀원을 리더를 신뢰하고 존중할 때 비로소 어떤 주제로도 대화가 가능합니다. 반면 신뢰가 없다면 피상적인 이야기만 오고 가는 대화가 됩니다. 묻는 말에만 대답하고 생각과 느낌을 교류하지 못합니다.
리더와 팀원이 서로 존중하는 관계를 만들기 위해 필요한 것은 서로에게 도움이 되는 존재가 되겠다고 결심하는 것입니다. 아이러니하죠? 신뢰가 없는데 어떻게 서로를 위할 수가 있죠? 팀으로 만나 협업하겠다고 결심했다면 리더와 팀원은 서로를 돕겠다고 언약했다고 생각합니다. 이와 같은 마음가짐에서 경험이 쌓이면 신뢰가 싹튼다고 믿습니다.
강점을 발견하고 개발할 수 있는 가장 좋은 방법이 피드백이라고 배웠습니다. 피드백도 결국 대화의 한 조각이라고 생각합니다. 리더는 팀원을 관찰하고 발견한 사실을 팀원에게 알려주는 것이 피드백입니다. 피드백은 성장을 돕는 장치입니다. 위에서 대화가 필요한 이유와 비슷합니다. 동반자로서 함께 걷는데 속도와 박자를 맞추기 위해 필요한 조언이 피드백이라고 생각합니다.
칭찬은 고래도 춤추게 한답니다. 결과가 좋지 않았던 일을 피드백할 때 리더는 먼저 팀원이 과정에서 기울인 노력과 결과에 대한 노고를 칭찬할 수 있어야 합니다. 그다음 개선이 필요한 사항을 객관적으로 전달하는 것이죠. 심리적 지지와 객관적 요구가 만나 피드백을 이룹니다. 성장을 돕는 피드백이 건강한 팀을 이루는 문화가 된다고 믿습니다.

계란후라이 1100 대화는 두 명 이상이 팀을 이뤄 목표를 달성해 가는 과정에서 반드시 필요한 것입니다. 같은 목표를 향해 각자 맡은 일을 수행하며 때때로 중간 성과를 공유하며 서로를 동기 부여할 수 있습니다.리더는 팀원과 수시로 대화하며 프로젝트의 상태를 체크하는 것이 완성된 결과의 품질을 높이는 방법입니다. 마이크로 매니징이 아니라 팀원이 어려움을 겪고 있어서 도움이 필요하거나 최초 목표와 같은 방향으로 프로젝트가 흘러가고 있는지 확인하는 것이 대화의 순기능입니다.어려움도 어렵지 않게 이야기할 수 있는 관계는 신뢰와 존중에서 비롯된다고 생각합니다. 리더는 팀원을, 팀원을 리더를 신뢰하고 존중할 때 비로소 어떤 주제로도 대화가 가능합니다. 반면 신뢰가 없다면 피상적인 이야기만 오고 가는 대화가 됩니다. 묻는 말에만 대답하고 생각과 느낌을 교류하지 못합니다.리더와 팀원이 서로 존중하는 관계를 만들기 위해 필요한 것은 서로에게 도움이 되는 존재가 되겠다고 결심하는 것입니다. 아이러니하죠? 신뢰가 없는데 어떻게 서로를 위할 수가 있죠? 팀으로 만나 협업하겠다고 결심했다면 리더와 팀원은 서로를 돕겠다고 언약했다고 생각합니다. 이와 같은 마음가짐에서 경험이 쌓이면 신뢰가 싹튼다고 믿습니다.강점을 발견하고 개발할 수 있는 가장 좋은 방법이 피드백이라고 배웠습니다. 피드백도 결국 대화의 한 조각이라고 생각합니다. 리더는 팀원을 관찰하고 발견한 사실을 팀원에게 알려주는 것이 피드백입니다. 피드백은 성장을 돕는 장치입니다. 위에서 대화가 필요한 이유와 비슷합니다. 동반자로서 함께 걷는데 속도와 박자를 맞추기 위해 필요한 조언이 피드백이라고 생각합니다.칭찬은 고래도 춤추게 한답니다. 결과가 좋지 않았던 일을 피드백할 때 리더는 먼저 팀원이 과정에서 기울인 노력과 결과에 대한 노고를 칭찬할 수 있어야 합니다. 그다음 개선이 필요한 사항을 객관적으로 전달하는 것이죠. 심리적 지지와 객관적 요구가 만나 피드백을 이룹니다. 성장을 돕는 피드백이 건강한 팀을 이루는 문화가 된다고 믿습니다.

꿈을 찾는 사람에게 보내는 288 번째 편지

NAVER D2

﻿
순간적으로 트래픽이 급증하는 서비스를 운영하다 보면 단순히 서버를 늘리는 것만으로 해결이 안되는 경우가 있습니다. 또한 동시성 해결을 위해서 다양한 락(Lock)을 적용하여 처리한다고 해도 서비스를 온전히 사용하는 사용자가 있는 반면, 비즈니스 로직이나 상황에 따라서는 일부 사용자들은 정상적으로 사용이 어려운 경우가 생기기 마련인데요. 인기 있는 음식점을 가면 한정된 공간 안에 손님들을 모시기 위해 대부분 마련한 번호표 시스템처럼 서비스에도 "대기열 시스템" 을 적용해 보는 것도 검토의 대상이라 생각을 해봅니다.

네이버페이 주문에 적용된 확장 대기열 개발기라는 주제로 확장성에 초점을 두고 시스템 설계 측면에서 설명하는 글이 있어 공유합니다.

특히, 일반적인 폴링 형태로 사용자가 대기열을 통과 가능한지 체크하는 방식이 아닌 사용자와 대기열 사이에 중계 서버를 둬서 순번에 맞는 사용자만 통과시키는 방식이라든지 대기표 관리를 범위로써 관리하여 데이터베이스 관점에서 좀 더 유연한 구조를 가져간 점이 특징이라 볼 수 있는 것 같습니다.

https://d2.naver.com/helloworld/6480558

﻿순간적으로&nbsp;트래픽이&nbsp;급증하는&nbsp;서비스를&nbsp;운영하다 보면&nbsp;단순히&nbsp;서버를&nbsp;늘리는&nbsp;것만으로&nbsp;해결이&nbsp;안되는&nbsp;경우가&nbsp;있습니다.&nbsp;또한&nbsp;동시성&nbsp;해결을&nbsp;위해서&nbsp;다양한&nbsp;락(Lock)을&nbsp;적용하여&nbsp;처리한다고&nbsp;해도&nbsp;서비스를&nbsp;온전히&nbsp;사용하는&nbsp;사용자가&nbsp;있는&nbsp;반면,&nbsp;비즈니스&nbsp;로직이나&nbsp;상황에&nbsp;따라서는&nbsp;일부&nbsp;사용자들은&nbsp;정상적으로&nbsp;사용이&nbsp;어려운&nbsp;경우가&nbsp;생기기&nbsp;마련인데요.&nbsp;인기 있는&nbsp;음식점을&nbsp;가면&nbsp;한정된&nbsp;공간 안에&nbsp;손님들을&nbsp;모시기&nbsp;위해&nbsp;대부분&nbsp;마련한&nbsp;번호표&nbsp;시스템처럼&nbsp;서비스에도&nbsp;"대기열&nbsp;시스템"&nbsp;을&nbsp;적용해 보는&nbsp;것도&nbsp;검토의&nbsp;대상이라&nbsp;생각을&nbsp;해봅니다. 네이버페이 주문에 적용된 확장 대기열 개발기라는 주제로 확장성에 초점을 두고 시스템 설계 측면에서 설명하는 글이 있어 공유합니다. 특히,&nbsp;일반적인&nbsp;폴링 형태로&nbsp;사용자가&nbsp;대기열을&nbsp;통과&nbsp;가능한지&nbsp;체크하는&nbsp;방식이&nbsp;아닌&nbsp;사용자와&nbsp;대기열&nbsp;사이에&nbsp;중계&nbsp;서버를&nbsp;둬서&nbsp;순번에&nbsp;맞는&nbsp;사용자만&nbsp;통과시키는&nbsp;방식이라든지&nbsp;대기표&nbsp;관리를&nbsp;범위로써&nbsp;관리하여&nbsp;데이터베이스&nbsp;관점에서&nbsp;좀 더&nbsp;유연한&nbsp;구조를&nbsp;가져간&nbsp;점이&nbsp;특징이라&nbsp;볼 수&nbsp;있는 것&nbsp;같습니다. https://d2.naver.com/helloworld/6480558

d2.naver.com

네이버페이 주문에 적용된 확장 가능한 대기열 개발기

컴포넌트 기반 UI 개발의 패러다임을 주도한 React가 등장한지도 어느 덧 10년이 넘었네요. 이제 Vue.js, Svelte, Angular 등 어떤 프론트엔드 프레임워크를 사용하든 현대 웹 개발에서 컴포넌트 기반으로 UI 개발하는 것은 거의 당연한 얘기가 되었죠. 그리고 마침내 웹 컴포넌트(Web Components)를 통해서 별다른 프론트엔드 프레임워크가 없어도 UI 컴포넌트를 만들 수 있는 길이 활짝 열렸습니다.

웹 컴포넌트는 웹사이트나 애플리케이션에서 UI를 모듈화하고 재사용할 수도록 해주는 웹 표준 기술입니다. React와 같은 프론트엔드 프레임워크에서 오랫동안 경험해왔던 UI 컴포넌트를 떠올리시면 이해가 쉬우실 것 같습니다.

React 컴포넌트는 React에서만 쓸 수 있고, Vue.js 컴포넌트는 Vue.js에서만 쓸 수 있는 근본적인 한계가 있습니다. 하지만 웹 컴포넌트는 이와 같은 구애를 받지 않고 어떤 프론트엔드 프레임워크와도 함께 쓸 수 있습니다. 왜냐하면 웹 컴포넌트는 브라우저에서 네이티브(native)하게 작동하기 때문입니다.

이러한 웹 컴포넌트의 띄어난 호환성과 이식성, 재사용성 및 생산성 덕분에 최근에는 디자인 시스템(Design System)을 구현하는 최고의 기술로 주목받고 있습니다.

모든 기술이 그러하든 웹 컴포넌트가 장점만 있는 것은 아닙니다. 대표적인 단점으로 API가 직관적이지 않다고 평가받고 있고, 배우기 쉬운 기존 프런트엔드 프레임워크 대비 진입 장벽이 높은 편입니다. 그래서 실제 프로젝트에서는 이러한 단점을 보완한기 위해서 웹 컴포넌트를 직접 작성하기 보다는 Lit나 Stencil과 같은 라이브러리를 많이 사용합니다.

웹 컴포넌트은 크게 다음 세 가지 핵심 기술로 이루어집니다.
 * Custom Elements: 사용자 정의 HTML 요소(element) 또는 태그(tag)를 정의할 수 있습니다.
 * Shadow DOM: DOM 트리의 일부를 캡슐화하여 스타일과 마크업이 외부와 충돌하지 않도록 해줍니다.
 * HTML Templates: 화면에 나타나지 않는 HTML 조각(fragment)을 정의해놓고 재사용할 수 있습니다.
이 웹 표준 기술들은 현재 주요 브라우저에서 모두 지원되고 있습니다.

이번 포스팅에서는 각각의 기반 기술을 하나씩 살펴보면 웹 컴포넌트의 기본 개념을 잡아보도록 하겠습니다.

📝 포스팅: https://www.daleseo.com/web-components/

컴포넌트 기반 UI 개발의 패러다임을 주도한 React가 등장한지도 어느 덧 10년이 넘었네요. 이제 Vue.js, Svelte, Angular 등 어떤 프론트엔드 프레임워크를 사용하든 현대 웹 개발에서 컴포넌트 기반으로 UI 개발하는 것은 거의 당연한 얘기가 되었죠. 그리고 마침내 웹 컴포넌트(Web Components)를 통해서 별다른 프론트엔드 프레임워크가 없어도 UI 컴포넌트를 만들 수 있는 길이 활짝 열렸습니다. 웹 컴포넌트는 웹사이트나 애플리케이션에서 UI를 모듈화하고 재사용할 수도록 해주는 웹 표준 기술입니다. React와 같은 프론트엔드 프레임워크에서 오랫동안 경험해왔던 UI 컴포넌트를 떠올리시면 이해가 쉬우실 것 같습니다. React 컴포넌트는 React에서만 쓸 수 있고, Vue.js 컴포넌트는 Vue.js에서만 쓸 수 있는 근본적인 한계가 있습니다. 하지만 웹 컴포넌트는 이와 같은 구애를 받지 않고 어떤 프론트엔드 프레임워크와도 함께 쓸 수 있습니다. 왜냐하면 웹 컴포넌트는 브라우저에서 네이티브(native)하게 작동하기 때문입니다. 이러한 웹 컴포넌트의 띄어난 호환성과 이식성, 재사용성 및 생산성 덕분에 최근에는 디자인 시스템(Design System)을 구현하는 최고의 기술로 주목받고 있습니다. 모든 기술이 그러하든 웹 컴포넌트가 장점만 있는 것은 아닙니다. 대표적인 단점으로 API가 직관적이지 않다고 평가받고 있고, 배우기 쉬운 기존 프런트엔드 프레임워크 대비 진입 장벽이 높은 편입니다. 그래서 실제 프로젝트에서는 이러한 단점을 보완한기 위해서 웹 컴포넌트를 직접 작성하기 보다는 Lit나 Stencil과 같은 라이브러리를 많이 사용합니다. 웹 컴포넌트은 크게 다음 세 가지 핵심 기술로 이루어집니다.<ul ><li>Custom Elements: 사용자 정의 HTML 요소(element) 또는 태그(tag)를 정의할 수 있습니다.</li><li>Shadow DOM: DOM 트리의 일부를 캡슐화하여 스타일과 마크업이 외부와 충돌하지 않도록 해줍니다.</li><li>HTML Templates: 화면에 나타나지 않는 HTML 조각(fragment)을 정의해놓고 재사용할 수 있습니다.</li></ul>이 웹 표준 기술들은 현재 주요 브라우저에서 모두 지원되고 있습니다. 이번 포스팅에서는 각각의 기반 기술을 하나씩 살펴보면 웹 컴포넌트의 기본 개념을 잡아보도록 하겠습니다. 📝 포스팅: https://www.daleseo.com/web-components/

웹 컴포넌트 (Web Components)

알림과 실시간 채팅 같은 서비스를 구현할 때, 우리는 자연스럽게 두 가지 기술 사이에서 고민에 빠지게 됩니다. SSE와 WebSocket은 각기 다른 매력을 지닌 두 명의 주인공과 같습니다. 이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다. 실시간 통신의 필요성여러분의 앱이 최신 주식 가격을 보여주거나 "우리 동네에 눈이 내립니다!" 같은 알림을 띄워야 한다면, 실시간 통신은 선택이 아니라 필수입니다. 그런데 문제는 단방향이냐, 양방향이냐! 양방향 통신을 택하면 더 복잡하지만 매력적이고, 단방향 통신은 더 기능이 적지만 그만큼 단순합니다. 둘 중 어느 쪽을 고를지 결정하기 위해선 기술들의 성격을 ..

SSE와 WebSocket, 그들은 왜 실시간 통신의 라이벌이 되었을까?

이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다.
 
SSE (Server-Sent Events)
SSE는 마치 선생님이 수업 시간 내내 일방적으로 학생들에게 말하는 것과 같습니다. 학생(클라이언트)은 계속해서 듣고 받아 적어야 하죠.
 * 학생: 선생님, 질문이 있습니다
 * SSE: 미안, 넌 질문할 수 없어!
 
 
SSE는 서버가 클라이언트에게 일방적으로 데이터를 푸시할 때 쓰입니다. HTTP 기반이라서 프록시나 방화벽이 거부하지 않습니다.
 
서버에서 매초마다 데이터를 보낸다고 상상해 볼까요?
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServletResponse;

@RestController
public class SSEController {

 @GetMapping("/sse")
 public void streamEvents(HttpServletResponse response) throws IOException {
 response.setContentType("text/event-stream");
 response.setCharacterEncoding("UTF-8");

 PrintWriter writer = response.getWriter();
 for (int i = 1; i <= 5; i++) {
 writer.write("data: SSE 이벤트 #" + i + "\n\n");
 writer.flush();
 try {
 Thread.sleep(1000); // 1초마다 이벤트 전송
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 }
 }
 writer.close();
 }
}

const eventSource = new EventSource('/sse');

eventSource.onmessage = function(event) {
 console.log("새 이벤트 수신:", event.data);
};

eventSource.onerror = function() {
 console.error("SSE 연결 오류 발생");
};

장점:
 * SSE는 자동 재연결을 지원합니다.
 * 설정이 간단해서 빨리 구현하고 싶은 개발자에겐 최적입니다.
단점:
 * 오직 단방향입니다. 클라이언트는 서버에 말을 걸 수 없어요. (서운하지만 어쩔 수 없습니다.)
 * 데이터를 텍스트로만 보내는 게 편합니다. 이미지나 비디오 전송은 꿈도 꾸지 마세요.
 
WebSocket
WebSocket은 연애 초기의 커플 같아요. 둘이 채팅하느라 시간 가는 줄 모르죠. 양방향 통신이 가능하기 때문에 서버와 클라이언트가 자유롭게 대화를 주고받습니다.
 * A: "지금 뭐 해?"
 * B: "지금 네 메시지 받았어. 다시 보낼게!"

이제 서버와 클라이언트가 한바탕 신나게 대화하는 예제를 보겠습니다.
@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
 @Override
 public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
 registry.addHandler(new TextWebSocketHandler() {
 @Override
 protected void handleTextMessage(WebSocketSession session, TextMessage message) 
 throws Exception {
 session.sendMessage(new TextMessage("에코: " + message.getPayload()));
 }
 }, "/ws");
 }
}

const socket = new WebSocket('ws://localhost:8080/ws');

socket.onopen = () => {
 console.log('WebSocket 연결 성공!');
 socket.send('안녕, 서버!');
};

socket.onmessage = (event) => {
 console.log('받은 메시지:', event.data);
};

장점:
 * 양방향이라 서버와 클라이언트가 마음껏 수다를 떨 수 있습니다.
 * 텍스트뿐만 아니라 바이너리 데이터도 전송할 수 있어요. (그림도 보낼 수 있다는 얘기죠!)
단점:
 * 설정이 조금 귀찮습니다. 방화벽에 걸리기 쉽고, 초기 핸드셰이크까지 해야 하니까요.
 * 재연결? 그런 거 없습니다. 알아서 다시 연결할 방법을 짜야 해요.
 
마무리 및 결론
 * SSE는 "너 듣기만 해, 내가 다 말해줄게" 스타일에 적합합니다. 실시간 뉴스나 알림처럼 서버에서 클라이언트로만 정보가 흐를 때 좋습니다.
 * 반면에, WebSocket은 "같이 떠들자!" 스타일입니다. 채팅, 게임처럼 상호작용이 필요한 경우 선택하세요.
 
저는 개인적으로 어드민 UI에서 서버 로그를 실시간으로 출력할 때 SSE를 사용했습니다. 클라이언트가 서버에게 말할 필요가 없었기 때문에 SSE가 완벽한 선택이었습니다. 만약 반대로 채팅 앱을 만들었다면? WebSocket이 당연히 주인공이 되었겠죠.
 
이제 여러분도 SSE와 WebSocket 중 누구를 주인공으로 선택할지 결정할 수 있겠죠?

이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다.&nbsp;SSE (Server-Sent Events)SSE는 마치 선생님이 수업 시간 내내 일방적으로 학생들에게 말하는 것과 같습니다. 학생(클라이언트)은 계속해서 듣고 받아 적어야 하죠.<ul ><li>학생: 선생님, 질문이 있습니다</li><li>SSE: 미안, 넌 질문할 수 없어! </li></ul>SSE는 서버가 클라이언트에게 일방적으로 데이터를 푸시할 때 쓰입니다. HTTP 기반이라서 프록시나 방화벽이 거부하지 않습니다.&nbsp;서버에서 매초마다 데이터를 보낸다고 상상해 볼까요?<pre ><code class="language-javascript">import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServletResponse;

@RestController
public class SSEController {

 @GetMapping("/sse")
 public void streamEvents(HttpServletResponse response) throws IOException {
 response.setContentType("text/event-stream");
 response.setCharacterEncoding("UTF-8");

 PrintWriter writer = response.getWriter();
 for (int i = 1; i &lt;= 5; i++) {
 writer.write("data: SSE 이벤트 #" + i + "\n\n");
 writer.flush();
 try {
 Thread.sleep(1000); // 1초마다 이벤트 전송
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 }
 }
 writer.close();
 }
}</code></pre><pre ><code class="language-javascript">const eventSource = new EventSource('/sse');

eventSource.onmessage = function(event) {
 console.log("새 이벤트 수신:", event.data);
};

eventSource.onerror = function() {
 console.error("SSE 연결 오류 발생");
};</code></pre>장점:<ul ><li>SSE는 자동 재연결을 지원합니다.</li><li>설정이 간단해서 빨리 구현하고 싶은 개발자에겐 최적입니다.</li></ul>단점:<ul ><li>오직 단방향입니다. 클라이언트는 서버에 말을 걸 수 없어요. (서운하지만 어쩔 수 없습니다.)</li><li>데이터를 텍스트로만 보내는 게 편합니다. 이미지나 비디오 전송은 꿈도 꾸지 마세요.</li></ul>&nbsp;WebSocketWebSocket은 연애 초기의 커플 같아요. 둘이 채팅하느라 시간 가는 줄 모르죠. 양방향 통신이 가능하기 때문에 서버와 클라이언트가 자유롭게 대화를 주고받습니다.<ul ><li>A: "지금 뭐 해?"</li><li>B: "지금 네 메시지 받았어. 다시 보낼게!"</li></ul> 이제 서버와 클라이언트가 한바탕 신나게 대화하는 예제를 보겠습니다.<pre ><code class="language-java">@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
 @Override
 public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
 registry.addHandler(new TextWebSocketHandler() {
 @Override
 protected void handleTextMessage(WebSocketSession session, TextMessage message) 
 throws Exception {
 session.sendMessage(new TextMessage("에코: " + message.getPayload()));
 }
 }, "/ws");
 }
}</code></pre><pre ><code class="language-java">const socket = new WebSocket('ws://localhost:8080/ws');

socket.onopen = () =&gt; {
 console.log('WebSocket 연결 성공!');
 socket.send('안녕, 서버!');
};

socket.onmessage = (event) =&gt; {
 console.log('받은 메시지:', event.data);
};</code></pre>장점:<ul ><li>양방향이라 서버와 클라이언트가 마음껏 수다를 떨 수 있습니다.</li><li>텍스트뿐만 아니라 바이너리 데이터도 전송할 수 있어요. (그림도 보낼 수 있다는 얘기죠!)</li></ul>단점:<ul ><li>설정이 조금 귀찮습니다. 방화벽에 걸리기 쉽고, 초기 핸드셰이크까지 해야 하니까요.</li><li>재연결? 그런 거 없습니다. 알아서 다시 연결할 방법을 짜야 해요.</li></ul>&nbsp;마무리 및 결론<ul ><li>SSE는 "너 듣기만 해, 내가 다 말해줄게" 스타일에 적합합니다. 실시간 뉴스나 알림처럼 서버에서 클라이언트로만 정보가 흐를 때 좋습니다.</li><li>반면에, WebSocket은 "같이 떠들자!" 스타일입니다. 채팅, 게임처럼 상호작용이 필요한 경우 선택하세요.</li></ul>&nbsp;저는 개인적으로 어드민 UI에서 서버 로그를 실시간으로 출력할 때 SSE를 사용했습니다. 클라이언트가 서버에게 말할 필요가 없었기 때문에 SSE가 완벽한 선택이었습니다. 만약 반대로 채팅 앱을 만들었다면? WebSocket이 당연히 주인공이 되었겠죠.&nbsp;이제 여러분도 SSE와 WebSocket 중 누구를 주인공으로 선택할지 결정할 수 있겠죠?&nbsp;&nbsp;

덕토피아

SSE와 WebSocket, 그들은 왜 실시간 통신의 라이벌이 되

요즘 연습 중인 생각의 회로: 다 대표 탓이라고 생각하면 돌파구가 나옵니다. 

눈코 뜰 새 없이 매일을 살아가다, 턱 막히는 순간들이 옵니다. 지금까지는 외부 요인에 집중했는데 시장, 제품, 팀, 투자자 탓 말고 원인을 창업가 본인에 두면 해결의 실마리도보이는 것 같아요. 

1)… | 댓글 11

LinkedIn Hannah Choi 페이지: 요즘 연습 중인 생각의 회로: 다 대표 탓이라고 생각하면 돌파구가 나옵니다. 눈코 뜰 새 없이 매일을 살아가다, 턱 막히는… | 댓글 11

스타트업을 운영 중이신 한 대표님께서 말씀하시길, 난관에 봉착했을 때 이전에는 외부 요인에 집중했었지만, 이제는 시장, 제품, 팀, 투자자를 탓하지 않고 원인을 창업가 본인에게서 찾아 해결의 실마리를 발견해 나간다고 합니다.

시장 "요즘 비시즌이라 섭외 볼륨이 없어요"
 * 계절성에 대해 대응을 하지 못한 탓
 * 시즌이 국가 한정이라면, 린하게 확장할 수 있을까? 반드시 상업 촬용 중개 수수료에만 BM을 한정해야 할까?

프로덕트 "고객님 거기까지는 아직 프로덕트 대응이 안돼서..."
 * 사업 상황에 맞지 않는 우선순위를 선정한 내 탓
 * 더욱 타이트하게 제품-사업 팀의 소통을 열 수 없었을까?
 * 채용 계획을 다시 점검해볼까 ?
 * 프로덕트 없이 손으로 당장 고객에게 벨류를 가져다 줄 방법은 없을까?

투자 "이번 라운드는 어려울 것 같습니다"
 * 해당 투자사가 원하는 제품, 시장, 벨류와 맞지 않는 피칭을 전달한 내 탓
 * 현재 우리 상황을 더 선호하는 투자사들을 만날 수 있게 아웃바운드 볼륨을 높여볼까?
 * 우리 팀의 미래에 대해 설득력을 높일 수 있는 방법은 없을까?

사업은 마음만큼 따라와 주지 않는 일이 90%지만, 이런 저런 핑계말고 내 손으로 더 할 수 있는 일을 찾아보고 있습니다. 시장이 당장 바뀌기 어려워도, 제품이 하루 아침에 업데이트 되기는 힘들어도, 돌아선 투자사의 마음을 바꾸기는 어려워도 적어도 창업자 자신은 지금 당장 무엇인가 시도해볼 수 있기 때문입니다.

스타트업을 운영 중이신 한 대표님께서 말씀하시길, 난관에 봉착했을 때 이전에는 외부 요인에 집중했었지만, 이제는 시장, 제품, 팀, 투자자를 탓하지 않고 원인을 창업가 본인에게서 찾아 해결의 실마리를 발견해 나간다고 합니다. 시장 "요즘 비시즌이라 섭외 볼륨이 없어요"<ul ><li>계절성에 대해 대응을 하지 못한 탓</li><li>시즌이 국가 한정이라면, 린하게 확장할 수 있을까? 반드시 상업 촬용 중개 수수료에만 BM을 한정해야 할까?</li></ul> 프로덕트 "고객님 거기까지는 아직 프로덕트 대응이 안돼서..."<ul ><li>사업 상황에 맞지 않는 우선순위를 선정한 내 탓 </li><li>더욱 타이트하게 제품-사업 팀의 소통을 열 수 없었을까?</li><li>채용 계획을 다시 점검해볼까 ?</li><li>프로덕트 없이 손으로 당장 고객에게 벨류를 가져다 줄 방법은 없을까?</li></ul> 투자 "이번 라운드는 어려울 것 같습니다"<ul ><li>해당 투자사가 원하는 제품, 시장, 벨류와 맞지 않는 피칭을 전달한 내 탓</li><li>현재 우리 상황을 더 선호하는 투자사들을 만날 수 있게 아웃바운드 볼륨을 높여볼까?</li><li>우리 팀의 미래에 대해 설득력을 높일 수 있는 방법은 없을까?</li></ul> 사업은 마음만큼 따라와 주지 않는 일이 90%지만, 이런 저런 핑계말고 내 손으로 더 할 수 있는 일을 찾아보고 있습니다. 시장이 당장 바뀌기 어려워도, 제품이 하루 아침에 업데이트 되기는 힘들어도, 돌아선 투자사의 마음을 바꾸기는 어려워도 적어도 창업자 자신은 지금 당장 무엇인가 시도해볼 수 있기 때문입니다.

www.linkedin.com

다 대표 탓이라고 하면 돌파구가 나옵니다.

단순히 취업이 아닌,
꾸준히 성장하는 핵심 인재가 되고 싶다면,

다각도에서 내 역량이 어떻게 성장하고 있는지
스스로 파악하는 메타 인지가 필요해요.

DATA/AI 분야 뿐만 아니라,
다양한 영역에서 내가
어떤 스킬을 얼마나 갖추고 있는지를 생각해보세요.

- 하드 스킬
- 소프트 스킬
- 커리어 스킬

기업이 뽑고 싶어하는,
아니 기업이 뽑을수 밖에 없는 인재들은
이런 디테일을 가지고 있답니다.

하드 스킬, 소프트 스킬, 그리고 커리어 스킬을 각각 성장의 관점에서 바라보고 주기적으로 점검하는 습관을 들여보세요.

이렇게 스스로 분석하고 객관적으로 바라볼수 있다면,
결국 기업에서 찾는 '핵심 인재'로 자리매김하게 될 거예요.

단순히 취업이 아닌, 꾸준히 성장하는 핵심 인재가 되고 싶다면, 다각도에서 내 역량이 어떻게 성장하고 있는지 스스로 파악하는 메타 인지가 필요해요. DATA/AI 분야 뿐만 아니라, 다양한 영역에서 내가 어떤 스킬을 얼마나 갖추고 있는지를 생각해보세요. - 하드 스킬 - 소프트 스킬 - 커리어 스킬 기업이 뽑고 싶어하는, 아니 기업이 뽑을수 밖에 없는 인재들은 이런 디테일을 가지고 있답니다. 하드 스킬, 소프트 스킬, 그리고 커리어 스킬을 각각 성장의 관점에서 바라보고 주기적으로 점검하는 습관을 들여보세요. 이렇게 스스로 분석하고 객관적으로 바라볼수 있다면, 결국 기업에서 찾는 '핵심 인재'로 자리매김하게 될 거예요.

꾸준히 성장하는 핵심 인재의 특징

Last week, I interviewed a friend who got to Staff (IC6) at Google by 28 in an unusual way.

What You Work On >> How Hard You Work

기술 경로에서 빠르게 성공한 개발자들의 전략이 무엇인지 궁금하지 않으신가요? 이번 이야기는 구글에서 20대 후반에 IC6(Staff) 단계까지 오른 한 개발자의 경험을 담고 있습니다. 그가 일주일에 평균 40시간도 일하지 않으면서도 어떻게 빠르게 승진할 수 있었는지, 핵심은 단순히 성실한 업무량이 아닌, 전략적인 선택과 소통 능력이었다고 합니다.

1) 결과 중심적 사고와 큰 임팩트를 만드는 일 선택하기
 * 핵심 목표 이해: 그는 조직에서 가장 중요하게 여기는 결과와 그것을 달성하기 위해 필요한 핵심 작업을 우선 파악했습니다.
 * 작은 일 거절하기: 영향력이 적은 일은 거절하고, 승진 가능성을 높일 수 있는 프로젝트에 집중했습니다.
 * 시간은 제한적: 누구에게나 주어진 시간은 동일하기에, 중요한 일을 선별하고 집중하는 것이 높은 성과를 내는 유일한 방법이라고 합니다.
 * 매니저와의 대화: 그가 일의 임팩트를 평가하는 능력을 키운 방법은 매니저나 기술 리더와의 대화를 통해서였습니다. 이는 다음 단계를 준비하는 데 중요한 과정이라고 합니다.
2) 부드럽게 “아니요”라고 말할 수 있는 소프트 스킬
 * 오버커뮤니케이션: 거절할 때는 반드시 설명이 필요하며, 이를 통해 오해나 문제를 방지할 수 있습니다. 예를 들어, 중요한 프로젝트에 집중해야 하므로 덜 중요한 일을 맡지 않겠다고 설명하는 식입니다.
 * 균형 잡기: 승진에 도움이 되지 않는 일을 모두 거절하면 팀 플레이어로서의 이미지가 나빠질 수 있으므로, 상황에 따라 유연하게 접근하는 것이 중요합니다.
 * 시간 보호하기: 시간이 곧 자산이므로, 무분별하게 모든 요청에 응답하지 않고 자신의 시간을 보호해야 합니다. 예를 들어, 다른 팀원들의 문의나 온콜(On-call) 근무를 모두 거절했던 한 Distinguished 엔지니어의 사례를 참고하며, 경우에 따라 시간 보호를 우선시할 필요도 있음을 강조했습니다.
자신의 시간을 지키고 집중하는 것이 성공적인 커리어로 가는 지름길이 될 수 있습니다. 여러분은 어떤 방식으로 업무를 선택하고, 집중력을 유지하고 계신가요?

https://www.developing.dev/p/what-you-work-on-how-hard-you-work

기술 경로에서 빠르게 성공한 개발자들의 전략이 무엇인지 궁금하지 않으신가요? 이번 이야기는 구글에서 20대 후반에 IC6(Staff) 단계까지 오른 한 개발자의 경험을 담고 있습니다. 그가 일주일에 평균 40시간도 일하지 않으면서도 어떻게 빠르게 승진할 수 있었는지, 핵심은 단순히 성실한 업무량이 아닌, 전략적인 선택과 소통 능력이었다고 합니다. 1) 결과 중심적 사고와 큰 임팩트를 만드는 일 선택하기<ul ><li>핵심 목표 이해: 그는 조직에서 가장 중요하게 여기는 결과와 그것을 달성하기 위해 필요한 핵심 작업을 우선 파악했습니다.</li><li>작은 일 거절하기: 영향력이 적은 일은 거절하고, 승진 가능성을 높일 수 있는 프로젝트에 집중했습니다.</li><li>시간은 제한적: 누구에게나 주어진 시간은 동일하기에, 중요한 일을 선별하고 집중하는 것이 높은 성과를 내는 유일한 방법이라고 합니다.</li><li>매니저와의 대화: 그가 일의 임팩트를 평가하는 능력을 키운 방법은 매니저나 기술 리더와의 대화를 통해서였습니다. 이는 다음 단계를 준비하는 데 중요한 과정이라고 합니다.</li></ul>2) 부드럽게 “아니요”라고 말할 수 있는 소프트 스킬<ul ><li>오버커뮤니케이션: 거절할 때는 반드시 설명이 필요하며, 이를 통해 오해나 문제를 방지할 수 있습니다. 예를 들어, 중요한 프로젝트에 집중해야 하므로 덜 중요한 일을 맡지 않겠다고 설명하는 식입니다.</li><li>균형 잡기: 승진에 도움이 되지 않는 일을 모두 거절하면 팀 플레이어로서의 이미지가 나빠질 수 있으므로, 상황에 따라 유연하게 접근하는 것이 중요합니다.</li><li>시간 보호하기: 시간이 곧 자산이므로, 무분별하게 모든 요청에 응답하지 않고 자신의 시간을 보호해야 합니다. 예를 들어, 다른 팀원들의 문의나 온콜(On-call) 근무를 모두 거절했던 한 Distinguished 엔지니어의 사례를 참고하며, 경우에 따라 시간 보호를 우선시할 필요도 있음을 강조했습니다.</li></ul>자신의 시간을 지키고 집중하는 것이 성공적인 커리어로 가는 지름길이 될 수 있습니다. 여러분은 어떤 방식으로 업무를 선택하고, 집중력을 유지하고 계신가요? https://www.developing.dev/p/what-you-work-on-how-hard-you-work

어떻게 일하느냐가 얼마나 열심히 하느냐보다 중요하다.

산호세 주립대에서 데이터 엔지니어링 강의를 가르친지 11주가 되어 간다. 80%의 학생은 인도에서 대학을 마치고 3-5년 일하면 번 돈으로 실리콘밸리에서 일하는 것을 꿈꾸며 넘어온 도전이란 관점에서 나무랄 때가 없는 사람들이다. 하지만 도전 정신 만큼 성적이 나오느냐는 다른 문제이다. 정규 분포를 분명히 따르며 적은 수의 다른 문화권 출신들과 비교해보면 평균 점수는 확연히 낮다. 나머지 20%의 학생들은 주로 대만계인데 중국 본토 출신들은 없다. 중국 본토 출신은 R&D에 관심이 있다보니 석사 후 취업 보다는 박사까지 하는 걸 많이 고려하다보니 없는 걸로 보인다.

지지난 주 중간 고사를 보고 결과에 대해 궁금증이 있거나 납득이 안되는 학생들은 오피스 아워로 오라고 했는데 인도 학생들만 오고 그 이외의 인종은 아무도 오지 않았다 :) 실리콘 밸리에서 일해본 사람이라면 어느 정도 인정할 수 밖에 없는 것은 바로 인도 사람들의 자신감과 도전 정신이다. 다른 문화권에 비해 자기 검열을 하는 사람은 현저하게 적다. 또 하나 다른 점은 권위에 도전한다는 점이다. 매니저라고 해서 교수라고 해서 자기 의견을 죽이는 사람보다는 어떻게든 표현하는 사람들이 많다. 암튼 이런 저런 요청을 많이 하고 질문이 많다.

이런 문화적 특성 위에 영어를 어렸을 때부터 사용했다보니 언어적인 문제가 적다. 같이 일했던 인도 동료들을 보면 발음은 처음에 이해하기 힘들지 몰라도 단어 선택이나 표현 자체는 원어민들보다도 좋은 사람들이 많았다.

이 조합들(자기검열을 덜 하고 권위에 도전하며 영어 자체에 익숙한 점)이 결국 리더십으로 갈 수 있느냐 없느냐를 결정하는 것 같다. 또 하나 무시할 수 없는 점은 동아시아권들에 비해 모국의 환경이 그다지 좋지 않다보니 실리콘밸리에서 어떻게든 성공하겠다는 간절함이 더 있다고 보여진다.

가르치면서 이런 관찰을 또 할 줄은 몰랐지만 암튼 덜 자기검열하고 욕망을 잘 표현하고 의사소통을 잘 하는 것이 긴 커리어에서는 참 중요한 기술이다. 참 이번에 주관식 초벌 채점은 RAG로 해봤는데 물론 최종검수를 했고 RAG 만드느라 더 시간을 썼지만 아주 흥미로운 경험이었다. 나중에는 한번 이 이야기해도 공유 해봐야겠다.

산호세 주립대에서 데이터 엔지니어링 강의를 가르친지 11주가 되어 간다. 80%의 학생은 인도에서 대학을 마치고 3-5년 일하면 번 돈으로 실리콘밸리에서 일하는 것을 꿈꾸며 넘어온 도전이란 관점에서 나무랄 때가 없는 사람들이다. 하지만 도전 정신 만큼 성적이 나오느냐는 다른 문제이다. 정규 분포를 분명히 따르며 적은 수의 다른 문화권 출신들과 비교해보면 평균 점수는 확연히 낮다. 나머지 20%의 학생들은 주로 대만계인데 중국 본토 출신들은 없다. 중국 본토 출신은 R&amp;D에 관심이 있다보니 석사 후 취업 보다는 박사까지 하는 걸 많이 고려하다보니 없는 걸로 보인다. 지지난 주 중간 고사를 보고 결과에 대해 궁금증이 있거나 납득이 안되는 학생들은 오피스 아워로 오라고 했는데 인도 학생들만 오고 그 이외의 인종은 아무도 오지 않았다 :) 실리콘 밸리에서 일해본 사람이라면 어느 정도 인정할 수 밖에 없는 것은 바로 인도 사람들의 자신감과 도전 정신이다. 다른 문화권에 비해 자기 검열을 하는 사람은 현저하게 적다. 또 하나 다른 점은 권위에 도전한다는 점이다. 매니저라고 해서 교수라고 해서 자기 의견을 죽이는 사람보다는 어떻게든 표현하는 사람들이 많다. 암튼 이런 저런 요청을 많이 하고 질문이 많다. 이런 문화적 특성 위에 영어를 어렸을 때부터 사용했다보니 언어적인 문제가 적다. 같이 일했던 인도 동료들을 보면 발음은 처음에 이해하기 힘들지 몰라도 단어 선택이나 표현 자체는 원어민들보다도 좋은 사람들이 많았다. 이 조합들(자기검열을 덜 하고 권위에 도전하며 영어 자체에 익숙한 점)이 결국 리더십으로 갈 수 있느냐 없느냐를 결정하는 것 같다. 또 하나 무시할 수 없는 점은 동아시아권들에 비해 모국의 환경이 그다지 좋지 않다보니 실리콘밸리에서 어떻게든 성공하겠다는 간절함이 더 있다고 보여진다. 가르치면서 이런 관찰을 또 할 줄은 몰랐지만 암튼 덜 자기검열하고 욕망을 잘 표현하고 의사소통을 잘 하는 것이 긴 커리어에서는 참 중요한 기술이다. 참 이번에 주관식 초벌 채점은 RAG로 해봤는데 물론 최종검수를 했고 RAG 만드느라 더 시간을 썼지만 아주 흥미로운 경험이었다. 나중에는 한번 이 이야기해도 공유 해봐야겠다.

산호세 주립대에서 가르치며 다시 한번 깨달은 인도계의 다른 점

이 글은 DuckDB 사용법을 작성한 글입니다 예상 독자 DuckDB가 궁금하신 분 데이터 분석가 : Pandas가 느리다고 생각해서 다른 대안을 찾고 있는 분 데이터 엔지니어 : 데이터 엔지니어링의 Transform 영역에서 활용할 수 있는 수단을 찾고 있는 분. 작은 규모의 회사에서 데이터 웨어하우스를 고민하고 있는 분 키워드 : Duckdb 사용법, Duckdb 설치,...

DuckDB 사용법(DuckDB Python + Jupyter Lab)

 * 요즘 Pandas 대용, 데이터 웨어하우스 대용으로 많이 언급되는 DuckDB 사용법을 작성한 글입니다
 * 정말 빠르니 데이터 직무에 계신 분들은 꼭 보시고 사용해보시면 좋겠네요..!!!

https://zzsza.github.io/data-engineering/2024/10/25/duckdb/

<ul ><li>요즘 Pandas 대용, 데이터 웨어하우스 대용으로 많이 언급되는 DuckDB 사용법을 작성한 글입니다</li><li>정말 빠르니 데이터 직무에 계신 분들은 꼭 보시고 사용해보시면 좋겠네요..!!!</li></ul> https://zzsza.github.io/data-engineering/2024/10/25/duckdb/

zzsza.github.io

DuckDB 사용법

채용 담당자 시절 느낀 적당한 장수는 다음과 같았습니다.

👉 총 35-40p 이내
👉 프로젝트 4-5개, 장당 7-8p
👉 구조: 배경 > 문제정의 > 가설 > 솔루션 > 결과해석 > 레슨런
👉 프로젝트 = 서비스 아님
👉 서비스 하나당 n개의 프로젝트가 나올 수 있음
👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치함 (최신순 아니어도 됨)

채용 담당자 시절 느낀 적당한 장수는 다음과 같았습니다. 👉 총 35-40p 이내👉 프로젝트 4-5개, 장당 7-8p👉 구조: 배경 &gt; 문제정의 &gt; 가설 &gt; 솔루션 &gt; 결과해석 &gt; 레슨런👉 프로젝트 = 서비스 아님👉 서비스 하나당 n개의 프로젝트가 나올 수 있음👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치함 (최신순 아니어도 됨)

🎯 적당한 포트폴리오 장수는?

월급이 적다는 이유로 회사를 그만둔 적은 없었지만… 그런 이유를 대봤으면 어땠을까 상상해 봤습니다.

대체 불가능한 직원

월급이 적다는 이유로 회사를 그만둔 적은 없었지만…
그런 이유를 대봤으면 어땠을까 상상해 봤습니다.

“얼마나 올려주면 되는데?”
“50퍼센트요.”

한 번쯤 그렇게 말해볼 걸.
회사에서 인정하는 진짜 내 가치를 알 수 있을 테니깐.

하지만 저는 답을 알고 있기도 합니다.
“잘 가라.”

저는 대체 불가능한 사람이 아니었으므로.

만약 제가 대체 불가능했다면…
어떤 이유를 대며 그만둔다고 말했든 간에 회사에서 먼저 제안 했을 겁니다.
절대 거절할 수 없는 제안을.

그런 제안을 받아본 적이 없다는 것은 슬픈 일입니다.
언제든 대체 가능한 사람이었다는 것이 분명하므로.

https://jeho.page/essay/2024/10/29/irreplaceable.html

월급이 적다는 이유로 회사를 그만둔 적은 없었지만… 그런 이유를 대봤으면 어땠을까 상상해 봤습니다. “얼마나 올려주면 되는데?” “50퍼센트요.” 한 번쯤 그렇게 말해볼 걸. 회사에서 인정하는 진짜 내 가치를 알 수 있을 테니깐. 하지만 저는 답을 알고 있기도 합니다.“잘 가라.” 저는 대체 불가능한 사람이 아니었으므로. 만약 제가 대체 불가능했다면… 어떤 이유를 대며 그만둔다고 말했든 간에 회사에서 먼저 제안 했을 겁니다.절대 거절할 수 없는 제안을. 그런 제안을 받아본 적이 없다는 것은 슬픈 일입니다. 언제든 대체 가능한 사람이었다는 것이 분명하므로. https://jeho.page/essay/2024/10/29/irreplaceable.html

K리그 프로그래머

chatGPT를 이용한 프레임워크중 가장 많이 사용되고 있는 프레임워크가 Langchain 일 것입니다. Langchain에서는 다양한 기능을 미리 만들어서 제공하고 있고, 다양한 검색엔진을 연계하는 Agent 또한 준비되어져 있습니다. 하지만 업무시스템에 구축되어져있는 상용검색엔진 혹은 업무시스템에 맞게 커스텀되어진 엘라스틱서치를 연계하는 맞춤형 Agent는 직접 개발해야 합니다. langchain 공식 문서의 예제 코드인 CustomSearchToo

chatGPT에 검색엔진을 붙여보자! feat. Naver search api

사내 검색 시스템이나 특정 검색엔진을 langchain에 붙여서 시멘틱 검색을 할 수 없을까 싶어서 만들어본 코드 입니다.

naver 검색 api 를 이용하게 작성했습니다. 특정 검색엔진을 사용하려면 요청 방식에 맞게 수정하시면 될거 같습니다.

별거 아닌 코드지만 저처럼 이런게 필요한 사람이 또 있을수 있어서 공유 드립니다.

감사합니다.

https://develop-park.tistory.com/59?fbclid=IwAR3DhOJccxwMI2KvdF5bIrvyE3VJ7dsINLEVbLIZG2NfaT5NwGvi8_VXT9Q

개발자의 스터디 노트

퍼블리의 그로스 매니저로 커리어를 시작하여, 현재는 멤버십 사업을 총괄하고 있습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책과 교육, 경제에 관심을 가지고 있습니다.
일하는 것을 싫어하지만, 많이 하고 있습니다..

커리어리 Lead Product Manager

김광종

퍼블리 그로스매니저로 커리어를 시작하여, 프로덕트매니저와 사업총괄을 거쳐, 커리어리팀을 리드하였습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책/교육/경제에 관심이 있습니다.
자유로운 삶을 추구하지만, 지금은 일에 매여 있습니다..

넷마블 잡부

민형기

#백엔드 #개발자 #소프트웨어엔지니어

langchain의 검색 Agent를 커스텀 해봤습니다.

SaaS

플랫폼

python

fastapi

Microsoft Azure

매니저

django

Java

Docker

mongodb

Spring

Github

aicc 인공지능 추천 모델 구현
 -cnn KoBERT KoELECTRA
인공지능 모델 서빙
NLP 자연어 처리 백엔드 개발
자연어처리 솔루션 관리도구 백엔드 개발

수석

엔터프라이즈 검색 솔루션 개발
 - 데이터 수집 정제 인덱싱 파이프라인 개발
 - 검색엔진 관리도구 웹개발

엔터프라이즈 웹크롤러 솔루션 개발
 - 웹수집 엔진 개발
 - 웹크롤러 관리도구 웹개발

다수 고객사 검색 솔루션 구축 사업 수행
다수 고객사 웹롤러 솔루션 구축 사업 수행

NLP 엔진 개발
 - 다빈도
 - 연관어
 - 오토 클러스터링
 - 주제어 분석
 - 문장요약

NLP 엔진 관리도구 웹개발

머신러닝을 통란 분류모델 개발 및 서빙
CNN RNN KoBERT릉 통한 딥러닝 분류모델 개발 및 서빙
AICC 솔루션 설계 및 개발

차장

인공지능융합전공

정보통신공학

박우석

08년부터 개발자로 밥벌어 먹는중
#백엔드 #개발자 #Ai #Web #서버개발 #AI/ML

langchain의 검색 Agent를 커스텀 해봤습니다.

댓글 1

비슷한 게시물

주간 인기 TOP 10

추천 프로필