안녕하세요, 요즘 프로덕트 메이커입니다.
프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.
요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

클로드로 작업하다 보면 답변이나 결과물의 한국어가 어딘가 어색할 때가 있습니다. 조사가 빠지거나, 문장이 명사만 뚝뚝 이어지거나, 평소 잘 안 쓰는 단어가 튀어나오죠. 최근 이런 현상을 겪는다는 이야기를 자주 봤는데요. fluent-korean은 이를걸 잡아주는 도구입니다. snflkd라는 개발자가 만들어 GitHub에 공개했어요.
fluent-korean은 클로드에게 명확한 한국어를 쓰라고 미리 지시해두는 출력 스타일(output-style)입니다. 클로드 코드(Claude Code)라는 개발 도구에 붙여 쓰는 방식이지만, 지침 자체를 복사해 클로드 웹이나 앱, 다른 AI에도 적용할 수 있어요.

흥미로운 부분은, 이 도구가 왜 이런 문제가 생기는지까지 짚어준다는 점입니다.
AI 코딩 도구는 대개 말을 짧게 하도록 맞춰져 있습니다. 처리하는 글자 수(토큰)를 줄이면 비용이 내려가고 속도가 빨라지거든요. 문제는 이 간결함이 한국어에서 문장 성분을 생략하는 쪽으로 나타난다는 거예요. 영어는 단어 순서로 문장의 뼈대가 잡혀서 좀 줄여도 뜻이 대략적으로 통하는데, 한국어는 조사와 어미가 그 뼈대를 지탱해서 이것들이 빠지면 의미가 흔들립니다. 그래서 짧게 쓰라는 설정이 유독 한국어에서 어색한 문장을 만들어내죠.
fluent-korean을 만든 사람은 여기에 한 가지를 더 짚습니다. 어색한 한국어가 단순히 읽기 불편한 데서 끝나지 않는다는 거예요. 요즘 AI는 답을 내기 전에 스스로 생각하는 과정(추론)을 거치는데, 그 생각을 흐린 한국어로 하면 생각의 질 자체가 나빠질 수 있다는 겁니다. 문장이 어색해지는 문제가 아니라 판단이 흐려지는 문제라는 관점이죠.
한 가지 더 있습니다. 요즘은 여러 AI가 서로 한국어로 정보를 주고받으며 일하는 경우가 늘고 있어요. 이때 어색한 한국어가 단계마다 조금씩 쌓이면, 처음엔 사소했던 의미 손실이 마지막엔 결과물 전체의 완성도를 떨어뜨릴 수 있습니다.
클로드 코드를 쓴다면 명령어 두 줄로 설치합니다.
/plugin marketplace add snflkd/fluent-korean
/plugin install fluent-korean@fluent-korean설치한 뒤 설정에서 출력 스타일을 고르고, 새 세션을 시작하면 적용됩니다. 코딩 지침을 함께 담은 버전과, 코딩 없이 글쓰기에만 쓰는 버전 두 가지가 있어요.
클로드 코드를 쓰지 않는 분이라면 더 간단합니다. 이 도구의 지침 텍스트를 클로드 웹이나 앱의 설정(개인 지침)에 붙여넣으면 돼요. 무료이고(MIT 라이선스), 세부 취향도 고를 수 있습니다. 초보 개발자도 이해하게 써달라거나, 높임말을 쓰게 하거나, 잘 안 쓰는 어려운 단어를 피하게 하는 식으로요.
명령어가 익숙하지 않다면, 클로드에게 이 저장소 주소를 주면서 README 읽고 설치 방법 알려줘라고 부탁하는 방법도 있습니다. 이 경우 알아서 내 환경에 맞게 안내해주죠.
한 가지 알아둘 점은, 이 방식이 토큰을 조금 더 쓴다는 겁니다. 생략됐던 문장 성분을 되살리니 그만큼 글자 수가 늘어나거든요. 품질과 비용을 맞바꾸는 셈인데, 한국어 결과물의 완성도가 중요한 작업이라면 그만한 값어치가 있을 것 같습니다.
참고로 이 도구를 만든 사람은 국어국문학 전공자라고 밝혔고, README에 앤트로픽이 이 글을 보면 연락 달라, 클로드에게 한국어가 무엇인지 알려주겠다는 위트 있는 문구도 남겼죠. (ㅎㅎ) 비슷한 목적의 다른 도구(im-not-ai, korean-skills 등)도 여럿 나오고 있어서, 한국어를 쓰는 개발자들이 같은 문제의식을 공유하고 있다는 것도 엿볼 수 있었습니다.

AI 에이전트를 직접 만들거나 깊이 이해하고 싶은 분께 반가운 자료가 나왔습니다. AI 에이전트를 깊이 이해하기라는 책의 한국어판이 8월 19일 공개됐어요. 원저자는 중국의 개발자 리보제(Bojie Li)이고, 한국어판은 커뮤니티 번역가가 옮겼습니다. 전체가 무료로 공개된 오픈소스 자료예요.
미리 말씀드리면, 이 책은 에이전트를 만드는 사람을 위한 본격 기술서에 가까운 자료입니다. 강화학습 같은 깊은 주제까지 다뤄주죠. 그래서 개발이 주 업무가 아니라면 처음부터 끝까지 볼 필요는 없습니다. 다만 요즘 여기저기서 들리는 에이전트라는 게 대체 어떻게 굴러가는 건지 그 큰 그림을 잡고 싶다면, 앞부분만 봐도 얻어갈 수 있는 것들이 있습니다.
책은 에이전트를 한 문장으로 정리합니다. 에이전트 = LLM + 컨텍스트 + 도구예요. 저자는 이걸 사람에 빗대 두뇌 + 눈 + 손발이라고 풀어줍니다.
두뇌(LLM)는 생각하고 판단하는 부분이에요. 눈(컨텍스트)은 에이전트가 무엇을 볼 수 있는지, 그러니까 어떤 정보와 지시를 갖고 일하는지를 정합니다. 손발(도구)은 에이전트가 실제로 무엇을 할 수 있는지, 검색이든 파일 작업이든 그 행동의 범위를 정하고요. 요즘 에이전트가 똑똑해 보이는 건 두뇌만 좋아서가 아니라, 이 눈과 손발을 잘 설계했기 때문이라는 게 책의 관점입니다.
이 비유 하나만 가져가도, 에이전트 관련 소식을 읽을 때 지금 이건 두뇌 얘기인가, 눈 얘기인가, 손발 얘기인가를 구분하며 볼 수 있어요. 앞선 회차들에서 다룬 컨텍스트 엔지니어링이 왜 중요한지도 이 틀로 보면 선명해집니다. 결국 에이전트에게 무엇을 보여줄지(눈)를 다루는 일이니까요.
저자는 서문에서 실천이 먼저이고 이름은 나중이라고 말합니다. 스킬이나 하네스처럼 요즘 에이전트 업계를 휩쓴 용어들이, 사실은 어떤 회사가 발명한 게 아니라 이미 현장에서 쓰이던 방식에 나중에 이름을 붙인 것뿐이라는 거죠.
여기서 저자가 끌어내는 교훈은 프로덕트 메이커에게도 통합니다. 어떤 용어가 유행하기 시작할 즈음이면, 앞서가는 곳은 이미 그 문제를 풀어본 뒤라는 겁니다. 유행어가 퍼지고 나서야 시작하면 이미 한발 늦은 셈이죠. 남보다 앞서고 싶다면 이름이 붙기 전에 직접 부딪혀 봐야 하는데, 이건 개발만이 아니라 새로운 걸 다루는 모든 일에 해당하는 이야기일 것 입니다.
이 책이 무료로 풀린 배경도 그렇습니다. 저자는 인세를 받는 대신 오픈소스 공개를 택했어요. 이 지식이 더 많은 실무자에게 닿기를 바란다는 이유였습니다.
개발자라면 94개의 실습 코드까지 딸려 있으니, 에이전트를 만드는 실전 교재로 삼을 만합니다. 개발자가 아니라면 두 가지만 기억해도 충분해요. 에이전트는 두뇌와 눈, 손발로 이뤄진다는 틀, 그리고 실천이 먼저이고 이름은 나중이라는 관점이요. 이 둘만 알아둬도 요즘 쏟아지는 AI 에이전트 소식을 한결 차분하게 볼 수 있을 거라 생각합니다. 무료로 공개돼 있으니 앞부분만 부담 없이 살펴봐도 좋을 것 같고요.

최근 AI로 뭐든 빠르게 만들 수 있게 되면서, 그럼 사람은 뭘 해야 하나 하는 질문이 많아졌습니다. 그리고 그에 대한 여러 관점과 의견도 나오고 있고요. 그중에서 시애틀의 개발자 조지프 헥(Joseph Heck)이 자기 블로그에 쓴 글을 소개하려 합니다. 흔히 나오는 관점과 취향을 길러라 같은 이야기에서 한발 더 들어가, 그래서 구체적으로 뭘 어떻게 챙겨야 하는지를 짚어주기 때문입니다. 저자는 개발자를 위해 쓴 글이지만 핵심 내용은 제품을 만드는 누구에게나 통한다고 생각해, 개발 이야기를 조금 걷어내고 프로덕트 메이커의 언어로 옮겨봤습니다.
저자는 20대에 용접을 배웠던 이야기를 꺼냅니다. 금방 뭔가를 만들어냈는데, 너무 크고 무거워서 작업장 문 밖으로 꺼낼 수조차 없었다고 합니다. 만드는 것과 실제로 쓸 수 있게 만드는 것은 다른 일이라는 걸 그때 배웠다고 하죠.
AI도 비슷한데요. AI로 작동하는 무언가를 뽑아내는 건 이제 쉬워졌습니다. 프로토타입이든 랜딩페이지든 하루면 나오죠. 그런데 그건 시작점이지 끝이 아니에요. 그게 실제로 굴러가는 제품이 되려면, 고객 문의에 대응하고, 내용을 고치고, 다른 기능과 붙이는 긴 과정이 남습니다. 급하게 만든 것이 이 단계에서 오히려 발목을 잡기도 하고요. 만드는 순간보다 만든 뒤 오래 데리고 살 것을 생각하며 판단하는 게 중요하다는 이야기입니다.
저자가 가장 힘주어 말하는 대목입니다. 개별 조각을 만드는 것보다, 그 조각들이 서로 맞물리는 이음새를 설계하는 게 훨씬 어렵다는 거예요.
개발자에게 이음새는 코드와 코드가 만나는 지점, 기능을 외부와 연결하는 방식입니다. 이를 프로덕트 메이커에게 옮기면, 기능과 기능이 이어지는 흐름, 화면에서 화면으로 넘어가는 경험, 여러 조각이 하나의 제품으로 통합되는 지점이라 할 수 있을 것 같습니다. AI에게 개별 기능이나 화면을 하나씩 만들라고 하면 곧잘 해냅니다. 그런데 그것들이 자연스럽게 이어지는지, 사용자가 A에서 B로 넘어갈 때 매끄러운지는 잘 챙기지 못하죠. 각 조각은 훌륭한데 합쳐놓으면 어딘가 어긋나는 경험, 다들 겪어보셨을 겁니다. AI가 조각을 잘 만들수록, 그 조각들을 하나의 경험으로 잇는 사람의 안목이 더 중요해집니다.
저자는 냉정하게 짚습니다. AI는 사실 추론하지 않는다는 거예요. 인간이 남긴 방대한 지식을 압축해뒀다가, 다음에 올 말을 예측해 내놓는 것에 가깝다고 합니다. 그래서 인간 지식에 이미 담긴 문제는 잘 풀지만, 전에 없던 새로운 상황에서는 약하죠.
이 이야기는 AI가 어떤 상황에서 약한지 알려줍니다. 많이 논의된 흔한 문제는 잘하지만, 처음 마주하는 문제에선 그럴듯하게 틀릴 수 있어요. 그럼 어떻게 해야 할까요. 저자의 답은 막연하지 않습니다. 저자의 답은 막연하지 않아요. 오히려 당연하게 들릴 만큼 구체적입니다. AI에게 좋고 간결한 자료를 적절한 때에 주고, 결과가 맞는지 확인할 방법을 함께 붙이라는 겁니다. 이건 개발만의 이야기가 아니라 AI에게 일을 시키는 법 자체에 가까워 보입니다. 기획서를 맡기든 리서치를 시키든, 좋은 자료를 주고 결과를 검증하는 습관은 직무를 가리지 않아요.
저자가 걱정하는 지점이 하나 더 있어요. AI는 좋은 지시와 나쁜 지시를 구분하지 못한 채, 시키는 대로 지치지 않고 따른다는 거예요. 좋은 판단 없이 지시만 충실히 따르는 존재가 오히려 무섭다고까지 말합니다.
프로덕트 메이커에게 이건 방향의 문제입니다. AI가 유능할수록, 사람이 잘못된 방향을 잡으면 그 잘못을 아주 빠르고 그럴듯하게 완성해버리겠죠. 그러니 AI가 얼마나 잘하느냐만큼, 무엇을 시킬지를 정하는 사람의 판단이 결과를 좌우합니다.
저자가 마지막에 던지는 요점입니다. 만들기의 핵심은 어떤 부분을 안정적으로 고정하고, 어떤 부분을 유연하게 바꿀 수 있게 둘지 정하는 데 있다는 거예요. 만병통치약은 없고, 늘 무엇을 얻고 무엇을 포기할지 고르는 일이라고 합니다.
이건 사실 기획의 본질과 맞닿아 있습니다. AI가 뭐든 빠르게 만들어주니 다 바꿀 수 있을 것 같지만, 그럴수록 무엇을 안 바꿀지를 정하는 게 중요해질 겁니다. 제품의 뼈대로 삼아 고정할 부분과, 실험하며 바꿔갈 부분을 나누는 판단이요.
다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.