DevOps에서 프롬프트 엔지니어링 (Prompt Engineering)보다 컨텍스트 엔지니어링 (Context Engineering)이 더

지난 1년 동안 프롬프트 엔지니어링 (Prompt Engineering)에 관한 대화를 얼마나 많이 보았는지 셀 수도 없습니다. 매주 다른 프롬프트 구조, 새로운 프레임워크, 또는 신중하게 선택된 단어 세트가 어떻게 AI 생성 응답의 품질을 극적으로 향상시킬 수 있는지 설명하는 또 다른 기사가 나오는 것 같습니다. 이는 흥미로운 주제이며, 분명 어느 정도 사실입니다. 잘 작성된 프롬프트는 보통 모호한 프롬프트보다 더 나은 답변을 생성합니다. 하지만 실제 DevOps 워크플로우에서 AI를 사용하는 데 더 많은 시간을 보낸 후, 저는 우리가 잘못된 문제에 집중하고 있다는 믿음을 갖게 되었습니다.

제가 목격한 가장 큰 개선은 더 나은 질문을 던지는 것에서 오지 않았습니다. 그것은 항상 AI가 추론해야 하는 환경에 대해 더 나은 이해를 제공하는 것에서 왔습니다.
이러한 깨달음은 하룻밤 사이에 일어난 것이 아닙니다. 많은 엔지니어와 마찬가지로, 저도 처음에는 AI가 특별히 유용하지 않은 답변을 내놓는다면 아마 제 잘못일 것이라고 가정했습니다. 아마도 프롬프트가 충분히 상세하지 않았을 수도 있습니다. 아마도 예상되는 형식을 지정해야 했을 수도 있습니다. 아마도 작업을 다르게 설명해야 했을 수도 있습니다. 그래서 저는 실험했습니다. 프롬프트를 다시 작성하고, 제약 조건을 추가하고, 단어를 바꾸고, 다양한 접근 방식을 시도했습니다. 응답은 약간 더 다듬어졌지만, 눈에 띄게 더 유용해지지는 않았습니다.

전환점은 제가 프롬프트를 바꾸는 것을 멈추고 제가 제공하는 정보를 바꾸기 시작했을 때 찾아왔습니다.
단순히 AI에게 Terraform 변경 사항을 검토해 달라고 요청하는 대신, 인프라가 어떻게 구성되어 있는지 설명하기 시작했습니다. Kubernetes 로그를 요약해 달라고 요청하는 대신, 플랫폼 아키텍처, 배포 워크플로우, 그리고 애플리케이션을 둘러싼 운영 제약 조건을 설명했습니다. 우리의 CI/CD 파이프라인이 어떻게 작동하는지 AI가 추론하기를 기대하는 대신, 팀의 모든 신입 엔지니어가 온보딩 (Onboarding) 중에 통상적으로 받게 되는 컨텍스트 (Context)를 제공했습니다.

그리고 그 차이는 놀라웠으며, 제가 사물을 접근하는 방식을 영구적으로 바꾸어 놓았습니다. 프롬프트 (Prompts) 자체는 거의 지루할 정도가 되었습니다. 그것들은 특별히 영리하거나 정교하지 않았습니다. 많은 경우 단 한두 문장에 불과했습니다. 변화된 점은 AI가 마침내 그 질문이 애초에 왜 중요한지를 이해할 수 있을 만큼 충분한 배경 정보 (Background information)를 갖게 되었다는 것입니다. 돌이켜보면, 이는 놀라운 일이 아니어야 했습니다.

만약 내일 새로운 플랫폼 엔지니어 (Platform engineer)가 팀에 합류한다면, 저는 그들이 첫 한 시간 동안 질문에 얼마나 잘 답변하는지를 바탕으로 그들의 능력을 판단하지 않을 것입니다. 유용한 결정을 기대하기 전에, 저는 우리 환경 (Environments)이 어떻게 구성되어 있는지, 배포 (Deployments)가 파이프라인 (Pipeline)을 통해 어떻게 흐르는지, 어떤 서비스가 핵심적 (Critical)으로 간주되는지, 운영 경계 (Operational boundaries)가 어디에 존재하는지, 그리고 아마도 가장 중요하게는 왜 과거에 특정 엔지니어링 결정들이 내려졌는지에 대해 설명할 것입니다. 그 어떤 정보도 티켓 설명 (Ticket description) 안에 깔끔하게 들어맞지는 않겠지만, 그 정보는 앞으로 그 엔지니어가 내릴 모든 결정에 지대한 영향을 미칠 것입니다.

AI도 다르지 않습니다. 우리는 종종 수년에 걸쳐 진화해 온 인프라에 대해 추론하기를 기대하면서, 고작 몇 개의 설정 파일과 정교하게 작성된 프롬프트(Prompt)만을 제공하곤 합니다. 답변이 기대에 미치지 못할 때, 우리의 본능은 더 근본적인 질문을 던지는 대신 프롬프트를 계속해서 다듬는 쪽으로 향합니다. 즉, '모델이 실제로 추론하도록 요청받은 환경을 이해하고 있는가?'라는 질문 말입니다. DevOps에서 그 대답은 종종 '아니오'입니다.

인프라는 단순히 Terraform 모듈, Kubernetes 매니페스트(Manifests), 또는 CI/CD 파이프라인(Pipelines)만으로 정의되지 않습니다. 인프라는 이러한 요소들 사이의 관계에 의해 정의됩니다. 여기에는 수년 전에 내려진 아키텍처 결정, 이전 사고들로 인해 존재하게 된 운영 가드레일(Guardrails), 팀원 모두가 무의식적으로 따르는 명명 규칙(Naming conventions), 배포 일정에 영향을 미치는 비즈니스 우선순위, 그리고 숙련된 엔지니어들이 거의 본능적으로 간직하고 있는 수많은 작은 결정들이 포함됩니다. 이러한 정보의 대부분은 프롬프트에 나타나지 않지만, 우리가 내리는 거의 모든 엔지니어링 결정의 형태를 결정짓습니다.

이것이 제가 컨텍스트 엔지니어링 (Context Engineering)이라고 생각하는 것에 점점 더 관심을 갖게 된 이유입니다. 저에게 이것은 또 다른 AI 유행어를 만들어내는 것이 아닙니다. 유용한 답변을 기대하기 전에 주변 시스템을 이해할 수 있는 상태로 만드는 단순한 실천입니다. 좋은 문서화(Documentation)는 그 컨텍스트의 일부가 됩니다. 아키텍처 다이어그램(Architecture diagrams)도 그 컨텍스트의 일부가 됩니다. 저장소 컨벤션(Repository conventions), 배포 워크플로(Deployment workflows), 사고로부터 얻은 교훈, 인프라 경계, 그리고 이전의 기술적 결정 뒤에 숨겨진 이유들까지 모두 AI가 이해하려고 노력하는 환경의 일부가 됩니다.

아이러니하게도, 이것은 인간 엔지니어들에게도 이득이 되는 바로 그런 종류의 작업입니다. 모든 팀은 성숙한 플랫폼에 새로운 인원을 온보딩(Onboarding)하는 과정에서 어려움을 겪어본 적이 있습니다. 문제는 Terraform 구문을 가르치거나 Kubernetes가 어떻게 작동하는지 설명하는 것이 아닙니다. 숙련된 엔지니어들은 이미 그런 것들을 알고 있습니다. 진짜 어려운 부분은 문서의 행간에 존재하는 모든 지식을 전달하는 것입니다. 왜 운영(Production) 환경은 스테이징(Staging) 환경과 다르게 배포되는가? 왜 특정 서비스들은 서로 다른 릴리스 주기(Release window)를 따르는가? 왜 하나의 Terraform 모듈이 공유되는 대신 의도적으로 중복되어 사용되는가? 그러한 답변들은 대개 소스 코드보다는 대화, 설계 검토(Design review), 그리고 운영 경험 속에 존재합니다.

아마도 그렇기 때문에 컨텍스트 엔지니어링 (Context Engineering)은 프롬프트 엔지니어링 (Prompt Engineering)보다 인프라 엔지니어링 (Infrastructure Engineering)과 훨씬 더 일치하는 느낌을 줍니다. 인프라는 항상 개별 리소스보다는 시스템을 이해하는 것에 관한 것이었습니다. AI는 단지 다른 각도에서 동일한 진실을 드러낼 뿐입니다. 시스템이 더 잘 문서화되고 이해될수록, 인간과 기계 모두 그 안에서 더 잘 작동할 수 있습니다.

프롬프트 엔지니어링이 계속해서 진화할 것이며, AI 도구로부터 최선의 결과를 얻기 위한 중요한 기술로 남을 것임은 분명합니다. 하지만 적어도 DevOps 분야에서 그 중요성이 종종 과장되어 있다고 생각합니다. 일단 모델이 환경을 진정으로 이해하게 되면, 프롬프트 자체는 놀라울 정도로 평범해집니다. 그것들은 정교하게 설계된 지침이라기보다, 한 엔지니어가 다른 엔지니어에게 자연스럽게 던지는 질문처럼 보이기 시작합니다.

그리고 아마도 그것이 제가 인프라 엔지니어링에서 AI를 사용하며 얻은 가장 큰 교훈일 것입니다. 답변의 품질은 우리가 질문을 얼마나 우아하게 하느냐에 달려 있기보다, 시스템이 우리의 문제를 해결해주기를 기대하기 전에 우리의 세계를 이해할 수 있도록 충분한 컨텍스트 (Context)를 제공했느냐에 훨씬 더 크게 좌우됩니다.

참고: 이 글은 구조화 및 초안 작성을 위해 AI 도구의 도움을 받아 작성되었습니다. 아이디어, 예시 및 관점은 DevOps 및 클라우드 엔지니어링 (Cloud Engineering) 분야의 실제 경험을 바탕으로 합니다.

Medium에 최초 게시됨: https://medium.com/@yogesh.vk/why-better-prompts-wont-fix-ai-in-devops-235c0abe1814