프롬프트에서 컨텍스트, 그리고 루프 엔지니어링으로

실천이 먼저, 이름이 나중

기술 분야에서 새로운 실천법은 대개 이름이 붙기 전에 먼저 퍼진다. 프롬프트를 조심스럽게 다듬던 엔지니어들은 자신이 “프롬프트 엔지니어링”을 하고 있다는 사실을 나중에야 알았다. 컨텍스트 창을 정교하게 관리하던 팀들도 마찬가지였다. 그리고 지금 우리는 세 번째 이름이 자리를 잡아 가는 시점에 서 있다. 루프 엔지니어링(Loop Engineering).

이 세 계층은 순차적으로 등장했지만 서로를 대체하지 않는다. 더 높은 계층은 더 낮은 계층을 내부에 포함하고, 더 넓은 문제를 다룬다.

계층 1: 프롬프트 엔지니어링 (2022–2024)

초기 LLM 활용법의 핵심은 입력 텍스트를 정교하게 구성하는 것이었다. 역할 부여(“너는 전문 번역가야”), 퓨샷(few-shot) 예제 삽입, 사고 연쇄(chain-of-thought) 유도 같은 기법이 표준 레퍼토리가 됐다. 이 시기의 엔지니어링은 단일 프롬프트라는 좁은 공간 안에서 이루어졌다.

프롬프트 엔지니어링의 한계는 모델이 더 강력해질수록 역설적으로 드러났다. 모델이 더 많은 컨텍스트를 처리할 수 있게 되고, 외부 도구와 연결되기 시작하면서, “입력 텍스트 한 줄을 어떻게 쓰느냐”보다 “무엇을 컨텍스트에 넣고 무엇을 빼느냐”가 더 중요해졌다.

계층 2: 컨텍스트 엔지니어링 (2025)

Shopify CEO Tobi Lütke와 Andrej Karpathy가 이 실천법에 이름을 붙이기 시작했다. Simon Willison은 2025년 6월 컨텍스트 엔지니어링을 이렇게 정의했다. “모델이 작업을 수행하는 데 필요한 컨텍스트를 올바르게 구성하는 기술.” 이는 단순한 프롬프트 작성을 넘어, 어떤 정보를 어떤 순서로 어느 위치에 배치하느냐의 문제다.

컨텍스트 엔지니어링의 관심사는 컨텍스트 창이라는 자원을 어떻게 최적 배분하느냐다. 너무 많은 정보를 넣으면 모델이 중요한 부분을 놓친다. 너무 적으면 필요한 근거가 없어 환각(hallucination)이 늘어난다. 어떤 도구 결과를 압축하고, 어떤 메모리를 주입하고, 어떤 히스토리를 버릴지 결정하는 일이 핵심 역량이 됐다.

계층 3: 루프 엔지니어링 (2025–)

Addy Osmani는 2025년 루프 엔지니어링을 별도 계층으로 명명했다. 컨텍스트 창 하나를 잘 채우는 것이 아니라, 반복되는 모델 호출 사이클 전체를 설계하는 것이 이제 핵심 과제라는 인식에서 나온 용어다.

Boris Cherny(Claude Code 책임자)의 말은 이 전환을 선명하게 드러낸다. “나는 더 이상 Claude에 프롬프트하지 않는다. 루프를 돌리며 무엇을 할지 알아내게 한다. 내 일은 루프를 작성하는 것이다.” (출처: Addy Osmani, Loop Engineering)

루프 엔지니어링이 다루는 질문들은 단일 프롬프트나 단일 컨텍스트 창을 넘어선다. 루프를 언제 멈출 것인가? 이터레이션 사이에 무엇을 기억하고 무엇을 버릴 것인가? 실패가 다음 이터레이션으로 전파되지 않게 어떻게 막을 것인가? 비용과 지연 시간을 어떻게 제어할 것인가?

세 계층의 포함 관계

┌────────────────────────────────────────────────────────┐
│              루프 엔지니어링 (Loop Engineering)          │
│  반복 사이클 설계 · 종료 조건 · 메모리 관리 · 비용 제어   │
│                                                        │
│  ┌──────────────────────────────────────────────────┐  │
│  │         컨텍스트 엔지니어링 (Context Eng.)         │  │
│  │  컨텍스트 창 구성 · 정보 우선순위 · 압축 전략       │  │
│  │                                                  │  │
│  │  ┌────────────────────────────────────────────┐  │  │
│  │  │      프롬프트 엔지니어링 (Prompt Eng.)        │  │  │
│  │  │  역할 부여 · 퓨샷 · 사고 연쇄 · 출력 형식     │  │  │
│  │  └────────────────────────────────────────────┘  │  │
│  └──────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────┘

상위 계층이 하위 계층을 흡수한다는 점이 중요하다. 루프 엔지니어가 컨텍스트를 어떻게 구성할지 결정하고, 각 루프 이터레이션 안에서 어떤 프롬프트를 쓸지도 결정한다. 세 계층은 상호 배타적이 아니라 누적적(cumulative) 이다.

개발자 역할의 변화

이 계보가 가리키는 방향은 명확하다. 개발자의 역할이 모델에게 지시하는 사람에서 모델이 작동하는 시스템을 설계하는 사람으로 이동하고 있다. Andrej Karpathy가 주창하는 Software 3.0 관점에서 LLM은 새로운 컴퓨팅 기판이고, 루프는 그 기판 위에서 작동하는 프로그램이다.

개념 이해용 의사 코드이며 실제 API와 다를 수 있습니다.

# 프롬프트 엔지니어링: 입력 텍스트를 정밀하게 작성
prompt = """당신은 숙련된 코드 리뷰어입니다.
다음 Python 코드의 버그를 찾아 수정 방법을 제안하세요.

코드:
{code}

요구사항:
1. 버그를 명확히 지목하세요
2. 수정 코드를 제시하세요
"""

# 컨텍스트 엔지니어링: 컨텍스트 창 구성을 설계
context = build_context(
    system=system_prompt,       # 안정적 접두사 (캐시 대상)
    recent_files=load_files(),  # 최근 관련 파일만 선별
    error_log=last_errors(),    # 최신 에러 로그
    # 오래된 히스토리는 제외
)

# 루프 엔지니어링: 반복 사이클과 종료 조건을 설계
def engineering_loop(task: str) -> str:
    state = initialize_state(task)
    for iteration in range(MAX_ITERATIONS):
        context = build_context(state)        # 컨텍스트 엔지니어링
        response = model.generate(context)    # 프롬프트 엔지니어링 적용
        state = update_state(state, response) # 상태 관리
        if is_complete(state):
            break
    return state.result

루프 엔지니어는 세 수준 모두에서 결정을 내린다. 이 사이트의 나머지 챕터들은 그 결정들을 체계적으로 다룬다.

앞으로의 여정

다음 챕터에서는 루프라는 아이디어가 역사적으로 어떻게 발전해 왔는지 연표로 살펴본다. ReAct 논문에서 시작해 AutoGPT의 실패, Anthropic Building Effective Agents 가이드, 그리고 Ralph 기법에 이르기까지 에이전틱 루프의 짧지만 밀도 높은 역사를 추적한다.