생성형 AI를 ‘잘 쓰는 법’을 부르는 이름이 1~2년 사이 여러 번 바뀌었습니다. 한때 ‘프롬프트 엔지니어링’이 유일한 핵심 역량처럼 다뤄졌지만, 지금은 ‘컨텍스트 엔지니어링’, ‘하네스(harness) 엔지니어링’, ‘루프(loop) 엔지니어링’이 나란히 등장합니다. 한쪽에서는 부산교육청처럼 학생 대상 프롬프트 경진대회가 열리고, 다른 쪽 개발 매체에서는 “프롬프트는 이미 옛말”이라는 자극적인 진단이 나옵니다. 같은 시기에 정반대로 보이는 두 신호가 공존하는 셈인데, 이 글은 흩어진 용어를 하나의 ‘4층 지도’로 묶어 무엇이 어떻게 달라졌고 실무자는 어느 층에 손대야 하는지를 정리합니다.
먼저 오해부터 걷어내겠습니다. 프롬프트 엔지니어링은 사라지지 않았습니다. 달라진 것은 무게중심입니다. ‘질문 한 번을 잘 던지는 기술’에서 ‘AI가 여러 단계를 스스로 돌며 문제를 풀도록 환경과 반복 구조를 설계하는 일’로 관심이 이동하는 중입니다. 용어의 유행을 외우기보다 각 개념이 ‘어떤 문제를 풀려고 생겼는가’를 이해하면, 다음에 새 용어가 또 나와도 흔들리지 않고 판단할 수 있습니다.
프롬프트 엔지니어링은 왜 한계에 부딪혔나
프롬프트 엔지니어링은 ‘입력 문장을 어떻게 구성하면 원하는 답이 나오는가’를 다루는 기술입니다. 역할 부여(“너는 계약서를 검토하는 변호사다”), 예시 제공(few-shot, 보통 2~5개 예시를 붙이면 형식 준수율이 눈에 띄게 오릅니다), 단계적 사고 유도(chain-of-thought) 같은 기법이 대표적입니다. 같은 질문이라도 지시를 구체화하면 결과가 확 달라지고, 모델을 새로 학습시키는 것과 달리 비용이 사실상 0이라 ‘가장 저렴한 성능 향상 수단’으로 통했습니다. 교육 현장에서 경진대회 종목이 될 만큼 기본기로 자리 잡은 이유입니다.
한계는 ‘적용 범위’에서 드러납니다. 요약·번역 같은 단발성 작업은 문장 하나로 품질을 끌어올릴 수 있지만, 코드 리팩터링·리서치 보고서·다단계 데이터 처리처럼 5~10단계가 얽힌 작업은 완벽한 프롬프트 한 줄로 끝나지 않습니다. 가장 흔한 오해가 바로 ‘마법의 프롬프트 한 줄만 찾으면 된다’는 기대인데, 실제로는 작업이 복잡해질수록 프롬프트만의 개선 효과가 빠르게 정체됩니다. 게다가 모델이 애초에 모르는 사실(사내 문서, 어제 바뀐 API)은 지시를 아무리 다듬어도 채워지지 않습니다. 여기서 “어떻게 물을까”와 “무엇을 알려주고 어떤 순서로 시킬까”가 별개 문제라는 인식이 생겼고, 그 빈틈에서 다음 세 개념이 나왔습니다.
컨텍스트·하네스·루프, 네 층으로 갈라 읽기
세 용어는 경쟁이 아니라 관심의 초점이 다릅니다. 한 문장으로 요약하면 이렇습니다. 프롬프트 = 무엇을 물을까, 컨텍스트 = 무엇을 보여줄까, 하네스 = 어떤 도구와 검증 장치를 붙일까, 루프 = 몇 번 어떻게 반복시킬까. 컨텍스트 엔지니어링은 사내 문서·코드베이스·이전 대화 중 필요한 것만 골라 넣고 나머지는 걷어내, 제한된 입력창(컨텍스트 윈도)을 효율적으로 채우는 설계입니다. 검색으로 관련 문서를 붙이는 RAG가 대표 사례죠. 하네스 엔지니어링은 한 겹 바깥에서 AI가 파일을 읽고 도구를 호출하고 결과를 검증하는 ‘작업 환경 골격’을 짜는 일입니다. 루프 엔지니어링은 그 골격 위에서 실행→결과 확인→수정을 여러 차례 자동 반복시키며 목표에 수렴하도록 순환 구조를 설계하는 관점입니다.
헷갈릴 때는 ‘AI 코딩 도구가 테스트를 돌려 실패 로그를 다시 읽고 코드를 고치는 과정을 자동 반복하는’ 장면을 떠올리면 네 층이 한꺼번에 보입니다. 어떤 파일을 읽힐지 고르는 것은 컨텍스트, 테스트 실행·로그 회수 도구를 연결하는 것은 하네스, 몇 번까지 돌리고 언제 멈출지 정하는 것은 루프, 각 단계의 지시문은 프롬프트입니다. 여기서 가장 값비싼 함정은 ‘반복 횟수를 늘리면 무조건 좋아진다’는 착각입니다. 종료 조건과 검증 기준이 부실하면 AI는 같은 실수를 조금씩 바꿔가며 계속 맴돌고, 그동안 토큰은 선형이 아니라 누적 대화가 쌓이며 급격히 불어납니다. 실제로 자동 반복 에이전트에 ‘최대 시도 횟수’ 상한을 두는 이유가 이 폭주를 막기 위해서입니다.
실무 적용: 어느 층에 손댈지 두 축으로 판단하기
판단 기준을 두 축으로 좁히면 선택이 쉬워집니다. 하나는 ‘작업의 단계 수’, 다른 하나는 ‘성공 여부를 기계가 자동으로 판정할 수 있는가’입니다. 1) 단발성·주관적 작업(요약, 번역, 카피 초안)은 여전히 프롬프트 개선이 비용 대비 효과가 가장 큽니다. 자동 반복 구조를 짜는 건 과잉 설계입니다. 2) 최신·사내 지식이 필요한 작업(규정 Q&A, 제품 문서 응답)은 컨텍스트 설계(RAG)가 먼저입니다. 프롬프트를 다듬어도 모델이 모르는 사실은 못 채우기 때문입니다. 3) 결과를 기계적으로 검증할 수 있는 작업(코드 생성, 스키마 맞춘 데이터 추출)일수록 하네스·루프의 효과가 큽니다. ‘테스트 통과’, ‘JSON 스키마 일치’처럼 성공을 자동 판정할 신호가 있어야 반복이 의미를 갖습니다. 뒤집어 말하면, 이 신호가 없는 작업에 루프부터 얹는 것은 방향을 모르는 채 액셀을 밟는 셈입니다.
도입 전 체크포인트는 세 가지로 압축됩니다. (1) 이 작업의 성공을 사람 개입 없이 판정할 수단이 있는가 — 없으면 루프 대신 프롬프트·컨텍스트에 집중. (2) 종료 조건과 최대 반복 횟수를 정했는가 — 상한이 없으면 비용 폭증과 무한 루프의 문이 열립니다. (3) 중간 결과를 사람이 어디서 확인·중단할 수 있는가 — 자동 반복은 실패해도 ‘조용히’ 틀린 결과를 확정하는 위험이 있어, 리뷰 지점을 남겨야 합니다. 흔한 실패 패턴이 하나 더 있습니다. 검증 자동화도, 비용 모니터링도 없는 조직이 유행만 보고 복잡한 루프부터 들이는 경우인데, 성과는 안 나고 디버깅·운영 부담만 커집니다. 새 도구를 ‘왜 안 되지’로 붙잡는 대신, 애초에 그 조직에 자동 검증 기반이 있었는지를 먼저 봐야 하는 이유입니다.
과장과 실제를 가르는 질문 하나
“프롬프트 엔지니어링은 죽었다” 류의 선언은 주목을 끌기 위한 수사로 받아들이는 편이 안전합니다. 실제로는 기본기가 그대로 필요하고, 그 위에 설계 층이 얹혔을 뿐입니다. 교육 현장에서 프롬프트 대회가 계속 열리는 것과 개발 현장에서 루프·하네스가 화두인 것은 모순이 아니라 ‘다루는 층이 다르다’는 증거입니다. 입문자는 프롬프트로 감을 잡고, 이후 컨텍스트→도구(하네스)→반복(루프) 순으로 확장하는 경로가 자연스럽습니다. 처음부터 반복 구조에 손대면 얻는 것보다 디버깅 부담이 큽니다.
6개월~2년 관점에서 개별 용어의 수명은 짧아도 방향은 뚜렷합니다. ‘한 번 잘 묻기’에서 ‘AI가 스스로 일하도록 판을 짜기’로, 정적인 문장 설계에서 동적인 작업 환경 설계로 역량의 무게가 옮겨가고 있습니다. 다만 이 방향이 모든 조직에 지금 당장 필요한 것은 아닙니다. 검증 자동화, 토큰 비용 모니터링, 보안·책임 소재 정리 같은 기반이 없으면 자동 반복은 성과가 아니라 리스크로 돌아옵니다. 결국 유행보다 오래 통하는 판단 기준은 단순합니다. 새 용어가 나올 때마다 ‘이건 무슨 문제를 풀려는 개념이고, 우리 작업에 그 문제가 실제로 있는가’를 먼저 묻는 것 — 이 한 질문이 어떤 용어의 유행보다 수명이 깁니다.
자주 묻는 질문
프롬프트 엔지니어링은 이제 배울 필요가 없나요?
아닙니다. 요약·번역·분류처럼 한 번에 끝나는 작업은 여전히 프롬프트 품질이 결과를 좌우하고, 컨텍스트·하네스·루프도 결국 각 단계의 좋은 지시문 위에서 작동합니다. 프롬프트가 대체된 게 아니라 그 위에 설계 층이 추가됐다고 보는 편이 정확합니다. 입문자에게는 여전히 가장 먼저 익힐 기본기입니다.
루프 엔지니어링과 하네스 엔지니어링은 뭐가 다른가요?
하네스는 AI가 파일을 읽고 도구를 호출하고 결과를 검증하는 ‘작업 환경 골격’을 짜는 것이고, 루프는 그 골격 위에서 실행→확인→수정을 몇 번 반복하고 언제 멈출지 ‘순환 구조와 종료 조건’을 정하는 것입니다. 하네스가 무대라면 루프는 그 무대에서 몇 회 어떻게 돌릴지를 결정합니다.
우리 회사도 자동 반복(루프) 구조를 도입해야 할까요?
먼저 작업 성공을 사람 개입 없이 판정할 수단(테스트 통과, 스키마 일치 등)이 있는지 확인하세요. 이 신호와 비용 모니터링이 없으면 AI가 틀린 방향으로 반복하며 토큰만 소모합니다. 검증이 어려운 작업이라면 루프보다 프롬프트·컨텍스트 개선이 먼저이고, 도입하더라도 최대 반복 횟수 상한을 반드시 걸어야 합니다.
입문자는 어떤 순서로 익히는 게 좋나요?
프롬프트 기본기(역할 부여, 예시 2~5개 제공, 단계적 지시)로 감을 잡은 뒤, 필요한 정보를 붙이는 컨텍스트 설계(RAG), 도구 연결(하네스), 반복 구조(루프) 순으로 확장하세요. 각 층은 아래층 위에 쌓이므로 순서를 건너뛰면 문제가 어느 층에서 났는지 구분하기 어려워집니다.