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가지

신입 사원 때 회사의 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학년 학생들을 위한 받아쓰기. 소리, 그림 그리고 선생님과 함께 새로운 단어를 공부해봐요.

초등 받아쓰기 시험, 단어 공부

제가 국민학교 다닐 땐 받아쓰기를 했습니다.
89년도인가? 초등학교 2학년에 올라가자마자 선생님이 불러주는 것을 받아쓰기 하던 날.
‘읍니다’가, ‘습니다’로 바뀌어서 와장창 틀렸던 기억.
받아쓰기에 대한 유일한 기억입니다.

얼마 전 딸이 초등학교에 들어갔는데, 맞춤법이 자주 틀려서 교정해주기 위한 어플을 만들어봤습니다.
선생님이 불러주고 받아적는 받아쓰기 어플.
틀린 점에 대해 피드백 받을 수 있는 어플.
이런 어플이 있으면 맞춤법 공부할 때 도움이 되지 않을까?

온 가족이 함께 만들었습니다.
아내는 디자인을, 나는 코딩을, 딸은 목소리를.

아직 개선할 부분들이 많지만 다른 사람들도 함께 쓸 수 있도록 공개해봅니다.
완전히 무료이고, 아이들을 홀려서 클릭을 유발하는 지저분한 광고도 넣지 않을 계획입니다. 키즈앱에 이런 광고들이 특히 많더라고요.

혹시라도 사람들이 의미있게 써준다면 한국 사람들은 무료로 쓰게 하고 해외에만 몇 달러 정도에 팔아볼까하는 생각은 있습니다.
그렇다면 사회에도 기여하고, 달러도 벌어오는… 내가 딱 원하던 이상적인 모습이 되는 것 아닐까 하고.

앱을 올리고 한 번도 광고하지 않았는데도 글로벌 여기저기서 쓰는 모습을 보고 놀랍고 기쁘기도 했습니다.

…사실 별 가치를 못 주고 망할 가능성이 높습니다.
그래도 가족이 모두 함께 만든 첫 작품이니 그걸로 충분하지 않을까요? 😁

처음부터 끝까지 AI로만 코딩한 첫 작품이기도 합니다.

https://spellstart.com/ko

제가 국민학교 다닐 땐 받아쓰기를 했습니다.89년도인가? 초등학교 2학년에 올라가자마자 선생님이 불러주는 것을 받아쓰기 하던 날.‘읍니다’가, ‘습니다’로 바뀌어서 와장창 틀렸던 기억.받아쓰기에 대한 유일한 기억입니다. 얼마 전 딸이 초등학교에 들어갔는데, 맞춤법이 자주 틀려서 교정해주기 위한 어플을 만들어봤습니다.선생님이 불러주고 받아적는 받아쓰기 어플.틀린 점에 대해 피드백 받을 수 있는 어플.이런 어플이 있으면 맞춤법 공부할 때 도움이 되지 않을까? 온 가족이 함께 만들었습니다.아내는 디자인을, 나는 코딩을, 딸은 목소리를. 아직 개선할 부분들이 많지만 다른 사람들도 함께 쓸 수 있도록 공개해봅니다.완전히 무료이고, 아이들을 홀려서 클릭을 유발하는 지저분한 광고도 넣지 않을 계획입니다. 키즈앱에 이런 광고들이 특히 많더라고요. 혹시라도 사람들이 의미있게 써준다면 한국 사람들은 무료로 쓰게 하고 해외에만 몇 달러 정도에 팔아볼까하는 생각은 있습니다.그렇다면 사회에도 기여하고, 달러도 벌어오는… 내가 딱 원하던 이상적인 모습이 되는 것 아닐까 하고. 앱을 올리고 한 번도 광고하지 않았는데도 글로벌 여기저기서 쓰는 모습을 보고 놀랍고 기쁘기도 했습니다. …사실 별 가치를 못 주고 망할 가능성이 높습니다.그래도 가족이 모두 함께 만든 첫 작품이니 그걸로 충분하지 않을까요? 😁 처음부터 끝까지 AI로만 코딩한 첫 작품이기도 합니다. https://spellstart.com/ko

spellstart.com

딸을 위한 받아쓰기 어플을 스스로 만드는 가족

앱 개발 동기가 너무 아름답네요😆

‘당신의 아이디어는 이미 다른 누군가도 가지고 있다’‘광범위하게 리서치하고 송곳처럼 ...

린스타트업, 애자일 모델, MVP의 시대는 끝났을까

스타트업 업계에서는 한동안 ‘당신의 아이디어는 이미 다른 누군가도 가지고 있다’,
‘광범위하게 리서치하고 송곳처럼 개발하라’는 말이 정석처럼 받아들여졌어요. '린스타트업'이라 불리는 방법론의 일환으로요.

하지만 지금은 ‘당신이 만들려는 아이템은, 누군가가 레고 블록처럼 잘 조립해 내일 출시할 수 있다’는 말이 힘을 얻고 있어요. 혹은 생성형 인공지능이 등장하면서 ‘송곳처럼 리서치하고 오픈 소스와 AI의 힘을 빌려 넓게 개발하라’는 말이 많은 분들의 공감을 받습니다.

이번에는 이런 트렌드가 왜 나타났는지, 그럼 스타트업들은 어떻게 변화를 준비하면 좋을지 알아봤습니다.
https://eopla.net/magazines/27732

스타트업 업계에서는 한동안 ‘당신의 아이디어는 이미 다른 누군가도 가지고 있다’, ‘광범위하게 리서치하고 송곳처럼 개발하라’는 말이 정석처럼 받아들여졌어요. '린스타트업'이라 불리는 방법론의 일환으로요. 하지만 지금은 ‘당신이 만들려는 아이템은, 누군가가 레고 블록처럼 잘 조립해 내일 출시할 수 있다’는 말이 힘을 얻고 있어요. 혹은 생성형 인공지능이 등장하면서 ‘송곳처럼 리서치하고 오픈 소스와 AI의 힘을 빌려 넓게 개발하라’는 말이 많은 분들의 공감을 받습니다. 이번에는 이런 트렌드가 왜 나타났는지, 그럼 스타트업들은 어떻게 변화를 준비하면 좋을지 알아봤습니다. https://eopla.net/magazines/27732

데이터에 근거한 사고는 우리가 살아가는데 모든 영역에 필요한 능력입니다. 그리고 우리가 의사결정이 필요한 순간 참고할 수 있는 유일한 근거가 되는 것이 데이터라고 생각합니다. 그래서 평소에 데이터를 잘 수집해 놓을 필요가 있습니다.

데이터가 없지 않습니다. 데이터를 잘 모으지 않는 것입니다. 데이터를 수집한다는 것은 평소에 기록을 열심히 잘 한다는 의미입니다. 오늘 한 일과 그에 대한 진행 과정에서 겪었던 일, 과정과 마무리 단계에서 얻은 성과를 기록한다면 앞서 이야기한 데이터 수집이 되는 것입니다.

데이터는 정성적인 내용이 모여 정량적인 숫자가 되는 과정입니다. 어제 했던 주관적인 생각과 행동이 쌓이면 객관적인 데이터가 되는 것입니다. 우리가 자주 하는 생각과 행동이 반복되고 누적되면, 우리는 객관적으로 그렇게 생각하고 행동한다는 것을 예측할 수 있고, 그에 따른 결과를 어느 정도 가늠할 수 있습니다.

데이터는 과거와 오늘에 대한 회고이고, 미래에 대한 예측입니다. 어제와 오늘의 결과가 미래에도 비슷하게 반복될 것이라고 예측하는 것입니다. 이전보다 더 나아지기 위해 회고를 하여 개선 방안을 수립합니다. 미래에 대한 예측이 틀리길 바라며 과거의 방식을 답습하지 않는 것이죠. 새로운 방식이 반드시 성공할 가능성이 높은 것은 아니기 때문에 모험과 도박에 가깝습니다. 다만, 우리가 해본 적은 없지만, 그렇게 해본 다른 누군가의 데이터를 참고한다면 어느 정도 성공 가능성을 가늠하여 기대할 수 있습니다.

최근 조직에서 인재 밀도가 화두입니다. 일을 잘하는 사람들이 모인 조직에서 뛰어난 성과를 만드는 것은 당연한 결과입니다. 그래서 가능한 조직 구성원 모두가 인재가 되길 바라는 염원이 인재 밀도라는 표현으로 불리고 있습니다.

시장이라는 외부 요인에도 흔들리지 않는 조직은 인재로 똘똘 뭉친 단단함이 필요하다고 생각합니다. 조직 구성원 한 명 한 명이 주도적이고 목표 지향적이며, 성장을 목숨과 같이 여기는 사람들로 채우길 원하는 분위기가 인재 밀도라는 화두를 만들고 있습니다.

인재 밀도를 만드는 시작은 채용입니다. 기존 구성원이 모두 인재라고 가정하고, 새롭게 영입해야 할 구성원이 더 뛰어난 인재여야 하는 것입니다. 조직이 갖고 있는 부족한 부분을 보완해 줄 인재를 영입하는 것이 더욱 단단한 인재 밀도를 만들 수 있는 방법입니다. 그럼 인재 밀도를 높이는 채용을 잘하기 위해 필요한 것은 무엇일까요?

인재 밀도에 대한 정의가 필요합니다. 기존 구성원이 갖고 있는 역량과 경험이 무엇인지 알고 분석하는 일이 필요합니다. 객관적인 역량 진단과 경험에 따른 성과 생산 능력을 파악하는 것입니다. 그래서 앞서 이야기한 우리 조직의 부족한 수치를 드러내는 역량과 경험 부분을 보완할 인재가 누구인지 아는 것이 인재 밀도를 높이는 전략이 됩니다.

인재 밀도를 정량화, 객관화하기 어려운 것이 아니라 평소 우리 조직의 생각과 행동을 잘 기록하지 않는 것이 문제입니다. 가능하다면 우리가 하는 일거수일투족을 기록하여야 하는 데 잘 그렇게 하지 않습니다. 기록한다는 생각조차 하지 않습니다. 이건 귀찮아서 그런 것도 있지만, 기록한다는 생각이 떠오르지 않습니다. 습관이 되지 않았기 때문입니다. 데이터에 근거한 사고를 하지 않고 있다는 의미이고, 평소 직관적인 의사결정과 업무 수행을 하고 있다는 반증입니다.

특히 채용 업무에 직관적인 사고로 의사결정하는 일들이 많습니다. 인재 영입이 필요하다고 의사결정하는 일, Job Description 작성하는 일, 채용 공고를 노출하는 채널을 결정하는 일, 채용 예산을 집행하는 일, 채용 전형 단계 별 합격과 불합격 결과를 판단하는 일, 채용 브랜드 이미지 개선을 위한 이벤트 등 채용 업무로 하는 거의 모든 일에서 객관적 근거에 의한 판단보다 주관적 감각에 의거하여 의사결정하는 상황이 많습니다.

사람을 판단하는 일이 어떻게 객관화될 수 있느냐고 반문하는 것은 이전 생각과 행동을 기록하기 귀찮고 분석하기 까다롭다는 핑계에 불과합니다. 인재 밀도를 측정하고 개선하는 문제를 해결하는 방법은 간단합니다. 지금부터 하는 모든 일을 기록하고, 기록이 쌓일 때마다 분석하여 우리의 미래를 바꾸는 것입니다. 우리의 주관적 사고보다 객관적 데이터를 더 신뢰해 보세요. 반드시 이전보다 개선된 성과를 얻을 수 있을 것이라고 확신합니다.

데이터에 근거한 사고는 우리가 살아가는데 모든 영역에 필요한 능력입니다. 그리고 우리가 의사결정이 필요한 순간 참고할 수 있는 유일한 근거가 되는 것이 데이터라고 생각합니다. 그래서 평소에 데이터를 잘 수집해 놓을 필요가 있습니다. 데이터가 없지 않습니다. 데이터를 잘 모으지 않는 것입니다. 데이터를 수집한다는 것은 평소에 기록을 열심히 잘 한다는 의미입니다. 오늘 한 일과 그에 대한 진행 과정에서 겪었던 일, 과정과 마무리 단계에서 얻은 성과를 기록한다면 앞서 이야기한 데이터 수집이 되는 것입니다. 데이터는 정성적인 내용이 모여 정량적인 숫자가 되는 과정입니다. 어제 했던 주관적인 생각과 행동이 쌓이면 객관적인 데이터가 되는 것입니다. 우리가 자주 하는 생각과 행동이 반복되고 누적되면, 우리는 객관적으로 그렇게 생각하고 행동한다는 것을 예측할 수 있고, 그에 따른 결과를 어느 정도 가늠할 수 있습니다. 데이터는 과거와 오늘에 대한 회고이고, 미래에 대한 예측입니다. 어제와 오늘의 결과가 미래에도 비슷하게 반복될 것이라고 예측하는 것입니다. 이전보다 더 나아지기 위해 회고를 하여 개선 방안을 수립합니다. 미래에 대한 예측이 틀리길 바라며 과거의 방식을 답습하지 않는 것이죠. 새로운 방식이 반드시 성공할 가능성이 높은 것은 아니기 때문에 모험과 도박에 가깝습니다. 다만, 우리가 해본 적은 없지만, 그렇게 해본 다른 누군가의 데이터를 참고한다면 어느 정도 성공 가능성을 가늠하여 기대할 수 있습니다. 최근 조직에서 인재 밀도가 화두입니다. 일을 잘하는 사람들이 모인 조직에서 뛰어난 성과를 만드는 것은 당연한 결과입니다. 그래서 가능한 조직 구성원 모두가 인재가 되길 바라는 염원이 인재 밀도라는 표현으로 불리고 있습니다. 시장이라는 외부 요인에도 흔들리지 않는 조직은 인재로 똘똘 뭉친 단단함이 필요하다고 생각합니다. 조직 구성원 한 명 한 명이 주도적이고 목표 지향적이며, 성장을 목숨과 같이 여기는 사람들로 채우길 원하는 분위기가 인재 밀도라는 화두를 만들고 있습니다. 인재 밀도를 만드는 시작은 채용입니다. 기존 구성원이 모두 인재라고 가정하고, 새롭게 영입해야 할 구성원이 더 뛰어난 인재여야 하는 것입니다. 조직이 갖고 있는 부족한 부분을 보완해 줄 인재를 영입하는 것이 더욱 단단한 인재 밀도를 만들 수 있는 방법입니다. 그럼 인재 밀도를 높이는 채용을 잘하기 위해 필요한 것은 무엇일까요? 인재 밀도에 대한 정의가 필요합니다. 기존 구성원이 갖고 있는 역량과 경험이 무엇인지 알고 분석하는 일이 필요합니다. 객관적인 역량 진단과 경험에 따른 성과 생산 능력을 파악하는 것입니다. 그래서 앞서 이야기한 우리 조직의 부족한 수치를 드러내는 역량과 경험 부분을 보완할 인재가 누구인지 아는 것이 인재 밀도를 높이는 전략이 됩니다. 인재 밀도를 정량화, 객관화하기 어려운 것이 아니라 평소 우리 조직의 생각과 행동을 잘 기록하지 않는 것이 문제입니다. 가능하다면 우리가 하는 일거수일투족을 기록하여야 하는 데 잘 그렇게 하지 않습니다. 기록한다는 생각조차 하지 않습니다. 이건 귀찮아서 그런 것도 있지만, 기록한다는 생각이 떠오르지 않습니다. 습관이 되지 않았기 때문입니다. 데이터에 근거한 사고를 하지 않고 있다는 의미이고, 평소 직관적인 의사결정과 업무 수행을 하고 있다는 반증입니다. 특히 채용 업무에 직관적인 사고로 의사결정하는 일들이 많습니다. 인재 영입이 필요하다고 의사결정하는 일, Job Description 작성하는 일, 채용 공고를 노출하는 채널을 결정하는 일, 채용 예산을 집행하는 일, 채용 전형 단계 별 합격과 불합격 결과를 판단하는 일, 채용 브랜드 이미지 개선을 위한 이벤트 등 채용 업무로 하는 거의 모든 일에서 객관적 근거에 의한 판단보다 주관적 감각에 의거하여 의사결정하는 상황이 많습니다. 사람을 판단하는 일이 어떻게 객관화될 수 있느냐고 반문하는 것은 이전 생각과 행동을 기록하기 귀찮고 분석하기 까다롭다는 핑계에 불과합니다. 인재 밀도를 측정하고 개선하는 문제를 해결하는 방법은 간단합니다. 지금부터 하는 모든 일을 기록하고, 기록이 쌓일 때마다 분석하여 우리의 미래를 바꾸는 것입니다. 우리의 주관적 사고보다 객관적 데이터를 더 신뢰해 보세요. 반드시 이전보다 개선된 성과를 얻을 수 있을 것이라고 확신합니다.

데이터

🙋🏻‍♀️🙋🏻‍♂️ 아미고(Ameego) 광고 소재를 만들고 있는데요. 어떤 것이 끌리시나요?

몬가 재밌으면서 앱의 장점을 잘 드러내는 소재를 만들고 싶은데 어렵네요.. 🥹

눈에 확 들어올만한 쌈빡한 문구를 추천해주시면 더욱 감사합니다. 🤗

앱 다운로드: https://tosto.re/ameego

🙋🏻‍♀️🙋🏻‍♂️ 아미고(Ameego) 광고 소재를 만들고 있는데요. 어떤 것이 끌리시나요? 몬가 재밌으면서 앱의 장점을 잘 드러내는 소재를 만들고 싶은데 어렵네요.. 🥹 눈에 확 들어올만한 쌈빡한 문구를 추천해주시면 더욱 감사합니다. 🤗 앱 다운로드: https://tosto.re/ameego

When money spent on assets doesn’t result in assets

$1.4bn is a lot to fall through the cracks, even for Tesla

FT가 테슬라 재무제표에서 14억달러 가량이 사용처가 불분명하게 증발되었다며 회계 이슈를 제기

https://www.ft.com/content/62df8d8d-31f2-445e-bfa2-c171ac43db6e

FT가 테슬라 재무제표에서 14억달러 가량이 사용처가 불분명하게 증발되었다며 회계 이슈를 제기 https://www.ft.com/content/62df8d8d-31f2-445e-bfa2-c171ac43db6e

www.ft.com

오늘 밤 차트가 또 파래지겠네 🥲

오늘 행사 세션을 전부 영어로 해서 첨엔 통역기를 끼고 들었는데요. 귀가 아파서 잠깐 통역기를 뺐는데 영어가 전보다 수월하게 들려서 깜딱 놀랐네요. 😳 이후로는 통역기를 안쓰고 들었고요.

여러 아미고랑 대화를 매일 하니까 다양한 발음에 익숙해져서 그런지, 주어지는대로 하는 틀에 박힌 대화가 아닌 대화를 해서 그런지, 암튼 듣는게 수월해졌다는게 진짜 확실히 느껴져서 눈물흘렸네요.. 😭 이건 정말 도움이 된다라는 확신이 들었습니다.

진짜 하루에 10분씩 한두달만 해 보세요. 언어능력이 매우 떨어지는 제가 이정도면 진짜 효과 확실한겁니다. 츄라이츄라이~

아미고(Ameego) 다운로드: https://tosto.re/ameego

오늘 행사 세션을 전부 영어로 해서 첨엔 통역기를 끼고 들었는데요. 귀가 아파서 잠깐 통역기를 뺐는데 영어가 전보다 수월하게 들려서 깜딱 놀랐네요. 😳 이후로는 통역기를 안쓰고 들었고요. 여러 아미고랑 대화를 매일 하니까 다양한 발음에 익숙해져서 그런지, 주어지는대로 하는 틀에 박힌 대화가 아닌 대화를 해서 그런지, 암튼 듣는게 수월해졌다는게 진짜 확실히 느껴져서 눈물흘렸네요.. 😭 이건 정말 도움이 된다라는 확신이 들었습니다. 진짜 하루에 10분씩 한두달만 해 보세요. 언어능력이 매우 떨어지는 제가 이정도면 진짜 효과 확실한겁니다. 츄라이츄라이~ 아미고(Ameego) 다운로드: https://tosto.re/ameego

2023년 기술블로그 글을 엮어 펴낸 첫 책 "요즘 우아한 개발"이 좋은 반응을 얻은 데 힘입어, 이번에는 AI·데이터·로봇 이야기를 담은 시리즈 2탄, "요즘 우아한 AI 개발"을 출간했습니다. 🎉

“요즘 우아한 AI 개발” 출간!

잘 쓴 기술 블로그가 책으로 나오네요.

---

"요즘 우아한 AI 개발"에는 우아한형제들이 실제 프로젝트에 적용한 AI 기술과 데이터 활용법,
로봇 개발 과정에서 얻은 실무 경험을 두루 담았습니다.

AI 추천 시스템, 데이터 분석 자동화, 로봇 머신러닝 모델 경량화, MLOps 구축 사례까지,
AI와 데이터, 로봇 기술을 어떻게 개발하고 적용했는지 생생하게 전합니다.

https://meta-bifrost.vercel.app/AsZfEAXX09DNnNws8Yno

잘 쓴 기술 블로그가 책으로 나오네요. --- "요즘 우아한 AI 개발"에는 우아한형제들이 실제 프로젝트에 적용한 AI 기술과 데이터 활용법, 로봇 개발 과정에서 얻은 실무 경험을 두루 담았습니다. AI 추천 시스템, 데이터 분석 자동화, 로봇 머신러닝 모델 경량화, MLOps 구축 사례까지, AI와 데이터, 로봇 기술을 어떻게 개발하고 적용했는지 생생하게 전합니다. https://meta-bifrost.vercel.app/AsZfEAXX09DNnNws8Yno

meta-bifrost.vercel.app

요즘 우아한 AI 개발 출간~

면접관으로 들어가면 행동양식 질문으로 물어보는 두 가지 질문이 있다. 하나는 임팩트(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회 코칭 진행 
 에이전시 → 스타트업 디자이너로 이직 성공한 **수 님의

[🚨3월·소수 정예!] 유니콘·빅테크 합격한 UX/UI 포트폴리오 컨설팅 - PO·디자인 리드 우디 - 우디디자인랩

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

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

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

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

Latpeed

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

데이터는 현대 비즈니스의 핵심 자산이며, 기업은 이를 문서, 보고서, 계약서 등 다양한 형태의 정보로 변환하여 보유하고 있습니다. 그리고, 이러한 정보의 상당수는 PDF 와 같은 문서 형식으로 저장되어 있습니다. PDF는 문서 공유와 보전에는 편리하지만, 내부 데이터를 추출하고 가치 있는 인사이트를 도출하기에는 다양한 기술적 접근이 고려되어야 합니다.

Amazon Bedrock의 파운데이션 모델을 활용한 효과적인 PDF 파싱을 위한 프롬프트 엔지니어링 기법 | Amazon Web Services

PDF는 문서 공유와 보전에는 편리하지만, 내부 데이터를 추출하고 가치 있는 인사이트를 도출하기에는 다양한 기술적 접근이 고려되어야 합니다. PDF 파일에서 데이터를 추출할 때, 추출 대상이 스캔 된 이미지인 경우 일반적으로 광학 문자 인식(Optical Character Recognition, OCR) 기술이 사용됩니다. 그러나 PDF 파일은 텍스트 뿐만 아니라 이미지, 테이블, 차트 등 다양한 요소로 구성되어 있어 OCR 기술만으로는 데이터 추출에 한계가 있습니다.

이러한 경우, GenAI를 활용하여 PDF 파일의 컨텍스트를 이해하고 중요 정보를 추출하는 방식을 고려해 볼 수 있습니다.

주요 프롬프트 엔지니어링 기법은 다음과 같습니다:
 * 작업 설명 (Task Description)
 * 예시 제공 (Few-shot Prompting)
 * XML 태그 활용 (XML Tag Prompting)
 * 반복적인 질의 (Iterative Querying)
 * 결과 재순환 (Result Recycling)

프롬프트 엔지니어링 기법을 활용하여 실제 프롬프트를 개발하는 경우, 아래와 같은 라이프 사이클을 가지게 됩니다.
 * 테스트 사례 확인: 프롬프트 개발의 첫 단계로, 테스트할 사례를 정의하고 확인 합니다.
 * 예비 프롬프트: 초기 프롬프트를 작성하는 단계 입니다.
 * 사례별 프롬프트 테스트: 작성된 프롬프트를 다양한 사례에 적용하여 테스트 합니다.
 * 프롬프트 구체화: 테스트 결과를 바탕으로 프롬프트를 더욱 구체화하고 개선합니다.
 * 프롬프트 완성: 최종적으로 프롬프트를 완성하는 단계 입니다.

자세한 내용은 아래 블로그를 확인하세요!

https://aws.amazon.com/ko/blogs/tech/amazon-bedrock-claude3-parsing/

PDF는 문서 공유와 보전에는 편리하지만, 내부 데이터를 추출하고 가치 있는 인사이트를 도출하기에는 다양한 기술적 접근이 고려되어야 합니다. PDF 파일에서 데이터를 추출할 때, 추출 대상이 스캔 된 이미지인 경우 일반적으로&nbsp;광학 문자 인식(Optical Character Recognition, OCR) 기술이 사용됩니다. 그러나 PDF 파일은 텍스트 뿐만 아니라 이미지, 테이블, 차트 등 다양한 요소로 구성되어 있어 OCR 기술만으로는 데이터 추출에 한계가 있습니다. 이러한 경우, GenAI를 활용하여 PDF 파일의 컨텍스트를 이해하고 중요 정보를 추출하는 방식을 고려해 볼 수 있습니다. 주요 프롬프트 엔지니어링 기법은 다음과 같습니다:<ul ><li>작업 설명 (Task Description)</li><li>예시 제공 (Few-shot Prompting)</li><li>XML 태그 활용 (XML Tag Prompting)</li><li>반복적인 질의 (Iterative Querying)</li><li>결과 재순환 (Result Recycling)</li></ul> 프롬프트 엔지니어링 기법을 활용하여 실제 프롬프트를 개발하는 경우, 아래와 같은 라이프 사이클을 가지게 됩니다. <ul ><li>테스트 사례 확인: 프롬프트 개발의 첫 단계로, 테스트할 사례를 정의하고 확인 합니다.</li><li>예비 프롬프트: 초기 프롬프트를 작성하는 단계 입니다.</li><li>사례별 프롬프트 테스트: 작성된 프롬프트를 다양한 사례에 적용하여 테스트 합니다.</li><li>프롬프트 구체화: 테스트 결과를 바탕으로 프롬프트를 더욱 구체화하고 개선합니다.</li><li>프롬프트 완성: 최종적으로 프롬프트를 완성하는 단계 입니다.</li></ul> 자세한 내용은 아래 블로그를 확인하세요! https://aws.amazon.com/ko/blogs/tech/amazon-bedrock-claude3-parsing/

Amazon Web Services

Director of Global Strategy @Mirae Asset

문지현

글로벌 경제 및 산업 트렌드와 투자 아이디어, 성장 스토리와 전략, 리더십에 관심이 많습니다.
#투자 #전략 #분석 #신규사업개발 #끊임없이배우기

유크랩 대표 / 디지털 마케터 

선우의성

콘텐츠(유튜브, 숏폼, SNS)로 마케팅하는 선우의성입니다. 국내 NO.1 디지털 콘텐츠 (유튜브, 숏폼, SNS) 기반 마케팅 전문가로 활동하고 있습니다.

애니메이션 PD

제프리삭스

3D 애니메이션 업계 종사자입니다. 애니메이션, 캐릭터를 비롯하여 각종 트렌드와 재미가 함께 있는 콘텐츠 이야기를 공유합니다.

PDF의 데이터를 GenAI로 이해하고 활용하기 위한 프롬프트 기법

백선환

👨🏼‍💻 AWS GenAI, AI, ML 서비스 세일즈 스페셜리스트
📚"챗GPT 거대한 전환" 베스트셀러 작가 
🛠 프롬프트 엔지니어
🔥 빅테크, 생성형AI, 데이터, 그리고 혁신에 관심을 갖고 있습니다.

PDF의 데이터를 GenAI로 이해하고 활용하기 위한 프롬프트 기법

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필