인공지능으로 개발을 처음 시작할 때, 가장 목소리가 큰 사람들은 모두 한 곳, 즉 모델만을 가리킵니다. 적절한 모델을 선택하기만 하면 나머지는 저절로 해결될 것이라고 말이죠. 저 역시 몇 주간의 실험을 거치며 깨달은 점은, 그것이 결코 사실이 아니라는 것입니다. 사용 가능한 대규모 언어 모델(LLM) 사이에서 선택하는 것도 중요하지만, 그것은 전체 업무의 약 20%에 불과합니다. 나머지는 시스템 구축의 영역입니다. 그것은 배관 작업(plumbing)이자, 기술적 숙련도이며, 끊임없는 테스트입니다. 저는 이 사실을 초기에 깨달았고, 그 이후 모든 프로젝트에 접근하는 방식이 완전히 바뀌었습니다.
모델은 시작일 뿐입니다
초보자들이 왜 모델에 집착하는지 이해하기는 쉽습니다. 릴리스 노트는 더 나은 추론 능력, 더 넓은 컨텍스트 창(context window), 더 깔끔한 출력을 약속합니다. 이러한 개선은 실제로 이루어지고 있지만, 이는 범용적인 개선일 뿐입니다. 최첨단 모델이라 할지라도 귀사의 환불 정책을 자동으로 알 수는 없습니다. 어떻게 해야 하는지 알려주지 않는 한, 모바일 앱에 맞는 응답 형식을 안정적으로 만들어내지도 못합니다. 실시간 재고 데이터를 허공에서 뚝딱 가져올 수도 없습니다.
저는 이를 혹독한 경험을 통해 배웠습니다. 저의 첫 번째 프로토타입은 성능 좋은 모델을 사용했기에 유려하고 자신감 넘치는 문장을 만들어냈지만, 때로는 완전히 틀린 내용을 담고 있었습니다. 모델이 말투를 완벽히 익혔기에 텍스트는 전문적으로 들렸지만, 최신 정보에는 접근할 수 없었습니다. 저는 데이터 파이프라인과 컨텍스트 주입(context injection)에 대해 고민해야 했을 때, 모델 벤치마크를 비교하는 데 며칠을 허비하고 있었습니다. 모델이 고장 난 것이 아니었습니다. 모델을 둘러싼 시스템이 불완전했던 것입니다. 데모 단계를 넘어 사람들이 실제로 신뢰할 수 있는 소프트웨어를 만들 때는 이 차이가 모든 것을 결정합니다.
프롬프트는 제안이 아니라 코드입니다
고품질의 프롬프트는 신뢰할 수 있는 모든 AI 애플리케이션의 핵심입니다. 초기에는 프롬프트를 짧고, 격식 없으며, 낙관적인 검색어처럼 취급했습니다. 모델에게 "이것을 요약해줘" 또는 "도움이 되어줘"라고 요청하고는 결과가 좋기를 바랄 뿐이었습니다. 결과는 유용함과 무관함 사이를 극단적으로 오갔고, 저는 그 이유를 전혀 알지 못했습니다.
이제 저는 프롬프트를 가벼운 프로그램처럼 다룹니다. 좋은 프롬프트는 역할을 정의하고, 출력 형식을 지정하며, 필요한 경우 예시를 포함하고, 경계선을 설정합니다. JSON 형식이 필요하면 JSON을 요청하고 스키마를 보여줍니다. 간결한 답변이 필요하면 길이를 명시적으로 제한하고 서론(preamble)을 금지합니다. 반복 작업이 중요합니다. 저는 프롬프트와 그 출력값을 기록하는 로그를 유지하며, 한 번에 하나의 변수만 변경하며 테스트합니다. 프롬프트에 포함된 모호한 형용사 하나가 전체 워크플로우의 동작을 바꿀 수 있습니다. 이러한 민감함은 추측이 아닌 엄격함을 요구합니다.
Garbage In, Garbage Out
신뢰할 수 있는 데이터 검색(retrieval)은 많은 AI 프로젝트가 조용히 실패하는 지점입니다. 검색 증강 생성(Retrieval-Augmented Generation, RAG)은 모델이 비공개 데이터나 최신 데이터에 접근할 수 있도록 하는 표준 패턴이 되었습니다. 개념은 간단합니다. 관련 문서를 가져와 모델의 컨텍스트 창에 넣고, 모델이 사실을 바탕으로 추론하게 하는 것입니다. 하지만 실제 구현은 훨씬 더 복잡합니다.
저는 관련 없는 결과만 계속 반환하는 단순한 지식 베이스를 디버깅하며 많은 시간을 보냈습니다. 모델은 문제가 없었습니다. 검색 레이어(retrieval layer)가 실패하고 있었습니다. 제가 만든 청크(chunk)는 너무 작았고 문맥이 결여되어 있었습니다. 임베딩은 중복된 헤더를 정리하지 않은 채 생성되었습니다. 유사도 검색은 기술적으로는 가깝지만 질문과는 상관없는 텍스트를 찾아냈습니다. 이를 해결하려면 청킹(chunking) 전략을 재고하고, 메타데이터 필터를 추가하며, 리랭킹(re-ranking) 단계를 도입해야 했습니다. 검색이 안정화되자 모델의 답변은 즉시 개선되었습니다. 교훈은 명확했습니다. 잘못된 데이터 검색을 더 좋은 모델로 메울 수는 없습니다. 파이프라인을 올바르게 구축해야 합니다.
측정할 수 없는 것은 개선할 수 없습니다
지속적인 평가는 실험과 제품을 구분 짓는 습관입니다. 처음 시작할 때 저는 '느낌(vibe)'으로 평가했습니다. 출력물을 다섯 개 정도 읽어보고 고개를 끄덕이며 넘어갔습니다. 하지만 사용자가 여섯 번째 질문을 던졌을 때 이상한 답변을 받는 순간, 그 방식은 통하지 않게 됩니다.
이제 저는 모든 기능에 대해 작은 평가 세트(evaluation sets)를 구축합니다. 실제 사용자 쿼리를 수집하고, 기대되는 동작을 라벨링한 뒤, 이를 바탕으로 자동화된 체크를 실행합니다. 또한 드리프트(drift) 현상을 주시합니다. 지난달에 잘 작동하던 프롬프트가 모델 업데이트나 기반 데이터의 변경 이후 성능이 저하될 수 있기 때문입니다. 저는 스타일 평가와 사실적 정확성을 분리합니다. 전문적으로 보이는 것도 좋지만, 정확한 것은 필수입니다. 이러한 루프가 없다면 당신은 희망에 기대어 제품을 출시하는 것이며, 희망은 테스트 전략이 될 수 없습니다.
기계의 한계를 파악하십시오
Understanding model limits has saved me from overpromising and underdelivering. These systems have genuine constraints. Context windows are larger than they used to be, but they still have ceilings, and stuffing them full degrades performance at the edges. Models hallucinate, especially on niche topics where training data is thin. They struggle with precise arithmetic and certain types of multi-step logic. They are sensitive to phrasing.
Cost and speed are limits too. A model that generates perfect prose in ten seconds might be unusable in a real-time chat interface. I now map features to latency budgets early. If a task needs sub-second response, I may precompute answers, cache aggressively, or use a smaller model for the first draft and a larger one only for refinement. Working within constraints is standard engineering. AI is no different.
Building for Real People
I am currently studying LLM applications and software engineering with a simple goal: build tools people use every day. That sounds obvious, but the gap between a cool prototype and a daily-use tool is massive. A demo can tolerate a forty-second pause and a verbose answer. A person trying to finish a task before a meeting cannot.
Daily-use tools need error handling, fallbacks, and clear UI when the model is uncertain. They need to integrate with existing workflows rather than forcing new ones. I think about edge cases now: what happens when the model refuses to answer, when the context overflows, or when the API times out? Shipping AI software means answering those questions with code, not just optimism.
Let's Share What We Learn
I want to connect with other developers who are navigating the same path. The field moves quickly, and the best practices are still being written. No one has all the answers. Whether you are wrestling with prompt design, fighting retrieval pipelines, or figuring out how to evaluate outputs at scale, the problems are better solved together.
Let us share what we learn. Not polished conference talks, but the messy middle. The broken pipelines, the prompt tweaks that finally worked, the evaluation tests that caught a bug before launch. That granular, honest exchange is what turns individual experiments into a shared body of knowledge.
The Real Takeaway
If you are starting out with AI development, spend less time searching for the