스펙 주도 개발(SDD)은 폭포수와 무엇이 다를까?
코딩 에이전트에게 「로그인 화면에 비밀번호 재설정을 넣어 줘」라고 한 줄을 건넵니다. 몇 분 뒤 코드가 돌아옵니다. 그 안에는 아무도 묻지 않은 결정이 여럿 들어 있습니다. 재설정 링크를 메일로 보낼지 문자로 보낼지, 링크가 몇 분 뒤에 만료되는지, 없는 이메일을 넣었을 때 「없는 계정」이라고 알려 줄지 같은 것들입니다…
코딩 에이전트에게 「로그인 화면에 비밀번호 재설정을 넣어 줘」라고 한 줄을 건넵니다. 몇 분 뒤 코드가 돌아옵니다. 그 안에는 아무도 묻지 않은 결정이 여럿 들어 있습니다. 재설정 링크를 메일로 보낼지 문자로 보낼지, 링크가 몇 분 뒤에 만료되는지, 없는 이메일을 넣었을 때 「없는 계정」이라고 알려 줄지 같은 것들입니다…
맥락 창이 100만 토큰까지 커졌으니 이제는 관련 있어 보이는 것을 전부 넣으면 된다고 생각하기 쉽습니다. 문서 전체, 대화 전체, 도구 결과 전체를 넣으면 적어도 빠뜨린 것은 없을 테니까요.
「지난 분기 매출 상위 고객 10곳」을 물었더니 모델이 깔끔한 SQL을 돌려줍니다. JOIN도 맞고 GROUP BY도 맞고 실행도 됩니다. 그런데 그 숫자를 재무팀 보고서와 나란히 놓으면 맞지 않습니다. 환불이 빠지지 않았을 수도 있고, 부가세가 들어갔을 수도 있고, 회사의 회계 분기가 달력 분기와 다를 수도 있습니다.…
LLM 기능을 개발하면서 테스트는 몇 달째 로컬 모델로만 돌리고 있습니다. 대화, 툴을 부르는 에이전트, 문서에서 필드를 뽑는 구조화 추출, 이미지 인식, 요약까지 전부 자체 추론 서버 한 대에서 확인했습니다. 호출 비용이 0원이라 마음 놓고 몇백 번씩 돌릴 수 있다는 점이 가장 컸습니다. 그런데 기능이 늘수록 로컬 모…
같은 모델에 같은 질문을 두 번 보낸다고 해 보겠습니다. 한 번은 stream: false, 한 번은 stream: true 입니다. 스트리밍 쪽이 훨씬 빠르게 느껴집니다. 그런데 마지막 글자가 도착하는 시각은 두 쪽이 거의 같습니다. 모델은 어느 쪽이든 토큰을 하나씩 순서대로 만들고, 스트리밍은 그 순서를 바꾸지 않기…
데모는 십 분 만에 나오는데 제품이 되지 않는 일이 반복됩니다. 잘 되던 프롬프트가 입력이 조금 달라지면 무너지고, 고쳤더니 다른 경우가 깨지고, 무엇이 나아졌는지 말할 근거가 없습니다. 모델을 다루는 어려움보다는 정답이 하나가 아닌 시스템을 어떻게 판정하고 운영할지의 문제입니다.
로컬에서 AI 모델을 돌리다 보면 이런 상식이 생깁니다. 모델이 크면 똑똑하지만 느리다. 대체로 맞습니다.
온프레미스 추론 서버에 모델이 25개, 154GB 쌓여 있었습니다. 저는 필요할 때마다 하나씩 받았고, 어느 시점부터 무엇을 왜 갖고 있는지 설명할 수 없게 됐습니다.
사내 문서 RAG 챗봇처럼 비용을 아껴야 하는 환경에서는 작은 모델을 쓰게 됩니다. 그런데 작은 모델은 시스템 프롬프트의 금지 규칙을 자주 어깁니다. 이때 흔히 하는 대응이 프롬프트를 더 강하게 쓰는 것입니다. "절대 하지 마세요", "반드시" 같은 말을 덧붙이고, 예시를 추가하고, 규칙 번호를 매깁니다.
사내 문서를 근거로 답하는 RAG 챗봇을 도입하면 대부분 비슷한 지점에서 막힙니다. 첫 질문에는 그럴듯하게 답하는데, 이어서 "그럼 그건 언제 바뀐 거야?" 같은 질문을 던지면 갑자기 엉뚱한 문서를 근거로 들고 옵니다. 사용자는 "AI가 헛소리를 한다"고 느끼고, 도입은 거기서 멈춥니다.
RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
문서 검색과 질의응답을 결합한 RAG 시스템을 만들 때 가장 먼저 떠오르는 질문은 대개 비슷합니다.
AI를 잘 쓰는 핵심은 좋은 모델을 고르는 것만이 아닙니다. 모델에게 어떤 정보를 주고, 어떤 도구를 연결하고, 결과를 어떻게 검증할지까지 설계해야 실제 업무에 도움이 됩니다.