프롤로그어느 날 밤의 피로퇴근길에 새 모델 소식을 훑다가 갑자기 피로해진 날이 있었다. 반년 전 며칠을 붙잡고 겨우 이해한 기법 아래 "이제 이 방식은 끝났다"는 문장이 달려 있었다.그날 든 감정은 놀라움이 아니라 이거였다.나는 계속 따라가기만 하는구나. 뭘 해도 흉내내는 것 같다. 하네스 엔지니어링, 루프 엔지니어링, Hermes Agent...이걸 또 공부해야 하나...공부는 계속했다. 강의도 듣고 프로젝트도 굴려봤다. 그런데 양은 늘어나는데 밀도가 안 느껴졌다. ' 나는 계속 따라가기만 하고 있구나. 뭘 해도 흉내내는 것 같다.' 실무자로서 AI를 활용해서 무엇인가 시도하는 사람이라면 나와 같은 사람이 꽤나 될 것 같다. 1. AI 활용에 대한 프로젝트 경험의 축적이 필요하다생각해보면 실력이 부족한..

AI로 뭔가를 만들어 본 사람이라면 하네스(harness)를 안 만들 수 없다. 모델 혼자 두면 엉뚱한 데로 새니까, 앞뒤로 뭔가를 덧대게 된다. 출력 포맷을 강제하고, 단계를 쪼개고, 검증을 붙이고, 실패하면 다시 부른다. 그렇게 덧댄 것들이 쌓여서 하나의 구조물이 된다.문제는 이 구조물이 영원히 자산으로 남지 않는다는 점이다. 어떤 하네스는 6개월 뒤에 짐이 되고, 어떤 하네스는 5년 뒤에도 필요하다. 이 둘을 구분하지 못하면, 없어져도 되는 걸 붙들고 유지보수하면서 정작 필요한 건 아무도 안 적어두는 상태가 된다.구분선은 의외로 단순하다. 모델이 못해서 만든 하네스인가, 우리가 안 정해서 만든 하네스인가. 실행 하네스: 모델의 부족함을 메우는 것실행 하네스는 모델의 능력 부족을 보완하려고 만든 것들..

RAG(Retrieval-Augmented Generation) 시스템을 실제로 구축하다 보면, 튜토리얼에서는 절대 알려주지 않는 결정의 순간들이 찾아옵니다. "벡터DB에 다 넣으면 되는 거 아냐?"라고 생각하며 시작했다가, 문서를 어디에 어떻게 저장할지부터 사용자의 질의를 어떻게 해석할지까지, 매 단계가 선택의 연속이었습니다.이 글은 여러 종류의 전문 문서를 다루는 검색 시스템을 설계하면서 실제로 부딪혔던 네 개의 갈림길과, 각 지점에서 내린 판단의 근거를 정리한 기록입니다. 완성된 정답을 나열하기보다, "왜 그렇게 결정했는가"의 사고 과정을 담으려 했습니다.시작점: 왜 저장소를 세 개로 나누는가가장 먼저 정리해야 할 것은 데이터가 어디에 사는가입니다. 처음에는 벡터DB 하나면 충분해 보였지만, 실제로..

최근 랭그래프(LangGraph)를 활용한 멀티 에이전트 AI 서비스나 복잡한 공공 데이터를 다루는 데이터 기획 실무를 하다 보면 큰 고민에 빠지게 됩니다. 바로 '데이터 간의 숨겨진 맥락과 관계를 시스템에 어떻게 이해시킬 것인가' 하는 문제입니다.본 내용은 패스트캐퍼스에 '온톨로지 기반 프로덕트 레벨 AI Agent 서비스 구축' 공부하고 남긴 글입니다. 우리가 널리 사용하는 관계형 데이터베이스(RDB)는 스키마가 잘 짜여 있어 빠르고 안정적입니다. 하지만 현실 세계의 복잡한 네트워크를 표현하기 위해 수많은 테이블을 쪼개고 무거운 조인(Join) 연산을 걸어야 하는 한계가 있습니다.이번 글에서는 단순히 데이터를 저장하는 것을 넘어, 데이터 스스로 관계를 맺고 지식을 도출하는 기술인 온톨로지(Ontolo..

안녕하세요! 오늘은 데이터 관리와 AI 서비스 기획에서 아주 중요한, 하지만 종종 오해받곤 하는 '온톨로지(Ontology)'에 대해 이야기해보려 합니다. 본 내용은 패스트캐퍼스에 '온톨로지 기반 프로덕트 레벨 AI Agent 서비스 구축' 공부하고 남긴 글입니다. 많은 분이 "데이터베이스(DB)가 있는데 왜 굳이 온톨로지를 써야 하나요?"라고 묻습니다. 결론부터 말씀드리면, 데이터베이스는 '사실'을 저장하는 도구이고, 온톨로지는 그 사실의 '의미'를 정의하는 모델링 철학이기 때문입니다.1. DB가 대답하지 못하는 질문들우리가 흔히 쓰는 DB는 "무엇이 있는가(What)"를 찾는 데는 최고의 도구입니다. 하지만 사용자의 모호한 의도가 담긴 질문에는 당황하곤 하죠.사용자: "새벽에 쓰기 좋은 가벼운 노트북..

LLM 서비스는 겉보기에는 다 비슷해 보여도, 1년만 지나도 성능과 기능에서 큰 차이가 벌어집니다. 그래서 "1년 전에 통하던 최적 사용법"이 지금은 오히려 비효율적일 수 있습니다. 특히 Claude처럼 빠르게 발전하는 모델은, 모델을 만든 회사가 공개한 연구를 이해하면 프롬프트 작성 수준이 확연히 달라집니다.이 글에서는 Anthropic이 공개한 핵심 연구 세 가지를 바탕으로, 최신 Claude를 실제로 잘 쓰는 프롬프트·컨텍스트 설계법을 정리했습니다. 단순한 이론 소개가 아니라, 각 연구에서 곧바로 끌어낼 수 있는 실전 프롬프트 팁 위주로 담았습니다.왜 '모델을 만든 사람의 연구'를 봐야 할까프롬프트를 잘 쓰는 방법은 인터넷에 넘쳐납니다. 하지만 대부분은 "이렇게 하면 잘 되더라"는 경험칙이고, 모델..

공부기간 : 3월 29일~4월 4일 수강한 이유:  1) Flutter를 배워보고 싶어서2) Flutter와 LLM API를 연결한 서비스를 경험하고 싶어서 후기 : Lanchain을 재밌게 들은 강사의 강의였고, 언제 한번 Flutter를 가볍게 공부고 싶었기 때문에 수강하게 되었습니다. 결론부터 이야기하면 Flutter가 쉽지 않네요. Dart문법에 익숙하지 않아서 인지 모르지만, 생소한 느낌이 강했습니다. 강사가 치는 코드를 그냥 따라하긴 했는데... 왜 그렇게 해야 하는지 이해가 되지 않은 면도 있습니다. 섹션3까지는 따라하기가 어렵지 않는데, 섹션4는 따라하긴 하는데 결과물이 다르게 나와서 코드를 이해하지는 못한 채로 Cursor로 문제를 해결하긴 했습니다. 아래 영상은 섹션4에서 작업한 Flu..

공부기간 : 3월 27일~4월 2일 수강한 이유:  1) supabase를 활용해보고 싶어서2) Next.js를 활용한 간단한 프로젝트를 하고 싶어서3) 무료 강의라서 부담이 없어서 후기 : supabase에 대해서 공부를 하고 싶었는데 마침 인프런에 무료강의가 있다는 것을 발견하고 신청했습니다. supabase에 대한 전체적인 설명과 간단한 프로젝트를 수행하는 강의였습니다.  Nest.js와 Typescript, tailwind 등에 익숙하지 않아서 강사의 코드를 따라치는데 생각보다 시간이 꽤 걸렸습니다. 실습 강좌 부분은 1시간 정도 되는데, 막상 따라하면서 시행착오를 경험했는데 3~4시간 정도 시간이 소요되었습니다. 코드에 대한 상세한 설명을 하지 않기 때문에 이해도 잘 안되는 상태에서 그냥 따라치..

공부기간 : 3월 1일~3월 21일 수강한 이유:  1) CUSOR를 활용한 API 개발(Springboot)활용 2) data.go.kr에서 1)아파트실거래, 2)청약 api를 통해 데이터를 자체 DB에 저장하고 이를 활용하여 API 개발 3) 그누보드에 대해서 사용을 안해봤는데 이참에 사용해야 겠음  후기 : 인프런에서 하는 Cursor를 활용해서 강의를 찾던 중, API를 직접 개발하는 강의가 있어서 듣게 되었습니다. 이전부터 API를 개발해보고 싶었는데 마침 강좌가 출시되어 신청하게 되었습니다. 자바가 익숙하지 않아서 일단 한번 저자의 방식을 그대로 따라서 했는데... 생각보다 시간이 많이 걸렸습니다. 코드를 완벽히 숙지 않지 상태로 Cursor를 활용하여 이것저것 요청을 통해 문제를 해결하다보니..