1
대단한 아이디어는 협업에서 탄생하기도 하지만, 혜안을 지닌 한 사람이 올바른 방향으로 이끌어주고 목표를 분명하게 제시할 때 나온다. 

 
 
2
다양성은 성공을 가능케하는 최상의 조합을 만들어내지만 그 조합이 제 실력을 발휘하려면 지도자가 필요하다.

 
 
3
프로그래밍 분야에서 팀이 성공할수록 결과물에 기여한 바는 한 사람에게 쏠린다. 한 사람의 지도자가 부상해 결정을 내리고 프로그래밍 업무 대부분을 처리하기 때문이다. 

 
 
4
물론 동료들도 중요한 역할을 하기는 한다. 핵심적인 전문 지식을 제공하고 허점을 메워준다. 

 
 
5
그러나 지도자는 개개인이 범하는 실수를 바로 잡고 수준 미달인 결과들은 퇴짜를 놓고 최종적 결과물이 자신이 생각하는 모습과 기준을 충족시키는지 확인하면서 프로젝트의 전체적인 모습을 그려간다.

 
 
#성공의공식포뮬러 #앨버트라슬로바라바시 
#하루한문장📚

1대단한 아이디어는 협업에서 탄생하기도 하지만, 혜안을 지닌 한 사람이 올바른 방향으로 이끌어주고 목표를 분명하게 제시할 때 나온다.&nbsp; &nbsp;&nbsp;2다양성은 성공을 가능케하는 최상의 조합을 만들어내지만 그 조합이 제 실력을 발휘하려면 지도자가 필요하다. &nbsp;&nbsp;3프로그래밍 분야에서 팀이 성공할수록 결과물에 기여한 바는 한 사람에게 쏠린다. 한 사람의 지도자가 부상해 결정을 내리고 프로그래밍 업무 대부분을 처리하기 때문이다.&nbsp; &nbsp;&nbsp;4물론 동료들도 중요한 역할을 하기는 한다. 핵심적인 전문 지식을 제공하고 허점을 메워준다.&nbsp; &nbsp;&nbsp;5그러나 지도자는 개개인이 범하는 실수를 바로 잡고 수준 미달인 결과들은 퇴짜를 놓고 최종적 결과물이 자신이 생각하는 모습과 기준을 충족시키는지 확인하면서 프로젝트의 전체적인 모습을 그려간다. &nbsp;&nbsp;#성공의공식포뮬러 #앨버트라슬로바라바시&nbsp;#하루한문장📚

<팀은 중요하다. 하지만 팀이 실력을 발휘하려면 지도자는 더 중요하다>

카카오의 새 컨트롤타워 CA협의체에서 경영지원총괄을 맡은 김정호 브라이언임팩트 이사장이 카카오의 내부비리 폭로에 나섰습니다. 오늘(28일) 김 총괄은 자신의 소셜미디어(SNS)에 연달아 글을 올려 카카오의 인사·재무

카카오 컨트롤타워 김정호 총괄, 내부 경영실태 폭로

김 위원장이 경영 일선에 전면에 나섰지만 비상경영체제에도 내부 비리가 폭로되면서 카카오의 쇄신 속도와 강도는 더욱 강해질 전망입니다. 어제(27일) 열린 카카오 5차 공동체 경영회의에서 김 위원장은 "전 공동체 차원에서 준법·인사·재무 등 측면에서 밀착 관리할 수 있는 방향으로 제도를 개편하기를 강력히 권고한다"고 밝힌 바 있습니다.

https://n.news.naver.com/article/374/0000360574?sid=101

김 위원장이 경영 일선에 전면에 나섰지만 비상경영체제에도 내부 비리가 폭로되면서 카카오의 쇄신 속도와 강도는 더욱 강해질 전망입니다. 어제(27일) 열린 카카오 5차 공동체 경영회의에서 김 위원장은 "전 공동체 차원에서 준법·인사·재무 등 측면에서 밀착 관리할 수 있는 방향으로 제도를 개편하기를 강력히 권고한다"고 밝힌 바 있습니다. https://n.news.naver.com/article/374/0000360574?sid=101

Naver

사기범죄로 구치소에 수감중인, 암호화폐 거래소 FTX 창업자 뱅크먼 프리드 曰

“고등어 절임 화폐 시스템이 암호화폐보다 훨씬 안정적”

사기범죄로 구치소에 수감중인, 암호화폐 거래소 FTX 창업자 뱅크먼 프리드 曰 “고등어 절임 화폐 시스템이 암호화폐보다 훨씬 안정적”

사용자에게 꼭 필요한 핵심 기능을 인공지능 제품으로 개발하기 위해서는 사용자에 대한 이해가 선행되어야 합니다. 사용자를 이해하는 것이 쉬워 보일 수도 있지만 실제로는 간단하지 않습니다. 또한, 사용자가 이해하고 이에 맞는 서비스를 개발한다고 했을때, 해당 서비스에 인공지능 서비스가 꼭 필요한지 여부를 판단하는 것은 매우 어렵습니다. 그래서 대부분 인공지능 및 데이터 제품을 개발할 때 "기능 및 기술"에 초점을 맞추는 경우가 많이 있습니다. 하지만, 실제 서비스를 이용하는 사용자는 제품을 개발할때 고려하지 않았던 다양한 용도로 각자의 목표에 따라 서비스를 다양하게 활용하곤 합니다.

예를 들어, 사진 공유 플랫폼에 사용되는 인공지능 사진 분류 서비스를 개발한다고 가정해 보겠습니다. 대부분 제품 매니저는 "이미지를 유형별로 더 잘 분류할 수 있는 인공지능 서비스 구축"에 방점을 두고 기획 및 개발을 진행하게 됩니다. 이렇게 개발된 인공지능 기반의 이미지 유형 분류 서비스는 의외로 다양한 목적을 가진 사용자들이 매력을 느끼며 사용하게 됩니다. 대표적으로 세가지 사용자 그룹이 있을것 같습니다. 첫번째 사용자 그룹은 기획 의도대로 사진을 카테고리별로 정리하는 데 사용할 것입니다. 두번째 사용자 그룹은 인공지능 분류 서비스를 활용하여 특정 카테고리의 사진을 찾는 용도에 방점을 두고 서비스를 사용할 것입니다. 세번째 사용자 그룹은 기획 당시에는 생각하지 못했던 사용자입니다. 이들은 기업 내부의 저작권 감사 담당자가 될 수 있으며, 사진 분류 서비스를 이용하여 저작권이 있는 사진을 식별하는데 사진 분류 서비스를 사용할 것입니다.

위의 예시처럼 하나의 인공지능 제품이 목적에 따라 각기 다른 방향으로 사용될 수 있음을 인지할 수 있어야 합니다. 이는 인공지능 제품을 출시한 이후에 사용자 그룹을 비지도학습 방법등으로 분류하고, 각 사용자 그룹이 제품을 어떻게 활용하고 있는지 이해하기 위한 데이터 분석을 통해 확인 할 수 있습니다. 처음부터 모든 사용자 그룹을 만족시킬 수 있는 제품을 개발하기는 어렵습니다. 제품 사용 패턴을 분석했을때 다양한 사용자 그룹이 있는 경우에는 가장 대표적인 사용자 그룹에 초점을 맞추어 해당 그룹의 사용자에게 최상의 사용자 경험을 줄 수 있도록 제품을 고도화 하는 것이 중요합니다. 모든 사람에게 좋은 경험을 줄 수 있는 제품을 만드는 것은 너무 어려운 일입니다. 여러 사용자 그룹 중에서 어떤 사용자에게 집중하는 것이 최선일까요? 해당 제품의 필요성을 가장 크게 느끼면서, 인공지능 제품을 도입함으로써 이득을 가장 많이 볼 수 있는 사용자 그룹에 집중할 필요가 있습니다. 인공지능 제품은 "출시"가 업무의 끝이 아니라, 새로운 시작입니다.

해당 인공지능 제품의 최대 사용자가 누구인지 파악했다면 이제 핵심 문제를 이해하는 과정이 필요합니다. 인공지능 제품 매니저는 UX 리써치 조직과, 데이터 분석가, 데이터 과학자와 지속적인 논의와 가설 검증을 통해 사용자들이 진짜로 필요로 하는 기능을 파악해야 합니다. 또한, 인공지능 제품의 경우 해당 제품을 운영하기 위해서는 데이터의 전처리 등 일반적인 IT 서비스 개발 과정에 더해 추가로 검토해야 하는 기술셋이 있습니다. 가령, 개발하고자 하는 인공지능 제품의 적용을 위해서 데이터의 실시간 스트리밍 처리 기술이 필요한지? 아니면, 사용자의 전일자 데이터를 사용해도 되는지? 등 개발하고자 하는 제품에 어떤 데이터와 기술셋이 필요한지에 대해서도 함께 검토를 진행해야 합니다. 제품 개발에 필요한 기술셋을 미리 검토하고 준비하는 것은 사용자의 핵심 문제를 해결하는 제품 개발에 필수 요소입니다. 이러한 과정을 통해서 사용자 요구의 "진짜 이유"를 파악하고, "핵심"이 되는 문제를 해결할 수 있는 인공지능 제품을 개발하거나 기존의 IT서비스를 인공지능 기술로 혁신 할 수 있습니다.

사용자가 SNS나 서비스의 리뷰 코멘트를 통해 사진 공유 플랫폼에 사진 편집 기능이 필요하다고 불평한다면, 그저 그 요청을 받아들여 구축하는 것은 문제 해결 방법이 아닙니다. 대신에, '왜'라는 질문을 여러 번 반복하여 핵심 문제를 파악할 수 있어야 합니다. '왜'라는 질문을 반복하면서 사용자들이 편집 기능을 필요로 하는 진짜 이유를 알아볼 수 있습니다. 예를 들어, 사용자들은 편집 기능을 이용해서 자신의 사진을 크게 확대해서 보고 싶어 한다는 것을 파악할 수 있어야 합니다. 이렇듯 고객이 필요로 하는 기능을 그대로 반영하기 보다는 조금 더 구체적인 질문을 함으로써 핵심 문제를 해결하는 방법을 다양하게 고민해 볼 수 있습니다. 인공지능 제품 매니저로서 사용자에게 맥가이버칼 같은 만능 도구를 제공하기 보다는 사용자의 핵심 문제를 구체화하고 이에 맞는 인공지능 또는 데이터 제품을 통해서 해결 방법을 제공해야 합니다. 근본적인 문제를 이해함으로써, 그것을 더 효과적으로 해결할 수 있는 다양한 기술을 탐색할 수 있습니다.

수많은 기능 개발 요청과 아이디어에 직면했을 때, 사용자가 겪고 있는 핵심 문제를 바탕으로 우선 순위를 정하는 것이 중요합니다. 모든 요청이나 아이디어를 구현할 필요는 없습니다. 기업내 여러 이유로 그렇게 할 수도 없습니다. 대신에, 사용자에게 가장 가치를 줄 수 있는 가장 중요한 문제를 해결하는 데 집중해야 합니다. 이를 달성하기 위해 UX 리서치, 포커스 그룹 인터뷰, 피드백 분석, 로그 데이터 분석 등의 기법을 활용하여 사용자의 필요, 고충, 그리고 열망에 대한 통찰력을 발견해야 합니다. UX 리서치 등은 본격적으로 기획을 시작하기 전에 사용자가 겪고 있는 핵심 문제를 파악하기 위한 목적으로 진행해야 합니다. 사용자가 남긴 다양한 기록으로부터 그들의 불편함과 해결해야 할 가장 중요한 문제를 파악할 수 있으며, 사용자의 편의를 더욱 잘 반영하는 제품을 개발할 수 있습니다.

핵심 문제에 대한 명확한 이해를 갖게 되면, 잠재적인 해결책에 대한 아이디어를 생각하고 브레인스토밍을 시작할 수 있습니다. 이 과정에서는 여러 유관 부서와 업무 담당자들이 함께 참여하는 것이 중요합니다. "어떤 사용자 필요에 의해서" 또는 "어떤 업무 영역에서의 불편 요소의 해결을 위해서" 라는 문제를 해결하기 위해 인공지능 제품 개발을 위해서 기획자, 디자이너, 현업부서, 데이터 과학자, 엔지니어가 함께 협력함으로써 다양한 관점과 혁신적인 아이디어를 도출할 수 있습니다.

인공지능 제품 개발 단계에서는 대상 사용자와 함께 아이디어를 반복하고 검증하는 것이 필수적입니다. 프로토타입 제품을 만들고 다양한 개념을 테스트하여 초기 단계에서 피드백을 수집함으로써, 사용자의 의견을 반영하는 제품을 세련되게 만들 수 있습니다. 다만, 돈이 오가는 핀테크 제품 등 금융 분야에서는 프로토타입 제품을 이용한 사용자 테스트가 쉽지 않을 수 있습니다. 이런 경우에는 기업 내에서 품질 관리(Quality Assurance, QA) 담당자와 제품 매니저가 다양한 사례에 대해서 충분히 품질을 점검해 보는 과정이 필요합니다. 

인공지능 제품 매니저로서 제품을 기획하고 개발될 수 있도록 매니징 역할을 하는 것을 넘어서, 해당 제품을 이용하게될 사용자들에게 즐거운 경험을 선사해야 한다는 마음 가짐이 필요합니다. 사용자가 직면한 핵심 문제를 이해하고 해결하는 데 집중함으로써, 사용자의 기대를 뛰어넘는 제품을 만들 수 있습니다. 결론적으로, 인공지능 제품 매니저는 사용자가 겪고 있는 핵심 문제를 파악하는데 우선순위를 두어야 합니다. UX Research, 데이터 분석을 통한 가설 검증, 문제 식별, 개발, 반복적인 기능 테스트를 통해서 사용자에게 즐거움과 의미있는 경험을 제공하는 인공지능 제품을 개발할 수 있을 것입니다.

사용자에게 꼭 필요한 핵심 기능을 인공지능 제품으로 개발하기 위해서는 사용자에 대한 이해가 선행되어야 합니다. 사용자를 이해하는 것이 쉬워 보일 수도 있지만 실제로는 간단하지 않습니다. 또한, 사용자가 이해하고 이에 맞는 서비스를 개발한다고 했을때, 해당 서비스에 인공지능 서비스가 꼭 필요한지 여부를 판단하는 것은 매우 어렵습니다. 그래서 대부분 인공지능 및 데이터 제품을 개발할 때 "기능 및 기술"에 초점을 맞추는 경우가 많이 있습니다. 하지만, 실제 서비스를 이용하는 사용자는 제품을 개발할때 고려하지 않았던 다양한 용도로 각자의 목표에 따라 서비스를 다양하게 활용하곤 합니다. 예를 들어, 사진 공유 플랫폼에 사용되는 인공지능 사진 분류 서비스를 개발한다고 가정해 보겠습니다. 대부분 제품 매니저는 "이미지를 유형별로 더 잘 분류할 수 있는 인공지능 서비스 구축"에 방점을 두고 기획 및 개발을 진행하게 됩니다. 이렇게 개발된 인공지능 기반의 이미지 유형 분류 서비스는 의외로 다양한 목적을 가진 사용자들이 매력을 느끼며 사용하게 됩니다. 대표적으로 세가지 사용자 그룹이 있을것 같습니다. 첫번째 사용자 그룹은 기획 의도대로 사진을 카테고리별로 정리하는 데 사용할 것입니다. 두번째 사용자 그룹은 인공지능 분류 서비스를 활용하여 특정 카테고리의 사진을 찾는 용도에 방점을 두고 서비스를 사용할 것입니다. 세번째 사용자 그룹은 기획 당시에는 생각하지 못했던 사용자입니다. 이들은 기업 내부의 저작권 감사 담당자가 될 수 있으며, 사진 분류 서비스를 이용하여 저작권이 있는 사진을 식별하는데 사진 분류 서비스를 사용할 것입니다. 위의 예시처럼 하나의 인공지능 제품이 목적에 따라 각기 다른 방향으로 사용될 수 있음을 인지할 수 있어야 합니다. 이는 인공지능 제품을 출시한 이후에 사용자 그룹을 비지도학습 방법등으로 분류하고, 각 사용자 그룹이 제품을 어떻게 활용하고 있는지 이해하기 위한 데이터 분석을 통해 확인 할 수 있습니다. 처음부터 모든 사용자 그룹을 만족시킬 수 있는 제품을 개발하기는 어렵습니다. 제품 사용 패턴을 분석했을때 다양한 사용자 그룹이 있는 경우에는 가장 대표적인 사용자 그룹에 초점을 맞추어 해당 그룹의 사용자에게 최상의 사용자 경험을 줄 수 있도록 제품을 고도화 하는 것이 중요합니다. 모든 사람에게 좋은 경험을 줄 수 있는 제품을 만드는 것은 너무 어려운 일입니다. 여러 사용자 그룹 중에서 어떤 사용자에게 집중하는 것이 최선일까요? 해당 제품의 필요성을 가장 크게 느끼면서, 인공지능 제품을 도입함으로써 이득을 가장 많이 볼 수 있는 사용자 그룹에 집중할 필요가 있습니다. 인공지능 제품은 "출시"가 업무의 끝이 아니라, 새로운 시작입니다. 해당 인공지능 제품의 최대 사용자가 누구인지 파악했다면 이제 핵심 문제를 이해하는 과정이 필요합니다. 인공지능 제품 매니저는 UX 리써치 조직과, 데이터 분석가, 데이터 과학자와 지속적인 논의와 가설 검증을 통해 사용자들이 진짜로 필요로 하는 기능을 파악해야 합니다. 또한, 인공지능 제품의 경우 해당 제품을 운영하기 위해서는 데이터의 전처리 등 일반적인 IT 서비스 개발 과정에 더해 추가로 검토해야 하는 기술셋이 있습니다. 가령, 개발하고자 하는 인공지능 제품의 적용을 위해서 데이터의 실시간 스트리밍 처리 기술이 필요한지? 아니면, 사용자의 전일자 데이터를 사용해도 되는지? 등 개발하고자 하는 제품에 어떤 데이터와 기술셋이 필요한지에 대해서도 함께 검토를 진행해야 합니다. 제품 개발에 필요한 기술셋을 미리 검토하고 준비하는 것은 사용자의 핵심 문제를 해결하는 제품 개발에 필수 요소입니다. 이러한 과정을 통해서 사용자 요구의 "진짜 이유"를 파악하고, "핵심"이 되는 문제를 해결할 수 있는 인공지능 제품을 개발하거나 기존의 IT서비스를 인공지능 기술로 혁신 할 수 있습니다. 사용자가 SNS나 서비스의 리뷰 코멘트를 통해 사진 공유 플랫폼에 사진 편집 기능이 필요하다고 불평한다면, 그저 그 요청을 받아들여 구축하는 것은 문제 해결 방법이 아닙니다. 대신에, '왜'라는 질문을 여러 번 반복하여 핵심 문제를 파악할 수 있어야 합니다. '왜'라는 질문을 반복하면서 사용자들이 편집 기능을 필요로 하는 진짜 이유를 알아볼 수 있습니다. 예를 들어, 사용자들은 편집 기능을 이용해서 자신의 사진을 크게 확대해서 보고 싶어 한다는 것을 파악할 수 있어야 합니다. 이렇듯 고객이 필요로 하는 기능을 그대로 반영하기 보다는 조금 더 구체적인 질문을 함으로써 핵심 문제를 해결하는 방법을 다양하게 고민해 볼 수 있습니다. 인공지능 제품 매니저로서 사용자에게 맥가이버칼 같은 만능 도구를 제공하기 보다는 사용자의 핵심 문제를 구체화하고 이에 맞는 인공지능 또는 데이터 제품을 통해서 해결 방법을 제공해야 합니다. 근본적인 문제를 이해함으로써, 그것을 더 효과적으로 해결할 수 있는 다양한 기술을 탐색할 수 있습니다. 수많은 기능 개발 요청과 아이디어에 직면했을 때, 사용자가 겪고 있는 핵심 문제를 바탕으로 우선 순위를 정하는 것이 중요합니다. 모든 요청이나 아이디어를 구현할 필요는 없습니다. 기업내 여러 이유로 그렇게 할 수도 없습니다. 대신에, 사용자에게 가장 가치를 줄 수 있는 가장 중요한 문제를 해결하는 데 집중해야 합니다. 이를 달성하기 위해 UX 리서치, 포커스 그룹 인터뷰, 피드백 분석, 로그 데이터 분석 등의 기법을 활용하여 사용자의 필요, 고충, 그리고 열망에 대한 통찰력을 발견해야 합니다. UX 리서치 등은 본격적으로 기획을 시작하기 전에 사용자가 겪고 있는 핵심 문제를 파악하기 위한 목적으로 진행해야 합니다. 사용자가 남긴 다양한 기록으로부터 그들의 불편함과 해결해야 할 가장 중요한 문제를 파악할 수 있으며, 사용자의 편의를 더욱 잘 반영하는 제품을 개발할 수 있습니다. 핵심 문제에 대한 명확한 이해를 갖게 되면, 잠재적인 해결책에 대한 아이디어를 생각하고 브레인스토밍을 시작할 수 있습니다. 이 과정에서는 여러 유관 부서와 업무 담당자들이 함께 참여하는 것이 중요합니다. "어떤 사용자 필요에 의해서" 또는 "어떤 업무 영역에서의 불편 요소의 해결을 위해서" 라는 문제를 해결하기 위해 인공지능 제품 개발을 위해서 기획자, 디자이너, 현업부서, 데이터 과학자, 엔지니어가 함께 협력함으로써 다양한 관점과 혁신적인 아이디어를 도출할 수 있습니다. 인공지능 제품 개발 단계에서는 대상 사용자와 함께 아이디어를 반복하고 검증하는 것이 필수적입니다. 프로토타입 제품을 만들고 다양한 개념을 테스트하여 초기 단계에서 피드백을 수집함으로써, 사용자의 의견을 반영하는 제품을 세련되게 만들 수 있습니다. 다만, 돈이 오가는 핀테크 제품 등 금융 분야에서는 프로토타입 제품을 이용한 사용자 테스트가 쉽지 않을 수 있습니다. 이런 경우에는 기업 내에서 품질 관리(Quality Assurance, QA) 담당자와 제품 매니저가 다양한 사례에 대해서 충분히 품질을 점검해 보는 과정이 필요합니다.&nbsp; 인공지능 제품 매니저로서 제품을 기획하고 개발될 수 있도록 매니징 역할을 하는 것을 넘어서, 해당 제품을 이용하게될 사용자들에게 즐거운 경험을 선사해야 한다는 마음 가짐이 필요합니다. 사용자가 직면한 핵심 문제를 이해하고 해결하는 데 집중함으로써, 사용자의 기대를 뛰어넘는 제품을 만들 수 있습니다. 결론적으로, 인공지능 제품 매니저는 사용자가 겪고 있는 핵심 문제를 파악하는데 우선순위를 두어야 합니다. UX Research, 데이터 분석을 통한 가설 검증, 문제 식별, 개발, 반복적인 기능 테스트를 통해서 사용자에게 즐거움과 의미있는 경험을 제공하는 인공지능 제품을 개발할 수 있을 것입니다.

사용자의 핵심문제를 해결하는 인공지능 제품

📌 이럴 때 추천해요 : "책에 대한 기분 좋은 반전과 마주하고 싶을 때"

01 . 얼마 전 세계에서 가장 아름다운 서점이라고 불리는 '돈트 북스(Daunt Books)'에 관한 기사를 읽었습니다. (네. 거리에서 자주 보이는 그 에코백에 쓰인 Daunt Books가 바로 이곳입니다.) 어떻게 작은 독립서점이 영국을 상징하는 장소 중 한곳이 되었는지, 어떻게 지구 반대편에 있는 국가에서도 그들이 만든 굿즈를 명품처럼 소비하는지를 취재한 기사인데 시간 가는지 모르고 한 번에 훅 읽어 내려갔고 정말 재미있게 읽었습니다. (이 기사는 다음번에 한 번 제대로 소개해 보겠습니다.)

02 . 그러다 혹시 영국의 책 문화에 관해 소개한 책이 있을까 싶어 인터넷 서점 사이트를 뒤적뒤적 거리다 이 책을 발견했습니다. 바로 ⟪책 읽는 사람 만드는 사람 파는 사람⟫이란 책입니다. 이 작품의 부제는 '영국의 책 사랑은 어떻게 문화가 되었나?'인데요, 제목과 부제에서 말해주듯 영국의 책 문화를 들여다보는 자세를 취하고 있지만 실상은 책이 어떻게 사회의 근간이 되어주는가를 이야기하는 책이라고 할 수 있습니다.
그렇습니다. 개인적으로는 정말 정말 좋은 책이라고 생각합니다.

03 . 제가 받은 첫인상은 '오호, 책이 유통되는 과정이나 도서 산업의 전반을 훑어보는 내용인가?'라는 느낌에 더해 '책 한 번 써보자는 의지가 만연한 요즘 좋은 독립출판문화를 소개하는 책이려나?'라는 기대가 더해졌는데, 웬걸요. 이 책은 왜 영국이 이야기라는 문화에 빠져들었는지, 그게 어떻게 돈을 버는 산업이 되었는지, 영국인이 사랑하는 작가는 어떤 사람들인지, 찰스 다윈이 비글호 항해를 마치고 어떻게 '종의 기원'을 구성하고 발표하게 되었는지, 그런 사람들의 어떤 방식으로 이야기를 보존하고 이어가고 있는지 등이 고스란히 담겨있습니다.

04 . 때문에 가벼운 마음으로 접근한 것에 비해 정말 높은 몰입감을 선물해 주는 책이자 꽤 쏠쏠한 지식들로 흠뻑 적셔주는 책이죠. (사실 몇 페이지 짜리 책인지 안 보고 주문했는데... 얇은 에세이 집일 거라 생각한 기대와는 달리.. 344쪽이더라고요..하하) 따라서 그저 책이라는 산물보다 이야기라는 문화가 궁금할 때 저는 이 책을 한 번 펼쳐보면 좋을 것 같다는 생각입니다. 무엇보다 영국이라는 그 클래식한 나라의 매력을 좋아하는 분이라면 더없이 흥미롭게 읽을 것 같고요.

05 . 저는 제 기대를 기분 좋게 바꿔놓는 책을 좋아합니다. 한 권의 책을 골랐다면 당연히 그 안에는 기대와 예측과 선입견과 고정관념이 묻어있을 수밖에 없거든요. 그리고 이들은 우리가 실제로 읽어가는 그 시간 동안 기대라는 그물 안에 고스란히 담겨오기도 하고 넓은 틈망 사이로 휙휙 빠져나가기도 합니다. 하지만 책을 완독한 후에 그 그물 속에 담긴 것들이 꽤 흥미롭고 유용한 것들이라면 사실 성공한 독서이자 기억에 남는 경험이 되는 거 아닐까 싶어요.

06 . 그러니 혹시 이 책을 읽게 되신다면 첫 장을 넘기기 전에 스스로 몇 가지 예측을 해보는 것도 재미있는 기획 요소라고 생각합니다. 마치 우리가 여행을 가기 전에 단편적인 정보들로 그 도시를 상상해 보는 것처럼 내가 받은 첫인상으로 그 책이 어떤 경험을 줄지 상상해 보는 거죠. 때로는 예측과 반전을 오가는 그 경험 사이에서 우리의 생각이 더 깊어지고 더 또렷해지는 순간과 만날 수 있는 거니까요.

📌 이럴 때 추천해요 : "책에 대한 기분 좋은 반전과 마주하고 싶을 때" 01 . 얼마 전 세계에서 가장 아름다운 서점이라고 불리는 '돈트 북스(Daunt Books)'에 관한 기사를 읽었습니다. (네. 거리에서 자주 보이는 그 에코백에 쓰인 Daunt Books가 바로 이곳입니다.) 어떻게 작은 독립서점이 영국을 상징하는 장소 중 한곳이 되었는지, 어떻게 지구 반대편에 있는 국가에서도 그들이 만든 굿즈를 명품처럼 소비하는지를 취재한 기사인데 시간 가는지 모르고 한 번에 훅 읽어 내려갔고 정말 재미있게 읽었습니다. (이 기사는 다음번에 한 번 제대로 소개해 보겠습니다.) 02 . 그러다 혹시 영국의 책 문화에 관해 소개한 책이 있을까 싶어 인터넷 서점 사이트를 뒤적뒤적 거리다 이 책을 발견했습니다. 바로 ⟪책 읽는 사람 만드는 사람 파는 사람⟫이란 책입니다. 이 작품의 부제는 '영국의 책 사랑은 어떻게 문화가 되었나?'인데요, 제목과 부제에서 말해주듯 영국의 책 문화를 들여다보는 자세를 취하고 있지만 실상은 책이 어떻게 사회의 근간이 되어주는가를 이야기하는 책이라고 할 수 있습니다. 그렇습니다. 개인적으로는 정말 정말 좋은 책이라고 생각합니다. 03 . 제가 받은 첫인상은 '오호, 책이 유통되는 과정이나 도서 산업의 전반을 훑어보는 내용인가?'라는 느낌에 더해 '책 한 번 써보자는 의지가 만연한 요즘 좋은 독립출판문화를 소개하는 책이려나?'라는 기대가 더해졌는데, 웬걸요. 이 책은 왜 영국이 이야기라는 문화에 빠져들었는지, 그게 어떻게 돈을 버는 산업이 되었는지, 영국인이 사랑하는 작가는 어떤 사람들인지, 찰스 다윈이 비글호 항해를 마치고 어떻게 '종의 기원'을 구성하고 발표하게 되었는지, 그런 사람들의 어떤 방식으로 이야기를 보존하고 이어가고 있는지 등이 고스란히 담겨있습니다. 04 . 때문에 가벼운 마음으로 접근한 것에 비해 정말 높은 몰입감을 선물해 주는 책이자 꽤 쏠쏠한 지식들로 흠뻑 적셔주는 책이죠. (사실 몇 페이지 짜리 책인지 안 보고 주문했는데... 얇은 에세이 집일 거라 생각한 기대와는 달리.. 344쪽이더라고요..하하) 따라서 그저 책이라는 산물보다 이야기라는 문화가 궁금할 때 저는 이 책을 한 번 펼쳐보면 좋을 것 같다는 생각입니다. 무엇보다 영국이라는 그 클래식한 나라의 매력을 좋아하는 분이라면 더없이 흥미롭게 읽을 것 같고요. 05 . 저는 제 기대를 기분 좋게 바꿔놓는 책을 좋아합니다. 한 권의 책을 골랐다면 당연히 그 안에는 기대와 예측과 선입견과 고정관념이 묻어있을 수밖에 없거든요. 그리고 이들은 우리가 실제로 읽어가는 그 시간 동안 기대라는 그물 안에 고스란히 담겨오기도 하고 넓은 틈망 사이로 휙휙 빠져나가기도 합니다. 하지만 책을 완독한 후에 그 그물 속에 담긴 것들이 꽤 흥미롭고 유용한 것들이라면 사실 성공한 독서이자 기억에 남는 경험이 되는 거 아닐까 싶어요. 06 . 그러니 혹시 이 책을 읽게 되신다면 첫 장을 넘기기 전에 스스로 몇 가지 예측을 해보는 것도 재미있는 기획 요소라고 생각합니다. 마치 우리가 여행을 가기 전에 단편적인 정보들로 그 도시를 상상해 보는 것처럼 내가 받은 첫인상으로 그 책이 어떤 경험을 줄지 상상해 보는 거죠. 때로는 예측과 반전을 오가는 그 경험 사이에서 우리의 생각이 더 깊어지고 더 또렷해지는 순간과 만날 수 있는 거니까요.

[ 그때를 위한 책 vol.23 ] 책 읽는 사람 만드는 사람 파는 사람

커리어 코칭 일기 (Work & Tech) 769

스포츠에서 기본 기술이 중요하다고 많이 강조합니다. 축구는 볼 간수 능력, 야구는 배트 스윙, 배구는 리시브 등 이런 기술이 없으면 아예 게임을 할 수 없는 기술입니다. 화려한 기술도 많은데 전문가들은 왜 입을 모아 기본이 중요하다고 하는 걸까요?
대학교 4학년 취업을 준비하는 학생들에게 이런 질문을 종종 받습니다. 마케팅을 하려면 어떤 자격증이 필요한가요? 개발자가 되려면 어떤 기술을 배워야 하나요? 최소한 무엇을 배우고 익히면 본인이 원하는 직무로 취업을 할 수 있는지 궁금한가 봅니다.
미래를 꿈꾸는 친구들에게 위와 같은 질문을 받는다면, 경력자 여러분은 무엇이라고 답변해 주시겠습니까? 특정 자격과 기술을 소개해 줄 수도 있고, 직무 능력을 학습할 수 있는 책과 학원을 추천해 주실 수도 있을 것 같습니다.
부트캠프 커리어 코치로 근무하며 위와 같은 질문을 참 많이 받습니다. 취업을 고민하는 입장에서 아무래도 지금까지 접해보지 않은 분야에 대한 정보가 부족하니 막연한 불안감이 클 것입니다. 그래서 저도 현직 전문가와 채용담당자, 리더십을 많이 만나서 이야기 나누고 온라인 콘텐츠를 통해 정보를 수집하고 있습니다.
주니어를 채용하는 회사가 기대하는 인재의 모습에 대해서 다양한 정보를 입수하여 깨닫게 된 인사이트 두 가지가 있습니다. 하나는 기본이 중요하구나. 다른 하나는 될 때까지 도전하면 된다는 것입니다.
기본이 중요합니다. 특히 주니어에게 기대하는 것은 화려한 기술이 아니라 기본적인 이해입니다. 기술을 구현하기 위한 내용을 잘 이해하는 것이 중요합니다. 기술을 활용하는 것은 현업에서 할 수 있는 일이기 때문입니다. 주니어 시절에는 기본 기술에 대한 충분한 이해가 필요합니다.
경력이 있는 분들은 주니어 시절을 떠올려 보시면 쉽게 공감할 것입니다. 우리가 처음부터 엑셀을 잘 했나요? 우리가 처음부터 자료를 잘 정리했나요? 우리가 처음부터 협업이 잘 되고, 소통이 원활하게 되었나요? 너무 못했죠. 이렇게 내가 무능한 사람이었나 생각했죠.
그럼에도 불구하고 우리를 신입 사원으로 채용한 이유는 우리가 지닌 성장 가능성 때문일 것이라고 생각합니다. 그리고 겸손한 태도로 소통하고 협업할 준비가 되어있다고 판단했던 것이라고 추측합니다.
그러니 신입으로 주니어 포지션에 입사 준비를 하고 계신 여러분, 꿈과 용기를 가지세요. 기술 역량만 가지고 입사 여부를 판단하는 직무는 세상에 단 하나도 없습니다. 기본적인 지식과 소양을 갖추고 있고, 거기에 더해 협업에 필요한 겸손한 태도가 있다면 충분히 취업할 수 있습니다.
될 때까지 도전하세요! 50개 회사가 나를 못 알아보면 100개 회사에 지원하고, 그래도 안 되면 200개, 그래도 없으면 그 이상 최종 합격 통보를 받는 순간까지 포기하지 않고 도전하는 것입니다.
다양한 산업에서 근무하는 다양한 직무 전문가와 채용 담당자, 리더십이 한목소리로 이야기했습니다. 어떤 문제든 될 때까지 도전하는 입사 지원자가 멋지다고 생각하고 호감이 생긴다고요. 그러니까 절대 포기하지 마시고 하시고 싶은 일에 도전해서 꼭 커리어 목표 달성하면 좋겠습니다.

커리어 코칭 일기 (Work &amp; Tech) 769 스포츠에서 기본 기술이 중요하다고 많이 강조합니다. 축구는 볼 간수 능력, 야구는 배트 스윙, 배구는 리시브 등 이런 기술이 없으면 아예 게임을 할 수 없는 기술입니다. 화려한 기술도 많은데 전문가들은 왜 입을 모아 기본이 중요하다고 하는 걸까요?대학교 4학년 취업을 준비하는 학생들에게 이런 질문을 종종 받습니다. 마케팅을 하려면 어떤 자격증이 필요한가요? 개발자가 되려면 어떤 기술을 배워야 하나요? 최소한 무엇을 배우고 익히면 본인이 원하는 직무로 취업을 할 수 있는지 궁금한가 봅니다.미래를 꿈꾸는 친구들에게 위와 같은 질문을 받는다면, 경력자 여러분은 무엇이라고 답변해 주시겠습니까? 특정 자격과 기술을 소개해 줄 수도 있고, 직무 능력을 학습할 수 있는 책과 학원을 추천해 주실 수도 있을 것 같습니다.부트캠프 커리어 코치로 근무하며 위와 같은 질문을 참 많이 받습니다. 취업을 고민하는 입장에서 아무래도 지금까지 접해보지 않은 분야에 대한 정보가 부족하니 막연한 불안감이 클 것입니다. 그래서 저도 현직 전문가와 채용담당자, 리더십을 많이 만나서 이야기 나누고 온라인 콘텐츠를 통해 정보를 수집하고 있습니다.주니어를 채용하는 회사가 기대하는 인재의 모습에 대해서 다양한 정보를 입수하여 깨닫게 된 인사이트 두 가지가 있습니다. 하나는 기본이 중요하구나. 다른 하나는 될 때까지 도전하면 된다는 것입니다.기본이 중요합니다. 특히 주니어에게 기대하는 것은 화려한 기술이 아니라 기본적인 이해입니다. 기술을 구현하기 위한 내용을 잘 이해하는 것이 중요합니다. 기술을 활용하는 것은 현업에서 할 수 있는 일이기 때문입니다. 주니어 시절에는 기본 기술에 대한 충분한 이해가 필요합니다.경력이 있는 분들은 주니어 시절을 떠올려 보시면 쉽게 공감할 것입니다. 우리가 처음부터 엑셀을 잘 했나요? 우리가 처음부터 자료를 잘 정리했나요? 우리가 처음부터 협업이 잘 되고, 소통이 원활하게 되었나요? 너무 못했죠. 이렇게 내가 무능한 사람이었나 생각했죠.그럼에도 불구하고 우리를 신입 사원으로 채용한 이유는 우리가 지닌 성장 가능성 때문일 것이라고 생각합니다. 그리고 겸손한 태도로 소통하고 협업할 준비가 되어있다고 판단했던 것이라고 추측합니다.그러니 신입으로 주니어 포지션에 입사 준비를 하고 계신 여러분, 꿈과 용기를 가지세요. 기술 역량만 가지고 입사 여부를 판단하는 직무는 세상에 단 하나도 없습니다. 기본적인 지식과 소양을 갖추고 있고, 거기에 더해 협업에 필요한 겸손한 태도가 있다면 충분히 취업할 수 있습니다.될 때까지 도전하세요! 50개 회사가 나를 못 알아보면 100개 회사에 지원하고, 그래도 안 되면 200개, 그래도 없으면 그 이상 최종 합격 통보를 받는 순간까지 포기하지 않고 도전하는 것입니다.다양한 산업에서 근무하는 다양한 직무 전문가와 채용 담당자, 리더십이 한목소리로 이야기했습니다. 어떤 문제든 될 때까지 도전하는 입사 지원자가 멋지다고 생각하고 호감이 생긴다고요. 그러니까 절대 포기하지 마시고 하시고 싶은 일에 도전해서 꼭 커리어 목표 달성하면 좋겠습니다.

화려한 기술보다 기본적인 소양이 중요합니다

[주먹구구식 경영 탈피] 직원 이직률이 낮은 회사를 만드는 법 - 비즈니스 모비인사이드 MOBIINSIDE

[주먹구구식 경영 탈피] 직원 이직률이 낮은 회사를 만드는 법 - 모비인사이드 MOBIINSIDE

세계 최고의 기업들인 구글, 아마존, 애플, 넷플릭스 등도 최고 인재를 유치하고 이직률을 낮추기 위해 부단히 노력하고 있죠. 인재들에게 최고 수준의 대우를 해주고 A급 인재들로 팀을 꾸려 최고의 성과를 내려합니다. 그야말로 ‘인재 전쟁’입니다.

그러나 중소기업 입장에서는 딴 세상 이야기 같습니다. 중소기업은 채용이 어려운 것보다 이직률이 높은 것이 더 골치 아픕니다. 직원들이 계속 퇴사하게 되면 사장의 감도 무디어집니다. ‘그냥 새로 뽑지, 뭐’하고 붙잡을 생각도 하지 않습니다.

직원 이직은 회사 입장에서는 엄청나게 큰 비용을 치르는 것입니다. 이에 더해 추가 채용으로 인한 시간과 비용 손실, 업무 공백, 기존 직원의 업무량 증가 및 사기 저하 등 유무형의 손실이 너무나 많습니다.

중소기업에서 이직률이 높은 원인과 이를 낮추기 위한 방안은 무엇일까요? 이직률이 높은 표면적인 조사 결과는 낮은 연봉과 복리후생 부족이라고 합니다. 하지만 실제로는 이와 다릅니다.

1️⃣회사와 사장에게 실망하기 때문입니다. 회사에 비전도 없고 직원을 존중하지도 않습니다. 어떻게든 비용만 아끼려 합니다. 회사에 합리적인 체계를 만드는 것을 싫어합니다. 직원 교육을 시키는 것에 대해서도 부정적입니다. 이런 회사는 직원들이 이상하게 느낄 수밖에 없습니다. 직원들이 자꾸 회사를 떠난다면 회사의 시스템과 사장의 마인드를 재점검해봐야 합니다.

2️⃣회사에 인사체계가 없기 때문입니다. 직급 체계와 연봉 책정 기준이 없습니다. 승진과 보상 기준도 모호합니다. 인사 평가도 하지 않습니다. 이 회사는 가망이 없다고 느낍니다. 비록 회사의 규모가 작더라도 기본적인 인사체계가 있어야 합니다. 나중에 연봉제, 성과급제를 하더라도 기본적인 틀은 있어야 하는 거죠. 직원들은 합리적 인사체계가 없으면 뭔가 불공정할 것이라고 생각합니다.

3️⃣처음부터 잘못된 만남이었을 가능성이 큽니다. 회사의 욕심에 학벌과 경력만 보고 직원을 뽑았을 수도 있습니다. 직원도 회사를 제대로 파악하지 못하고 입사했을 수 있습니다. 나중에는 서로가 추구하는 바가 다르니 실망을 하게 됩니다. 거기에다가 연봉이나 복리후생마저 열악하다면 불만이 팽배하게 되는 것이죠.

4️⃣외부 인재를 영입할 때 기존 직원과의 형평성을 고려하지 않습니다. 사장은 능력이 뛰어난 인재를 영입하고 싶습니다. 이 과정에서 기존 직원과 다른 연봉과 복리후생을 약속하는 경우가 있습니다. 기존 직원에 대한 배려가 부족한 것이죠. 기존 직원들이 이를 알게 되면 상실감과 박탈감, 배신감을 크게 느끼며, 이는 집단 반발, 퇴사 등으로 이어질 수도 있습니다. 

5️⃣‘상사와의 갈등‘이 가장 큰 이유입니다. 특히, 팀원들과 가장 오랜 시간을 근무하는 팀장과의 관계가 문제지요. 사장은 팀장급 이상을 많이 상대하므로 팀장의 말을 더 믿게 됩니다. 상대적으로 힘이 없는 팀원이 이직이나 퇴사를 고려하게 되는 것이죠. 특정팀에 퇴사자가 많다면 팀장의 리더십을 의심해봐야 합니다.

팀장의 성향이나 능력에만 맡겨 놓으면 안 됩니다. 내부에서 승진한 사람들은 리더십을 배운 경험이 거의 없을 수 있습니다. 외부에서 영입한 사람도 회사 문화에 적응하지 못하면 제대로 된 리더십을 발휘할 수 없습니다. 뭔가 보여줘야 한다는 강박감으로 팀원과 불화를 일으킬 가능성이 더 큽니다. 팀장들이 리더십을 기를 수 있도록 리더십 교육을 반드시 해야 합니다.

또한 사장은 개인적인 친분이나 오랜 경력보다는 능력 있는 팀장을 임명해야 합니다. 팀장의 그릇이 되지 않으면, 팀에 우수한 인재가 들어와도 포용하지 못합니다. 직원들은 뭔가 배울 것이 있는 상사와 일하고 싶어 합니다. 능력 없는 사람과 같이 일하면 잦은 의견 충돌이 일어나게 마련입니다. 결국 직원들은 퇴사하게 됩니다.

✅현실적으로 직원이 이직하는 것을 막을 수 있는 특별한 방법은 없습니다. 두발 가진 인간이 어디든 못 가겠습니까? 본인의 자유 의지를 가졌으니까요. 모든 회사가 가지고 있는 공통의 고민입니다. 글로벌 기업이라고 인재 이탈을 걱정하지 않을까요?

그렇다고 해서 직원 이직에 대해 불만만 토로하며 손을 놓고 있으면 안 됩니다. 직원의 이직률을 낮추기 위한 회사의 다양한 노력이 뒤따라야 합니다. 회사는 최선의 노력을 다하고 있으며 직원과 함께 가려고 노력한다는 의지를 보여줘야 합니다.

세계 최고의 기업들인 구글, 아마존, 애플, 넷플릭스 등도 최고 인재를 유치하고 이직률을 낮추기 위해 부단히 노력하고 있죠. 인재들에게 최고 수준의 대우를 해주고 A급 인재들로 팀을 꾸려 최고의 성과를 내려합니다. 그야말로 ‘인재 전쟁’입니다. 그러나 중소기업 입장에서는 딴 세상 이야기 같습니다. 중소기업은 채용이 어려운 것보다 이직률이 높은 것이 더 골치 아픕니다. 직원들이 계속 퇴사하게 되면 사장의 감도 무디어집니다. ‘그냥 새로 뽑지, 뭐’하고 붙잡을 생각도 하지 않습니다. 직원 이직은 회사 입장에서는 엄청나게 큰 비용을 치르는 것입니다. 이에 더해 추가 채용으로 인한 시간과 비용 손실, 업무 공백, 기존 직원의 업무량 증가 및 사기 저하 등 유무형의 손실이 너무나 많습니다. 중소기업에서 이직률이 높은 원인과 이를 낮추기 위한 방안은 무엇일까요? 이직률이 높은 표면적인 조사 결과는 낮은 연봉과 복리후생 부족이라고 합니다. 하지만 실제로는 이와 다릅니다. 1️⃣회사와 사장에게 실망하기 때문입니다. 회사에 비전도 없고 직원을 존중하지도 않습니다. 어떻게든 비용만 아끼려 합니다. 회사에 합리적인 체계를 만드는 것을 싫어합니다. 직원 교육을 시키는 것에 대해서도 부정적입니다. 이런 회사는 직원들이 이상하게 느낄 수밖에 없습니다. 직원들이 자꾸 회사를 떠난다면 회사의 시스템과 사장의 마인드를 재점검해봐야 합니다. 2️⃣회사에 인사체계가 없기 때문입니다. 직급 체계와 연봉 책정 기준이 없습니다. 승진과 보상 기준도 모호합니다. 인사 평가도 하지 않습니다. 이 회사는 가망이 없다고 느낍니다. 비록 회사의 규모가 작더라도 기본적인 인사체계가 있어야 합니다. 나중에 연봉제, 성과급제를 하더라도 기본적인 틀은 있어야 하는 거죠. 직원들은 합리적 인사체계가 없으면 뭔가 불공정할 것이라고 생각합니다. 3️⃣처음부터 잘못된 만남이었을 가능성이 큽니다. 회사의 욕심에 학벌과 경력만 보고 직원을 뽑았을 수도 있습니다. 직원도 회사를 제대로 파악하지 못하고 입사했을 수 있습니다. 나중에는 서로가 추구하는 바가 다르니 실망을 하게 됩니다. 거기에다가 연봉이나 복리후생마저 열악하다면 불만이 팽배하게 되는 것이죠. 4️⃣외부 인재를 영입할 때 기존 직원과의 형평성을 고려하지 않습니다. 사장은 능력이 뛰어난 인재를 영입하고 싶습니다. 이 과정에서 기존 직원과 다른 연봉과 복리후생을 약속하는 경우가 있습니다. 기존 직원에 대한 배려가 부족한 것이죠. 기존 직원들이 이를 알게 되면 상실감과 박탈감, 배신감을 크게 느끼며, 이는 집단 반발, 퇴사 등으로 이어질 수도 있습니다.&nbsp; 5️⃣‘상사와의 갈등‘이 가장 큰 이유입니다. 특히, 팀원들과 가장 오랜 시간을 근무하는 팀장과의 관계가 문제지요. 사장은 팀장급 이상을 많이 상대하므로 팀장의 말을 더 믿게 됩니다. 상대적으로 힘이 없는 팀원이 이직이나 퇴사를 고려하게 되는 것이죠. 특정팀에 퇴사자가 많다면 팀장의 리더십을 의심해봐야 합니다. 팀장의 성향이나 능력에만 맡겨 놓으면 안 됩니다. 내부에서 승진한 사람들은 리더십을 배운 경험이 거의 없을 수 있습니다. 외부에서 영입한 사람도 회사 문화에 적응하지 못하면 제대로 된 리더십을 발휘할 수 없습니다. 뭔가 보여줘야 한다는 강박감으로 팀원과 불화를 일으킬 가능성이 더 큽니다. 팀장들이 리더십을 기를 수 있도록 리더십 교육을 반드시 해야 합니다. 또한 사장은 개인적인 친분이나 오랜 경력보다는 능력 있는 팀장을 임명해야 합니다. 팀장의 그릇이 되지 않으면, 팀에 우수한 인재가 들어와도 포용하지 못합니다. 직원들은 뭔가 배울 것이 있는 상사와 일하고 싶어 합니다. 능력 없는 사람과 같이 일하면 잦은 의견 충돌이 일어나게 마련입니다. 결국 직원들은 퇴사하게 됩니다. ✅현실적으로 직원이 이직하는 것을 막을 수 있는 특별한 방법은 없습니다. 두발 가진 인간이 어디든 못 가겠습니까? 본인의 자유 의지를 가졌으니까요. 모든 회사가 가지고 있는 공통의 고민입니다. 글로벌 기업이라고 인재 이탈을 걱정하지 않을까요? 그렇다고 해서 직원 이직에 대해 불만만 토로하며 손을 놓고 있으면 안 됩니다. 직원의 이직률을 낮추기 위한 회사의 다양한 노력이 뒤따라야 합니다. 회사는 최선의 노력을 다하고 있으며 직원과 함께 가려고 노력한다는 의지를 보여줘야 합니다.

모비인사이드 MOBIINSIDE

You may not have these apps just yet, but you absolutely should. Get in on the ground floor of these lesser-known gems and watch them soar.

Best Hidden Gems

데얼스가
구글이 선정한
'올해를 빛낸 숨은 보석 앱' 우수상을
수상하였습니다.

구글 설명:
최근에 출시된 앱이라고는 믿기지 않을 만큼 (품질),
(쓰임새) 그 어느 것에서도 여느 인기 앱 못지않은 
(수준)을 자랑하는
그야말로 숨은 보석을 소개합니다.
많은 사람의 사랑을 받아야 마땅한 Google Play 선정

2024년에도
데얼스의 가치를 더 알리도록
최선을 다하겠습니다.
보석 같은 데얼스를 만들고 있는
Jay, Roy, Stella, Andy, Liam
Ted, William, Hazel, lina, Esti, Evan에게
감사의 말씀 전합니다.

https://play.google.com/store/apps/editorial?id=mc_bo23_apps_gem_fcp

데얼스가구글이 선정한'올해를 빛낸 숨은 보석 앱' 우수상을수상하였습니다. 구글 설명:최근에 출시된 앱이라고는 믿기지 않을 만큼 (품질),(쓰임새) 그 어느 것에서도 여느 인기 앱 못지않은&nbsp;(수준)을 자랑하는그야말로 숨은 보석을 소개합니다.많은 사람의 사랑을 받아야 마땅한 Google Play 선정 2024년에도데얼스의 가치를 더 알리도록최선을 다하겠습니다.보석 같은 데얼스를 만들고 있는Jay, Roy, Stella, Andy, LiamTed, William, Hazel, lina, Esti, Evan에게감사의 말씀 전합니다. https://play.google.com/store/apps/editorial?id=mc_bo23_apps_gem_fcp

Google

(수상) 대한민국 '올해를 빛낸 숨은 보석 앱' 우수상

포털 사이트 네이버(NAVER(035420))의 자회사 네이버파이낸셜이 이르면 다음 달 '네이버 증권(Npay 증권)'을 통한 주식거래 서비스를 내놓을 예정인 가운데 대형 증권사마저 온라인 플랫폼에 종속될 수 있다는

대형 증권사마저 '네이버 늪' 빠지나

이르면 올해 안에 미래에셋증권을 비롯한 1~2개 증권사가 입점해 관련 서비스를 선보일 계획이다. 이 서비스는 네이버 증권 포털과 증권사 계좌를 연동해 클릭 몇 번으로 편리하게 주식을 매매할 수 있다는 게 강점이다. 개별 증권사의 홈트레이딩시스템(HTS)이나 모바일트레이딩시스템(MTS)에 접속하지 않고도 거래할 수 있는 것이다. 

https://n.news.naver.com/article/011/0004267491?sid=101

이르면 올해 안에 미래에셋증권을 비롯한 1~2개 증권사가 입점해 관련 서비스를 선보일 계획이다. 이 서비스는 네이버 증권 포털과 증권사 계좌를 연동해 클릭 몇 번으로 편리하게 주식을 매매할 수 있다는 게 강점이다. 개별 증권사의 홈트레이딩시스템(HTS)이나 모바일트레이딩시스템(MTS)에 접속하지 않고도 거래할 수 있는 것이다.&nbsp; https://n.news.naver.com/article/011/0004267491?sid=101

프론트엔드 개발자라면 아마 웹사이트 성능을 최적화하는 것에 관심이 있을 것이다. 웹사이트 로딩 시간을 줄이고, 물 흐르듯 자연스러운 사용자 경험을 만드는 것은 비즈니스에도 큰 영향을 끼친다. 웹을 최적화할 수 있는 방법에는 여러 가지가 있는데, 그중에서 빠질 수 없는 개념이 바로 캐싱이다. 이번 글에서는 프론트엔드 개발자가 알아야 할 캐싱의 종류와 개념을 살펴보려고 한다.

프론트엔드 개발자가 알아야 할 '캐싱' 개념 정리 | 요즘IT

개발을 하다보면 캐싱 개념에 대해 알아야 하는데, 프론트엔드 개발 관점의 캐싱 글을 발견해 공유해보아요! 백엔드 개발 관점의 캐싱과 다른 관점이라 흥미롭네요

 * 캐싱의 종류
   * 웹 캐시 : 클라이언트에서 해당 웹사이트를 그리기 위해 필요한 데이터
   * 브라우저 캐시 : 한 번 불러온 데이터고 거의 바뀔 일 없는 데이터. 블로그 로고, 이미지, 제목, 사이드바 목차 등
   * 프록시 캐시 : 한 명 이상의 사용자에 의해 재사용되는 응답
   * 네트워크 캐시 : 하나의 서버에 여러 개의 프록시 서버가 있을 수 있고 서비스 대상에 따라 지역이 여러군데일 수 있음
     * CDN : Content delivery Network로 성능 향상을 위해 요청을 분산시킴
 * HTTP 헤더의 ETag : 특정 버전의 리소스 식별
 * Cache-Control : 요청을 보낼지 말지 판단할 때 사용
   * no-cache : 캐시 먼저 사용하기 이전에 서버에 해당 캐시를 사용해도 되는제 검증 요청을 보내는 속성
   * no-cache는 서버에서 허락을 받고 사용해서 시간 소요
   * no-store : 반환된 응답에 대해 브라우저가 캐싱하지 않음

https://yozm.wishket.com/magazine/detail/2341/

개발을 하다보면 캐싱 개념에 대해 알아야 하는데, 프론트엔드 개발 관점의 캐싱 글을 발견해 공유해보아요! 백엔드 개발 관점의 캐싱과 다른 관점이라 흥미롭네요 <ul><li>캐싱의 종류<ul><li>웹 캐시 : 클라이언트에서 해당 웹사이트를 그리기 위해 필요한 데이터</li><li>브라우저 캐시 : 한 번 불러온 데이터고 거의 바뀔 일 없는 데이터. 블로그 로고, 이미지, 제목, 사이드바 목차 등</li><li>프록시 캐시 : 한 명 이상의 사용자에 의해 재사용되는 응답</li><li>네트워크 캐시 : 하나의 서버에 여러 개의 프록시 서버가 있을 수 있고 서비스 대상에 따라 지역이 여러군데일 수 있음<ul><li>CDN : Content delivery Network로 성능 향상을 위해 요청을 분산시킴</li></ul></li></ul></li><li>HTTP 헤더의 ETag : 특정 버전의 리소스 식별</li><li>Cache-Control : 요청을 보낼지 말지 판단할 때 사용<ul><li>no-cache : 캐시 먼저 사용하기 이전에 서버에 해당 캐시를 사용해도 되는제 검증 요청을 보내는 속성</li><li>no-cache는 서버에서 허락을 받고 사용해서 시간 소요</li><li>no-store : 반환된 응답에 대해 브라우저가 캐싱하지 않음</li></ul></li></ul> https://yozm.wishket.com/magazine/detail/2341/

요즘IT

프론트엔드 개발자가 알아야 할 캐싱 개념 정리

Bored of algorithms? Here are my recommendations that are exciting, understandable, and sometimes even useful!

Challenging algorithms and data structures every programmer should try

모든 프로그래머가 해보면 좋은 도전 과제 알고리즘 입니다
 * 토폴로지컬 소트
 * 리커시브 디센트 파싱
 * 마이어의 스트링 디프 (git의 diff알고리즘)
 * 블룸 필터 (데이터가 없는지 찾아낼 때 사용)
 * 피스 테이블 (테스트에디터에서 사용한다고함)
 * 스플레이 트리

여러분도 도전해보세요!
https://austinhenley.com/blog/challengingalgorithms.html

모든 프로그래머가 해보면 좋은 도전 과제 알고리즘 입니다<ul><li>토폴로지컬 소트</li><li>리커시브 디센트 파싱</li><li>마이어의 스트링 디프 (git의 diff알고리즘)</li><li>블룸 필터 (데이터가 없는지 찾아낼 때 사용)</li><li>피스 테이블 (테스트에디터에서 사용한다고함)</li><li>스플레이 트리</li></ul> 여러분도 도전해보세요! https://austinhenley.com/blog/challengingalgorithms.html

Austinhenley

모든 프로그래머가 해보면 좋은 도전 과제 알고리즘들

Edit 2: Lots of insightful comments at the bottom, do give them a read, too, before going with any... Tagged with go, programming, javascript, json.

JSON is Slower. Here Are Its 4 Faster Alternatives

JSON 은 데이터를 정의하는 포맷중 하나로 웹 서비스에서 서버와 클라이언트간에 통신시 많이 사용되고 있습니다.

제가 신입일때까지만 해도 XML 이나 Plain Text 형식으로 통신하는 API 들도 여럿 있었지만,
시간이 흘러 이러한 API 들은 deprecated 되었고
현재 서비스 되고 있는 OPEN API 들의 문서를 봐도 JSON 으로 통신하지 않는 API 는 찾아보기가 힘듭니다.

JSON 이 이렇게 인기가 많아진 이유는 다음과 같습니다.

📌 사람이 읽을 수 있는 형식
📌 언어에 구애받지 않음
📌 데이터 구조 일관성
📌 브라우저 지원
📌 프로그래밍 언어의 JSON API 지원

그렇지만 이러한 JSON 도 다음과 같은 이유로 성능 저하를 발생시킬 수 있습니다.

📌 광범위하거나 중첩이 깊은 데이터일 경우 Parsing 오버헤드가 발생할 수 있습니다
📌 데이터 송수신시 반드시 해야하는 직렬화 및 역직렬화 과정이 성능에 영향을 줄 수 있습니다
📌 JSON 은 텍스트 기반이기 때문에 문자열 처리를 하게 되는데 이는 이진 데이터 처리에 비해 느릴 수 밖에 없습니다
📌 JSON 에서 제공하는 데이터 Type 이 제한되기 때문에 복잡한 데이터 구조를 사용할 경우 추가적인 장치나 표현이 필요하게 되어 성능에 영향을 줄 수 있습니다
📌 바이너리 데이터에 대한 지원이 없기 때문에 이를 표현할 경우 텍스트 인코딩, 디코딩을 하게 되어 성능에 영향을 줄 수 있습니다

이러한 JSON 의 단점을 대체할 수 있는 것으로 다음과 같은 솔루션이 있습니다.

📌 Protocol Buffers
Protobuf 라고도 알려진 프로토콜 버퍼는 Google 에서 개발한 바이너리 직렬화 형식입니다.
JSON 에 비해 인코딩 및 디코딩이 더 간단하고 빠른 바이너리 인코딩을 사용하고 이전 버전과의 호환성을 유지하면서 데이터 구조를 업데이트할 수 있는 Schema Evolution 을 지원합니다.

📌 MessagePack
MessagePack 은 효율성과 속도를 위해 설계된 또 다른 이진 직렬화 형식입니다.
매우 컴팩트한 데이터 표현을 생성하여 데이터 전송 크기를 줄일 수 있고, Protocol Buffers 와 동일하게 바이너리 특성으로 빠른 인코딩 및 디코딩이 가능합니다.

📌 BSON
MongoDB 에서 사용하는것으로 유명한 BSON 은 바이너리 데이터 유형이 추가된 JSON과 유사한 구조를 유지하여 효율성과 가독성 간의 균형을 제공합니다.
또한 이미지나 멀티미디어와 같은 데이터를 처리하는 데 유용한 바이너리 데이터 유형에 대한 기본 지원을 제공합니다.

📌 Avro
Avro는 Apache Hadoop 프로젝트 내에서 개발된 데이터 직렬화 프레임워크로 스키마 호환성과 성능에 강점을 두고 있습니다.
컴팩트 바이너리 인코딩 형식을 사용하므로 페이로드를 줄일 수 있고 여러 프로그래밍 언어를 지원하므로 다양한 애플리케이션 생태계에 적합합니다.

공유 드린 원문에 이에 대한 자세한 내용과 JSON 을 계속 사용할 경우 성능을 최적화 할 수 있는 팁들이 정리되어있으니 관심있으신 분들은 원문 내용을 참고해주세요.

📚 원문
https://dev.to/nikl/json-is-slower-here-are-its-4-faster-alternatives-2g30?utm_source=oneoneone

JSON 은 데이터를 정의하는 포맷중 하나로 웹 서비스에서 서버와 클라이언트간에 통신시 많이 사용되고 있습니다. 제가 신입일때까지만 해도 XML 이나 Plain Text 형식으로 통신하는 API 들도 여럿 있었지만,시간이 흘러 이러한 API 들은 deprecated 되었고현재 서비스 되고 있는 OPEN API 들의 문서를 봐도 JSON 으로 통신하지 않는 API 는 찾아보기가 힘듭니다. JSON 이 이렇게 인기가 많아진 이유는 다음과 같습니다. 📌 사람이 읽을 수 있는 형식📌 언어에 구애받지 않음📌 데이터 구조 일관성📌 브라우저 지원📌 프로그래밍 언어의 JSON API 지원 그렇지만 이러한 JSON 도 다음과 같은 이유로 성능 저하를 발생시킬 수 있습니다. 📌 광범위하거나 중첩이 깊은 데이터일 경우 Parsing 오버헤드가 발생할 수 있습니다📌 데이터 송수신시 반드시 해야하는 직렬화 및 역직렬화 과정이 성능에 영향을 줄 수 있습니다📌 JSON 은 텍스트 기반이기 때문에 문자열 처리를 하게 되는데 이는 이진 데이터 처리에 비해 느릴 수 밖에 없습니다📌 JSON 에서 제공하는 데이터 Type 이 제한되기 때문에 복잡한 데이터 구조를 사용할 경우 추가적인 장치나 표현이 필요하게 되어 성능에 영향을 줄 수 있습니다📌 바이너리 데이터에 대한 지원이 없기 때문에 이를 표현할 경우 텍스트 인코딩, 디코딩을 하게 되어 성능에 영향을 줄 수 있습니다 이러한 JSON 의 단점을 대체할 수 있는 것으로 다음과 같은 솔루션이 있습니다. 📌 Protocol BuffersProtobuf 라고도 알려진 프로토콜 버퍼는 Google 에서 개발한 바이너리 직렬화 형식입니다.JSON 에 비해 인코딩 및 디코딩이 더 간단하고 빠른 바이너리 인코딩을 사용하고 이전 버전과의 호환성을 유지하면서 데이터 구조를 업데이트할 수 있는 Schema Evolution 을 지원합니다. 📌 MessagePackMessagePack 은 효율성과 속도를 위해 설계된 또 다른 이진 직렬화 형식입니다.매우 컴팩트한 데이터 표현을 생성하여 데이터 전송 크기를 줄일 수 있고, Protocol Buffers 와 동일하게 바이너리 특성으로 빠른 인코딩 및 디코딩이 가능합니다. 📌 BSONMongoDB 에서 사용하는것으로 유명한 BSON 은 바이너리 데이터 유형이 추가된 JSON과 유사한 구조를 유지하여 효율성과 가독성 간의 균형을 제공합니다.또한 이미지나 멀티미디어와 같은 데이터를 처리하는 데 유용한 바이너리 데이터 유형에 대한 기본 지원을 제공합니다. 📌 AvroAvro는 Apache Hadoop 프로젝트 내에서 개발된 데이터 직렬화 프레임워크로 스키마 호환성과 성능에 강점을 두고 있습니다.컴팩트 바이너리 인코딩 형식을 사용하므로 페이로드를 줄일 수 있고 여러 프로그래밍 언어를 지원하므로 다양한 애플리케이션 생태계에 적합합니다. 공유 드린 원문에 이에 대한 자세한 내용과 JSON 을 계속 사용할 경우 성능을 최적화 할 수 있는 팁들이 정리되어있으니 관심있으신 분들은 원문 내용을 참고해주세요. 📚 원문https://dev.to/nikl/json-is-slower-here-are-its-4-faster-alternatives-2g30?utm_source=oneoneone

DEV Community

💡 JSON 보다 더 빠른 대안들

LINE 의 오픈챗은 대규모 트래픽을 처리하는 서비스 중 하나입니다.

특히 유명 가수의 콘서트 시, 수백만 팬들이 오픈챗에서 활발히 소통하면서 트래픽이 급증하는 현상이 발생합니다.

이렇게 하나의 오픈챗이 다른 오픈챗보다 트래픽이 많이 발생하는 걸 LINE은 '핫 챗 (Hot Chat)'으로 정의하며, 이 글에서는 핫 챗의 발생 패턴과 해결 방법을 살펴보겠습니다.

<오픈챗이 처리하는 트래픽의 규모>

하나의 오픈챗은 수천에서 수만 명의 사용자를 수용할 수 있습니다.

오픈챗 서버는 분당 1천만 건, 일일 약 100억 건의 API 요청을 처리합니다. 활발한 하나의 오픈챗은 분당 최대 20만 건의 API 요청을 생성하기도 합니다.

<오픈챗 서비스의 구조>

LINE의 오픈챗 서비스는 이벤트 기반 아키텍처로 구성되어 있습니다.

사용자가 메시지를 보내는 등의 이벤트가 발생하면, 이들은 데이터베이스에 기록되고 Kafka를 통해 전달됩니다.

이후 Publish 서비스가 Kafka 토픽에서 이벤트를 소비하고, 사용자들에게 이벤트를 알리는 서버 푸시를 합니다.

사용자들은 API 호출을 통해 필요한 데이터를 가져갑니다.

서비스 구조는 그림으로 보는 것이 좋을 것 같은데요. 아래 파일로 첨부해두었습니다.

<Hot Chat 패턴별로 발생하는 문제와 이를 해결하는 전략>

1.1 첫 번째 문제: 오픈챗 트래픽 증가

수백만명의 가수의 팬들이 콘서트를 열 때 오픈챗에서 활발히 떠들다보니 오픈챗의 이벤트를 가져오려는 API 호출 트래픽이 급증하는 사례가 발생합니다.

이로 인해 발생하는 증상은 다음과 같습니다:
 * 트래픽 급증으로 인한 데이터베이스 요청 증가, Slow Query 발생
 * API 서버의 GC, CPU 사용량 증가 및 응답 지연
 * 카프카의 Lag 증가

1.2 해결책:

일반적으로 Naive 하게 생각해 수 있는 해결책은 Shard 를 추가하는 것일텐데, 핫 챗은 전체 오픈챗 중의 0.1% 정도 되기 때문에 단순 샤드를 추가하는 건 영향이 작을 것입니다.

LINE 에서는 Hot Chat 을 Detecting 하고 일정시간 동안 Throttling 을 적용하는 방법으로 해결했습니다:
 * 핫 챗 탐지:
 * Publish 서버에서 발생한 채팅방의 이벤트 수를 추적하고, 특정 임계점이 넘었으면 이 채팅방을 Hot Chat 이라고 기록합니다. 
 * 트래픽 Throttling 적용:
 * 핫 챗으로 분류된 채팅방에서는 확률적으로 서버 푸시 메시지 전송 빈도를 조절합니다.
 * 이는 API 요청의 폭증을 방지하고 서버 부하를 줄이는 데 도움이 됩니다.
 * 정책 동적 조정:
 * 핫 챗 정책은 LINE의 오픈소스 솔루션인 Central Dogma를 사용하여 동적으로 조정됩니다.
 * 이를 통해 서비스 운영자는 배포 없이 실시간으로 트래픽 상황에 맞춰 정책을 조정할 수 있습니다.
 * Note:
 * 이 방법은 폭증하는 트래픽에서 서버를 보호하는 방법이지, 트래픽 자체를 해결하는 방법은 아닙니다.
 * 위의 LINE 의 사례와 같은 Hot Key 문제에 대해서 트래픽 자체를 해결하려면 하나의 샤드로 향하는 트래픽을 다른 샤드들로 분산시키는 것이 필요합니다.
 * 그래서 일반적인 해결 방법 중 하나는 Shard Key 에다가 Random Number 를 붙혀서 하나의 샤드에서 다른 샤드들로 저장되고 읽을 수 있도록 하는 것입니다. 이를 'Salted Key' 라고도 합니다.
 * 이 방법으로 할 경우 읽기 요청을 할 때가 문제라서 Hot Key 의 Shard Key 가 어떻게 분산되었는지를 추적할 수 있는 방법을 추가로 필요로 합니다.
 * 이 방식으로 해결해야한다는 뜻을 말하는 것은 아닙니다. 개인적인 생각으로는 활발한 오픈챗에서 이벤트 전달은 되게 작은 문제라고 보여서 Throttling 하는 것이 더 나은 솔루션 같아 보입니다.

2.1 두 번째 문제: 오픈챗 참여 요청이 급증:

인플루언서가 오픈챗 링크를 공유하면서 참여 요청이 갑자기 증가하는 상황이 발생할 수 있습니다.

이로 인해 발생하는 증상은 다음과 같습니다:
 * MySQL Slow Log 증가, CPU 사용률 증가
 * OpenChat 서비스의 응답 타임아웃 증가

2.2 해결책:

MySQL INSERT 성능 최적화:
 * 오픈챗 참여 INSERT 는 단순 INSERT 가 아니라, INSERT 내부에서 SELECT 를 사용하는 쿼리로 구성되어 있습니다. 이는 내부적으로 Bulk Insert 로 취급이 됩니다.
 * Bulk Insert 에서 레코드가 Auto Increment 타입의 칼럼을 쓰고 있는 경우 auto_increment_lock_mode=1 로 설정되어 있는 경우에는 Auto Increment 의 값을 연속적으로 증가함을 보장하며 테이블 락을 잡습니다. (MySQL 8.0 이전에는 auto_increment_lock_mode 의 기본 값은 1입니다.)
 * 그래서 동시에 오픈챗 참여 요청을 하면 이런 테이블락의 경합으로 인해서 CPU 사용률이 치솟는 것입니다.
 * 이를 auto_increment_lock_mode=2 로 변경하면 Auto Increment 값이 연속적으로 증가함을 보장하지는 않지만, 테이블 락보다 가벼운 Mutex 를 사용해서 더 나은 성능을 낼 수 있습니다. 
 * 모든 기술이 그렇듯이 주의할 점이 있는데  auto_increment_lock_mode=2 로 적용할 경우에는 복제에서 statement-based replication 이 아니라 row-based replication 을 적용해야합니다. Auto Increment 값이 연속적으로 증가하지 않기 때문에 복제 서버에서는 다른 값이 될 수 있기 때문입니다. 

참여 요청에 대한 Throttling 적용:
 * auto_increment_lock_mode 를 튜닝해서 처리할 수 있는 성능을 높혔더라도, 언제든지 MySQL 이 처리할 수 있는 양보다 훨씬 많은 부하를 받을 수 있습니다.
 * 여기서 Throttling 을 적용할 때 중요했던 건 Hot Chat Throttling 과 달리 Throttling 을 지연없이 빠르게 적용할 수 있는가 입니다.
 * Redis 에서도 참여 요청의 수를 집계해서 Throttling 를 적용할 수도 있지만 얼마 안되는 핫 오픈챗에 대해서 전체 오픈챗에 대해 기록하는 건 큰 오버헤드라고 판단해서 Local Cache 에서 집계를 해서 Throttling 을 적용했습니다.

Reference:
https://engineering.linecorp.com/ko/blog/how-line-openchat-server-handles-extreme-traffic-spikes

LINE 의 오픈챗은 대규모 트래픽을 처리하는 서비스 중 하나입니다. 특히 유명 가수의 콘서트 시, 수백만 팬들이 오픈챗에서 활발히 소통하면서 트래픽이 급증하는 현상이 발생합니다. 이렇게 하나의 오픈챗이 다른 오픈챗보다 트래픽이 많이 발생하는 걸 LINE은 '핫 챗 (Hot Chat)'으로 정의하며, 이 글에서는 핫 챗의 발생 패턴과 해결 방법을 살펴보겠습니다. &lt;오픈챗이 처리하는 트래픽의 규모&gt; 하나의 오픈챗은 수천에서 수만 명의 사용자를 수용할 수 있습니다. 오픈챗 서버는 분당 1천만 건, 일일 약 100억 건의 API 요청을 처리합니다. 활발한 하나의 오픈챗은 분당 최대 20만 건의 API 요청을 생성하기도 합니다. &lt;오픈챗 서비스의 구조&gt; LINE의 오픈챗 서비스는 이벤트 기반 아키텍처로 구성되어 있습니다. 사용자가 메시지를 보내는 등의 이벤트가 발생하면, 이들은 데이터베이스에 기록되고 Kafka를 통해 전달됩니다. 이후 Publish 서비스가 Kafka 토픽에서 이벤트를 소비하고, 사용자들에게 이벤트를 알리는 서버 푸시를 합니다. 사용자들은 API 호출을 통해 필요한 데이터를 가져갑니다. 서비스 구조는 그림으로 보는 것이 좋을 것 같은데요. 아래 파일로 첨부해두었습니다. &lt;Hot Chat 패턴별로 발생하는 문제와 이를 해결하는 전략&gt; 1.1 첫 번째 문제: 오픈챗 트래픽 증가 수백만명의 가수의 팬들이 콘서트를 열 때 오픈챗에서 활발히 떠들다보니 오픈챗의 이벤트를 가져오려는 API 호출 트래픽이 급증하는 사례가 발생합니다. 이로 인해 발생하는 증상은 다음과 같습니다:<ul><li>트래픽 급증으로 인한 데이터베이스 요청 증가, Slow Query 발생</li><li>API 서버의 GC, CPU 사용량 증가 및 응답 지연</li><li>카프카의 Lag 증가</li></ul> 1.2 해결책: 일반적으로 Naive 하게 생각해 수 있는 해결책은 Shard 를 추가하는 것일텐데, 핫 챗은 전체 오픈챗 중의 0.1% 정도 되기 때문에 단순 샤드를 추가하는 건 영향이 작을 것입니다. LINE 에서는 Hot Chat 을 Detecting 하고 일정시간 동안 Throttling 을 적용하는 방법으로 해결했습니다:<ul><li>핫 챗 탐지:<ul><li>Publish 서버에서 발생한 채팅방의 이벤트 수를 추적하고, 특정 임계점이 넘었으면 이 채팅방을 Hot Chat 이라고 기록합니다.&nbsp;</li></ul></li><li>트래픽 Throttling 적용:<ul><li>핫 챗으로 분류된 채팅방에서는 확률적으로 서버 푸시 메시지 전송 빈도를 조절합니다.</li><li>이는 API 요청의 폭증을 방지하고 서버 부하를 줄이는 데 도움이 됩니다.</li></ul></li><li>정책 동적 조정:<ul><li>핫 챗 정책은 LINE의 오픈소스 솔루션인 Central Dogma를 사용하여 동적으로 조정됩니다.</li><li>이를 통해 서비스 운영자는 배포 없이 실시간으로 트래픽 상황에 맞춰 정책을 조정할 수 있습니다.</li></ul></li><li>Note:<ul><li>이 방법은 폭증하는 트래픽에서 서버를 보호하는 방법이지, 트래픽 자체를 해결하는 방법은 아닙니다.</li><li>위의 LINE 의 사례와 같은 Hot Key 문제에 대해서 트래픽 자체를 해결하려면 하나의 샤드로 향하는 트래픽을 다른 샤드들로 분산시키는 것이 필요합니다.</li><li>그래서 일반적인 해결 방법 중 하나는 Shard Key 에다가 Random Number 를 붙혀서 하나의 샤드에서 다른 샤드들로 저장되고 읽을 수 있도록 하는 것입니다. 이를 'Salted Key' 라고도 합니다.</li><li>이 방법으로 할 경우 읽기 요청을 할 때가 문제라서 Hot Key 의 Shard Key 가 어떻게 분산되었는지를 추적할 수 있는 방법을 추가로 필요로 합니다.</li><li>이 방식으로 해결해야한다는 뜻을 말하는 것은 아닙니다. 개인적인 생각으로는 활발한 오픈챗에서 이벤트 전달은 되게 작은 문제라고 보여서 Throttling 하는 것이 더 나은 솔루션 같아 보입니다.</li></ul></li></ul> 2.1 두 번째 문제: 오픈챗 참여 요청이 급증: 인플루언서가 오픈챗 링크를 공유하면서 참여 요청이 갑자기 증가하는 상황이 발생할 수 있습니다. 이로 인해 발생하는 증상은 다음과 같습니다:<ul><li>MySQL Slow Log 증가, CPU 사용률 증가</li><li>OpenChat 서비스의 응답 타임아웃 증가</li></ul> 2.2 해결책: MySQL INSERT 성능 최적화:<ul><li>오픈챗 참여 INSERT 는 단순 INSERT 가 아니라, INSERT 내부에서 SELECT 를 사용하는 쿼리로 구성되어 있습니다. 이는 내부적으로 Bulk Insert 로 취급이 됩니다.</li><li>Bulk Insert 에서 레코드가 Auto Increment 타입의 칼럼을 쓰고 있는 경우 auto_increment_lock_mode=1 로 설정되어 있는 경우에는 Auto Increment 의 값을 연속적으로 증가함을 보장하며 테이블 락을 잡습니다. (MySQL 8.0 이전에는 auto_increment_lock_mode 의 기본 값은 1입니다.)</li><li>그래서 동시에 오픈챗 참여 요청을 하면 이런 테이블락의 경합으로 인해서 CPU 사용률이 치솟는 것입니다.</li><li>이를 auto_increment_lock_mode=2 로 변경하면 Auto Increment 값이 연속적으로 증가함을 보장하지는 않지만, 테이블 락보다 가벼운 Mutex 를 사용해서 더 나은 성능을 낼 수 있습니다.&nbsp;</li><li>모든 기술이 그렇듯이 주의할 점이 있는데&nbsp; auto_increment_lock_mode=2 로 적용할 경우에는 복제에서 statement-based replication 이 아니라 row-based replication 을 적용해야합니다. Auto Increment 값이 연속적으로 증가하지 않기 때문에 복제 서버에서는 다른 값이 될 수 있기 때문입니다.&nbsp;</li></ul> 참여 요청에 대한 Throttling 적용:<ul><li>auto_increment_lock_mode 를 튜닝해서 처리할 수 있는 성능을 높혔더라도, 언제든지 MySQL 이 처리할 수 있는 양보다 훨씬 많은 부하를 받을 수 있습니다.</li><li>여기서 Throttling 을 적용할 때 중요했던 건 Hot Chat Throttling 과 달리 Throttling 을 지연없이 빠르게 적용할 수 있는가 입니다.</li><li>Redis 에서도 참여 요청의 수를 집계해서 Throttling 를 적용할 수도 있지만 얼마 안되는 핫 오픈챗에 대해서 전체 오픈챗에 대해 기록하는 건 큰 오버헤드라고 판단해서 Local Cache 에서 집계를 해서 Throttling 을 적용했습니다.</li></ul> Reference: https://engineering.linecorp.com/ko/blog/how-line-openchat-server-handles-extreme-traffic-spikes

LINE 의 오픈챗 서버는 어떻게 급증하는 트래픽을 다룰까?

AI 시대에 소프트웨어 엔지니어가 필수로 배워야 하는 기초 지식은 다음과 같습니다.

1️⃣ 하나만 배운다면 데이터 구조

2️⃣ 두가질 배운다면 알고리즘

3️⃣ 세가질 배운다면 머신러닝

4️⃣ 네가질 배운다면 프롬프트 엔지니어링

소프트웨어 엔지니어의 주요 업무인 프로그래밍이라는 것은, 주어진 데이터를 변형하거나 데이터를 추출하는 것이 전부라고 할 수 있습니다. 따라서 데이터 구조와 데이터를 다루는 알고리즘을 배우는 것이 기본이겠고요.

더불어 데이터를 통해 소프트웨어를 만들어내는 머신러닝과, 이를 통해 만들어진 AI를 이용하는 프롬프트 엔지니어링을 이해해야 다가오는 AI 시대에 적응 할 수 있을 것 입니다.

즉, 프로그램이, AI가 어떻게 만들어지고 작동하는지, 그리고 AI를 어떻게 다루는지를 이해하는 것이 중요한 것이죠. 왜냐하면 나머지는 이제 앞으로 AI가 다 해 줄 테니까요.

AI 시대에 소프트웨어 엔지니어가 필수로 배워야 하는 기초 지식은 다음과 같습니다. 1️⃣ 하나만 배운다면 데이터 구조 2️⃣ 두가질 배운다면 알고리즘 3️⃣ 세가질 배운다면 머신러닝 4️⃣ 네가질 배운다면 프롬프트 엔지니어링 소프트웨어 엔지니어의 주요 업무인 프로그래밍이라는 것은, 주어진 데이터를 변형하거나 데이터를 추출하는 것이 전부라고 할 수 있습니다. 따라서 데이터 구조와 데이터를 다루는 알고리즘을 배우는 것이 기본이겠고요. 더불어 데이터를 통해 소프트웨어를 만들어내는 머신러닝과, 이를 통해 만들어진 AI를 이용하는 프롬프트 엔지니어링을 이해해야 다가오는 AI 시대에 적응 할 수 있을 것 입니다. 즉, 프로그램이, AI가 어떻게 만들어지고 작동하는지, 그리고 AI를 어떻게 다루는지를 이해하는 것이 중요한 것이죠. 왜냐하면 나머지는 이제 앞으로 AI가 다 해 줄 테니까요.

AI 시대 소프트웨어 엔지니어 필수 지식

자바스크립트 패키지 매니저: npm vs. Yarn

패키지 매니저(package manager)는 프로젝트가 의존하고 있는 패키지를 효과적으로 설치, 갱신, 삭제할 수 있도록 도와주는 관리 도구입니다. 그 어떤 프로그래밍 언어보다 풍부한 오픈 소스 생태계를 자랑하는 자바스크립트에서 특히 패키지 매니저는 중요한 역할을 하는데요. 아무리 간단한 자바스크립트 프로젝트라고 해도 적게는 수십게 많게는 수백개의 다른 패키지에 의존하기 때문입니다.

대부분의 자바스크립트 패키지 매니저는 Node.js 실행 환경(runtime)에서 돌아가며 `package.json`이라는 파일에 프로젝트가 의존하고 있는 패키지 목록을 명시합니다. 일반적으로 패키지는 프로젝트의 `node_modules` 디렉토리에 저장되는데, 주로 공개 npm 저장소(registry)로 부터 다운을 받지만 회사의 경우 사내망 내의 사설 저장소를 운영하는 경우도 있습니다.

자바스크립트 커뮤니티에서는 npm과 Yarn이라는 두 가지 패키지 매니저가 오랫동안 시장을 양분해왔는데요. 이번 포스팅에서는 현재 기준으로 npm과 Yarn을 비교해보고 이중 무엇을 쓰는 게 좋을지 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/js-package-manager/

사실 자바스크립트 생태계에서는 본 포스팅에서 다룬 npm과 Yarn 외에도 Pnpm과 같은 새로운 패키지 매니저가 줄줄이 등장하고 있습니다. 또한 차세대 자바스크립트 런타임인 Bun의 경우에는 아예 패키지 매니저를 내장하고 있어서 어떤 패키지 매니저를 사용할지 고민할 필요도 없습니다. 기본적으로 표준화보다는 자율성을 가치로 삼는 자바스크립트 커뮤니티에서 향후 이 패키지 매니저 전쟁이 어떻게 진행될지 지켜보면 흥미로울 것 같습니다.

패키지 매니저 관련해서 아래 게시물도 함께 읽어보시기를 추천드립니다.

📕 자바스크립트 개발자를 위한 package.json 파일 정리: https://careerly.co.kr/comments/90359
📗 패키지 잠금 파일 (package-lock.json, yarn.lock): https://careerly.co.kr/comments/93535
📘 자바스크립트 개발자를 위한 필수 npm 커맨드 정리 (+npx): https://careerly.co.kr/comments/93003
📙 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임 🥟: https://careerly.co.kr/comments/92202

패키지 매니저(package manager)는 프로젝트가 의존하고 있는 패키지를 효과적으로 설치, 갱신, 삭제할 수 있도록 도와주는 관리 도구입니다. 그 어떤 프로그래밍 언어보다 풍부한 오픈 소스 생태계를 자랑하는 자바스크립트에서 특히 패키지 매니저는 중요한 역할을 하는데요. 아무리 간단한 자바스크립트 프로젝트라고 해도 적게는 수십게 많게는 수백개의 다른 패키지에 의존하기 때문입니다. 대부분의 자바스크립트 패키지 매니저는 Node.js 실행 환경(runtime)에서 돌아가며 `package.json`이라는 파일에 프로젝트가 의존하고 있는 패키지 목록을 명시합니다. 일반적으로 패키지는 프로젝트의 `node_modules` 디렉토리에 저장되는데, 주로 공개 npm 저장소(registry)로 부터 다운을 받지만 회사의 경우 사내망 내의 사설 저장소를 운영하는 경우도 있습니다. 자바스크립트 커뮤니티에서는&nbsp;npm과 Yarn이라는 두 가지 패키지 매니저가 오랫동안 시장을 양분해왔는데요. 이번 포스팅에서는 현재 기준으로 npm과 Yarn을 비교해보고 이중 무엇을 쓰는 게 좋을지 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/js-package-manager/ 사실 자바스크립트 생태계에서는 본 포스팅에서 다룬 npm과 Yarn 외에도 Pnpm과 같은 새로운 패키지 매니저가 줄줄이 등장하고 있습니다. 또한 차세대 자바스크립트 런타임인 Bun의 경우에는 아예 패키지 매니저를 내장하고 있어서 어떤 패키지 매니저를 사용할지 고민할 필요도 없습니다. 기본적으로 표준화보다는 자율성을 가치로 삼는 자바스크립트 커뮤니티에서 향후 이 패키지 매니저 전쟁이 어떻게 진행될지 지켜보면 흥미로울 것 같습니다. 패키지 매니저 관련해서 아래 게시물도 함께 읽어보시기를 추천드립니다. 📕 자바스크립트 개발자를 위한 package.json 파일 정리: https://careerly.co.kr/comments/90359📗 패키지 잠금 파일 (package-lock.json, yarn.lock): https://careerly.co.kr/comments/93535📘 자바스크립트 개발자를 위한 필수 npm 커맨드 정리 (+npx): https://careerly.co.kr/comments/93003📙 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임 🥟: https://careerly.co.kr/comments/92202

Daleseo

자바스크립트 패키지 매니저: npm vs. Yarn 🥊

유명한 프로그램들을 많이 만들었습니다. 카카오톡. N드라이브. 왓챠. 하지만 제 프로그램이라고 부를 수는 없었습니다. 내가 처음부터 만든 게 아니었으니까. 다른 사람들이 만들고 이미 유명해진 상태에서 내가 껴들었을 뿐.

회사를 그만두도록 뽐뿌를 준 책들

유명한 프로그램들을 많이 만들었습니다.
카카오톡. N드라이브. 왓챠.
하지만 제 프로그램이라고 부를 수는 없었습니다.
내가 처음부터 만든 게 아니었으니까.
다른 사람들이 만들고 이미 유명해진 상태에서 내가 껴들었을 뿐.

그래도 좋긴 했습니다.
내 실력으로는 엄두도 못 낼 유명한 프로그램들을 함께 만들고…
지하철에서 옆 사람들이 앱을 써주는 걸 보는 기분은 끝내줬습니다.

그런데 가만…
내가 처음부터 만든 건 뭐가 있지…?
뭐야, 아무것도 없잖아.

책을 읽다가 그런 생각이 들었던 것 같습니다.
나도 내 제품을 만들어 보고 싶어.
아무것도 없는 백지에서 시작한 나의 코드, 나의 제품 말이야.

나도 창업이란 걸 해보고 싶다.
아니, 창업이란 말은 너무 거창하고…
내 제품을 만들어서 그걸로 돈을 벌어 보고 싶어.
단 돈 만 원이라도 벌어봤으면.

그 당시에 저에게 뽐뿌를 줬던 책들.
'플레이', '아이디어맨', '티몬이 간다'

넥슨의 창업이야기.
마이크로소프트의 창업이야기.
티켓몬스터의 창업이야기.

이 책들을 읽을 때 어찌나 가슴이 두근거렸는지…
어쩌면 이 책들을 읽으면서 회사를 떠날 준비를 했는지도 모르겠습니다.
언젠가 다시 한번 읽어보고 싶습니다.

https://jeho.page/essay/2023/11/23/business-books.html

유명한 프로그램들을 많이 만들었습니다. 카카오톡. N드라이브. 왓챠. 하지만 제 프로그램이라고 부를 수는 없었습니다. 내가 처음부터 만든 게 아니었으니까. 다른 사람들이 만들고 이미 유명해진 상태에서 내가 껴들었을 뿐. 그래도 좋긴 했습니다. 내 실력으로는 엄두도 못 낼 유명한 프로그램들을 함께 만들고… 지하철에서 옆 사람들이 앱을 써주는 걸 보는 기분은 끝내줬습니다. 그런데 가만… 내가 처음부터 만든 건 뭐가 있지…? 뭐야, 아무것도 없잖아. 책을 읽다가 그런 생각이 들었던 것 같습니다. 나도 내 제품을 만들어 보고 싶어. 아무것도 없는 백지에서 시작한 나의 코드, 나의 제품 말이야. 나도 창업이란 걸 해보고 싶다. 아니, 창업이란 말은 너무 거창하고… 내 제품을 만들어서 그걸로 돈을 벌어 보고 싶어. 단 돈 만 원이라도 벌어봤으면. 그 당시에 저에게 뽐뿌를 줬던 책들. '플레이', '아이디어맨', '티몬이 간다' 넥슨의 창업이야기. 마이크로소프트의 창업이야기. 티켓몬스터의 창업이야기. 이 책들을 읽을 때 어찌나 가슴이 두근거렸는지…어쩌면 이 책들을 읽으면서 회사를 떠날 준비를 했는지도 모르겠습니다. 언젠가 다시 한번 읽어보고 싶습니다. https://jeho.page/essay/2023/11/23/business-books.html

K리그 프로그래머

01 . 저는 책상에 뭔가 많이 올려두는 걸 좋아하지 않는 편입니다. 집에서 쓰는 책상은 물론이고 회사 책상도 마찬가지죠. 그래서 가끔 팀 사람들이 '도영님은 퇴사하는 사람처럼 퇴근한다'는 우스갯소리를 던지고는 합니다. 출근하면 꺼내 올려두는 게 휴대전화, 에어팟, 노트, 필기구 몇 개 정도니까요. 그마저도 퇴근할 땐 장사판 접는 사장님처럼 말끔하게 회수해(?) 집으로 돌아가니 그런 말이 나올 법도 하죠.

02 . 하지만 제가 유일하게 책상에 자주 올려두는 것이 하나 있습니다. 바로 책입니다.
물론 책상의 일부를 마치 책장처럼 활용하며 여러 권의 책을 꽂아두시는 분들도 있지만 저는 최근 읽고 있는 책 한 권 정도만 책상에 둡니다. 그러니 자연스레 제 주위를 오가던 사람들도 제가 읽고 있는 책에 관심을 기울이고 그 책에 대해 이런저런 질문을 던지기도 하죠.

03 . 당연히 그런 자랑(?) 용도로 책을 두는 것은 아닙니다. 제가 책상에 책을 올려두는 건 일종의 마인드셋에 가깝기 때문이죠.
아무래도 기획 업무를 하다 보니 새로운 업무에 들어가거나 새로운 아이디어를 떠올려야 할 때와 자주 마주치는데 이때마다 저 스스로 어떤 관점과 마음가짐으로 그 업무를 대할지 첫 자세를 잡는 게 참 중요하더라고요. 어떤 때는 하기 싫은 일에 최대한 정을 붙여보려 노력할 때도 있고 또 어떤 때는 꽤 재미있어 보이는 일이라 저 자신이 오버하지 않도록 최대한 차분해지려는 노력을 할 때도 있죠.

04 . 그때마다 저는 그 순간에 필요한 관점을 담은 책들을 한 권씩 올려놓습니다. 그럼 왠지 그 책으로부터 좋은 영향을 받는 것 같은 느낌이 들거든요. 이따끔씩 머리 회전이 잘 안되면 책을 펼쳐서 단 5분이라도 잠깐 읽는 과정을 반복하기도 하지만 사실 꼭 그러지 않더라도 내 가까이에 그 책이 있다는 것만으로도 위로가 될 때가 있습니다. 심지어는 일종의 부적처럼 느껴질 때도 있고요.

05 . 최근에 한 프로젝트에 참여하면서는 '일'에 대한 근본적인 고민과 제 나름의 이야기를 풀어놔야 하는 과제가 주어졌는데, 이때 저는 제 책상 위에 제현주 작가님의 ⟪일하는 마음⟫이란 책을 올려두었습니다. 몇 해 전에 꽤 인상 깊게 읽었던 책이라 언제 한 번 꼭 다시 읽어야지라는 생각을 하고 있었는데 이번 기회에 다시 책상 위로 불러들인 것이죠. 지금이 바로 그 타이밍이라는 생각과 함께요.

06 . 물론 실제로 다시 책을 펼쳐서 읽은 시간은 몇 분 남짓 되지 않았지만 그런 제목의 책이 제 책상을 지켜주고 있다는 사실만으로도 뭔가 마음을 다잡게 되더라고요. 저는 늘 책 한 권을 읽는다는 건 잠깐이나마 그 작가의 생각을 빌어 살아보는 것이라고 생각하는데 제가 좋아하는 책을 끼고 일을 시작하면 조금은 새로운 마음가짐을 장착한 느낌을 받을 때가 많기 때문입니다.

07 . 누군가에게 이 얘기를 했더니 그분이 이런 말을 해주셨습니다.
"그럼 도영님께는 책이 일종의 유니폼 역할을 하는 거네요. 왜 제복을 입는 직업을 가진 사람들은 그 옷을 입는 순간 마음가짐이 달라진다고 하잖아요. 도영님이 책상에 책을 올려두는 것도 비슷한 의미이지 않을까요."

08 . 오! 그 말을 들으니 진짜 제겐 책이 그런 역할을 하는 것 같았어요. 솔직히 가끔 죽기보다도 싫은 일과 마주쳐서 책상에 앉기조차 싫을 때, 문득 책상 한 켠에 있는 책을 보면 일종의 작은 죄책감 같은 것도 느껴지거든요.
'저 책 읽을 때만 해도 온갖 좋은 생각은 다했었는데... 현실에서 또 이렇게 투덜대고만 있을 수는 없겠구나' 하면서요. 책을 읽는 이유 중 하나가 나 자신을 조금이라도 좋은 방향으로 끌고 가기 위함일 텐데 책 읽을 때 마음 따로, 책상에 앉을 때 마음 따로면 그런 나약한 애티튜드도 없겠다 싶었으니까요.

09 . 그래서 저는 주위 사람들에게 당장 읽지 않아도 좋으니 책상 위에 책 한 권 정도 올려두라는 말을 합니다. 그리고 가급적이면 꽂아두지 말고, 여러 권의 책과 함께 두지도 말고 언제든 손을 뻗으면 잡힐 만한 거리에 딱 한 권을 두는 게 더 좋다고 권하죠.
더불어 마치 그곳에 영원히 있을 것처럼 두지 말고 업무에 따라 또 기분에 따라 다른 책으로 바꿔 가져다 두는 걸 반복해 보라고 말합니다. 정말 별것 아닌 일처럼 보여도 그 작은 행동이 주는 마음가짐의 변화가 분명 존재하기 때문이죠.

10 . 그러니 여러분도 한 주의 시작은 맘에 드는 책 한 권 책상 위에 올려두는 것으로 출발하면 어떨까요? 혹시 친한 동료가 있다면 그 사람의 책상 위에 한 권을 선물해 주는 것도 좋고요. 그리고는 귀찮고, 힘들고, 짜증 나고, 하기 싫은 순간이 올 때마다 그냥 그 책 한번 집어 들어서 휘리릭 넘기고 맘에 드는 부분은 5분 정도 가볍게 읽어보는 겁니다. 마음가짐이란 게 거창해 보여도 사실 어떻게 책상 앞에 앉느냐의 문제이기도 하니까요, 그 순간에 맘에 드는 제목이 눈에 띄도록 세팅해두는 것 역시 어쩌면 내 마인드셋을 현명하게 관리하는 비법일지 모르죠.

01 . 저는 책상에 뭔가 많이 올려두는 걸 좋아하지 않는 편입니다. 집에서 쓰는 책상은 물론이고 회사 책상도 마찬가지죠. 그래서 가끔 팀 사람들이 '도영님은 퇴사하는 사람처럼 퇴근한다'는 우스갯소리를 던지고는 합니다. 출근하면 꺼내 올려두는 게 휴대전화, 에어팟, 노트, 필기구 몇 개 정도니까요. 그마저도 퇴근할 땐 장사판 접는 사장님처럼 말끔하게 회수해(?) 집으로 돌아가니 그런 말이 나올 법도 하죠. 02 . 하지만 제가 유일하게 책상에 자주 올려두는 것이 하나 있습니다. 바로 책입니다.물론 책상의 일부를 마치 책장처럼 활용하며 여러 권의 책을 꽂아두시는 분들도 있지만 저는 최근 읽고 있는 책 한 권 정도만 책상에 둡니다. 그러니 자연스레 제 주위를 오가던 사람들도 제가 읽고 있는 책에 관심을 기울이고 그 책에 대해 이런저런 질문을 던지기도 하죠. 03 . 당연히 그런 자랑(?) 용도로 책을 두는 것은 아닙니다. 제가 책상에 책을 올려두는 건 일종의 마인드셋에 가깝기 때문이죠.아무래도 기획 업무를 하다 보니 새로운 업무에 들어가거나 새로운 아이디어를 떠올려야 할 때와 자주 마주치는데 이때마다 저 스스로 어떤 관점과 마음가짐으로 그 업무를 대할지 첫 자세를 잡는 게 참 중요하더라고요. 어떤 때는 하기 싫은 일에 최대한 정을 붙여보려 노력할 때도 있고 또 어떤 때는 꽤 재미있어 보이는 일이라 저 자신이 오버하지 않도록 최대한 차분해지려는 노력을 할 때도 있죠. 04 . 그때마다 저는 그 순간에 필요한 관점을 담은 책들을 한 권씩 올려놓습니다. 그럼 왠지 그 책으로부터 좋은 영향을 받는 것 같은 느낌이 들거든요. 이따끔씩 머리 회전이 잘 안되면 책을 펼쳐서 단 5분이라도 잠깐 읽는 과정을 반복하기도 하지만 사실 꼭 그러지 않더라도 내 가까이에 그 책이 있다는 것만으로도 위로가 될 때가 있습니다. 심지어는 일종의 부적처럼 느껴질 때도 있고요. 05 . 최근에 한 프로젝트에 참여하면서는 '일'에 대한 근본적인 고민과 제 나름의 이야기를 풀어놔야 하는 과제가 주어졌는데, 이때 저는 제 책상 위에 제현주 작가님의 ⟪일하는 마음⟫이란 책을 올려두었습니다. 몇 해 전에 꽤 인상 깊게 읽었던 책이라 언제 한 번 꼭 다시 읽어야지라는 생각을 하고 있었는데 이번 기회에 다시 책상 위로 불러들인 것이죠. 지금이 바로 그 타이밍이라는 생각과 함께요. 06 . 물론 실제로 다시 책을 펼쳐서 읽은 시간은 몇 분 남짓 되지 않았지만 그런 제목의 책이 제 책상을 지켜주고 있다는 사실만으로도 뭔가 마음을 다잡게 되더라고요. 저는 늘 책 한 권을 읽는다는 건 잠깐이나마 그 작가의 생각을 빌어 살아보는 것이라고 생각하는데 제가 좋아하는 책을 끼고 일을 시작하면 조금은 새로운 마음가짐을 장착한 느낌을 받을 때가 많기 때문입니다. 07 . 누군가에게 이 얘기를 했더니 그분이 이런 말을 해주셨습니다."그럼 도영님께는 책이 일종의 유니폼 역할을 하는 거네요. 왜 제복을 입는 직업을 가진 사람들은 그 옷을 입는 순간 마음가짐이 달라진다고 하잖아요. 도영님이 책상에 책을 올려두는 것도 비슷한 의미이지 않을까요." 08 . 오! 그 말을 들으니 진짜 제겐 책이 그런 역할을 하는 것 같았어요. 솔직히 가끔 죽기보다도 싫은 일과 마주쳐서 책상에 앉기조차 싫을 때, 문득 책상 한 켠에 있는 책을 보면 일종의 작은 죄책감 같은 것도 느껴지거든요. '저 책 읽을 때만 해도 온갖 좋은 생각은 다했었는데... 현실에서 또 이렇게 투덜대고만 있을 수는 없겠구나' 하면서요. 책을 읽는 이유 중 하나가 나 자신을 조금이라도 좋은 방향으로 끌고 가기 위함일 텐데 책 읽을 때 마음 따로, 책상에 앉을 때 마음 따로면 그런 나약한 애티튜드도 없겠다 싶었으니까요. 09 . 그래서 저는 주위 사람들에게 당장 읽지 않아도 좋으니 책상 위에 책 한 권 정도 올려두라는 말을 합니다. 그리고 가급적이면 꽂아두지 말고, 여러 권의 책과 함께 두지도 말고 언제든 손을 뻗으면 잡힐 만한 거리에 딱 한 권을 두는 게 더 좋다고 권하죠. 더불어 마치 그곳에 영원히 있을 것처럼 두지 말고 업무에 따라 또 기분에 따라 다른 책으로 바꿔 가져다 두는 걸 반복해 보라고 말합니다. 정말 별것 아닌 일처럼 보여도 그 작은 행동이 주는 마음가짐의 변화가 분명 존재하기 때문이죠. 10 . 그러니 여러분도 한 주의 시작은 맘에 드는 책 한 권 책상 위에 올려두는 것으로 출발하면 어떨까요? 혹시 친한 동료가 있다면 그 사람의 책상 위에 한 권을 선물해 주는 것도 좋고요. 그리고는 귀찮고, 힘들고, 짜증 나고, 하기 싫은 순간이 올 때마다 그냥 그 책 한번 집어 들어서 휘리릭 넘기고 맘에 드는 부분은 5분 정도 가볍게 읽어보는 겁니다. 마음가짐이란 게 거창해 보여도 사실 어떻게 책상 앞에 앉느냐의 문제이기도 하니까요, 그 순간에 맘에 드는 제목이 눈에 띄도록 세팅해두는 것 역시 어쩌면 내 마인드셋을 현명하게 관리하는 비법일지 모르죠.

책상에 좋아하는 책 한 권 올려두기

최근 외주로 운영 되던 서비스를 내재화하는 작업을 담당하게 되면서, 특정 도메인의 목적을 위해 구현된 소스코드를 이해하는 데에는 순전히 '기술적'인 사항만 존재하지 않는다는 사실을 절실히 깨달았습니다. '모바일 쿠폰 서비스'라는 컨택스트 상에서는 당연하고 상식적인 흐름이, 그러한 컨택스트를 제외한 '기술적'요소들만을 살펴보았을 때는 터무니 없이 복잡하고 어렵게 느껴졌습니다.

DDD란? ((Business) Domain-Driven (Software) Design)

최근 팀내에서 논의가 있었다. 내부 툴 Front 단 개발을 어떤 형태로 진행할까에 대한 논의였다. 

보통 '이러한' 개발은 특정 이름 a라고 불리는 팀에 요청하여 처리하였기에, 이번에도 그런 형태로 처리하자고 마무리가 되었다. 내부에서 보면 '뚜렷하게' 차이가 나지 않는 팀 a는 명확히 구분하자면 외부사로, 특정 계약을 통해 프로젝트별로 비용을 지불하는 것으로 보였다. 

그 순간 내 머릿속에 떠오른 질문은 '어떤 기준으로 특정 작업(A)은 외주를 맡기고, 특정 작업(B)은 직접 고용한 인원으로 개발을 진행할까?'였다. 이어서, '그렇다면 내 밥값은 A 대신 B라는 특정 작업을 하고 있다는 사실로 정당한걸까?'였다. 

...

순간 스쳐지나간 생각을 글로 '끌고올' 정도로, 의미가 있다고 느꼈던 이유는

1. 이 부분에 대한 정리된 관점이, 앞으로 커리어를 잘 베팅하는 촉에 대한 도움이 될 것 같기에
2. 언젠가 '보이지 않는' 곳에서 이러한 판단을 내릴 수도 있기에 

라는 2가지 점 때문인 것 같다. 

어쨋든, 이 고민에 좀 더 머물러도 재밌겠다는 생각이 들었다.

이후 정리되지 않은 상태로 문제의 여운을 곰곰히 떠올려본 결과, 두 번째 의문은 쉽게 풀리는 것 같다. 

최근에 읽은 책, 사회학자 Jake Rosenfeld가 쓴 'You're paid what you're worth' [1]라는 책의 내용을 통해서다.

관련 부분은 짧게 요약하자면, "현대 기업은 점점 더 주주친화주의가 강해지면서 비용절감에 대한 요구에 지속적으로 부응하는 정책을 취했다. 기업들은 비핵심 또는 핵심 중에서도 비핵심적인 부분을 아웃소싱하는 형태로 발전해왔다. 또한, 그러한 시장을 만족시키는 아웃소싱 제공 업체도 점점 발전했다. 그렇기에 같은 회사에서 유사한 일을 하지만 소속에 따라서 급격한 임금 및 복지의 격차가 발생하고 있다." 
(논외로 책에서는 정확하게 성과를 측정하고 임금과 연결시키는 점의 어려움, 좋은 잡이 나빠지거나 나쁜 잡이 좋아졌던 히스토리 등 여러 흥미로운 내용을 다뤄준다 - 추천)

감정적으로는 안타깝다는 생각이 들지만, 개인적으로는 어쩔 수 없지 정도로 넘어갈 수 있는 정도의 정리인 것 같다.

...

첫 번째 고민을 생각해보니, 의외로 연관성이 있다고 느껴지는 부분은 꽤나 기술적인 개념에서 떠올랐다. 바로 DDD((Business) Domain-Driven (Software) Design) [2].

DDD에 관해 읽었던, (역시 좋은 책인) Vladik Khononov의 'What Is Domain-Driven Design?'라는 책에서는 비지니스 도메인 분석을 진행하며 서브도메인인 코어, 제너럴, 서포팅에 대하 구분지어 정의하고 있다. 

 * 코어: 경쟁기업과 '다르게' 행하는 부분, 반드시 기술적일 필요 없음, 경쟁자가 복사 및 모방이 어려워야 하기에 본질적으로 복잡, 인하우스로 구현, (기술적인 부분이라면) 높은 수준의 엔지니어를 요구
 * 제너럴: 대다수 기업들이 유사한 형태로 운영하고 있는 활동, 구현된 제품을 구입하는 것이 보통 더욱 비용효율적
 * 서포팅: 기업 비지니스를 지원하는 부분, 어떤 경쟁우위도 제공하지 않음, 인하우스로 구현하는 것에 대한 필요성이 드뭄, 아웃소싱도 고려해볼 수 있음

당시에 책을 읽고 열심히 정리[2]할 때에는 느끼지 못한 부분이 실감되었다. 명확하게 보이진 않지만, 어느 곳에서 진행되고 있는 방향성이 DDD에서 말하는 부분과 일치한다는 느낌이 들었다. 

안그래도 좋았던 DDD에 대한 인상이, 커리어 고민에 대한 도움까지 된다니 더욱 좋아지는 듯 했다.

...

돌아보니 이러한 생각의 흐름에서 찾고 있는 것은 막연한 단어로만 들었던 '고부가가치'를 '개발'에서 찾고 있는 것 같았다.

최근 하는 일에 의미를 찾으며 프로덕트에 대한 관심이 높아졌는데, 역시 이 부분도 프로덕트라는 컨택스트에서야 가치가 평가되는 것 같다. 

현재 컨택스트에서의 고부가가치는 무엇일지, 현재 가지고 있는 능력이 어느 컨택스트에서 고부가가치가 될지라는 또 다른 질문을 만드는 생각들이었다.

Reference
[1] You're paid what you're worth, Jave Rosenfeld
[2] https://kadensungbincho.tistory.com/73
[3] What Is Domain-Driven Design?, Vladik Khononov

최근 팀내에서 논의가 있었다. 내부 툴 Front 단 개발을 어떤 형태로 진행할까에 대한 논의였다.&nbsp; 보통 '이러한' 개발은 특정 이름 a라고 불리는 팀에 요청하여 처리하였기에, 이번에도 그런 형태로 처리하자고 마무리가 되었다. 내부에서 보면 '뚜렷하게' 차이가 나지 않는 팀 a는 명확히 구분하자면 외부사로, 특정 계약을 통해 프로젝트별로 비용을 지불하는 것으로 보였다.&nbsp; 그 순간 내 머릿속에 떠오른 질문은 '어떤 기준으로 특정 작업(A)은 외주를 맡기고, 특정 작업(B)은 직접 고용한 인원으로 개발을 진행할까?'였다. 이어서, '그렇다면 내 밥값은 A 대신 B라는 특정 작업을 하고 있다는 사실로 정당한걸까?'였다.&nbsp; ... 순간 스쳐지나간 생각을 글로 '끌고올' 정도로, 의미가 있다고 느꼈던 이유는 1. 이 부분에 대한 정리된 관점이, 앞으로 커리어를 잘 베팅하는 촉에 대한 도움이 될 것 같기에2. 언젠가 '보이지 않는' 곳에서 이러한 판단을 내릴 수도 있기에&nbsp; 라는 2가지 점 때문인 것 같다.&nbsp; 어쨋든, 이 고민에 좀 더 머물러도 재밌겠다는 생각이 들었다. 이후 정리되지 않은 상태로 문제의 여운을 곰곰히 떠올려본 결과, 두 번째 의문은 쉽게 풀리는 것 같다.&nbsp; 최근에 읽은 책, 사회학자 Jake Rosenfeld가 쓴 'You're paid what you're worth' [1]라는 책의 내용을 통해서다. 관련 부분은 짧게 요약하자면, "현대 기업은 점점 더 주주친화주의가 강해지면서 비용절감에 대한 요구에 지속적으로 부응하는 정책을 취했다. 기업들은 비핵심 또는 핵심 중에서도 비핵심적인 부분을 아웃소싱하는 형태로 발전해왔다. 또한, 그러한 시장을 만족시키는 아웃소싱 제공 업체도 점점 발전했다. 그렇기에 같은 회사에서 유사한 일을 하지만 소속에 따라서 급격한 임금 및 복지의 격차가 발생하고 있다."&nbsp;(논외로 책에서는 정확하게 성과를 측정하고 임금과 연결시키는 점의 어려움, 좋은 잡이 나빠지거나 나쁜 잡이 좋아졌던 히스토리 등 여러 흥미로운 내용을 다뤄준다 - 추천) 감정적으로는 안타깝다는 생각이 들지만, 개인적으로는 어쩔 수 없지 정도로 넘어갈 수 있는 정도의 정리인 것 같다. ... 첫 번째 고민을 생각해보니, 의외로 연관성이 있다고 느껴지는 부분은 꽤나 기술적인 개념에서 떠올랐다. 바로 DDD((Business) Domain-Driven (Software) Design) [2]. DDD에 관해 읽었던, (역시 좋은 책인) Vladik Khononov의 'What Is Domain-Driven Design?'라는 책에서는 비지니스 도메인 분석을 진행하며 서브도메인인 코어, 제너럴, 서포팅에 대하 구분지어 정의하고 있다.&nbsp; <ul><li>코어: 경쟁기업과 '다르게' 행하는 부분, 반드시 기술적일 필요 없음, 경쟁자가 복사 및 모방이 어려워야 하기에 본질적으로 복잡, 인하우스로 구현, (기술적인 부분이라면) 높은 수준의 엔지니어를 요구</li><li>제너럴: 대다수 기업들이 유사한 형태로 운영하고 있는 활동, 구현된 제품을 구입하는 것이 보통 더욱 비용효율적</li><li>서포팅: 기업 비지니스를 지원하는 부분, 어떤 경쟁우위도 제공하지 않음, 인하우스로 구현하는 것에 대한 필요성이 드뭄, 아웃소싱도 고려해볼 수 있음</li></ul> 당시에 책을 읽고 열심히 정리[2]할 때에는 느끼지 못한 부분이 실감되었다. 명확하게 보이진 않지만, 어느 곳에서 진행되고 있는 방향성이 DDD에서 말하는 부분과 일치한다는 느낌이 들었다.&nbsp; 안그래도 좋았던 DDD에 대한 인상이, 커리어 고민에 대한 도움까지 된다니 더욱 좋아지는 듯 했다. ... 돌아보니 이러한 생각의 흐름에서 찾고 있는 것은 막연한 단어로만 들었던 '고부가가치'를 '개발'에서 찾고 있는 것 같았다. 최근 하는 일에 의미를 찾으며 프로덕트에 대한 관심이 높아졌는데, 역시 이 부분도 프로덕트라는 컨택스트에서야 가치가 평가되는 것 같다.&nbsp; 현재 컨택스트에서의 고부가가치는 무엇일지, 현재 가지고 있는 능력이 어느 컨택스트에서 고부가가치가 될지라는 또 다른 질문을 만드는 생각들이었다. Reference[1] You're paid what you're worth, Jave Rosenfeld[2] https://kadensungbincho.tistory.com/73[3] What Is Domain-Driven Design?, Vladik Khononov

Kaden Sungbin Cho

고부가가치 개발

1 작년 9월 블로그를 시작했다. 1년 조금 넘는 동안 약 400개의 글을 썼다. 2 시작은 단순했다. 목적은 성...

기록이 쌓이면 '뭐든' 된다. 블로그 1년의 소회.

1
작년 9월 블로그를 시작했다. 1년 조금 넘는 동안 약 400개의 글을 썼다.

2
시작은 단순했다. 목적은 성장이었다. 성장하기 위해 읽고 쓰기보다 좋은 방법은 없으니까.

3
문제는 꾸준함이다. 뭐든 혼자서는 오래 하기 어렵다. 작은 성취감과 소소한 재미가 필요했다. 그래서 블로그에 기록들을 쌓기로 했다.

4
읽은 책과 생각을 기록한다. 나를 위한 기록이다. 나를 위함으로 시작하지만, 다른 사람에게 도움이 되면 좋겠다는 마음도 있었다. 의도할 수는 없다. 어떻게든 되겠지 싶었다.

5
기록은 쉽지 않았다. 글쓰기는 언제나 어려우니까. 유일한 위안이라면 모두에게 다 그렇다는 거다. 훌륭한 작가들에게도 절대 예외는 없다. 그냥 계속 쓸 뿐이다. 쓰고 쓰고 또 쓴다. 미련하게.

6
많이 쓴다고 글쓰기가 쉬워지지 않는다. 익숙해지지 않는다. 나를 위한 기록이지만 잘 쓰고 싶다. 하지만 결과물은 항상 마음에 들지 않는다. 몇 번을 고민해서 퇴고하고 발행 버튼을 눌러도 늘 찜찜할 뿐이다.

7
고비들도 많았다. 작은 공간에 남기는 이 기록이 무슨 의미가 있을까. 나보다 남들의 시선을 더 의식하기도 했다. 보는 눈이 없어도 자기검열은 사라지지 않는다. 때론 글쓰기에 도저히 시간을 낼 수 없을 때도 많았다.

8
그래도 1년 동안 놓지 않았다. 뭐라도 기록하고 남겼다. 놓지 않은 덕분에 성장했다. 나의 기록이 누군가에게 작은 도움이 된다. 기록이 새로운 연결의 시작이 됐다. 기쁘다.

9
기록이 쌓이면 뭐든 된다. 블로그 앱 스플래시 문구가 맘에 든다. 정말 그렇다. 한물간 서비스로 취급받던 블로그가 다시 대세가 됐다. 20년의 시간을 버텨왔기 때문이다. 중간에 놓지 않았기 때문이다.

10
모든 꾸준한 것들은 늘 사소하다. 사소함은 잘 보이지 않는다. 그래서 그것이 드러나면 모두 다 갑자기 나타났다고들 말한다. 하지만, 누구의 눈에도 보이지 않던 때를 놓지 않고 버텼기에 드러남의 시간이 있다. 축적과 발산. 모든 성장과 성공의 비밀은 여기에 있다. 예외는 없다고 믿는다.

1작년 9월 블로그를 시작했다. 1년 조금 넘는 동안 약 400개의 글을 썼다. ​ ​2시작은 단순했다. 목적은 성장이었다. 성장하기 위해 읽고 쓰기보다 좋은 방법은 없으니까. ​ ​3문제는 꾸준함이다. 뭐든 혼자서는 오래 하기 어렵다. 작은 성취감과 소소한 재미가 필요했다. 그래서 블로그에 기록들을 쌓기로 했다. ​ ​4읽은 책과 생각을 기록한다. 나를 위한 기록이다. 나를 위함으로 시작하지만, 다른 사람에게 도움이 되면 좋겠다는 마음도 있었다. 의도할 수는 없다. 어떻게든 되겠지 싶었다. ​ ​5기록은 쉽지 않았다. 글쓰기는 언제나 어려우니까. 유일한 위안이라면 모두에게 다 그렇다는 거다. 훌륭한 작가들에게도 절대 예외는 없다. 그냥 계속 쓸 뿐이다. 쓰고 쓰고 또 쓴다. 미련하게. ​ ​6많이 쓴다고 글쓰기가 쉬워지지 않는다. 익숙해지지 않는다. 나를 위한 기록이지만 잘 쓰고 싶다. 하지만 결과물은 항상 마음에 들지 않는다. 몇 번을 고민해서 퇴고하고 발행 버튼을 눌러도 늘 찜찜할 뿐이다. ​ ​7고비들도 많았다. 작은 공간에 남기는 이 기록이 무슨 의미가 있을까. 나보다 남들의 시선을 더 의식하기도 했다. 보는 눈이 없어도 자기검열은 사라지지 않는다. 때론 글쓰기에 도저히 시간을 낼 수 없을 때도 많았다. ​ ​8그래도 1년 동안 놓지 않았다. 뭐라도 기록하고 남겼다. 놓지 않은 덕분에 성장했다. 나의 기록이 누군가에게 작은 도움이 된다. 기록이 새로운 연결의 시작이 됐다. 기쁘다. ​ ​9기록이 쌓이면 뭐든 된다. 블로그 앱 스플래시 문구가 맘에 든다. 정말 그렇다. 한물간 서비스로 취급받던 블로그가 다시 대세가 됐다. 20년의 시간을 버텨왔기 때문이다. 중간에 놓지 않았기 때문이다. ​ ​10모든 꾸준한 것들은 늘 사소하다. 사소함은 잘 보이지 않는다. 그래서 그것이 드러나면 모두 다 갑자기 나타났다고들 말한다. 하지만, 누구의 눈에도 보이지 않던 때를 놓지 않고 버텼기에 드러남의 시간이 있다. 축적과 발산. 모든 성장과 성공의 비밀은 여기에 있다. 예외는 없다고 믿는다.

네이버 블로그 | 가장 보통의 스타트업 CEO

블로그에 글을 쓴 지 1년이 됐다.

1. 다이렉트 메일에선 ‘영업하는 분위기를 풍기지 말아야 한다’는 원리원칙을 지켜야 한다. (이는 다른 콘텐츠 마케팅 분야에서도 마찬가지다)

2. 처음부터 영업하는 분위기를 풍기면, 고객은 그만큼 감정적으로 반발하게 되고, 당연히 심리적 장벽을 구축한다. 그리고 그 장벽을 제거하는 건 매우 어렵다.

3. 따라서 다이렉트 메일의 경우, 봉투를 집어 들었을 때 영업이라는 분위기를 느끼지 않게 제작해야 한다.

4. 또한, 다이렉트 메일을 보낼 땐, 고객에게 이득은 있어도 리스크는 전혀 없는 제안을 해야 한다. “무료로 샘플을 보내드립니다. 하지만 이후 구입해야 할 의무는 없습니다” 같은 제안 말이다.

5. 더불어 “샘플을 요청하십시오”라고 말하는 게 아니라, “무료로 샘플을 보낼 테니 (부디) 허락만 해주십시오”라고 말하는 게 좋다.

6. 마지막으로, 고객에게 다음 행동을 하도록 만들기 위해 필요한 모든 정보를 담아야 한다. 그래서 다이렉트 메일의 문장은 매우 길다. 인사에서부터 상품 내용, 거래할 경우의 이익, 매장 내부 디스플레이 이미지 등 상세하게 설명해야 한다.

7. (물론) ‘이렇게 긴 문장을 누가 읽겠어?’라고 생각할 수도 있다. (대부분의) 회사에서는 “사람들은 바쁘다. 가능하면 간결한 문장으로 만들어야 한다”고 가르친다. 하지만 (콘텐츠 마케팅에서) 이건 (대단히) 잘못된 가르침이다.

8. 재미있으면 긴 문장이라도 읽는다. 그리고 그 문장을 읽는 사람은 결국 그 제품에 흥미가 있는 고객이다. 그리고 흥미가 있는 고객에게 다음 행동을 유도하려면 (고객이) 필요한 정보를 모두 제공해야 한다.

9. 사람은 정보가 부족한 경우에는, 리스크를 먼저 느끼기 때문에 행동하지 않는다.

10. 많은 회사들의 다이렉트 메일이 실패하는 이유는 이 때문이다. 기본적으로 “우리 제품은 훌륭하니, 부디 검토해주세요”라는 (영업 멘트와) 상품 설명만 들어있기 때문이다. 잠깐만 생각해봐도 알 수 있듯이, 영업 사원이 방문해서 “이 제품은 훌륭하니 부디 검토해주세요”라는 말만 한다면 계약이 성사될 리가 없다.

11. 그렇기 때문에 다이렉트 메일은 문장이 길어져도 필요한 정보를 모두 담는 것이 좋다. (다른 콘텐츠 마케팅도 마찬가지다. 다만, 그러려면 기본적으로 글을 잘 써야 한다)

12. 그리고 이렇게 다이렉트 메일을 설계하면 영업 과정은 매우 간단해진다. 왜냐, 결정하는 데 필요한 모든 정보가 이미 메일 안에 다 들어가 있기 때문이다.

13. 따라서 영업사원은 고객을 설득할 필요가 없다. 그저 영원사원이 하는 일은 고객의 질문에 (성실히) 대답해주는 것뿐이다. (고로) 영업용 화술을 발휘하거나 영업을 유도하는 테크닉은 필요 없다.

14. 그러니 (제품에 대한 충분한 설명이 담긴 문서나 콘텐츠가 있으면) 영업 기술이 부족한 신입사원이라고 해도 계약을 성사시킬 수 있다.

- 간다 마사노리, <90일 만에 당신의 회사를 고수익 기업으로 바꿔라> 중

1. 다이렉트 메일에선 ‘영업하는 분위기를 풍기지 말아야 한다’는 원리원칙을 지켜야 한다. (이는 다른 콘텐츠 마케팅 분야에서도 마찬가지다) 2. 처음부터 영업하는 분위기를 풍기면, 고객은 그만큼 감정적으로 반발하게 되고, 당연히 심리적 장벽을 구축한다. 그리고 그 장벽을 제거하는 건 매우 어렵다. 3. 따라서 다이렉트 메일의 경우, 봉투를 집어 들었을 때 영업이라는 분위기를 느끼지 않게 제작해야 한다. 4. 또한, 다이렉트 메일을 보낼 땐, 고객에게 이득은 있어도 리스크는 전혀 없는 제안을 해야 한다. “무료로 샘플을 보내드립니다. 하지만 이후 구입해야 할 의무는 없습니다” 같은 제안 말이다. 5. 더불어 “샘플을 요청하십시오”라고 말하는 게 아니라, “무료로 샘플을 보낼 테니 (부디) 허락만 해주십시오”라고 말하는 게 좋다. 6. 마지막으로, 고객에게 다음 행동을 하도록 만들기 위해 필요한 모든 정보를 담아야 한다. 그래서 다이렉트 메일의 문장은 매우 길다. 인사에서부터 상품 내용, 거래할 경우의 이익, 매장 내부 디스플레이 이미지 등 상세하게 설명해야 한다. 7. (물론) ‘이렇게 긴 문장을 누가 읽겠어?’라고 생각할 수도 있다. (대부분의) 회사에서는 “사람들은 바쁘다. 가능하면 간결한 문장으로 만들어야 한다”고 가르친다. 하지만 (콘텐츠 마케팅에서) 이건 (대단히) 잘못된 가르침이다. 8. 재미있으면 긴 문장이라도 읽는다. 그리고 그 문장을 읽는 사람은 결국 그 제품에 흥미가 있는 고객이다. 그리고 흥미가 있는 고객에게 다음 행동을 유도하려면 (고객이) 필요한 정보를 모두 제공해야 한다. 9. 사람은 정보가 부족한 경우에는, 리스크를 먼저 느끼기 때문에 행동하지 않는다. 10. 많은 회사들의 다이렉트 메일이 실패하는 이유는 이 때문이다. 기본적으로 “우리 제품은 훌륭하니, 부디 검토해주세요”라는 (영업 멘트와) 상품 설명만 들어있기 때문이다. 잠깐만 생각해봐도 알 수 있듯이, 영업 사원이 방문해서 “이 제품은 훌륭하니 부디 검토해주세요”라는 말만 한다면 계약이 성사될 리가 없다. 11. 그렇기 때문에 다이렉트 메일은 문장이 길어져도 필요한 정보를 모두 담는 것이 좋다. (다른 콘텐츠 마케팅도 마찬가지다. 다만, 그러려면 기본적으로 글을 잘 써야 한다) 12. 그리고 이렇게 다이렉트 메일을 설계하면 영업 과정은 매우 간단해진다. 왜냐, 결정하는 데 필요한 모든 정보가 이미 메일 안에 다 들어가 있기 때문이다. 13. 따라서 영업사원은 고객을 설득할 필요가 없다. 그저 영원사원이 하는 일은 고객의 질문에 (성실히) 대답해주는 것뿐이다. (고로) 영업용 화술을 발휘하거나 영업을 유도하는 테크닉은 필요 없다. 14. 그러니 (제품에 대한 충분한 설명이 담긴 문서나 콘텐츠가 있으면) 영업 기술이 부족한 신입사원이라고 해도 계약을 성사시킬 수 있다. - 간다 마사노리, &lt;90일 만에 당신의 회사를 고수익 기업으로 바꿔라&gt; 중

콘텐츠 마케팅을 할 때 대부분의 사람들이 흔히 저지르는 실수들

New Instagram test brings back the chronological feed

[Issue #164] "📌인스타그램 피드 변화 예고?"

인스타그램이 콘텐츠 피드 개편을 테스트 중이라고 밝혔습니다. 아담 모세리의 트위터에 따르면, 인스타그램은 총 3개의 피드를 도입할 예정이라고 해요. 현재 버전의 HOME, 내가 좋아하는 크리에이터, 친구들의 포스트만 볼 수 있는 FAVORITE, 팔로우 중인 모든 계정의 포스트가 알고리즘 없이 순서대로 나열되는 FOLLOWING. 이렇게 3개의 탭을 스위칭 할 수 있는 구조로 보이네요.

작년 연말, 메타(전 페이스북)가 청문회에서 지적받은 내용을 다들 기억하실 텐데요. 체류시간을 늘리기 위한 알고리즘 중심의 피드에서 벗어나, 유저가 포스팅한 순서에 맞춰 콘텐츠가 보여지는 <Chronological Feed>가 반영되는 점이 눈길을 끕니다.

The Verge

커리어리 Lead Community Manager

최자민

지금까지 신규 사업 팀 초기 멤버로 일하며 콘텐츠 혹은 사람을 발굴해왔습니다. “Frontiers are where you find them.” 이라는 문장을 마음에 새기며 일하고 있습니다. 
#콘텐츠기획 #콘텐츠제작 #커뮤니티기획

이은지

스타트업에서 주니어 기획자 겸 PM직을 맡고 있습니다.

커리어리 Product Manager

김명찬

링컨, 알렉스 퍼거슨, 빌리 빈을 존경합니다.

#프로덕트매니저 #데이터분석

브랜드 마케터

IT 서비스의 브랜드 마케터 셋이 모였습니다. 문제 해결을 위해 늘 새로운 소식을 보고, 경험하고, 실험해 봅니다. 각자 다른 배경과 강점을 가지고 좋은 시너지를 만들어 내고 있습니다. 일주일에 딱 다섯 가지 마케팅 이슈를 정리해 발행하는 뉴스레터 '위클리 파이브'를 운영했고, 지금은 퍼블리 뉴스 큐레이터로 활동하고 있습니다.

위클리 파이브

<위클리파이브> 카카오톡 채널

IT 서비스의 브랜드 마케터입니다.  문제 해결을 위해 늘 새로운 소식을 보고, 경험하고, 학습해야만 하는 일을 하고 있습니다. 현업에서 일하면서 접하는 새롭고 흥미로운 소식들을 공유합니다.

댓글 0