AI 도구에서 최대한의 성과를 얻기 위한 경쟁 속에서, 프롬프트 엔지니어링(Prompt Engineering)—AI 도구의 출력을 안내하는 명확하고 구조화된 입력을 작성하는 실천—이 중심 무대에 올랐습니다. 그러나 소프트웨어 엔지니어들에게 이 기술은 새로운 것이 아닙니다. 우리는 수십 년 동안 다른 이름으로 이와 유사한 작업을 해왔습니다. AI 프롬프트를 작성할 때 직면하는 도전은 소프트웨어 팀이 세대를 거쳐 씨름해온 것과 동일합니다. 오늘날 프롬프트 엔지니어링에 대해 이야기하는 것은 개발자가 무엇을 구축해야 하는지, 어떤 조건에서, 어떤 가정 하에, 그리고 팀에게 어떻게 전달할지를 명확히 하는 오래된 대화를 계속하는 것입니다.

소프트웨어 위기는 1960년대 후반부터 이 문제에 붙여진 이름으로, 특히 1968년 NATO 소프트웨어 엔지니어링 회의에서 "소프트웨어 엔지니어링"이라는 용어가 도입되었습니다. 이 위기는 소프트웨어 프로젝트가 예산을 초과하고 지연되며, 종종 사용자가 실제로 필요로 하는 것을 제공하지 못하는 산업 전반의 경험을 나타냅니다.

이러한 실패가 프로그래머의 기술 부족이나 더 많은 기술 훈련이 필요한 팀 때문이라는 오해가 있었습니다. 그러나 그 회의의 패널들은 진정한 근본 원인으로 팀과 이해관계자들이 해결하려는 문제와 실제로 구축해야 하는 것을 이해하는 데 어려움을 겪고, 그 필요와 아이디어를 명확히 소통하며, 전달된 시스템이 그 의도와 일치하는지 확인하는 데 어려움을 겪고 있다고 보았습니다. 이는 근본적으로 인간의 커뮤니케이션 문제였습니다.

회의 참가자들은 이를 정확히 포착했습니다. Bell Labs의 Dr. Edward E. David Jr.는 소프트웨어가 무엇을 해야 하는지 논리적으로 명확하게 명시할 방법이 종종 없다고 언급했습니다. MIT의 Douglas Ross는 문제를 해결했다고 가정하며 무엇을 할 것인지 명시하고 그것을 수행하는 함정에 대해 지적했습니다. Prof. W.L. van der Poel은 불완전한 명세의 문제를 요약하며 대부분의 문제는 시작할 때 충분히 정의되지 않아서 올바른 솔루션을 구축하는 데 필요한 정보를 얻지 못한다고 말했습니다.

이러한 문제들은 코드가 작성되기 전에 팀이 자신들이 만드는 소프트웨어를 오해하게 만드는 원인입니다. 그리고 AI를 사용하여 코드를 생성하는 오늘날의 개발자들에게도 익숙하게 들릴 것입니다.

문제의 많은 부분은 제가 종종 "내가 말한 것이 아니라 내가 의도한 것을 하라"는 고전적인 문제라고 부르는 것으로 귀결됩니다. 기계는 문자 그대로 받아들이며, 팀의 사람들도 종종 그렇습니다. 우리의 의도는 거의 완전히 명시되지 않으며, 소프트웨어가 무엇을 해야 하는지에 대해 모두가 일치하는 데는 의도적이고 종종 어려운 작업이 필요합니다.

Fred Brooks는 그의 고전적이고 널리 영향력 있는 "No Silver Bullet" 에세이에서 이에 대해 썼습니다. 그는 소프트웨어 개발을 쉽게 만드는 마법의 프로세스나 도구는 결코 없을 것이라고 주장했습니다. 소프트웨어 엔지니어링의 역사 내내, 팀들은 이해와 커뮤니케이션의 어려운 부분을 없애줄 은탄환을 찾으려는 유혹을 받았습니다. 소프트웨어 팀들이 AI 도구를 사용하기 시작했을 때, 그들이 수년간 괴롭혔던 동일한 문제가 다시 나타나는 것을 보는 것은 놀라운 일이 아닙니다.

1970년대 말까지 이러한 문제들은 품질의 관점에서 재구성되고 있었습니다. 품질 엔지니어링 분야에 큰 영향을 미친 Philip Crosby, Joseph M. Juran, W. Edwards Deming은 각각 많은 제품이 의도한 작업을 수행하지 못하는 이유에 대한 영향력 있는 견해를 가지고 있었으며, 이 아이디어는 특히 소프트웨어에 적용됩니다. Crosby는 품질이 근본적으로 요구사항에의 적합성이라고 주장하며, 명확히 정의하지 않으면 전달될 수 없다고 했습니다. Juran은 사용 적합성에 대해 이야기하며, 소프트웨어는 단지 체크리스트를 통과하는 것이 아니라 실제 문제를 실제 컨텍스트에서 해결해야 한다고 했습니다. Deming은 결함이 단순한 기술적 실수가 아니라 특히 커뮤니케이션의 부족과 공유 이해의 결여라는 깨진 시스템의 증상이라고 강조하며 더 나아갔습니다. 그는 엔지니어링의 인간적인 측면에 초점을 맞추어 사람들이 함께 배우고, 소통하고, 개선할 수 있는 프로세스를 만드는 것에 중점을 두었습니다.

1980년대에 품질 운동의 이러한 통찰은 소프트웨어 개발에 적용되기 시작했고, 이해관계자의 요구를 식별, 분석, 문서화, 관리하는 데 중점을 둔 요구사항 엔지니어링이라는 독립된 분야로 구체화되었습니다. 이는 자체 회의, 방법론 및 전문 실무를 갖춘 독립된 분야로 등장했습니다. IEEE 컴퓨터 학회는 1993년 첫 번째 국제 요구사항 엔지니어링 심포지엄을 통해 이를 공식화하여 소프트웨어 엔지니어링의 핵심 영역으로 인정했습니다.

1990년대는 요구사항 작업의 전성기로, 조직들은 더 나은 문서 형식이 더 나은 소프트웨어를 보장할 것이라는 믿음으로 공식 프로세스와 템플릿에 크게 투자했습니다. IEEE 830과 같은 표준은 소프트웨어 요구사항 명세의 구조를 규정하였고, 소프트웨어 개발 생명 주기 및 CMM/CMMI와 같은 프로세스 모델은 엄격한 문서화 및 반복 가능한 실무를 강조했습니다. 많은 조직들이 올바르게 작성하면 올바른 시스템을 보장할 것이라는 희망으로 상세한 템플릿과 양식을 설계하는 데 많은 투자를 했습니다. 실제로 이러한 템플릿은 일관성과 준수를 위해 유용했지만, 한 사람의 머릿속에 있는 것이 다른 모든 사람의 머릿속에 있는 것과 일치하는지 확인하는 어려운 부분을 제거하지는 않았습니다.

1990년대가 공식 문서화에 중점을 두었다면, 2000년대의 애자일(Agile) 운동은 더 가벼운 대화 중심의 접근 방식으로 전환되었습니다. 사용자 스토리(User Stories)는 무거운 명세에 대한 의도적인 반대점으로 등장하여 사용자의 관점에서 기능을 간단히 설명하는 짧고 간단한 설명으로, 작성하기 쉽고 이해하기 쉽게 설계되었습니다. 모든 세부 사항을 사전에 캡처하려고 하기보다는, 사용자 스토리는 개발자와 이해관계자 간의 대화를 위한 자리 표시자로 사용되었습니다. 이 실천은 의도적으로 간단하게 유지되었으며, 공유 이해는 문서화가 아닌 대화에서 비롯된다는 아이디어에 기반을 두고 있으며, 요구사항은 프로젝트 시작 시 고정되는 것이 아니라 반복과 작동하는 소프트웨어를 통해 발전한다고 보았습니다.

이 모든 것은 요구사항 엔지니어링을 소프트웨어 엔지니어링 실무의 정당한 영역이자 고유한 기술 세트를 갖춘 진정한 경력 경로로 강화했습니다. 이제 요구사항 엔지니어링이 구축해야 할 것에 대한 가정을 표면화하고 목표를 명확히 하며 관련된 모든 사람이 동일한 이해를 갖도록 하는 소프트웨어 엔지니어링의 중요한 영역이라는 광범위한 합의가 있습니다.

프롬프트 엔지니어링은 요구사항 엔지니어링이다

프롬프트 엔지니어링과 요구사항 엔지니어링은 문자 그대로 동일한 기술입니다—명확성, 컨텍스트, 의도를 사용하여 의도를 전달하고 구축되는 것이 실제로 필요한 것과 일치하도록 보장하는 것입니다.

사용자 스토리는 전통적인 공식 명세에서 진화한 것으로, 요구사항을 간단하고 유연하게 접근하면서도 의도를 모두가 이해하도록 하는 동일한 목표를 가지고 있었습니다. 사용자 스토리는 프로젝트에 대한 공유 이해를 만드는 것이 요구사항의 본질임을 팀들이 인식하도록 도왔기 때문에 산업 전반에 걸쳐 널리 수용되었습니다. 사용자 스토리는 팀이 의도를 캡처하고 대화, 반복, 작동하는 소프트웨어를 통해 이를 정제하는 가벼운 방법을 제공했습니다.

프롬프트 엔지니어링은 정확히 동일한 역할을 합니다. 프롬프트는 AI와의 대화를 위한 가벼운 자리 표시자입니다. 우리는 여전히 반복을 통해 이를 정제하며, 컨텍스트를 추가하고 의도를 명확히 하며, 실제로 의도한 것과 출력이 일치하는지 확인합니다. 그러나 중요한 것은 AI와의 전체 대화와 그 컨텍스트입니다. 개별 프롬프트는 단지 의도와 컨텍스트를 전달하는 수단일 뿐입니다. 애자일이 요구사항을 정적 명세에서 살아있는 대화로 전환한 것처럼, 프롬프트 엔지니어링은 AI와의 상호작용을 단일 명령에서 반복적인 정제 프로세스로 전환합니다—하지만 AI가 명확한 질문을 하지 않기 때문에 출력에서 누락된 부분을 추론해야 하는 경우가 많습니다.

사용자 스토리는 의도적으로 엔지니어링 작업을 사람들과 그들의 머릿속에 있는 것에 다시 집중시켰습니다. 요구사항 문서가 Word에 있든 Jira에 있는 사용자 스토리이든, 가장 중요한 것은 우리가 작성한 종이, 티켓, 문서가 아닙니다. 가장 중요한 것은 내 머릿속에 있는 것이 당신의 머릿속에 있는 것과 일치하고, 관련된 모든 사람의 머릿속에 있는 것과 일치하는 것입니다. 종이는 우리가 동의하는지 여부를 파악하는 데 도움이 되는 편리한 방법일 뿐입니다.

프롬프트 엔지니어링은 동일한 결과를 요구합니다. 팀원들과 정신 모델을 일치시키는 대신, 우리는 AI와 소통하고 있지만 목표는 변하지 않았습니다. 고품질 제품을 생산하는 것입니다. Deming, Juran, Crosby가 제시한 품질 엔지니어링의 기본 원칙은 프롬프트 엔지니어링에서도 직접적인 유사점을 가지고 있습니다.

• Deming의 시스템과 커뮤니케이션에 대한 초점: 프롬프트 실패는 사람의 문제가 아닌 프로세스의 문제로 추적될 수 있습니다. 이는 일반적으로 "나쁜 AI"가 아닌 컨텍스트와 커뮤니케이션의 부족에서 비롯됩니다.
• Juran의 사용 적합성에 대한 초점: Juran이 품질을 "사용 적합성"으로 정의했을 때, 그는 우리가 생산하는 것이 실제 요구를 충족해야 한다고 의미했습니다—단지 그럴듯해 보이는 것이 아니라. 프롬프트가 실제 문제를 해결하지 못하면 출력이 쓸모없으며, 사용에 적합한 프롬프트를 생성하지 못하면 환각이 발생할 것입니다.
• Crosby의 요구사항에의 적합성에 대한 초점: 프롬프트는 기능적 요구뿐만 아니라 유지보수성 및 가독성과 같은 비기능적 요구도 명시해야 합니다. 컨텍스트와 프레이밍이 명확하지 않으면 AI는 실제 의도가 아닌 훈련 분포에 맞는 출력을 생성할 것입니다.

이러한 품질 원칙이 프롬프트 엔지니어링에서 가장 명확하게 나타나는 방법 중 하나는 컨텍스트 엔지니어링(Context Engineering)이라고 불리는 것입니다—모델이 유용한 것을 생성하기 위해 볼 필요가 있는 것을 결정하는 것으로, 일반적으로 주변 코드, 테스트 입력, 예상 출력, 설계 제약 조건 및 기타 중요한 프로젝트 정보를 포함합니다. AI에게 너무 적은 컨텍스트를 제공하면, 그것은 훈련 데이터에 기반하여 가장 가능성이 높은 것으로 보이는 것을 채워넣습니다 (이는 대개 당신이 염두에 둔 것이 아닙니다). 너무 많은 정보를 제공하면, 정보에 묻혀서 당신이 정말로 요청한 것을 잃어버릴 수 있습니다. 무엇을 포함하고 무엇을 생략할지를 판단하는 것은 항상 요구사항 작업의 핵심에서 가장 깊은 도전 중 하나였습니다.

요구사항 엔지니어링과 프롬프트 엔지니어링 사이에는 또 다른 중요한 유사점이 있습니다. 1990년대에 많은 조직들은 템플릿 함정에 빠졌습니다—올바른 표준화된 양식이나 요구사항 템플릿이 좋은 결과를 보장할 수 있다고 믿었습니다. 팀들은 문서를 설계하고 작성하는 데 엄청난 노력을 기울였습니다. 그러나 진짜 문제는 형식이 아니라, 기본 의도가 진정으로 공유되고 이해되었는지 여부였습니다.

오늘날 많은 회사들은 프롬프트 라이브러리 또는 프롬프트 작성의 어려움을 제거하기 위해 실천을 표준화하려는 사전 작성된 프롬프트의 카탈로그와 같은 유사한 함정에 빠집니다. 프롬프트 라이브러리는 참조나 출발점으로 유용할 수 있지만, 문제를 프레이밍하고 공유 이해를 보장하는 핵심 기술을 대체하지는 않습니다. 1990년대의 완벽한 요구사항 템플릿이 올바른 시스템을 보장하지 않았던 것처럼, 오늘날의 캔 프롬프트도 올바른 코드를 보장하지 않습니다.

수십 년이 지난 후에도 Brooks가 그의 "No Silver Bullet" 에세이에서 제기한 포인트는 여전히 유효합니다. 이해해야 할 본질적인 복잡성을 제거할 수 있는 단일 템플릿, 라이브러리 또는 도구는 없습니다. 1990년대의 요구사항 엔지니어링이든 오늘날의 프롬프트 엔지니어링이든, 어려운 부분은 항상 동일합니다. 의도의 공유 이해를 구축하고 유지하는 것입니다. 도구는 도움이 될 수 있지만, 그 자체로는 규율을 대체하지 않습니다.

AI는 이 핵심 커뮤니케이션 문제의 중요성을 높입니다. 팀원과 달리 AI는 반박하거나 질문하지 않으며, 주어진 프롬프트에 기반하여 그럴듯해 보이는 것을 생성할 뿐입니다. 이는 요구사항의 명확한 커뮤니케이션을 더욱 중요하게 만듭니다.

요구사항 엔지니어링의 이해 정렬은 프로젝트에 AI 도구를 도입할 때 더욱 중요해집니다, 왜냐하면 AI는 판단력이 없기 때문입니다. AI는 거대한 모델을 가지고 있지만, 잘 지시될 때만 효과적으로 작동합니다. AI는 코드, 문서 및 기타 프로젝트 정보와 인공물의 형태로 제공되는 컨텍스트가 필요합니다, 이는 AI가 프로젝트에 대해 아는 유일한 것이 우리가 말해주는 것이라는 것을 의미합니다. 그렇기 때문에 AI가 "아는" 것이 실제로 우리가 아는 것과 일치하는지 확인하고 검증하는 방법을 갖는 것이 특히 중요합니다.

고전적인 요구사항 엔지니어링 문제—특히 Deming이 경고했던 커뮤니케이션의 부족과 공유 이해의 결여는 요구사항 엔지니어와 애자일 실무자들이 수십 년 동안 해결하려고 노력해온 문제—는 우리가 AI를 사용할 때 더욱 복잡해집니다. 우리는 여전히 의도를 전달하고 요구사항을 명확히 지정하는 동일한 문제에 직면해 있습니다. 그러나 이제 이러한 요구사항은 팀이 읽기 위한 것이 아니라 AI의 컨텍스트를 설정하는 데 사용됩니다. 문제 프레이밍의 작은 변화가 AI가 생성하는 것에 큰 영향을 미칠 수 있습니다. 자연어를 사용하여 코드의 구조화되고 명확한 구문을 점점 더 대체하는 것은 전통적으로 소프트웨어가 이해 실패로부터 보호받는 데 도움이 되었던 중요한 안전장치를 제거합니다.

요구사항 엔지니어링의 도구는 그 누락된 안전장치를 보완하는 데 도움이 됩니다. 애자일의 반복적인 프로세스는 개발자가 요구사항을 이해하고, 작동하는 소프트웨어를 구축하며, 제품 소유자와 지속적으로 검토하는 것이 오해가 조기에 발견되도록 보장하는 점검이었습니다. AI가 요구사항에서 직접 코드를 생성함으로써 번역과 이해의 추가 단계를 제거할수록, 관련된 모든 사람—이해관계자와 엔지니어 모두—이 구축해야 할 것에 대한 진정으로 공유된 이해를 갖는 것이 더욱 중요해집니다.

팀의 사람들이 소프트웨어를 함께 구축할 때, 그들은 무엇을 구축해야 하는지 이해하기 위해 많은 시간을 대화하고 질문하는 데 사용합니다. AI와 작업하는 것은 다른 종류의 피드백 사이클을 따릅니다—무엇이 누락되었는지 알기 전까지는 출력물을 보고 나서야 알 수 있으며, 종종 누락된 부분을 파악하기 위해 역설계를 해야 합니다. 그러나 두 가지 유형의 상호작용은 요구사항 엔지니어들이 항상 실천해온 컨텍스트와 커뮤니케이션에 대한 동일한 기본 기술을 요구합니다.

이는 실천에서 여러 가지 방식으로 나타납니다.

• 컨텍스트와 공유 이해는 기본입니다. 좋은 요구사항은 팀이 어떤 행동이 중요한지 이해하고 언제 작동하는지 알 수 있도록 도와줍니다—기능적 요구사항(무엇을 구축할 것인지)과 비기능적 요구사항(얼마나 잘 작동해야 하는지)을 모두 캡처합니다. 동일한 구분이 프롬프트에도 적용되지만, 수정할 기회는 더 적습니다. 중요한 것을 생략하면 AI는 반박하지 않고 그럴듯해 보이는 것으로 응답합니다. 때로는 그 출력이 합리적으로 보일 때까지는 문제가 해결된 것처럼 보입니다.
• 범위 설정은 진정한 판단이 필요합니다. AI를 사용하여 코드를 작성하는 데 어려움을 겪는 개발자는 일반적으로 두 가지 극단에 빠집니다. 너무 적은 컨텍스트를 제공하거나(실제로는 실패하는 것처럼 보이는 단일 문장) 전체 파일을 붙여넣고 모델이 올바른 메서드에 집중하기를 기대합니다. 중요한 것을 명시적으로 언급하지 않으면—기능적 요구사항과 비기능적 요구사항 모두—무엇이 중요한지 알 수 없습니다.
• 컨텍스트는 드리프트하고 모델은 그것이 드리프트하고 있다는 것을 모릅니다. 인간 팀과 함께라면, 이해는 점검과 대화를 통해 점진적으로 변화합니다. 프롬프트를 사용할 때, 드리프트는 몇 번의 교환만에 발생할 수 있습니다. 모델은 여전히 유창한 응답을 생성할 수 있지만, 말이 안 되는 수정을 제안할 때가 있습니다. 이는 컨텍스트가 드리프트했음을 나타내며, 대화를 재구성해야 한다는 신호입니다—아마도 모델에게 코드를 설명하거나 자신이 하고 있는 일을 다시 진술하도록 요청함으로써.

역사는 계속 반복됩니다. 흩어진 요구사항으로 가득 찬 바인더에서 IEEE 표준, 사용자 스토리, 오늘날의 프롬프트에 이르기까지, 규율은 동일합니다. 우리는 이를 진정한 엔지니어링으로 다룰 때 성공합니다. 프롬프트 엔지니어링은 요구사항 엔지니어링의 진화의 다음 단계입니다. 이는 프로젝트에 참여하는 모든 사람—AI를 포함하여—이 공유된 이해를 갖도록 보장하는 방법이며, 오해를 피하고 올바른 것을 구축하기 위해 항상 필요했던 동일한 주의, 명확성, 의도적인 커뮤니케이션을 요구합니다.

원문 . Prompt Engineering Is Requirements Engineering