시즌 2-4편. 프롬프트 엔지니어링은 이제 옛말일까

2026. 7. 12. 00:38시즌 2 | AI 도구와 실험

 

먼저 짧은 실험 하나를 해보겠습니다. 아래 두 요청을 읽어보세요. 둘 다 같은 목적, 즉 '블로그 글 초안 받기'입니다.

요청 A:

"블로그 글 써줘. 주제는 skill.md. 친절한 톤으로."

요청 B:

"너는 비전공자 독자를 위한 기술 블로그 작가야. 톤 예시로 지난 6주차 글을 참고해. 이번 주제는 skill.md이고, 3회차 개념 소개형 뼈대를 따라. 반드시 실제 코드 예시와 아키텍처 다이어그램을 포함해. 다음 주 글은 GPT vs 나만의 GPT 비교니까 티저로 이어질 수 있게."

어느 쪽이 더 나은 결과를 만들어낼까요? 대부분 B라고 답하실 겁니다. 그런데 여기서 흥미로운 지점이 있습니다. 두 요청은 사실 다른 종류의 작업입니다. A는 프롬프트 엔지니어링에 가깝고, B는 요즘 자주 언급되는 컨텍스트 엔지니어링입니다.

오늘은 왜 이 흐름이 바뀌고 있는지, 그리고 이게 우리에게 어떤 의미인지 정리해보겠습니다.

🎯 한 문장으로 요약

  • 프롬프트 엔지니어링 = AI에게 말을 잘 걸어 원하는 답을 뽑아내는 기술
  • 컨텍스트 엔지니어링 = AI에게 필요한 배경, 자료, 규칙, 도구를 잘 세팅해 원하는 결과를 만들게 하는 기술

한쪽은 '어떻게 물을까'에 초점이 있고, 다른 쪽은 '무엇을 보여줄까, 어떤 환경을 만들까'에 초점이 있습니다.

🎬 어쩌다 이 얘기가 나온 걸까

2023년만 해도 개발자 커뮤니티에서 가장 뜨거운 단어는 '프롬프트 엔지니어링'이었습니다. '좋은 프롬프트를 쓰는 사람이 새로운 직업이 될 것이다'라는 얘기까지 나왔죠. 실제로 그때는 프롬프트를 어떻게 쓰느냐에 따라 결과 품질 차이가 정말 컸습니다.

그런데 2024년, 2025년을 지나면서 흐름이 조금 달라졌습니다. 모델 자체가 훨씬 똑똑해졌기 때문입니다. 이제는 '말을 잘 거는 것'만으로는 부족합니다. 사용자가 하는 일이 복잡해졌고, 요구되는 결과물도 정교해졌기 때문입니다.

그래서 사람들이 관심을 옮긴 곳이 '컨텍스트'입니다. AI가 답할 때 참고할 수 있는 배경 정보 전체를 어떻게 설계할지가 새 화두가 된 것이죠.

🍳 요리 비유로 이해해보기

두 개념을 요리 비유로 풀어보겠습니다.

프롬프트 엔지니어링 = 주문 잘 넣기

여러분이 셰프에게 요리를 주문한다고 상상해보세요.

  • 나쁜 주문: "뭐 맛있는 거 해줘"
  • 좋은 주문: "매콤한 파스타. 새우 넣고. 면은 알덴테로"

주문이 구체적일수록 결과가 좋아집니다. 이게 프롬프트 엔지니어링의 감각입니다.

컨텍스트 엔지니어링 = 주방 세팅하기

같은 상황인데, 여러분이 셰프에게 이런 걸 미리 준비해준다고 해봅시다.

  • 냉장고에 어떤 재료가 있는지 정리표
  • 여러분이 좋아하는 매운맛 강도 (1~10)
  • 지난주에 먹었던 요리 목록 (같은 걸 또 안 만들도록)
  • 알러지 정보
  • 가족 구성과 각자의 취향

셰프는 이 정보를 다 보고 요리를 시작합니다. 이때는 주문이 짧아도(예: "오늘 저녁 부탁해") 훨씬 정확한 결과가 나옵니다. 왜냐하면 필요한 배경이 이미 다 세팅되어 있으니까요.

이게 컨텍스트 엔지니어링의 감각입니다.

🧩 컨텍스트에는 뭐가 들어가나

AI에게 주는 '컨텍스트'라는 그릇에는 대략 이런 것들이 담깁니다.

  • 시스템 프롬프트: '너는 어떤 역할이다'라는 설정
  • skill.md 같은 매뉴얼: 이 상황에서 이렇게 일해라 (1편에서 다룬 그것)
  • 참고 문서: 첨부한 PDF, 노션 페이지, 코드 파일
  • 대화 이력: 지금까지 나눈 대화
  • 도구 목록: 이 AI가 쓸 수 있는 기능 (웹 검색, 파일 읽기 등)
  • 최신 사용자 요청: 이번에 하고 싶은 일

주목할 점은, 예전에는 이 중 마지막 항목(최신 요청)에만 집중했다면, 이제는 위쪽 요소들을 잘 설계하는 것이 훨씬 중요해졌다는 것입니다.

📊 두 접근법 비교

항목 프롬프트 엔지니어링 컨텍스트 엔지니어링

초점 요청 문장의 품질 배경 정보 전체 설계
비유 주문을 잘 넣기 주방 자체를 세팅하기
주된 스킬 문장 표현력, 예시 활용 자료 정리, 구조 설계
결과 편차 프롬프트에 따라 큼 컨텍스트 설계에 따라 큼
재사용성 낮음 (매번 씀) 높음 (한 번 세팅, 여러 번 활용)
적합한 상황 단발성 대화 반복 업무, 복잡한 작업

🔗 skill.md와의 관계

여기서 skill.md가 다시 등장합니다. 1편에서 다뤘던 것 기억하시나요?

skill.md는 컨텍스트 엔지니어링의 대표적인 결과물입니다. '이런 상황에서는 이렇게 일해라'는 매뉴얼을 한 번 잘 세팅해두면, 사용자는 매번 짧은 요청만 던져도 원하는 결과를 얻습니다. 프롬프트를 매번 잘 쓰려고 노력하는 대신, 환경을 한 번 잘 만들어두는 접근이죠.

즉 요즘 사람들이 skill.md를 만드는 것 자체가 컨텍스트 엔지니어링 실천의 한 형태입니다.

💭 그럼 프롬프트 엔지니어링은 끝난 걸까

솔직히 저는 처음 이 흐름을 봤을 때 '아, 이제 프롬프트 잘 쓰는 건 의미 없어지는 건가?'라고 생각했습니다. 근데 몇 주 써보니 그건 아니었습니다.

컨텍스트를 잘 세팅해두면 짧은 프롬프트로도 충분하지만, 그 짧은 프롬프트 자체는 여전히 잘 써야 합니다. 주방이 아무리 잘 세팅되어 있어도, "뭐 좀 해줘"만 반복하면 셰프도 헷갈리니까요.

정리하면 이런 관계입니다.

  • 프롬프트 엔지니어링: 여전히 필요한 기본기
  • 컨텍스트 엔지니어링: 그 위에 얹혀 훨씬 큰 레버리지를 만드는 기술

프롬프트가 사라진 게 아니라, 그 위에 더 큰 층이 하나 추가된 것에 가깝습니다.

🎯 Technical Writer와 DevRel 관점에서

이 대목이 저에게는 정말 흥미로웠습니다. 왜냐하면 컨텍스트 엔지니어링은 사실상 문서 설계와 매우 비슷한 작업이기 때문입니다.

  • 어떤 자료를 어떤 순서로 보여줄지 결정하기
  • 독자(AI)가 헷갈리지 않게 배경을 정리해두기
  • 반복적으로 참고될 규칙을 재사용 가능한 형태로 정리하기

이거 다 Technical Writer가 매일 하는 일 아닌가요? 시즌 1 6주차에서 다뤘던 것처럼, 좋은 문서는 독자의 인지 부하를 줄여줍니다. 컨텍스트 엔지니어링은 그 원칙을 AI라는 독자에게 적용하는 작업입니다.

앞으로 이 분야가 커질수록, 문서 설계 감각을 가진 사람의 자리도 함께 커질 것 같습니다. DevRel로의 전환을 준비하는 입장에서, 저는 이 흐름이 오히려 반갑습니다.

📌 정리

  • 프롬프트 엔지니어링 = 요청 문장을 잘 쓰는 기술 (주문 잘 넣기)
  • 컨텍스트 엔지니어링 = 배경 정보와 환경 전체를 잘 설계하는 기술 (주방 세팅)
  • 왜 흐름이 바뀌었나: 모델이 똑똑해지면서 '말을 잘 걸기'만으로는 부족. 배경 설계의 레버리지가 훨씬 커짐
  • skill.md와의 관계: skill.md는 컨텍스트 엔지니어링의 대표적 실천
  • 프롬프트는 끝났나: 아니다. 여전히 기본기. 그 위에 컨텍스트 층이 얹혔을 뿐
  • 문서 설계와의 연결: 컨텍스트 엔지니어링은 사실상 AI를 독자로 삼은 문서 설계

다음 글에서는 요즘 자주 언급되는 또 다른 개념, **MCP(Model Context Protocol)**가 뭔지 정리해보겠습니다. 이름만 봐도 알 수 있듯이 컨텍스트와 밀접한 관계가 있는 개념입니다.

읽어주셔서 감사합니다.


TAG: #컨텍스트엔지니어링 #프롬프트엔지니어링 #ContextEngineering #PromptEngineering #AI워크플로우 #DevRel준비 #DocsToDevRel #TechnicalWriter #비전공자