기업의 가장 큰 자산은
학습하는 루프다

좋은 프롬프트는 한 번에 만들어질까.

경험이 많은 사람은 어떤 지시가 더 좋은 결과를 만드는지 어느 정도 안다. 목적을 명확히 하고, 필요한 맥락과 예시를 제공하고, 결과의 형식을 정한다. 몇 번의 시행착오를 거치면 꽤 쓸 만한 프롬프트를 만들 수 있다.

그러나 LLM은 같은 지시에도 매번 조금씩 다른 결과를 낸다. 어떤 표현은 한 문제에서 잘 작동하지만 다른 문제에서는 약해진다. 지시의 순서와 예시, 모델과 도구, 입력 자료의 작은 차이가 예상하지 못한 결과를 만든다.

이 비결정적인 성질은 기업이 AI를 신뢰하기 어렵게 만드는 약점으로 보인다.

동시에 전혀 다른 가능성을 만든다.

코드는 같은 과정을 지치지 않고 반복할 수 있다. 프롬프트를 조금씩 바꾸고, LLM에게 여러 결과를 만들게 하고, 기준에 따라 평가한 뒤, 더 나은 후보를 다시 변형할 수 있다. 사람이 직관으로 몇 번 고쳐보던 일을 수백 번, 수천 번 탐색할 수 있다.

결정적인 코드는 비결정적인 LLM을 반복시킨다. LLM은 다시 새로운 코드와 프롬프트를 만든다. 인간의 경험은 무엇이 좋은지를 판단한다. 이 세 가지가 연결될 때 기업은 스스로 개선되는 업무 시스템을 갖게 된다.

프롬프트를 작성하는 대신 채굴한다

보통 프롬프트는 사람이 작성한다.

업무를 잘 아는 사람이 모델에게 필요한 역할과 절차, 주의사항을 설명한다. 결과를 보고 문장을 고친다. 잘 작동하면 템플릿으로 저장한다.

루프를 이용하면 접근이 달라진다.

먼저 하나의 프롬프트와 평가할 업무 사례들을 준비한다. 코드는 프롬프트의 표현과 순서, 예시와 판단 절차를 여러 방식으로 변형한다. LLM은 각 후보로 결과를 만든다. 다른 LLM이나 규칙, 사람이 그 결과를 평가한다. 더 좋은 후보는 남고, 약한 후보는 버려진다. 살아남은 프롬프트를 다시 변형해 다음 라운드를 돌린다.

프롬프트 후보 생성 → 실제 업무 사례에 실행 → 결과 평가 → 좋은 후보 선택 → 실패 원인 분석 → 프롬프트·도구·절차 수정 → 다시 실행

이 과정은 하나의 정답 프롬프트를 논리적으로 설계하는 일보다 광산에서 유용한 조합을 찾는 일에 가깝다.

어떤 문장이 왜 잘 작동하는지 완전히 설명할 수 없어도 반복된 평가에서 안정적으로 좋은 결과를 만드는 조합을 발견할 수 있다. 사람의 직관으로 떠올리기 어려운 지시 순서나 예시의 조합도 탐색할 수 있다.

프롬프트를 쓰는 것이 아니라 가능성의 공간에서 채굴하는 것이다.

LLM의 비결정성은 탐색의 자원이 된다

일반 소프트웨어에서 같은 입력이 다른 결과를 만드는 것은 버그에 가깝다. 회계 계산과 권한 검사는 언제나 같은 규칙을 따라야 한다.

LLM은 다르다. 하나의 질문에 여러 해석과 표현, 접근 방법을 제안할 수 있다. 이 성질 때문에 결과를 예측하기 어렵지만, 정답이 하나가 아닌 문제에서는 폭넓은 탐색이 가능해진다.

• 새로운 마케팅 관점 찾기
• 복잡한 코드의 서로 다른 구현 방식 비교
• 고객 요청에 대한 다양한 대응안 생성
• 문서 구조와 설명 순서 실험
• 알려진 실패를 피하는 새로운 절차 제안
• 전문가가 미처 언어화하지 못한 판단 후보 발견

코드는 이 다양성을 통제된 방식으로 반복해서 꺼낼 수 있다.

LLM에게 무작정 여러 답을 요청하는 것과는 다르다. 탐색할 범위와 평가 기준, 중단 조건을 코드가 관리한다. 비결정성을 제거하려 하기보다 필요한 곳에서 충분히 발생시키고, 그중 좋은 결과를 걸러낸다.

코드는 LLM을 반복시키고, LLM은 다시 코드를 만든다

이 루프는 프롬프트 문장만 최적화하지 않는다.

LLM은 새로운 평가 코드와 데이터 변환기, 테스트와 도구 연결을 만들 수 있다. 반복 과정에서 발견된 실패를 줄이기 위해 규칙 기반 검사를 추가하거나, 더 나은 입력을 만드는 전처리 코드를 작성할 수도 있다.

예를 들어 문서 작성 Agent가 확인되지 않은 수치를 자주 사용한다면 여러 개선 방향을 시험할 수 있다.

• 프롬프트에 출처 확인 절차를 강화한다
• 숫자가 포함된 문장을 코드로 추출해 검사한다
• 허용된 출처만 검색하는 도구를 연결한다
• 별도의 검증 Agent가 모든 주장을 평가하게 한다
• 근거가 없는 문장은 자동으로 표시하거나 제거한다

어떤 문제는 자연어 지시로 해결되고, 어떤 문제는 코드로 강제하는 편이 낫다. 또 어떤 문제는 둘을 함께 사용해야 한다.

LLM은 유연하게 해석하고 생성한다. 코드는 반드시 지켜야 할 조건을 안정적으로 반복한다. 서로 다른 장점이 루프 안에서 역할을 나눈다.

LLM이 모든 것을 판단하게 할 필요도 없고, 모든 예외를 코드로 미리 작성할 필요도 없다.

정확한 계산과 형식, 권한과 금지 조건은 코드에 둔다. 해석과 탐색, 초안과 예외 후보는 LLM에 맡긴다. 반복 결과를 보며 두 경계를 계속 조정한다.

인간의 경험이 없으면 루프는 엉뚱한 것을 최적화한다

루프가 많은 결과를 비교할 수 있어도 무엇이 실제로 좋은지는 저절로 결정되지 않는다.

평가 지표가 단순하면 시스템은 그 지표만 잘 만족하는 방향으로 변한다.

고객 답변을 짧고 빠르게 만드는 점수만 높이면 중요한 맥락을 생략할 수 있다. 제안서의 설득력만 평가하면 확인되지 않은 주장을 과감하게 사용할 수 있다. 코드 테스트 통과율만 보면 유지하기 어렵거나 위험한 구현이 선택될 수 있다.

이때 필요한 것이 경험 많은 인간의 판단이다.

전문가는 결과에서 미세한 신호를 본다.

• 고객이 불신할 표현은 무엇인가
• 어떤 수치는 맞아 보여도 다시 확인해야 하는가
• 정상적인 결과지만 이번 상황에는 적합하지 않은 이유는 무엇인가
• 어느 예외는 자동화하지 말아야 하는가
• 당장의 점수는 낮아도 장기적으로 더 안전한 선택은 무엇인가

이 판단을 평가 사례와 규칙, 피드백으로 루프에 넣어야 한다.

인간 전문성은 마지막 결과를 승인하는 데만 쓰이지 않는다. 무엇을 탐색하고 어떻게 평가할지를 설계하는 데 쓰인다. 루프가 실패할 때 잘못된 프롬프트를 고치는 것이 아니라 잘못된 목표와 지표를 찾아낸다.

완벽한 궁합을 발견할 수 있다

LLM의 성능은 모델 하나로만 결정되지 않는다.

같은 모델도 어떤 시스템 프롬프트와 예시, 도구, 입력 구조, 코드 검증과 함께 사용되는지에 따라 결과가 크게 달라진다. 업무마다 잘 맞는 조합도 다르다.

• 특정 모델은 긴 문서의 구조를 잡는 데 강하다
• 다른 모델은 짧은 검증과 분류에서 더 빠르고 저렴하다
• 어떤 프롬프트는 검색 도구와 함께 사용할 때만 안정적이다
• 어떤 업무는 초안과 검토를 서로 다른 Agent에게 맡길 때 좋아진다
• 어떤 판단은 LLM보다 간단한 규칙이 훨씬 정확하다

반복 루프는 이 조합을 실제 업무 사례에서 시험한다.

모델, 프롬프트, 데이터, 도구, 코드, 평가 방식 사이의 완벽한 궁합을 찾는다. 범용적으로 가장 좋은 시스템이 아니라 우리 회사의 특정 업무에서 가장 잘 작동하는 구성을 발견한다.

이 궁합은 제품 문서만 읽어서는 알기 어렵다. 실제 입력과 실패 사례, 전문가의 평가가 쌓여야 보인다.

그러나 채굴에는 비용이 든다

루프를 많이 돌린다고 반드시 좋은 시스템이 되는 것은 아니다.

수백 개의 프롬프트 후보를 여러 업무 사례에 실행하고, 다시 평가 모델을 호출하면 토큰과 서버 비용이 빠르게 늘어난다. 결과를 저장하고 비교하는 인프라도 필요하다. 사람이 평가해야 한다면 전문가의 시간은 더 비싸다.

무엇보다 탐색 공간은 거의 무한하다.

프롬프트의 단어와 순서, 예시, 모델, 온도, 도구, 작업 순서까지 모두 바꾸기 시작하면 조합은 폭발적으로 늘어난다. 개선 폭이 작은데도 더 나은 후보를 찾기 위해 막대한 비용을 쓸 수 있다.

비효율을 줄이려면 루프에도 운영 원칙이 필요하다.

• 가치와 반복 빈도가 높은 업무부터 선택한다
• 현재 실패가 무엇인지 먼저 명확히 한다
• 한 번에 바꾸는 요소를 제한한다
• 값싼 규칙과 작은 모델로 먼저 후보를 거른다
• 대표적인 실제 사례와 어려운 예외를 함께 평가한다
• 개선 폭이 비용보다 작아지면 멈춘다
• 사람의 평가가 꼭 필요한 지점만 남긴다

모든 프롬프트를 자동 최적화할 필요는 없다. 일회성 업무나 결과를 쉽게 검토할 수 있는 작업은 사람이 몇 번 다듬는 편이 더 싸고 빠르다.

평가 데이터에 과적합될 수 있다

루프의 더 위험한 문제는 비용보다 착각이다.

같은 평가 사례를 반복해서 사용하면 프롬프트가 그 사례에만 잘 맞게 변할 수 있다. 점수는 계속 오르지만 새로운 고객과 문서, 예상하지 못한 상황에서는 오히려 약해진다.

평가를 다른 LLM에게 맡겼다면 그 모델이 좋아하는 표현만 학습할 수도 있다. 실제 고객에게 유용한 답보다 평가 Agent가 높은 점수를 주는 답을 만들게 된다.

이를 막으려면 소프트웨어와 비슷한 검증 원칙이 필요하다.

• 개선에 사용하는 사례와 최종 검증 사례를 분리한다
• 정상 사례뿐 아니라 경계와 실패 사례를 넣는다
• 자동 평가와 인간 평가를 함께 사용한다
• 점수 하나가 아니라 정확성, 안전성, 비용과 만족도를 함께 본다
• 새로운 실제 업무에서 일정 기간 관찰한다
• 좋아진 평균 뒤에 치명적인 실패가 숨지 않았는지 확인한다

채굴된 프롬프트가 평가표에서 이겼다는 사실만으로 실제 업무에 바로 배포해서는 안 된다.

루프는 결과가 아니라 학습 과정을 축적한다

좋은 프롬프트 하나를 찾는 것이 끝이라면 경쟁사가 비슷한 프롬프트를 복사할 수 있다.

기업에 더 중요한 자산은 어떤 과정을 통해 그 조합을 발견했는가이다.

• 실제 업무의 대표 사례와 어려운 예외
• 전문가가 좋은 결과를 구분하는 기준
• 실패했던 프롬프트와 원인
• 모델과 도구별 강점과 약점
• 코드로 강제해야 할 규칙
• 사람에게 남겨야 할 판단
• 비용과 품질 사이의 최적 지점
• 배포 후 새롭게 발견된 오류

이 기록이 있으면 모델이 바뀌어도 다시 평가할 수 있다. 새로운 도구가 등장하면 기존 업무에서 가치가 있는지 빠르게 검증한다. 한 Agent에서 발견한 규칙을 다른 업무에도 적용할 수 있다.

프롬프트가 자산인 것이 아니다.

프롬프트를 만들고 시험하고 실패에서 배우는 학습 루프가 자산이다.

가장 큰 기회는 세 가지 지능의 결합에 있다

코드는 정확하고 반복적이다. 정해진 규칙을 지치지 않고 수행하며 같은 조건을 안정적으로 검사한다.

LLM은 유연하고 생성적이다. 비정형 자료를 해석하고, 여러 가능성을 제시하며, 코드와 문장을 새로 만든다.

경험 많은 인간은 무엇이 중요한지 안다. 숫자로 쉽게 표현되지 않는 품질을 알아보고, 예외와 위험을 판단하며, 결과에 책임진다.

셋 중 하나만으로는 부족하다.

코드만으로는 모든 예외와 의미를 미리 규정하기 어렵다. LLM만으로는 결과가 흔들리고 잘못된 목표를 자신 있게 수행할 수 있다. 인간만으로는 가능한 조합을 충분히 빠르고 넓게 시험하기 어렵다.

코드의 반복성 × LLM의 비결정성과 생성 능력 × 인간 전문가의 판단 = 스스로 개선되는 기업의 업무 시스템

이 조합이 작동하면 회사는 AI를 사용하는 데서 멈추지 않는다. 자신의 업무에 가장 잘 맞는 모델과 프롬프트, 도구와 규칙을 계속 발견하고 개선한다.

기업의 최대 자산은 학습하는 방식이다

모델은 바뀐다. 오늘 가장 좋은 프롬프트는 다음 모델에서 필요 없어질 수 있다. 도구와 비용, 고객의 기대와 회사의 정책도 계속 달라진다.

고정된 정답을 자산으로 보면 변화할 때마다 다시 시작해야 한다.

반대로 학습 루프를 자산으로 만들면 변화 자체를 흡수할 수 있다.

새로운 모델을 기존 사례에 실행하고, 과거 실패를 다시 검사하고, 전문가의 평가를 받아 더 좋은 조합을 찾는다. 실제 업무에서 발생한 새로운 오류는 다음 평가 사례가 된다. 사람의 피드백은 프롬프트와 코드, skill과 정책을 바꾼다.

이 과정이 반복될수록 회사는 단순히 데이터를 많이 가진 조직과 달라진다.

무엇이 좋은 결과인지 알고, 그것을 찾기 위해 체계적으로 실험하며, 실패를 다음 실행의 개선으로 연결하는 조직이 된다.

AI 시대의 가장 큰 기업 자산은 완성된 프롬프트도, 특정 모델도 아니다.

사람의 경험과 LLM의 가능성, 코드의 반복성을 결합해 계속 더 나은 일하는 방법을 발견하는 루프다.