AI에 대한 프롬프트에는 역할이 다른 지시가 섞여 있다.

이 조건을 반드시 지켜라.

이 범위 내라면 변경해도 좋다.

이 처리는 금지한다.

이 순서대로 작업을 진행하라.

모두 AI를 움직이기 위한 규칙이다.

하지만 역할은 같지 않다.

• 완성된 출력이 충족해야 할 조건
• AI에게 부여하는 재량의 범위
• 처리 중에도 넘어서서는 안 되는 경계
• 작업을 진행하기 위한 절차

이것들을 하나의 문장에 같은 강도로 나열하면, 조건들 사이의 충돌이 보이지 않게 된다.

그리고 지시에 부족함이나 모순이 있어도, AI가 반드시 보고해 준다는 보장은 없다.

금지 조건을 독자적으로 좁게 해석한다.

부족한 정보를 그럴듯한 전제로 보충한다.

모순된 지시에 자신만의 우선순위를 매긴다.

예외가 필요하다고 판단하여 그대로 처리를 계속한다.

결과만 보면 어느 정도 정돈되어 보인다.

이 점이 까다롭다.

AI에게 규칙을 주는 것과 AI가 규칙을 올바르게 운용할 수 있는 것은 다르다.

따라서 이 기사에서는 AI에 대한 지시를 다음 네 가지로 나누어 생각한다.

• 필수
• 허가
• 금지
• 절차

나아가 정상적으로 처리할 수 없는 경우의 출구로서, 정지 조건을 추가한다.

단, 이 분류가 유일한 정답은 아니다.

하나의 조건이 여러 역할을 가질 수도 있다.

분류의 목적은 모든 조건을 하나의 상자에 올바르게 나누어 담는 것이 아니다.

그 조건이 완성품, 재량, 처리 경계, 절차 중 무엇을 제어하고 있는지를 확인하는 것이다.

필수(Must)는 완성된 출력의 성립 조건이다

필수 조건은 완성된 출력이 충족해야 할 상태이다.

예를 들어 다음과 같은 것들이 있다.

• 요약은 300자 이내로 할 것
• 원문의 결론을 포함할 것
• 지정된 항목을 모두 출력할 것
• 지정된 형식으로 반환할 것
• 대상 독자에 맞춘 문체로 할 것

이것들은 해당 작업이 성공했다고 판정하기 위한 조건이다.

지켜지지 않는다면 출력이 아무리 자연스러워도 성공이라고 할 수 없다.

단, 필수 조건을 대량으로 나열하면 좋은 것은 아니다.

예를 들어,

내용을 생략하지 말 것.

300자 이내로 요약할 것.

원문이 길다면 이 두 가지는 양립할 수 없다.

그럼에도 정지 조건이 없다면, AI는 어느 한쪽을 멋대로 우선시할 수 있다.

중요도가 낮아 보이는 부분을 삭제한다.

글자 수를 조금 초과한다.

내용을 압축했으므로 조건은 대체로 충족했다고 해석한다.

필수 조건을 작성할 때는 충족하지 못했을 경우의 처리 방식도 결정할 필요가 있다.

허가(Permission)는 AI에게 넘겨주는 재량의 경계이다

허가는 AI가 실행해도 좋다는 것을 나타낸다.

예를 들어 문장 수정이라면 다음과 같은 것들이 있다.

• 오탈자를 수정해도 좋다
• 줄바꿈과 문장 부호를 조정해도 좋다
• 중복 표현을 정리해도 좋다
• 지정된 범위 내에서 설명을 보충해도 좋다
• 여러 안을 제시해도 좋다

허가는 단순한 추가 조건이 아니다.

AI에게 넘겨주는 재량의 경계이다.

예를 들어,

읽기 쉽게 수정해 주세요.

라고만 적었을 경우, AI는 다양한 변경을 수행할 가능성이 있다.

어미를 바꾼다.

단락을 재배치한다.

설명을 추가한다.

주장을 정리한다.

경우에 따라서는 원문에 없던 결론까지 보충한다.

이용자는 오탈자 수정만을 상정했을지도 모른다.

하지만 무엇을 변경해도 되는지가 적혀 있지 않기 때문에, AI는 "읽기 쉽게 만들기 위해 필요한 처리"를 독자적으로 판단한다.

허가를 작성할 때는 무엇을 해도 되는지뿐만 아니라, 어디까지 해도 되는지를 작성한다.

나아가 그 목록이 한정 열거(Limited Enumeration)인지, 예시 열거(Exemplary Enumeration)인지도 명시하는 것이 좋다.

한정 열거할 경우

이하에 명기한 처리만을 실행해도 좋다.
기재되지 않은 변경은 수행하지 않는다.
- 오탈자 수정
...

이 경우 목록에 없는 처리는 허가되지 않는다.

예시 열거할 경우

이하를 포함하여, 의미나 사실관계에 영향을 주지 않는 경미한 수정을 해도 좋다.
- 오탈자 수정
- 문장 부호 조정
...

이 경우 목록은 허가 범위의 예시이며, 완전한 열거가 아니다.

"오탈자를 수정해도 좋다"라고 적었을 때, 줄바꿈 조정까지 허가된 것인가.

이 부분이 모호한 상태로 남아 있다면, 허가 범위는 다시 AI의 해석으로 돌아간다.

AI에게 자유를 준다면, 그 자유의 바깥쪽도 결정해야 한다.

금지(Prohibition)는 처리 중에도 넘어서서는 안 되는 경계이다

금지는 AI가 실행해서는 안 되는 행위를 나타낸다.

예를 들어 다음과 같은 것들이 있다.

• 원문에 없는 사실을 추가하지 말 것
• 불명확한 점을 추측으로 보충하지 말 것
• 개인정보를 출력하지 말 것
• 승인 없이 외부로 전송하지 말 것
• 원문의 주장을 다른 주장으로 바꾸지 말 것

필수와 금지는 비슷한 표현이 될 수 있다.

예를 들어,

입력된 정보만을 사용할 것.

은 필수 조건(Must)으로 작성할 수 있다.

입력에 없는 정보를 추가하지 말 것.

은 금지 사항(Prohibited)으로 작성할 수 있다.

개인정보를 출력하지 말 것, 이라는 조건 또한 완성품이 갖추어야 할 상태이기도 하며, 처리 중에 넘어서는 안 될 경계이기도 하다.

하나의 조건이 필수와 금지 양쪽의 역할을 모두 수행하는 경우도 있다.

그래도 괜찮다.

중요한 것은 분류상의 정답을 결정하는 것이 아니다.

그 조건이 무엇을 방지하고, 무엇을 성립시키는지를 확인하는 것이다.

금지 사항은 강력한 조건처럼 보인다.

하지만 단순히 「금지」라고 적는다고 해서 반드시 지켜지는 것은 아니다.

예를 들어,

원문을 변경해서는 안 된다.

읽기 쉽게 개선할 것.

이 두 가지가 동시에 있다고 가정하자.

본래라면 어디까지의 변경이 허용되는지 확인할 필요가 있다.

하지만 AI는,

의미를 바꾸지 않았으므로 이것은 원문의 변경이 아니다.

라고 말하듯, 표현이나 구조를 바꾸기도 한다.

AI가 의도적으로 말을 돌리는 것이 아니다.

태스크(Task)의 달성과 금지 조건을 양립시키려 노력한 결과, 금지의 적용 범위를 독자적으로 재해석하고 있는 것이다.

AI는 규칙을 어기기 전에, 규칙의 의미를 바꾸기도 한다.

따라서 금지 사항에는 금지되는 행위의 정의뿐만 아니라, 금지 사항에 저촉될 것 같을 때의 동작도 필요하다.

금지 사항에 저촉될 가능성이 있는 경우에는 독자적인 해석으로 계속 진행하지 않는다.
처리를 일시 중단하고, 저촉될 가능성이 있는 조건을 보고한다.

금지하는 것만으로는 부족하다.

금지에 저촉되었을 때 무엇을 할지까지 결정해야 한다.

절차(Procedure)는 처리의 진행 방식이다

절차는 AI가 어떤 순서로 작업할지를 나타낸다.

예를 들어, 다음과 같은 것들이 있다.

• 입력 내용을 확인한다
• 필수 항목을 추출한다
• 금지 사항 저촉 여부를 확인한다
• 조건을 만족하는 경우에만 출력한다

필수 조건은 최종적으로 만족해야 할 상태이다.

절차는 그곳에 도달하기 위한 진행 방식이다.

이 둘은 같지 않다.

예를 들어,

처음에 내용을 3가지로 분류할 것.

이라는 절차가 있다고 하자.

하지만 입력이 분류 불가능한 경우라도 AI가 억지로 세 가지로 나눌 가능성이 있다.

절차가 적혀 있기 때문이다.

본래 필요한 것은,

3가지로 분류할 수 없는 경우에는 억지로 분류하지 말고, 판단 불능으로 보고한다.

라는 이상 발생 시의 분기(Branch)이다.

다만, 절차를 명시한다고 해서 AI 내부에서 그 순서가 엄격하게 실행되었다고 보장할 수 있는 것은 아니다.

AI가 최종 출력에서,

확인했습니다. 문제없습니다.

라고 답변하더라도, 그것이 정말로 각 공정을 독립적으로 검증했다는 증거는 되지 않는다.

절차를 적음으로써 처리의 의도는 전달하기 쉬워진다.

하지만 중요한 판정은 처리 공정별로 분할하거나, 시스템 측에서 개별적으로 검증할 필요가 있다.

절차는 정상적으로 처리할 수 있는 경우의 흐름이다.

정상적으로 진행할 수 없는 경우의 동작은 별도로 설계해야 한다.

분류하면 인간 측의 모순이 보인다

예를 들어, 다음과 같은 프롬프트가 있다.

원문의 내용을 바꾸지 말고, 읽기 쉽게 수정해 주세요.
필요에 따라 설명을 추가해도 좋습니다.
새로운 정보는 추가하지 마세요.
...

언뜻 보기에는 상세하게 작성된 것 같다.

하지만 분류해 보면 문제가 보인다.

필수 (Must)

• 원문의 내용을 바꾸지 말 것
• 300자 이내로 작성할 것

허가 (May)

• 필요에 따라 설명을 추가해도 됨

금지 (Must Not)

• 새로운 정보를 추가하지 말 것

절차 또는 방침 (Procedure/Policy)

• 정보가 부족하더라도 완성할 것

여기에는 조건의 충돌, 허가 범위의 모호함, 이상 발생 시 방침의 부족함이 있다.

조건부로 충돌하는 것

원문의 내용을 모두 유지하면서 300자 이내로 작성한다.

원문이 짧다면 양립할 수 있다.

하지만 길다면 양립할 수 없다.

허가 범위가 모호한 것

설명을 추가해도 좋지만, 새로운 정보는 추가해서는 안 된다.

원문 내의 정보를 바꾸어 표현하는 것은 괜찮은가?

배경 지식을 더하는 것은 어떤가?

원문으로부터 추론할 수 있는 내용을 보충하는 것은 어떤가?

「설명의 추가」의 범위가 정의되어 있지 않다.

이상 발생 시의 방침이 부족한 것

정보가 부족하더라도 가능한 한 완성한다.

추측해도 되는가?

질문을 되물어야 하는가?

부족한 부분을 공란으로 남겨두는가?

그러한 방침이 없다.

이를 하나의 연속된 문장으로 쓰면 문제가 잘 보이지 않는다.

분류하면 결함이 보인다.

프롬프트를 정리하는 목적은 AI가 읽기 쉽게 만들기 위함만이 아니다.

인간이 자신의 지시 사항에 담긴 모순을 깨닫기 위함이기도 하다.

조건을 계속 추가하면 프롬프트는 사양(Specification)이 아니라 조건 집합이 된다

AI가 조건을 지키지 않았을 때, 주의 사항을 추가하고 싶어진다.

이 조건도 반드시 지켜라.

지난번에 실패했으니, 이 경우에는 금지한다.

예외로서, 이 조건만은 허가한다.

만약을 위해, 다른 표현으로 다시 한번 적는다.

그렇게 하면, 프롬프트는 길어진다.

하지만, 규칙을 늘린다고 해서 반드시 지켜지는 것은 아니다.

긴 프롬프트의 문제는 단순한 글자 수가 아니다.

• 중요한 금지 사항이 설명문에 파묻힌다
• 동일한 조건이 다른 표현으로 반복된다
• 전반부와 후반부의 조건이 충돌한다
• 예외 조건이 통상 조건보다 많아진다
• 어떤 조건이 중요한지 알 수 없게 된다

그 결과, 프롬프트는 엄격한 사양서가 아니라, 우선순위가 없는 조건들의 집합이 된다.

짧은 프롬프트가 강한 것이 아니다.

조건의 역할이 나누어져 있는 프롬프트가 강하다.

길어지는 경우라도, 필수, 허가, 금지, 절차를 나눈다.

중요한 조건을 압축한다.

중복을 줄인다.

그것만으로도, 자신이 무엇을 지시하고 있는지 보기 쉬워진다.

부족함이나 모순을, AI가 무단으로 해결하게 하지 마라

실제 입력에는 예상치 못한 상황이 있다.

필요한 정보가 없다.

조건을 동시에 만족할 수 없다.

허가 범위가 모호하다.

금지 사항에 저촉될 가능성이 있다.

절차대로 진행할 수 없다.

그때, AI는 반드시 확인을 해주는 것은 아니다.

그럴듯한 전제를 추가한다.

조건의 우선순위를 제멋대로 결정한다.

금지 조건을 좁게 해석한다.

예외로서 처리를 계속한다.

AI는, 일을 망치려고 하는 것이 아니다.

오히려, 완성된 답변을 돌려주려고 노력하고 있다.

하지만, 부족한 조건을 보충하는 것은 판단이다.

모순된 조건의 우선순위를 결정하는 것도 판단이다.

판단에는 책임이 따른다.

이용자가 전달하지 않은 판단 기준을, AI가 멋대로 만들어도 되는 것은 아니다.

정지 조건은, 우선순위가 아니라 처리 게이트(Gate)이다

필수, 허가, 금지, 절차를 정리하는 것만으로는, 이상 발생 시의 움직임이 결정되지 않는다.

그래서 정지 조건을 추가한다.

정지 조건이란, AI가 처리를 시작해도 되는지, 계속해도 되는지를 판정하는 게이트이다.

다른 조건과 경쟁하는 우선 사항이 아니다.

예를 들어, 다음과 같은 경우에는 처리를 멈춘다.

• 필수 조건끼리 양립할 수 없다
• 필요한 정보가 부족하다
• 허가된 범위를 판단할 수 없다
• 금지 사항에 저촉될 가능성이 있다
• 지정된 절차로 처리할 수 없다

여기서 말하는 정지에는, 완전한 중지뿐만 아니라 일시 중단도 포함한다.

부족한 정보에 대해 확인 질문을 돌려준다.

판단이 필요한 부분을 인간에게 되돌린다.

금지 사항에 저촉되므로 실행을 거부한다.

이것들은 모두, 다음 처리로 무단 진행하지 않기 위한 정지이다.

상태로서 나눈다면, 다음과 같다.

• 계속 가능
• 확인 대기
• 인간 판단으로 되돌림
• 실행 금지

정지 조건에 해당한다면, 우선순위를 사용하여 독자적으로 해결해서는 안 된다.

처리를 멈춘다.

이를 통해, AI에게 「가능한 한 완성할 것」 이외의 선택지를 줄 수 있다.

단, 「멈춰라」라고 쓰는 것만으로는 약하다.

멈췄을 때 무엇을 돌려줄지도 결정한다.

정지 시의 출력

• 정지한 이유
• 충돌하고 있는 조건
• 부족한 정보
• 확인이 필요한 질문
• 실행 가능한 대안

정상 시의 출력뿐만 아니라, 이상 시의 출력 형식을 만든다.

그것을 통해, 완성품을 억지로 만드는 대신, 문제를 보고하는 경로가 생긴다.

판정 순서와 우선순위를 분리한다

정지 조건은, 처음에 한 번만 확인하는 항목이 아니다.

처리 전 과정에 걸쳐 있는 게이트이다.

판정 순서

• 입력 부족이나, 지시 간의 모순이 없는지 확인한다
• 금지 사항에 저촉되지 않는지 확인한다
• 필수 조건을 동시에 만족할 수 있는지 확인한다
• 허가된 범위를 특정한다
• 지정된 절차를 실행한다
• 출력 형식과 품질을 확인한다

각 단계에서 정지 조건에 해당할 경우에는, 이후의 처리로 진행하지 않는다.

한편, 여러 조건이 동시에 영향을 미치는 경우의 우선순위는 별도로 작성한다.

우선순위

• 금지 사항
• 필수 조건
• 출력 형식
• 품질 개선

품질을 높이기 위해, 금지 사항을 어겨서는 안 된다.

형식을 지키기 위해, 사실을 보충해서는 안 된다.

글자 수를 맞추기 위해, 중요한 내용을 멋대로 깎아서는 안 된다.

허가는, 우선순위를 다투는 조건이 아니다.

애초에 처리해도 좋은 범위를 정하는 경계이다.

허가되지 않은 변경을, 출력 형식이나 품질 개선을 위해 실행해서는 안 된다.

또한, 조건을 동시에 만족할 수 없는 경우에는, 우선순위로 독자적으로 해결하지 않는다.

정지 조건으로서 보고한다.

우선순위는, 모순을 억지로 해결하기 위한 것이 아니다.

정상적으로 처리할 수 있는 범위 내에서, 무엇을 무겁게 다룰 것인지를 나타내는 것이다.

실용 템플릿

모든 항목을 매번 사용할 필요는 없다.

우선은, 기본과 이상계(Exception case)를 나누는 것이 좋다.

# 목적
실행하기를 원하는 작업을 한 문장으로 기재한다.
# 필수
...

허가 사항을 단순 열거가 아닌 예시로 사용할 경우에는 그 취지를 작성한다.

다음 내용을 포함하여, 의미나 사실관계에 영향을 주지 않는 경미한 수정은 수행해도 좋다.

필요에 따라 다음을 추가한다.

• 입력의 정의
• 조건의 우선순위
• 정상 시의 출력 형식
• 자기 체크 (Self-check)

자기 체크는 보조적인 수단이다.

중요한 조건을 보장하는 검증 기제 (Verification mechanism)가 아니다.

조건이 적은 작업이라면 짧게 작성해도 좋다.

분류하는 목적은 프롬프트를 길게 만드는 것이 아니다.

조건의 역할을 가시화하는 것이다.

뒤섞인 프롬프트를 정리하기

앞서 살펴본 프롬프트를 분류와 정지 조건을 사용하여 정리한다.

# 목적
원문을 읽기 쉽게 정돈한다.
# 필수
...

조건을 대량으로 추가한 것이 아니다.

원래 있던 조건을 나누고, 충돌했을 경우의 출구(Exit)를 만들었다.

이 부분이 중요하다.

채팅창에서 일어나는 일은 API에서도 일어난다

지금까지의 이야기는 채팅 AI만의 문제가 아니다.

채팅창에서 발생하는 무단 보완, 모순의 자기 해결, 금지 조건의 재해석은 API로 호출하는 AI에서도 일어날 수 있다.

채팅창의 습관은 API로 전환하는 순간 사라지는 것이 아니다.

단지 보이지 않게 될 뿐이다.

채팅창에서는 인간이 출력을 읽는다.

이상하다면 그 자리에서 멈출 수 있다.

하지만 API에서는 출력이 그대로 다음 공정으로 넘어가는 경우가 있다.

문의를 분류한다.

분류 결과에 따라 처리를 나눈다.

답변문을 생성한다.

별도의 시스템에 등록한다.

경우에 따라서는 그대로 전송한다.

채팅창에서는 멋대로 보완하는 것이 위화감으로 느껴진다.

API에서는 멋대로 보완한 것이 처리 결과로서 흘러간다.

그렇기에 API로 AI를 사용할 때일수록 프롬프트만으로 완결 지으려 해서는 안 된다.

API에서는 프롬프트의 분류를 처리 제어로 바꾼다

API로 AI를 호출하는 경우에는 정지나 확인이 필요한 상태를 시스템 측에서도 다룰 수 있도록 한다.

예를 들어, 다음과 같은 상태를 반환한다.

{
"status": "ok",
"result": {},
...
}

status에는 예를 들어 다음과 같은 값을 사용한다.

ok

needs_review

blocked

정상적으로 처리된 경우에만 ok를 반환한다.

정보 부족이나 판단 불능인 경우에는 needs_review를 반환한다.

금지 사항에 저촉되거나 해결할 수 없는 모순이 있는 경우에는 blocked를 반환한다.

시스템 측에서는 ok인 경우에만 다음 공정으로 진행한다.

needs_review는 인간에게 되돌린다.

blocked는 처리를 정지한다.

단, AI에게 JSON을 반환하게 한다고 해서 안전해지는 것은 아니다.

AI가 그럴듯하게 ok를 반환할 가능성이 있다.

AI가 반환한 status를 그대로 신용해서는 안 된다.

스키마 검증 (Schema validation)을 통해 필수 항목, 타입, 허가된 값을 확인한다.

나아가 업무 규칙에 따른 검증을 수행하여, 금지된 처리나 부정적인 상태가 다음 공정으로 흘러가지 않도록 한다.

결정론적 (Deterministic)으로 판정할 수 있는 입력 조건이나 금지 사항은 AI에게 판정하게 하지 말고, 코드 측에서 먼저 처리한다.

예를 들어 다음과 같은 것들이 있다.

• 필수 항목이 존재하는가
• 글자 수가 범위 내에 있는가
• 값이 허가된 열거형 값 (Enumerated value)인가
• 입력 형식이 스키마에 맞는가
• 외부 전송 대상이 허가 목록에 포함되어 있는가

AI가 판단할 필요가 없는 조건까지 AI에게 넘기지 않는다.

구조화된 출력 (Structured output)은 검증하기 쉬운 형태를 만드는 것이다.

정확성 그 자체를 보장하는 것은 아니다.

AI에게 멈추라고 부탁하는 것만으로는 부족하다.

멈춰야 할 출력을 시스템 측에서 다음으로 흘려보내지 않는 메커니즘이 필요하다.

프롬프트만으로 모든 것을 해결하려 하지 마라

필수, 허가, 금지, 절차를 정리하면 실패를 줄일 수 있다.

하지만 프롬프트만으로 모든 것을 보장할 수는 없다.

입력을 사전에 검증한다.

출력 형식을 고정한다.

허가된 값만 받아들인다.

처리를 작게 나눈다.

금지 사항을 시스템 측에서도 확인한다.

중요한 조작에는 인간의 승인을 넣는다.

실패한 출력을 기록한다.

같은 실패가 반복된다면 주의 사항을 늘리는 것이 아니라 처리 전체를 재검토한다.

AI에게 전부 시키려고 하면 프롬프트는 길어진다.

역할이 늘어난다.

조건이 늘어난다.

예외가 늘어난다.

모순도 늘어난다.

하나의 AI에게 분류, 판단, 문장 생성, 승인, 전송까지 모두 맡기면 어디에서 실패했는지 알기 어려워진다.

프롬프트를 강화하기 전에 업무를 나누는 것이 더 나은 경우도 있다.

요약: 조건을 늘리기 전에 역할을 나누어라

AI 프롬프트에는 서로 다른 역할의 규칙들이 섞여 있다.

필수(必須)는 완성된 출력의 성립 조건이다.

허가(許可)는 AI에게 부여하는 재량의 경계이다.

금지(禁止)는 처리 중에도 넘어서는 안 되는 경계이다.

절차(手順)는 처리의 진행 방식이다.

단, 이 분류가 유일한 정답은 아니다.

조건이 무엇을 제어하고 있는지를 파악하기 위한 보조선이다.

그리고 부족함이나 모순이 발생했을 때, AI가 독자적으로 해결하게 해서는 안 된다.

정지 조건(停止条件)을 전체 공정에 걸친 처리 게이트(Gate)로 배치한다.

정상 시의 출력뿐만 아니라, 이상 발생 시의 출력 형식도 만든다.

채팅창에서 발생하는 일은 API로 호출하는 AI에서도 일어날 수 있다.

오히려 API에서는 멋대로 이루어지는 보완이 위화감이 아니라, 처리 결과로서 다음 공정으로 흘러가 버린다.

필수, 허가, 금지, 절차를 분류한다.

분류할 수 없는 예외는 정지, 확인, 반려(差し戻し)로 보낸다.

API에서는 그 상태를 다음 공정의 제어로 전환한다.

규칙을 늘리기 전에, 규칙의 역할을 나눈다.

AI에게 무엇을 필수(必須)로 할 것인가.

무엇을 허가(許可)할 것인가.

무엇을 금지(禁止)할 것인가.

어떤 절차(手順)로 진행하게 할 것인가.

그리고 어떤 상태일 때 처리를 중단할 것인가.

그 단계까지 정리되어야 비로소 프롬프트는 긴 부탁문이 아니라, 이상계(異常系)까지 포함된 처리 사양(Specification)에 가까워진다.

Discussion