신입 사원 때 회사의 CTO 이자 수석 프로그래머였던 분이 말씀하셨습니다. 프로그래머는 손톱이 짧아야 한다고. 손톱이 길면 코딩하는 사람이 아니라고. 완전히 동감했습니다. 개발자라면 다들 동감할 겁니다. 손톱이 길 때 키보드에 닿는 그 느낌이 얼마나 싫은지. 손톱을 일주일에 두 번쯤 자릅니다. 아주 조금만 튀어나와도 그 느낌 때문에 코딩을 할 수가 없거든요.

프로그래머의 손톱

신입 사원 때 회사의 CTO 이자 수석 프로그래머였던 분이 말씀하셨습니다.
프로그래머는 손톱이 짧아야 한다고. 손톱이 길면 코딩하는 사람이 아니라고. 완전히 동감했습니다.
개발자라면 다들 동감할 겁니다. 손톱이 길 때 키보드에 닿는 그 느낌이 얼마나 싫은지.
손톱을 일주일에 두 번쯤 자릅니다. 아주 조금만 튀어나와도 그 느낌 때문에 코딩을 할 수가 없거든요.

예전에 어떤 대기업에 다닐 때 일입니다.
누군가 전체 게시판에 손톱에 대해 글을 썼습니다.
제발 사무실에서 손톱 좀 자르지 말라고. 딱딱 거리는 소리 아주 듣기 싫어 죽겠다고.
댓글이 무척이나 뜨거웠던 걸로 기억합니다. 모두가 볼 수 있는 전체 게시판이었으니까요.

말투가 너무 공격적이었기 때문에 비추를 많이 받았던 걸로 기억하지만…
생각해 보면 의견 자체는 타당한 것 같았습니다.
저 정도로 듣기 싫어하는 사람들이 있는데 내 약간의 편의를 위해서 손톱을 사무실에서 잘라야 하는가?

솔직히 말하면 저도 사무실에서 손톱을 자르는 사람 중 하나였습니다.
그 글을 본 이후 손톱을 자를 때마다 미안한 마음이 들었습니다. 결국 손톱깎이를 집으로 다시 가져왔습니다. 😂

https://jeho.page/essay/2025/03/17/programmer-nails.html

신입 사원 때 회사의 CTO 이자 수석 프로그래머였던 분이 말씀하셨습니다. 프로그래머는 손톱이 짧아야 한다고. 손톱이 길면 코딩하는 사람이 아니라고. 완전히 동감했습니다. 개발자라면 다들 동감할 겁니다. 손톱이 길 때 키보드에 닿는 그 느낌이 얼마나 싫은지. 손톱을 일주일에 두 번쯤 자릅니다. 아주 조금만 튀어나와도 그 느낌 때문에 코딩을 할 수가 없거든요. 예전에 어떤 대기업에 다닐 때 일입니다. 누군가 전체 게시판에 손톱에 대해 글을 썼습니다. 제발 사무실에서 손톱 좀 자르지 말라고. 딱딱 거리는 소리 아주 듣기 싫어 죽겠다고. 댓글이 무척이나 뜨거웠던 걸로 기억합니다. 모두가 볼 수 있는 전체 게시판이었으니까요. 말투가 너무 공격적이었기 때문에 비추를 많이 받았던 걸로 기억하지만… 생각해 보면 의견 자체는 타당한 것 같았습니다. 저 정도로 듣기 싫어하는 사람들이 있는데 내 약간의 편의를 위해서 손톱을 사무실에서 잘라야 하는가? 솔직히 말하면 저도 사무실에서 손톱을 자르는 사람 중 하나였습니다. 그 글을 본 이후 손톱을 자를 때마다 미안한 마음이 들었습니다. 결국 손톱깎이를 집으로 다시 가져왔습니다. 😂 https://jeho.page/essay/2025/03/17/programmer-nails.html

K리그 프로그래머

저도 손톱 닿는 느낌이 불편해서 바로 깎는편인데 화장실에서 자르고 있습니다
바로 안자르면 하루종일 불편할 때가 많아서 ㅋ

1️⃣ 아이디어의 가치는 실행했을 때 비로소 생긴다.

2️⃣ 고객이 정말 필요한 서비스를 만들어야 한다. 내가 고객인 서비스라면 더 수월하다.

3️⃣ 빠르게 만들고 빠르게 출시한다. 개발 기간이 길다고 더 좋은 서비스가 나오는 건 아니다.

4️⃣ 한 가지 핵심 기능에 집중하는 것이 좋다. 너무 많은 기능을 넣기보다 문제 해결에 초점을 맞춘다.

5️⃣ 나는 생각보다 고객의 마음을 생각보다 잘 모른다. 출시 후 피드백을 받아야 비로소 알게 되는 경우가 많았다.

6️⃣ 개발은 가장 비싼 검증 방법이다.
본격적으로 개발하기 전에 아이디어 검증이 가능하다면 반드시 검증부터 한다.

7️⃣ “시장의 크기 = 문제를 겪는 사람의 수 × 고통의 크기” 이다.
문제를 겪는 사람의 수는 적더라도 고통의 크기가 큰 문제를 해결하는 것이 유리하다.

8️⃣ 보일러플레이트(템플릿)를 만들어두면 멘탈 관리에 좋다.
로그인, 모달, 레이아웃 등 자주 쓰이는 기능을 미리 모듈화하면 개발이 훨씬 수월하다.

9️⃣ 사이드 프로젝트는 최소 1년은 유지해보는 것이 좋다.
언제 터질지 모르므로 Free Tier로 운영할 수 있는 1년 정도는 지켜본다.

🔟 결국, 대부분의 성공은 운이다.
기본적인 것을 지킨다는 전제하에, 성공 여부는 운에 의해 결정될 때가 많다.
그래서 꾸준히 만들고, 실패하며, 경험치를 쌓아가는 과정이 중요하다.

실행이 전부다. 만들고 배운다.

1️⃣ 아이디어의 가치는 실행했을 때 비로소 생긴다. 2️⃣ 고객이 정말 필요한 서비스를 만들어야 한다. 내가 고객인 서비스라면 더 수월하다. 3️⃣ 빠르게 만들고 빠르게 출시한다. 개발 기간이 길다고 더 좋은 서비스가 나오는 건 아니다. 4️⃣ 한 가지 핵심 기능에 집중하는 것이 좋다. 너무 많은 기능을 넣기보다 문제 해결에 초점을 맞춘다. 5️⃣ 나는 생각보다 고객의 마음을 생각보다 잘 모른다. 출시 후 피드백을 받아야 비로소 알게 되는 경우가 많았다. 6️⃣ 개발은 가장 비싼 검증 방법이다.본격적으로 개발하기 전에 아이디어 검증이 가능하다면 반드시 검증부터 한다. 7️⃣ “시장의 크기 = 문제를 겪는 사람의 수 × 고통의 크기” 이다.문제를 겪는 사람의 수는 적더라도 고통의 크기가 큰 문제를 해결하는 것이 유리하다. 8️⃣ 보일러플레이트(템플릿)를 만들어두면 멘탈 관리에 좋다.로그인, 모달, 레이아웃 등 자주 쓰이는 기능을 미리 모듈화하면 개발이 훨씬 수월하다. 9️⃣ 사이드 프로젝트는 최소 1년은 유지해보는 것이 좋다.언제 터질지 모르므로 Free Tier로 운영할 수 있는 1년 정도는 지켜본다. 🔟 결국, 대부분의 성공은 운이다.기본적인 것을 지킨다는 전제하에, 성공 여부는 운에 의해 결정될 때가 많다.그래서 꾸준히 만들고, 실패하며, 경험치를 쌓아가는 과정이 중요하다. 실행이 전부다. 만들고 배운다.

사이드 프로젝트 34개를 만들고 느낀점 10가지

각각의 해결안은 다음 문제의 근원이다. 문제를 이해할 때, 잘못될 수 있는 경우를 적어도 세 가지 이상 생각해내지 못 한다면 당신은 문제를 이해하지 못한 것이다.

우리는 부작용을 특정한 해결안에서 나온 자연스러운 결과로 간주하는 경향이 있다. ‘부작용들은 발생하지 않을 수도 있고 만약 발생한다 하더라도 항상 그것을 제거할 수 있는 해결책을 찾을 수 있다. 이런 순진한 생각이 얼마나 자주 우리를 곤경으로 몰아가는가?

<대체 뭐가 문제야>, 제럴드 M. 와인버그

https://www.instagram.com/p/DHXBa-3TLjT/?igsh=MXI5aWQ2NTQ5ajVu

각각의 해결안은 다음 문제의 근원이다. 문제를 이해할 때, 잘못될 수 있는 경우를 적어도 세 가지 이상 생각해내지 못 한다면 당신은 문제를 이해하지 못한 것이다. 우리는 부작용을 특정한 해결안에서 나온 자연스러운 결과로 간주하는 경향이 있다. ‘부작용들은 발생하지 않을 수도 있고 만약 발생한다 하더라도 항상 그것을 제거할 수 있는 해결책을 찾을 수 있다. 이런 순진한 생각이 얼마나 자주 우리를 곤경으로 몰아가는가? &lt;대체 뭐가 문제야&gt;, 제럴드 M. 와인버그 https://www.instagram.com/p/DHXBa-3TLjT/?igsh=MXI5aWQ2NTQ5ajVu

트레바리 <리서치 하는데요> 북클럽에서 꼽은 문장들

사실상 엑셀이나 구글 시트가 아닌가 싶다. 이만큼 많은 사람들이 쓸 줄 알고 여러 형태로 분석이 가능하고 결과물을 공유 가능한 툴은 많지 않다. 실제 현업부서들과 일을 해보면 굉장히 많은 데이터들을 구글 시트의 형태로 매뉴얼하게 관리한다. 이 위에서 간단한 차트등을 만들어 지표 관리를 하곤 한다.

즉 데이터 엔지니어의 관점에서 보면 구글 시트는 아주 중요한 데이터 소스가 된다. 문제는 필요한 데이터를 여기로 로딩하는 방법인데 적어도 구글 시트는 Sheet API(파이썬 모듈 중에 gspread 사용)와 여러 형태의 연동 툴들을 제공한다. 유데미 때 구글 시트를 데이터 소스로 다양한 매뉴얼 정보들을 데이터 웨어하우스로 로딩하는 ETL 파이프라인을 구현해서 현업 팀원들 (마케팅, CS/CX, 영업 등등)이 아주 좋아했었다.

또 회사에 돈이 충분치 않다면 혹은 돈이 충분해도 BI 관련해서 아직 무엇을 해야할지 불분명하다면 굳이 비싼 BI 툴들(Looker, Tableau, 등등)을 사지 말고 데이터웨어하우스(혹은 프로덕션 데이터베이스)의 써머리 테이블들을 구글스프레드시트로 자동으로 덤프해서 거기서 시각화하고 분석하는 것도 아주 효율적이다. 이 역시 다양한 회사에서 데이터 컨설팅을 하면서 효율적으로 사용했었는데 이 경우 이런 형태의 데이터 파이프라인을 보통 Reverse ETL이라고 부른다. 즉 소스가 데이터 웨어하우스가 되고 타켓이 시트가 되는 형태로 일반적인 ETL의 반대 방향으로 데이터가 흐르는 거다.

이번에 인프런에 만든 강의 뒷 부분에 새로 아래 두 개의 챕터를 추가했는데 이게 바로 구글 시트를 데이터소스로 보고 시트 정보를 읽어다가 Snowflake의 테이블로 적재하는 과정을 설명하고 데모하는 내용으로 구성되어 있다. 곧 Reverse ETL 내용 (Snowflake -> 구글시트)에 관한 챕터도 추가할 예정이다.

 * 구글 시트 ➜ Snowflake
 * 구글 시트 ➜ Snowflake (코드 리뷰와 실습)

"실리콘밸리 데이터 리더가 알려주는 Airflow 기초": https://inf.run/qRing

사실상 엑셀이나 구글 시트가 아닌가 싶다. 이만큼 많은 사람들이 쓸 줄 알고 여러 형태로 분석이 가능하고 결과물을 공유 가능한 툴은 많지 않다. 실제 현업부서들과 일을 해보면 굉장히 많은 데이터들을 구글 시트의 형태로 매뉴얼하게 관리한다. 이 위에서 간단한 차트등을 만들어 지표 관리를 하곤 한다. 즉 데이터 엔지니어의 관점에서 보면 구글 시트는 아주 중요한 데이터 소스가 된다. 문제는 필요한 데이터를 여기로 로딩하는 방법인데 적어도 구글 시트는 Sheet API(파이썬 모듈 중에 gspread 사용)와 여러 형태의 연동 툴들을 제공한다. 유데미 때 구글 시트를 데이터 소스로 다양한 매뉴얼 정보들을 데이터 웨어하우스로 로딩하는 ETL 파이프라인을 구현해서 현업 팀원들 (마케팅, CS/CX, 영업 등등)이 아주 좋아했었다. 또 회사에 돈이 충분치 않다면 혹은 돈이 충분해도 BI 관련해서 아직 무엇을 해야할지 불분명하다면 굳이 비싼 BI 툴들(Looker, Tableau, 등등)을 사지 말고 데이터웨어하우스(혹은 프로덕션 데이터베이스)의 써머리 테이블들을 구글스프레드시트로 자동으로 덤프해서 거기서 시각화하고 분석하는 것도 아주 효율적이다. 이 역시 다양한 회사에서 데이터 컨설팅을 하면서 효율적으로 사용했었는데 이 경우 이런 형태의 데이터 파이프라인을 보통 Reverse ETL이라고 부른다. 즉 소스가 데이터 웨어하우스가 되고 타켓이 시트가 되는 형태로 일반적인 ETL의 반대 방향으로 데이터가 흐르는 거다. 이번에 인프런에 만든 강의 뒷 부분에 새로 아래 두 개의 챕터를 추가했는데 이게 바로 구글 시트를 데이터소스로 보고 시트 정보를 읽어다가 Snowflake의 테이블로 적재하는 과정을 설명하고 데모하는 내용으로 구성되어 있다. 곧 Reverse ETL 내용 (Snowflake -&gt; 구글시트)에 관한 챕터도 추가할 예정이다. <ul ><li>구글 시트 ➜ Snowflake</li><li>구글 시트 ➜ Snowflake (코드 리뷰와 실습)</li></ul> "실리콘밸리 데이터 리더가 알려주는 Airflow 기초": https://inf.run/qRing

가장 많이 쓰이는 데이터 분석/BI 툴은 무엇일까?

저의 첫 멘토는 하청 업체에서 고용한 프리랜서 개발자였습니다.

저는 대기업에서 첫 커리어를 시작했는데, 하청 업체에 SI 프로젝트 외주를 많이 주었습니다. 그러다 어느 날 새로 투입된 프로젝트에서 충격적으로 잘 하시는 프리랜서 개발자를 만나게 되었습니다. 그 전까지는 저는 제가 나름 실력이 괜찮다고 생각을 했거든요? 그런데 그 개발자 님을 뵙고 저는 아무 것도 모르는 애송이었다는 것을 깨닫게 되었습니다.

처음에 그 개발자 분께 "사부님"으로 모시고 싶다고 말씀드렸더니 크게 놀라시며 손사례를 치셨습니다. (당시 멘토링 문화가 생소했기 때문에 이렇게 촌스럽게 말씀드렸지만, 사실 멘토가 되어 달라는 부탁이었습니다.) 본인이 같은 회사의 선배도 아니고, 을도 아닌 병, 정의 위치에 있는데 어찌 그럴 수 있겠냐고 난감해하셨습니다. 하지만 저는 포기하지 않고 그 분을 졸졸 딸아다니며 궁금한 것들을 계속 여쭤보면서 정말 많은 배움을 얻었습니다. 저의 이런 모습을 못마땅하게 보시는 부서 선배들 때문에 눈치를 보며 멘토님과의 밀월 관계를 이어나갔던 추억이 있습니다.

제가 주니어였을 때 첫 멘토로 부터 받은 영향은 그 이후 제가 소프트웨어 엔지니어로서 가치관을 정립하고 성장해 나가는 데 너무나 귀중한 자양분이 되었습니다. 당시에는 제 멘토가 하늘같이 보였지만 이제는 저도 연차가 쌓여서 지금은 편한 형 동생 사이가 되었네요. 요즘에는 우스갯소리로 이제 니가 나보다 훨씬 더 잘 한다고 해주시는데 그 말씀 조차 뭔가 힘이 됩니다.

멘토를 찾을 때 반드시 본인이 속한 조직으로 한정할 필요는 없다고 생각합니다. 나보다 잘 한다는 생각이 들고 본받고 싶은 부분이 있다면 누구나 여러분의 멘토가 될 자격이 있습니다. 개발자 밋업에서 우연히 만난 다른 회사의 개발자일 수도 있고, 참여하고 계신 오픈 소스 프로젝트의 다른 기여자가 될 수도 있습니다. 직책과 경력에도 구애받을 필요가 없다고 생각합니다. 단순히 더 오래 일 했다고 해서 더 잘 하는 것은 아니니까요.

정 주변에 멘토로 삼을 만한 분이 없다면 요즘에는 "랜선 멘토"라는 좋은 옵션도 있습니다. 멘티와 멘토를 매칭해주는 플랫폼도 잘 되어 있으니 의지만 있으면 어렵지 않게 멘토를 찾을 수 있을 것입니다. 진짜 정 못 찾으시겠다면 저한테 연락주세요! ㅎㅎ

늘 배워야 살아남을 수 있는 직업인 개발자로서 좋은 멘토를 만나는 것보다 더 큰 행운은 없다고 생각합니다. 좋은 개발자가 되시고 싶다면 주변에 있는 좋은 개발자를 찾아보세요. 내가 닮고 싶은 분과 꾸준히 대화를 나누는 것만으로도 여러분께 엄청난 동기부여가 될 것입니다. 다들 저처럼 인생 멘토를 찾으셨으면 좋겠습니다.

저의 첫 멘토는 하청 업체에서 고용한 프리랜서 개발자였습니다. 저는 대기업에서 첫 커리어를 시작했는데, 하청 업체에 SI 프로젝트 외주를 많이 주었습니다. 그러다 어느 날 새로 투입된 프로젝트에서 충격적으로 잘 하시는 프리랜서 개발자를 만나게 되었습니다. 그 전까지는 저는 제가 나름 실력이 괜찮다고 생각을 했거든요? 그런데 그 개발자 님을 뵙고 저는 아무 것도 모르는 애송이었다는 것을 깨닫게 되었습니다. 처음에 그 개발자 분께 "사부님"으로 모시고 싶다고 말씀드렸더니 크게 놀라시며 손사례를 치셨습니다. (당시 멘토링 문화가 생소했기 때문에 이렇게 촌스럽게 말씀드렸지만, 사실 멘토가 되어 달라는 부탁이었습니다.) 본인이 같은 회사의 선배도 아니고, 을도 아닌 병, 정의 위치에 있는데 어찌 그럴 수 있겠냐고 난감해하셨습니다. 하지만 저는 포기하지 않고 그 분을 졸졸 딸아다니며 궁금한 것들을 계속 여쭤보면서 정말 많은 배움을 얻었습니다. 저의 이런 모습을 못마땅하게 보시는 부서 선배들 때문에 눈치를 보며 멘토님과의 밀월 관계를 이어나갔던 추억이 있습니다. 제가 주니어였을 때 첫 멘토로 부터 받은 영향은 그 이후 제가 소프트웨어 엔지니어로서 가치관을 정립하고 성장해 나가는 데 너무나 귀중한 자양분이 되었습니다. 당시에는 제 멘토가 하늘같이 보였지만 이제는 저도 연차가 쌓여서 지금은 편한 형 동생 사이가 되었네요. 요즘에는 우스갯소리로 이제 니가 나보다 훨씬 더 잘 한다고 해주시는데 그 말씀 조차 뭔가 힘이 됩니다. 멘토를 찾을 때 반드시 본인이 속한 조직으로 한정할 필요는 없다고 생각합니다. 나보다 잘 한다는 생각이 들고 본받고 싶은 부분이 있다면 누구나 여러분의 멘토가 될 자격이 있습니다. 개발자 밋업에서 우연히 만난 다른 회사의 개발자일 수도 있고, 참여하고 계신 오픈 소스 프로젝트의 다른 기여자가 될 수도 있습니다. 직책과 경력에도 구애받을 필요가 없다고 생각합니다. 단순히 더 오래 일 했다고 해서 더 잘 하는 것은 아니니까요. 정 주변에 멘토로 삼을 만한 분이 없다면 요즘에는 "랜선 멘토"라는 좋은 옵션도 있습니다. 멘티와 멘토를 매칭해주는 플랫폼도 잘 되어 있으니 의지만 있으면 어렵지 않게 멘토를 찾을 수 있을 것입니다. 진짜 정 못 찾으시겠다면 저한테 연락주세요! ㅎㅎ 늘 배워야 살아남을 수 있는 직업인 개발자로서 좋은 멘토를 만나는 것보다 더 큰 행운은 없다고 생각합니다. 좋은 개발자가 되시고 싶다면 주변에 있는 좋은 개발자를 찾아보세요. 내가 닮고 싶은 분과 꾸준히 대화를 나누는 것만으로도 여러분께 엄청난 동기부여가 될 것입니다. 다들 저처럼 인생 멘토를 찾으셨으면 좋겠습니다.

나의 첫 멘토 이야기

매번 같은 실수, 악습관을 반복하게 됩니다 현재의 행복을 추구하고 미래의 행복을 소홀히 하게 됩니다 의지를 다잡지만 조금만 트리거가 생기거나 기분이 나빠지면 다시 돌아가버립니다 너무 어릴때부터 자극만 쫓아서 그런걸까요 이제는 어떻게 돌아갈지 모르겠습니다 도와주실수있는 몇마디가 있다면 부탁드립니다

1
앞으로 ’돈‘이라고 해도 그 기저에는 세 종류가 존재한다는 것을 이해해야 한다.

2
‘캐피탈리즘’에서 돈은 통화며 노동 혹은 자본 투하를 통해 얻는 것이다.

3
반면 ‘버추얼리즘’의 돈은 신용, 평판, 영향력에 의해 결정된다.

4
‘셰어리즘’에서는 편안한 거리감을 담보할 수 있는 평판, 커뮤니케이션의 대가로써 답례가 있다. 셰어리즘에서는 시간과 공헌을 쌓아 올리는 것이 특히 중요하다.

5
각각의 세계에서 ’돈‘은 서로 관계되면서도 개개의 성질이 크게 다르다.

#3개의세계 📚

1 앞으로 ’돈‘이라고 해도 그 기저에는 세 종류가 존재한다는 것을 이해해야 한다. ​ 2 ‘캐피탈리즘’에서 돈은 통화며 노동 혹은 자본 투하를 통해 얻는 것이다. ​ 3 반면 ‘버추얼리즘’의 돈은 신용, 평판, 영향력에 의해 결정된다. ​ 4 ‘셰어리즘’에서는 편안한 거리감을 담보할 수 있는 평판, 커뮤니케이션의 대가로써 답례가 있다. 셰어리즘에서는 시간과 공헌을 쌓아 올리는 것이 특히 중요하다. ​ 5 각각의 세계에서 ’돈‘은 서로 관계되면서도 개개의 성질이 크게 다르다. #3개의세계 📚

< 미래에 돈은 세 종류로 나뉜다 >

https://blog.naver.com/madaboutit/223776694587

신한투자증권 대상 제3자 배정 방식 신주 발행 라이더 등 인프라 확대·테크 역량 강화

부릉, 300억원 규모 투자 유치…배달 대행 시장 경쟁력 강화 - 매일경제

배달대행 플랫폼 부릉이 신한투자증권으로부터 300억 원 규모의 투자를 유치했다고 17일 밝혔다.

이번 투자 유치를 통해 부릉은 자금 안정성을 높이는 동시에 배달대행 시장에서의 경쟁력을 한층 강화할 계획이다. 특히 라이더, 크라우드소싱 플랫폼 ‘부릉프렌즈’, 제휴 네트워크 등 인프라를 확충해 증가하는 시장 내 배달 물량과 부릉에 의존하는 기업 고객의 수요에 대응할 예정이다.

https://m.mk.co.kr/news/it/11265420

배달대행 플랫폼 부릉이 신한투자증권으로부터 300억 원 규모의 투자를 유치했다고 17일 밝혔다. 이번 투자 유치를 통해 부릉은 자금 안정성을 높이는 동시에 배달대행 시장에서의 경쟁력을 한층 강화할 계획이다. 특히 라이더, 크라우드소싱 플랫폼 ‘부릉프렌즈’, 제휴 네트워크 등 인프라를 확충해 증가하는 시장 내 배달 물량과 부릉에 의존하는 기업 고객의 수요에 대응할 예정이다. https://m.mk.co.kr/news/it/11265420

매일경제

﻿
취업이나 이직을 고려하는 사람들에게 회사가 어떤 부분에서 얼마나 매력을 갖고 있는지 알아보는 지표가 있습니다. Employee Value Proposition이라고 하는 지표입니다. 영어를 한글로 직역하면 ‘직원 가치 제안’으로 기업이 직원들에게 제공하는 포괄적인 가치를 의미합니다.
제가 경험한 EVP 지표 조사는 크게 4가지 항목을 측정하는 것이었습니다. 보상, 성장 가능성, 조직문화, 복지 이상 4가지 항목입니다. 이와 같은 4가지 항목을 각각 더 잘게 쪼개어 약 40개 이상의 문항으로 설문을 받는 것이었습니다. 설문을 받는 대상은 IT 플랫폼 기업에 근무 중인 직장인 약 500명이었습니다.

다른 기업과 상대적인 EVP 지표가 궁금하여 약 30개 기업을 선정하여 해당 기업에 대한 보상, 성장 가능성, 조직문화, 복지에 대해서 물어보았습니다. 그래서 직접적으로 제가 근무하고 있던 곳과 객관적인 비교 우위를 확인하였습니다. 이는 산업 군에서 회사 경쟁력을 순위로 알고 싶다는 회사 주인의 의지였습니다. 

EVP 비교 기업을 선정하는 것이 가장 어려웠습니다. 직관적으로 제가 근무하고 있던 기업보다 브랜드 인지도가 훌륭한 기업은 EVP 설문 결과가 당연히 높게 나올 것이고, 반대로 브랜드 인지도가 아직 잘 갖춰지지 않은 기업은 상대적으로 EVP 설문 결과가 낮게 나올 것이라고 예상했습니다. 그럼에도 불구하고 비교해야 한다면, 어느 정도 적절히 믹스를 해야 할지 고민이 되었던 것입니다.

총 30개 비교 대상 중 20개는 브랜드 인지도 우위에 있을 것이라고 예상한 기업으로 선정하고, 나머지 10개는 우리가 우위에 있을 것이라고 상상한 곳으로 선정했습니다. 예상은 보기 좋게 적중했습니다. 역시 사람들 생각은 거기서 거기인가 봅니다. 이런 결과를 보면 때론 데이터를 공들여 분석하는 일이 무슨 의미가 있나 허무주의에 빠지기도 합니다.

예상은 했지만, 실제로 사람들에게 우리 회사 EVP 지표를 피드백 받아 보니 씁쓸하기도 했습니다. 설문을 만든 사람이나 응답한 사람이나 비교 대상 30개 회사 중 1-2개 기업을 제외하고 직접 근무해 본 경험이 있은 것은 아닌데, 더 좋아 보이고 덜 좋아 보이는 것이 확연히 드러나는 인식이 무섭고 쓸쓸했습니다.

이런 것을 보면 마케팅의 힘이 강력하다는 생각도 듭니다. 그리고 회사에 근무했던 사람과 지금 근무하고 있는 사람들이 만들어낸 목소리의 힘이 얼마나 멀리 크게 전파가 되는지 알 수 있습니다. 간접이든 직접이든 경험이 브랜드를 만들어 냅니다.

EVP는 경험이 만들어낸 지표라고 할 수 있습니다. 회사에 대해서 소문을 들어본 사람들과 회사에서 근무하며 경험한 것을 피드백하는 사람들이 평가한 지표입니다. 보상, 성장 가능성, 조직문화, 복지에 대한 사람들의 생각을 숫자로 확인해 볼 수 있는 흥미로운 지표라고 생각합니다.

4가지 항목을 평가한 500명의 사람들 중 대부분은 보상이 중요하다고 이야기했습니다. 그다음은 성장 가능성이 중요했고, 조직문화와 복지는 거의 비슷한 수준이었습니다. 직군에 따라서 약간 다른 점은 엔지니어 직군은 보상이 성장 가능성보다 훨씬 중요했고, 사업과 운영 분야 직군은 성장 가능성을 보상보다 근소한 차이로 더 중요하게 생각했습니다.

어떤 가치를 다른 가치보다 더 중요하다고 판단하는 것은 순전히 개인의 가치관에 달려 있는 것이라고 생각합니다. 개인이 중요하게 생각하는 가치가 어떤 배경에서 자리 잡게 되었는지 모두 알 수 없습니다. 하지만 아주 특수한 경우가 아니고 대한민국에서 공교육을 받고 평범한 가정에서 자란 사람들이 가지고 있는 가치라면 500명의 생각이 그 이상의 숫자를 어느 정도 대변할 수도 있을 것 같다는 섣부른 추측을 해봅니다.

아직 재정적으로 여유를 갖고 있지 못한 스타트업이 보상이나 복지와 같은 물리적인 혜택을 인재에게 제공하긴 어렵습니다. 그래서 인재를 영입할 때, 무기로 장착해야 하는 것이 성장 가능성과 조직문화에 대한 내용일 것입니다. 현재에 제공 가능한 것보다 미래에 줄 수 있는 혜택이 더 크다는 것을 어필해야 한다고 생각합니다.

물론 당장 눈앞에 보이는 보상과 복지와 같은 혜택을 너무 중요하게 생각하는 인재라면 설득이 어려울 것입니다. 그러나 성장 가능성과 조직문화와 같이 눈에 보이지 않는 가치에 대해서도 중요하다고 생각하는 인재가 있다면, 설득할 수 있는 여지가 있다고 생각합니다. 물론 인재가 현재 받고 있는 보상 수준과 터무니없이 차이가 나는 처우를 제시하며 이상적인 성장 가능성과 조직문화를 이야기하며 설득하겠다는 의지는 현실적으로 실현 가능성이 낮습니다.

어느 정도 채용 시장에 형성된 보상 체계를 이해하고 그와 준수한 처우와 복지 시스템을 갖추는 노력이 필요합니다. 아직 그렇게까지 보상과 복지를 갖출 형편이 되지 않는다면, 현재 구성원으로 조금 더 성장을 만들어야 하는 것은 아닌지 감히 진단해 봅니다.

사람이 매력을 느끼는 가치에는 분명히 여러 가지 요인이 있습니다. 인재를 영입하는 과정에서 회사가 제공할 수 있는 수준에 맞게 인재의 생각을 객관적으로 파악해 보려는 노력이 중요하다고 생각합니다. EVP 지표는 효과적인 인재 영입 프로세스를 갖추기 위해 필요한 인재와 기업이 조건을 객관적으로 파악하는 데 도움이 되는 내용입니다.

﻿취업이나 이직을 고려하는 사람들에게 회사가 어떤 부분에서 얼마나 매력을 갖고 있는지 알아보는 지표가 있습니다. Employee Value Proposition이라고 하는 지표입니다. 영어를 한글로 직역하면 ‘직원 가치 제안’으로 기업이 직원들에게 제공하는 포괄적인 가치를 의미합니다.제가 경험한 EVP 지표 조사는 크게 4가지 항목을 측정하는 것이었습니다. 보상, 성장 가능성, 조직문화, 복지 이상 4가지 항목입니다. 이와 같은 4가지 항목을 각각 더 잘게 쪼개어 약 40개 이상의 문항으로 설문을 받는 것이었습니다. 설문을 받는 대상은 IT 플랫폼 기업에 근무 중인 직장인 약 500명이었습니다. 다른 기업과 상대적인 EVP 지표가 궁금하여 약 30개 기업을 선정하여 해당 기업에 대한 보상, 성장 가능성, 조직문화, 복지에 대해서 물어보았습니다. 그래서 직접적으로 제가 근무하고 있던 곳과 객관적인 비교 우위를 확인하였습니다. 이는 산업 군에서 회사 경쟁력을 순위로 알고 싶다는 회사 주인의 의지였습니다.&nbsp; EVP 비교 기업을 선정하는 것이 가장 어려웠습니다. 직관적으로 제가 근무하고 있던 기업보다 브랜드 인지도가 훌륭한 기업은 EVP 설문 결과가 당연히 높게 나올 것이고, 반대로 브랜드 인지도가 아직 잘 갖춰지지 않은 기업은 상대적으로 EVP 설문 결과가 낮게 나올 것이라고 예상했습니다. 그럼에도 불구하고 비교해야 한다면, 어느 정도 적절히 믹스를 해야 할지 고민이 되었던 것입니다. 총 30개 비교 대상 중 20개는 브랜드 인지도 우위에 있을 것이라고 예상한 기업으로 선정하고, 나머지 10개는 우리가 우위에 있을 것이라고 상상한 곳으로 선정했습니다. 예상은 보기 좋게 적중했습니다. 역시 사람들 생각은 거기서 거기인가 봅니다. 이런 결과를 보면 때론 데이터를 공들여 분석하는 일이 무슨 의미가 있나 허무주의에 빠지기도 합니다. 예상은 했지만, 실제로 사람들에게 우리 회사 EVP 지표를 피드백 받아 보니 씁쓸하기도 했습니다. 설문을 만든 사람이나 응답한 사람이나 비교 대상 30개 회사 중 1-2개 기업을 제외하고 직접 근무해 본 경험이 있은 것은 아닌데, 더 좋아 보이고 덜 좋아 보이는 것이 확연히 드러나는 인식이 무섭고 쓸쓸했습니다. 이런 것을 보면 마케팅의 힘이 강력하다는 생각도 듭니다. 그리고 회사에 근무했던 사람과 지금 근무하고 있는 사람들이 만들어낸 목소리의 힘이 얼마나 멀리 크게 전파가 되는지 알 수 있습니다. 간접이든 직접이든 경험이 브랜드를 만들어 냅니다. EVP는 경험이 만들어낸 지표라고 할 수 있습니다. 회사에 대해서 소문을 들어본 사람들과 회사에서 근무하며 경험한 것을 피드백하는 사람들이 평가한 지표입니다. 보상, 성장 가능성, 조직문화, 복지에 대한 사람들의 생각을 숫자로 확인해 볼 수 있는 흥미로운 지표라고 생각합니다. 4가지 항목을 평가한 500명의 사람들 중 대부분은 보상이 중요하다고 이야기했습니다. 그다음은 성장 가능성이 중요했고, 조직문화와 복지는 거의 비슷한 수준이었습니다. 직군에 따라서 약간 다른 점은 엔지니어 직군은 보상이 성장 가능성보다 훨씬 중요했고, 사업과 운영 분야 직군은 성장 가능성을 보상보다 근소한 차이로 더 중요하게 생각했습니다. 어떤 가치를 다른 가치보다 더 중요하다고 판단하는 것은 순전히 개인의 가치관에 달려 있는 것이라고 생각합니다. 개인이 중요하게 생각하는 가치가 어떤 배경에서 자리 잡게 되었는지 모두 알 수 없습니다. 하지만 아주 특수한 경우가 아니고 대한민국에서 공교육을 받고 평범한 가정에서 자란 사람들이 가지고 있는 가치라면 500명의 생각이 그 이상의 숫자를 어느 정도 대변할 수도 있을 것 같다는 섣부른 추측을 해봅니다. 아직 재정적으로 여유를 갖고 있지 못한 스타트업이 보상이나 복지와 같은 물리적인 혜택을 인재에게 제공하긴 어렵습니다. 그래서 인재를 영입할 때, 무기로 장착해야 하는 것이 성장 가능성과 조직문화에 대한 내용일 것입니다. 현재에 제공 가능한 것보다 미래에 줄 수 있는 혜택이 더 크다는 것을 어필해야 한다고 생각합니다. 물론 당장 눈앞에 보이는 보상과 복지와 같은 혜택을 너무 중요하게 생각하는 인재라면 설득이 어려울 것입니다. 그러나 성장 가능성과 조직문화와 같이 눈에 보이지 않는 가치에 대해서도 중요하다고 생각하는 인재가 있다면, 설득할 수 있는 여지가 있다고 생각합니다. 물론 인재가 현재 받고 있는 보상 수준과 터무니없이 차이가 나는 처우를 제시하며 이상적인 성장 가능성과 조직문화를 이야기하며 설득하겠다는 의지는 현실적으로 실현 가능성이 낮습니다. 어느 정도 채용 시장에 형성된 보상 체계를 이해하고 그와 준수한 처우와 복지 시스템을 갖추는 노력이 필요합니다. 아직 그렇게까지 보상과 복지를 갖출 형편이 되지 않는다면, 현재 구성원으로 조금 더 성장을 만들어야 하는 것은 아닌지 감히 진단해 봅니다. 사람이 매력을 느끼는 가치에는 분명히 여러 가지 요인이 있습니다. 인재를 영입하는 과정에서 회사가 제공할 수 있는 수준에 맞게 인재의 생각을 객관적으로 파악해 보려는 노력이 중요하다고 생각합니다. EVP 지표는 효과적인 인재 영입 프로세스를 갖추기 위해 필요한 인재와 기업이 조건을 객관적으로 파악하는 데 도움이 되는 내용입니다.﻿

방산 인공지능(AI) 스타트업 퀀텀에어로 주식회사는 ST캐피탈, 오픈워터엔젤스 및 전략적 투자자(SI) 2곳으로부터 초기 투자 37억원을 유치했다고 18일 밝혔다. 퀀텀에어로는 AI 드론 등을 수입하고 있으며 미국 

방산 AI 스타트업 퀀텀에어로 "시드 투자 37억원 유치"

인공지능(AI) 스타트업 퀀텀에어로 주식회사는 ST캐피탈, 오픈워터엔젤스 및 전략적 투자자(SI) 2곳으로부터 초기 투자 37억원을 유치했다고 18일 밝혔다.

퀀텀에어로는 AI 드론 등을 수입하고 있으며 미국 전투 무인기 제작업체 '쉴드 AI' 국내 독점 파트너기도 하다.

https://n.news.naver.com/article/001/0015270572?sid=105

인공지능(AI) 스타트업 퀀텀에어로 주식회사는 ST캐피탈, 오픈워터엔젤스 및 전략적 투자자(SI) 2곳으로부터 초기 투자 37억원을 유치했다고 18일 밝혔다. 퀀텀에어로는 AI 드론 등을 수입하고 있으며 미국 전투 무인기 제작업체 '쉴드 AI' 국내 독점 파트너기도 하다. https://n.news.naver.com/article/001/0015270572?sid=105

n.news.naver.com

`대화지능` 저자·커뮤니케이션 대가 `글레이저`성과 얻고 싶다면 직원의 마음을먼저 돌봐줘야

[매경 MBA] 직원에 문제있다고?…리더의 대화지능 높여라 - 매일경제

불안과 두려움은 왜 신뢰와 협력을 방해하는 것일까? 세계적인 커뮤니케이션 전문가이며 <대화지능>의 저자인 주디스 E 글레이저 Creating We Institute 회장은 우리의 뇌가 그렇게 생겨먹었기 때문이라고 설명한다.

fMRI로 뇌를 스캔하면, 신뢰는 주로 전전두엽피질이, 불신은 주로 편도체가 관장한다. 편도체는 진화과정에서 아주 오래전에 형성된 원시 뇌에 속한다. 반면 전전두엽피질은 상대적으로 최근에 만들어졌다.

인간이 두려움, 불안, 위협을 느끼면 편도체가 활성화된다. 그러면 신뢰를 관장하는 전전두엽피질이 닫혀 버린다. 그래서 상대방을 믿지 못하게 된다.

많은 직원들이 리더와 대화할 때 불안과 두려움을 느낀다. 두뇌 속 편도체가 활성화되고 전전두엽피질은 닫힌다. 결국 리더가 바라는 대로 행동하지 않게 된다.

이런 직원들 앞에서 리더는 말하기(tell)-또 말하기(sell)-고함치기(yell) 신드롬에 빠지게 된다. 직원에게 자신의 생각을 말하고 또 말하지만, 효과가 없자 고함을 지르게 된다는 뜻이다.

1️⃣인간의 뇌는 타인을 만나면 그가 적인지 친구인지부터 판단하나?
🔸우리 뇌는 상대가 믿을 만한 사람인지, 아니면 믿지 못할 사람인지부터 판단한다. 먼저 원시 뇌가 판단의 근거가 되는 신호를 감지한다. 그리고 그 신호를 뇌의 다른 부분에 전달한다. 0.07초면 상대가 적인지, 친구인지 판단할 수 있다. 자동적, 무의식적으로 그렇게 된다.

2️⃣못 믿을 사람이라고 판단하면 편도체가 활성화되나?
🔸그렇다. 적이냐, 친구냐는 판단은 믿을 수 없을 만큼 강력하고 빠르다. 못 믿을 사람이라고 판단되면 편도체를 비롯한 뇌에서 두려움을 관장하는 네트워크가 활성화된다. 달아나거나 싸우거나 죽은 척하라고 몸에 지시한다. 자신을 지키는 데 집중하는 것이다.

3️⃣그 순간 전전두엽피질 등 뇌의 신뢰 네트워크가 활성화될 순 없나?
🔸편도체와 전전두엽피질은 노예와 주인의 관계다. 한쪽이 주인이 되면 다른 쪽은 노예가 된다. 우리가 두려움을 느끼면 편도체가 우리 뇌의 주인이 된다. 뇌의 다른 영역은 그에 복종하게 된다. 반대로 뇌의 신뢰 네트워크가 활성화되면 원시 뇌가 그에 복종한다. 인간의 뇌는 오랫동안 그렇게 진화해 왔다.

4️⃣대화에 레벨 1, 레벨 2, 레벨 3가 있나?
🔸레벨 1은 정보와 데이터를 교환하는 수준의 대화다(보스가 직원에게 ‘보고서 지시대로 만들었니?’ 묻는 질문은 레벨 1이다).

이런 대화는 자기중심적이다. 내가 아는 것, 옳다고 믿는 것을 확인하려는 욕구에서 출발하기 때문이다. 이런 욕구가 충족되면 편안함을 느낀다 (예; 보스가 자신이 믿는 바를 부하에게 말하고, 부하가 이를 이행하면 편안함을 느낀다).

그러나 우리는 종종 상대가 나와 생각이 다르다는 것을 발견하게 된다. 그러면 내가 왜 옳은지를 설명해 상대방을 설득하려 든다. 리더가 부하를 설득하는 대화는 레벨 2다.

레벨 3는 상대방과 함께 무엇인가를 공유하고 새로운 것을 발견하고자 하는 대화다. 상대를 신뢰하고 상대의 의견에 열려 있다. 상대를 설복해 이기는 게 목표가 아니다. 파트너로서 함께 미래를 만들어가는 게 중요하다.

5️⃣자세히 설명해달라.
🔸자크 나세르는 2000년 포드의 CEO가 됐다. 그는 톱다운 방식의 계층제 조직을 바꾸고 싶어했다. 처음에는 좋았다. 전국을 돌며 타운홀 미팅을 열고 직원과 대화했다. 모든 직원들에게 조직 변화에 동참할 것을 요청했다.

그러나 직원들은 나세르가 바라는 만큼 행동하지 않았다. 그는 실망했다. 이윽고 그는 이른바 말하기(tell)-또 말하기(sell)-고함치기(yell) 신드롬에 빠졌다. 결국 CEO에서 물러나야 했다.

이런 신드롬은 레벨1에서 흔히 나타난다. 내가 원하는 것을 상대방에게 말하는 건 레벨1 대화이다. 그런데 상대방이 자기 말대로 하지 않으면 어떤 리더들은 고함을 친다. 이러면 직원은 두려움을 느낀다. 두뇌 속 편도체가 활성화되고 신뢰 네트워크는 닫힌다.

6️⃣레벨2 대화에서 나타나는 현상은?
🔸자신의 옮음에 중독되는 신드롬이다. 우리 뇌는 옮음에 중독되기 쉽다. 자신이 옳다는 게 입증되면 몸에서 도파민이 나오고 쾌감을 느낀다. 문제는 도파민은 중독성이 강하다는 것.

그래서 우리 뇌는 마치 중독된 것처럼 자신의 옮음을 계속 갈망하게 된다. 이 신드롬에 빠지면 타인에게 귀를 기울이지 않는다. 그저 자신의 옮음을 관철시켜 승리하는 데 초점을 맞춘다. 상대를 적으로 인식하게 되고 두뇌 속 편도체가 활성화된다.

7️⃣뇌에서 두려움의 네트워크가 활성화되지 않도록 막는 최고의 항생제는?
🔸누군가 나를 믿고 공감하며 지원한다고 생각해보라. 이것은 그가 나를 돌보고 있다는 신호다. 이 신호를 받으면 우리 몸에 옥시토신(oxytocin) 호르몬이 분비된다. 호르몬 작용으로 우리는 연대감을 느끼게 된다. 이런 기분이 들면 두려움은 줄어든다. 안전함을 느낀다.

8️⃣레벨3 대화만이 직원들을 긍정적인 방향으로 변화시킬 수 있다고 믿나?
🔸그렇다. 대화 중에 에너지가 어떻게 창조되고 사라지는지를 40년간 연구했다. 레벨 1-2의 대화는 에너지를 소모한다. 내 의견을 입증하고 지키려면 에너지를 쓸 수밖에 없다. 그러나 레벨3 대화는 다르다. 대화 상대 양쪽 모두에게 힘을 부여한다. 에너지를 창조하고 서로를 긍정적인 방향으로 변화시킨다.

9️⃣성과가 낮은 직원에게도 신뢰, 공감, 지원을 보내야 하나?
🔸직원 성과가 리더 기대에 미치지 못하는 갭(gap)은 언제나 있다. 이때 리더에게는 용기(candor)와 돌봄(caring) 두 가지가 모두 필요하다. 그 같은 갭을 내버려두거나 없는 척하는 것은 용기 없는 행위다. 우리 모두를 기만하는 것이다. 보스와 직원 간의 관계를 악화시킬 뿐이다.

동시에 리더는 직원을 돌봐야 한다. 리더가 자신을 돌보고 있다는 것을 직원이 느끼게 해야 한다. 그래야만 직원의 발전을 위해 무엇이 필요한지 효과적으로 대화할 수 있다.

그리고 그에 앞서 리더는 성과가 낮은 직원에 대한 자신의 좌절감을 다스리는 방법부터 배워야 한다. 화를 내거나 소리를 질러서는 안 된다.

불안과 두려움은 왜 신뢰와 협력을 방해하는 것일까? 세계적인 커뮤니케이션 전문가이며 &lt;대화지능&gt;의 저자인 주디스 E 글레이저 Creating We Institute 회장은 우리의 뇌가 그렇게 생겨먹었기 때문이라고 설명한다. fMRI로 뇌를 스캔하면, 신뢰는 주로 전전두엽피질이, 불신은 주로 편도체가 관장한다. 편도체는 진화과정에서 아주 오래전에 형성된 원시 뇌에 속한다. 반면 전전두엽피질은 상대적으로 최근에 만들어졌다. 인간이 두려움, 불안, 위협을 느끼면 편도체가 활성화된다. 그러면 신뢰를 관장하는 전전두엽피질이 닫혀 버린다. 그래서 상대방을 믿지 못하게 된다. 많은 직원들이 리더와 대화할 때 불안과 두려움을 느낀다. 두뇌 속 편도체가 활성화되고 전전두엽피질은 닫힌다. 결국 리더가 바라는 대로 행동하지 않게 된다. 이런 직원들 앞에서 리더는 말하기(tell)-또 말하기(sell)-고함치기(yell) 신드롬에 빠지게 된다. 직원에게 자신의 생각을 말하고 또 말하지만, 효과가 없자 고함을 지르게 된다는 뜻이다. 1️⃣인간의 뇌는 타인을 만나면 그가 적인지 친구인지부터 판단하나?🔸우리 뇌는 상대가 믿을 만한 사람인지, 아니면 믿지 못할 사람인지부터 판단한다. 먼저 원시 뇌가 판단의 근거가 되는 신호를 감지한다. 그리고 그 신호를 뇌의 다른 부분에 전달한다. 0.07초면 상대가 적인지, 친구인지 판단할 수 있다. 자동적, 무의식적으로 그렇게 된다. 2️⃣못 믿을 사람이라고 판단하면 편도체가 활성화되나?🔸그렇다. 적이냐, 친구냐는 판단은 믿을 수 없을 만큼 강력하고 빠르다. 못 믿을 사람이라고 판단되면 편도체를 비롯한 뇌에서 두려움을 관장하는 네트워크가 활성화된다. 달아나거나 싸우거나 죽은 척하라고 몸에 지시한다. 자신을 지키는 데 집중하는 것이다. 3️⃣그 순간 전전두엽피질 등 뇌의 신뢰 네트워크가 활성화될 순 없나?🔸편도체와 전전두엽피질은 노예와 주인의 관계다. 한쪽이 주인이 되면 다른 쪽은 노예가 된다. 우리가 두려움을 느끼면 편도체가 우리 뇌의 주인이 된다. 뇌의 다른 영역은 그에 복종하게 된다. 반대로 뇌의 신뢰 네트워크가 활성화되면 원시 뇌가 그에 복종한다. 인간의 뇌는 오랫동안 그렇게 진화해 왔다. 4️⃣대화에 레벨 1, 레벨 2, 레벨 3가 있나?🔸레벨 1은 정보와 데이터를 교환하는 수준의 대화다(보스가 직원에게 ‘보고서 지시대로 만들었니?’ 묻는 질문은 레벨 1이다). 이런 대화는 자기중심적이다. 내가 아는 것, 옳다고 믿는 것을 확인하려는 욕구에서 출발하기 때문이다. 이런 욕구가 충족되면 편안함을 느낀다 (예; 보스가 자신이 믿는 바를 부하에게 말하고, 부하가 이를 이행하면 편안함을 느낀다). 그러나 우리는 종종 상대가 나와 생각이 다르다는 것을 발견하게 된다. 그러면 내가 왜 옳은지를 설명해 상대방을 설득하려 든다. 리더가 부하를 설득하는 대화는 레벨 2다. 레벨 3는 상대방과 함께 무엇인가를 공유하고 새로운 것을 발견하고자 하는 대화다. 상대를 신뢰하고 상대의 의견에 열려 있다. 상대를 설복해 이기는 게 목표가 아니다. 파트너로서 함께 미래를 만들어가는 게 중요하다. 5️⃣자세히 설명해달라.🔸자크 나세르는 2000년 포드의 CEO가 됐다. 그는 톱다운 방식의 계층제 조직을 바꾸고 싶어했다. 처음에는 좋았다. 전국을 돌며 타운홀 미팅을 열고 직원과 대화했다. 모든 직원들에게 조직 변화에 동참할 것을 요청했다. 그러나 직원들은 나세르가 바라는 만큼 행동하지 않았다. 그는 실망했다. 이윽고 그는 이른바 말하기(tell)-또 말하기(sell)-고함치기(yell) 신드롬에 빠졌다. 결국 CEO에서 물러나야 했다. 이런 신드롬은 레벨1에서 흔히 나타난다. 내가 원하는 것을 상대방에게 말하는 건 레벨1 대화이다. 그런데 상대방이 자기 말대로 하지 않으면 어떤 리더들은 고함을 친다. 이러면 직원은 두려움을 느낀다. 두뇌 속 편도체가 활성화되고 신뢰 네트워크는 닫힌다. 6️⃣레벨2 대화에서 나타나는 현상은?🔸자신의 옮음에 중독되는 신드롬이다. 우리 뇌는 옮음에 중독되기 쉽다. 자신이 옳다는 게 입증되면 몸에서 도파민이 나오고 쾌감을 느낀다. 문제는 도파민은 중독성이 강하다는 것. 그래서 우리 뇌는 마치 중독된 것처럼 자신의 옮음을 계속 갈망하게 된다. 이 신드롬에 빠지면 타인에게 귀를 기울이지 않는다. 그저 자신의 옮음을 관철시켜 승리하는 데 초점을 맞춘다. 상대를 적으로 인식하게 되고 두뇌 속 편도체가 활성화된다. 7️⃣뇌에서 두려움의 네트워크가 활성화되지 않도록 막는 최고의 항생제는?🔸누군가 나를 믿고 공감하며 지원한다고 생각해보라. 이것은 그가 나를 돌보고 있다는 신호다. 이 신호를 받으면 우리 몸에 옥시토신(oxytocin) 호르몬이 분비된다. 호르몬 작용으로 우리는 연대감을 느끼게 된다. 이런 기분이 들면 두려움은 줄어든다. 안전함을 느낀다. 8️⃣레벨3 대화만이 직원들을 긍정적인 방향으로 변화시킬 수 있다고 믿나?🔸그렇다. 대화 중에 에너지가 어떻게 창조되고 사라지는지를 40년간 연구했다. 레벨 1-2의 대화는 에너지를 소모한다. 내 의견을 입증하고 지키려면 에너지를 쓸 수밖에 없다. 그러나 레벨3 대화는 다르다. 대화 상대 양쪽 모두에게 힘을 부여한다. 에너지를 창조하고 서로를 긍정적인 방향으로 변화시킨다. 9️⃣성과가 낮은 직원에게도 신뢰, 공감, 지원을 보내야 하나?🔸직원 성과가 리더 기대에 미치지 못하는 갭(gap)은 언제나 있다. 이때 리더에게는 용기(candor)와 돌봄(caring) 두 가지가 모두 필요하다. 그 같은 갭을 내버려두거나 없는 척하는 것은 용기 없는 행위다. 우리 모두를 기만하는 것이다. 보스와 직원 간의 관계를 악화시킬 뿐이다. 동시에 리더는 직원을 돌봐야 한다. 리더가 자신을 돌보고 있다는 것을 직원이 느끼게 해야 한다. 그래야만 직원의 발전을 위해 무엇이 필요한지 효과적으로 대화할 수 있다. 그리고 그에 앞서 리더는 성과가 낮은 직원에 대한 자신의 좌절감을 다스리는 방법부터 배워야 한다. 화를 내거나 소리를 질러서는 안 된다.

면접관으로 들어가면 행동양식 질문으로 물어보는 두 가지 질문이 있다. 하나는 임팩트(Impact)에 관한 것이고 다른 하나는 협업(Collaboration)에 관한 것이다. 임팩트에는 관한 것으로 "커리어에서 가장 임팩트있는 프로젝트에 대해 이야기해달라"는 질문을 하고 협업에 관해서는 "같이 일해본 동료 중에 가장 힘들었던 사람이 누구였고 왜 힘들었지 이야기해달라"이다.

임팩트 질문은 전에 포스팅을 한 적이 있었는데 오늘은 협업 질문에 대해 더 이야기해보고자 한다. 어려운 동료에 관한 질문을 통해 알고자 하는 것은 이 사람이 완벽한 사람인지를 알고자 하는 것이 아니다. 얼마나 솔직한지 알고 싶고 어려운 동료를 통해 무엇을 배웠고 다음에 어떤 변화를 시도했는지 알고 싶은 거다. 즉 자신의 취약한 점을 솔직히 이야기할 줄 아는 사람인지 그리고 복기를 통해 발전을 꾀하는 사람인지 알고 싶은 건데 어떤 답변들은 너무나도 구체적이지 않고 피상적이다. 면접을 잘 하는 방법 중의 하나는 솔직하되 발전하는 모습에 대해 이야기하는 것이며 그렇게 커리어를 바라보는 것이 정말 좋지 않나 싶다.

이 이야기는 지난 주에 산호세 주립대 강의 도입부에 학생들에게 해준 면접 팁의 일부인데 매주 하나씩 공유할 계획이다.

면접관으로 들어가면 행동양식 질문으로 물어보는 두 가지 질문이 있다. 하나는 임팩트(Impact)에 관한 것이고 다른 하나는 협업(Collaboration)에 관한 것이다. 임팩트에는 관한 것으로 "커리어에서 가장 임팩트있는 프로젝트에 대해 이야기해달라"는 질문을 하고 협업에 관해서는 "같이 일해본 동료 중에 가장 힘들었던 사람이 누구였고 왜 힘들었지 이야기해달라"이다. 임팩트 질문은 전에 포스팅을 한 적이 있었는데 오늘은 협업 질문에 대해 더 이야기해보고자 한다. 어려운 동료에 관한 질문을 통해 알고자 하는 것은 이 사람이 완벽한 사람인지를 알고자 하는 것이 아니다. 얼마나 솔직한지 알고 싶고 어려운 동료를 통해 무엇을 배웠고 다음에 어떤 변화를 시도했는지 알고 싶은 거다. 즉 자신의 취약한 점을 솔직히 이야기할 줄 아는 사람인지 그리고 복기를 통해 발전을 꾀하는 사람인지 알고 싶은 건데 어떤 답변들은 너무나도 구체적이지 않고 피상적이다. 면접을 잘 하는 방법 중의 하나는 솔직하되 발전하는 모습에 대해 이야기하는 것이며 그렇게 커리어를 바라보는 것이 정말 좋지 않나 싶다. 이 이야기는 지난 주에 산호세 주립대 강의 도입부에 학생들에게 해준 면접 팁의 일부인데 매주 하나씩 공유할 계획이다.

면접 질문: 같이 일해본 동료 중에 가장 힘들었던 사람은 누구였나

저를 포함한 주변에서 자주 보이는, AI에 대해 공부하는 단계별 순서입니다.

1. ChatGPT 무료로 시작하기
2. GPTs 사용해보기
3. Claude, Google AI studio, Perplexity로 확장
4. 텍스트 기반 LLM에서 다른 모달(Modal)로 확장
(Ex. Midjourney, Genspark, PikaAI, Cursor)
5. LLM 무료 버전에서 유료 버전으로 전환하기
6. Prompt에 대해 공부하고 적용해보기
7. 새로 나오는 연구/논문 찾아보고 공부하기
8. Agent/Workflow에 대해 탐구하고 적용해보기
9. API로 연결해 직접 AI 도구 만들어보기

저를 포함한 주변에서 자주 보이는, AI에 대해 공부하는 단계별 순서입니다. 1. ChatGPT 무료로 시작하기2. GPTs 사용해보기3. Claude, Google AI studio, Perplexity로 확장4. 텍스트 기반 LLM에서 다른 모달(Modal)로 확장(Ex. Midjourney, Genspark, PikaAI, Cursor)5. LLM 무료 버전에서 유료 버전으로 전환하기6. Prompt에 대해 공부하고 적용해보기7. 새로 나오는 연구/논문 찾아보고 공부하기8. Agent/Workflow에 대해 탐구하고 적용해보기9. API로 연결해 직접 AI 도구 만들어보기&nbsp;

AI, 어디까지 써보셨나요?

‘매번 신경쓰지 않아도 API 요청 당 쿼리 호출 수가 임계치를 넘으면, 자동으로 알림이 오도록 만들 순 없을까?’ 라는 작은 고민을 시작으로 ‘모두가 쉽게 사용할 수 있게끔 라이브러리로 만들어보자!’ 까지 도달한 과정을 담은 이야기입니다. 실제로…

API 요청 당 쿼리 개수를 알고 싶어 라이브러리까지 만든 이야기 — 라이브러리 제작

‘매번 신경쓰지 않아도 API 요청 당 쿼리 호출 수가 임계치를 넘으면, 자동으로 알림이 오도록 만들 순 없을까?’ 라는 작은 고민을 시작으로 ‘모두가 쉽게 사용할 수 있게끔 라이브러리로 만들어보자!’ 까지 도달한 이야기
https://medium.com/@hyeon9mak/api-%EC%9A%94%EC%B2%AD-%EB%8B%B9-%EC%BF%BC%EB%A6%AC-%EA%B0%9C%EC%88%98%EB%A5%BC-%EC%95%8C%EA%B3%A0-%EC%8B%B6%EC%96%B4-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC%EA%B9%8C%EC%A7%80-%EB%A7%8C%EB%93%A0-%EC%9D%B4%EC%95%BC%EA%B8%B0-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EC%A0%9C%EC%9E%91-de39f0d27351

‘매번 신경쓰지 않아도 API 요청 당 쿼리 호출 수가 임계치를 넘으면, 자동으로 알림이 오도록 만들 순 없을까?’ 라는 작은 고민을 시작으로 ‘모두가 쉽게 사용할 수 있게끔 라이브러리로 만들어보자!’ 까지 도달한 이야기https://medium.com/@hyeon9mak/api-%EC%9A%94%EC%B2%AD-%EB%8B%B9-%EC%BF%BC%EB%A6%AC-%EA%B0%9C%EC%88%98%EB%A5%BC-%EC%95%8C%EA%B3%A0-%EC%8B%B6%EC%96%B4-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC%EA%B9%8C%EC%A7%80-%EB%A7%8C%EB%93%A0-%EC%9D%B4%EC%95%BC%EA%B8%B0-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EC%A0%9C%EC%9E%91-de39f0d27351

Medium

API 요청 당 쿼리 개수를 알고 싶어 라이브러리까지 만든 이야기

Embarking on a native port of the existing TypeScript compiler and toolset to achieve a 10x performance speed-up.

A 10x Faster TypeScript - TypeScript

타입스크립트가 컴파일러를 Go로 재작성하여 속도를 무려 10배 향상시킨다고 예고했습니다. 7.0 버전으로 출시 예정이고 올해 11월 즈음 베타 버전이 나올 것 같다고 하네요. 그동안 타입스크립트의 성능을 개선하기 위해서 오픈 소스로 여러 시도가 있었지만 모두 실패했는데 마이크로소프트에서 이렇게 직접 나서서 늦게라도 해결해주니 너무 좋은 것 같습니다. 덕분에 VSCode도 얼마나 빠릿빠릿해질지 벌써 기대가 되네요. 단지 Rust를 선택하지 않은 부분은 여러 커뮤니티에서 논쟁거리가 되고 있는 것 같습니다.

타입스크립트가 컴파일러를 Go로 재작성하여 속도를 무려 10배 향상시킨다고 예고했습니다. 7.0 버전으로 출시 예정이고 올해 11월 즈음 베타 버전이 나올 것 같다고 하네요. 그동안 타입스크립트의 성능을 개선하기 위해서 오픈 소스로 여러 시도가 있었지만 모두 실패했는데 마이크로소프트에서 이렇게 직접 나서서 늦게라도 해결해주니 너무 좋은 것 같습니다. 덕분에 VSCode도 얼마나 빠릿빠릿해질지 벌써 기대가 되네요. 단지 Rust를 선택하지 않은 부분은 여러 커뮤니티에서 논쟁거리가 되고 있는 것 같습니다.

TypeScript

🏎️ 타입스크립트가 10배나 빨라 진다구?! 😲

절대 죽지 않는 프로그램을 짜고 싶었습니다. 널 처리만 잘하면 된다고 생각했습니다. 프로그램이 죽는 이유의 대부분이 널 포인터를 건드리는 경우였으니까.

성급한 널 처리의 오류

절대 죽지 않는 프로그램을 짜고 싶었습니다. 널 처리만 잘하면 된다고 생각했습니다.
프로그램이 죽는 이유의 대부분이 널 포인터를 건드리는 경우였으니까.

회사에 처음 들어가서 윈도우 클라이언트 프로그램을 부여받았습니다.
맨티스라는 도구에 버그가 올라오면 내가 고칠 수 있는 게 있을까 신이 나서 찾아 고쳤습니다.
대부분 널 포인터만 감싸면 고쳐지는 에러였습니다.

26살의 신입사원답게 아주 재빨랐습니다.
재현 후 디버거를 붙여서 값이 널로 들어온다?
오케이, 찾았어. 바로 널 체크 코드를 추가했습니다.
if (pData == NULL)
  return;

그리고 다시 재현해 보고 재현이 안 되면 Fix로 변경.
아~ 코딩 참 쉽다.

저는 이걸 성급한 널 처리의 오류라고 부르고 싶습니다.

경험이 쌓이면서 이게 그리 쉬운 문제가 아니라는 걸 알았습니다.
이렇게 널과 널 체크를 남용하면 프로그램이 죽지는 않더라도 버그를 영영 감추는 꼴이 되어버리고 맙니다. 절대 죽지 않는 프로그램보다 문제가 생기면 곧장 죽는 프로그램이 오히려 낫다는 걸 시간이 지나고서야 깨달았습니다.
감춰진 버그는 나중에 결국 나에게 돌아온다는걸.
ASSERT(pData);

ASSERT 같은 코드를 왜 쓰는지도 그쯤에야 깨달았습니다. (학생 때는 도무지 이해가 되지 않았습니다)
알게 된 후로는 적극적으로 사용했습니다.

이후로는 변수가 널이어야 하는 경우와 절대 널이어선 안 되는 경우를 엄격하게 구분하기 시작했습니다. 애초에 널 상태를 만들지 않으려 애썼습니다.
변수를 처음 선언할 때부터.
DB 스키마를 만들 때부터.
서버에서 클라이언트에 데이터를 내려줄 때도 함부로 null 을 사용하지 않았습니다.
이렇게 하면 그걸 받아서 쓰는 애플리케이션 쪽에서 고민거리가 줄어들므로 코딩이 편해집니다.

C/C++처럼 낡은 언어와는 다르게 요즘 언어들은 nullable 혹은 optional 타입 기능을 제공하는 것 같습니다.
저는 C#에서 이걸 처음 봤는데, 최근 언어는 다 탑재하고 있더라고요.
가끔 귀찮다는 느낌이 들 때도 있긴 하지만… 귀찮다고 느껴질 때는 널을 다뤄야 할 때입니다.
애초에 널을 건네주는 곳이 없다면 귀찮을 일도 생기지 않습니다. 이 기능에 대해 호불호가 있지만 저는 선호하는 쪽입니다.

https://jeho.page/essay/2025/03/11/fallacy-of-hasty-null-handling.html

절대 죽지 않는 프로그램을 짜고 싶었습니다. 널 처리만 잘하면 된다고 생각했습니다. 프로그램이 죽는 이유의 대부분이 널 포인터를 건드리는 경우였으니까. 회사에 처음 들어가서 윈도우 클라이언트 프로그램을 부여받았습니다. 맨티스라는 도구에 버그가 올라오면 내가 고칠 수 있는 게 있을까 신이 나서 찾아 고쳤습니다.대부분 널 포인터만 감싸면 고쳐지는 에러였습니다. 26살의 신입사원답게 아주 재빨랐습니다. 재현 후 디버거를 붙여서 값이 널로 들어온다? 오케이, 찾았어. 바로 널 체크 코드를 추가했습니다.<pre ><code>if (pData == NULL)
 return;</code></pre>그리고 다시 재현해 보고 재현이 안 되면 Fix로 변경. 아~ 코딩 참 쉽다. 저는 이걸 성급한 널 처리의 오류라고 부르고 싶습니다. 경험이 쌓이면서 이게 그리 쉬운 문제가 아니라는 걸 알았습니다. 이렇게 널과 널 체크를 남용하면 프로그램이 죽지는 않더라도 버그를 영영 감추는 꼴이 되어버리고 맙니다. 절대 죽지 않는 프로그램보다 문제가 생기면 곧장 죽는 프로그램이 오히려 낫다는 걸 시간이 지나고서야 깨달았습니다. 감춰진 버그는 나중에 결국 나에게 돌아온다는걸.<pre ><code>ASSERT(pData);</code></pre>ASSERT 같은 코드를 왜 쓰는지도 그쯤에야 깨달았습니다. (학생 때는 도무지 이해가 되지 않았습니다) 알게 된 후로는 적극적으로 사용했습니다. 이후로는 변수가 널이어야 하는 경우와 절대 널이어선 안 되는 경우를 엄격하게 구분하기 시작했습니다. 애초에 널 상태를 만들지 않으려 애썼습니다. 변수를 처음 선언할 때부터. DB 스키마를 만들 때부터. 서버에서 클라이언트에 데이터를 내려줄 때도 함부로 null 을 사용하지 않았습니다. 이렇게 하면 그걸 받아서 쓰는 애플리케이션 쪽에서 고민거리가 줄어들므로 코딩이 편해집니다. C/C++처럼 낡은 언어와는 다르게 요즘 언어들은 nullable 혹은 optional 타입 기능을 제공하는 것 같습니다. 저는 C#에서 이걸 처음 봤는데, 최근 언어는 다 탑재하고 있더라고요. 가끔 귀찮다는 느낌이 들 때도 있긴 하지만… 귀찮다고 느껴질 때는 널을 다뤄야 할 때입니다. 애초에 널을 건네주는 곳이 없다면 귀찮을 일도 생기지 않습니다. 이 기능에 대해 호불호가 있지만 저는 선호하는 쪽입니다. https://jeho.page/essay/2025/03/11/fallacy-of-hasty-null-handling.html

학생 때는 회사 생활이 두려웠어요. 미디어에 비친 회사 생활은 수직적이고 권위적이었거든요.

회사에선 눈치 보는 야근을 해야 하고, 강요받는 회식 자리에 가야하며, 능력보다 관계가 중요한 곳이라고 느꼈어요.

그래서 도망쳤어요. 견뎌낼 자신 없는 문화를 가진 회사는 쳐다보지도 않았어요.

초봉이 중요하다며 조금 참고 돈 잘 주는 곳 가라는 말을 들었어요. 무시했어요. 적은 돈을 받더라도 괜찮았어요.

일이 좋아 출근이 기대되고, 동료들이 좋아 함께 여행도 떠날 수 있으면서, 능력으로 인정받을 수 있는 곳을 찾아다녔어요.

그렇게 9년이 흘렀어요. 저는 도망친 곳에서 낙원을 발견했고 지금의 제 삶을 즐기고 있어요.

학생 때는 회사 생활이 두려웠어요. 미디어에 비친 회사 생활은 수직적이고 권위적이었거든요. 회사에선 눈치 보는 야근을 해야 하고, 강요받는 회식 자리에 가야하며, 능력보다 관계가 중요한 곳이라고 느꼈어요. 그래서 도망쳤어요. 견뎌낼 자신 없는 문화를 가진 회사는 쳐다보지도 않았어요. 초봉이 중요하다며 조금 참고 돈 잘 주는 곳 가라는 말을 들었어요. 무시했어요. 적은 돈을 받더라도 괜찮았어요. 일이 좋아 출근이 기대되고, 동료들이 좋아 함께 여행도 떠날 수 있으면서, 능력으로 인정받을 수 있는 곳을 찾아다녔어요. 그렇게 9년이 흘렀어요. 저는 도망친 곳에서 낙원을 발견했고 지금의 제 삶을 즐기고 있어요.

도망친 곳에 낙원은… 있었다

Apache Kafka는 고성능의 분산 스트리밍 플랫폼으로, 프로듀서(Producer)와 컨슈머(Consumer) 간의 효율적인 데이터 전송을 지원합니다. 그러나 Kafka 자체는 데이터의 구조나 형식에 대한 검증을 수행하지 않으므로, 데이터 스키마의 관리와 호환성 유지에 어려움이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Schema Registry가 도입되었습니다.​ Schema Registry란 무엇인가?Schema Registry는 Kafka와 별도로 동작하는 독립적인 애플리케이션으로, Kafka에서 주고받는 메시지의 스키마를 중앙에서 관리하고 저장하는 역할을 합니다. 이를 통해 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 정의를 공유하며, 데이터의 일관성과 호환성을 보장합니다. 왜 ..

Kafka Schema Registry: 데이터 스키마의 중앙 집중 관리

 Apache Kafka는 고성능의 분산 스트리밍 플랫폼으로, 프로듀서(Producer)와 컨슈머(Consumer) 간의 효율적인 데이터 전송을 지원합니다. 그러나 Kafka 자체는 데이터의 구조나 형식에 대한 검증을 수행하지 않으므로, 데이터 스키마의 관리와 호환성 유지에 어려움이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Schema Registry가 도입되었습니다.
 
Schema Registry란 무엇인가?
Schema Registry는 Kafka와 별도로 동작하는 독립적인 애플리케이션으로, Kafka에서 주고받는 메시지의 스키마를 중앙에서 관리하고 저장하는 역할을 합니다. 이를 통해 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 정의를 공유하며, 데이터의 일관성과 호환성을 보장합니다.
 
왜 Schema Registry가 필요한가?
Kafka는 기본적으로 바이트 스트림으로 데이터를 처리하며, 데이터의 구조나 형식에 대한 제약이 없습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다:
 * 스키마 변경으로 인한 장애 발생: 프로듀서가 데이터 형식을 변경하면, 이를 알지 못한 컨슈머는 역직렬화 과정에서 오류가 발생할 수 있습니다.
 * 데이터 명세 관리의 어려움: 여러 프로듀서와 컨슈머가 존재하는 환경에서 데이터 구조에 대한 명확한 정의가 없으면, 시스템 전체의 안정성이 저하될 수 있습니다. 
Schema Registry는 이러한 문제를 해결하기 위해 다음과 같은 기능을 제공합니다:
 * 스키마 중앙 관리: 모든 스키마를 중앙에서 관리하여 데이터 구조의 일관성을 유지합니다.
 * 호환성 검증: 새로운 스키마 등록 시 기존 스키마와의 호환성을 검증하여, 스키마 진화로 인한 오류를 방지합니다.
 * 스키마 버전 관리: 스키마의 버전을 체계적으로 관리하여, 필요 시 이전 버전으로의 롤백을 가능하게 합니다.

Schema Registry의 작동 원리
Schema Registry는 다음과 같은 흐름으로 작동합니다:
 1. 스키마 등록: 프로듀서는 메시지를 Kafka에 전송하기 전에 해당 메시지의 스키마를 Schema Registry에 등록합니다. 
 2. 스키마 ID 부여: Schema Registry는 등록된 스키마에 고유한 ID를 부여하고, 프로듀서는 이 스키마 ID를 메시지에 포함시켜 Kafka에 전송합니다.
 3. 메시지 소비: 컨슈머는 Kafka에서 메시지를 읽어들인 후, 메시지에 포함된 스키마 ID를 사용하여 Schema Registry에서 스키마를 조회하고, 이를 통해 메시지를 역직렬화합니다.
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int"}
  ]
}

 
이러한 과정은 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 계약을 가능하게 하며, 시스템의 안정성과 데이터의 신뢰성을 향상시킵니다.
 
Schema Registry의 장단점
✅ 장점
 * 시스템 안정성 향상: 스키마 변경 시 발생할 수 있는 오류를 사전에 방지하여 시스템의 안정성을 높입니다.
 * 데이터 명세 관리 용이: 중앙에서 스키마를 관리함으로써 데이터 구조에 대한 명확한 정의를 제공하고, 운영의 효율성을 향상시킵니다.
 * 업무 효율성 증대: 스키마 관리로 인한 불필요한 커뮤니케이션을 줄여 개발자들이 본연의 업무에 집중할 수 있게 합니다.
❌ 단점
 * 관리 포인트 증가: Schema Registry 서버를 추가로 관리해야 하므로 운영 복잡성이 증가할 수 있습니다.
 * 스키마 관리 부담: 엄격한 스키마 검증으로 인해 스키마 변경 시 추가적인 관리 작업이 필요할 수 있습니다.
 
결론
Kafka Schema Registry는 데이터의 스키마를 중앙에서 관리하여 프로듀서와 컨슈머 간의 일관성을 보장하는 필수적인 컴포넌트입니다. 이를 통해 데이터의 신뢰성을 유지하고, 스키마 변경으로 인한 장애를 방지할 수 있습니다.
 
📌 기억할 점
 * Kafka 자체는 데이터 형식을 검증하지 않음 → Schema Registry가 필요함
 * 프로듀서는 메시지를 전송하기 전에 Schema Registry에 스키마를 등록해야 함
 * 컨슈머는 메시지를 소비할 때 Schema Registry에서 스키마를 조회하여 역직렬화함
 * JSON, Avro, Protobuf 등의 다양한 포맷을 지원함

&nbsp;Apache Kafka는 고성능의 분산 스트리밍 플랫폼으로, 프로듀서(Producer)와 컨슈머(Consumer) 간의 효율적인 데이터 전송을 지원합니다. 그러나 Kafka 자체는 데이터의 구조나 형식에 대한 검증을 수행하지 않으므로, 데이터 스키마의 관리와 호환성 유지에 어려움이 발생할 수 있습니다. 이러한 문제를 해결하기 위해 Schema Registry가 도입되었습니다.​&nbsp;Schema Registry란 무엇인가?Schema Registry는 Kafka와 별도로 동작하는 독립적인 애플리케이션으로, Kafka에서 주고받는 메시지의 스키마를 중앙에서 관리하고 저장하는 역할을 합니다. 이를 통해 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 정의를 공유하며, 데이터의 일관성과 호환성을 보장합니다.&nbsp;왜 Schema Registry가 필요한가?Kafka는 기본적으로 바이트 스트림으로 데이터를 처리하며, 데이터의 구조나 형식에 대한 제약이 없습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다:​<ul ><li>스키마 변경으로 인한 장애 발생: 프로듀서가 데이터 형식을 변경하면, 이를 알지 못한 컨슈머는 역직렬화 과정에서 오류가 발생할 수 있습니다. ​</li><li>데이터 명세 관리의 어려움: 여러 프로듀서와 컨슈머가 존재하는 환경에서 데이터 구조에 대한 명확한 정의가 없으면, 시스템 전체의 안정성이 저하될 수 있습니다.&nbsp;</li></ul>Schema Registry는 이러한 문제를 해결하기 위해 다음과 같은 기능을 제공합니다:​<ul ><li>스키마 중앙 관리: 모든 스키마를 중앙에서 관리하여 데이터 구조의 일관성을 유지합니다.​</li><li>호환성 검증: 새로운 스키마 등록 시 기존 스키마와의 호환성을 검증하여, 스키마 진화로 인한 오류를 방지합니다.​</li><li>스키마 버전 관리: 스키마의 버전을 체계적으로 관리하여, 필요 시 이전 버전으로의 롤백을 가능하게 합니다.</li></ul> Schema Registry의 작동 원리Schema Registry는 다음과 같은 흐름으로 작동합니다:​<ol ><li>스키마 등록: 프로듀서는 메시지를 Kafka에 전송하기 전에 해당 메시지의 스키마를 Schema Registry에 등록합니다.&nbsp;</li><li>스키마 ID 부여: Schema Registry는 등록된 스키마에 고유한 ID를 부여하고, 프로듀서는 이 스키마 ID를 메시지에 포함시켜 Kafka에 전송합니다.​</li><li>메시지 소비: 컨슈머는 Kafka에서 메시지를 읽어들인 후, 메시지에 포함된 스키마 ID를 사용하여 Schema Registry에서 스키마를 조회하고, 이를 통해 메시지를 역직렬화합니다.​</li></ol><pre ><code class="language-bash">{
 "type": "record",
 "name": "User",
 "fields": [
 {"name": "name", "type": "string"},
 {"name": "age", "type": "int"}
 ]
}</code></pre>&nbsp;이러한 과정은 프로듀서와 컨슈머 간의 데이터 구조에 대한 명확한 계약을 가능하게 하며, 시스템의 안정성과 데이터의 신뢰성을 향상시킵니다.&nbsp;Schema Registry의 장단점✅ 장점<ul ><li>시스템 안정성 향상: 스키마 변경 시 발생할 수 있는 오류를 사전에 방지하여 시스템의 안정성을 높입니다.</li><li>데이터 명세 관리 용이: 중앙에서 스키마를 관리함으로써 데이터 구조에 대한 명확한 정의를 제공하고, 운영의 효율성을 향상시킵니다.​</li><li>업무 효율성 증대: 스키마 관리로 인한 불필요한 커뮤니케이션을 줄여 개발자들이 본연의 업무에 집중할 수 있게 합니다.</li></ul>❌ 단점<ul ><li>관리 포인트 증가: Schema Registry 서버를 추가로 관리해야 하므로 운영 복잡성이 증가할 수 있습니다.​</li><li>스키마 관리 부담: 엄격한 스키마 검증으로 인해 스키마 변경 시 추가적인 관리 작업이 필요할 수 있습니다.</li></ul>&nbsp;결론Kafka Schema Registry는 데이터의 스키마를 중앙에서 관리하여 프로듀서와 컨슈머 간의 일관성을 보장하는 필수적인 컴포넌트입니다. 이를 통해 데이터의 신뢰성을 유지하고, 스키마 변경으로 인한 장애를 방지할 수 있습니다.&nbsp;📌 기억할 점<ul ><li>Kafka 자체는 데이터 형식을 검증하지 않음 → Schema Registry가 필요함</li><li>프로듀서는 메시지를 전송하기 전에 Schema Registry에 스키마를 등록해야 함</li><li>컨슈머는 메시지를 소비할 때 Schema Registry에서 스키마를 조회하여 역직렬화함</li><li>JSON, Avro, Protobuf 등의 다양한 포맷을 지원함 </li></ul>

덕토피아

🕊️ Kafka Schema Registry: 데이터 스키마 관리

사용자가 공유한 콘텐츠

체력은 "하고 싶은 것과 할 수 있는 것 사이의 갭을 줄이는 거예요."라는 말에 밑줄을 그었습니다. 원문 제목은 "40대 이후엔 체력전이다"인데, 전체를 관통하는 내용은 '다정함은 체력에서 나오니까, 다정하려면 체력을 길러라'는 명제에 가까운 내용입니다. 전 구글 디렉터 정김경숙 님이 체력을 가꾸는 이유, 나노운동을 통해 "시간이 없다"라는 핑계를 멀리하는 이유에도 고개를 끄덕이게 됩니다.

사실 정김경숙 님이 유명해진 건 구글에서 17년 일하다 갑자기 해고당한 이후 주 80시간의 육체노동을 택하며 '트레이더조'에서 일하며 스몰토크를 하는 경험을 긍정적으로 이야기하면서부터였는데요. 점심시간 1시간을 활용해서는 리프트로 라이드헤일링을 하며 다리는 쉬면서 또 일을 했죠. 트레이더조 일이 끝나면 곧장 스타벅스 유니폼을 입었습니다. 즐겁게 일했다는 점을 생각하면 그녀는 스스로에게 다정했습니다.

낯선 사람에게 친절을 베풀면 그 의도를 의심하는 게 더 합리적인 것 같은 사회에 살고 있지만, 다정함은 누구나에게 필요합니다. 스스로에게 다정할 만큼 체력을 기르고 나면, 남는 체력으로는 이방인에게도 다정할 수 있지 않을까요? 오늘 이 아티클 덕분에 낯선 이에게 조금 더 친절할 수 있었고, 더 괜찮은 사람이 되겠다는 다짐을 했습니다.

https://www.folin.co/article/10337/gift/DghwhBThRk5eYf1Xrm2vYX7f6xiFZe6L

체력은 "하고 싶은 것과 할 수 있는 것 사이의 갭을 줄이는 거예요."라는 말에 밑줄을 그었습니다. 원문 제목은 "40대 이후엔 체력전이다"인데, 전체를 관통하는 내용은 '다정함은 체력에서 나오니까, 다정하려면 체력을 길러라'는 명제에 가까운 내용입니다. 전 구글 디렉터 정김경숙 님이 체력을 가꾸는 이유, 나노운동을 통해 "시간이 없다"라는 핑계를 멀리하는 이유에도 고개를 끄덕이게 됩니다. 사실 정김경숙 님이 유명해진 건 구글에서 17년 일하다 갑자기 해고당한 이후 주 80시간의 육체노동을 택하며 '트레이더조'에서 일하며 스몰토크를 하는 경험을 긍정적으로 이야기하면서부터였는데요. 점심시간 1시간을 활용해서는 리프트로 라이드헤일링을 하며 다리는 쉬면서 또 일을 했죠. 트레이더조 일이 끝나면 곧장 스타벅스 유니폼을 입었습니다. 즐겁게 일했다는 점을 생각하면 그녀는 스스로에게 다정했습니다. 낯선 사람에게 친절을 베풀면 그 의도를 의심하는 게 더 합리적인 것 같은 사회에 살고 있지만, 다정함은 누구나에게 필요합니다. 스스로에게 다정할 만큼 체력을 기르고 나면, 남는 체력으로는 이방인에게도 다정할 수 있지 않을까요? 오늘 이 아티클 덕분에 낯선 이에게 조금 더 친절할 수 있었고, 더 괜찮은 사람이 되겠다는 다짐을 했습니다. https://www.folin.co/article/10337/gift/DghwhBThRk5eYf1Xrm2vYX7f6xiFZe6L

www.folin.co

《다정함도 체력에서 나오니까》

최근 DeepSeek에 이어 중국발 AI에이전트 돌풍(?)을 일으키고 있는 마누스(Manus) AI 내용을 정리해봅니다.

🍏 Manus AI 개요
 * 개발사: 중국 스타트업 Monica
 * 출시: 2025년 3월 6일
 * 기반 모델: Anthropic의 Claude 3.5 Sonnet과 Alibaba의 Qwen 모델 기반
 * 특징
   * 세계 최초의 범용 자율 AI 에이전트
   * OpenAI Deep Research, Gemini Deep Research 등에서 볼 수 있는 딥 리서치 기능을 구현한 멀티 에이전트 협업 시스템
   * 기존의 챗봇이나 AI 모델과 달리, Manus는 단순한 답변 제공을 넘어 실제 결과물을 도출하는 데 초점
   * 계획, 실행, 검증을 담당하는 별도의 에이전트들로 구성된 멀티 에이전트 아키텍처
   * 대규모 작업을 수백개의 실행 가능한 하위 작업으로 나누는 동적 타겟 분해 기능
   * 여러 유형의 데이터를 동시에 처리하는 교차 모달 추론 기능
   * 강화학습을 통한 의사결정 효율성 지속적인 개선 및 오류율 최소화
   * 지시를 기다리지 않고 스스로 작업을 시작하고 새로운 정보를 평가하며 접근 방식으로 동적으로 조정하는 자기주도적 작업 수행

🍏 기술적 특징
 * 멀티 에이전트 아키텍처
   * 계획 에이전트(Planning Agent)
     * 작업 분석 및 단계별 계획 수립
     * 사용자 요청을 PDCA(Plan-Do-Check-Act) 사이클로 분해
     * Monte Carlo Tree Search(MCTS) 알고리즘 활용
     * Anthropic Qwen 모델 기반의 텍스트 분석 및 전략 세분화
   * 실행 에이전트(Execution Agent)
     * 웹 브라우저/데이터베이스 등 27개 외부 도구와 실시간 연동
     * Claude 3.5 Sonnet 모델을 주력으로 사용
     * 비동기적 클라우드 처리 아키텍처 지원
   * 검증 에이전트(Validation Agent)
     * 결과 검증 및 최적화
     * 3단계 검증 프로세스: 형식 검증 (표 구조/코드 문법), 내용 검증 (사실 관계 확인, 컨텍스트 검증 (사용자 의도 부합 여부)
 * 성능 향상 메커니즘
   * 동적 모델 로딩: 작업 요구사항에 따라 GPT-4, Gemini 등 제3자 모델 추가 호출
   * 실시간 피드백 루프: 오류 발생 시 자동 재계획 알고리즘 가동
   * 크로스 모달 퓨전: 텍스트-이미지 결합 분석을 위한 어텐션 메커니즘 적용
 * 혁신적인 기능
   * 비동기 처리: Celery 작업규 + Redis 캐시 - 오픈라인 작업 지속 가능
   * 메모리 시스템: 벡터 데이터베이스 기반 장기 기억 - 사용자 패턴 학습 최적화
   * 보안 프레임워크: 샌드박스 가상머신 격리 - 외부시스템 영향 제거
 * 외부 도구 통합: 웹 브라우저, 데이터베이스, 코드 편집기 등 다양한 소프트웨어와 통합
 * 클라우드 기반 운영: 비동기적 클라우드 처리를 지원하여 효율적인 작업 수행 가능

🍏 성능
 * Meta AI와 Hugging Face가 개발한 GAIA 테스트에서 OpenAI GPT-4o 대비 18% or 23% 높은 정확도

🍏 단점 및 한계
 * 초기 오류 빈도: 무한 루프 발생, 오류 메시지 출력 등 초기 사용자 경험에서 문제 보고
 * 사실 정확성 부족: 정보 누락 또는 부정확한 데이터 제공 사례 존재
 * API 의존성: API가 없는 애플리케이션과의 호환성이 제한적
 * 복제 가능성: 자체 모델 개발보다는 통합에 의존하기 때문에 경쟁사에 의해 복제될 위험

🍏 비즈니스 가능성
 * 기업용 솔루션: B2B 공급업체 발굴, 재무 보고서 분석 등
 * 개인 비서 역할: 여행 계획, 보험 비교, 교육 과정 개발 등
 * 자동화된 업무 처리: 온라인 스토어 운영 분석, 채용 인터뷰 준비 등

🍏 미래 전망
 * 오픈소스화 계획: Monica는 2025년 말까지 Manus AI를 오픈소스로 공개할 계획
 * 확장성: 개발자들이 맞춤형 플러그인을 구축하거나 틈새 응용 프로그램에 최적화할 수 있는 가능성 제공

최근 DeepSeek에 이어 중국발 AI에이전트 돌풍(?)을 일으키고 있는 마누스(Manus) AI 내용을 정리해봅니다. 🍏 Manus AI 개요<ul><li>개발사: 중국 스타트업 Monica</li><li>출시: 2025년 3월 6일</li><li>기반 모델: Anthropic의 Claude 3.5 Sonnet과 Alibaba의 Qwen 모델 기반</li><li>특징<ul><li>세계 최초의 범용 자율 AI 에이전트</li><li>OpenAI Deep Research, Gemini Deep Research 등에서 볼 수 있는 딥 리서치 기능을 구현한 멀티 에이전트 협업 시스템</li><li>기존의 챗봇이나 AI 모델과 달리, Manus는 단순한 답변 제공을 넘어 실제 결과물을 도출하는 데 초점</li><li>계획, 실행, 검증을 담당하는 별도의 에이전트들로 구성된 멀티 에이전트 아키텍처</li><li>대규모 작업을 수백개의 실행 가능한 하위 작업으로 나누는 동적 타겟 분해 기능</li><li>여러 유형의 데이터를 동시에 처리하는 교차 모달 추론 기능</li><li>강화학습을 통한 의사결정 효율성 지속적인 개선 및 오류율 최소화</li><li>지시를 기다리지 않고 스스로 작업을 시작하고 새로운 정보를 평가하며 접근 방식으로 동적으로 조정하는 자기주도적 작업 수행</li></ul></li></ul> 🍏 기술적 특징<ul><li>멀티 에이전트 아키텍처<ul><li>계획 에이전트(Planning Agent)<ul><li>작업 분석 및 단계별 계획 수립</li><li>사용자 요청을 PDCA(Plan-Do-Check-Act) 사이클로 분해</li><li>Monte Carlo Tree Search(MCTS) 알고리즘 활용</li><li>Anthropic Qwen 모델 기반의 텍스트 분석 및 전략 세분화</li></ul></li><li>실행 에이전트(Execution Agent)<ul><li>웹 브라우저/데이터베이스 등 27개 외부 도구와 실시간 연동</li><li>Claude 3.5 Sonnet 모델을 주력으로 사용</li><li>비동기적 클라우드 처리 아키텍처 지원</li></ul></li><li>검증 에이전트(Validation Agent)<ul><li>결과 검증 및 최적화</li><li>3단계 검증 프로세스: 형식 검증 (표 구조/코드 문법), 내용 검증 (사실 관계 확인, 컨텍스트 검증 (사용자 의도 부합 여부)</li></ul></li></ul></li><li>성능 향상 메커니즘<ul><li>동적 모델 로딩: 작업 요구사항에 따라 GPT-4, Gemini 등 제3자 모델 추가 호출</li><li>실시간 피드백 루프: 오류 발생 시 자동 재계획 알고리즘 가동</li><li>크로스 모달 퓨전: 텍스트-이미지 결합 분석을 위한 어텐션 메커니즘 적용</li></ul></li><li>혁신적인 기능<ul><li>비동기 처리: Celery 작업규 + Redis 캐시 - 오픈라인 작업 지속 가능</li><li>메모리 시스템: 벡터 데이터베이스 기반 장기 기억 - 사용자 패턴 학습 최적화</li><li>보안 프레임워크: 샌드박스 가상머신 격리 - 외부시스템 영향 제거</li></ul></li><li>외부 도구 통합: 웹 브라우저, 데이터베이스, 코드 편집기 등 다양한 소프트웨어와 통합</li><li>클라우드 기반 운영: 비동기적 클라우드 처리를 지원하여 효율적인 작업 수행 가능</li></ul> 🍏 성능<ul><li>Meta AI와 Hugging Face가 개발한 GAIA 테스트에서 OpenAI GPT-4o 대비 18% or 23% 높은 정확도</li></ul> 🍏 단점 및 한계<ul><li>초기 오류 빈도: 무한 루프 발생, 오류 메시지 출력 등 초기 사용자 경험에서 문제 보고</li><li>사실 정확성 부족: 정보 누락 또는 부정확한 데이터 제공 사례 존재</li><li>API 의존성: API가 없는 애플리케이션과의 호환성이 제한적</li><li>복제 가능성: 자체 모델 개발보다는 통합에 의존하기 때문에 경쟁사에 의해 복제될 위험</li></ul> 🍏 비즈니스 가능성<ul><li>기업용 솔루션: B2B 공급업체 발굴, 재무 보고서 분석 등</li><li>개인 비서 역할: 여행 계획, 보험 비교, 교육 과정 개발 등</li><li>자동화된 업무 처리: 온라인 스토어 운영 분석, 채용 인터뷰 준비 등</li></ul> 🍏 미래 전망<ul><li>오픈소스화 계획: Monica는 2025년 말까지 Manus AI를 오픈소스로 공개할 계획</li><li>확장성: 개발자들이 맞춤형 플러그인을 구축하거나 틈새 응용 프로그램에 최적화할 수 있는 가능성 제공</li></ul>

마누스(Manus) AI

우디의 컨설팅:  합격으로 가는 3가지 차별점 회사별 맞춤 포트폴리오,  합격을 부르는 비결입니다. 5회 코칭 진행 
 유니콘 프로덕트 디자이너로 최종 합격한 김** 님의 실제 리뷰입니다.  2회 코칭 진행 
 유니콘 프로덕트 디자이너로 최종 합격한 **호 님의 실제 리뷰입니다.  2회 코칭 진행 
 에이전시 → 스타트업 디자이너로 이직 성공한 **수 님의

[🦄 유니콘·빅테크] 합격한 UX/UI 포트폴리오 컨설팅 - PO·디자인 리드 우디 - 우디디자인랩

Q) 🧑‍💻 평소 업무나 협업 시, 본인의 커뮤니케이션 스타일은 어떤 편인가요? (우디)

A) 🙋‍♀️ 저는 상대방이 궁금해하거나 필요로 할 수 있는 정보를 구체적으로 전달하려는 편이에요. 가령 프로젝트를 진행할 때도, “이건 왜 필요한가” “어떤 방식으로 진행될 것인가” 같은 구체적인 맥락을 먼저 짚어요. 특히 추가 설명이 필요할 것 같은 부분은 상세하게 적어서 미리 공유하고, 혹시 오해가 생기지 않도록 직접 확인하려고 노력합니다. 제가 조금 더 신경을 써야 의사소통 과정에서 불필요한 혼란을 줄일 수 있다고 생각해요. (5년차 UX/UI 디자이너분)

* 저맥락 커뮤니케이션을 통해 오해를 줄이는 커뮤니케이션 스타일이 느껴져 좋았습니다.

Q) 🧑‍💻 평소 업무나 협업 시, 본인의 커뮤니케이션 스타일은 어떤 편인가요? (우디) A) 🙋‍♀️ 저는 상대방이 궁금해하거나 필요로 할 수 있는 정보를 구체적으로 전달하려는 편이에요. 가령 프로젝트를 진행할 때도, “이건 왜 필요한가” “어떤 방식으로 진행될 것인가” 같은 구체적인 맥락을 먼저 짚어요. 특히 추가 설명이 필요할 것 같은 부분은 상세하게 적어서 미리 공유하고, 혹시 오해가 생기지 않도록 직접 확인하려고 노력합니다. 제가 조금 더 신경을 써야 의사소통 과정에서 불필요한 혼란을 줄일 수 있다고 생각해요. (5년차 UX/UI 디자이너분) * 저맥락 커뮤니케이션을 통해 오해를 줄이는 커뮤니케이션 스타일이 느껴져 좋았습니다.

Latpeed

기억에 남는 디자이너 면접 답변 [9]

OpenAI의 마켓침투가 여러면에서 매우 영리하게 동작합니다.

대학의 학생, 교수진, 연구원 및 캠퍼스 운영에 AI를 배포할 수 있도록 구축된 ChatGPT-4o 기반 버전인 ChatGPT Edu를 발표했습니다.

이 새로운 솔루션은 엔터프라이즈급 보안과 제어 기능을 포함하며 교육 기관에 적합한 합리적인 가격으로 제공된다고 합니다. 아무래도 학생들에겐 매달 20달러의 사용료에, 개발을 위한 API사용료가 부담이 될텐데 그 부분을 크게 해결해 주겠네요

이런 결정은 아무래도 MSFT의 지원이 없이는 가능하지 않아 보이는데요. 사실 대학이나 교육기관에 소프트웨어 프레임워크를 제공하는 것은 미래 투자 성격이 강합니다. 당연히 학교에서 사용한 ChatGPT의 사용과 활용 뿐만 아니라 개발 플랫폼으로서 표준처럼 자리를 잡을 것이고, 여기서 부터 수많은 생태계와 스타트업이 나올겁니다. 여기에서 그치지 않고, 마이크로소프트는 업무용과 학업용으로 365와 함께 코파일럿을 자연스럽게 넣을겁니다. 그러면서 Azure 클라우드가 들어갈테구요.

이렇게 되면 이 환경에서 공부를 하고 연구를 한 분들은 자연스럽게 이런 툴에 익숙해져서 졸업 후에도 이 환경이 아닌 다른 곳으로 이동하기 힘든 락인이 됩니다. 마이크로소프트가 전통적으로 해왔던 비즈니스 모델이죠.

우리나라의 대표 AI기업들도 적극적으로 이런 움직임을 보였으면 합니다. 당장의 수익보다는 튼튼한 생태계 구축을 하는 것에 우선 순위가 있기를 바라고 그러려면 누군가 씨를 뿌려야 하거든요.
https://openai.com/index/introducing-chatgpt-edu/

OpenAI의 마켓침투가 여러면에서 매우 영리하게 동작합니다. 대학의 학생, 교수진, 연구원 및 캠퍼스 운영에 AI를 배포할 수 있도록 구축된 ChatGPT-4o 기반 버전인 ChatGPT Edu를 발표했습니다. 이 새로운 솔루션은 엔터프라이즈급 보안과 제어 기능을 포함하며 교육 기관에 적합한 합리적인 가격으로 제공된다고 합니다. 아무래도 학생들에겐 매달 20달러의 사용료에, 개발을 위한 API사용료가 부담이 될텐데 그 부분을 크게 해결해 주겠네요 이런 결정은 아무래도 MSFT의 지원이 없이는 가능하지 않아 보이는데요. 사실 대학이나 교육기관에 소프트웨어 프레임워크를 제공하는 것은 미래 투자 성격이 강합니다. 당연히 학교에서 사용한 ChatGPT의 사용과 활용 뿐만 아니라 개발 플랫폼으로서 표준처럼 자리를 잡을 것이고, 여기서 부터 수많은 생태계와 스타트업이 나올겁니다. 여기에서 그치지 않고, 마이크로소프트는 업무용과 학업용으로 365와 함께 코파일럿을 자연스럽게 넣을겁니다. 그러면서 Azure 클라우드가 들어갈테구요. 이렇게 되면 이 환경에서 공부를 하고 연구를 한 분들은 자연스럽게 이런 툴에 익숙해져서 졸업 후에도 이 환경이 아닌 다른 곳으로 이동하기 힘든 락인이 됩니다. 마이크로소프트가 전통적으로 해왔던 비즈니스 모델이죠. 우리나라의 대표 AI기업들도 적극적으로 이런 움직임을 보였으면 합니다. 당장의 수익보다는 튼튼한 생태계 구축을 하는 것에 우선 순위가 있기를 바라고 그러려면 누군가 씨를 뿌려야 하거든요.https://openai.com/index/introducing-chatgpt-edu/

메디트 백엔드 엔지니어

권주성

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

신동수

하위

<ChatGPT Edu 발표>

대학에서 컴퓨터 공학을 전공하고, 한국내 Fujitsu의 소프트웨어 엔지니어로 사회생활을 시작, 그 후  프랑스 파리로 이주하여 SAP에서 개발매니저를 거쳐 현재 총괄 디자인그룹의 프로그램 매니저로 좋은 서비스와 UX로 세상을 즐겁고 행복하게 만들고자 합니다.

김영욱

책 <프로덕트 매니지먼트> 저자
한국에서 학업을 마치고, 한국 Fujitsu에서 개발자 커리어를 시작. 그 후 프랑스 파리로 이주, SAP에서 개발 아키텍트를 거쳐 클라우드 ERP 엔지니어링그룹의 시니어 프로그램 매니저로 세상에 행복한 서비스와 UX를 제공하려 합니다.

<ChatGPT Edu 발표>

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필