회사에서 AI 프롬프트는 왜 업무를 다시 정의하게 만드는가?

AI 모델은 빠르게 좋아졌다.

예전에는 프롬프트를 잘 쓰려면 긴 지시문을 외우듯 써야 한다고 생각했다. 역할을 정해주고, 단계별로 생각하라고 하고, 출력 형식을 세세하게 지정해야 좋은 결과가 나온다고 여겼다.

지금은 조금 다르다. 모델은 짧은 말도 꽤 잘 알아듣는다. 대충 말해도 문장을 만들고, 자료를 요약하고, 초안을 정리한다. 그래서 이런 생각이 들 수 있다.

이제 프롬프트에 의도를 넣는 일이 꼭 필요한가?

이미 모델이 많이 학습되었으니, 그럴 필요조차 줄어든 것 아닌가?

내 생각은 조금 다르다.

줄어든 것은 프롬프트의 잔기술이다. 남아 있는 것은 의도와 판단 기준이다.

AI가 문장을 더 잘 만들수록 회사는 더 분명히 말해야 한다. 무엇을 만들 것인지보다, 무엇을 좋은 결과로 볼 것인지. 어디까지 맡길 것인지보다, 어디서 사람이 판단할 것인지. 결과물을 받을 것인지보다, 그 결과물이 어떤 결정과 행동에 쓰일 것인지.

이 글의 질문은 이것이다.

회사에서 AI 프롬프트는 여전히 중요한가? 중요하다면, 무엇이 중요해졌는가?

개인의 프롬프트와 회사의 프롬프트는 다르다

개인이 AI를 쓸 때는 짧게 말해도 된다.

“이 문장 다듬어줘.”

“이 자료 요약해줘.”

“아이디어 몇 개 뽑아줘.”

이런 일은 실패해도 손실이 작다. 마음에 들지 않으면 다시 물어보면 된다. 이때 프롬프트는 개인의 작업 요령에 가깝다.

하지만 회사에서 반복되는 일은 다르다. 결과물이 다른 사람에게 전달되고, 고객에게 나가고, 회의의 판단 자료가 되고, 다음 실행의 근거가 된다. 이때 AI가 만든 문장은 단순한 초안이 아니라 조직의 판단에 들어간다.

예를 들어 고객 답변 초안을 생각해보자.

“고객에게 답변해줘”라고 말하면 AI는 답변을 만든다. 문장도 자연스럽다. 그러나 회사에서 필요한 답변은 자연스러운 문장만으로 충분하지 않다.

사과할 것인가, 설명할 것인가. 보상 가능성을 열어둘 것인가, 닫을 것인가. 어떤 표현은 피해야 하는가. 고객에게 약속해도 되는 범위는 어디까지인가. 최종 확인은 누가 해야 하는가.

이 질문이 빠지면 답변은 그럴듯해도 위험할 수 있다. AI가 못해서가 아니다. 회사가 자신의 입장과 판단 기준을 충분히 설명하지 않았기 때문이다.

프롬프트가 어려운 이유는 더 이상 AI가 말을 못 알아들어서만은 아니다.

회사가 자기 일을 어떤 의도로 맡기는지 분명히 말하지 못하기 때문이다.

프롬프트는 의도를 설명하게 만든다

프롬프트에는 의도가 담겨야 한다.

그리고 그 의도는 설명될 수 있어야 한다.

여기서 의도란 거창한 말이 아니다. 왜 이 결과가 필요한지, 어디에 쓸 것인지, 무엇을 좋은 결과로 볼 것인지, 누가 마지막으로 확인할 것인지에 가깝다.

무엇을 할 것인지 말하는 것만으로는 부족하다. 왜 그 일을 하는지, 어떤 맥락에서 판단해야 하는지, 어떤 자료를 기준으로 삼아야 하는지, 결과물의 형식과 깊이는 어느 정도여야 하는지 설명되어야 한다. 어디까지는 AI가 처리하고, 어디부터는 사람이 판단해야 하는지도 정해야 한다.

예를 들어 “고객 불만 답변 초안 작성해줘”라는 프롬프트는 약하다.

대신 이렇게 물어야 한다.

이 답변의 목적은 사과인가, 설명인가, 조치 안내인가. 고객에게 약속할 수 있는 범위는 어디까지인가. 법적·계약상 표현에서 피해야 할 말은 무엇인가. 회사가 인정할 사실과 아직 확인 중인 사실은 무엇인가. 최종 발송 전에 누가 확인해야 하는가.

이렇게 쓰면 프롬프트는 AI에게 던지는 문장을 넘어선다. 그 문장에는 회사가 고객을 어떻게 대하고, 어떤 책임을 인정하며, 어디서 사람의 판단을 남겨둘 것인지가 들어간다.

이 점에서 반복 업무의 프롬프트는 업무 설명의 일부 기능을 드러낸다. 일을 설명하고, 필요한 결과와 기준을 밝히고, 사람과 AI의 역할을 나누게 만들기 때문이다.

물론 프롬프트가 직무기술서를 대신하는 것은 아니다. 한 번 쓰고 버리는 실험적 질문, 개인의 아이디어 탐색, 단순 문장 다듬기까지 조직 문서로 만들 필요는 없다. 이 글에서 말하는 프롬프트는 회사 안에서 반복되는 업무, 여러 사람이 함께 쓰는 일, 결과에 책임이 따르는 일에 가깝다.

모델이 좋아질수록 사람의 판단은 더 잘 보여야 한다

모델이 좋아지면 프롬프트는 덜 중요해지는 것처럼 보인다. 실제로 일부는 맞다.

예전처럼 복잡한 형식과 주문을 길게 붙이지 않아도 모델은 꽤 좋은 답을 낸다. 그래서 프롬프트를 문장 기술로만 이해하면, 그 중요성은 줄어든 것처럼 보인다.

하지만 회사에서는 다른 문제가 남는다.

모델은 답을 만들 수 있지만, 회사의 입장을 대신 정할 수는 없다. 모델은 표현을 다듬을 수 있지만, 어떤 약속을 해도 되는지 결정할 수는 없다. 모델은 여러 대안을 만들 수 있지만, 그중 무엇을 선택할지에 따른 책임은 조직이 져야 한다.

그러므로 지금 필요한 프롬프트는 길고 화려한 지시문이 아니다.

회사의 의도와 판단 기준이 드러나는 문장이다.

눈치로 하던 일이 문장으로 바뀐다

직무설계 연구는 일이 사람의 동기와 성과에 영향을 준다고 본다. Hackman과 Oldham(J. Richard Hackman and Greg R. Oldham)의 직무특성이론은 일이 의미, 책임감, 결과에 대한 피드백을 어떻게 만들어내는지를 설명했다.[1]

이 논의를 그대로 AI 프롬프트에 옮기자는 뜻은 아니다. 다만 한 가지는 분명하다. 일은 그냥 주어지는 것이 아니라 설계된다.

회사에서 반복 업무를 AI에 맡기는 순간, 그 설계가 드러난다.

이 일의 목적은 무엇인가.

이 결과는 어디에 쓰이는가.

좋은 결과의 기준은 무엇인가.

AI가 만든 결과를 누가 검토하는가.

틀렸을 때 수정 기준은 어디에 남기는가.

다음 사람이 같은 일을 할 때 무엇을 재사용할 수 있는가.

이 질문에 답하는 과정에서 조직은 눈치로 하던 일을 문장으로 바꾸게 된다. 누가 판단할지, 어디까지 맡길지, 무엇을 좋은 결과로 볼지가 조금씩 드러난다.

그 문장이 반복해서 쓰이고, 고쳐지고, 공유되면 개인의 요령은 조직이 다시 쓸 수 있는 기준이 된다.

반복되는 프롬프트는 루틴을 드러낸다

조직루틴 연구는 루틴을 단순히 굳어진 절차로만 보지 않는다. Feldman과 Pentland(Martha S. Feldman and Brian T. Pentland)는 조직루틴을 고정된 규칙이 아니라, 구조와 실제 수행이 함께 움직이는 것으로 설명했다.[2]

프롬프트도 그렇다. 처음 만든 프롬프트는 완벽하지 않다. 현장에서 써보면 빠진 기준이 보인다. 어떤 자료를 더 넣어야 하는지 알게 된다. 사람이 어디에서 개입해야 하는지도 드러난다.

그때 프롬프트를 고치고, 수정 이유를 남기고, 다음 사람이 다시 쓴다. 그러면 프롬프트는 단순한 문장이 아니라 루틴의 일부가 된다.

반대로 프롬프트가 개인 컴퓨터 안에만 있으면 조직 자산이 되기 어렵다.

누군가는 잘 쓰지만, 다른 사람은 모른다. 한 사람의 프롬프트는 좋아지지만, 팀의 일하는 방식은 바뀌지 않는다. 퇴사하거나 담당이 바뀌면 다시 처음부터 시작한다.

그래서 회사가 물어야 할 질문은 “프롬프트를 잘 쓰는 사람이 있는가”만이 아니다.

“그 프롬프트에 담긴 판단 기준이 조직 안에서 다시 쓰이고 고쳐지는가”다.

지식은 판단 기준으로 남는다

Nonaka(Ikujiro Nonaka)의 조직 지식창조 이론은 개인의 암묵지가 조직의 명시지로 바뀌고, 다시 개인과 조직의 행동으로 돌아오는 과정을 설명한다.[3]

AI 프롬프트도 이 관점에서 볼 수 있다.

프롬프트에는 조직의 암묵지가 들어간다. 어떤 표현을 조심해야 하는지, 어떤 고객을 먼저 봐야 하는지, 어떤 숫자를 중요하게 봐야 하는지, 어떤 상황에서 사람의 판단이 필요한지가 담긴다.

그런데 이 지식이 개인의 머릿속에만 있으면 조직에 남지 않는다. AI에게 일을 시키는 문장으로 바뀌고, 그 문장이 팀 안에서 공유되고, 실제 업무에 다시 쓰일 때 지식은 조직의 자산이 된다.

프롬프트는 지식관리의 작은 단위가 될 수 있다. 거창한 시스템이 없어도 된다. 어떤 일을 맡겼는지, 어떤 기준으로 결과를 판단했는지, 사람이 어디에서 개입해야 했는지가 남으면 된다. 이 세 가지가 남으면 AI 사용은 개인의 편의에서 조직의 학습으로 넘어갈 수 있다.

프롬프트를 보면 회사의 업무 구조가 보인다

어떤 회사는 프롬프트를 많이 만든다. 하지만 결과는 크게 달라지지 않는다.

왜 그럴까.

프롬프트가 업무 구조를 바꾸지 못했기 때문이다.

예를 들어 고객 답변 초안을 AI가 만들었다. 그런데 어떤 표현은 피해야 하는지, 어떤 약속은 하면 안 되는지, 어떤 상황에서는 상급자 확인이 필요한지 정하지 않았다. 그러면 AI는 답변을 만들지만, 책임 구조는 더 흐려질 수 있다.

또 다른 회사는 영업 제안서 초안을 AI로 만든다. 그런데 우리 회사가 반드시 지켜야 할 가격 원칙, 약속할 수 없는 납기, 강조해야 할 차별점, 최종 승인 기준이 없다. 그러면 제안서는 빨리 나오지만, 회사의 판단은 문서 안에 들어가지 않는다.

프롬프트의 품질은 문장 길이로 결정되지 않는다.

업무의 목적, 판단 기준, 책임 경계, 재사용 방식이 얼마나 분명한지로 결정된다.

결론

회사에서 AI 프롬프트는 단순한 기술 명령어가 아니다. 그렇다고 직무기술서를 대신하는 문서도 아니다.

프롬프트는 조직이 일을 어떻게 이해하고 있는지 드러내는 작은 창이다. 왜 필요한지 설명하지 못하면 프롬프트도 흐릿하다. 판단 기준이 없으면 AI 결과도 흔들린다. 책임 경계가 없으면 산출물은 빠르게 나오지만, 조직의 일하는 방식은 바뀌지 않는다.

그래서 AI 프롬프트를 너무 크게 볼 필요는 없다. 하지만 너무 작게 볼 수도 없다.

문서를 하나 더 만들자는 뜻이 아니다. AI에게 일을 시키는 문장을 통해 그 결과가 왜 필요한지, 누가 판단해야 하는지, 무엇이 반복되어야 하는지를 다시 보자는 뜻이다.

AI를 잘 쓰는 회사는 프롬프트를 많이 가진 회사가 아니다. 프롬프트를 통해 일을 더 분명하게 이해하고, 그 이해를 조직의 루틴으로 남기는 회사다.

모델이 좋아질수록 프롬프트의 잔기술은 줄어든다. 그러나 의도와 판단 기준은 사라지지 않는다.

참고문헌과 주석

1. J. Richard Hackman and Greg R. Oldham, “Motivation through the Design of Work: Test of a Theory,” Organizational Behavior and Human Performance 16, no. 2 (1976): 250-279. DOI: 10.1016/0030-5073(76)90016-7. 이 글에서는 일이 설계 대상이며, 역할과 피드백 구조가 성과와 경험에 영향을 준다는 배경으로 사용했다.

2. Martha S. Feldman and Brian T. Pentland, “Reconceptualizing Organizational Routines as a Source of Flexibility and Change,” Administrative Science Quarterly 48, no. 1 (2003): 94-118. DOI: 10.2307/3556620. 이 글에서는 루틴을 고정된 절차가 아니라 반복 수행 속에서 수정될 수 있는 조직 행동으로 보는 배경으로 사용했다.

3. Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science 5, no. 1 (1994): 14-37. DOI: 10.1287/orsc.5.1.14. 이 글에서는 개인의 암묵지가 조직의 명시지와 행동으로 전환되는 지식창조 관점의 배경으로 사용했다.