계란후라이 1078

﻿
생산성은 여러 가지 요인이 복합적으로 작용하여 결정됩니다. 시간, 몰입, 우선순위, 의사결정, 동료 등 다양하게 많습니다. 생산성이란 일을 하는데 우리가 사용하는 노력 대비 결과를 얻을 수 있는 정도를 의미합니다. 모든 사람과 조직은 합리적인 생산성을 기대합니다.
회사에서 하루 일과를 돌아보면 생산성 있게 일을 했는지 확신이 들지 않는 날이 더 많습니다. 특히 HR 분야 업무는 구성원의 행동이 결과로 빠르게 이어지는 경우가 드물게 때문입니다. 조직문화를 개선하거나 교육을 통해 구성원의 성장을 돕는 일, 인재를 채용했는데 그분이 조직이 기대했던 사람이 맞고 기여하고 있는지 정확히 알 수 없습니다. 측정하기 어려우니 실행의 의미를 가늠하기 어려운 것입니다.
하루에 생산성을 발휘할 수 있는 시간은 제한적입니다. 무조건 일을 오래 한다고 계속 합리적인 생산성을 발휘할 수 있는 것은 아닙니다. 8시간을 기준으로 2시간 정도 집중해서 일을 할 수 있고, 나머지 6시간은 여러 가지 방해를 받으며 집중하지 못합니다. 집중하지 못하면 시간과 노력 대비 성과를 얻기 힘듭니다. 그리고 고민하는 시간을 생산 활동으로 봐야 하는지 애매합니다. 더 좋은 방법을 찾기 위해여 고민이 필요하지만, 그 고민을 언제 하는 것이 좋은지 답을 찾고 싶습니다.
하루 일과를 계획하고 실행할 때 얼마나 촘촘히 시간 관리를 하는 것이 옳은지 알고 싶습니다. 멀티태스킹이 숙명인 직장인으로서 머릿속에 떠오르는 다양한 일감들을 손대지 않고 지금 당장 집중해야 하는 일에만 온전히 몰입할 수 있는 방법을 알고 싶습니다. 지금보다 더 생산적으로 일을 할 수 있을 것 같은데 그러지 못하고 있는 것 같아 답답합니다. 아마 제가 일을 못하는 사람이라 이런 혼란을 겪는 것이겠죠?
궁극적으로 도달해야 하는 목표에 가까워진다면, 과정에 정답이 있는 것은 아닙니다. 빠른 시일 내에 목표를 달성할 수 있도록 추진한다면, 일꾼을 혹사하는 상황이 될 것입니다. 감당할 수 있는 일정을 계획하여 진행하는 것도 건전한 생산성 향상을 위해 꼭 필요합니다.
이전에는 업무 프로세스가 짜여 있는 환경이 갑갑하게 느껴졌습니다. 업무 생산성을 떨어뜨리는 대표적인 악의 축이라고 여겼습니다. 느린 의사결정과 형식적인 업무 수행으로 아이디어를 제한하고 일을 하기 위해 일을 한다는 느낌을 받았습니다. 그러나 이제는 생각이 달라졌습니다. 업무의 종류에 관계없이 거의 모든 일은 순서와 절차가 있다는 것을 깨달았기 때문입니다. 프로세스에 따라서 일을 시작하는 것이 수월해지고, 진행 과정에서 누락을 방지할 수 있습니다. 프로세스가 생산성을 방해하는 것이 아니라 프로세스를 개선하는 것이 생산성을 올리는 일입니다.
직장인은 매일 정해진 루틴을 삽니다. 출근 시간에 낮춰 알람 소리를 듣고 일어나는 순간부터 퇴근 후 터벅터벅 집으로 돌아와 지친 육신과 영혼을 침대 위에서 달래는 순간까지 거의 똑같은 일상을 반복합니다. 우리가 꼭 오늘보다 더 내일 나아져야만 하는 것은 아니지만, 만약 성장하고 싶은 욕구가 강한 분이 있다면, 오늘 하루 중에 언제 무엇을 하는 순간이 변화가 필요할지 고민해 보세요. 꼭 성장을 위한 고민이 아니어도 괜찮습니다. 건강, 관계 등 변화가 필요하다고 생각하는 영역이 있다면 하루에 했던 일과 그 결과를 회고해 보면, 변화를 위한 작은 넛지를 발견하게 될 것이라고 믿습니다.

계란후라이 1078 ﻿생산성은 여러 가지 요인이 복합적으로 작용하여 결정됩니다. 시간, 몰입, 우선순위, 의사결정, 동료 등 다양하게 많습니다. 생산성이란 일을 하는데 우리가 사용하는 노력 대비 결과를 얻을 수 있는 정도를 의미합니다. 모든 사람과 조직은 합리적인 생산성을 기대합니다.회사에서 하루 일과를 돌아보면 생산성 있게 일을 했는지 확신이 들지 않는 날이 더 많습니다. 특히 HR 분야 업무는 구성원의 행동이 결과로 빠르게 이어지는 경우가 드물게 때문입니다. 조직문화를 개선하거나 교육을 통해 구성원의 성장을 돕는 일, 인재를 채용했는데 그분이 조직이 기대했던 사람이 맞고 기여하고 있는지 정확히 알 수 없습니다. 측정하기 어려우니 실행의 의미를 가늠하기 어려운 것입니다.하루에 생산성을 발휘할 수 있는 시간은 제한적입니다. 무조건 일을 오래 한다고 계속 합리적인 생산성을 발휘할 수 있는 것은 아닙니다. 8시간을 기준으로 2시간 정도 집중해서 일을 할 수 있고, 나머지 6시간은 여러 가지 방해를 받으며 집중하지 못합니다. 집중하지 못하면 시간과 노력 대비 성과를 얻기 힘듭니다. 그리고 고민하는 시간을 생산 활동으로 봐야 하는지 애매합니다. 더 좋은 방법을 찾기 위해여 고민이 필요하지만, 그 고민을 언제 하는 것이 좋은지 답을 찾고 싶습니다.하루 일과를 계획하고 실행할 때 얼마나 촘촘히 시간 관리를 하는 것이 옳은지 알고 싶습니다. 멀티태스킹이 숙명인 직장인으로서 머릿속에 떠오르는 다양한 일감들을 손대지 않고 지금 당장 집중해야 하는 일에만 온전히 몰입할 수 있는 방법을 알고 싶습니다. 지금보다 더 생산적으로 일을 할 수 있을 것 같은데 그러지 못하고 있는 것 같아 답답합니다. 아마 제가 일을 못하는 사람이라 이런 혼란을 겪는 것이겠죠?궁극적으로 도달해야 하는 목표에 가까워진다면, 과정에 정답이 있는 것은 아닙니다. 빠른 시일 내에 목표를 달성할 수 있도록 추진한다면, 일꾼을 혹사하는 상황이 될 것입니다. 감당할 수 있는 일정을 계획하여 진행하는 것도 건전한 생산성 향상을 위해 꼭 필요합니다.이전에는 업무 프로세스가 짜여 있는 환경이 갑갑하게 느껴졌습니다. 업무 생산성을 떨어뜨리는 대표적인 악의 축이라고 여겼습니다. 느린 의사결정과 형식적인 업무 수행으로 아이디어를 제한하고 일을 하기 위해 일을 한다는 느낌을 받았습니다. 그러나 이제는 생각이 달라졌습니다. 업무의 종류에 관계없이 거의 모든 일은 순서와 절차가 있다는 것을 깨달았기 때문입니다. 프로세스에 따라서 일을 시작하는 것이 수월해지고, 진행 과정에서 누락을 방지할 수 있습니다. 프로세스가 생산성을 방해하는 것이 아니라 프로세스를 개선하는 것이 생산성을 올리는 일입니다.직장인은 매일 정해진 루틴을 삽니다. 출근 시간에 낮춰 알람 소리를 듣고 일어나는 순간부터 퇴근 후 터벅터벅 집으로 돌아와 지친 육신과 영혼을 침대 위에서 달래는 순간까지 거의 똑같은 일상을 반복합니다. 우리가 꼭 오늘보다 더 내일 나아져야만 하는 것은 아니지만, 만약 성장하고 싶은 욕구가 강한 분이 있다면, 오늘 하루 중에 언제 무엇을 하는 순간이 변화가 필요할지 고민해 보세요. 꼭 성장을 위한 고민이 아니어도 괜찮습니다. 건강, 관계 등 변화가 필요하다고 생각하는 영역이 있다면 하루에 했던 일과 그 결과를 회고해 보면, 변화를 위한 작은 넛지를 발견하게 될 것이라고 믿습니다.﻿

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

🙅‍♂️ 내가 하지 않는 생각
- 이걸로 무조건 성공해서 돈 벌어야지
- 많은 기능 넣으면 사용자들이 좋아하겠지?
- 이왕 만드는 거 완벽하게 만들어야지

🙆‍♀️ 내가 하는 생각
- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자
- 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자
- 필요한 기능 1개만 추려서 빠르게 만들어 보자
- 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

🙅‍♂️ 내가 하지 않는 생각- 이걸로 무조건 성공해서 돈 벌어야지 - 많은 기능 넣으면 사용자들이 좋아하겠지? - 이왕 만드는 거 완벽하게 만들어야지 🙆‍♀️ 내가 하는 생각- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자 - 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자 - 필요한 기능 1개만 추려서 빠르게 만들어 보자 - 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

사이드 프로젝트 만들 때

AI 데이터 수집의 법적 승리

최근 함부르크 법원은 이미지 AI 개발에 필요한 데이터셋을 만드는 비영리 단체 LAION이 사진작가의 허락 없이 저작권이 있는 이미지를 AI 시스템 훈련을 위해 수집할 수 있다고 판결했어요. 이 판결은 독일 저작권법 제60d조에 따라 비상업적 과학 연구를 위한 텍스트 및 데이터 마이닝을 허용하는 조항을 근거로 했다고 해요.

AI '추수'의 시작!

일반적인 기사나 블로글에서는 보지 못했던 나름 인사이트 있는 글이라 생각되어 옮겨봅니다. 자세한 내용은 원문을 참고해주세요~^^

🏵️ AI 데이터 수집의 법적 승리
 * 최근 함부르크 법원은 이미지 AI 개발에 필요한 데이터셋을 만드는 비영리 단체 LAION이 사진작가의 허락 없이 저작권이 있는 이미지를 AI 시스템 훈련을 위해 수집할 수 있다고 판결내렸습니다.
 * 이 판결은 독일 저작권법 제60d조에 따라 비상업적 과학 연구를 위한 텍스트 및 데이터 마이닝을 허용하는 조항을 근거로 했다고 합니다.

🏵️ 저커버그의 도발
 * 최근 메타(Meta)의 CEO 마크 저커버그(Mark Zuckerberg)는 AI 모델 훈련을 위한 데이터 스크래핑과 관련하여 대부분의 창작자들이 자신의 콘텐츠 가치를 과대평가한다고 주장하며, 메타는 유용한 콘텐츠에 대해서만 특정 파트너십을 맺을 것이라고 밝혔습니다.
 * 만약 창작자들이 콘텐츠 사용에 대해 비용을 요구한다면, 메타는 그 콘텐츠를 사용하지 않을 것이라고 합니다.

🏵️ 캘리포니아 주지사, AI 규제 법안 거부
 * 캘리포니아 주지사 개빈 뉴섬(Gavin Newsom)이 최근 강력한 AI 시스템을 출시하기 전에 테스트하고, 기술이 사람들에게 해를 끼칠 경우 책임을 묻는 AI 규제 법안 S.B. 1047을 거부했습니다.

🏵️ 2025년, AI 에이전트의 대중화!
 * OpenAI가 2025년까지 AI 에이전트의 대중화를 예측하며, 최근 데브데이(DevDay)에서 공개된 향상된 모델 o1과 GPT-4o의 음성 기능등을 통해 복잡한 작업을 수행하고 추론하는 AI 에이전트를 통해 시장을 선점하려는 전략을 가져가고 있습니다.
   
   
🏵️ 마케터의 새로운 무기!
 * 인바운드 2024(Inbound 2024)에서 OpenAI의 데인 바히(Dane Vahey)는 AI 프리미티브(AI Primitives)라는 개념을 제시하며 마케터들이 AI를 활용하는 새로운 패러다임을 제시했습니다.
 * AI 프리미티브(AI Primitives)는 연구(Research), 데이터 분석(Data Analysis), 콘텐츠 생성(Content Generation), 자동화 및 코딩(Automation & Coding), 사고(Thinking)입니다.
   
   
🏵️ 모든 인류가 질병 없이
 * 최근 열린 더 타임즈 테크 서미트(The Times Tech Summit)에서 구글 딥마인드(Google DeepMind)의 CEO인 데미스 하사비스(Demis Hassabis)는 AI가 향후 10년 내에 인간의 일반적인 인지 능력을 갖추게 될 것이며, 이를 통해 모든 질병을 치료할 수 있는 잠재력을 지니고 있다고 주장했습니다.

🏵️ AI, 세 가지 변화의 물결
 * 구글(Google)의 전 CEO인 에릭 슈미트(Eric Schmidt)는 가까운 미래, 특히 올해 안에 AI가 세 가지 중요한 변화로 '무한한 맥락 창(context window)'의 등장, '에이전트'의 발전, '텍스트 투 액션(Text to Action)'을 전망했습니다.

 * source: https://news.aikoreacommunity.com/ai-cusuyi-sijag/?ref=ai-koria-keomyuniti-nyuseureteo-newsletter

일반적인 기사나 블로글에서는 보지 못했던 나름 인사이트 있는 글이라 생각되어 옮겨봅니다. 자세한 내용은 원문을 참고해주세요~^^ 🏵️ AI 데이터 수집의 법적 승리<ul ><li>최근 함부르크 법원은 이미지 AI 개발에 필요한 데이터셋을 만드는 비영리 단체 LAION이 사진작가의 허락 없이 저작권이 있는 이미지를 AI 시스템 훈련을 위해 수집할 수 있다고 판결내렸습니다. </li><li>이 판결은 독일 저작권법 제60d조에 따라 비상업적 과학 연구를 위한 텍스트 및 데이터 마이닝을 허용하는 조항을 근거로 했다고 합니다.</li></ul> 🏵️ 저커버그의 도발<ul ><li>최근 메타(Meta)의 CEO 마크 저커버그(Mark Zuckerberg)는 AI 모델 훈련을 위한 데이터 스크래핑과 관련하여 대부분의 창작자들이 자신의 콘텐츠 가치를 과대평가한다고 주장하며, 메타는 유용한 콘텐츠에 대해서만 특정 파트너십을 맺을 것이라고 밝혔습니다.</li><li>만약 창작자들이 콘텐츠 사용에 대해 비용을 요구한다면, 메타는 그 콘텐츠를 사용하지 않을 것이라고 합니다.</li></ul> 🏵️ 캘리포니아 주지사, AI 규제 법안 거부<ul ><li>캘리포니아 주지사 개빈 뉴섬(Gavin Newsom)이 최근 강력한 AI 시스템을 출시하기 전에 테스트하고, 기술이 사람들에게 해를 끼칠 경우 책임을 묻는 AI 규제 법안 S.B. 1047을 거부했습니다.</li></ul> 🏵️ 2025년, AI 에이전트의 대중화!<ul ><li>OpenAI가 2025년까지 AI 에이전트의 대중화를 예측하며, 최근 데브데이(DevDay)에서 공개된 향상된 모델 o1과 GPT-4o의 음성 기능등을 통해 복잡한 작업을 수행하고 추론하는 AI 에이전트를 통해 시장을 선점하려는 전략을 가져가고 있습니다. </li></ul>🏵️ 마케터의 새로운 무기!<ul ><li>인바운드 2024(Inbound 2024)에서 OpenAI의 데인 바히(Dane Vahey)는 AI 프리미티브(AI Primitives)라는 개념을 제시하며 마케터들이 AI를 활용하는 새로운 패러다임을 제시했습니다.</li><li>AI 프리미티브(AI Primitives)는 연구(Research), 데이터 분석(Data Analysis), 콘텐츠 생성(Content Generation), 자동화 및 코딩(Automation &amp; Coding), 사고(Thinking)입니다. </li></ul>🏵️ 모든 인류가 질병 없이<ul ><li>최근 열린 더 타임즈 테크 서미트(The Times Tech Summit)에서 구글 딥마인드(Google DeepMind)의 CEO인 데미스 하사비스(Demis Hassabis)는 AI가 향후 10년 내에 인간의 일반적인 인지 능력을 갖추게 될 것이며, 이를 통해 모든 질병을 치료할 수 있는 잠재력을 지니고 있다고 주장했습니다.</li></ul> 🏵️ AI, 세 가지 변화의 물결<ul ><li>구글(Google)의 전 CEO인 에릭 슈미트(Eric Schmidt)는 가까운 미래, 특히 올해 안에 AI가 세 가지 중요한 변화로 '무한한 맥락 창(context window)'의 등장, '에이전트'의 발전, '텍스트 투 액션(Text to Action)'을 전망했습니다.</li></ul> <ul ><li>source: https://news.aikoreacommunity.com/ai-cusuyi-sijag/?ref=ai-koria-keomyuniti-nyuseureteo-newsletter</li></ul>

AI 코리아 커뮤니티 뉴스레터

[AI코리아 커뮤니티] AI '추수'의 시작!

“골드러시 시대에는 금맥을 찾는 대신 청바지나 곡괭이를 팔아라.”라는 비즈니스 격언, 한 번쯤 들어보셨을 겁니다. 최근 AI 골드러시 시대에도 청바지로 비유되는 GPU를 판매한 엔비디아가 가장 큰 수혜를 입으며 격언을 또 한 번 입증했습니다. 참고로 이 AI 골드러시 시대를 연 주역은 바로 OpenAI입니다. 이들은 생성형 AI라는 금광을 발견해 세상에 알리는 데 큰 역할을 했는데요. 금광을 발견함과 동시에 가장 먼저 채굴(ChatGPT Plus 요금제 도입 등)을 시작했지만, 이것만으로는 수익이 불확실해지자 안정적인 수익을 낼 수 있는 청바지(API, 인프라)를 제작하기 시작했습니다. 그리고 지난 10월 1일(현지 시각)에 진행된 OpenAI Devday 2024를 통해 자신들이 열심히 만든 최고급 청바지를 선보였습니다.

‘OpenAI DevDay 2024’ 최고급 청바지를 선보이다 | 요즘IT

10월1일 진행한 OpenAI의 DevDay 2024에 대한 정갈하고(?) 세심하게 정리한 내용이 있어 공유해봅니다. 보다 상세한 내용은 원문을 참고해주세요. 플리즈~^^

 1. Realtime API “야너두 음성 대화 앱 만들 수 있어!”
 * 이번에 오픈데이가 출시한 실시간 API는 기존의 음성인식, 의도파악 및 답변 생성, 음성출력의 3단계를 하나로 통합하여 시간과 리소스의 효율성이 크게 향상
 * 개발자가 애플리케이션에 오픈AI의 AI 모델을 사용해 멀티모달 처리 기능을 장착할 수 있도록 하는 클라우드 서비스

 2. Vision fine-tuning “이제 이미지도 파인튜닝할 수 있어!”
 * 기존에는 텍스트에 적용하던 fine-tuning(미세 조정)을 이미지에도 적용하게 되어, 보다 특화되고 개인화된 서비스를 개발 지원
 * OpenAI는 이 기능을 통해 시각 검색, 자율 주행차나 스마트 시티를 위한 객체 감지, 의료 이미지 분석과 같은 다양한 분야의 앱이 발전할 수 있을 것으로 기대

 3. Prompt Caching “물어봤던 거네? 반값에 해줄게!”
 * 비슷한 요청이 반복해서 들어올 경우 이를 기억하고 있다가 빠르게 답변을 내놓을 수 있게
 * 저장된 요청에 대한 응답 시에는 입력 토큰 금액을 절반(50%)만 지불하도록 하여 비용 절감과 응답시간 개선 기대

 4. Distillation “작은 모델로도 충분해!”
 * 대형 언어 모델(LLM)은 뛰어난 성능을 자랑하지만, 그만큼 무겁고 비용이 많이 든다는 단점이 있는데, 간단한 서비스를 만들 때는 모델의 크기를 줄여 비용을 절감하는 것이 필요한데, 이를 위해 OpenAI가 제안한 기능이 바로 ‘Distillation(정제, 증류)’ 기능
 * 각 개발자는 자신에게 필요한 모델들을 직접 파인 튜닝하고, 원하는 만큼 모델 크기를 줄여 응답 시간과 비용을 절감

 * source: https://yozm.wishket.com/magazine/detail/2790/

10월1일 진행한 OpenAI의 DevDay 2024에 대한 정갈하고(?) 세심하게 정리한 내용이 있어 공유해봅니다. 보다 상세한 내용은 원문을 참고해주세요. 플리즈~^^ <ol ><li>Realtime API “야너두 음성 대화 앱 만들 수 있어!”</li></ol><ul ><li>이번에 오픈데이가 출시한 실시간 API는 기존의 음성인식, 의도파악 및 답변 생성, 음성출력의 3단계를 하나로 통합하여 시간과 리소스의 효율성이 크게 향상</li><li>개발자가 애플리케이션에 오픈AI의 AI 모델을 사용해&nbsp;멀티모달 처리 기능을 장착할 수 있도록 하는 클라우드 서비스</li></ul> <ol start="2"><li>Vision fine-tuning “이제 이미지도 파인튜닝할 수 있어!”</li></ol><ul ><li>기존에는 텍스트에 적용하던 fine-tuning(미세 조정)을 이미지에도 적용하게 되어, 보다&nbsp;특화되고 개인화된 서비스를 개발 지원</li><li>OpenAI는 이 기능을 통해 시각 검색, 자율 주행차나 스마트 시티를 위한 객체 감지, 의료 이미지 분석과 같은 다양한 분야의 앱이 발전할 수 있을 것으로 기대</li></ul> <ol start="3"><li>Prompt Caching “물어봤던 거네? 반값에 해줄게!”</li></ol><ul ><li>비슷한 요청이 반복해서 들어올 경우 이를 기억하고 있다가 빠르게 답변을 내놓을 수 있게</li><li>저장된 요청에 대한 응답 시에는 입력 토큰 금액을 절반(50%)만 지불하도록 하여 비용 절감과 응답시간 개선 기대</li></ul> <ol start="4"><li>Distillation “작은 모델로도 충분해!”</li></ol><ul ><li>대형 언어 모델(LLM)은 뛰어난 성능을 자랑하지만, 그만큼 무겁고 비용이 많이 든다는&nbsp;단점이 있는데, 간단한&nbsp;서비스를 만들&nbsp;때는 모델의 크기를 줄여 비용을 절감하는 것이 필요한데,&nbsp;이를 위해 OpenAI가 제안한 기능이 바로&nbsp;‘Distillation(정제, 증류)’ 기능</li><li>각 개발자는 자신에게 필요한 모델들을 직접&nbsp;파인 튜닝하고, 원하는 만큼 모델 크기를 줄여 응답 시간과 비용을 절감</li></ul> <ul ><li>source: https://yozm.wishket.com/magazine/detail/2790/</li></ul>

요즘IT

[요즘IT]‘OpenAI DevDay 2024’ 최고급 청바지를 선보이다

이 글은 UX Collective 내 Pavel Samsonov의 Nike’s $25B blunder shows us the limits of “data-driven”를 번역, 의역, 재구성한 글입니다.   [나이키에게 발생한 30조원 손실]  2024년 7월, 나이키의 전 수석 브랜드 디렉터가 4년에 걸쳐 발생한 마케팅 실패 사례들을 공개했다. 이 사례들

나이키에게 30조원 재앙을 부른 데이터 드리븐

기업의 실패를 결과론적으로 분석하는 건 큰 의미가 없다고 생각하지만, 그럼에도 불구하고 생각해볼만한 포인트가 있어서 가져온 글입니다. 흔히 '빈 카운터스'로 대표되는, 잘못된 데이터(혹은 미시적 데이터)에 집중하면서 회사를 잘못 이끄는 케이스가 많은데요. 최근 몇 년 동안의 나이키도 이 함정에 빠졌다고 설명하는 글이에요. 사실 구체적인 케이스가 적시되지 않아서 좀 애매한 부분이 있긴 한데, 완전 내부자가 아니라면 이 부분까지는 정확히 알기 어려울 것 같기도 하네요. 아무튼, 데이터 분석을 한다는 사람들이 항상 경계해야 하는 지점이 아닌가 싶습니다.

기업의 실패를 결과론적으로 분석하는 건 큰 의미가 없다고 생각하지만, 그럼에도 불구하고 생각해볼만한 포인트가 있어서 가져온 글입니다. 흔히 '빈 카운터스'로 대표되는, 잘못된 데이터(혹은 미시적 데이터)에 집중하면서 회사를 잘못 이끄는 케이스가 많은데요. 최근 몇 년 동안의 나이키도 이 함정에 빠졌다고 설명하는 글이에요. 사실 구체적인 케이스가 적시되지 않아서 좀 애매한 부분이 있긴 한데, 완전 내부자가 아니라면 이 부분까지는 정확히 알기 어려울 것 같기도 하네요. 아무튼, 데이터 분석을 한다는 사람들이 항상 경계해야 하는 지점이 아닌가 싶습니다.

Brunch Story

[나이키에게 30조원 재앙을 부른 데이터 드리븐]

조직에 비생산적인 환경을 조성하여 방해하는 방법에 대한 CIA의 매뉴얼 한장의 시사점이 크네요. 이걸 읽어보시면 과연 내가 속한 조직의 현재 모습이 아닌가 싶을 정도입니다.

결국 이런 모습을 보이면 조직은 망해간다고 생각해도 될 것 같습니다.
======
1. 모든 절차를 반드시 '공식 경로'로 처리하도록 고집한다. 결정을 신속하게 내리기 위한 지름길은 허용하지 않는다.
2. '연설'을 한다. 가능한 자주, 그리고 길게 말한다. 긴 일화나 개인 경험을 이야기하며 자신의 '주장'을 설명한다
3.가능한 경우, 모든 사안을 '추가 연구와 검토'를 위해 위원회에 회부한다. 위원회는 최소 다섯 명 이상으로 구성한다.
4. 관련 없는 문제를 자주 제기한다.
5. 문서, 회의록, 결의안의 정확한 문구에 대해 끝없이 논쟁한다.
6. 지난 회의에서 결정된 문제를 다시 언급하고, 그 결정의 타당성에 대해 재검토를 요구한다.
7. '주의'를 권장한다. '합리적'이라는 명목으로 속도를 늦추고, 회의 참가자들에게도 신중하게 행동하라고 촉구한다. 추후 문제나 곤란함을 피하려면 서두르지 말라고 한다.
8. 어떤 결정이든 적절성에 대해 걱정한다. 해당 행동이 그룹의 권한 내에 있는지, 혹은 더 높은 계층의 정책과 충돌할 가능성이 있는지를 의심하라고 한다.
-------

소위 이런 관료주의는 다음과 같은 특성이 있습니다.
1. 모든 결정을 위한 위원회를 만들고, 사소한 일도 복잡한 승인 절차를 거쳐야 합니다.
2. 사람들은 빠르게 행동하는 것을 경계하며, 모든 결정을 합의에 의존합니다.
3. 프로젝트의 범위는 계속해서 확장되며, "의미 없는 지표"나 "가시적인 성과"를 축하합니다.
4, 법률, 브랜드, 준법감시팀의 승인을 모든 사안에 필수적으로 요구합니다.
5. 이러한 방식은 일반적으로 "최선의 의도"로 시작되지만, 규모가 커지면서 효율성이 떨어지고, 관료주의가 만연하게 됩니다.

그리고 이런 관료주의는 사이클을 갖고 있습니다. IT와 같은 기술 산업도 예외는 아니죠..

1. 신생 스타트업이 등장하여 빠르고 공격적으로 시장을 장악합니다.
2. 이후 성장을 위해 관리자들을 채용하면서 점차 규모를 키우고, 결국 IPO에 성공합니다.
3. 시간이 지나 관료주의자들이 조직을 장악하고, 창업자는 물러나거나 엑시트하게 됩니다.
4. 이 과정에서 관료주의적 절차가 강화되고, 창의적이고 빠르게 움직이던 사람들은 회사를 떠납니다.

결국 성공하는 조직은 관료주의 모드로 전환되며, 새로운 스타트업이 등장하여 시장을 교체하는 패턴이 반복됩니다.

여러분의 조직은 어디쯤에 있나요?

조직에 비생산적인 환경을 조성하여 방해하는 방법에 대한 CIA의 매뉴얼 한장의 시사점이 크네요. 이걸 읽어보시면 과연 내가 속한 조직의 현재 모습이 아닌가 싶을 정도입니다. 결국 이런 모습을 보이면 조직은 망해간다고 생각해도 될 것 같습니다. ====== 1. 모든 절차를 반드시 '공식 경로'로 처리하도록 고집한다. 결정을 신속하게 내리기 위한 지름길은 허용하지 않는다. 2. '연설'을 한다. 가능한 자주, 그리고 길게 말한다. 긴 일화나 개인 경험을 이야기하며 자신의 '주장'을 설명한다 3.가능한 경우, 모든 사안을 '추가 연구와 검토'를 위해 위원회에 회부한다. 위원회는 최소 다섯 명 이상으로 구성한다. 4. 관련 없는 문제를 자주 제기한다. 5. 문서, 회의록, 결의안의 정확한 문구에 대해 끝없이 논쟁한다. 6. 지난 회의에서 결정된 문제를 다시 언급하고, 그 결정의 타당성에 대해 재검토를 요구한다. 7. '주의'를 권장한다. '합리적'이라는 명목으로 속도를 늦추고, 회의 참가자들에게도 신중하게 행동하라고 촉구한다. 추후 문제나 곤란함을 피하려면 서두르지 말라고 한다. 8. 어떤 결정이든 적절성에 대해 걱정한다. 해당 행동이 그룹의 권한 내에 있는지, 혹은 더 높은 계층의 정책과 충돌할 가능성이 있는지를 의심하라고 한다. ------- 소위 이런 관료주의는 다음과 같은 특성이 있습니다. 1. 모든 결정을 위한 위원회를 만들고, 사소한 일도 복잡한 승인 절차를 거쳐야 합니다. 2. 사람들은 빠르게 행동하는 것을 경계하며, 모든 결정을 합의에 의존합니다. 3. 프로젝트의 범위는 계속해서 확장되며, "의미 없는 지표"나 "가시적인 성과"를 축하합니다. 4, 법률, 브랜드, 준법감시팀의 승인을 모든 사안에 필수적으로 요구합니다. 5. 이러한 방식은 일반적으로 "최선의 의도"로 시작되지만, 규모가 커지면서 효율성이 떨어지고, 관료주의가 만연하게 됩니다. 그리고 이런 관료주의는 사이클을 갖고 있습니다. IT와 같은 기술 산업도 예외는 아니죠.. 1. 신생 스타트업이 등장하여 빠르고 공격적으로 시장을 장악합니다. 2. 이후 성장을 위해 관리자들을 채용하면서 점차 규모를 키우고, 결국 IPO에 성공합니다. 3. 시간이 지나 관료주의자들이 조직을 장악하고, 창업자는 물러나거나 엑시트하게 됩니다. 4. 이 과정에서 관료주의적 절차가 강화되고, 창의적이고 빠르게 움직이던 사람들은 회사를 떠납니다. 결국 성공하는 조직은 관료주의 모드로 전환되며, 새로운 스타트업이 등장하여 시장을 교체하는 패턴이 반복됩니다. 여러분의 조직은 어디쯤에 있나요?

<CIA 매뉴얼 : 조직 망하게 하기 >

계란후라이 1079

Challenge 도전이라는 단어는 사전에서 '정면으로 맞서 싸움을 거는 것이라고 정의하고 있습니다. 처음 알았네요. 도전이 이렇게 날카로운 뜻을 가지고 있는지 몰랐습니다. 평소에 생각하기를 도전이라고 하면 꿈을 향해 나아가는 낭만적인 과정이라고 이해했습니다.
돌이켜 보면 첫 회사에서 '챌린지'라는 표현을 자주 들었습니다. 신선식품 MD 본부에서 매주 월요일 아침, 지난주 매출 실적을 리뷰했습니다. 매출이 잘 안 나온 주간에는 원인을 더 철저히 분석하여 보고해야 했습니다. 그 주간 실적을 보고하는 자리에서 본부장님이 팀장님의 설명을 듣고 불호령을 내렸습니다. 씁쓸한 마음으로 자리에 돌아온 팀장님은 팀원을 붙잡고 본부장님에게 '챌린지' 받았다고 하소연했습니다. 본부장님이 팀장님을 정면으로 보고 맞서 싸움을 걸었으니 '챌린지'라는 표현이 정확히 맞네요.
저도 어제 오랜만에 강한 챌린지를 받았습니다. 예상하지 못했던 상황에서 갑자기 훅 치고 들어와서 멘탈이 약간 흔들렸습니다. 목덜미가 뻔뻔하게 경직되는 느낌과 함께 말이 제대로 나오지 않았습니다. 억울했지만 제대로 대꾸를 할 수 없었던 것은 어느 정도 제가 부족했던 것을 마음속으로 인정했기 때문입니다.
어제 받은 챌린지가 아쉽게 느껴졌던 것은 제가 글로 배운 피드백 방식과 너무 달랐습니다. 그래서 저를 챌린지 했던 분이 리더로서 역할을 하고 있는 부서의 구성원에게 저에게 어제 보여줬던 방식으로 피드백을 할까 봐 두렵다는 생각을 했습니다. 그리고 보니 제 직속 상사가 아니고 현업 관계에 있는 리더인데 챌린지 받은 상황이 더 어처구니없게 느껴집니다. 하지만 이 상황 가운데 제가 배우고 깨달아야 하는 점이 있겠죠.
다른 사람이 나에게 주는 피드백을 수용하는 것은 매우 어렵습니다. 내 생각과 다른 내용을 이해하고 공감하는 일이 쉽지 않기 때문입니다. 같은 사물과 현상을 보고 서로 다른 느낌을 받을 수 있는데, 그것을 마치 A라는 사람이 정답인 것처럼 B라는 사람에게 공감을 강요할 수 없습니다. K-직장에서 여전히 상사가 아랫사람에게 자신의 생각을 강요하는 문화가 존재합니다. 이와 같은 챌린지에 승자는 상사로 정해져 있습니다.
그러나 저는 더 이상 당하고 있지 않을 것입니다. 반격을 준비하여 시작해야죠. 똑같은 태도로 덤비지 않고 철저히 실력으로 보여주는 것입니다. 그래서 제발 나 좀 도와달라고 하소연하며 매달리게 만드는 것입니다. 복수는 나의 것! 기다리세요.

계란후라이 1079 Challenge 도전이라는 단어는 사전에서 '정면으로 맞서 싸움을 거는 것이라고 정의하고 있습니다. 처음 알았네요. 도전이 이렇게 날카로운 뜻을 가지고 있는지 몰랐습니다. 평소에 생각하기를 도전이라고 하면 꿈을 향해 나아가는 낭만적인 과정이라고 이해했습니다.돌이켜 보면 첫 회사에서 '챌린지'라는 표현을 자주 들었습니다. 신선식품 MD 본부에서 매주 월요일 아침, 지난주 매출 실적을 리뷰했습니다. 매출이 잘 안 나온 주간에는 원인을 더 철저히 분석하여 보고해야 했습니다. 그 주간 실적을 보고하는 자리에서 본부장님이 팀장님의 설명을 듣고 불호령을 내렸습니다. 씁쓸한 마음으로 자리에 돌아온 팀장님은 팀원을 붙잡고 본부장님에게 '챌린지' 받았다고 하소연했습니다. 본부장님이 팀장님을 정면으로 보고 맞서 싸움을 걸었으니 '챌린지'라는 표현이 정확히 맞네요.저도 어제 오랜만에 강한 챌린지를 받았습니다. 예상하지 못했던 상황에서 갑자기 훅 치고 들어와서 멘탈이 약간 흔들렸습니다. 목덜미가 뻔뻔하게 경직되는 느낌과 함께 말이 제대로 나오지 않았습니다. 억울했지만 제대로 대꾸를 할 수 없었던 것은 어느 정도 제가 부족했던 것을 마음속으로 인정했기 때문입니다.어제 받은 챌린지가 아쉽게 느껴졌던 것은 제가 글로 배운 피드백 방식과 너무 달랐습니다. 그래서 저를 챌린지 했던 분이 리더로서 역할을 하고 있는 부서의 구성원에게 저에게 어제 보여줬던 방식으로 피드백을 할까 봐 두렵다는 생각을 했습니다. 그리고 보니 제 직속 상사가 아니고 현업 관계에 있는 리더인데 챌린지 받은 상황이 더 어처구니없게 느껴집니다. 하지만 이 상황 가운데 제가 배우고 깨달아야 하는 점이 있겠죠.다른 사람이 나에게 주는 피드백을 수용하는 것은 매우 어렵습니다. 내 생각과 다른 내용을 이해하고 공감하는 일이 쉽지 않기 때문입니다. 같은 사물과 현상을 보고 서로 다른 느낌을 받을 수 있는데, 그것을 마치 A라는 사람이 정답인 것처럼 B라는 사람에게 공감을 강요할 수 없습니다. K-직장에서 여전히 상사가 아랫사람에게 자신의 생각을 강요하는 문화가 존재합니다. 이와 같은 챌린지에 승자는 상사로 정해져 있습니다.그러나 저는 더 이상 당하고 있지 않을 것입니다. 반격을 준비하여 시작해야죠. 똑같은 태도로 덤비지 않고 철저히 실력으로 보여주는 것입니다. 그래서 제발 나 좀 도와달라고 하소연하며 매달리게 만드는 것입니다. 복수는 나의 것! 기다리세요.

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

작년에 이겼던 실험군이 이번에는 지다.

세월 앞에 장사 없다

AB테스트에 대해서 많은 분들이 가지고 있는 오해 중 하나는, "한번 검증된 사실이 영원하다(?)" 라는 것 같습니다. 실제로 AB테스트는 Optimal Solution을 찾는 방법론이 아니라 주어진 제약조건 하에서의 국지적 최적점을 찾는 방법론이며, 시간의 흐름에 따라 그 결과가 얼마든지 달라질 수도 있습니다. (서비스도 바뀌고, 유저도 바뀌고, 사용 맥락도 바뀔 수 있으니까요)

실제 딜라이트룸에서 거의 동일한 AB테스트를 시차를 두고 진행해서, 다른 결론을 이끌어 낸 사례에 대해서 PO인 Stephan이 깔끔한 글을 정리해 주셨습니다.

AB테스트에 대해서 많은 분들이 가지고 있는 오해 중 하나는, "한번 검증된 사실이 영원하다(?)" 라는 것 같습니다. 실제로 AB테스트는 Optimal Solution을 찾는 방법론이 아니라 주어진 제약조건 하에서의 국지적 최적점을 찾는 방법론이며, 시간의 흐름에 따라 그 결과가 얼마든지 달라질 수도 있습니다. (서비스도 바뀌고, 유저도 바뀌고, 사용 맥락도 바뀔 수 있으니까요) 실제 딜라이트룸에서 거의 동일한 AB테스트를 시차를 두고 진행해서, 다른 결론을 이끌어 낸 사례에 대해서 PO인 Stephan이 깔끔한 글을 정리해 주셨습니다.

Medium

[세월 앞에 장사 없다]

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다. 바로 MongoTemplate와 MongoRepository 입니다. 이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다. MongoRepository와 MongoTemplate[MongoRepository] MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와..

Spring Boot의 MongoDB 연동: MongoTemplate vs MongoRepository

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다.

바로 MongoTemplate와 MongoRepository 입니다.
 
이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다.
 
[MongoRepository]
MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와 비슷하게 작동하며, MongoDB 데이터를 처리하는 데 매우 간단한 방법을 제공합니다.
 
장점
 * 기본적인 CRUD 작업을 자동으로 처리
 * 코드가 매우 간결하고 유지보수가 쉬움
 * 메서드 이름만으로 커스텀 쿼리를 작성할 수 있음 (ex. findByCategory)
단점
 * 복잡한 쿼리 작업에서는 제한적
 * 커스터마이징이 어렵고 고급 기능을 구현하기에 한계가 있음
 
[MongoTemplate]
MongoTemplate은 Spring의 템플릿 패턴을 사용한 MongoDB 연동 방식입니다. 더 복잡한 MongoDB 제어가 가능하며, 어려운 쿼리 작성에 적합합니다.
 
장점
 * 복잡한 쿼리나 커스텀 작업을 더 쉽게 수행 가능
 * MongoDB와의 깊이 있는 상호작용에 적합
 * 더 세밀한 데이터 처리와 제어가 가능
단점
 * 기본적인 CRUD 작업도 코드로 직접 작성해야 하므로 코드가 다소 복잡해짐
 * 레파지토리 패턴보다 다소 비효율적일 수 있음
 
[MongoRepository 사용 예시]

Product 엔티티
@Document(collection = "products")
public class Product {
 @Id
 private String id;
 private String name;
 private String category;
}

ProductRepository 인터페이스
public interface ProductRepository extends MongoRepository<Product, String> {
 List<Product> findByCategory(String category);
}

MongoRepository를 확장한 ProductRepository를 정의하였습니다. CRUD 메서드는 기본으로 제공되며, 커스텀으로 findByCategory 같은 메서드를 쉽게 추가할 수 있습니다.
 
CRUD 작업 사용 예시
@Autowired
private ProductRepository productRepository;

public void addProduct(Product product) {
 productRepository.save(product);
}

public List<Product> getProductsByCategory(String category) {
 return productRepository.findByCategory(category);
}

이처럼 MongoRepository를 사용하면 간단한 CRUD 작업을 매우 직관적으로 처리할 수 있습니다.
 
[MongoTemplate 사용 예시]
이번에는 같은 Product 엔티티를 사용하여 MongoTemplate을 이용한 예제를 살펴보겠습니다.
 
MongoTemplate으로 복잡한 쿼리 작성
@Autowired
private MongoTemplate mongoTemplate;

public List<Product> findProductsByCategory(String category) {
 Query query = new Query();
 query.addCriteria(Criteria.where("category").is(category));
 return mongoTemplate.find(query, Product.class);
}

위 코드에서는 MongoTemplate을 사용하여 MongoDB 쿼리를 직접 사용했습니다. Criteria와 Query 객체를 이용해 더 복잡한 쿼리나 고급 기능을 쉽게 구현할 수 있습니다.
 
CRUD 작업 처리 
public void addProduct(Product product) {
 mongoTemplate.save(product);
}

public Product getProductById(String id) {
 return mongoTemplate.findById(id, Product.class);
}

MongoTemplate을 사용하면 모든 작업을 수동으로 처리해야 하지만, 그만큼 더 세밀하게 제어할 수 있는 장점이 있습니다.
 
[어떤 것을 선택해야 할까?]
MongoRepository를 사용해야 할 때:
 * 기본적인 CRUD 작업을 빠르게 처리해야 할 때
 * 코드의 간결함과 유지보수의 용이함이 중요할 때
MongoTemplate을 사용해야 할 때:
 * 복잡한 쿼리나 트랜잭션 처리가 필요한 경우
 * 데이터베이스와의 더 세밀한 상호작용이 필요할 때
 
[결론]
MongoDB와 Spring Boot의 연동에서 MongoRepository와 MongoTemplate은 각각 다른 용도에 맞춰 설계된 도구입니다. 저는 실제 프로젝트에서 bulk upsert 기능이 필요한 상황을 겪었는데, MongoRepository에는 해당 기능이 기본적으로 제공되지 않아, 더 유연한 MongoTemplate을 사용할 수밖에 없었습니다. 물론 upsert를 여러 번 호출하는 방법도 가능하지만, 이는 비효율적이므로 MongoTemplate을 통해 간단히 처리할 수 있었습니다.
 
반면, 단순한 조회 작업에서는 MongoRepository를 사용했습니다. MongoTemplate보다 코드가 훨씬 깔끔하고 유지보수하기가 쉬웠기 때문입니다. 이처럼 MongoRepository는 기본적인 작업에 최적화되어 있고, MongoTemplate은 고급 작업에서 강력한 기능을 제공합니다.
 
결국 중요한 것은 프로젝트의 요구사항에 맞춰 이 두 방식을 적절히 선택하거나 혼합하여 사용하는 것입니다. 각 도구가 제공하는 장점을 최대한 활용해, 프로젝트에 가장 적합한 솔루션을 찾는 것이 성공적인 MongoDB 연동의 핵심입니다.

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다. 바로&nbsp;MongoTemplate와&nbsp;MongoRepository 입니다.&nbsp;이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다.&nbsp;[MongoRepository]MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와 비슷하게 작동하며, MongoDB 데이터를 처리하는 데 매우 간단한 방법을 제공합니다.&nbsp;장점<ul ><li>기본적인 CRUD 작업을 자동으로 처리</li><li>코드가 매우 간결하고 유지보수가 쉬움</li><li>메서드 이름만으로 커스텀 쿼리를 작성할 수 있음 (ex. findByCategory)</li></ul>단점<ul ><li>복잡한 쿼리 작업에서는 제한적</li><li>커스터마이징이 어렵고 고급 기능을 구현하기에 한계가 있음</li></ul>&nbsp;[MongoTemplate]MongoTemplate은 Spring의 템플릿 패턴을 사용한 MongoDB 연동 방식입니다. 더 복잡한 MongoDB 제어가 가능하며, 어려운 쿼리 작성에 적합합니다.&nbsp;장점<ul ><li>복잡한 쿼리나 커스텀 작업을 더 쉽게 수행 가능</li><li>MongoDB와의 깊이 있는 상호작용에 적합</li><li>더 세밀한 데이터 처리와 제어가 가능</li></ul>단점<ul ><li>기본적인 CRUD 작업도 코드로 직접 작성해야 하므로 코드가 다소 복잡해짐</li><li>레파지토리 패턴보다 다소 비효율적일 수 있음</li></ul>&nbsp;[MongoRepository 사용 예시] Product 엔티티<pre ><code class="language-java">@Document(collection = "products")
public class Product {
 @Id
 private String id;
 private String name;
 private String category;
}</code></pre>ProductRepository 인터페이스<pre ><code class="language-java">public interface ProductRepository extends MongoRepository&lt;Product, String&gt; {
 List&lt;Product&gt; findByCategory(String category);
}</code></pre>MongoRepository를 확장한 ProductRepository를 정의하였습니다. CRUD 메서드는 기본으로 제공되며, 커스텀으로 findByCategory 같은 메서드를 쉽게 추가할 수 있습니다.&nbsp;CRUD 작업 사용 예시<pre ><code class="language-java">@Autowired
private ProductRepository productRepository;

public void addProduct(Product product) {
 productRepository.save(product);
}

public List&lt;Product&gt; getProductsByCategory(String category) {
 return productRepository.findByCategory(category);
}</code></pre>이처럼 MongoRepository를 사용하면 간단한 CRUD 작업을 매우 직관적으로 처리할 수 있습니다.&nbsp;[MongoTemplate 사용 예시]이번에는 같은 Product 엔티티를 사용하여 MongoTemplate을 이용한 예제를 살펴보겠습니다.&nbsp;MongoTemplate으로 복잡한 쿼리 작성<pre ><code class="language-java">@Autowired
private MongoTemplate mongoTemplate;

public List&lt;Product&gt; findProductsByCategory(String category) {
 Query query = new Query();
 query.addCriteria(Criteria.where("category").is(category));
 return mongoTemplate.find(query, Product.class);
}</code></pre>위 코드에서는 MongoTemplate을 사용하여 MongoDB 쿼리를 직접 사용했습니다. Criteria와 Query 객체를 이용해 더 복잡한 쿼리나 고급 기능을 쉽게 구현할 수 있습니다.&nbsp;CRUD 작업 처리&nbsp;<pre ><code class="language-java">public void addProduct(Product product) {
 mongoTemplate.save(product);
}

public Product getProductById(String id) {
 return mongoTemplate.findById(id, Product.class);
}</code></pre>MongoTemplate을 사용하면 모든 작업을 수동으로 처리해야 하지만, 그만큼 더 세밀하게 제어할 수 있는 장점이 있습니다.&nbsp;[어떤 것을 선택해야 할까?]MongoRepository를 사용해야 할 때:<ul ><li>기본적인 CRUD 작업을 빠르게 처리해야 할 때</li><li>코드의 간결함과 유지보수의 용이함이 중요할 때</li></ul>MongoTemplate을 사용해야 할 때:<ul ><li>복잡한 쿼리나 트랜잭션 처리가 필요한 경우</li><li>데이터베이스와의 더 세밀한 상호작용이 필요할 때</li></ul>&nbsp;[결론]MongoDB와 Spring Boot의 연동에서 MongoRepository와 MongoTemplate은 각각 다른 용도에 맞춰 설계된 도구입니다. 저는 실제 프로젝트에서 bulk upsert 기능이 필요한 상황을 겪었는데, MongoRepository에는 해당 기능이 기본적으로 제공되지 않아, 더 유연한 MongoTemplate을 사용할 수밖에 없었습니다. 물론 upsert를 여러 번 호출하는 방법도 가능하지만, 이는 비효율적이므로 MongoTemplate을 통해 간단히 처리할 수 있었습니다.&nbsp;반면, 단순한 조회 작업에서는 MongoRepository를 사용했습니다. MongoTemplate보다 코드가 훨씬 깔끔하고 유지보수하기가 쉬웠기 때문입니다. 이처럼 MongoRepository는 기본적인 작업에 최적화되어 있고, MongoTemplate은 고급 작업에서 강력한 기능을 제공합니다.&nbsp;결국 중요한 것은 프로젝트의 요구사항에 맞춰 이 두 방식을 적절히 선택하거나 혼합하여 사용하는 것입니다. 각 도구가 제공하는 장점을 최대한 활용해, 프로젝트에 가장 적합한 솔루션을 찾는 것이 성공적인 MongoDB 연동의 핵심입니다.

덕토피아

MongoRepository vs MongoTemplate 차이와 활용

이거 3가지는 피하세요
1. 너무 많은 기능 - 한가지 기능에 집중하세요
2. 처음부터 완벽하게 만들기 - 린하게 만들고 이후에 반응이 오면 개선하세요
3. 오래 붙잡기 - 늘어지면 한도 끝도 없습니다 빠르면 2주, 적어도 1달안에 구체화 시키세요

이거 3가지는 피하세요1. 너무 많은 기능 - 한가지 기능에 집중하세요2. 처음부터 완벽하게 만들기 - 린하게 만들고 이후에 반응이 오면 개선하세요3. 오래 붙잡기 - 늘어지면 한도 끝도 없습니다 빠르면 2주, 적어도 1달안에 구체화 시키세요

사이드 프로젝트 만들다가 흐지부지 된 경험이 있다면

The guide to Git I never had.

Rebasing 과 Merging
Rebasing을 Merging과 비교하는 것은 의미가 있습니다. 두 명령의 목표는 같지만 이를 달성하는 방법이 다릅니다. 중요한 차이점은 Rebasing이 프로젝트의 히스토리를 재작성한다는 것입니다. 깔끔하고 이해하기 쉬운 프로젝트 히스토리를 중요시하는 프로젝트에 적합합니다. 반면, Merging은 새로운 병합 커밋을 생성하여 두 브랜치의 히스토리를 유지합니다.
 
Squashing
Git Squashing은 여러 커밋을 하나의 통합된 커밋으로 압축하는 데 사용됩니다.

Cherry-picking
Cherry-picking은 특정 브랜치의 변경 사항을 선택적으로 다른 브랜치에 통합할 때 유용합니다. 전체 브랜치를 병합하는 것이 바람직하지 않거나 불가능한 경우에 특히 유용합니다. 그러나 Cherry-picking을 신중하게 사용해야 하며, 잘못 사용할 경우 중복된 커밋과 분기된 히스토리를 초래할 수 있습니다.

Signing commits
Signing commits는 Git에서 커밋의 진위와 무결성을 검증하는 방법입니다. GNU Privacy Guard(GPG) 키를 사용해 커밋에 암호화 서명을 추가함으로써, 커밋 작성자가 본인임을 보장할 수 있습니다. GPG 키를 생성하고 Git이 커밋할 때 이 키를 사용하도록 설정할 수 있습니다.

Git Reflog
Git references는 Git 히스토리의 명명된 지점으로, 사용자가 저장소의 타임라인을 탐색하고 프로젝트의 특정 스냅샷에 접근할 수 있게 합니다. Git references를 탐색하는 방법을 알고 있으면 유용하며, 이를 위해 git reflog를 사용할 수 있습니다. 다음과 같은 장점이 있습니다:
 * 잃어버린 커밋 또는 브랜치 복구
 * 디버깅 및 문제 해결
 * 실수 취소

Interactive rebase
인터랙티브 리베이스는 커밋 히스토리를 대화형으로 재작성할 수 있는 강력한 Git 기능입니다. 커밋을 적용하기 전에 수정, 재정렬, 결합, 삭제할 수 있습니다.

Origin vs Upstream
origin은 로컬 Git 저장소와 연관된 기본 원격 저장소입니다. 저장소를 복제(clone)하면 해당 복제본이 기본적으로 origin 원격 저장소로 설정됩니다. 저장소를 포크(fork)했다면, 그 포크가 기본적으로 origin 저장소가 됩니다.
 
반면, upstream은 저장소가 포크된 원래 저장소를 가리킵니다.
 
포크된 저장소를 원래 프로젝트의 최신 변경 사항과 동기화하려면 upstream 저장소에서 변경 사항을 가져와(git fetch) 로컬 저장소에 병합(merge)하거나 리베이스(rebase)해야 합니다.
 
Conflicts
브랜치를 병합하거나 리베이스할 때 충돌이 발생해도 당황하지 마세요. 이는 저장소의 동일 파일 또는 여러 파일의 다른 버전 사이에 충돌하는 변경 사항이 있음을 의미하며, 대부분의 경우 쉽게 해결할 수 있습니다.
 
Feature Branch Workflow
각 새로운 기능이나 버그 수정은 별도의 브랜치에서 개발되고 완료된 후 메인 브랜치로 병합됩니다.
 * 장점: 변경 사항의 격리 및 충돌 감소
 * 단점: 복잡해질 수 있으며 철저한 브랜치 관리가 필요

Gitflow Workflow
Gitflow는 다양한 개발 작업을 위한 사전 정의된 브랜치를 포함하는 엄격한 브랜칭 모델을 정의합니다.
 * 메인, 개발, 기능, 릴리스, 핫픽스 브랜치와 같은 장기 브랜치를 포함합니다.
 * 장점: 정기 릴리스 및 장기 유지보수가 필요한 프로젝트에 적합
 * 단점: 소규모 팀에는 너무 복잡할 수 있음

Forking Workflow
이 워크플로우에서는 각 개발자가 메인 저장소를 복제(clone)하지만, 변경 사항을 메인 저장소에 직접 푸시하는 대신 자신의 포크에 푸시합니다. 이후 메인 저장소로 변경 사항을 제안하는 풀 리퀘스트를 생성하여 병합 전에 코드 리뷰 및 협업이 이루어집니다.
 * 이 워크플로우는 오픈 소스 Glasskube 저장소에서 협업하는 데 사용합니다.
 * 장점: 외부 기여자의 협업을 장려하면서 메인 저장소에 대한 직접적인 쓰기 권한 부여를 방지
 * 단점: 포크와 메인 저장소 간의 동기화 유지가 어려울 수 있음

Pull Request Workflow
포크 워크플로우와 유사하지만, 개발자가 메인 저장소에 직접 기능 브랜치를 생성합니다.
 * 장점: 코드 리뷰, 협업, 팀원 간의 지식 공유 촉진
 * 단점: 사람에 의존한 코드 리뷰로 인해 개발 과정에서 지연이 발생할 수 있음

Trunk-Based Development
빠른 반복 및 지속적 배포에 집중하는 팀이라면 메인 브랜치에서 직접 개발하고 작은 변경 사항을 자주 커밋하는 트렁크 기반 개발을 사용할 수 있습니다.
 * 장점: 빠른 반복, 지속적 통합, 소규모 자주 변경을 프로덕션에 배포하는 데 집중
 * 단점: 메인 브랜치의 안정성을 보장하기 위해 강력한 자동화 테스트 및 배포 파이프라인이 필요하며, 릴리스 일정이 엄격하거나 복잡한 기능 개발이 필요한 프로젝트에는 적합하지 않을 수 있음
 
Git Cheatsheet
 
# Clone a Repository
git clone <repository_url>

# Stage Changes for Commit
git add <file(s)>

# Commit Changes
git commit -m "Commit message"

# Push Changes to the Remote Repository
git push

# Force Push Changes (use with caution)
git push --force

# Reset Working Directory to Last Commit
git reset --hard

# Create a New Branch
git branch <branch_name>

# Switch to a Different Branch
git checkout <branch_name>

# Merge Changes from Another Branch
git merge <branch_name>

# Rebase Changes onto Another Branch (use with caution)
git rebase <base_branch>

# View Status of Working Directory
git status

# View Commit History
git log

# Undo Last Commit (use with caution)
git reset --soft HEAD^

# Discard Changes in Working Directory
git restore <file(s)>

# Retrieve Lost Commit References
git reflog

# Interactive Rebase to Rearrange Commits
git rebase --interactive HEAD~3

 
번역: [https://ducktopia.tistory.com/134]
원문:

Rebasing 과 MergingRebasing을 Merging과 비교하는 것은 의미가 있습니다. 두 명령의 목표는 같지만 이를 달성하는 방법이 다릅니다. 중요한 차이점은 Rebasing이 프로젝트의 히스토리를 재작성한다는 것입니다. 깔끔하고 이해하기 쉬운 프로젝트 히스토리를 중요시하는 프로젝트에 적합합니다. 반면, Merging은 새로운 병합 커밋을 생성하여 두 브랜치의 히스토리를 유지합니다.&nbsp;SquashingGit Squashing은 여러 커밋을 하나의 통합된 커밋으로 압축하는 데 사용됩니다. Cherry-pickingCherry-picking은 특정 브랜치의 변경 사항을 선택적으로 다른 브랜치에 통합할 때 유용합니다. 전체 브랜치를 병합하는 것이 바람직하지 않거나 불가능한 경우에 특히 유용합니다. 그러나 Cherry-picking을 신중하게 사용해야 하며, 잘못 사용할 경우 중복된 커밋과 분기된 히스토리를 초래할 수 있습니다. Signing commitsSigning commits는 Git에서 커밋의 진위와 무결성을 검증하는 방법입니다. GNU Privacy Guard(GPG) 키를 사용해 커밋에 암호화 서명을 추가함으로써, 커밋 작성자가 본인임을 보장할 수 있습니다. GPG 키를 생성하고 Git이 커밋할 때 이 키를 사용하도록 설정할 수 있습니다. Git ReflogGit references는 Git 히스토리의 명명된 지점으로, 사용자가 저장소의 타임라인을 탐색하고 프로젝트의 특정 스냅샷에 접근할 수 있게 합니다. Git references를 탐색하는 방법을 알고 있으면 유용하며, 이를 위해 git reflog를 사용할 수 있습니다. 다음과 같은 장점이 있습니다:<ul ><li>잃어버린 커밋 또는 브랜치 복구</li><li>디버깅 및 문제 해결</li><li>실수 취소</li></ul> Interactive rebase인터랙티브 리베이스는 커밋 히스토리를 대화형으로 재작성할 수 있는 강력한 Git 기능입니다. 커밋을 적용하기 전에 수정, 재정렬, 결합, 삭제할 수 있습니다. Origin vs Upstreamorigin은 로컬 Git 저장소와 연관된 기본 원격 저장소입니다. 저장소를 복제(clone)하면 해당 복제본이 기본적으로 origin 원격 저장소로 설정됩니다. 저장소를 포크(fork)했다면, 그 포크가 기본적으로 origin 저장소가 됩니다.&nbsp;반면, upstream은 저장소가 포크된 원래 저장소를 가리킵니다.&nbsp;포크된 저장소를 원래 프로젝트의 최신 변경 사항과 동기화하려면 upstream 저장소에서 변경 사항을 가져와(git fetch) 로컬 저장소에 병합(merge)하거나 리베이스(rebase)해야 합니다.&nbsp;Conflicts브랜치를 병합하거나 리베이스할 때 충돌이 발생해도 당황하지 마세요. 이는 저장소의 동일 파일 또는 여러 파일의 다른 버전 사이에 충돌하는 변경 사항이 있음을 의미하며, 대부분의 경우 쉽게 해결할 수 있습니다.&nbsp;Feature Branch Workflow각 새로운 기능이나 버그 수정은 별도의 브랜치에서 개발되고 완료된 후 메인 브랜치로 병합됩니다.<ul ><li>장점: 변경 사항의 격리 및 충돌 감소</li><li>단점: 복잡해질 수 있으며 철저한 브랜치 관리가 필요</li></ul> Gitflow WorkflowGitflow는 다양한 개발 작업을 위한 사전 정의된 브랜치를 포함하는 엄격한 브랜칭 모델을 정의합니다.<ul ><li>메인, 개발, 기능, 릴리스, 핫픽스 브랜치와 같은 장기 브랜치를 포함합니다.</li><li>장점: 정기 릴리스 및 장기 유지보수가 필요한 프로젝트에 적합</li><li>단점: 소규모 팀에는 너무 복잡할 수 있음</li></ul> Forking Workflow이 워크플로우에서는 각 개발자가 메인 저장소를 복제(clone)하지만, 변경 사항을 메인 저장소에 직접 푸시하는 대신 자신의 포크에 푸시합니다. 이후 메인 저장소로 변경 사항을 제안하는 풀 리퀘스트를 생성하여 병합 전에 코드 리뷰 및 협업이 이루어집니다.<ul ><li>이 워크플로우는 오픈 소스 Glasskube 저장소에서 협업하는 데 사용합니다.</li><li>장점: 외부 기여자의 협업을 장려하면서 메인 저장소에 대한 직접적인 쓰기 권한 부여를 방지</li><li>단점: 포크와 메인 저장소 간의 동기화 유지가 어려울 수 있음</li></ul> Pull Request Workflow포크 워크플로우와 유사하지만, 개발자가 메인 저장소에 직접 기능 브랜치를 생성합니다.<ul ><li>장점: 코드 리뷰, 협업, 팀원 간의 지식 공유 촉진</li><li>단점: 사람에 의존한 코드 리뷰로 인해 개발 과정에서 지연이 발생할 수 있음</li></ul> Trunk-Based Development빠른 반복 및 지속적 배포에 집중하는 팀이라면 메인 브랜치에서 직접 개발하고 작은 변경 사항을 자주 커밋하는 트렁크 기반 개발을 사용할 수 있습니다.<ul ><li>장점: 빠른 반복, 지속적 통합, 소규모 자주 변경을 프로덕션에 배포하는 데 집중</li><li>단점: 메인 브랜치의 안정성을 보장하기 위해 강력한 자동화 테스트 및 배포 파이프라인이 필요하며, 릴리스 일정이 엄격하거나 복잡한 기능 개발이 필요한 프로젝트에는 적합하지 않을 수 있음</li></ul>&nbsp;Git Cheatsheet&nbsp;<pre ><code class="language-bash"># Clone a Repository
git clone &lt;repository_url&gt;

# Stage Changes for Commit
git add &lt;file(s)&gt;

# Commit Changes
git commit -m "Commit message"

# Push Changes to the Remote Repository
git push

# Force Push Changes (use with caution)
git push --force

# Reset Working Directory to Last Commit
git reset --hard

# Create a New Branch
git branch &lt;branch_name&gt;

# Switch to a Different Branch
git checkout &lt;branch_name&gt;

# Merge Changes from Another Branch
git merge &lt;branch_name&gt;

# Rebase Changes onto Another Branch (use with caution)
git rebase &lt;base_branch&gt;

# View Status of Working Directory
git status

# View Commit History
git log

# Undo Last Commit (use with caution)
git reset --soft HEAD^

# Discard Changes in Working Directory
git restore &lt;file(s)&gt;

# Retrieve Lost Commit References
git reflog

# Interactive Rebase to Rearrange Commits
git rebase --interactive HEAD~3</code></pre>&nbsp;번역: [https://ducktopia.tistory.com/134]원문:

🕊️ [Medium] 내가 원했던, Git 가이드 (2)

돌이켜 생각해보면, 지금까지 꽤 많은 '인재 선발을 위한 인터뷰(면접)'를 진행했다. 대학교 시절 S&D 라는 경영학회 활동을 3~4년 하면서 '학회원 선발' 인터뷰를 진행했었고, 그 이후 BCG/Ringle 에서 다수 채용 인터뷰에 참여했다. 그리고, 컨설팅/MBA/스타트업에 입사하고자 했던 지인들의 mock interview를 도운것까지 합치면, '꽤 

기억에 남는 인터뷰(면접)의 특징

면접은 채용 과정에서 중요한 역할을 합니다. 서류 전형과 코딩 테스트를 후, 대부분의 최종 결정이 면접을 통해 이루어지기 때문인데요. 최근 ‘기억에 남는 인터뷰(면접)의 특징’ 이라는 글을 보게 되었는데, 공감도 되고 괜찮은 내용이라 소개드립니다.

 1. 아이컨택을 잘한다.
    아이컨택은 단순 시선 처리 이상의 의미를 갖습니다. 아이컨택을 통해 면접자는 진정성을 전달하고, 암기된 답변이 아닌 소통을 하고 있음을 보여줍니다. 사람은 논리적인 면보다 정서적인 공감에 더 강하게 반응하기 때문에, 이런 자연스러운 아이컨택은 더 깊은 인상을 남길 수 있습니다.
    
    
 2. 어설프게 논리적이지 않고, 자연스럽게 논리적이다.
    근거가 적절하며 자연스럽게 이어지는 대화속에서도 논리와 스토리가 묻어 있는 사람들이 있습니다. 이런 사람은 어설프게 연습해서 면접 답변을 하기 보다는, 평소 소통 방식에서도 자연스럽게 소통하면서 그 안에 구조적 사고와 논리적 표현이 내재화 되어 있음을 보여줍니다.
    
    
 3. 발표가 아닌 대화
    일방적인 발표를 하는 느낌으로 면접을 보는 분들이 많습니다. 그런 답변은 면접관 으로서 흥미와 공감이 떨어집니다. 반면 ‘대화가 통한다’는 느낌을 주는 분들이 있습니다. 핵심적인 답변을 짧고 명확 하게 하고, 인터뷰어는 다시 질문 - 답변 으로 티키타카 식의 소통은 면접관에게 ‘대화가 통한다’는 느낌을 주며, 면접의 전반적인 분위기도 생동감이 듭니다.
    
    
 4. 솔직함
    역량, 리더십, 품성 이 느껴지는 사람의 특징은 매우 솔직합니다. 시행착오나 실패도 덤덤하게 풀어내는 분들은 기억에 오래 남습니다. 이런 솔직함은 면접관에게 강한 신뢰감을 주는데요. 성공 스토리만큼이나 실패를 극복한 경험 역시 중요하기 때문입니다.
    
    
 5. 의지, 생각 보다는 경험
    의지나 생각은 그 사람의 본질이 아닙니다. 개인의 진정한 모습은 과거의 경험을 통해 가장 잘 드러나는데요. 과거 경험을 바탕으로 한 이야기는 면접관의 관심을 끌며, 면접관 자신의 경험 역시도 떠올리게 하여 더욱 깊이 있는 대화로 이어질 수 있습니다.
    
    
 6. 회사에 호기심을 가지고 있다
    회사, 제품에 호기심이 없는 사람은 입사를 하더라도 평범하게 일할 확률이 높습니다. 하지만 회사와 제품에 진정한 호기심을 보이는 면접자라면 입사 후에도 회사에 더 큰 기여를 할 수 있는 잠재력을 보여줍니다.
    
    
 7. 자세/태도가 모두 좋다.
    앉은 자세 및 태도(제스처) 도 중요한 평가 요소입니다. 안정된 자세, 적절한 제스처 는 중요한 비언어적 신호로써, 평소에도 이러한 태도로 일할 가능성이 높음을 시사하기 때문입니다.
    
    
 8. 질문도 한다.
    면접 과정에서도 중간에 질문을 하는 사람이 있습니다. 바로 질문해야 하는 타이밍에, 꼭 해야 할 질문을, 짧고 명확하게 하는 사람들인데요. 이런 질문으로 인해 면접관은 ‘똑똑하다’ 라는 인상을 받게 됩니다. 또한 올바른 질문을 잘 하는 사람은 향후 업무에서도 주체적이고 능동적으로 일할 확률이 높습니다.

개발자의 경우, 소통하는데 있어 솔직한 나의 모습을 직관적으로 전달하기 어려울 때가 있는데요. 결국에는 지속적인 연습과 피드백을 통해 자신의 진정한 모습을 효과적으로 전달할 수 있도록 노력하는 것이 중요할것 같습니다. 그리고 위에서 언급한 특징을 염두에 두고 준비한다면, 자신의 가치를 최대한 드러낼 수 있을 것입니다.

결국 중요한것은 자신의 경험과 역량을 진정성 있게 전달하면서도, 지원하는 회사와 직무에 대한 깊은 이해와 열정이 중요할 것 같습니다.이런 준비와 태도를 통해 면접관에게 깊은 인상을 남기며, 성공적인 면접 결과로 이어질 수 있습니다.

https://brunch.co.kr/@seunghoon82/559

면접은 채용 과정에서 중요한 역할을 합니다. 서류 전형과 코딩 테스트를 후, 대부분의 최종 결정이 면접을 통해 이루어지기 때문인데요. 최근 ‘기억에 남는 인터뷰(면접)의 특징’ 이라는 글을 보게 되었는데, 공감도 되고 괜찮은 내용이라 소개드립니다. <ol ><li>아이컨택을 잘한다.아이컨택은 단순 시선 처리 이상의 의미를 갖습니다. 아이컨택을 통해 면접자는 진정성을 전달하고, 암기된 답변이 아닌 소통을 하고 있음을 보여줍니다. 사람은 논리적인 면보다 정서적인 공감에 더 강하게 반응하기 때문에, 이런 자연스러운 아이컨택은 더 깊은 인상을 남길 수 있습니다. </li><li>어설프게 논리적이지 않고, 자연스럽게 논리적이다.근거가 적절하며 자연스럽게 이어지는 대화속에서도 논리와 스토리가 묻어 있는 사람들이 있습니다. 이런 사람은 어설프게 연습해서 면접 답변을 하기 보다는, 평소 소통 방식에서도 자연스럽게 소통하면서 그 안에 구조적 사고와 논리적 표현이 내재화 되어 있음을 보여줍니다. </li><li>발표가 아닌 대화일방적인 발표를 하는 느낌으로 면접을 보는 분들이 많습니다. 그런 답변은 면접관 으로서 흥미와 공감이 떨어집니다. 반면 ‘대화가 통한다’는 느낌을 주는 분들이 있습니다. 핵심적인 답변을 짧고 명확 하게 하고, 인터뷰어는 다시 질문 - 답변 으로 티키타카 식의 소통은 면접관에게 ‘대화가 통한다’는 느낌을 주며, 면접의 전반적인 분위기도 생동감이 듭니다. </li><li>솔직함역량, 리더십, 품성 이 느껴지는 사람의 특징은 매우 솔직합니다. 시행착오나 실패도 덤덤하게 풀어내는 분들은 기억에 오래 남습니다. 이런 솔직함은 면접관에게 강한 신뢰감을 주는데요. 성공 스토리만큼이나 실패를 극복한 경험 역시 중요하기 때문입니다. </li><li>의지, 생각 보다는 경험의지나 생각은 그 사람의 본질이 아닙니다. 개인의 진정한 모습은 과거의 경험을 통해 가장 잘 드러나는데요. 과거 경험을 바탕으로 한 이야기는 면접관의 관심을 끌며, 면접관 자신의 경험 역시도 떠올리게 하여 더욱 깊이 있는 대화로 이어질 수 있습니다. </li><li>회사에 호기심을 가지고 있다회사, 제품에 호기심이 없는 사람은 입사를 하더라도 평범하게 일할 확률이 높습니다. 하지만 회사와 제품에 진정한 호기심을 보이는 면접자라면 입사 후에도 회사에 더 큰 기여를 할 수 있는 잠재력을 보여줍니다. </li><li>자세/태도가 모두 좋다.앉은 자세 및 태도(제스처) 도 중요한 평가 요소입니다. 안정된 자세, 적절한 제스처 는 중요한 비언어적 신호로써, 평소에도 이러한 태도로 일할 가능성이 높음을 시사하기 때문입니다. </li><li>질문도 한다.면접 과정에서도 중간에 질문을 하는 사람이 있습니다. 바로 질문해야 하는 타이밍에, 꼭 해야 할 질문을, 짧고 명확하게 하는 사람들인데요. 이런 질문으로 인해 면접관은 ‘똑똑하다’ 라는 인상을 받게 됩니다. 또한 올바른 질문을 잘 하는 사람은 향후 업무에서도 주체적이고 능동적으로 일할 확률이 높습니다.</li></ol> 개발자의 경우, 소통하는데 있어 솔직한 나의 모습을 직관적으로 전달하기 어려울 때가 있는데요. 결국에는 지속적인 연습과 피드백을 통해 자신의 진정한 모습을 효과적으로 전달할 수 있도록 노력하는 것이 중요할것 같습니다. 그리고 위에서 언급한 특징을 염두에 두고 준비한다면, 자신의 가치를 최대한 드러낼 수 있을 것입니다. 결국 중요한것은 자신의 경험과 역량을 진정성 있게 전달하면서도, 지원하는 회사와 직무에 대한 깊은 이해와 열정이 중요할 것 같습니다.이런 준비와 태도를 통해 면접관에게 깊은 인상을 남기며, 성공적인 면접 결과로 이어질 수 있습니다. https://brunch.co.kr/@seunghoon82/559

인상적인 면접자의 8가지 특징: 성공적인 면접을 위한 가이드

우아한형제들과 우아하게 이별하기를 해보려 합니다. 떠나는 마당에 코드 한 줄을 더 작성할 수도 있겠지만 이번에는 2022.05–2024.09까지의 회사 생활을 되돌아보고 공유하기로 하였습니다.

우아한형제들 퇴사 부검

iOS 프로그래머인 민호님이 우아한형제들을 떠나며 남긴 퇴사부검 입니다.

기대하는 바가 있었지만 점차 사라져버린 것에 아쉬움을 느껴서 새로운 곳에서 도전을 시작하신다고 하네요.

바람을 극복한 프로그래머로 좋은 소식 기다립니다!

https://medium.com/a-day-of-a-programmer/우아한형제들-퇴사-부검-010ce38609a5

iOS 프로그래머인 민호님이 우아한형제들을 떠나며 남긴 퇴사부검 입니다. 기대하는 바가 있었지만 점차 사라져버린 것에 아쉬움을 느껴서 새로운 곳에서 도전을 시작하신다고 하네요. 바람을 극복한 프로그래머로 좋은 소식 기다립니다! https://medium.com/a-day-of-a-programmer/우아한형제들-퇴사-부검-010ce38609a5

민호님의 우아한형제들 퇴사부검

동료에게 “놀랍지 않은 사람”이 되어보세요.

성과는 놀랍지만 일과는 예측 가능한 사람이 되어보세요.

예측 가능성은 상호 신뢰로 이어져요. 이후에는 척하면 척하는 팀이 되더라고요.

핵심은 주도적인 과정의 공유라고 생각해요. 여러분의 업무 과정을 애써 공유하세요.

공유했던 대로 업무를 끝낸 여러분을 보고 동료들은 ”역시! 믿고 있었다고!“라고, 생각할 거예요.

동료에게 “놀랍지 않은 사람”이 되어보세요. 성과는 놀랍지만 일과는 예측 가능한 사람이 되어보세요. 예측 가능성은 상호 신뢰로 이어져요. 이후에는 척하면 척하는 팀이 되더라고요. 핵심은 주도적인 과정의 공유라고 생각해요. 여러분의 업무 과정을 애써 공유하세요. 공유했던 대로 업무를 끝낸 여러분을 보고 동료들은 ”역시! 믿고 있었다고!“라고, 생각할 거예요.

예측 가능한 사람되기

Begin with the basics to understand Docker and Kubernetes networking: learn how to create and interconnect Linux network namespaces using only command-line tools.


How Container Networking Works: a Docker Bridge Network From Scratch | iximiuz Labs

컨테이너의 브릿지 네트워크가 어떻게 동작하는지를 배워볼 수 있는 재미있는 사이트입니다.

네트워크는 여전히 저에게 너무 어렵긴 한데 netns, veth, bridge, NAT를 설명하면서 우측에 플레이그라운드를 제공하기 때문에 웹사이트에서 설명에 나온 명령어를 따라해보면서 직접 구성해 볼 수 있습니다.

하나하나 직접 따라해보고 테스트도 해볼 수 있기 때문에 브릿지 네트워크를 이해해 보기 좋은 튜토리얼 사이트라고 생각합니다.

일반적으로는 컨테이너의 네트워크가 잘 동작하기 때문에 다 알아야 할 필요는 없지만 종종 겪게되는 엣지 케이스에서는 이러한 네트워크 구성을 알면 트러블시팅 및 원인 파악에 큰 도움이 되기 때문에 자세한 부분은 그때그때 찾아보더라도 전체적인 구조를 이해해두는 건 큰 도움이 된다고 생각합니다.

https://labs.iximiuz.com/tutorials/container-networking-from-scratch

컨테이너의 브릿지 네트워크가 어떻게 동작하는지를 배워볼 수 있는 재미있는 사이트입니다. 네트워크는 여전히 저에게 너무 어렵긴 한데 netns, veth, bridge, NAT를 설명하면서 우측에 플레이그라운드를 제공하기 때문에 웹사이트에서 설명에 나온 명령어를 따라해보면서 직접 구성해 볼 수 있습니다. 하나하나 직접 따라해보고 테스트도 해볼 수 있기 때문에 브릿지 네트워크를 이해해 보기 좋은 튜토리얼 사이트라고 생각합니다. 일반적으로는 컨테이너의 네트워크가 잘 동작하기 때문에 다 알아야 할 필요는 없지만 종종 겪게되는 엣지 케이스에서는 이러한 네트워크 구성을 알면 트러블시팅 및 원인 파악에 큰 도움이 되기 때문에 자세한 부분은 그때그때 찾아보더라도 전체적인 구조를 이해해두는 건 큰 도움이 된다고 생각합니다. https://labs.iximiuz.com/tutorials/container-networking-from-scratch

iximiuz Labs

컨테이너의 브릿지 네트워크가 어떻게 동작하는지를 배워볼 수 있는 

오랫동안 React 프로젝트를 만들기 위해서 Create React App라는 CLI 도구가 사용되었습니다.
State of JS 2023 설문 결과를 보시면 Create React App을 사용해봤다는 응답자가 90%가 넘을 정도로 CRA는 오랫동안 React 생태계에서 프로젝트를 생성하는 표준처럼 여겨졌습니다.

하지만 CRA는 2022년 4월 이후로 업데이트가 전혀 없으며, React 공식 문서에서도 사라지면서 사실 상 폐기(deprecated) 수순을 밟고 있습니다.

Next.js도 React 프로젝트를 만들기 위해서 많이 사용되는데요. 하지만 Next.js는 프로젝트 생성 뿐만 아니라 라우팅, 데이터 패칭(fetching), Server-Side Rendering(SSR), Static Site Generation(SSG), 이미지 최적화 등 온갖 부가 기능을 지원하는 메타 프레임워크입니다. 따라서 제대로 활용하려면 배워야할 것도 많고 CRA처럼 간단하게 React 프로젝트를 만들어 보는데는 적합한 도구가 아니죠.

이러한 이유로 최근에 Vite가 CRA의 대안 기술로 부상하고 있습니다. Vite를 사용하면 CRA처럼 간편하게 React 프로젝트를 만들 수 있을 뿐만 아니라, CRA보다 훨씬 빠르고 쾌적한 개발 서버를 사용할 수 있습니다.

뿐만 아니라, CRA로 만든 프로젝트는 규모가 커지면 결국 돌이킬 수 없는 eject를 해야한다는 부담이 있었는데, Vite는 그런 걱정없이 소규모 프로젝트부터 대규모 프로젝트까지 범용적으로 쓸 수 있도록 설계되어 있습니다.

이번 포스팅에서는 차세대 번들러인 Vite 사용하여 React 프로젝트를 생성하고 설정하는 방법에 대해서 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/vite-react/

Vite에 대한 기초적인 내용에 대해서는 아래 게시물을 참고하세요.
📕 Vite 처음 시작하기: https://careerly.co.kr/comments/110882

오랫동안 React 프로젝트를 만들기 위해서 Create React App라는 CLI 도구가 사용되었습니다.State of JS 2023 설문 결과를 보시면 Create React App을 사용해봤다는 응답자가 90%가 넘을 정도로 CRA는 오랫동안 React 생태계에서 프로젝트를 생성하는 표준처럼 여겨졌습니다. 하지만 CRA는 2022년 4월 이후로 업데이트가 전혀 없으며, React 공식 문서에서도 사라지면서 사실 상 폐기(deprecated) 수순을 밟고 있습니다. Next.js도 React 프로젝트를 만들기 위해서 많이 사용되는데요. 하지만 Next.js는 프로젝트 생성 뿐만 아니라 라우팅, 데이터 패칭(fetching), Server-Side Rendering(SSR), Static Site Generation(SSG), 이미지 최적화 등 온갖 부가 기능을 지원하는 메타 프레임워크입니다. 따라서 제대로 활용하려면 배워야할 것도 많고 CRA처럼 간단하게 React 프로젝트를 만들어 보는데는 적합한 도구가 아니죠. 이러한 이유로 최근에 Vite가 CRA의 대안 기술로 부상하고 있습니다. Vite를 사용하면 CRA처럼 간편하게 React 프로젝트를 만들 수 있을 뿐만 아니라, CRA보다 훨씬 빠르고 쾌적한 개발 서버를 사용할 수 있습니다. 뿐만 아니라, CRA로 만든 프로젝트는 규모가 커지면 결국 돌이킬 수 없는 eject를 해야한다는 부담이 있었는데, Vite는 그런 걱정없이 소규모 프로젝트부터 대규모 프로젝트까지 범용적으로 쓸 수 있도록 설계되어 있습니다. 이번 포스팅에서는 차세대 번들러인 Vite 사용하여 React 프로젝트를 생성하고 설정하는 방법에 대해서 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/vite-react/ Vite에 대한 기초적인 내용에 대해서는 아래 게시물을 참고하세요.📕 Vite 처음 시작하기: https://careerly.co.kr/comments/110882

CRA 대신에 Vite로 React 프로젝트 시작하기

1
단순히 해야 할 일만 적어 넣으면 점점 일이 쌓이는 것 같은 압박감을 느낀다.

2
그런데 그 옆에 언제까지 그 일을 할 것인지 시간을 할당해놓으면, 해야 할 일이 아니라 해결한 일이 더 많아지는 느낌이다. 이는 성취감마저 느끼게 하고 알차게 살고 있다는 뿌듯함을 준다.

3
눈에 보이지 않는 것들을 눈에 보이게 만들면 생산성과 효율성이 획기적으로 증가한다.

4
시간을 할당해 두려움과 걱정을 한곳으로 몰아넣어라. 한곳에 몰아넣으면 그것들을 통제하는 것이 가능해진다. 두려움을 통제하는 사람은 포기하지 않는다.

5
우리에게 필요한 것은 '의식적인 멈춤'이다. 의식적으로 한 걸음 물러나서 흐름을 통찰하는 것이다.

6
나는 수첩에 '멈춰야 할 시간'이란 항목을 마련해놓고 있다. 중요한 의사결정이나 브리핑, 미팅이 있는 날 아침에는 수첩을 열어 호흡을 가다듬고 생각을 차분히 정리하는 시간을 미리 정해놓는다.

7
이런 습관을 들이면 중요한 일이 있을 때 방향을 잃지 않게 된다. 팽팽한 긴장감에서 1분 만이라도 벗어나 침착해지면, 중요한 것들을 놓치고 후회하는 일이 놀랍게 줄어든다.

8
어떤 경험을 하고 났을 때는 그 경험에 이름을 붙여주어라. 긍정적인 이름이나 제목을 붙여 기억은행 속에 예치해둔다. 그러면 그 경험이 비록 끔찍한 것이었다 할지라도 부정적 감정이 아니라 하나의 교훈이 먼저 소환된다.

9
인간의 잠재의식은 언제나 한 번에 한 장면만 불러낼 수 있도록 작동한다. 다시 말해 긍정적인 생각을 하면 부정적 생각이 비집고 들어올 자리가 없다. 모든 행동이 그렇다. 무엇인가를 집중적으로 행하고 주의를 기울이면 두려움이 끼어들 자리가 생겨나지 않는다.

1 단순히 해야 할 일만 적어 넣으면 점점 일이 쌓이는 것 같은 압박감을 느낀다. ​ ​2 그런데 그 옆에 언제까지 그 일을 할 것인지 시간을 할당해놓으면, 해야 할 일이 아니라 해결한 일이 더 많아지는 느낌이다. 이는 성취감마저 느끼게 하고 알차게 살고 있다는 뿌듯함을 준다. ​ ​3​ 눈에 보이지 않는 것들을 눈에 보이게 만들면 생산성과 효율성이 획기적으로 증가한다. ​ ​4 시간을 할당해 두려움과 걱정을 한곳으로 몰아넣어라. 한곳에 몰아넣으면 그것들을 통제하는 것이 가능해진다. 두려움을 통제하는 사람은 포기하지 않는다. ​ ​5​ 우리에게 필요한 것은 '의식적인 멈춤'이다. 의식적으로 한 걸음 물러나서 흐름을 통찰하는 것이다. ​ ​6 나는 수첩에 '멈춰야 할 시간'이란 항목을 마련해놓고 있다. 중요한 의사결정이나 브리핑, 미팅이 있는 날 아침에는 수첩을 열어 호흡을 가다듬고 생각을 차분히 정리하는 시간을 미리 정해놓는다. ​ ​7 이런 습관을 들이면 중요한 일이 있을 때 방향을 잃지 않게 된다. 팽팽한 긴장감에서 1분 만이라도 벗어나 침착해지면, 중요한 것들을 놓치고 후회하는 일이 놀랍게 줄어든다. ​ ​8​ 어떤 경험을 하고 났을 때는 그 경험에 이름을 붙여주어라. 긍정적인 이름이나 제목을 붙여 기억은행 속에 예치해둔다. 그러면 그 경험이 비록 끔찍한 것이었다 할지라도 부정적 감정이 아니라 하나의 교훈이 먼저 소환된다. ​ ​​9 인간의 잠재의식은 언제나 한 번에 한 장면만 불러낼 수 있도록 작동한다. 다시 말해 긍정적인 생각을 하면 부정적 생각이 비집고 들어올 자리가 없다. 모든 행동이 그렇다. 무엇인가를 집중적으로 행하고 주의를 기울이면 두려움이 끼어들 자리가 생겨나지 않는다.

< 할 일을 쉽게 해치우는 시간 관리의 기술 >

What I've learned from spending a summer in SF

[Frontier] 실리콘밸리의 여름.

실리콘밸리에서 여름을 보내며 배운 10가지라고 해주셨는데, 많은 분들이 보시면 좋을 것 같아 공유해보아요. 원문을 꼭 읽어보셔요.

 1.  Have conviction and keep building (자기 확신을 가지고 계속 만들어라.)
 2.  Don't think about A -> Z, focus on A -> B (체계적인 계획이 아니라, 당장 빠르게 잘 실행하는 것에 집중하라)
 3.  10 Loving customers is all you need (10명이 제품을 사랑하게 하라)
 4.  Technical founding team is key (코파운더의 기술적 능력이 필수적이다)
 5.  Keep showing up to YC, a16z SR etc... (미국 진출을 위해 미국 accelerator에 문을 계속 두드리자)
 6.  Follow your energy
 7.  Live the life you would live if you knew you wouldn't fail. (실패하지 않을 거라 가정하고, 가장 기대되는 인생을 살자)
 8.  Obsession and taste (제품과 고객에 대한 집착과 완벽주의)
 9.  AI is really changing the world (AI는 정말 세상을 바꾸고 있다)
 10. Seoul vs San Francisco
     
     
https://frontierbydoyeob.substack.com/p/frontier

실리콘밸리에서 여름을 보내며 배운 10가지라고 해주셨는데, 많은 분들이 보시면 좋을 것 같아 공유해보아요. 원문을 꼭 읽어보셔요. <ol ><li>Have conviction and keep building (자기 확신을 가지고 계속 만들어라.)</li><li>Don't think about A -&gt; Z, focus on A -&gt; B (체계적인 계획이 아니라, 당장 빠르게 잘 실행하는 것에 집중하라)</li><li>10 Loving customers is all you need (10명이 제품을 사랑하게 하라)</li><li>Technical founding team is key (코파운더의 기술적 능력이 필수적이다)</li><li>Keep showing up to YC, a16z SR etc... (미국 진출을 위해 미국 accelerator에 문을 계속 두드리자)</li><li>Follow your energy</li><li>Live the life you would live if you knew you wouldn't fail. (실패하지 않을 거라 가정하고, 가장 기대되는 인생을 살자)</li><li>Obsession and taste (제품과 고객에 대한 집착과 완벽주의)</li><li>AI is really changing the world (AI는 정말 세상을 바꾸고 있다)</li><li>Seoul vs San Francisco </li></ol>https://frontierbydoyeob.substack.com/p/frontier

frontierbydoyeob.substack.com

실리콘밸리에서 깨달은 10가지

사용자가 공유한 콘텐츠

1. “(요즘 데이터로 확인되는 흐름 중 하나는) 직급이 아닌 '이름' 으로 불리는 이들이 늘고 있는 거예요”

2. “(지금까지) 우리 사회는 이름에 참 각박한 사회였어요. 내 이름으로 불리는 기간이 아주 짧았죠. 신입 사원 때 잠깐 이름으로 불리다 직급을 다는 순간 '김 대리'가 돼요. 심지어 퇴직 후 20년이 지나도 옛 동료끼리는 서로를 마지막 직급으로 부른다고 하죠”

3. “물론 (직급을 부른 문화에는) 성취에 대한 인정도 있지만, (어떤 면에선) 부당해요. 각자의 다양성과 다면성을 (직급을 부르며) 제거하는 거니까요. (그러다) 주체적으로 자신의 삶을 사는 (요즘의) '핵개인'들은, 직급이 아닌 자기 이름으로 불린다는 걸 알게 됐어요”

4. “이름으로 부른다는 건 곧 단독자로서의 지칭이자 그의 아이덴티티를 인식한다는 뜻이잖아요? (그러면서 생각했죠) 이제는 홀로 선 각자가 서로의 이름을 부르는 시대로 가는구나, 서로의 소중함을 인식하는구나, 그래서 (시대예보 책 타이틀에) '호명사회'라는 이름을 붙인 거예요”

5. “이런 사회 변화는 (크게) 2가지 키워드로 정리할 수 있어요. 첫 번째는 '유동화(=스트리밍화)'. (이젠) 한 사람이 여러 곳의 일을 동시에 할 수 있게 됐어요. (단순히 사람을 채용하는 것이 아니라) 그 사람이 가진 능력을 사는 시대가 되고 있는 거죠”

6. “두 번째는 극소화(=극단적 효율화)예요. 자동화와 플랫폼의 등장으로 한 명이 할 수 있는 일이 많아졌어요. 무리 지어 일할 필요가 없어진 거죠. 그러면 개인의 영향력이 극단적으로 증강됩니다. '내가 80% 이상을 일하는데, 왜 우리 팀은 4명이지?' 그 의문에서 1인 기업을 택하는 분들이 늘고 있죠. 그게 (더) 합리적인 선택이라고 판단하니까요”

7. “이렇듯 점차 개인의 이름이 드러나는 사회로 가고 있어요. 그런 사회에서는 온전히 자신이 만든 것을 세상에 알리며 성과를 쌓아가는 사람에게 많은 이들이 열광하게 돼요. 내가 한 일이라면 그 결과가 나에게 온전히 귀속되는 사회, 새로운 공정 사회가 오고 있는 거죠”

8. “(바꿔 말하면, 무슨 전문가니, 컨설턴트니, 코치니 하는 온갖 직업명이나 수식어로 자기를 꾸미는 퍼스널 브랜딩의 시대는 끝났고, 그 사람이 무슨 일을 했고, 어떤 결과를 만들었는지를 중심으로, 그 개인의 시간과 능력을 사려는 분위기가 생기고 있다는 얘깁니다)”

9. “(그러니 온갖 미사여구를 동원해 자기 자신을 억지로 브랜딩하려고 하지 말고, 지금부터는 딱 깔끔하게 실력과 능력과 결과로, 자기 이름이 지닌 가치를 높이세요. 그렇게 자기 이름으로 업계에서 네임드가 되세요. 앞으로는 훨씬 더 중요할 겁니다)”

- 송길영 박사

1. “(요즘 데이터로 확인되는 흐름 중 하나는) 직급이 아닌 '이름' 으로 불리는 이들이 늘고 있는 거예요” 2. “(지금까지) 우리 사회는 이름에 참 각박한 사회였어요. 내 이름으로 불리는 기간이 아주 짧았죠. 신입 사원 때 잠깐 이름으로 불리다 직급을 다는 순간 '김 대리'가 돼요. 심지어 퇴직 후 20년이 지나도 옛 동료끼리는 서로를 마지막 직급으로 부른다고 하죠” 3. “물론 (직급을 부른 문화에는) 성취에 대한 인정도 있지만, (어떤 면에선) 부당해요. 각자의 다양성과 다면성을 (직급을 부르며) 제거하는 거니까요. (그러다) 주체적으로 자신의 삶을 사는 (요즘의) '핵개인'들은, 직급이 아닌 자기 이름으로 불린다는 걸 알게 됐어요” 4. “이름으로 부른다는 건 곧 단독자로서의 지칭이자 그의 아이덴티티를 인식한다는 뜻이잖아요? (그러면서 생각했죠) 이제는 홀로 선 각자가 서로의 이름을 부르는 시대로 가는구나, 서로의 소중함을 인식하는구나, 그래서 (시대예보 책 타이틀에) '호명사회'라는 이름을 붙인 거예요” 5. “이런 사회 변화는 (크게) 2가지 키워드로 정리할 수 있어요. 첫 번째는 '유동화(=스트리밍화)'. (이젠) 한 사람이 여러 곳의 일을 동시에 할 수 있게 됐어요. (단순히 사람을 채용하는 것이 아니라) 그 사람이 가진 능력을 사는 시대가 되고 있는 거죠” 6. “두 번째는 극소화(=극단적 효율화)예요. 자동화와 플랫폼의 등장으로 한 명이 할 수 있는 일이 많아졌어요. 무리 지어 일할 필요가 없어진 거죠. 그러면 개인의 영향력이 극단적으로 증강됩니다. '내가 80% 이상을 일하는데, 왜 우리 팀은 4명이지?' 그 의문에서 1인 기업을 택하는 분들이 늘고 있죠. 그게 (더) 합리적인 선택이라고 판단하니까요” 7. “이렇듯 점차 개인의 이름이 드러나는 사회로 가고 있어요. 그런 사회에서는 온전히 자신이 만든 것을 세상에 알리며 성과를 쌓아가는 사람에게 많은 이들이 열광하게 돼요. 내가 한 일이라면 그 결과가 나에게 온전히 귀속되는 사회, 새로운 공정 사회가 오고 있는 거죠” 8. “(바꿔 말하면, 무슨 전문가니, 컨설턴트니, 코치니 하는 온갖 직업명이나 수식어로 자기를 꾸미는 퍼스널 브랜딩의 시대는 끝났고, 그 사람이 무슨 일을 했고, 어떤 결과를 만들었는지를 중심으로, 그 개인의 시간과 능력을 사려는 분위기가 생기고 있다는 얘깁니다)” 9. “(그러니 온갖 미사여구를 동원해 자기 자신을 억지로 브랜딩하려고 하지 말고, 지금부터는 딱 깔끔하게 실력과 능력과 결과로, 자기 이름이 지닌 가치를 높이세요. 그렇게 자기 이름으로 업계에서 네임드가 되세요. 앞으로는 훨씬 더 중요할 겁니다)” - 송길영 박사

www.folin.co

일을 잘 해서 네임드가 되면, 퍼스널 브랜딩 따위는 1도 중요하지

긱뉴스를 처음 보기 시작했던 게 2019년이었던가. 서비스가 나오자마자 보기 시작했습니다. 서비스 자체보다는 서비스를 어떻게 운영하는지에 더 관심이 있었습니다.

긱뉴스에서 배운 것들

긱뉴스를 처음 보기 시작했던 게 2019년이었던가.
서비스가 나오자마자 보기 시작했습니다.
서비스 자체보다는 서비스를 어떻게 운영하는지에 더 관심이 있었습니다.

어려울 거라 생각했습니다.
운영자님 혼자만 글을 올리는 개발 뉴스 커뮤니티.
한국이라는 작은 시장.
과연 이게 될까?

뭔가를 꾸준히 한다는 게 참 쉽지가 않습니다.
아무리 쉬운 일이라도 빼먹지 않고 매일 한다는 것.
저는 번번이 실패했습니다.

매일 팔굽혀펴기 100개씩을 해보자, 더도 말고 딱 100개만.
한 달을 조금 넘기고 빵꾸를 냈습니다.
한 번 빵꾸를 내니 더 이상 지속되질 않았습니다.

이번엔 좀 더 쉬운 걸로 해보자.
인스타그램을 만들어서 사진을 하루에 하나씩 올려보는 거야.
여행 사진이든 음식 사진이든.
이건 진짜 쉬운 일 아닌가?
이것도 한 달을 넘기질 못했습니다.

긱뉴스를 보면서 감탄했던 건 운영자님 혼자서 매일 5개의 글을 올렸다는 것.
눈이 오나 비가 오나. 반응이 있건 없건.
그것도 무려 5년 동안이나.

1년간 총 2411개의 기술뉴스가 작성되었습니다. 그중에 제가 작성한 것은 1974개 입니다. 일년간 하루도 빠짐없이 뉴스를 올려서, 평균 5.4개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다.

긱뉴스 1주년 회고 중

지난 1년간총 2225개의 기술뉴스가 작성되어서 현재까지 총 뉴스는 4636개 입니다. 저는 오픈 후 2년간 하루도 빠짐없이 뉴스를 올려서, 총 3764개, 하루 평균 5.1개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다.

긱뉴스 2주년 회고 중

도저히 활성화되지 않을 것 같던 커뮤니티에..
3년 쯤 지나니 다른 사람들도 종종 글을 올리고 댓글들도 달리기 시작했습니다.
와, 이게 되긴 되는구나.
서비스는 이렇게 하는 거구나.

제가 매일 코딩하기를 하는 것.
커피한잔을 만들면서 포기하지 않고 버텨낸 것.
긱뉴스를 운영하는 모습을 보며 영향을 많이 받았습니다.

오늘 긱뉴스에 올라온 한 글에서…
수많은 댓글을 보고 이제 커뮤니티가 많이 커졌구나 느꼈습니다.
피곤할 만한 글에 대한 운영자님의 대응을 보면서 많이 배우기도 했습니다. 감탄했습니다.

한때는 RSS를 500여 개 등록해놓고 매일 아침 눈 떴을 때부터 자기 전까지 틈날 때마다 읽었습니다.
다 읽어야 한다는 부담을 가지고. 아주 고통스럽게.
이제 긱뉴스 덕분에 RSS는 잘 보지 않습니다.
긱뉴스만 읽어도 이전보다 좋은 소식을 더 많이 알게 되는 것 같습니다.
바로 운영자님이 바라던 그 모습 그대로.

정말 대단한 서비스입니다.
항상 응원하고 감사하게 생각합니다.

https://jeho.page/essay/2024/09/30/geek-news.html

긱뉴스를 처음 보기 시작했던 게 2019년이었던가.서비스가 나오자마자 보기 시작했습니다.서비스 자체보다는 서비스를 어떻게 운영하는지에 더 관심이 있었습니다. 어려울 거라 생각했습니다.운영자님 혼자만 글을 올리는 개발 뉴스 커뮤니티.한국이라는 작은 시장.과연 이게 될까? 뭔가를 꾸준히 한다는 게 참 쉽지가 않습니다.아무리 쉬운 일이라도 빼먹지 않고 매일 한다는 것.저는 번번이 실패했습니다. 매일 팔굽혀펴기 100개씩을 해보자, 더도 말고 딱 100개만.한 달을 조금 넘기고 빵꾸를 냈습니다.한 번 빵꾸를 내니 더 이상 지속되질 않았습니다. 이번엔 좀 더 쉬운 걸로 해보자.인스타그램을 만들어서 사진을 하루에 하나씩 올려보는 거야.여행 사진이든 음식 사진이든.이건 진짜 쉬운 일 아닌가?이것도 한 달을 넘기질 못했습니다. 긱뉴스를 보면서 감탄했던 건 운영자님 혼자서 매일 5개의 글을 올렸다는 것.눈이 오나 비가 오나. 반응이 있건 없건.그것도 무려 5년 동안이나. 1년간 총 2411개의 기술뉴스가 작성되었습니다. 그중에 제가 작성한 것은 1974개 입니다. 일년간 하루도 빠짐없이 뉴스를 올려서, 평균 5.4개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다. 긱뉴스 1주년 회고 중 지난 1년간총 2225개의 기술뉴스가 작성되어서 현재까지 총 뉴스는 4636개 입니다. 저는 오픈 후 2년간 하루도 빠짐없이 뉴스를 올려서, 총 3764개, 하루 평균 5.1개의 뉴스를 올렸네요. 지금도 가능하면 하루에 5개 이상은 뉴스를 엄선해서 올리려고 노력하고 있습니다. 긱뉴스 2주년 회고 중 도저히 활성화되지 않을 것 같던 커뮤니티에..3년 쯤 지나니 다른 사람들도 종종 글을 올리고 댓글들도 달리기 시작했습니다.와, 이게 되긴 되는구나.서비스는 이렇게 하는 거구나. 제가 매일 코딩하기를 하는 것.커피한잔을 만들면서 포기하지 않고 버텨낸 것.긱뉴스를 운영하는 모습을 보며 영향을 많이 받았습니다. 오늘 긱뉴스에 올라온 한 글에서…수많은 댓글을 보고 이제 커뮤니티가 많이 커졌구나 느꼈습니다.피곤할 만한 글에 대한 운영자님의 대응을 보면서 많이 배우기도 했습니다. 감탄했습니다. 한때는 RSS를 500여 개 등록해놓고 매일 아침 눈 떴을 때부터 자기 전까지 틈날 때마다 읽었습니다.다 읽어야 한다는 부담을 가지고. 아주 고통스럽게.이제 긱뉴스 덕분에 RSS는 잘 보지 않습니다.긱뉴스만 읽어도 이전보다 좋은 소식을 더 많이 알게 되는 것 같습니다.바로 운영자님이 바라던 그 모습 그대로. 정말 대단한 서비스입니다.항상 응원하고 감사하게 생각합니다. https://jeho.page/essay/2024/09/30/geek-news.html

K리그 프로그래머

CROLO: AI 배너 디자이너

💬이미지 광고 배너, 이제 AI가 만들어준다고?💬

#AI가 점점 더 고도화되면서 AI가 커버하는 영역이 점점 더 넓어지고 있다. 특히 뉴스 기사와 같은 텍스트 기반은 이미 굉장히 활성화되어 있지만 아직 이미지와 영상과 같은 비주얼 요소가 들어간 분야는 상대적으로 그렇지 못했다. 이번에 나온 CROLO라는 서비스는 원본 디자인 소스를 업로드하면 AI가 자동으로 최적의 조합을 찾아 이미지 배너를 제작해준다고 한다. 인력에 대한 부담이 없기 때문에 다양한 베리에이션을 하여 A/B테스트에 더 유리할 것이라는 서비스 측의 설명이다. 이제 알파 또는 베타 단계인 것으로 보여 대기자를 신청하고 있는데, 실제 배너 제작물의 퀄리티가 궁금하다.

CROLO

운영PM

ader

#고객경험 #운영기획 #CS최소화 #운영정책수립
안녕하세요! 9년차 CX 운영기획자 입니다.
최근 신사업 피엠으로 업무 중입니다 🤹🏻‍♂️

콘텐츠 기획/제작

ultramarine_b

서동환

퍼플라이언즈

심사위원

홍보 담당

Co-founder

IMC Manager

이사

Agency Solutions Lead

정보미디어 MBA

송재오

"Think big, Start small" 전략은 크게 실행은 빠르게를 지향하는 디지털 마케터이자 늘 새로운 광고를 고민하는 기획자.   브랜드와 대행사를 두루 거쳐 현재는 MCN에서 세상에 없던 광고 사업을 고민하고 있습니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필