수탁 개발(受託開発)이나 SES, 프리랜서 참여 그 자체를 부정하고 싶은 것은 아닙니다.

다만, AI를 도입했을 때 정보 단절이나 권한 단절이 더욱 눈에 띄게 되지 않을까 하는 이야기입니다.

지난번에는 AI 시대에는 기능별로 사람을 배정하는 것만으로는 어려워지지 않을까 하는 이야기를 썼습니다.

이번에는 일을 맡기는 쪽(발주 측)의 이야기입니다.

AI를 사용한 개발 이야기에서는 아무래도 개발자 측의 사용법에 주목이 쏠리기 쉽습니다.

어떤 AI 도구를 사용할 것인가.

프롬프트(Prompt)를 어떻게 작성할 것인가.

어디까지 AI에게 맡길 것인가.

리뷰(Review)를 어떻게 할 것인가.

물론 그것들은 중요합니다.

하지만 수탁 개발이나 SES 현장에서는 받는 쪽(수주 측)만 AI를 잘 사용한다고 해서 한계가 있다고 느낍니다.

왜냐하면, AI가 판단하기 위한 전제는 일을 맡기는 쪽에서 전달되는 정보에 크게 의존하기 때문입니다.

일을 맡기는 쪽이 배경이나 판단 기준을 전달하지 못한 채, "이 기능을 만들어 주세요"라고 의뢰해도 AI는 진정한 의미에서 판단할 수 없습니다.

이 기사에서는 AI 시대에 일을 맡기는 쪽이 무엇을 전달할 필요가 있는지 생각해 보겠습니다.

개발에서는 사양서(仕様書)가 전달됩니다.

화면 목록, 항목 정의, API 사양, DB 정의, 처리 플로우(Flow) 등입니다.

이것들은 물론 필요합니다.

사양이 없으면 구현할 수 없습니다.

다만, AI를 사용하며 느끼는 것은 사양만으로는 판단할 수 없는 경우가 많다는 점입니다.

예를 들어, 사양서에는 다음과 같이 적혀 있다고 가정해 봅시다.

신청 상태가 승인됨인 경우, 편집 버튼을 숨김 처리한다.

이 한 문장만으로도 구현은 가능합니다.

하지만 설계 판단을 하기 위해서는 조금 더 배경이 필요해집니다.

왜 승인되면 편집할 수 없는가.

반려(差し戻し)는 있는가.

승인 후에 수정하고 싶은 경우는 어떻게 하는가.

관리자는 편집할 수 있는가.

기존 운용에서는 어떻게 하고 있는가.

감사(Audit)상의 이유가 있는가.

이러한 배경이 없으면 AI는 사양의 문구 그대로 구현하게 됩니다.

그것으로 충분한 경우도 있습니다.

하지만 업무상의 판단이 필요한 장면에서는 배경이 없으면 위험합니다.

AI는 배경 정보가 많을수록 사용하기 쉬워집니다.

예를 들어, 단순히 "편집 버튼을 숨겨 주세요"라고 말하는 것보다 다음과 같이 전달하는 편이 판단하기 쉬워집니다.

승인된 데이터는 감사 대상이 되므로, 원칙적으로 편집 불가능하게 합니다.
단, 승인 후에 오류가 발견된 경우에는 관리자가 반려하여 재신청하는 운용 방식입니다.
따라서 화면에서는 일반 사용자에게 편집 버튼을 보여주지 말고, 관리자에게는 반려 조작만 표시해 주세요.

이 정도까지 적혀 있으면 AI는 상당히 판단하기 쉬워집니다.

단순한 화면 제어가 아니라, 업무상 왜 그렇게 하는지를 알 수 있기 때문입니다.

AI는 문장을 바탕으로 추론(Inference)합니다.

따라서 "무엇을 만드는가"뿐만 아니라 "왜 그렇게 하는가"가 있으면 제안의 질이 달라집니다.

이는 인간 개발자도 마찬가지지만, AI의 경우에는 특히 전제 정보의 영향이 크다고 느껴집니다.

일을 맡기는 쪽은 배경을 알고 있는 경우가 많습니다.

왜 그 기능이 필요한가.

어떤 업무가 곤란을 겪고 있는가.

무엇을 바꿔서는 안 되는가.

과거에 어떤 실패가 있었는가.

하지만 그것을 모두 언어화하여 전달하고 있다고는 단정할 수 없습니다.

맡기는 쪽 입장에서는 너무 당연해서 설명에서 빠지는 경우가 있습니다.

반대로 받는 쪽은 사양서에 적혀 있는 것이 전부라고 생각해 버릴 때가 있습니다.

이 격차는 AI를 사용해도 남습니다.

오히려 AI는 전달받은 정보를 바탕으로 자연스럽게 보완해 버리기 때문에, 배경이 누락되었다는 사실을 알아차리기 어려워질 수도 있습니다.

일을 맡기는 쪽이 "보통은 알겠지"라고 생각하는 것일수록 AI에게도 인간에게도 명시하는 편이 좋을지도 모릅니다.

받는 쪽에게도 질문할 책임은 있습니다.

사양이 모호하다면 확인한다.

예외 케이스를 묻는다.

업무 플로우(Flow)를 확인한다.

AI에게 확인 사항을 뽑아내게 한다.

이것은 중요합니다.

다만, 받는 쪽의 질문력만으로는 한계가 있습니다.

왜냐하면 받는 쪽은 무엇을 모르는지조차 모르는 경우가 있기 때문입니다.

s사양서에 적혀 있지 않은 업무 배경.

현장에서는 당연한 운용.

과거에 실패했던 설계.

고객사의 조직 내 사정.

장래에 예정하고 있는 변경.

이러한 정보는 받는 쪽에서 질문하기 어려울 때가 있습니다.

AI에게 확인 사항을 내보내게 해도, 질문 대상에게 전달되지 않으면 의미가 없습니다.

답변이 짧게 돌아올 뿐 배경이 없다면, 다시 해석이 어긋날지도 모릅니다.

따라서 AI 시대에는 받는 쪽이 질문할 뿐만 아니라, 맡기는 쪽이 배경을 전달하는 것도 중요해질 것이라고 생각합니다.

일을 맡기는 쪽이 배경을 알고 있다면, 그것을 AI에게 전달할 수 있는 형태로 남겨두는 것이 좋을 것입니다.

예를 들어, 다음과 같은 정보입니다.

• 업무의 목적
• 현재의 고민 사항
• 기존 운용 방식
• 중요한 예외 케이스
• 변경해서는 안 되는 것
• 과거의 판단 이유
• 향후 확장 예정
• 미결 사항
• 판단자

이것은 깔끔한 사양서(Specification)가 아니어도 괜찮다고 생각합니다.

처음에는 불렛 포인트(Bullet point) 형태든, 의사록이든, 메모든 상관없습니다.

중요한 것은 AI나 개발자가 읽을 수 있는 장소에 남아 있는 것입니다.

배경이 문서(Document)로 남아 있다면, AI에게 읽혀서 확인 사항을 뽑아낼 수 있습니다.

설계안을 비교할 수 있습니다.

구현 후의 리뷰에도 사용할 수 있습니다.

반대로, 배경이 구두로만 전달되거나 일부 사람의 머릿속에만 있다면 AI에게는 전달되지 않습니다.

AI 시대의 의뢰에서는 '만드는 것'뿐만 아니라 '판단 기준'도 함께 전달하는 것이 좋다고 느낍니다.

예를 들어, 단순히 다음과 같이 의뢰하는 것이 아니라,

사용자 목록 화면에 검색 조건을 추가해 주세요.

다음과 같이 판단 기준도 덧붙입니다.

사용자 목록 화면에 부서 검색을 추가해 주세요.
이 화면은 관리자가 일상적으로 사용하기 때문에 조작 속도를 우선시합니다.
검색 조건은 너무 많아지면 사용하기 불편해지므로, 초기 표시에서는 주요 조건만 보여주세요.
...

이 정도까지 되어 있으면, AI는 구현뿐만 아니라 설계상의 판단도 하기 쉬워집니다.

무엇을 우선할 것인가.

무엇을 이번에는 하지 않을 것인가.

어디를 향후의 변경 사항으로 남겨둘 것인가.

이러한 판단 기준이 없으면, AI는 일반적으로 좋아 보이는 구현을 내놓습니다.

하지만 그것이 해당 현장에 좋은 구현인지는 알 수 없습니다.

일을 맡기는 쪽이 모든 것을 처음부터 결정할 수 있는 것은 아닙니다.

미결 사항이 있는 것은 자연스러운 일입니다.

중요한 것은 미결 사항을 미결 사항으로서 전달하는 것이라고 생각합니다.

예를 들어, 다음과 같이 작성합니다.

미결 사항:
- 승인 후 수정을 허용할지 여부는 미결
- 관리자의 권한 범위는 확인 중
...

이렇게 적혀 있으면 AI도 "이 부분은 확정되지 않았다"라고 인식하기 쉬워집니다.

반대로 미결 사항이 숨겨져 있으면, AI는 임시 전제로 구현을 진행해 버리는 경우가 있습니다.

임시 구현이 필요한 경우도 있습니다.

다만, 그 경우에도 "이것은 임시입니다"라고 알 수 있게 해두는 편이 좋습니다.

AI 시대에는 확정된 것뿐만 아니라, 확정되지 않은 것을 명시하는 것도 중요해지지 않을까요.

AI를 사용하는 개발에서는 개발자만이 AI에 정통하면 되는 것은 아니라고 생각합니다.

일을 맡기는 쪽에도 어느 정도의 AI 리터러시(AI Literacy)가 필요하게 됩니다.

여기서 말하는 AI 리터러시는 프롬프트(Prompt)를 능숙하게 작성할 수 있는 것만을 의미하지 않습니다.

AI가 무엇을 모르는가.

AI에게 무엇을 전달해야 판단하기 쉬운가.

어떤 정보가 빠지면 위험한가.

AI가 그럴싸하게 보완해 버리는 경우가 있는가.

이러한 감각입니다.

발주 측이나 상류 공정 측이 이러한 감각을 가지고 있으면 의뢰하는 방식이 달라집니다.

"이 기능을 만들어 주세요"라고만 하는 것이 아니라, "배경은 이렇습니다", "판단 기준은 이렇습니다", "미결 사항은 여기입니다"라고 전달할 수 있게 됩니다.

이것은 AI 시대의 수탁 개발에서 상당히 중요해질 것이라는 느낌이 듭니다.

AI를 사용한 개발에서는 받는 쪽의 사용법이 주목받기 쉽습니다.

하지만 AI가 판단하기 위한 전제는 일을 맡기는 쪽에서 전달되는 정보에 크게 의존합니다.

사양만으로는 부족한 경우가 있습니다.

배경, 목적, 제약, 판단 기준, 미결 사항이 필요할 때가 있습니다.

일을 맡기는 쪽이 그것들을 전달하지 못한 채 받는 쪽만 AI를 사용한다면, 잘 풀리지 않는 장면은 계속 남을 것이라고 생각합니다.

AI는 전달되지 않은 배경을 알아서 올바르게 이해하는 것이 아닙니다.

부족한 정보를 자연스럽게 보완하기도 하지만, 그 보완이 반드시 옳다는 보장은 없습니다.

그렇기에 AI 시대에는 일을 맡기는 쪽의 정보 전달 방식도 바꿀 필요가 있다고 생각합니다.

"무엇을 만드는가"뿐만 아니라 "왜 만드는가"를 전달한다.

"어떻게 동작하는가"뿐만 아니라 "무엇을 우선하는가"를 전달한다.

"결정된 것"뿐만 아니라 "아직 결정되지 않은 것"을 전달한다.

AI를 잘 활용하기 위해서는 받는 쪽의 프롬프트 능력뿐만 아니라, 내는 쪽의 전제 공유 능력도 요구되지 않을까요.