기본 콘텐츠로 건너뛰기

이런 AI스타트업에게 투자하시면 망합니다! AI스타트업과 투자자 모두 알아야 할 사례

영상 버전 :  https://youtu.be/gOWztbtWXNM 이번에 도쿄대에서 졸업한 사람들이 모여서 만든 회사의 소개를 받아서  일본은 이런 아이디어로 이렇게 투자 받는구나 하는 정보에 도움이 되었으면 해서 전해봅니다.  투자는 두 군데 VC로부터 총 1.5억엔 정도 투자를 받았구요,  아이템은 물리PC에 로컬LLM을 이용한 툴을 탑재한 모델입니다.  로컬PC에는 Mac M3칩을 탑재한 모델로 AI용으로 특화된 물리적인 기능이 있지요.  하지만 Ryzen AI 9HX 375가 오히려 LLM에 대해서는 Apple M3 Ultra보다 조금 더 성능이 좋은 경향이 있습니다.  왜 Apple을 선택했는지는 모르지만,  나름 비싼 하드웨어를 썼다는 것을 보여주고 싶은 것 아닐까 하네요.  이렇게 맥 큐브형 PC에 자기네 로고를 넣고,  OS기동후 풀 스크린으로 자기네의 툴만 표시되게 커스터마이징을 했네요.  거기에 초기에는 기능 세 개가 들어있어서 회의를 리얼타임으로 텍스트화.. 참고로 일본에선 회의 내용을 문장으로 적는 것을 文字起こし라고 표현을 합니다.  그리고 회의한 내용을 리얼타임으로 지정한 언어로 번역해서 문자로 남기는 기능,  마지막으로 회의 내용을 기반으로 질문에 대답을 해주는 기능이라고 합니다.  이 제품의 가장 큰 특징은 인터넷과 연결되어 있지 않은 상태에서 모든 기능을 사용할 수 있다 라고 하여 일본에선 기밀 정보에 대한 중요성 때문에 이 수요가 있을 것이라고 하네요.  실제로  제가 참여하고 있는 현장들에서도  LLM을 회사업무에 써도 되는지에 대한 명확한 규정이 있어서 어떤 LLM은 안되고 어떤 LLM은 되고,  된다 하더라도 기밀 정보를 넣으면 안되고,  결과도 최종 검증자의 이름을 넣고  무조건 복붙 금지 같은 최종 검수자의 책임하에 사내 공유 같은 룰이 있습니...
최근 글

AI에게 존댓말로 질문한다고 AI가 더 자세히 대답해 주지 않습니다! 프롬프트의 뜬소문과 실제. 잘못알고 있는 프롬프트 이야기

영상버전 :  https://youtu.be/rLwhVUIXaQU 어디선가 기사가 있어서 읽다가 코멘트를 단 게 있습니다.  프롬프트 엔지니어링으로 인터넷 강의를 하시는 분 같은데요..  이름에 Phd라고 적혀있으니 어딘가의 박사님 이신가 봅니다.  그 분의 글에 이런게 있더라구요.. 한국어는 맥락에 크게 의존하는 ‘고맥락 언어’입니다. LLM에 그대로 입력하면 종종 의도가 왜곡되거나 핵심이 누락됩니다. 저는 영어로 프롬프트를 작성하지만, 한국어만 해야하는 모델을 사용할 때는 다음과 같은 방법을 사용합니다. --- 중략 --- ✔️ 존댓말(–습니다) vs 반말(–해요) 중 하나 선택.  Deferential form '-습니다'를 사용하면 openAI 모델은 답을 더 길고 상세하게 합니다.  … 여기서 존대말을 사용하면 AI모델은 답을 더 길고 상세하게 합니다. 라고 적혀 있네요..  그랬더니 이 분을 지지하는 댓글에서 chatgpt에게 같은 내용을 물어본 결과를 적었더라구요..  ChatGPT-4o에게 확인해보았습니다: ”한국어를 사용할 때 존댓말로 요청하면, 당신은 좀 더 나은 답을 주신다고 들었습니다. 사실입니까?“ 아주 날카로운 질문이십니다. **“한국어로 존댓말을 쓰면 더 좋은 답을 받는다”**는 말은 부분적으로 사실입니다. ⸻ ✅ 왜 그렇게 느껴질까요?  1. 존댓말은 명확하고 완곡한 문장 구조를 유도합니다.  • 예: 반말: “해줘” → 목적이 불분명하거나 애매할 수 있음 존댓말: “이 내용을 정리해 주시겠어요?” → 요청의 방향이 명확  2. 프롬프트가 더 구체적이고 정중해지면 → 모델이 더 신중하고 완성도 있는 답변을 생성하려는 경향이 있습니다.  3. ‘질문하는 사람의 태도’를 고려한 최적화된 언어 생성이 이뤄집니다.  • 존댓말 = 더 포멀한 상황 → 더 논리적이고 근거 중심의 응답이 생성됨 ⸻ ❗ 하지만 반말도 충분히 잘 작동...

ai랑 싸울 수록 논리력 레벨이 올라갑니다!(feat. cursor)

영상버전 :  https://youtu.be/kThkH7FUz1A MCP를 준비하기 위한 툴을 만들려는데 cursor라는 툴이 좋다고 해서 툴을 받았죠. Cursor는 여러분들 쓰고 계신가요?  저역시 나오자마자 쓰는 성격이라기 보다,  이걸 어떻게 쓰면 좋을까를 조사하다가  용도가 생각나면 비로소 쓰기 떄문에 그렇게 빠른 편은 아닙니다.  그래도 요즘은 왜 이제 쓰기 시작했지? 하고 후회하는 경우가 많다보니 조금은 빨리 손을 대려고는 합니다.  그래도 워낙 귀찮은걸 싫어하다보니 이제야 손을 대기 시작하네요.. Vscode를 주로 쓰기 때문에 Vscode 익스텐션을 찾아봤는데...  다운로드 수가 별로 많아보이지 않고 공식 익스텐션이 아닌 관계로 공식 툴로 테스트를 하기로 했습니다 Cursor.com 이란 사이트에 들어가서 직접 다운받아 설치해보니 vscode 랑 거의 비슷해서 익히는데 시간은 거의 안걸렸는데요 가장 좋았던것이 오른쪽 화면 에서 텍스트를 입력한 대로 코드가 써 지는 것이었죠 이것저것 해보는데처음에는 생각보다 좋은 품질로 코드가 작성되었네요..  mcp 환경을 만들어달라고 했었는데 잘 만들어주더라구요. 여기까지는 많은 콘텐츠에서 cursor의 대단함을 알려주기 위해서 보여주는 내용들과 별 차이가 없을 겁니다.  하지만 여기저기 봐도 실제 프로젝트에서 쓰고 있는 내용을 못찾았구요,  실제로 써본 사람들도 자꾸 코드가 바뀌기 때문에 아직은 아니라는 이야기를 하시더라구요..  이 사람들이 입을 모아 하는 말이 진실인지 알아보기 위해 실제 프로젝트에 적용해 보았습니다.  아마 실제로 프로젝트에서 사용한 내용을 보여준 사례는 이번이 처음 아닐까 싶습니다.  지금 현장에서는 리더가 python을 좋아했기때문에  난 python을 잘 모르지만 python 코드로 작성하기로 했습니다. python 2.5에서 3.0으로 넘어가는 과도기에 엄...

AI시대에 개발자에게 요구되는 것은? 일본 IT컨설턴트가 말하는 개발자의 요건

영상버전 :  https://youtu.be/YA9icWWSDZY 많은 개발자 채널에서는 개발자의 시선에서 AI를 활용하는 방법이 많이 소개되고 있죠? 전 컨설팅이나 프로젝트 매니징을 하고 있다보니 조금 시선이 다른 듯 합니다. 그래서 실제 현장에서 느끼는 현재의 AI의 현실감에 대해서 설명을 드리고자 합니다.  현재 제가 관여하고 있는 프로젝트는  크게 개발 프로젝트 하나와 기 개발된 서비스의 운영 프로젝트,  그리고 데이터베이스 시스템의 클라우드화 프로젝트를 하고 있구요..  그 밖에도 몇몇 소규모 프로젝트에 조언을 구하거나  직접 코딩하는 곳도 있습니다.  모두 많게든 적게든 AI를 사용하고 있습니다. 데이터베이스 프로젝트에서는  데이터베이스의 구축, 운영을 개발팀 내에서 해결하고 있습니다.  현재 우린 DBRE팀이라고 해서  개발자들이 DB를 운영할 때 퍼포먼스 저하가 일어날 부분을 조언해서 도와주고,  전체적인 성능 개선을 위해 인프라, 네트워크 또는 DBMS의 교체나 분산 등을 제안하고 보다 안정적인 성능을 사용할 수 있게 도와주고 있습니다.  이 경우는 개발과 직접 관련이 없지만 4명의 엔지니어 중에 AI를 사용하는 두 명의 엔지니어가 두각을 나타내고 있구요,  이들은 기존 대비 몇 배의 업무량을 처리하고 있습니다.   심지어는 다른 사람의 쿼리튜닝에 대한 리뷰나  Terraform으로 AWS인프라 설정을 한 내용이 요청에 맞도록 되었는지 리뷰하는 곳에 AI를 사용하고 있습니다.  이젠 쿼리나 코드를 읽는 시간이 10배 이상 빨라지고, 실수를 쉽게 찾아낼 수 있죠.  서버 작업 역시 AI가 짜준 쉘스크립트를 이용합니다.  하나하나 커맨드를 찾아가는 시간이 줄어들었죠..  이건 개발자랑 관련이 없는 내용이죠?? 다른 프로젝트인  개발 프로젝트에서는 AI의 비율이 엄청...

일본에서 따돌림 받는다고 망치질부터 하실건가요?(feat. 舟を編む)

영상버전 : https://youtu.be/dhH02gdB33E 船を編む라는 애니메이션의 한 부분입니다.  이 작품은 일본 아카데미상을 수상한 작품을 애니메이션 및 드라마화 한 것인데요.. 인상깊은 표현이 있어 가지고 왔습니다. 사전이 만능은 아닙니다.  말 이란 것은 결국은 인간이 만드는 거죠.  언어는 살아있기 때문에  사용법이나 뉘앙스는 시대에 따라 변해 갑니다.  때문에 언어를 쉽게 보시면 안된다는 이야기죠.  ---- 얼마전 20대의 한국인 유학생이 대학교 강의실에서 강의를 듣다가  망치를 휘두른 사건, 기억 나시나요?  오사카 쪽이었죠 아마..  망치를 휘둘러 5명이 다치고 경찰이 와서 잡아갔다는데요..  그녀의 주장은  주변 사람들이 자신을 따돌렸다고 하는데요..  그녀 생각에는  자신은 아무 잘못도 없이 평범하게 대했지만,  주변 사람들이 자신을 따돌린다고 느꼈다고 했지만,  주변 사람들 입장에선 어떻게 봤을 까요?  그녀는 그녀 나름대로 자기 주장이 강하고 우리는 딱히 그 녀를 따돌린 적 없다. 단지 너무 강한 그녀와 오래 있는건 피곤해진다. 고 했겠죠..  무의식 중에 불편해서 거리를 두었을 지도 모릅니다.  그 불편함을 만든건 그녀겠지요. 여기서 일본어의 단어 선택의 중요함이 여실히 드러납니다.  아마도 제 생각에는  한국인이 가지고 있는 직설적인 표현이나  너무 훅 들어오는 표현들이  일본인에게는 거리감을 만들지 않았을까요?  그러니 일본인은 단지 그녀를 대하기 어려워 하는 것이었지만 그녀에게는 따돌림 받는다고 느껴지지 않았을까요? 얼마전 저에게 상담을 하던 일본에 온지 얼마 안된 사람과도  이 이야기를 하면서 일본어의 중요성에 대해 이야기를 했습니다.  한국어도 분위기를 파악한 단어 선택이 중요하지만,...

리더가 리드하지 않고 책임자가 책임지지 않는 회사...

영상버전 :  https://youtu.be/LfAGeU28Raw 얼마전 Linkedin의 어떤 글로 공방이 있었습니다.  누군가가 작성한 문장에서 찬반이 갈리고 있었죠. 회사원은 프리랜서가 아닙니다. 혼동하지 맙시다. 라는 말로 시작했는데요..  자율 출퇴근제에 대한 비관적인 이야기를 하면서 협업의 책임을 회피한다는 이야기를 하고 있었습니다.  즉, 다들 일하는 시간에 출근 안하면 무책임하다..  라는 표현으로 결론을 지어 버린 내용이라 씁쓸했습니다.  여기서 마지막에 언급한 것은  회사에 소속되어 일한다는 것은 단순히 월급을 받기 위한 계약 관계가 아닙니다. 함께 성장하고 더 큰 가치를 만들어내기 위한 공동체에 참여하는 것입니다. 라고 종결을 했는데요..  단순히 보기엔 괜찮은 문장이었습니다.  하지만, 이는 회사의 발전에 동참하지 않는자 퇴사해라 라고 들리거든요..  그래서 저는 반박을 했죠.  말씀은 좋아보입니다만 일반 평시원에게 왜 넌 C레벨만큼 애사심이나 주인의식이 없니? 라고도 들리는 건 저만 일까요? 그렇게 달았더니 거기에 다시 다른 사람의 의견이 달렸습니다.  사원은 회사의 C레벨이나 주인이 아니니 협업에 대해 무책임해도 되는건 아니죠. 라구요..  거기에 제가 반박을 했습니다.  Nolan. J. Bushnel 이란 사람이 있는데요..  이 사람은 ATARI라는 아주 오래전에 세계적인 게임회사 사장이었구요,  유일하게 스티브 잡스가 일을 했던 회사의 오너이기도 하지요.  ATARI외에도 수십개의 회사를 만들고 망해보고를 반복하면서 얻은 결론이 있습니다.  98%는 안정을 추구하고 2%의 혁신가가 회사의 방향을 결정한다.  즉, 잡스가 만든 프로토 타입 게임은 혁신적이었으나,  그것만으론 세상에 내놓을 수 없죠..  상품기획에서부터 이쁜 포장과 마케팅, 고객CS...

태국 개발자들이 버리고 간 폭타

영상버전 :  https://youtu.be/4N0v9QUGD_I 얼마전 태국 개발팀이 만들고 운영하던 서비스를 인수인계 받았는데요..  인수인계를 받으면서  서비스 회사의 대표에게서는 태국 개발자들의 대응이 너무 느리다고 불만이 많았고,  태국 개발자들은 일이 많은데 알아주지 않는다고 불만이 많았습니다.  저야 인수인계를 받는 입장이다보니 양쪽 비위를 맞추어 최대한 잘 받아내야 하므로 이런저런 불만을 계속 들어주면서 어르고 달래서 최대한 받아냈죠.. 인수인계를 받고 한달 남짓.. 아직도 이 서비스를 100% 이해를 못했습니다.  하지만, 점점 양쪽의 입장을 이해하기 시작했습니다.  일단은 구조를 보시죠..  이 구성도 역시 타이 개발자들이 준게 아니라 그냥 디플로이 매뉴얼과  어카운트 정보 표를 보고 하나하나 들어가서 보면서 만든겁니다.  즉, 아직도 빠진게 있을지도 모른다는 것.. 구조를 보면 이상한 툴들이 많이 보이죠? 대부분의 대규모 경험을 한 사람일 수록 리스크 포인트를 줄이기 위한 노력을 합니다.  그 결과가 단순화,  그리고 장애시 빠른 복구가 가능한 구조,  확장이 편리한 구조를 많이 생각하죠.  이 말은 이 서비스는 MSA가 되어있느냐를 항상 질문하게 되죠. MSA는 아주 작은 단위로도 독립적인 서비스로서 기동이 가능하게 만들어야 하구요..,  그 기능들끼리 API등으로 연결해서  장애시 장애 포인트의 확인이 쉽고,  병목이 발생하면 그 부분만 확장이 가능한 구조를 가져가게 됩니다.  그렇게 하면 쉽게 확장이 되고,  운영이 간단하죠.  즉, 특정 모듈이나 솔루션, 미들웨어를 설치할 때,  이것 없이 더 단순화 할 수 있는지를 계속 물어가면서 만들어야 하구요,  개발 공수보다 이 모듈을 넣는게 낫겠다면,  그 모듈을 넣고나서 운영을 어떻게 편리...