(이 글은 제가 근무하고 있는 딜라이트룸 제품 블로그에도 동일하게 포스팅되었습니다.) 여러분의 DAU ...

알라미에서 DAU를 분석하는 방법

서비스 활동성 지표(DAU, MAU...)는 굉장히 중요하지만, 단순히 DAU 일별 트렌드를 본다고 해서 특별한 인사이트를 얻을 수 있는 건 아닙니다. 일별로 기록되는 DAU나 MAU는 여러 가지 요인들이 복합적으로 작용한 결과를 보여주는 전형적인 후행 지표이기 때문입니다. 현재 유저들의 사용 패턴을 깊이있게 분석하고 DAU를 높이기 위한 구체적인 아이디어를 검증하려면, 유저의 여러 상태값을 세세한 레벨로 쪼개서 살펴볼 수 있어야 합니다. Alarmy에서 어떤 프레임워크를 가지고 활동성 지표를 살펴보고 있는지 간단히 정리했습니다.

서비스 활동성 지표(DAU, MAU...)는 굉장히 중요하지만, 단순히 DAU 일별 트렌드를 본다고 해서 특별한 인사이트를 얻을 수 있는 건 아닙니다. 일별로 기록되는 DAU나 MAU는 여러 가지 요인들이 복합적으로 작용한 결과를 보여주는 전형적인 후행 지표이기 때문입니다. 현재 유저들의 사용 패턴을 깊이있게 분석하고 DAU를 높이기 위한 구체적인 아이디어를 검증하려면, 유저의 여러 상태값을 세세한 레벨로 쪼개서 살펴볼 수 있어야 합니다. Alarmy에서 어떤 프레임워크를 가지고 활동성 지표를 살펴보고 있는지 간단히 정리했습니다.

네이버 블로그 | 스타트업 다이어리

[알라미에서 DAU를 분석하는 방법]

요즘은 복지의 일환으로 매년마다 건강검진을 제공하는 회사들이 많은 것 같습니다. 개인적으로는 최애 복지 중 하나인데, 1년이라는 적당한 주기에 나이가 들면서 달라지는 나의 몸 상태를 객관적인 숫자의 지표들로 확인할 수 있어서 일종의 경각심을 느끼게 하면서 앞으로의 관리 방향을 고민하게 해주어서 고맙게 느껴집니다. (체지방률과 근육량은 해마다 안 좋아지는…

알라미는 건강검진을 얼마나 자주할까 (feat. 광고 지표)

딜라이트룸에서는 스쿼드마다 일정 주기로 지표 미팅을 가집니다. 핵심 지표를 정의하고, 해당 지표의 추이를 확인하고, 지표를 개선하기 위한 실험 결과를 함께 살펴보기도 합니다. 지표 모니터링이 중요하긴 하지만, 그렇다고 지나치게 자주 들여다보는 건 효용 측면에서 그렇게 좋은 선택은 아닙니다. 어느 정도의 주기로, 어떤 구조로 지표를 쪼개서 살펴봐야 효율적인 모니터링을 할 수 있을까요? 알라미에서 광고 데이터분석을 담당하는 Livio가 지표 모니터링에 대한 인사이트를 정리한 글이 있어서 공유합니다.

딜라이트룸에서는 스쿼드마다 일정 주기로 지표 미팅을 가집니다. 핵심 지표를 정의하고, 해당 지표의 추이를 확인하고, 지표를 개선하기 위한 실험 결과를 함께 살펴보기도 합니다. 지표 모니터링이 중요하긴 하지만, 그렇다고 지나치게 자주 들여다보는 건 효용 측면에서 그렇게 좋은 선택은 아닙니다. 어느 정도의 주기로, 어떤 구조로 지표를 쪼개서 살펴봐야 효율적인 모니터링을 할 수 있을까요? 알라미에서 광고 데이터분석을 담당하는 Livio가 지표 모니터링에 대한 인사이트를 정리한 글이 있어서 공유합니다.

Medium

[알라미는 건강검진을 얼마나 자주할까]

계란후라이 1042

조직을 떠나는 사람들을 위해서 해줄 수 있는 것은 무엇일까요? 어떤 것을 해주면 조직과 개인 간 서로에게 아름다운 이별이 되는 걸까요?
우리는 살면서 숱한 헤어짐을 경험합니다. 학교를 졸업하며 친구들과 이별하고, 이성친구와 싸우고 결별하기도 하고, 엄마는 아들을 군대나 유학 보내며 일정 기간 몸을 떠나보기도 합니다.
직장인에게 가장 빈번한 이별 장면은 동료의 퇴사사입니다. 정들었던 동료를 떠나보내는 것은 떠나는 이유에 관계없이 아쉽고 슬픈 일입니다. 그래도 만남이 있으면 헤어짐도 있는 법, 아쉬움을 뒤로하고 남는 자나 떠나는 자 모두 각자의 자리에서 다음 미션을 향해 나아갑니다.
헤어지는 작별의 순간 손 흔들며 인사하는 것 외에 남는 사람이 떠나는 자를 위해 해줄 수 있는 것이 있다면 좋겠다는 생각이 들었습니다.

조직에 새로운 구성원을 맞아 환영하고. 낯선 새로운 환경에 적응하는 것을 돕는 역할이 온보딩이라면, 조직을 떠나는 구성원이 다음 기회의 장소에서 더 멋진 여정을 경험하도록 이전 조직 생활의 순탄한 마무리를 돕는 역할을 오프보딩이라고 합니다.
조직을 나가는 사람을 위해 무엇을 해줘야 한다고? 냉철한 이성을 가진 분들에게 쉽게 이해가 되지 않을 수도 있으니 오프보딩의 전략적 성과를 설명해 보겠습니다.
조직을 떠나는 결정을 내리는 구성원이 느낀 조직에 대한 아쉬움이 있을 것입니다. 떠나는 구성원이 느끼는 그 아쉬움을 조직이 채워주지 못했음을 사과해야 합니다. 아쉬움이 해소되지 않고 쌓이면 미움과 분노가 되기 때문입니다.
아쉬움을 만든 요인은 물리적인 조건일 수도 있지만, 조건을 얻지 못한 아쉬움은 사람이 느낀 감정입니다. 그러니 아쉬운 감정을 털고 나갈 수 있도록 돕는 것이죠. 미안하고 고마웠다는 표현으로 충분합니다. 그럼 사과를 받은 떠나는 사람이 남는 사람들을 위해 진심으로 응원할 것이라고 믿습니다.

그다음으로 조직을 떠나는 사람에게 해줄 수 있는 것은 진심으로 함께 다음 여정을 고민해 주는 것입니다. 아마도 다음 여정에 대한 고민이 끝난 상태로 이전 조직을 나가는 것일 수도 있고, 아닐 수도 있습니다. 중요한 건 함께 다음 여정을 진심으로 고민해 줬는지입니다.
우리는 너무 이직을 조심스럽게 조용히 진행하는 경향이 있습니다. 그러니까 동료에게 이직한다고 이야기했을 때 화들짝 놀라는 경우가 많은 것입니다. 이직을 고민하는 순간부터 동료와 생각을 교류할 수 있어야 한다고 생각해요. 그것이 정말 건강한 커리어 여정을 만드는 방법입니다. 커리어 여정을 혼자 고민하는 것보다 여러 사람이 함께 힘을 보태는 것이 더 건강한 의사결정을 할 수 있기 때문입니다. 그리고 퇴직에 대한 고민을 현재 조직에 알려서 보완이 필요한 부분이 있다면 조속히 대응할 수 있도록 정보를 주는 차원으로도 좋습니다. 만약 당장 아쉬운 부분이 보완될 수 있다면 굳이 이직을 하지 않는 선택도 가능하죠.
경력 개발은 직장인 누구에게나 평생의 화두입니다. 너나 나나, 팀장이나 구성원 모두가 염려하고 걱정하는 내용입니다. 그렇다면 더 이상 음지에서 다른 사람 몰래 혼자 전전긍긍하도록 방치하지 말고, 공개적으로 커리어 여정을 설계하는 것을 돕는 장치가 필요하다고 생각합니다.

대한민국 직장인 네트워크는 생각보다 상당히 좁습니다. 언제 어디서 만날지 모르는 오늘의 동료를 소중히 여깁시다. 꼭 그런 것이 아니더라도 대단한 인연으로 소중한 동료를 위해 진심으로 돕는 일이 무엇인지 고민해 보는 하루가 되길 진심으로 응원합니다.

계란후라이 1042 조직을 떠나는 사람들을 위해서 해줄 수 있는 것은 무엇일까요? 어떤 것을 해주면 조직과 개인 간 서로에게 아름다운 이별이 되는 걸까요?우리는 살면서 숱한 헤어짐을 경험합니다. 학교를 졸업하며 친구들과 이별하고, 이성친구와 싸우고 결별하기도 하고, 엄마는 아들을 군대나 유학 보내며 일정 기간 몸을 떠나보기도 합니다.직장인에게 가장 빈번한 이별 장면은 동료의 퇴사사입니다. 정들었던 동료를 떠나보내는 것은 떠나는 이유에 관계없이 아쉽고 슬픈 일입니다. 그래도 만남이 있으면 헤어짐도 있는 법, 아쉬움을 뒤로하고 남는 자나 떠나는 자 모두 각자의 자리에서 다음 미션을 향해 나아갑니다.헤어지는 작별의 순간 손 흔들며 인사하는 것 외에 남는 사람이 떠나는 자를 위해 해줄 수 있는 것이 있다면 좋겠다는 생각이 들었습니다.​조직에 새로운 구성원을 맞아 환영하고. 낯선 새로운 환경에 적응하는 것을 돕는 역할이 온보딩이라면, 조직을 떠나는 구성원이 다음 기회의 장소에서 더 멋진 여정을 경험하도록 이전 조직 생활의 순탄한 마무리를 돕는 역할을 오프보딩이라고 합니다.조직을 나가는 사람을 위해 무엇을 해줘야 한다고? 냉철한 이성을 가진 분들에게 쉽게 이해가 되지 않을 수도 있으니 오프보딩의 전략적 성과를 설명해 보겠습니다.조직을 떠나는 결정을 내리는 구성원이 느낀 조직에 대한 아쉬움이 있을 것입니다. 떠나는 구성원이 느끼는 그 아쉬움을 조직이 채워주지 못했음을 사과해야 합니다. 아쉬움이 해소되지 않고 쌓이면 미움과 분노가 되기 때문입니다.아쉬움을 만든 요인은 물리적인 조건일 수도 있지만, 조건을 얻지 못한 아쉬움은 사람이 느낀 감정입니다. 그러니 아쉬운 감정을 털고 나갈 수 있도록 돕는 것이죠. 미안하고 고마웠다는 표현으로 충분합니다. 그럼 사과를 받은 떠나는 사람이 남는 사람들을 위해 진심으로 응원할 것이라고 믿습니다.​그다음으로 조직을 떠나는 사람에게 해줄 수 있는 것은 진심으로 함께 다음 여정을 고민해 주는 것입니다. 아마도 다음 여정에 대한 고민이 끝난 상태로 이전 조직을 나가는 것일 수도 있고, 아닐 수도 있습니다. 중요한 건 함께 다음 여정을 진심으로 고민해 줬는지입니다.우리는 너무 이직을 조심스럽게 조용히 진행하는 경향이 있습니다. 그러니까 동료에게 이직한다고 이야기했을 때 화들짝 놀라는 경우가 많은 것입니다. 이직을 고민하는 순간부터 동료와 생각을 교류할 수 있어야 한다고 생각해요. 그것이 정말 건강한 커리어 여정을 만드는 방법입니다. 커리어 여정을 혼자 고민하는 것보다 여러 사람이 함께 힘을 보태는 것이 더 건강한 의사결정을 할 수 있기 때문입니다. 그리고 퇴직에 대한 고민을 현재 조직에 알려서 보완이 필요한 부분이 있다면 조속히 대응할 수 있도록 정보를 주는 차원으로도 좋습니다. 만약 당장 아쉬운 부분이 보완될 수 있다면 굳이 이직을 하지 않는 선택도 가능하죠.경력 개발은 직장인 누구에게나 평생의 화두입니다. 너나 나나, 팀장이나 구성원 모두가 염려하고 걱정하는 내용입니다. 그렇다면 더 이상 음지에서 다른 사람 몰래 혼자 전전긍긍하도록 방치하지 말고, 공개적으로 커리어 여정을 설계하는 것을 돕는 장치가 필요하다고 생각합니다.​대한민국 직장인 네트워크는 생각보다 상당히 좁습니다. 언제 어디서 만날지 모르는 오늘의 동료를 소중히 여깁시다. 꼭 그런 것이 아니더라도 대단한 인연으로 소중한 동료를 위해 진심으로 돕는 일이 무엇인지 고민해 보는 하루가 되길 진심으로 응원합니다.

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

너무 좋은 말이지만, 이직 생각있다고 말하는 순간 우리 나라 사회가 그걸 부정적으로만 바라보는 시선이 있어 숨길 수 밖에 없게 만드네요 ㅠㅠ

HR, 데이터 분석가, 프로덕트 디자이너, 사업본부장이 말하는 좋은 포트폴리오!

실무자의 눈을 사로잡는 포트폴리오를 위한 5가지 비밀 재료

HR, 데이터 분석가, 프로덕트 디자이너, 사업본부장이 말하는 좋은 포트폴리오!

다섯 가지 공통 질문을 바탕으로한 포트폴리토 제작 팁을 확인해보세요!
 * 포트폴리오에서 가장 중요하게 생각해봐야 할 요소는 무엇인가요?
 * 포트폴리오 프로젝트 내용을 볼때 어떤 내용을 가장 중요하게 보시나요?
 * 포트폴리오에서 지원자의 성장 가능성을 어떻게, 효과적으로 보여줄 수 있을까요?
 * 포트폴리오에서 가장 인상 깊었던 요소나 접근 방식 중 기억에 남는 건 무엇인가요?
 * 포트폴리오에서 흔히 볼 수 있는 실수와 이를 개선할 방법은 무엇인가요?

HR, 데이터 분석가, 프로덕트 디자이너, 사업본부장이 말하는 좋은 포트폴리오! 다섯 가지 공통 질문을 바탕으로한 포트폴리토 제작 팁을 확인해보세요!<ul ><li>포트폴리오에서 가장 중요하게 생각해봐야 할 요소는 무엇인가요?</li><li>포트폴리오 프로젝트 내용을 볼때 어떤 내용을 가장 중요하게 보시나요?</li><li>포트폴리오에서 지원자의 성장 가능성을 어떻게, 효과적으로 보여줄 수 있을까요?</li><li>포트폴리오에서 가장 인상 깊었던 요소나 접근 방식 중 기억에 남는 건 무엇인가요?</li><li>포트폴리오에서 흔히 볼 수 있는 실수와 이를 개선할 방법은 무엇인가요?</li></ul>

PRODUCT LAB. 프로덕트랩

토스뱅크는 지난 9일 첫 번째 테크밋업인 '테크닉(Tech.nic)'을 개최해 100여 명의 금융권 IT 개발자와 혁신 기술 노하우를 나누는 시간을 가졌다고 12일 밝혔다.토스뱅크는 "테크닉은 Tech(기술)와 Picnic(소풍)을 합친 용어로 소풍처럼 즐거운 마음으로 참여해 금융 혁신 기술에 대한 경험과 지식을 나누는 자리라는 의미"라고 설명했다.이날 행사는 서울 강남구 테헤란로의 토스뱅크 사옥에서 열렸으며, 금융권 및 IT 개발자 100여 명과 함께

토스뱅크, 첫 테크밋업 '테크닉' 열어...개발자 100명과 혁신 노하우 공유

지난 8/9에 기술로 금융권 IT의 혁신을 이끌고 있는 토스뱅크가 첫 테크밋업인 'Tech.nic'을 진행했습니다!

토스뱅크 테크밋업에서 발표한 내용이 궁금하시다면 토스 테크 블로그에서 토스뱅크 동료들의 글을 확인해주세요!

토스 테크 블로그 >> https://toss.tech/
토스뱅크 채용 >> https://toss.im/career/tossbank

지난 8/9에 기술로 금융권 IT의 혁신을 이끌고 있는 토스뱅크가 첫 테크밋업인 'Tech.nic'을 진행했습니다! 토스뱅크 테크밋업에서 발표한 내용이 궁금하시다면 토스 테크 블로그에서 토스뱅크 동료들의 글을 확인해주세요! 토스 테크 블로그 &gt;&gt; https://toss.tech/토스뱅크 채용 &gt;&gt; https://toss.im/career/tossbank

이코노믹리뷰

토스뱅크 첫 테크밋업, ‘Tech.nic’

01 . 프리드리히 니체가 쓴 ⟪선악의 저편⟫에는 이런 말이 나옵니다.
'괴물과 싸우는 사람은 스스로 괴물이 되지 않도록 주의해야 한다. 우리가 괴물의 심연을 오랫동안 들여다보면, 심연 또한 우리를 들여다보기 때문이다.'
부당한 것들에 저항하는 행위 자체는 매우 중요하고 용감한 것이지만 그 대상을 다룰 때는 오히려 부당한 방법을 사용하지 않도록 주의해야 한다는 말입니다. '저들이 저토록 나쁜데 어떻게 좋게 해결할 수 있나?'라는 생각에 심취하면 나 역시 그들과 다르지 않은 괴물이 되어간단 거죠.

02 . 사회를 나와보면 좋은 사람만큼 나쁜 사람도 많다는 걸 절실히 체감하게 됩니다. 솔직히 말하면 적당히 좋고, 적당히 나쁜 중간인 사람을 찾는 게 현실적으론 더 어려운 일인지도 모르죠. 지금 여러분들께서 떠올릴 수 있는 주위 사람들만 봐도 '좋은 사람' 혹은 '그렇지 않은 사람'의 범주에 바로 포함시킬 수 있는 인물들이 많을 테니까요, 지극히 개인적인 잣대고 그들의 속 사정을 하나하나 헤아리지 못하는 데서 오는 오류라고 하더라도 사회생활을 함에 있어 인간관계에 대한 가치관을 가지고 산다는 건 사실 꽤나 중요한 문제입니다.

03 . 마냥 짧지도, 마냥 길지도 않은 정도의 사회생활을 해오며 배운 것 중 하나는 나쁜 사람들은 혼자 활동하지 않는다는 사실이었습니다. 그들은 늘 자신의 행동을 합리화하는 데 바빴고, 합리화의 과정이 끝나면 누군가로부터 동의나 공감을 얻어내는 데 주력했기 때문이죠. 쉽게 말해 '내가 하는 이 언행들은 합당한 목표나 이유가 있는 것이고, 여기에 뜻을 같이 해주는 사람도 적지 않다'는 사실을 은연중에 공표하는 것이었습니다.
때문에 전혀 우발적이지도, 감정적이지도 않으며 오히려 나쁜 것들을 행해 끝없는 빌드업(?) 하는 부류의 사람들에 가까웠죠. 심지어는 나쁜 행위가 끝나고 나면 그 행위에 동참한 사람들이 죄책감을 갖지 않도록 케어해주는 행위까지 잊지 않았으니까요.

04 . 안타깝지만 이런 과정에 동원되는 사람들은 소위 말에 늘 '만만한 사람들'이었습니다.
니체가 말한 것처럼 괴물과 부딪히는 사람들은 크게 두 가지 부류의 사람들이 많습니다. 하나는 같이 괴물이 되어 진흙탕 싸움을 벌이는 종족이고, 다른 하나는 끝까지 본인의 선함을 놓지 않고 정공법을 택하는 사람들이죠. 그러니 악한 사람들의 입장에선 이 두 부류 모두 달가울 수 없습니다. 자기와 전혀 다른 사람과의 싸움도, 자기와 똑같이 나쁜 길을 택한 사람과의 싸움도 버거운 것은 매한가지거든요.

05 . 때문에 제 주위 경험에 비춰봐도 나쁜 사람은 늘 만만한 사람부터 골랐습니다. 옳고 그름에 대한 기준이 선명하지 않은 사람들, 어느 한쪽으로 치우치지는 않지만 타이밍에 따라서 쉽게 양쪽을 오갈 수 있는 사람들, 나쁜 것도 금방 잊고 좋은 것도 금방 잊는 사람들, 누군가의 설득에 쉽게 감화되고 타인의 사정에 극한 공감을 일으키는 사람들이 대부분 그런 유형의 사람들이었습니다. 물론 인간 군상을 일반화한다는 게 애초에 불가능한 일이지만, 적어도 이런 글로 내 생각을 표현할 땐 또 그에 맞는 표현법들이 있는 것이니까요, 제 경험에 기대어 제 기준으로 분류해낸 것임을 감안하고 들어주시면 좋겠습니다.

06 . 그래서 회사 생활을 오래 같이한 동료들 중 일부는 가끔 이런 말을 하기도 합니다. '나는 그때 그 사람이 그렇게까지 나쁜 사람인지도 몰랐고, 우리에게 시킨 지시들이 그렇게까지 나쁜 일인지도 몰랐다'고 말입니다. 이 역시 각자의 가치관을 가늠좌로 놓고 해결해야 할 문제지만 적어도 '뒤돌아보니 나쁜 사람의, 나쁜 지시였던 것 같다'는 걸 인정하는 걸 보면 모두가 느끼는 것을 뒤늦게 깨닫는 사람들도 적지 않았음이 분명합니다. 그리고 그 사람들은 대부분 나쁜 사람이 하는 나쁜 일에 일정 부분이라도 동원된 사람들이었거나 동의 혹은 공감을 해준 사람들이었죠.

07 . 물론 그런 만만한 사람들이 모두 어리석은 것은 아니니 스스로 빠져나올 힘 역시 갖추고 있겠지만 제가 안타까웠던 부분은 누군가는 그런 일로 인해 악하지 않은 사람마저도 나쁜 사람으로 규정하고 기억한다는 사실이었습니다. 가끔은 그 사이에 저와 친한 사람도 끼어있어서 나름의 해명을 해주려고 해도 '애초에 그런 사람의 부당한 지시를 따랐다는 것에서 본인 책임도 있는 것 아닌가요?'라는 반문을 들을 때면 정신이 번쩍 들더라고요. '아, 내가 지금 하는 행동이 오히려 그 사람에게도, 이 사람에게도 더 해가 될 수 있겠구나' 싶었던 겁니다.

08 . 하지만 슬프게도 만만한 사람으로 여겨지는 사람 중에 스스로를 '만만한 사람'으로 생각하는 이는 단 한 명도 없습니다. 그럼에도 불구하고 나쁜 사람이 만만한 사람을 선택하는 과정을 지켜보고 있노라면 왜 그 사람을 선택하는지가 뻔히 보이곤 하죠. 자신의 목표를 감화시키는데도 유리하고, 때론 자신의 의견에 힘을 실어주는 역할도 마다하지 않으며, 무엇보다 자기 손으로 직접 뭔가를 하지 않아도 그 사람을 통해 목적을 달성할 수 있기 때문입니다. 그러니 결코 가볍게 여길 문제는 아닌 거죠.

09 . '만만하다'란 말은 우리말 중에서도 정확한 어원을 찾기 어려운 말 중 하나입니다. 유력한 설은 '찰 만(滿)'자 두 개 이어 붙여서 '이 정도면 적당히 찼고, 부족함이 없는 상태다'를 뜻하는 말이 형용사로 굳어지며 '다루기 쉽고, 접근하기 쉬운 상태 혹은 그런 사람'으로 확대되었다는 가정입니다. 물건이야 이 만만한 상태가 쓸모를 가질지 모르지만 사실 사람에게 있어서는 절대 좋은 평판일 수 없습니다. 무엇보다 이 길을 자의로 택하는 사람이 있을 리 없으니까요.
그렇다고 오늘의 결론이 '모든 아젠다에 있어서 선악 중 하나를 택하라'고 귀결될 수는 없을 겁니다. 우리 삶에 이토록 다양한 문제들을 모조리 심판대에 올린다는 것 역시 불가능한 일이고요.

10 . 하지만 나쁜 사람이 나쁜 일을 할 때 나를 선택한다는 사실을 인지하지 못한다면 이는 자신의 역량도, 인품도, 평판도 모조리 깎아먹는 행위가 됩니다. '끼리끼리는 공학'이라는 가벼운 말로 대체하고 싶은 생각은 없지만 때로는 '나쁜 사람을 걸러내는 능력이 없는 것만으로도 나쁘다'는 평가가 존재하는 만큼 이는 반드시 확보해야 할 능력치 중 하나이기도 하죠.
조금 씁쓸한 이야기들을 풀어놓았지만 한 달의 마지막이 저무는 시점에서 또 한 번 저 스스로를 바로잡게 되는 말인 것 같기도 합니다. 나쁜 사람들의 달콤한 말에 무너질 정도로 어리석은 행동을 한 적은 없는지, 그게 나쁜 행동임을 알면서도 좋은 사람 컴플렉스를 버리고 싶지 않아 거절을 미룬 적은 없는지 일단 저 자신에게 먼저 물어봐야 할 지점이 존재하는 것이니 말이죠.

01 . 프리드리히 니체가 쓴 ⟪선악의 저편⟫에는 이런 말이 나옵니다. '괴물과 싸우는 사람은 스스로 괴물이 되지 않도록 주의해야 한다. 우리가 괴물의 심연을 오랫동안 들여다보면, 심연 또한 우리를 들여다보기 때문이다.'부당한 것들에 저항하는 행위 자체는 매우 중요하고 용감한 것이지만 그 대상을 다룰 때는 오히려 부당한 방법을 사용하지 않도록 주의해야 한다는 말입니다. '저들이 저토록 나쁜데 어떻게 좋게 해결할 수 있나?'라는 생각에 심취하면 나 역시 그들과 다르지 않은 괴물이 되어간단 거죠. 02 . 사회를 나와보면 좋은 사람만큼 나쁜 사람도 많다는 걸 절실히 체감하게 됩니다. 솔직히 말하면 적당히 좋고, 적당히 나쁜 중간인 사람을 찾는 게 현실적으론 더 어려운 일인지도 모르죠. 지금 여러분들께서 떠올릴 수 있는 주위 사람들만 봐도 '좋은 사람' 혹은 '그렇지 않은 사람'의 범주에 바로 포함시킬 수 있는 인물들이 많을 테니까요, 지극히 개인적인 잣대고 그들의 속 사정을 하나하나 헤아리지 못하는 데서 오는 오류라고 하더라도 사회생활을 함에 있어 인간관계에 대한 가치관을 가지고 산다는 건 사실 꽤나 중요한 문제입니다. 03 . 마냥 짧지도, 마냥 길지도 않은 정도의 사회생활을 해오며 배운 것 중 하나는 나쁜 사람들은 혼자 활동하지 않는다는 사실이었습니다. 그들은 늘 자신의 행동을 합리화하는 데 바빴고, 합리화의 과정이 끝나면 누군가로부터 동의나 공감을 얻어내는 데 주력했기 때문이죠. 쉽게 말해 '내가 하는 이 언행들은 합당한 목표나 이유가 있는 것이고, 여기에 뜻을 같이 해주는 사람도 적지 않다'는 사실을 은연중에 공표하는 것이었습니다. 때문에 전혀 우발적이지도, 감정적이지도 않으며 오히려 나쁜 것들을 행해 끝없는 빌드업(?) 하는 부류의 사람들에 가까웠죠. 심지어는 나쁜 행위가 끝나고 나면 그 행위에 동참한 사람들이 죄책감을 갖지 않도록 케어해주는 행위까지 잊지 않았으니까요. 04 . 안타깝지만 이런 과정에 동원되는 사람들은 소위 말에 늘 '만만한 사람들'이었습니다. 니체가 말한 것처럼 괴물과 부딪히는 사람들은 크게 두 가지 부류의 사람들이 많습니다. 하나는 같이 괴물이 되어 진흙탕 싸움을 벌이는 종족이고, 다른 하나는 끝까지 본인의 선함을 놓지 않고 정공법을 택하는 사람들이죠. 그러니 악한 사람들의 입장에선 이 두 부류 모두 달가울 수 없습니다. 자기와 전혀 다른 사람과의 싸움도, 자기와 똑같이 나쁜 길을 택한 사람과의 싸움도 버거운 것은 매한가지거든요. 05 . 때문에 제 주위 경험에 비춰봐도 나쁜 사람은 늘 만만한 사람부터 골랐습니다. 옳고 그름에 대한 기준이 선명하지 않은 사람들, 어느 한쪽으로 치우치지는 않지만 타이밍에 따라서 쉽게 양쪽을 오갈 수 있는 사람들, 나쁜 것도 금방 잊고 좋은 것도 금방 잊는 사람들, 누군가의 설득에 쉽게 감화되고 타인의 사정에 극한 공감을 일으키는 사람들이 대부분 그런 유형의 사람들이었습니다. 물론 인간 군상을 일반화한다는 게 애초에 불가능한 일이지만, 적어도 이런 글로 내 생각을 표현할 땐 또 그에 맞는 표현법들이 있는 것이니까요, 제 경험에 기대어 제 기준으로 분류해낸 것임을 감안하고 들어주시면 좋겠습니다. 06 . 그래서 회사 생활을 오래 같이한 동료들 중 일부는 가끔 이런 말을 하기도 합니다. '나는 그때 그 사람이 그렇게까지 나쁜 사람인지도 몰랐고, 우리에게 시킨 지시들이 그렇게까지 나쁜 일인지도 몰랐다'고 말입니다. 이 역시 각자의 가치관을 가늠좌로 놓고 해결해야 할 문제지만 적어도 '뒤돌아보니 나쁜 사람의, 나쁜 지시였던 것 같다'는 걸 인정하는 걸 보면 모두가 느끼는 것을 뒤늦게 깨닫는 사람들도 적지 않았음이 분명합니다. 그리고 그 사람들은 대부분 나쁜 사람이 하는 나쁜 일에 일정 부분이라도 동원된 사람들이었거나 동의 혹은 공감을 해준 사람들이었죠. 07 . 물론 그런 만만한 사람들이 모두 어리석은 것은 아니니 스스로 빠져나올 힘 역시 갖추고 있겠지만 제가 안타까웠던 부분은 누군가는 그런 일로 인해 악하지 않은 사람마저도 나쁜 사람으로 규정하고 기억한다는 사실이었습니다. 가끔은 그 사이에 저와 친한 사람도 끼어있어서 나름의 해명을 해주려고 해도 '애초에 그런 사람의 부당한 지시를 따랐다는 것에서 본인 책임도 있는 것 아닌가요?'라는 반문을 들을 때면 정신이 번쩍 들더라고요. '아, 내가 지금 하는 행동이 오히려 그 사람에게도, 이 사람에게도 더 해가 될 수 있겠구나' 싶었던 겁니다. 08 . 하지만 슬프게도 만만한 사람으로 여겨지는 사람 중에 스스로를 '만만한 사람'으로 생각하는 이는 단 한 명도 없습니다. 그럼에도 불구하고 나쁜 사람이 만만한 사람을 선택하는 과정을 지켜보고 있노라면 왜 그 사람을 선택하는지가 뻔히 보이곤 하죠. 자신의 목표를 감화시키는데도 유리하고, 때론 자신의 의견에 힘을 실어주는 역할도 마다하지 않으며, 무엇보다 자기 손으로 직접 뭔가를 하지 않아도 그 사람을 통해 목적을 달성할 수 있기 때문입니다. 그러니 결코 가볍게 여길 문제는 아닌 거죠. 09 . '만만하다'란 말은 우리말 중에서도 정확한 어원을 찾기 어려운 말 중 하나입니다. 유력한 설은 '찰 만(滿)'자 두 개 이어 붙여서 '이 정도면 적당히 찼고, 부족함이 없는 상태다'를 뜻하는 말이 형용사로 굳어지며 '다루기 쉽고, 접근하기 쉬운 상태 혹은 그런 사람'으로 확대되었다는 가정입니다. 물건이야 이 만만한 상태가 쓸모를 가질지 모르지만 사실 사람에게 있어서는 절대 좋은 평판일 수 없습니다. 무엇보다 이 길을 자의로 택하는 사람이 있을 리 없으니까요. 그렇다고 오늘의 결론이 '모든 아젠다에 있어서 선악 중 하나를 택하라'고 귀결될 수는 없을 겁니다. 우리 삶에 이토록 다양한 문제들을 모조리 심판대에 올린다는 것 역시 불가능한 일이고요. 10 . 하지만 나쁜 사람이 나쁜 일을 할 때 나를 선택한다는 사실을 인지하지 못한다면 이는 자신의 역량도, 인품도, 평판도 모조리 깎아먹는 행위가 됩니다. '끼리끼리는 공학'이라는 가벼운 말로 대체하고 싶은 생각은 없지만 때로는 '나쁜 사람을 걸러내는 능력이 없는 것만으로도 나쁘다'는 평가가 존재하는 만큼 이는 반드시 확보해야 할 능력치 중 하나이기도 하죠. 조금 씁쓸한 이야기들을 풀어놓았지만 한 달의 마지막이 저무는 시점에서 또 한 번 저 스스로를 바로잡게 되는 말인 것 같기도 합니다. 나쁜 사람들의 달콤한 말에 무너질 정도로 어리석은 행동을 한 적은 없는지, 그게 나쁜 행동임을 알면서도 좋은 사람 컴플렉스를 버리고 싶지 않아 거절을 미룬 적은 없는지 일단 저 자신에게 먼저 물어봐야 할 지점이 존재하는 것이니 말이죠.

나쁜 사람은 만만한 사람부터 고르니까

디자인 취업 고민을 위한 자리에 하루동안
제 예상보다 많은 분들이 등록해 주셨습니다.

구글 폼으로 미리 공유해 주신 어려움들에
공감이 많이 갔습니다.

진심으로 감사하고 남은 시간 잘 준비해 보겠습니다.

디자인 취업 고민을 위한 자리에 하루동안 제 예상보다 많은 분들이 등록해 주셨습니다. 구글 폼으로 미리 공유해 주신 어려움들에공감이 많이 갔습니다. 진심으로 감사하고 남은 시간 잘 준비해 보겠습니다.

디자이너 취업 고민 웨비나

제품 개발은 크게 발견(product discovery)와 배포(delievery)로 구분된다. 다시 설명하면 제품팀이 잘 모르는 영역을 알아가는 과정과 이를 바탕으로 디자인, 엔지니어링을 통해 제품에 가치를 증분하는 작업 과정으로 구성된다.

많은 팀들이 경우 제품 발견(product discovery)을 생략하고 바로 기능을 개발하는 단계로 건너 뛰는 경우가 많다. 이렇게 제품을 만들면 3-4명의 제품팀 멤버(PM, 엔지니어, 디자이너)가 최소 2-3주 개발을 진행하게 된다. 

그렇게 배포된 기능은 대부분 성과가 바로 나타나지 않기 때문에 후속 개선 작업을 진행한다. 문제는 이 개선 작업이 프로젝트 시작부터 애초에 근거(evidence)가 빈약한 상태였기 때문에 계속해서 잘못된 최적화를 시도하게 된다. 그러면 이렇게 추가로 1-2주 더 시간이 지나간다. 여기서 제품 발견을 중요하게 생각하지 않는 조직이 좋아하는 단어 '리소스' 기준으로 계산하면 멤버 1명당 연봉이 7천만원이라고 가정하면 최소 3명 기준으로 2000만원의 비용이 소요되는 것이다. 단순한 인건비 손해 외 팀 전체적으로 단순히 기능 구현에 집중했기 때문에 팀이 모르고 있는 영역(unknown)에 대해 팀의 학습과 이해도를 높일 수 있는 기회를 잃게 된다.

어떻게 하면 빠르게 모르는 것(unknown)을 파악할 수 있을까? 내가 자주 활용했던 방법은 바로 제품을 만들지 않고, 상품 소개서를 기반으로 바로 고객 및 시장의 이해관계자를 만나는 것이다.
 
과거 카카오스타일에서 포스티(Posty)라는 신규 사업을 담당할 때 상품 소개서를 빠르게 제작하여 브랜드 패션 기업을 컨택했다. 아직 제품이 만들어지지 않은 상태였기 때문에 포스티가 풀려고 했던 문제점과 비전을 중심으로 상품 소개서를 제작했다. 상품 소개서가 구체적이지 않았지만, 당시 팀이 브랜드 패션 시장에 대한 이해도가 높지 않은 상태였기 때문에 빠르게 시장의 이해관계자를 만나서 니즈를 파악하는 것이 중요하다고 생각하여 바로 컨택을 진행했다.
당시에 우리 팀은 브랜드 패션에 있어 핵심 이해관계자가 벤더사(온라인 판매 대행사)일 것이라고 가정했다. 주요 브랜드 패션 커머스 플랫폼에서 상세 페이지 정보를 확인하면 주요 연락처에 스탁컴퍼니, 웹뜰과 같은 벤더사 정보가 있어서, 브랜드 패션에 있어 벤더사를 공략하면 패션 브랜드 입점 세일즈가 효율적일 것이라고 생각했다. 

하지만 몇 번의 미팅을 진행하니 우리의 가정이 틀렸다는 것을 파악했다. 다른 온라인 비즈니스(예: 광고)의 대행사와 달리 패션 커머스 시장에서 벤더가 가진 권한이 크지는 않았다. 커머스 플랫폼 입점은 벤더가 단독으로 진행할 수 없고, 패션 브랜드사의 승인을 받아야 진행이 가능했다. 주요 벤더사를 통해 우리 플랫폼 영업이 빠르게 확장하길 바랐던 바람은 그저 행복한 상상일 뿐이었다. 또 한편으로는 잘못된 가정으로 제품 개발을 시작했다면 1개의 벤더사가 여러 브랜드를 대행하여 관리하는 영역에 대해서 잘못된 엔지니어링 요구사항을 정의할 수도 있었다. 다행히 빠른 검증을 통해 잘못된 문제 정의를 하지 않게 되어서 마음의 안심을 얻기도 했다.
상품 소개서를 통해 계속 브랜드사 미팅을 진행하면서 피드백 기반으로 계속 상품 소개서의 콘텐츠를 업데이트하였고, 또한 제품 개발 관련해서 여러 근거들을 확보할 수 있었다. 팀이 이 과정을 통해 얻게 된 인사이트는 아래와 같다.

1. 패션브랜드 기업 내부의 중요한 조직간 이해관계가 존재한다. 오프라인 채널과 온라인 채널을 관리하는 조직이 분리되어 있으며, 주요 재고는 오프라인 매장 중심으로 우선순위 높게 유통이 된다. 만일 온라인 판매 가격이 오프라인 판매가 보다 낮은 경우 두 조직간의 이해관계 충돌이 발생한다. 이에 대한 대안으로 우회적으로 네이버 지식쇼핑에 가격이 노출되지 않는 온라인 판매 방식을 활용하거나 기업 내부적으로 합의를 통해 기획전이란 형태로 프로모션을 진행한다. 하지만 이 경우에도 조직간의 긴장감이 존재한다. 이밖에 오프라인 조직은 신상을 판매하고, 온라인 조직은 이월상품 중심으로 판촉 활동을 진행하는 경우도 존재했다. 따라서 패션 브랜드 온라인 MD 담당자가 오프라인 조직로부터 챌린지를 최소화할 수 있는 상품 노출/유통 구조가 필요했다.

2. 온라인 채널을 관리하는 MD 인력 대비 관리하는 플랫폼이 많다. 기본적으로 패션브랜드는 전통적인 리테일 비즈니스의 자산을 가지고 있다. 영업이익이 전반적으로 높지 않은 상황에서 이커머스 조직에 대한 투자를 적극적으로 하기 힘든 상황이다. 따라서 적은 수의 MD 멤버가 여러 온라인 채널(예: 하프클럽, 패션플러스 등)을 관리해야 한다. 여러 온라인 채널에 상품 정보(상품명, 옵션, 가격정보 등)와 주문 정보를 동시에 관리해야한다. 이를 위해서 브랜드 패션 MD는 셀링툴(예: EC모니터, 사방넷, 플레이오토, 샵링커)이란 솔루션을 통해 단일한 인터페이스로 온라인 채널의 상품, 주문 정보를 관리하고 있다. 사실 우리팀은 셀링툴이란 존재도 모르고 있던 상황이어서 빠르게 관련해서 상품정보 연동하는 API를 개발하고, 셀링툴 업체와 빠르게 계약을 맺어서 연동 개발을 진행했다. 외부 업체와 빠르게 계약하고 연동하는 과정은 사실 쉽지 않은데, 작업 중간에 다행히 상품 정보를 관리하는 유관부서가 지원을 해주어 적절한 시점에 필요한 bottleneck을 해결할 수 있었다. 이후 셀링툴 업체 연동 개발은 포스티 뿐만 아니라 지그재그의 브랜드 사업 확장에도 활용될 수 있었다.

3. 가격 할인 제약으로 인해 별도 장치가 필요하다. 패션 브랜드는 주로 기획전을 여러 플랫폼을 구분해서 일정을 나눠서 진행을 한다. 보통 패션브랜드 MD는 셀링툴을 통해 여러 온라인 채널의 가격을 관리하기 때문에 기획전 또는 어떤 형태의 할인에 대해서 특정 채널의 판매가격을 낮추는 것을 부담스러워 한다. 또한 브랜딩 또는 오프라인 매장과 가격 일관성 관점에서 판매가를 건드리기 보다는 별도 상품 쿠폰 형태의 할인을 선호한다. 결국 플랫폼을 운영하는 입장에선 수요를 만들기 위해서 가격을 낮추는 기재가 필요한데 이러한 요소에 대한 고려가 필요하다. 일반적인 형태는 쿠폰 플레이를 생각할 수 있고, 이밖에 컨셉 관점에서 접근하면 공동 구매와 같은 장치를 통하여 우리 플랫폼 만의 가격 체계를 설계할 수도 있다. 

4. 브랜딩에 대한 안심이 중요하다. 이 일을 하면서 "매출이 인격이다"라는 말을 많이 들었지만, 여전히 패션 브랜드사 담당자가 우려하는 것은 브랜딩이었다. 대부분 담당자 분들은 "입점한 브랜드가 어떻게 되나요?"라고 항상 질문을 하신다. 새로운 플랫폼이기 때문에 Selection이 어떤 전시 구조로 보여지는지 명확하지 않기 때문에 이 점을 잘 커뮤니케이션하는 것이 중요했다. 기본적으로 우리팀은 기술 기반으로 패션 시장의 문제점을 혁신하는 장점이었다. 관련해서 유저 데이터 기반으로 개인화된 상품 추천 방식으로 이에 대한 우려를 해소시키려 했다. 결국 초기 프로덕트에서 브랜딩과 관련해서 높은 퀄리티의 크리에이티브를 제공하는 쇼케이스 CMS 같은 플랫폼을 제공하는 것이 어려웠기 때문에 이 점은 숙제로 가져갔었고, 항상 신중하게 커뮤니케이션하려고 모두가 노력했다.

브랜드 패션에 대해서 낮았던 팀의 이해도는 빠르게 상품 소개서 기반으로 사업의 가치제안을 검증하면서 점점 개선이 되었고, 이러한 요구사항은 제품 개발에도 반영되었다. 당시 포스티팀은 풀타임 5명(PM, 디자이너, 사업개발, MD), 파트타임 1명(CTO)의 소규모 조직이었고 이렇게 2개월을 준비하여 포스티 서비스를 출시했다. 출시 후 사업 추진 과정에서 아쉬운 점이 많았지만 커머스 프로덕트를 2개월만에 출시하고, 이후 빠르게 구글 플레이 쇼핑 카테고리 2위, 월 거래액 10억원 대에 진입한 점은 팀 스스로 자부심을 가져도 좋다고 생각한다.

제품 개발은 크게 발견(product discovery)와 배포(delievery)로 구분된다. 다시 설명하면 제품팀이&nbsp;잘 모르는 영역을 알아가는 과정과 이를 바탕으로 디자인, 엔지니어링을 통해 제품에 가치를 증분하는 작업 과정으로 구성된다. 많은 팀들이 경우 제품 발견(product discovery)을 생략하고 바로 기능을 개발하는 단계로 건너 뛰는 경우가 많다. 이렇게 제품을 만들면 3-4명의 제품팀 멤버(PM, 엔지니어, 디자이너)가 최소 2-3주 개발을 진행하게 된다.&nbsp; 그렇게 배포된 기능은 대부분 성과가 바로 나타나지 않기 때문에 후속 개선 작업을 진행한다. 문제는 이 개선 작업이 프로젝트 시작부터 애초에 근거(evidence)가 빈약한 상태였기 때문에&nbsp;계속해서 잘못된 최적화를 시도하게 된다. 그러면 이렇게 추가로 1-2주 더 시간이 지나간다.&nbsp;여기서&nbsp;제품 발견을 중요하게 생각하지 않는 조직이 좋아하는 단어 '리소스' 기준으로 계산하면 멤버 1명당 연봉이 7천만원이라고 가정하면 최소 3명 기준으로 2000만원의 비용이 소요되는 것이다.&nbsp;단순한 인건비 손해 외 팀 전체적으로 단순히 기능 구현에 집중했기 때문에 팀이 모르고 있는 영역(unknown)에 대해 팀의 학습과 이해도를 높일 수 있는 기회를 잃게 된다. 어떻게 하면 빠르게 모르는 것(unknown)을 파악할 수 있을까? 내가 자주 활용했던&nbsp;방법은 바로 제품을 만들지 않고,&nbsp;상품 소개서를 기반으로 바로 고객 및 시장의 이해관계자를 만나는 것이다.&nbsp;과거 카카오스타일에서&nbsp;포스티(Posty)라는 신규 사업을 담당할 때 상품 소개서를 빠르게 제작하여 브랜드 패션 기업을 컨택했다. 아직 제품이 만들어지지 않은 상태였기 때문에 포스티가 풀려고 했던 문제점과 비전을 중심으로 상품 소개서를 제작했다.&nbsp;상품 소개서가 구체적이지 않았지만, 당시 팀이 브랜드 패션 시장에 대한 이해도가 높지 않은 상태였기 때문에 빠르게 시장의 이해관계자를 만나서 니즈를 파악하는 것이 중요하다고 생각하여 바로 컨택을 진행했다.당시에 우리 팀은 브랜드 패션에 있어 핵심 이해관계자가 벤더사(온라인 판매 대행사)일 것이라고 가정했다.&nbsp;주요 브랜드 패션 커머스 플랫폼에서&nbsp;상세 페이지 정보를 확인하면 주요 연락처에 스탁컴퍼니, 웹뜰과 같은 벤더사&nbsp;정보가 있어서, 브랜드 패션에 있어 벤더사를 공략하면 패션 브랜드 입점 세일즈가 효율적일 것이라고 생각했다.&nbsp; 하지만 몇 번의 미팅을 진행하니 우리의 가정이 틀렸다는 것을 파악했다. 다른 온라인 비즈니스(예: 광고)의 대행사와 달리 패션 커머스 시장에서 벤더가 가진 권한이 크지는 않았다. 커머스 플랫폼 입점은 벤더가 단독으로 진행할 수 없고, 패션 브랜드사의 승인을 받아야 진행이 가능했다. 주요 벤더사를 통해 우리 플랫폼 영업이 빠르게 확장하길 바랐던 바람은 그저 행복한 상상일 뿐이었다. 또 한편으로는 잘못된 가정으로 제품 개발을 시작했다면 1개의 벤더사가 여러 브랜드를 대행하여 관리하는 영역에 대해서 잘못된 엔지니어링 요구사항을 정의할 수도 있었다.&nbsp;다행히 빠른 검증을 통해 잘못된 문제 정의를 하지 않게 되어서 마음의&nbsp;안심을 얻기도 했다.상품 소개서를 통해 계속 브랜드사 미팅을 진행하면서 피드백 기반으로 계속 상품 소개서의 콘텐츠를 업데이트하였고, 또한 제품 개발 관련해서 여러 근거들을 확보할 수 있었다.&nbsp;팀이 이 과정을 통해 얻게 된 인사이트는 아래와 같다. 1. 패션브랜드 기업 내부의 중요한 조직간 이해관계가 존재한다.&nbsp;오프라인 채널과 온라인 채널을 관리하는 조직이 분리되어 있으며, 주요 재고는 오프라인 매장 중심으로 우선순위 높게 유통이 된다. 만일 온라인 판매 가격이 오프라인 판매가 보다 낮은 경우 두 조직간의 이해관계 충돌이 발생한다. 이에 대한 대안으로 우회적으로 네이버 지식쇼핑에 가격이 노출되지 않는 온라인 판매 방식을 활용하거나 기업 내부적으로 합의를 통해 기획전이란 형태로 프로모션을 진행한다. 하지만 이 경우에도 조직간의 긴장감이 존재한다. 이밖에 오프라인 조직은 신상을 판매하고, 온라인 조직은 이월상품 중심으로 판촉 활동을 진행하는 경우도 존재했다. 따라서&nbsp;패션 브랜드 온라인 MD 담당자가 오프라인 조직로부터 챌린지를 최소화할 수 있는 상품 노출/유통 구조가 필요했다. 2. 온라인 채널을 관리하는 MD 인력 대비 관리하는 플랫폼이 많다. 기본적으로 패션브랜드는 전통적인 리테일 비즈니스의 자산을 가지고 있다. 영업이익이 전반적으로 높지 않은 상황에서&nbsp;이커머스 조직에 대한 투자를 적극적으로 하기 힘든 상황이다. 따라서 적은 수의 MD 멤버가&nbsp;여러 온라인 채널(예: 하프클럽, 패션플러스 등)을 관리해야 한다. 여러 온라인 채널에 상품 정보(상품명, 옵션, 가격정보 등)와&nbsp;주문 정보를 동시에 관리해야한다.&nbsp;이를 위해서 브랜드 패션 MD는 셀링툴(예: EC모니터, 사방넷, 플레이오토, 샵링커)이란 솔루션을 통해 단일한 인터페이스로 온라인 채널의 상품, 주문 정보를 관리하고 있다.&nbsp;사실 우리팀은 셀링툴이란 존재도 모르고 있던 상황이어서 빠르게 관련해서 상품정보 연동하는 API를 개발하고, 셀링툴 업체와 빠르게 계약을 맺어서 연동 개발을 진행했다. 외부 업체와 빠르게 계약하고 연동하는 과정은 사실 쉽지 않은데, 작업 중간에 다행히 상품 정보를 관리하는 유관부서가 지원을 해주어 적절한 시점에 필요한 bottleneck을 해결할 수&nbsp;있었다. 이후 셀링툴 업체 연동 개발은 포스티 뿐만 아니라&nbsp;지그재그의 브랜드 사업 확장에도 활용될 수 있었다. 3. 가격 할인 제약으로 인해 별도 장치가 필요하다.&nbsp;패션 브랜드는 주로 기획전을 여러 플랫폼을 구분해서 일정을 나눠서 진행을 한다. 보통 패션브랜드 MD는 셀링툴을 통해 여러 온라인 채널의 가격을 관리하기 때문에 기획전 또는 어떤 형태의 할인에 대해서 특정 채널의 판매가격을 낮추는 것을 부담스러워 한다. 또한 브랜딩 또는 오프라인 매장과 가격 일관성 관점에서 판매가를 건드리기 보다는 별도 상품 쿠폰 형태의 할인을 선호한다.&nbsp;결국 플랫폼을 운영하는 입장에선 수요를 만들기 위해서 가격을 낮추는 기재가 필요한데 이러한 요소에 대한 고려가 필요하다. 일반적인 형태는 쿠폰 플레이를 생각할 수 있고, 이밖에 컨셉 관점에서 접근하면 공동 구매와 같은 장치를 통하여 우리 플랫폼 만의 가격 체계를 설계할 수도 있다.&nbsp; 4. 브랜딩에 대한 안심이 중요하다. 이 일을 하면서 "매출이 인격이다"라는 말을 많이 들었지만, 여전히 패션 브랜드사 담당자가 우려하는 것은 브랜딩이었다. 대부분 담당자 분들은 "입점한 브랜드가 어떻게 되나요?"라고 항상 질문을 하신다. 새로운 플랫폼이기 때문에 Selection이 어떤 전시 구조로 보여지는지 명확하지 않기 때문에 이 점을 잘 커뮤니케이션하는 것이 중요했다. 기본적으로 우리팀은 기술 기반으로 패션 시장의 문제점을 혁신하는 장점이었다. 관련해서 유저 데이터 기반으로 개인화된 상품 추천 방식으로 이에 대한 우려를 해소시키려 했다.&nbsp;결국 초기 프로덕트에서 브랜딩과 관련해서 높은 퀄리티의 크리에이티브를 제공하는&nbsp;쇼케이스 CMS 같은 플랫폼을 제공하는 것이 어려웠기 때문에 이 점은&nbsp;숙제로 가져갔었고, 항상 신중하게 커뮤니케이션하려고 모두가 노력했다. 브랜드 패션에 대해서 낮았던 팀의 이해도는 빠르게 상품 소개서 기반으로 사업의 가치제안을 검증하면서 점점 개선이 되었고, 이러한 요구사항은 제품 개발에도 반영되었다. 당시 포스티팀은 풀타임 5명(PM, 디자이너, 사업개발, MD), 파트타임 1명(CTO)의 소규모 조직이었고 이렇게 2개월을 준비하여 포스티 서비스를 출시했다. 출시 후 사업 추진 과정에서 아쉬운 점이 많았지만 커머스 프로덕트를 2개월만에 출시하고, 이후 빠르게 구글 플레이 쇼핑 카테고리 2위, 월 거래액 10억원 대에 진입한 점은 팀 스스로 자부심을 가져도 좋다고 생각한다.

효율적인 제품 발견 과정: 포스티(Posty)에서 배운 교훈

제가 운영하는 뉴스레터 공유드립니다. 구독 부탁드립니다 :)
https://maily.so/7ish

계란후라이 1041

조직에 새로운 구성원이 왔을 때, 그들의 적용을 돕는 것을 온보딩 프로그램이라고 합니다. 어제 한 회사의 온보딩 프로그램을 경험하고 느끼고 배운 점을 공유합니다.
어제 온보딩 프로그램을 경험하며 느낀 점은 담당자가 참 친절하다는 것이었습니다. 시종일관 밝은 표정으로 새로운 구성원을 맞이하고 조직과 문화, 제도에 대해서 설명해 주는 내내 친절함을 잃지 않았습니다. 그래서 조금 힘들 것 같다는 생각을 했어요. 한 시간이 넘는 동안 새로운 구성원의 반응 없음에도 불구하고 밝음과 친절함을 유지하는 일이 보통 난이도가 아닐 것입니다. 온보딩 프로그램 진행하는 친절한 담당자의 의도와 다르게 내용이 친절했는지 돌아보면 꼭 그런 것 같진 않습니다. 많은 정보를 한 번에 입력받는 입장에서 겪는 당연한 문제인가 생각도 들지만, 방법을 조금 개선한다면 현재 버전보다 나아질 수 있을 것입니다.

온보딩 프로그램에 필요한 콘셉트는 크게 두 가지입니다. 그 두 가지는 환영과 정보입니다. 처음 방문하는 매장에 문을 열기 전에 ‘여기에 내가 원하는 제품이 있을까? 매장 이용 방법을 모르는 데 어떡하지? 두 마음이 들 것입니다.
직원이 두 팔 벌려 환영하는 인사하는 모습은 마음속 태도로부터 기인하는데 이건 아주 기본적이 마인드 셋입니다.
환영은 느낌으로 전달해야 하는 메시지라고 생각해요.
우리가 고객으로 방문하는 매장에서 긍정적으로 느끼는 부분은 직원이 우리에게 작은 정성을 보여 주는 것과 준비된 모습, 그리고 섬세한 배려일 것입니다. 말과 행동뿐만 아니라 잘 준비된 프로그램 시작과 끝이 환영한다는 느낌을 줍니다.
조직이 근무하는 공간 활용에 대한 이해와 방법, 근무하는 동안 지켜야 하는 규칙, 업무 수행을 위한 기본적인 도구 사용 방법 등 매뉴얼대로 따라 하면 누구나 할 수 있는 정보가 필요합니다. 새로 합류한 조직에서 앞으로 무엇을 해야 하는지 알고, 무엇을 알아야 해야 할 일을 문제없이 진행할 수 있는지 정보를 전달해야 합니다. 가능한 이해하기 쉽도록 설명이 친절하는 내용이 중요합니다.
도움이 필요한 순간에 찾아야 하는 사람과 도움을 줄 수 있는 사람에게 상황 설명 tip, 실전에 도입해서 업무에 자연스럽게 적응할 수 있는 방법을 알려주면 좋겠습니다.
구체적이고 쉽게 적응 방법을 설명했음에도 행동하지 않을 때 문제가 새로운 구성원에게 문제가 있다고 판단할 수 있습니다. 매뉴얼이 명확하지 않은 경우, 새로운 구성원의 열정과 태도만 탓할 수 없습니다.

꼼꼼하게 짜인 각본처럼 시작과 끝까지 짜임새를 갖춘 온보딩 프로그램이 된다면 새로운 구성원은 입사 첫날을 한 결 더 기분 좋은 느낌을 받을 수 있을 것입니다.
'내가 조직을 잘 선택했구나!’
신뢰할 수 있는 사람들과 문화가 있는 조직이라고 감동할 것입니다.

계란후라이 1041 조직에 새로운 구성원이 왔을 때, 그들의 적용을 돕는 것을 온보딩 프로그램이라고 합니다. 어제 한 회사의 온보딩 프로그램을 경험하고 느끼고 배운 점을 공유합니다.어제 온보딩 프로그램을 경험하며 느낀 점은 담당자가 참 친절하다는 것이었습니다. 시종일관 밝은 표정으로 새로운 구성원을 맞이하고 조직과 문화, 제도에 대해서 설명해 주는 내내 친절함을 잃지 않았습니다. 그래서 조금 힘들 것 같다는 생각을 했어요. 한 시간이 넘는 동안 새로운 구성원의 반응 없음에도 불구하고 밝음과 친절함을 유지하는 일이 보통 난이도가 아닐 것입니다. 온보딩 프로그램 진행하는 친절한 담당자의 의도와 다르게 내용이 친절했는지 돌아보면 꼭 그런 것 같진 않습니다. 많은 정보를 한 번에 입력받는 입장에서 겪는 당연한 문제인가 생각도 들지만, 방법을 조금 개선한다면 현재 버전보다 나아질 수 있을 것입니다.​온보딩 프로그램에 필요한 콘셉트는 크게 두 가지입니다. 그 두 가지는 환영과 정보입니다. 처음 방문하는 매장에 문을 열기 전에 ‘여기에 내가 원하는 제품이 있을까? 매장 이용 방법을 모르는 데 어떡하지? 두 마음이 들 것입니다.직원이 두 팔 벌려 환영하는 인사하는 모습은 마음속 태도로부터 기인하는데 이건 아주 기본적이 마인드 셋입니다.환영은 느낌으로 전달해야 하는 메시지라고 생각해요.우리가 고객으로 방문하는 매장에서 긍정적으로 느끼는 부분은 직원이 우리에게 작은 정성을 보여 주는 것과 준비된 모습, 그리고 섬세한 배려일 것입니다. 말과 행동뿐만 아니라 잘 준비된 프로그램 시작과 끝이 환영한다는 느낌을 줍니다.조직이 근무하는 공간 활용에 대한 이해와 방법, 근무하는 동안 지켜야 하는 규칙, 업무 수행을 위한 기본적인 도구 사용 방법 등 매뉴얼대로 따라 하면 누구나 할 수 있는 정보가 필요합니다. 새로 합류한 조직에서 앞으로 무엇을 해야 하는지 알고, 무엇을 알아야 해야 할 일을 문제없이 진행할 수 있는지 정보를 전달해야 합니다. 가능한 이해하기 쉽도록 설명이 친절하는 내용이 중요합니다.도움이 필요한 순간에 찾아야 하는 사람과 도움을 줄 수 있는 사람에게 상황 설명 tip, 실전에 도입해서 업무에 자연스럽게 적응할 수 있는 방법을 알려주면 좋겠습니다.구체적이고 쉽게 적응 방법을 설명했음에도 행동하지 않을 때 문제가 새로운 구성원에게 문제가 있다고 판단할 수 있습니다. 매뉴얼이 명확하지 않은 경우, 새로운 구성원의 열정과 태도만 탓할 수 없습니다.​꼼꼼하게 짜인 각본처럼 시작과 끝까지 짜임새를 갖춘 온보딩 프로그램이 된다면 새로운 구성원은 입사 첫날을 한 결 더 기분 좋은 느낌을 받을 수 있을 것입니다.'내가 조직을 잘 선택했구나!’신뢰할 수 있는 사람들과 문화가 있는 조직이라고 감동할 것입니다.

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

> 이 포스팅은 링크드인 @이재철 님의 도움으로 완성되었습니다. 미리 감사드립니다! 🙏

공공데이터를 사용할 때, OpenAPI를 통해 특정 날짜나 조건에 맞는 데이터를 추출할 수 있습니다. 보통은 파이썬 코드를 사용해
request
로 데이터를 가져오고, JSON으로 파싱하여 가공하지만, 이번 포스팅에서는 노코드로 동일한 과정을 처리하는 방법을 설명드리려고 합니다.

💡 참고로, 이 시나리오를 실행하면 많은 Operation 수가 요구되어 최적화를 하지 않으면 비용이 발생할 수 있습니다. 따라서, Make로도 이런 작업이 가능하다는 점을 이해해주시면 좋겠습니다.

제가 사용하는 API는 "서울시 공공자전거 대여소 정보"입니다. 사용을 위해서는 별도의 가입과 API 인증키가 필요합니다.

 * 공공데이터 URL: [서울시 공공자전거 대여소 정보](https://data.seoul.go.kr/dataList/OA-13252/F/1/datasetView.do)
 * 샘플 API: [샘플 API 링크](https://openapi.seoul.go.kr:8088/sample/json/tbCycleStationInfo/1/5/)

# 프로세스 📊
1. 공공데이터 포털에서 API 발급받기
2. API 키값과 파라미터 값을 Make에서 설정
3. 인덱스가 step만큼 늘어나는 반복문 생성
4. API 호출 후 필요한 데이터만 JSON으로 파싱
5. 커스텀 컬럼명 설정 후 CSV로 저장
6. 구글 드라이브에 업로드

이 프로세스를 보면, 파이썬에서 작업하는 방식과 크게 다르지 않은 구조입니다. 사실, Make에서 직접 파이썬 코드를 실행해보고 싶었지만, 비용 발생 우려로 인해 최소화된 방법으로 시도해보았습니다.

개인적인 경험을 공유드리면, 파이썬 코드가 익숙한 저로선 Make 제작을 권장 드리긴 어렵습니다. 간단해 보이지만, 이 시나리오를 제작하는 데는 상당한 시간이 걸렸습니다. Make에서 모듈이 작동하는 방식을 이해하는 데 시간이 필요했고, 여러 시행착오를 거쳐 완성한 시나리오입니다.

노코드가 매력적이지만, 이를 제대로 활용하기 위해서는 많은 공부가 필요하며, 유지보수 측면에서 코드 작업보다 번거로울 수 있다는 점은 분명합니다. 그래도, 노코드로도 데이터를 자동으로 수집할 수 있다는 점은 큰 장점입니다.

앞으로도 더 나은 Make 분석 시나리오들을 만들어보려고 합니다. 좋은 아이디어나 의견이 있다면 언제든지 공유해 주세요. 감사합니다! 🙌

#공공데이터 #Make자동화 #노코드 #데이터수집

&gt; 이 포스팅은 링크드인 @이재철 님의 도움으로 완성되었습니다. 미리 감사드립니다! 🙏 공공데이터를 사용할 때, OpenAPI를 통해 특정 날짜나 조건에 맞는 데이터를 추출할 수 있습니다. 보통은 파이썬 코드를 사용해 <code >request</code>로 데이터를 가져오고, JSON으로 파싱하여 가공하지만, 이번 포스팅에서는 노코드로 동일한 과정을 처리하는 방법을 설명드리려고 합니다. 💡 참고로, 이 시나리오를 실행하면 많은 Operation 수가 요구되어 최적화를 하지 않으면 비용이 발생할 수 있습니다. 따라서, Make로도 이런 작업이 가능하다는 점을 이해해주시면 좋겠습니다. 제가 사용하는 API는 "서울시 공공자전거 대여소 정보"입니다. 사용을 위해서는 별도의 가입과 API 인증키가 필요합니다. <ul ><li>공공데이터 URL: [서울시 공공자전거 대여소 정보](https://data.seoul.go.kr/dataList/OA-13252/F/1/datasetView.do)</li><li> 샘플 API: [샘플 API 링크](https://openapi.seoul.go.kr:8088/sample/json/tbCycleStationInfo/1/5/)</li></ul> # 프로세스 📊1. 공공데이터 포털에서 API 발급받기2. API 키값과 파라미터 값을 Make에서 설정3. 인덱스가 step만큼 늘어나는 반복문 생성4. API 호출 후 필요한 데이터만 JSON으로 파싱5. 커스텀 컬럼명 설정 후 CSV로 저장6. 구글 드라이브에 업로드 이 프로세스를 보면, 파이썬에서 작업하는 방식과 크게 다르지 않은 구조입니다. 사실, Make에서 직접 파이썬 코드를 실행해보고 싶었지만, 비용 발생 우려로 인해 최소화된 방법으로 시도해보았습니다. 개인적인 경험을 공유드리면, 파이썬 코드가 익숙한 저로선 Make 제작을 권장 드리긴 어렵습니다. 간단해 보이지만, 이 시나리오를 제작하는 데는 상당한 시간이 걸렸습니다. Make에서 모듈이 작동하는 방식을 이해하는 데 시간이 필요했고, 여러 시행착오를 거쳐 완성한 시나리오입니다. 노코드가 매력적이지만, 이를 제대로 활용하기 위해서는 많은 공부가 필요하며, 유지보수 측면에서 코드 작업보다 번거로울 수 있다는 점은 분명합니다. 그래도, 노코드로도 데이터를 자동으로 수집할 수 있다는 점은 큰 장점입니다. 앞으로도 더 나은 Make 분석 시나리오들을 만들어보려고 합니다. 좋은 아이디어나 의견이 있다면 언제든지 공유해 주세요. 감사합니다! 🙌 #공공데이터 #Make자동화 #노코드 #데이터수집

[Make 자동화] 공공데이터 OpenAPI 데이터 수집 시나리오 🚀

Have you noticed that Git is so integral to working with code that people hardly ever include it in their tech stack or on their CV at all? The assumption is you know it already, or at least enough...

The guide to Git I never had.

개발자로서 우리의 일상은 코드를 읽고, 작성하고, 검토하는 데 집중되어 있습니다. Git은 우리가 사용하는 도구 중 가장 중요한 것 중 하나라고 할 수 있습니다. Git의 기능과 특징을 마스터하는 것은 개발자로서 자신에게 할 수 있는 최고의 투자 중 하나입니다.
 
브랜치 (Branches)
Git 저장소에는 "main" 또는 "master"(deprecated)라는 메인 개발 라인이 있으며, 여기서 여러 브랜치가 분기됩니다. 이 브랜치들은 동시에 여러 기능이나 수정을 병행하여 작업할 수 있도록 해줍니다.

커밋 (Commits)
Git 커밋은 업데이트된 코드를 묶어 특정 시점의 프로젝트 코드를 캡처합니다. 각 커밋은 이전 커밋 이후로 이루어진 변경사항을 기록하며, 프로젝트 개발의 전체적인 역사를 구축합니다.

커밋을 참조할 때는 일반적으로 고유한 암호화 해시 값을 사용합니다.
git show abc123def456789

이 명령어는 해당 해시 값을 가진 커밋의 상세 정보를 보여줍니다.
 
태그 (Tags)
Git 태그는 Git 역사 내에서 주요 이정표를 나타내며, 일반적으로 릴리스, 버전, 또는 중요한 커밋을 표시합니다. 이러한 태그는 프로젝트의 여정에서 특정 시점을 나타내는 데 매우 유용합니다.

헤드 (HEAD)
현재 체크아웃된 브랜치의 가장 최신 커밋은 HEAD에 의해 표시되며, 저장소 내의 모든 참조를 가리킬 수 있는 포인터 역할을 합니다. 특정 브랜치에 있을 때, HEAD는 해당 브랜치의 최신 커밋을 가리킵니다. 가끔 HEAD는 브랜치의 끝이 아닌 특정 커밋을 직접 가리킬 수도 있습니다.
 
스테이지 (Stages)
Git 단계를 이해하는 것은 Git 워크플로우를 이해하는 데 매우 중요합니다. 단계는 파일에 대한 변경사항이 커밋되기 전에 발생하는 논리적 전환을 나타냅니다. Git 단계를 더 자세히 살펴봅시다:

 * 작업 디렉토리 (Working directory) 👷: 작업 디렉토리는 프로젝트 파일을 수정하고 생성하는 곳입니다. 로컬 머신에서 파일의 현재 상태를 나타냅니다.
 * 스테이징 영역 (Staging area) 🚉: 스테이징 영역은 변경사항을 커밋하기 전에 준비하는 대기 영역 또는 사전 커밋 구역입니다.
 * 로컬 저장소 (Local repository) 🗄️: 로컬 저장소는 Git이 커밋된 변경사항을 영구히 저장하는 곳입니다. 프로젝트의 역사를 검토하고, 이전 상태로 되돌리며, 동일한 코드베이스에서 다른 사람들과 협업할 수 있게 해줍니다.
 * 원격 저장소 (Remote repository) 🛫: 원격 저장소는 중앙 서버(예: GitHub, GitLab, Bitbucket)에 위치하며, 프로젝트를 공유하고 다른 사람들과 협업할 수 있는 곳입니다.
 
Git 시작하기
어디서부터 시작해야 할지 고민이라면, Git에서는 작업 공간(workspace)에서 시작해야 합니다. 기존의 저장소(repository)를 포크(fork)하거나 클론(clone)하여 그 작업 공간의 복사본을 가질 수 있습니다. 만약 완전히 새롭게 로컬 폴더에서 시작하고자 한다면, 해당 폴더를 Git 저장소로 만들기 위해 git init 명령어를 사용해야 합니다. 다음 단계로는 자격 증명 설정을 반드시 잊지 말아야 합니다.

브랜치 작업
로컬에서 작업할 때는 현재 어떤 브랜치에 있는지 아는 것이 중요합니다. 다음 명령어들이 유용합니다:
# Will show the changes in the local repository
git branch 
# Or create a branch directly with
git branch feature-branch-name

브랜치 간 전환을 위해서는:
git switch

또한, 브랜치 간 전환뿐만 아니라 다음과 같이 할 수도 있습니다:
git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name

저장소의 상태를 확인하려면 다음을 사용하십시오:
git status

현재 브랜치를 항상 명확하게 보기 위해서는 터미널에 브랜치를 표시하는 것이 좋습니다. 이를 도와주는 여러 터미널 애드온이 있습니다.

커밋 작업
커밋을 작업할 때, git commit -m을 사용하여 변경 사항을 기록하고, git amend를 사용하여 가장 최근의 커밋을 수정하며, 커밋 메시지 규칙을 지키는 것이 중요합니다.
git commit -m "의미 있는 메시지"

마지막 커밋에 변경 사항이 있을 때는 새 커밋을 만들지 않고 --amend 플래그를 사용하여 가장 최근 커밋을 수정할 수 있습니다:
# 변경사항을 추가
git add .
git commit --amend

이 명령어는 기본 텍스트 편집기를 열어 필요하면 커밋 메시지를 수정할 수 있게 합니다.
git push origin your_branch --force

기본적으로 자주 커밋하는 것이 더 좋습니다. 이는 진행 상황을 잃거나 스테이징되지 않은 변경사항을 실수로 리셋하는 것을 방지합니다. 이후에 여러 커밋을 합치거나 인터랙티브 리베이스(interactive rebase)를 통해 히스토리를 재작성할 수 있습니다.
 
git log를 사용하여 최근 커밋부터 과거로 거슬러 올라가는 순서로 커밋 목록을 확인할 수 있습니다.
 

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

개발자로서 우리의 일상은 코드를 읽고, 작성하고, 검토하는 데 집중되어 있습니다. Git은 우리가 사용하는 도구 중 가장 중요한 것 중 하나라고 할 수 있습니다. Git의 기능과 특징을 마스터하는 것은 개발자로서 자신에게 할 수 있는 최고의 투자 중 하나입니다.&nbsp;브랜치 (Branches)Git 저장소에는 "main" 또는 "master"(deprecated)라는 메인 개발 라인이 있으며, 여기서 여러 브랜치가 분기됩니다. 이 브랜치들은 동시에 여러 기능이나 수정을 병행하여 작업할 수 있도록 해줍니다. 커밋 (Commits)Git 커밋은 업데이트된 코드를 묶어 특정 시점의 프로젝트 코드를 캡처합니다. 각 커밋은 이전 커밋 이후로 이루어진 변경사항을 기록하며, 프로젝트 개발의 전체적인 역사를 구축합니다. 커밋을 참조할 때는 일반적으로 고유한 암호화 해시 값을 사용합니다.<pre ><code class="language-bash">git show abc123def456789</code></pre>이 명령어는 해당 해시 값을 가진 커밋의 상세 정보를 보여줍니다.&nbsp;태그 (Tags)Git 태그는 Git 역사 내에서 주요 이정표를 나타내며, 일반적으로 릴리스, 버전, 또는 중요한 커밋을 표시합니다. 이러한 태그는 프로젝트의 여정에서 특정 시점을 나타내는 데 매우 유용합니다. 헤드 (HEAD)현재 체크아웃된 브랜치의 가장 최신 커밋은 HEAD에 의해 표시되며, 저장소 내의 모든 참조를 가리킬 수 있는 포인터 역할을 합니다. 특정 브랜치에 있을 때, HEAD는 해당 브랜치의 최신 커밋을 가리킵니다. 가끔 HEAD는 브랜치의 끝이 아닌 특정 커밋을 직접 가리킬 수도 있습니다.&nbsp;스테이지 (Stages)Git 단계를 이해하는 것은 Git 워크플로우를 이해하는 데 매우 중요합니다. 단계는 파일에 대한 변경사항이 커밋되기 전에 발생하는 논리적 전환을 나타냅니다. Git 단계를 더 자세히 살펴봅시다: <ul ><li>작업 디렉토리 (Working directory) 👷: 작업 디렉토리는 프로젝트 파일을 수정하고 생성하는 곳입니다. 로컬 머신에서 파일의 현재 상태를 나타냅니다.</li><li>스테이징 영역 (Staging area) 🚉: 스테이징 영역은 변경사항을 커밋하기 전에 준비하는 대기 영역 또는 사전 커밋 구역입니다.</li><li>로컬 저장소 (Local repository) 🗄️: 로컬 저장소는 Git이 커밋된 변경사항을 영구히 저장하는 곳입니다. 프로젝트의 역사를 검토하고, 이전 상태로 되돌리며, 동일한 코드베이스에서 다른 사람들과 협업할 수 있게 해줍니다.</li><li>원격 저장소 (Remote repository) 🛫: 원격 저장소는 중앙 서버(예: GitHub, GitLab, Bitbucket)에 위치하며, 프로젝트를 공유하고 다른 사람들과 협업할 수 있는 곳입니다.</li></ul>&nbsp;Git 시작하기어디서부터 시작해야 할지 고민이라면, Git에서는 작업 공간(workspace)에서 시작해야 합니다. 기존의 저장소(repository)를 포크(fork)하거나 클론(clone)하여 그 작업 공간의 복사본을 가질 수 있습니다. 만약 완전히 새롭게 로컬 폴더에서 시작하고자 한다면, 해당 폴더를 Git 저장소로 만들기 위해 git init 명령어를 사용해야 합니다. 다음 단계로는 자격 증명 설정을 반드시 잊지 말아야 합니다. 브랜치 작업로컬에서 작업할 때는 현재 어떤 브랜치에 있는지 아는 것이 중요합니다. 다음 명령어들이 유용합니다:<pre ><code class="language-bash"># Will show the changes in the local repository
git branch 
# Or create a branch directly with
git branch feature-branch-name</code></pre>브랜치 간 전환을 위해서는:<pre ><code class="language-bash">git switch</code></pre>또한, 브랜치 간 전환뿐만 아니라 다음과 같이 할 수도 있습니다:<pre ><code class="language-bash">git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name</code></pre>저장소의 상태를 확인하려면 다음을 사용하십시오:<pre ><code class="language-bash">git status</code></pre>현재 브랜치를 항상 명확하게 보기 위해서는 터미널에 브랜치를 표시하는 것이 좋습니다. 이를 도와주는 여러 터미널 애드온이 있습니다. 커밋 작업커밋을 작업할 때, git commit -m을 사용하여 변경 사항을 기록하고, git amend를 사용하여 가장 최근의 커밋을 수정하며, 커밋 메시지 규칙을 지키는 것이 중요합니다.<pre ><code class="language-bash">git commit -m "의미 있는 메시지"</code></pre>마지막 커밋에 변경 사항이 있을 때는 새 커밋을 만들지 않고 --amend 플래그를 사용하여 가장 최근 커밋을 수정할 수 있습니다:<pre ><code class="language-bash"># 변경사항을 추가
git add .
git commit --amend</code></pre>이 명령어는 기본 텍스트 편집기를 열어 필요하면 커밋 메시지를 수정할 수 있게 합니다.<pre ><code class="language-bash">git push origin your_branch --force</code></pre>기본적으로 자주 커밋하는 것이 더 좋습니다. 이는 진행 상황을 잃거나 스테이징되지 않은 변경사항을 실수로 리셋하는 것을 방지합니다. 이후에 여러 커밋을 합치거나 인터랙티브 리베이스(interactive rebase)를 통해 히스토리를 재작성할 수 있습니다.&nbsp;git log를 사용하여 최근 커밋부터 과거로 거슬러 올라가는 순서로 커밋 목록을 확인할 수 있습니다.&nbsp; 번역: [https://ducktopia.tistory.com/132]원문:

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

카카오페이에서 프론트엔드 개발을 하며 스켈레톤 UI와 사용자 경험 향상에 대해 고민한 내용을 공유합니다.

무조건 스켈레톤 화면을 보여주는게 사용자 경험에 도움이 될까요? | 카카오페이 기술 블로그

웹사이트에서 데이터를 불러올 때, 흔히 '스켈레톤 화면'이라는 로딩 표시를 사용합니다. 하지만 이게 항상 최선의 선택은 아니라는 흥미로운 블로그 글이 있어 공유드립니다.

세계적인 UX리서치 그룹 닐슨 노먼은 1초 미만이 소요되는 항목의 경우 애니메이션을 사용하면 오히려 주의가 산만해진다고 합니다. 이유는 사용자 입장에서는 너무 짧은 시간 이기에 화면에서 어떤 일이 발생했는지 따라갈 수 없기 때문인데요.

스켈레톤 화면의 효과
 1. 빠른 로딩 (100ms 미만):
    * 스켈레톤이 너무 빨리 사라져 화면이 '덜그럭거리는' 느낌을 줍니다.
    * 결론: 이런 경우 스켈레톤을 보여주지 않는 것이 더 깔끔합니다.
 2. 느린 로딩 (300ms 이상):
    * 스켈레톤 화면이 유용하게 작용합니다.
    * 사용자에게 '무언가 로딩 중'이라는 시각적 피드백을 제공합니다.

카카오페이의 해결책: 지연된 스켈레톤
카카오페이는 이 문제를 Suspense와 DeferredComponent라는 유틸리티 컴포넌트로 아래와 같이 해결했습니다. 200ms 까지는 빈 화면을 보여주고 이후에는 스켈레톤을 표시하는 방식인데요.
 * 작동 방식:
   * 0-200ms: 빈 화면 표시
   * 200ms 이후:
     * 데이터 로딩 완료 시 → 즉시 데이터 표시
     * 데이터 로딩 중 → 스켈레톤 표시
 * 예시:
   * 100ms 응답: 200ms 후 바로 데이터 표시 (스켈레톤 없음)
   * 400ms 응답: 200ms 후 스켈레톤 표시, 400ms에 데이터 표시

또한 성능 모니터링 도구(Firebase)를 활용하여 실제 API 응답 시간을 분석하여 대부분의 응답시간이 200ms이내임을 확인하고, 위와 같은 전략으로 '덜그럭거림'이 없는 부드러운 경험을 제공했습니다.

따라서 무조건 스켈레톤을 보여주는것보다는 사용자의 환경과 데이터를 분석하여 선택적으로 스켈레톤을 보여주는 것이 더 나을 수 있습니다. 이렇게 사용자 경험에 대한 연구들을 통해 인사이트를 얻고 데이터를 활용한 가설 및 검증 과정을 통해 더 좋은 사용자 경험을 제공할 수 있습니다.

https://tech.kakaopay.com/post/skeleton-ui-idea/

웹사이트에서 데이터를 불러올 때, 흔히 '스켈레톤 화면'이라는 로딩 표시를 사용합니다. 하지만 이게 항상 최선의 선택은 아니라는 흥미로운 블로그 글이 있어 공유드립니다. 세계적인 UX리서치 그룹 닐슨 노먼은 1초 미만이 소요되는 항목의 경우 애니메이션을 사용하면 오히려 주의가 산만해진다고 합니다. 이유는 사용자 입장에서는 너무 짧은 시간 이기에 화면에서 어떤 일이 발생했는지 따라갈 수 없기 때문인데요. 스켈레톤 화면의 효과<ol ><li>빠른 로딩 (100ms 미만):<ul ><li>스켈레톤이 너무 빨리 사라져 화면이 '덜그럭거리는' 느낌을 줍니다.</li><li>결론: 이런 경우 스켈레톤을 보여주지 않는 것이 더 깔끔합니다.</li></ul></li><li>느린 로딩 (300ms 이상):<ul ><li>스켈레톤 화면이 유용하게 작용합니다.</li><li>사용자에게 '무언가 로딩 중'이라는 시각적 피드백을 제공합니다.</li></ul></li></ol> 카카오페이의 해결책: 지연된 스켈레톤카카오페이는 이 문제를 Suspense와 DeferredComponent라는 유틸리티 컴포넌트로 아래와 같이 해결했습니다. 200ms 까지는 빈 화면을 보여주고 이후에는 스켈레톤을 표시하는 방식인데요.<ul ><li>작동 방식:<ul ><li>0-200ms: 빈 화면 표시</li><li>200ms 이후:<ul ><li>데이터 로딩 완료 시 → 즉시 데이터 표시</li><li>데이터 로딩 중 → 스켈레톤 표시</li></ul></li></ul></li><li>예시:<ul ><li>100ms 응답: 200ms 후 바로 데이터 표시 (스켈레톤 없음)</li><li>400ms 응답: 200ms 후 스켈레톤 표시, 400ms에 데이터 표시</li></ul></li></ul> 또한 성능 모니터링 도구(Firebase)를 활용하여 실제 API 응답 시간을 분석하여 대부분의 응답시간이 200ms이내임을 확인하고, 위와 같은 전략으로 '덜그럭거림'이 없는 부드러운 경험을 제공했습니다. 따라서 무조건 스켈레톤을 보여주는것보다는 사용자의 환경과 데이터를 분석하여 선택적으로 스켈레톤을 보여주는 것이 더 나을 수 있습니다. 이렇게 사용자 경험에 대한 연구들을 통해 인사이트를 얻고 데이터를 활용한 가설 및 검증 과정을 통해 더 좋은 사용자 경험을 제공할 수 있습니다. https://tech.kakaopay.com/post/skeleton-ui-idea/

Kakaopay

스켈레톤 화면: 언제나 좋은 선택일까요?

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 이상? 그런데 이 트러블 슈팅은 컴퓨터 과학/공학의 기초가 없으면 해결하기가 어렵다.

기초 공부는 알겠다. 그럼 이 트러블 슈팅은 어떻게 배워야하나? 이제는 너무 쉽다.

AI(LLM)에게 개발을 시킨다. 거의 무조건 문제가 생기거나 완벽히 원하는대로 나오지 않는다. 어렵거나 새로운 문제일수록 그렇다. 이걸 해결해보는 과정을 많이 거쳐보면 된다.

AI에게 개발을 시킨다 -> 문제가 생긴다 & 문제를 만든다 -> 문제를 해결한다.

이 방식을 통하면 개발의 많은 과정을 이해하고 익힐 수 있다. 다만, 개발을 시키는 것도 뭘 알아야 시킬 수 있다. (서울대 강의에 썼던 방식이다)

부가적인 효과로 대화를 통해 목적을 달성해가는 스킬을 익힐 수 있고, AI의 결과가 틀릴 수 있다는 것이 몸에 새겨지므로, 늘 의심하고 확인하는 습관을 가질 수 있다.

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 이상? 그런데 이 트러블 슈팅은 컴퓨터 과학/공학의 기초가 없으면 해결하기가 어렵다. 기초 공부는 알겠다. 그럼 이 트러블 슈팅은 어떻게 배워야하나? 이제는 너무 쉽다. AI(LLM)에게 개발을 시킨다. 거의 무조건 문제가 생기거나 완벽히 원하는대로 나오지 않는다. 어렵거나 새로운 문제일수록 그렇다. 이걸 해결해보는 과정을 많이 거쳐보면 된다. AI에게 개발을 시킨다 -&gt; 문제가 생긴다 &amp; 문제를 만든다 -&gt; 문제를 해결한다. 이 방식을 통하면 개발의 많은 과정을 이해하고 익힐 수 있다. 다만, 개발을 시키는 것도 뭘 알아야 시킬 수 있다. (서울대 강의에 썼던 방식이다) 부가적인 효과로 대화를 통해 목적을 달성해가는 스킬을 익힐 수 있고, AI의 결과가 틀릴 수 있다는 것이 몸에 새겨지므로, 늘 의심하고 확인하는 습관을 가질 수 있다.

소프트웨어 개발의 80% 이상은 트러블 슈팅이다. 어쩌면 90% 

결국은 가독성이 높은 코드가 좋은 코드다. 그래야 나도 나중에 쉽게 다시 기억을 되살릴 수 있고, 다른 사람들이 쉽게 이해하고 내가 그만두거나 다른 일로 넘어갈 때 유지보수가 쉬워진다.

단 코드를 작성할 때 본인이 하는 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현을 할 수 있기 때문이다. 문제의 복잡도와 들어가는 시간에는 다른 모든 것들처럼 보통 20:80 법칙이 적용된다. 마지막 20%를 해결하는데 보통 80%의 시간을 쓰게 되기에 20%를 단순하게 해결할 방법을 생각해보는 것이 필요하며 의사 소통을 통해 문제 정의를 잘 한다면 이 부분이 쉬워진다. 내 생각을 정리해보자면

 * 가독성이 높은 단순한 코드를 작성하자 (The simpler the better). 그래야 코드 리뷰부터 시작해서 모든 것이 쉬워진다. 불필요하게 복잡한 코드를 작성하면 본인도 나중에 다시 이해하려면 고생한다.
 * 모듈화 등을 통해 유지보수가 쉬운 코드를 작성하는 것이다. 예를 들어 비슷한 코드가 게으름이나 시간 압박으로 인해 하드코드 형태로 여기저기 흩어져 있다고 하면 유지보수에 큰 어려움을 겪게 될 가능성이 높다.
 * 문제 정의를 잘하는 것이 가장 중요하며 선행되어야 한다. 하지만 주의할 점은 처음 만드는 거라면 요구 조건이 시간을 두고 바뀔 가능성이 높기에 유연하게 만들고 너무 빠르게 최적화하지 않을 필요가 있다.
 * 마지막 20%를 해결하는데 들어가는 노력이 80%임을 인지하고 이 20%의 해결방법을 단순하게 할 방법을 찾아보자.

요약하자면 "읽기 쉽고 유지보수가 쉬운 코드를 작성해서 다른 사람들과의 협업이 쉽도록 만들자"

결국은 가독성이 높은 코드가 좋은 코드다. 그래야 나도 나중에 쉽게 다시 기억을 되살릴 수 있고, 다른 사람들이 쉽게 이해하고 내가 그만두거나 다른 일로 넘어갈 때 유지보수가 쉬워진다. 단 코드를 작성할 때 본인이 하는 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현을 할 수 있기 때문이다. 문제의 복잡도와 들어가는 시간에는 다른 모든 것들처럼 보통 20:80 법칙이 적용된다. 마지막 20%를 해결하는데 보통 80%의 시간을 쓰게 되기에 20%를 단순하게 해결할 방법을 생각해보는 것이 필요하며 의사 소통을 통해 문제 정의를 잘 한다면 이 부분이 쉬워진다. 내 생각을 정리해보자면 <ul ><li>가독성이 높은 단순한 코드를 작성하자 (The simpler the better). 그래야 코드 리뷰부터 시작해서 모든 것이 쉬워진다. 불필요하게 복잡한 코드를 작성하면 본인도 나중에 다시 이해하려면 고생한다.</li><li>모듈화 등을 통해 유지보수가 쉬운 코드를 작성하는 것이다. 예를 들어 비슷한 코드가 게으름이나 시간 압박으로 인해 하드코드 형태로 여기저기 흩어져 있다고 하면 유지보수에 큰 어려움을 겪게 될 가능성이 높다.</li><li>문제 정의를 잘하는 것이 가장 중요하며 선행되어야 한다. 하지만 주의할 점은 처음 만드는 거라면 요구 조건이 시간을 두고 바뀔 가능성이 높기에 유연하게 만들고 너무 빠르게 최적화하지 않을 필요가 있다.</li><li>마지막 20%를 해결하는데 들어가는 노력이 80%임을 인지하고 이 20%의 해결방법을 단순하게 할 방법을 찾아보자.</li></ul> 요약하자면 "읽기 쉽고 유지보수가 쉬운 코드를 작성해서 다른 사람들과의 협업이 쉽도록 만들자"

좋은 코드란?

2018년 작성해 오래된 아티컬이긴하지만
그때 고민해본 실제 동작하는 MSA 아키텍트의 프레임을 공유해봅니다.

https://wiki.webnori.com/plugins/servlet/mobile?contentId=16646192#content/view/16646192

2018년 작성해 오래된 아티컬이긴하지만그때 고민해본 실제 동작하는 MSA 아키텍트의 프레임을 공유해봅니다. https://wiki.webnori.com/plugins/servlet/mobile?contentId=16646192#content/view/16646192

MSA with Spring

Java developers tend to use 'java.util.UUID#randomUUID()' API, to generate a UUID (Universally Unique Identifier) number (i.e., 'b8bbcbed-ca07-490c-8711-5118ee0af2f9'). Under certain circumstances...

Java UUID generation - Performance impact

﻿
랜덤으로 유니크한 문자열을 만들기 위해 Java.util.UUID#randomUUID() 라는 메서드를 사용해 보신 적이 있으실 겁니다. 이 글에서는 해당 메서드로 인해 시스템이 느려졌던 사례를 공유합니다.
글의 설명에 따르면, 내부 운영체제에서 entropy를 사용하여 고유번호를 생성한다고 하는데 이는 다양한 시스템의 상태 (마우스 움직임, 하드웨어 팬 소음의 변화, 장치 드라이버의 소음 변화 등)을 활용한다고 하는데요. 이때 운영체제에 이 entropy가 부족할 경우 난수 생성 속도가 느려지고 이는 애플리케이션에 영향을 준다고 합니다. 글에 나와있는 스레드 덤프 리포트를 보면 상당히 흥미로운데요.
무심코 사용하던 코드에서도 결함이 생기는 경우가 종종 있으니 특히나 외부 라이브러리를 사용할 때는 한 번쯤은 추상화되어있는 인터페이스 내부에서 어떤 식으로 돌아가는지 살펴보는 것 또한 중요해 보입니다.

https://medium.com/@RamLakshmanan/java-uuid-generation-performance-impact-cec888b7d9b8

﻿랜덤으로 유니크한 문자열을 만들기 위해 Java.util.UUID#randomUUID() 라는 메서드를 사용해 보신 적이 있으실 겁니다. 이 글에서는 해당 메서드로 인해 시스템이 느려졌던 사례를 공유합니다.글의 설명에 따르면, 내부 운영체제에서 entropy를 사용하여 고유번호를 생성한다고 하는데 이는 다양한 시스템의 상태 (마우스 움직임, 하드웨어 팬 소음의 변화, 장치 드라이버의 소음 변화 등)을 활용한다고 하는데요. 이때 운영체제에 이 entropy가 부족할 경우 난수 생성 속도가 느려지고 이는 애플리케이션에 영향을 준다고 합니다. 글에 나와있는 스레드 덤프 리포트를 보면 상당히 흥미로운데요.무심코 사용하던 코드에서도 결함이 생기는 경우가 종종 있으니 특히나 외부 라이브러리를 사용할 때는 한 번쯤은 추상화되어있는 인터페이스 내부에서 어떤 식으로 돌아가는지 살펴보는 것 또한 중요해 보입니다. https://medium.com/@RamLakshmanan/java-uuid-generation-performance-impact-cec888b7d9b8

Java UUID generation-Performance imp

토스와 애플의 조직문화인 DRI는 무엇일까? DRI를 효과적으로 도입하기 위해 꼭 알아야 할 3가지 요소(결정, 실행, 책임)에 대해 알아보겠습니다. | HR 인사이트

DRI를 도입하기 위한 필수 요소 3가지 - 진짜 나를 빛나게, 스펙터 Specter

애플은 DRI 문화를 도입한 대표적인 사례로 잘알려져있고, 국내에서는 토스가 DRI를 성공적으로 도입한 기업으로 많이 언급되고 있습니다.
DRI 조직문화 관련해서 상세하게 적힌 글이 있어 내용을 공유드립니다.

🏃🏻‍♀️ 그래서 이거 누가 담당하실 건가요?
업무를 진행하다보면 여러 사람의 손을 거쳐야 할 때가 있습니다. 이런 문제는 회사가 여러 사람이 모여 있는 '팀'이기에 발생하고, 특히 다양한 부서에서 함께 프로젝트를 진행하다 보면 의견을 공유하는 과정이 길어지기 마련입니다.
이 과정에서 누가 결정을 내릴 것인지 명확하지 않다면 의견이 엇갈리게 되고, 프로젝트는 지연될 수 밖에 없습니다. 그러다 각자 다른 업무때문에 바빠지면 '다른 누군가가 하겠지' 라는 생각에 누구도 책임을 지지 않으려는 분위기가 형성되면서 실패로 끝날 가능성이 높아집니다.
이러한 문제를 해결하기위해 DRI(Directly Responsible Individual) 개념을 도입한 회사들이 있습니다.

💁‍♂️ DRI란
특정 업무나 프로젝트의 전 과정을 책임지는 개인 (최종의사결정권자)을 의미합니다.
프로젝트의 주요한 결정과 실행, 그리고 최종 결과까지의 책임을 한 사람이 담당하도록 하여 의사결정 과정을 단순화하고, 책임 소재를 명확히 하기위해 도입된 개념입니다.
DRI의 핵심은 한 명의 책임자에게 모든 권한을 위임한다는점입니다.

📈 DRI 도입 이후 직원들에게 일어난 변화
 * 활발한 의사소통: 프로젝트의 권한을 갖는 사람이 업무의 실행 및 결과까지 책임지면서, 업무의 성공여부가 온전히 자신에게 달려있음을 인지하게 되었습니다. 더 나은 결정을 하기위해 더 많은 사람들의 의견에 귀를 기울이고, 팀원들과 활발히 소통하게 되었습니다.
 * 전체 성과 향상: DRI를 통해 모든 구성원이 자신이 맡은 업무와 목표를 더욱 명확하게 이해하게 되었고, 상호 협력할 수 있는 환경이 조성되었습니다. 또한 구체적인 목표를 설정과 함께 책임감이 강화되면서 불필요한 업무에 시간을 낭비하지 않고 더 효율적으로 일할 수 있게 되었습니다.

🏄🏻‍♂️ DRI를 구성하는 요소
 * 결정: DRI는 프로젝트에서 주요한 결정을 내리는 역할을 합니다. 최선의 합리적인 결정을 내리기 위해 정보를 수집하고 분석하며, 필요한 모든 자원을 고려해야 합니다.
 * 실행: DRI는 결정된 사항을 실행하는 것 또한 본인의 주도 하에 진행됩니다. 이 단계에서 자원을 효과적으로 관리하고, 인력을 적절히 배치하며 프로젝트가 계획대로 진행될 수 있도록 모든 과정에 관여합니다.
 * 책임: DRI는 결과가 좋든 나쁘든 그에 따른 모든 책임을 집니다. 결과가 무조건 성공적이어야 한다는 것에 초점을 두는 것이 아닌, 맡고 있는 프로젝트의 처음부터 끝까지 누락된 것은 없는지 살피고, 레슨런을 통해 실패에서 성공을, 성공에서 더 큰 성공을 이루어내기 위해 고민하는 것이 필요합니다.

🎁 DRI 조직 문화를 만들기 위한 필수사항
 * 신뢰와 피드백: DRI는 조직 내 사람들의 의견을 경청하고, 합리적으로 설득할 수 있어야합니다. 피드백을 주고 받을 때에도 신뢰를 바탕으로 '공동의 목표를 달성하기 위해 협력하는 과정'이라는 것을 인지할 수 있어야 합니다.
 * 수평적 의사소통: 팀원들의 다양한 시각이 결합될 때 더 나은 의사결정과 혁신적인 해결책이 도출됩니다. 수평적 의사소통은 또한 팀원들이 서로의 강점과 약점을 이해하고 협력할 수 있는 기회를 제공합니다.
 * DRI형 리더십을 가진 직책자: 프로젝트의 성공 여부는 DRI 개인의 역량과 자질에 의해 크게 좌우됩니다. 기업에 DRI문화를 효과적으로 도입하는 방법은 DRI형 리더십이 있는 직책자가 조직 전체에 퍼뜨리는 것입니다.

애플은 DRI 문화를 도입한 대표적인 사례로 잘알려져있고, 국내에서는 토스가 DRI를 성공적으로 도입한 기업으로 많이 언급되고 있습니다.DRI 조직문화 관련해서 상세하게 적힌 글이 있어 내용을 공유드립니다. 🏃🏻‍♀️ 그래서 이거 누가 담당하실 건가요?업무를 진행하다보면 여러 사람의 손을 거쳐야 할 때가 있습니다. 이런 문제는 회사가 여러 사람이 모여 있는 '팀'이기에 발생하고, 특히 다양한 부서에서 함께 프로젝트를 진행하다 보면 의견을 공유하는 과정이 길어지기 마련입니다.이 과정에서 누가 결정을 내릴 것인지 명확하지 않다면 의견이 엇갈리게 되고, 프로젝트는 지연될 수 밖에 없습니다. 그러다 각자 다른 업무때문에 바빠지면 '다른 누군가가 하겠지' 라는 생각에 누구도 책임을 지지 않으려는 분위기가 형성되면서 실패로 끝날 가능성이 높아집니다.이러한 문제를 해결하기위해 DRI(Directly Responsible Individual) 개념을 도입한 회사들이 있습니다. 💁‍♂️ DRI란특정 업무나 프로젝트의 전 과정을 책임지는 개인 (최종의사결정권자)을 의미합니다.프로젝트의 주요한 결정과 실행, 그리고 최종 결과까지의 책임을 한 사람이 담당하도록 하여 의사결정 과정을 단순화하고, 책임 소재를 명확히 하기위해 도입된 개념입니다.DRI의 핵심은 한 명의 책임자에게 모든 권한을 위임한다는점입니다. 📈 DRI 도입 이후 직원들에게 일어난 변화<ul ><li>활발한 의사소통: 프로젝트의 권한을 갖는 사람이 업무의 실행 및 결과까지 책임지면서, 업무의 성공여부가 온전히 자신에게 달려있음을 인지하게 되었습니다. 더 나은 결정을 하기위해 더 많은 사람들의 의견에 귀를 기울이고, 팀원들과 활발히 소통하게 되었습니다. </li><li>전체 성과 향상: DRI를 통해 모든 구성원이 자신이 맡은 업무와 목표를 더욱 명확하게 이해하게 되었고, 상호 협력할 수 있는 환경이 조성되었습니다. 또한 구체적인 목표를 설정과 함께 책임감이 강화되면서 불필요한 업무에 시간을 낭비하지 않고 더 효율적으로 일할 수 있게 되었습니다.</li></ul> 🏄🏻‍♂️ DRI를 구성하는 요소<ul ><li>결정: DRI는 프로젝트에서 주요한 결정을 내리는 역할을 합니다. 최선의 합리적인 결정을 내리기 위해 정보를 수집하고 분석하며, 필요한 모든 자원을 고려해야 합니다.</li><li>실행: DRI는 결정된 사항을 실행하는 것 또한 본인의 주도 하에 진행됩니다. 이 단계에서 자원을 효과적으로 관리하고, 인력을 적절히 배치하며 프로젝트가 계획대로 진행될 수 있도록 모든 과정에 관여합니다. </li><li>책임: DRI는 결과가 좋든 나쁘든 그에 따른 모든 책임을 집니다. 결과가 무조건 성공적이어야 한다는 것에 초점을 두는 것이 아닌, 맡고 있는 프로젝트의 처음부터 끝까지 누락된 것은 없는지 살피고, 레슨런을 통해 실패에서 성공을, 성공에서 더 큰 성공을 이루어내기 위해 고민하는 것이 필요합니다.</li></ul> 🎁 DRI 조직 문화를 만들기 위한 필수사항<ul ><li>신뢰와 피드백: DRI는 조직 내 사람들의 의견을 경청하고, 합리적으로 설득할 수 있어야합니다. 피드백을 주고 받을 때에도 신뢰를 바탕으로 '공동의 목표를 달성하기 위해 협력하는 과정'이라는 것을 인지할 수 있어야 합니다.</li><li>수평적 의사소통: 팀원들의 다양한 시각이 결합될 때 더 나은 의사결정과 혁신적인 해결책이 도출됩니다. 수평적 의사소통은 또한 팀원들이 서로의 강점과 약점을 이해하고 협력할 수 있는 기회를 제공합니다. </li><li>DRI형 리더십을 가진 직책자: 프로젝트의 성공 여부는 DRI 개인의 역량과 자질에 의해 크게 좌우됩니다. 기업에 DRI문화를 효과적으로 도입하는 방법은 DRI형 리더십이 있는 직책자가 조직 전체에 퍼뜨리는 것입니다. </li></ul>

Specter

토스와 애플 조직문화 DRI

01 . 황정민 배우님의 동생이자 유명한 영화음악 감독이기도 한 황상준 감독님이 얼마 전 유퀴즈에 출연하셔서 이런 말씀을 하셨습니다.
"우리 같은 사람들은 기회가 있을 때 잘하는 게 아니라 늘 잘해야 한다."
그리고 공교롭게 얼마 지나지 않아 출연한 차승원 배우님은 또 이런 이야기를 풀어 놓았죠.
"경쟁력이라는 것도 사실 50점 이하면 안 된다. 필요한 여러 자질들에서 최소한 50점은 되어야 그때부터 의미가 생긴다."

02 . 두 분의 이야기를 종합해 보자면 이렇게 요약할 수 있을 겁니다. '적어도 자신의 성과를 다른 사람에게 선보이고 이를 통해 수익을 창출하는 사람이라면, 늘 꾸준히 잘해야 하며 그 퀄리티는 일반적인 기준을 우회해야 한다'라고 말입니다.
그리고 이렇게 정리하고 나니 살짝 오싹해지기도 합니다. 꼭 배우나 제작자가 아니더라도 우리 같은 회사원들 역시도 똑같은 기준을 적용받고 사는 존재들이라는 게 더욱 명확해지니 말입니다.

03 . 물론 그들도, 우리도 수많은 실패를 합니다. 연예인들이라고 매번 히트작을 낼 수는 없는 것처럼 회사에서 하는 공동 업무나 개인적으로 일구는 사업 혹은 과제들 역시 성공보단 실패의 확률이 훨씬 크기 때문이죠. 그래서 가끔은 '세상은 참 가혹한 환경인데도 사람들은 이 가혹함을 인생이라고 정의하며 살고 있구나'하는 생각이 들 때도 있습니다.

04 . 하지만 '잘한다'는 기준에 대해 조금만 생각해 보면 내부로부터의 평가와 외부로부터의 평가가 각각 존재한다는 사실을 발견할 수 있습니다. 대중이나 소비자처럼 우리가 선보이는 결과물을 평가해 줄 집단이 있나 하면, 반대로 그 결과물까지 어떻게 도달했나를 평가해 줄 내부의 동료들과 관계자들이 있으니 말이죠. 전자가 결과의 평가라면 후자는 과정의 평가라고도 볼 수 있겠네요.

05 . 그리고 이 지점에서 또 하나의 고민이 고개를 듭니다. 그럼 우리는 이 각각의 평가단(?)을 어떻게 관리해야 하며, '잘한다'는 기준을 들이밀었을 땐 이 두 평가단으로부터 어떤 평가를 끌어내는 것이 '잘한다'의 의미인 것인지 알쏭달쏭함이 꼬리를 물고 이어지기 때문입니다. 성과는 기가 막히게 뽑아내지만 그 누구에게도 환영받지 못하는 캐릭터가 있고, 성실한 태도와 모자람 없는 실력을 갖췄음에도 유독 성과로 이어지는 그 연결고리가 약한 사람이 있으니까요, 아마 지금 여러분의 머릿속에도 몇몇 사람들이 마치 O, X 게임을 하듯 편을 나눠 양쪽에 선 모습이 그려질 겁니다.

06 . 누가 더 낫다, 아니다를 평가할 수 없다는 건 여러분도 잘 아실 겁니다. 이건 애초에 두부 자르듯 정확하게 가를 수 없는 문제고 파고 내려가다 보면 결국 개인의 스타일과 선호의 문제로 이어질 가능성이 크기 때문입니다.
다만 만약 누군가 제게 '이런 모든 상황을 감안했을 때 늘, 꾸준히, 기본 이상 잘한다는 건 어떤 의미일까요?'라고 묻는다면 저는 이렇게 대답할 것도 같습니다.
"50 이상을 유지하기 위해서는 나만의 기준이 있어야 하고, 늘 꾸준히 잘하기 위해서는 나만의 방법이 있어야 한다"라고 말입니다.

07 . 이에 대해 황상준 감독님과 차승원 배우님은 각각 이런 말을 들려주셨습니다.
"매일 아침 일어나서 정해진 시간에 음악을 만든다. 그게 꾸준히 잘할 수 있게 해주는 것 같다"라는 말과 "우리 같은 직업은 경쟁력 있는 실력, 경쟁력 있는 가격, 경쟁력 있는 인품, 경쟁력 있는 외형이 필요한데 그중 두 가지만 적절히 조합돼도 괜찮게 인정을 받는다. 나는 경쟁력 있는 가격과 인품이 나를 유지하는 방법이다."라는 말이었죠.

08 . 제 생각도 마찬가지입니다. 일단 대부분 스스로 전문성을 가진 분야는 시간이 지남에 따라 점점 실력이 늘어나고 통찰력 또한 깊어질 거라 생각하지만 꼭 그런 것만은 아닙니다. 당장 어제 통용되던 문법이 오늘은 전혀 통하지 않는 시대가 작금의 현실이고, 어느 분야를 막론하고 늘 나보다 더 나은 사람, 더 경험이 많은 사람은 존재하는 법이니 그들을 뛰어넘을 미친 듯한 경쟁력이 없는 이상 적어도 기본 이상을 해낼 수 있는 나만의 기준 하나쯤은 가지고 있어야 합니다. 그래야 새로운 세상이 다가오고 더 잘하는 사람이 등장해도 '내가 지금 무엇을 더 하고, 덜 해야 하나'를 판단할 수 있기 때문이죠.

09 . 더불어 꾸준히 잘하기 위해서는 내 역량을 풀어내는 나만의 방법이 있어야 합니다. 잘하고 싶은 마음이 굴뚝같아도, 언젠가 쌓이고 쌓인 역량이 '팡'하고 터지는 대기만성의 그날을 기약한다고 해도, 누군가의 평가를 받아야 하는 존재들은 일단 눈앞의 있는 것들을 비교적 잘 해내야 합니다. 때문에 내가 나를 잘 이해해야 하고, 내가 나를 잘 활용할 수 있는 힘을 기르지 않고는 꾸준한 퀄리티를 유지하기는 힘듭니다. 시간이 지날수록 나에 대한 정보들이 나에게 잘 유입되고 처리되도록 하는 것이 엄청난 경쟁력이 되는 이유죠.

10 . 말은 이렇게 했지만 꾸준히, 일정 이상 잘한다는 건 정말정말 어려운 일입니다. 그럼에도 이런 이야기를 글로 한 번 풀어본 가장 중요한 이유는 세상 모두가 내 사정을 속속들이 이해해 주진 않는다는 것이고, 한 번 삐끗하는 것만으로도 다시 기회가 주어지지 않는 꽤 쌀쌀맞은 로직이 동작하는 게 현실이기 때문입니다. 그러니 어쩌겠습니까. 달콤한 말로 위로해 줄 수 없는 순간이라면 덤덤하게 삼켜내기를 택해야 할 때도 있는 거죠. 그래도 한가지 희망적인 것은 이런 고민을 하고 사는 것과 하지 않고 사는 것부터 이미 조금씩 차이를 보이기 시작한다는 겁니다. 그런 의미에서 우리는 늘, 꾸준히, 일정 이상 잘하는 방법을 향해 안테나 정도는 세운 셈인지도 모르겠네요.

01 . 황정민 배우님의 동생이자 유명한 영화음악 감독이기도 한 황상준 감독님이 얼마 전 유퀴즈에 출연하셔서 이런 말씀을 하셨습니다. "우리 같은 사람들은 기회가 있을 때 잘하는 게 아니라 늘 잘해야 한다." 그리고 공교롭게 얼마 지나지 않아 출연한 차승원 배우님은 또 이런 이야기를 풀어 놓았죠. "경쟁력이라는 것도 사실 50점 이하면 안 된다. 필요한 여러 자질들에서 최소한 50점은 되어야 그때부터 의미가 생긴다." 02 . 두 분의 이야기를 종합해 보자면 이렇게 요약할 수 있을 겁니다. '적어도 자신의 성과를 다른 사람에게 선보이고 이를 통해 수익을 창출하는 사람이라면, 늘 꾸준히 잘해야 하며 그 퀄리티는 일반적인 기준을 우회해야 한다'라고 말입니다. 그리고 이렇게 정리하고 나니 살짝 오싹해지기도 합니다. 꼭 배우나 제작자가 아니더라도 우리 같은 회사원들 역시도 똑같은 기준을 적용받고 사는 존재들이라는 게 더욱 명확해지니 말입니다. 03 . 물론 그들도, 우리도 수많은 실패를 합니다. 연예인들이라고 매번 히트작을 낼 수는 없는 것처럼 회사에서 하는 공동 업무나 개인적으로 일구는 사업 혹은 과제들 역시 성공보단 실패의 확률이 훨씬 크기 때문이죠. 그래서 가끔은 '세상은 참 가혹한 환경인데도 사람들은 이 가혹함을 인생이라고 정의하며 살고 있구나'하는 생각이 들 때도 있습니다. 04 . 하지만 '잘한다'는 기준에 대해 조금만 생각해 보면 내부로부터의 평가와 외부로부터의 평가가 각각 존재한다는 사실을 발견할 수 있습니다. 대중이나 소비자처럼 우리가 선보이는 결과물을 평가해 줄 집단이 있나 하면, 반대로 그 결과물까지 어떻게 도달했나를 평가해 줄 내부의 동료들과 관계자들이 있으니 말이죠. 전자가 결과의 평가라면 후자는 과정의 평가라고도 볼 수 있겠네요. 05 . 그리고 이 지점에서 또 하나의 고민이 고개를 듭니다. 그럼 우리는 이 각각의 평가단(?)을 어떻게 관리해야 하며, '잘한다'는 기준을 들이밀었을 땐 이 두 평가단으로부터 어떤 평가를 끌어내는 것이 '잘한다'의 의미인 것인지 알쏭달쏭함이 꼬리를 물고 이어지기 때문입니다. 성과는 기가 막히게 뽑아내지만 그 누구에게도 환영받지 못하는 캐릭터가 있고, 성실한 태도와 모자람 없는 실력을 갖췄음에도 유독 성과로 이어지는 그 연결고리가 약한 사람이 있으니까요, 아마 지금 여러분의 머릿속에도 몇몇 사람들이 마치 O, X 게임을 하듯 편을 나눠 양쪽에 선 모습이 그려질 겁니다. 06 . 누가 더 낫다, 아니다를 평가할 수 없다는 건 여러분도 잘 아실 겁니다. 이건 애초에 두부 자르듯 정확하게 가를 수 없는 문제고 파고 내려가다 보면 결국 개인의 스타일과 선호의 문제로 이어질 가능성이 크기 때문입니다. 다만 만약 누군가 제게 '이런 모든 상황을 감안했을 때 늘, 꾸준히, 기본 이상 잘한다는 건 어떤 의미일까요?'라고 묻는다면 저는 이렇게 대답할 것도 같습니다. "50 이상을 유지하기 위해서는 나만의 기준이 있어야 하고, 늘 꾸준히 잘하기 위해서는 나만의 방법이 있어야 한다"라고 말입니다. 07 . 이에 대해 황상준 감독님과 차승원 배우님은 각각 이런 말을 들려주셨습니다. "매일 아침 일어나서 정해진 시간에 음악을 만든다. 그게 꾸준히 잘할 수 있게 해주는 것 같다"라는 말과 "우리 같은 직업은 경쟁력 있는 실력, 경쟁력 있는 가격, 경쟁력 있는 인품, 경쟁력 있는 외형이 필요한데 그중 두 가지만 적절히 조합돼도 괜찮게 인정을 받는다. 나는 경쟁력 있는 가격과 인품이 나를 유지하는 방법이다."라는 말이었죠. 08 . 제 생각도 마찬가지입니다. 일단 대부분 스스로 전문성을 가진 분야는 시간이 지남에 따라 점점 실력이 늘어나고 통찰력 또한 깊어질 거라 생각하지만 꼭 그런 것만은 아닙니다. 당장 어제 통용되던 문법이 오늘은 전혀 통하지 않는 시대가 작금의 현실이고, 어느 분야를 막론하고 늘 나보다 더 나은 사람, 더 경험이 많은 사람은 존재하는 법이니 그들을 뛰어넘을 미친 듯한 경쟁력이 없는 이상 적어도 기본 이상을 해낼 수 있는 나만의 기준 하나쯤은 가지고 있어야 합니다. 그래야 새로운 세상이 다가오고 더 잘하는 사람이 등장해도 '내가 지금 무엇을 더 하고, 덜 해야 하나'를 판단할 수 있기 때문이죠. 09 . 더불어 꾸준히 잘하기 위해서는 내 역량을 풀어내는 나만의 방법이 있어야 합니다. 잘하고 싶은 마음이 굴뚝같아도, 언젠가 쌓이고 쌓인 역량이 '팡'하고 터지는 대기만성의 그날을 기약한다고 해도, 누군가의 평가를 받아야 하는 존재들은 일단 눈앞의 있는 것들을 비교적 잘 해내야 합니다. 때문에 내가 나를 잘 이해해야 하고, 내가 나를 잘 활용할 수 있는 힘을 기르지 않고는 꾸준한 퀄리티를 유지하기는 힘듭니다. 시간이 지날수록 나에 대한 정보들이 나에게 잘 유입되고 처리되도록 하는 것이 엄청난 경쟁력이 되는 이유죠. 10 . 말은 이렇게 했지만 꾸준히, 일정 이상 잘한다는 건 정말정말 어려운 일입니다. 그럼에도 이런 이야기를 글로 한 번 풀어본 가장 중요한 이유는 세상 모두가 내 사정을 속속들이 이해해 주진 않는다는 것이고, 한 번 삐끗하는 것만으로도 다시 기회가 주어지지 않는 꽤 쌀쌀맞은 로직이 동작하는 게 현실이기 때문입니다. 그러니 어쩌겠습니까. 달콤한 말로 위로해 줄 수 없는 순간이라면 덤덤하게 삼켜내기를 택해야 할 때도 있는 거죠. 그래도 한가지 희망적인 것은 이런 고민을 하고 사는 것과 하지 않고 사는 것부터 이미 조금씩 차이를 보이기 시작한다는 겁니다. 그런 의미에서 우리는 늘, 꾸준히, 일정 이상 잘하는 방법을 향해 안테나 정도는 세운 셈인지도 모르겠네요.

늘, 꾸준히, 일정 기준 이상으로 '잘하기'

An overview of Go syntax and features. Contribute to a8m/golang-cheat-sheet development by creating an account on GitHub.

GitHub - a8m/golang-cheat-sheet: An overview of Go syntax and features.

Golang을 한번 훓었는데 까먹었거나,
책한권 보는 것은 귀찮으신 분은 이거 참고하시면 될 것 같습니다.
목차가 아주 알차네요~

- Basic Syntax (기본 문법)
- Operators (연산자)
- Declarations (선언)
- Functions (함수)
- Built-in Types (내장 타입)
- Type Conversions (타입 변환)
- Packages (패키지)
- Control structures (제어 구조)
- Arrays, Slices, Ranges (배열, 슬라이스, 범위)
- Maps (맵)
- Structs (구조체)
- Pointers (포인터)
- Interfaces (인터페이스)
- Embedding (임베딩)
- Errors (오류 처리)
- Concurrency (동시성)
- Printing (출력)
- Reflection (리플렉션)
- Snippets (코드 스니펫)

https://github.com/a8m/golang-cheat-sheet/tree/master

Golang을 한번 훓었는데 까먹었거나,책한권 보는 것은 귀찮으신 분은 이거 참고하시면 될 것 같습니다.목차가 아주 알차네요~ - Basic Syntax (기본 문법)- Operators (연산자)- Declarations (선언)- Functions (함수)- Built-in Types (내장 타입)- Type Conversions (타입 변환)- Packages (패키지)- Control structures (제어 구조)- Arrays, Slices, Ranges (배열, 슬라이스, 범위)- Maps (맵)- Structs (구조체)- Pointers (포인터)- Interfaces (인터페이스)- Embedding (임베딩)- Errors (오류 처리)- Concurrency (동시성)- Printing (출력)- Reflection (리플렉션)- Snippets (코드 스니펫) https://github.com/a8m/golang-cheat-sheet/tree/master

GitHub

Golang 치트 시트

1
스티브 잡스는 매일 아침 거울 앞에서 스스로에게 물었다. 오늘이 내 삶의 마지막 날이라면, 지금 이 일을 계속할 거냐고.

2
모멘토 모리. 죽음을 기억하라. 죽음은 인간이 만든 최고의 발명품이다. 그 누구도 예외 없다. 사람은 모두 죽는다. 사람의 시간은 유한하다.

3
그럼에도 우리는 시간을 무한한 자원처럼 다룬다. 눈에 보이지 않기 때문이다. 한 시간, 하루, 한 달. 보이지 않는 시간을 단위로 개념화했다. 그럼에도 시간은 잘 와닿지 않는다.

4
우선순위는 보이지 시간에 대한 결정이다. 한정된 시간을 어디에 쓸 것인가. 사람의 삶과 마찬가지로 기업에게도 가장 중요하다.

5
텅 빈 투명한 통이 있다. 여기 다양한 크기의 돌멩이를 담는다. 통은 시간이다. 돌멩이는 우리가 시간을 쓰는 일이다.

6
돌의 크기는 저마다 다르다. 크기는 중요도와 비례한다고 하자. 어떤 걸 먼저 담아야 같은 통에 가장 많은 돌을 채울 수 있을까? 쉽다. 큰 돌을 먼저 담은 다음, 나머지 공간을 작은 돌로 채운다. 가장 밀도가 높다. 시간을 효율적으로 쓴 셈이다.

7
순서를 거꾸로 한다면 어떻게 될까? 작은 돌들을 먼저 채운다. 나중에 큰 돌을 담아본다. 몇 개 들어가지 않는다. 많은 작은 돌들이 이미 꽉 차버렸으니까. 큰일이다. 그래도 돌멩이는 쏟고 다시 담으면 된다. 하지만, 써버린 시간은 되돌릴 수 없다.

8
부와 성공을 이룬 사람은 돈으로 최대한 시간을 산다. 중요하지 않은 결정은 시간을 안 쓴다. 매일 같은 옷을 입고, 같은 식단을 먹는다.

9
기업도 마찬가지다. 기업의 시간은 구성원의 시간이다. 구성원의 수만큼 시간이 있는 셈이다.

10
기업의 시간을 늘리는 방법은 두 가지다. 채용을 해서 구성원의 수를 늘리면 된다. 빠르게 시간을 늘릴 수 있다. 하지만 감당해야 할 대가가 매우 크다. 되돌리기 어려운 결정이다.

11
다른 방법은 시간 사용을 효율화하는 것이다. 높은 역량이 있는 사람을 채용한다. 성과를 내는 과정을 효율화한다.

12
'어떤 일을 할 시간이 없다'라는 말은 사실 '그 일은 우선순위에 없다'라는 말과 같다. 최악은 내가 가진 돌멩이에 우선순위가 없는 것이다. 이 돌, 저 돌 건드리다 결국 하나도 제대로 해내지 못한다. 흐지부지 시간은 계속 흐른다.

13
모래시계처럼 우리의 남은 시간을 눈으로 볼 수 있다면 얼마나 좋을까. 조금은 더 효율적으로 살 수 있지 않을까.

14
시각은 뇌가 다루는 감각의 90%를 차지한다. 그래서 우리는 눈에 안 보이는 걸 덜 중요하게 여긴다.

15
시간, 결정, 건강, 관계. 살면서 점점 더 중요한 것들은 눈에 보이지 않는다는 것을 깨닫는다. 무의식의 흐름대로 살다가도 문득문득 멈춰서 다시 챙겨 본다. 나는 지금 보이지 않는 것들을 잘 챙겨가고 있을까.

1 스티브 잡스는 매일 아침 거울 앞에서 스스로에게 물었다. 오늘이 내 삶의 마지막 날이라면, 지금 이 일을 계속할 거냐고. ​ ​2 모멘토 모리. 죽음을 기억하라. 죽음은 인간이 만든 최고의 발명품이다. 그 누구도 예외 없다. 사람은 모두 죽는다. 사람의 시간은 유한하다. ​ ​3 그럼에도 우리는 시간을 무한한 자원처럼 다룬다. 눈에 보이지 않기 때문이다. 한 시간, 하루, 한 달. 보이지 않는 시간을 단위로 개념화했다. 그럼에도 시간은 잘 와닿지 않는다. ​ ​4 우선순위는 보이지 시간에 대한 결정이다. 한정된 시간을 어디에 쓸 것인가. 사람의 삶과 마찬가지로 기업에게도 가장 중요하다. ​ ​5 텅 빈 투명한 통이 있다. 여기 다양한 크기의 돌멩이를 담는다. 통은 시간이다. 돌멩이는 우리가 시간을 쓰는 일이다. ​ ​6 돌의 크기는 저마다 다르다. 크기는 중요도와 비례한다고 하자. 어떤 걸 먼저 담아야 같은 통에 가장 많은 돌을 채울 수 있을까? 쉽다. 큰 돌을 먼저 담은 다음, 나머지 공간을 작은 돌로 채운다. 가장 밀도가 높다. 시간을 효율적으로 쓴 셈이다. ​7 순서를 거꾸로 한다면 어떻게 될까? 작은 돌들을 먼저 채운다. 나중에 큰 돌을 담아본다. 몇 개 들어가지 않는다. 많은 작은 돌들이 이미 꽉 차버렸으니까. 큰일이다. 그래도 돌멩이는 쏟고 다시 담으면 된다. 하지만, 써버린 시간은 되돌릴 수 없다. ​8 부와 성공을 이룬 사람은 돈으로 최대한 시간을 산다. 중요하지 않은 결정은 시간을 안 쓴다. 매일 같은 옷을 입고, 같은 식단을 먹는다. ​ ​9 기업도 마찬가지다. 기업의 시간은 구성원의 시간이다. 구성원의 수만큼 시간이 있는 셈이다. ​ ​10 기업의 시간을 늘리는 방법은 두 가지다. 채용을 해서 구성원의 수를 늘리면 된다. 빠르게 시간을 늘릴 수 있다. 하지만 감당해야 할 대가가 매우 크다. 되돌리기 어려운 결정이다. ​ ​11 다른 방법은 시간 사용을 효율화하는 것이다. 높은 역량이 있는 사람을 채용한다. 성과를 내는 과정을 효율화한다. ​ ​12 '어떤 일을 할 시간이 없다'라는 말은 사실 '그 일은 우선순위에 없다'라는 말과 같다. 최악은 내가 가진 돌멩이에 우선순위가 없는 것이다. 이 돌, 저 돌 건드리다 결국 하나도 제대로 해내지 못한다. 흐지부지 시간은 계속 흐른다. ​ ​13 모래시계처럼 우리의 남은 시간을 눈으로 볼 수 있다면 얼마나 좋을까. 조금은 더 효율적으로 살 수 있지 않을까. ​ ​14 시각은 뇌가 다루는 감각의 90%를 차지한다. 그래서 우리는 눈에 안 보이는 걸 덜 중요하게 여긴다. ​ ​15 시간, 결정, 건강, 관계. 살면서 점점 더 중요한 것들은 눈에 보이지 않는다는 것을 깨닫는다. 무의식의 흐름대로 살다가도 문득문득 멈춰서 다시 챙겨 본다. 나는 지금 보이지 않는 것들을 잘 챙겨가고 있을까.

< 죽음을 기억하라. 중요한 것들은 눈에 보이지 않는다 >

때론 용감하고 과감하고 무모한 방법이 기회를 가져다주시고 한다 | 전 글(B2B세일즈, 고객의 언어를 꼭 찾아보세요!)에서도 언급드렸듯이, 저와 공동 창업자는 해외 대학 재학생이었고 기업 경험도 전혀 없어서 B2B 세일즈를 시작하기에 적합하지 않은 역량을 가진 창업자였다고 해도 과언이 아닙니다. 이런 상황에서 저희가 어떻게 초기 B2B 세일즈를 시작해 나갔는지에 대해 이야기하고자 합니다.

초기 세일즈, 때론 용감하고 과감하고 무모하게

저는 세일즈 직무를 담당해 본 적은 없지만, 주변에서 영업을 잘 하는 친구들을 보면 늘 감탄하곤 했는데요. 영업에 대해 가지는 일반적인 이미지(?)와는 달리 굉장히 전략적이고, 꼼꼼하고 + 거기에 대담하고 빠른 실행력을 갖춘 경우를 많이 봤습니다. 특히 여러 번의 거절에도 위축되지 않고, 꾸준히 시간을 들이며 작은 성공을 쌓아가더라구요. 공유하는 글에서도 B2B 세일즈의 초기 모습이 나오는데, 솔직하면서도 인상적인 글입니다.

저는 세일즈 직무를 담당해 본 적은 없지만, 주변에서 영업을 잘 하는 친구들을 보면 늘 감탄하곤 했는데요. 영업에 대해 가지는 일반적인 이미지(?)와는 달리 굉장히 전략적이고, 꼼꼼하고 + 거기에 대담하고 빠른 실행력을 갖춘 경우를 많이 봤습니다. 특히 여러 번의 거절에도 위축되지 않고, 꾸준히 시간을 들이며 작은 성공을 쌓아가더라구요. 공유하는 글에서도 B2B 세일즈의 초기 모습이 나오는데, 솔직하면서도 인상적인 글입니다.

Brunch Story

삼성전자 소프트웨어 엔지니어

새나라씨

스트라 대표

김용호

DB Designer & SQLer

김도열

[초기 세일즈, 때론 용감하고 과감하고 무모하게]

데이터 분석

• 데이터 분석환경 구축, 마트 모델링
• 실험 설계 및 결과 분석
• 핵심지표 정의 및 대시보드 관리

Data Lead

• 네이버 검색히스토리 서비스
• 네이버 지도 UI개편 
• 네이버 통합검색 UI전면개편
• 네이버 통합검색 사용자리서치 
• 네이버 모바일 통합검색 UI 및 모델링 개편
• 네이버 통합검색 추천검색어 영역 버킷테스트 

UX Researcher

• 서비스 핵심지표 관리 및 데이터 분석
• 크로스셀 활성화 전략수립 및 관련 기능개선
• 퍼포먼스, 컨텐츠, CRM 마케팅 관리

Growth Lead

• 이음 서비스 기획 및 운영 총괄
• 이음 서비스 어드민 & 지표 모니터링 시스템 구축
• 서비스 로직 및 매칭알고리즘 설계, 데이터분석 및 리포팅, 운영정책 셋업
• 모바일앱 / 웹 / 관리자 어드민 기획 및 UX화면설계

Product Lead

• T전화 서비스기획(검색, T114, 안심통화)
• 전화번호 DB 수집/관리 체계 구축, 관련 운영프로세스 및 관리툴 기획
• T연락처 서비스기획

Product Manager

인지과학/HCI

심리학

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

양승화

그로스해킹 강의

개인 홈페이지

블로그

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

https://bit.ly/leoyang6

[초기 세일즈, 때론 용감하고 과감하고 무모하게]

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필