AI 시대의 핵심. 기술 기획.
난이도: 입문 — 기술과 사업의 우선순위를 고민하는 실무자를 위한 글입니다. 개발 경험 없이도 읽을 수 있습니다.
AI로 시제품을 빠르게 만들었다고 가정해 보겠습니다. 화면도 있고 기능도 작동합니다. 그런데 공개하려니 질문이 남습니다. 누가 계속 쓸지, 기존 업무보다 나은지, 틀린 답을 내놓으면 누가 처리할지 확인해야 합니다.
구현 속도와 좋은 투자 결정은 별개입니다. 만들 수 있는 선택지가 늘어나도 인력과 예산은 제한돼 있습니다. 기술 기획은 이 조건에서 무엇을 시험하고 어디에 투자할지 구체화해야 합니다. AI가 구현을 돕는 환경에서 이 판단이 더 중요해진다는 것이 이 글의 주장입니다.
자료 확인: 2026년 11월 9일(KST). 직무 정의와 업무 방식은 이 글의 실무적 제안이며 조직마다 다를 수 있습니다. 사례는 모두 가상으로, 특정 개인의 경험이나 기업 내부 정보를 옮긴 것이 아닙니다. 연구 결과는 해당 시점과 조건에 한정합니다.
1. 기술 기획이란?
이 글에서 기술 기획은 기술로 해결할 문제를 고르고, 대안과 제약을 비교해, 무엇을 검증하고 어디에 투자할지 결정하도록 돕는 일입니다. 기술 소개를 넘어 실행 여부와 범위를 판단할 수 있게 만드는 역할입니다.
출발점은 기술 이름보다 문제입니다. “생성형 AI를 도입하자”보다 “상담원이 자료를 찾는 동안 고객이 기다리는 시간을 줄이자”가 검색 개선, 문서 정비, AI 도입을 비교하기에 적합합니다. 기술 기획이 반드시 별도 직책일 필요도 없습니다. 개발자나 제품 책임자가 함께 수행할 수 있습니다.
유관 직무와의 경계는 다음처럼 질문의 초점으로 나눠 볼 수 있습니다. 보편적인 인사 기준이 아닌 협업을 위한 예시입니다.
| 역할 | 주로 답하려는 질문 |
|---|---|
| 사업 기획 | 어떤 고객과 시장에서 어떤 수익·비용 구조를 만들 것인가? |
| 제품 기획·PM | 어떤 사용자 문제를 어떤 경험과 우선순위로 풀 것인가? |
| 아키텍트·개발자 | 어떤 구조와 구현으로 요구 품질을 충족할 것인가? |
| 프로젝트 관리 | 합의한 범위를 일정과 자원 안에서 어떻게 실행할 것인가? |
| 기술 기획 | 어떤 기술적 선택을 왜 지금 검증하거나 투자해야 하는가? |
실제로는 이 질문들이 겹칩니다. 기술 기획자가 사업 가치를 혼자 결정하거나 개발자의 기술 판단을 대신해서는 안 됩니다. 각 담당자의 근거를 연결하고, 의견이 다를 때 무엇을 더 확인할지 정하는 역할에 가깝습니다.
2. 기술 기획은 어떤 일을 하는가
가상의 고객지원 서비스가 상담 대기 시간을 줄이려 합니다. AI 상담봇 도입 제안이 나왔지만 아직 해결책은 정하지 않았습니다.
먼저 문의 유형과 처리 과정을 조사합니다. 답변 작성이 느린지, 문서가 흩어져 있는지, 담당 부서의 승인을 기다리는지 구분합니다. 승인 대기가 원인이라면 답변 생성만 빨라져도 전체 대기 시간은 크게 줄지 않을 수 있습니다. 이 단계에서는 문제 정의와 현재 상태를 측정할 계획이 필요합니다. 측정하지 않은 효과를 숫자로 채우지 않습니다.
그다음 대안을 비교합니다. 검색 개선, 문서 정비, 상담원용 답변 초안, 고객에게 직접 답하는 상담봇을 같은 기준에 놓습니다. 새 기능을 만들지 않는 선택도 포함합니다. 목표 달성 가능성뿐 아니라 연동 비용, 오류의 영향, 유지보수 부담을 따져야 합니다.
선택한 대안은 작은 실험으로 검증합니다. 문서로 유용한 답을 만들 수 있다는 가설과, 상담원이 검토를 마친 뒤에도 시간이 절약된다는 가설은 다릅니다. 가상 사례에서는 개인정보를 제거한 승인된 평가 자료로 답변과 오류를 확인한 뒤 제한된 업무 실험을 설계할 수 있습니다. 실제 고객 자료나 응답 노출에는 별도 권한과 보호 조치가 필요합니다.
실험 전에 성공·중단 기준을 합의합니다. 검토·수정까지 포함한 처리 시간, 재문의, 중요한 정책의 오안내를 함께 봅니다. 결과를 보고 유리한 지표만 고르지 않도록 비교 방식도 미리 정해야 합니다.
마지막으로 결과를 투자 결정에 연결합니다. 확대할지, 문서부터 정비할지, 추가 검증하거나 멈출지 정합니다. 선택 이유와 남은 불확실성, 담당자, 다음 검토 시점을 남겨야 다음 사람이 같은 논의를 반복하지 않습니다. 운영에 들어간다면 문서 갱신과 비용·장애 대응을 맡을 사람도 정해야 합니다.
3. AI 시대, 기술 기획이 중요해진 이유와 역할 변화
구현 속도와 전체 성과를 나눠 봐야 합니다
AI가 항상 생산성을 높인다고 전제할 수는 없습니다. NBER의 2023년 워킹페이퍼는 고객지원 상담원 5,179명의 자료에서 AI 도구 접근이 시간당 해결 건수로 측정한 생산성을 평균 14% 높였지만, 숙련도가 높은 상담원에게서는 영향이 작았다고 보고했습니다.[1]
다른 조건의 연구도 있습니다. METR의 2025년 실험에서는 자신이 기여하던 오픈소스 저장소에서 일하는 숙련 개발자들이 당시 AI 도구를 사용할 때 작업에 19% 더 오래 걸렸습니다.[2] 다만 METR은 현재 원문에 이 결과가 오래됐으며 최신 모델의 영향을 나타내지 않는다고 명시합니다.[2]
2026년 후속 설명에서는 참여자 등의 선택 편향과 시간 측정 문제로 새 실험에서 현재 생산성 효과를 신뢰성 있게 추정하기 어렵다고 밝혔습니다.[3] 연구진은 이전보다 가속 효과가 커졌을 가능성을 보지만 증가 폭에 대한 근거는 매우 약하다고 설명합니다.[3]
이 연구들은 업무·도구·시점이 달라 수치로 승패를 가릴 수 없습니다. 과거 결과를 오늘의 모든 업무에 적용해서도 안 됩니다. 기획에 가져올 교훈은 자기 업무에서 검토와 재작업을 포함한 효과를 측정해야 한다는 것입니다.
선택지가 늘어도 운영 자원은 제한됩니다
더 많은 시제품을 만들 수 있는 팀이라도 운영 인력까지 함께 늘어나는 것은 아닙니다. 가상 고객지원 팀이 요약·번역·자동 응답을 모두 시연할 수 있어도 한꺼번에 운영할 이유는 없습니다. 대기 시간의 원인이 자료 검색이라면 그 부분부터 시험하는 편이 타당할 수 있습니다.
이 조건에서는 구현 가능한 기능을 늘리는 것보다 자원을 쓸 대상을 좁히는 판단이 중요해집니다. 이는 역할의 중요성에 대한 논지이지, 기술 기획 직책의 채용이 늘었다거나 모든 조직이 해당 부서를 확대해야 한다는 주장이 아닙니다.
운영 검토를 시연 이후로 미루기 어렵습니다
문서 변경이 답변에 반영되는지, 권한 밖의 자료를 보여주지 않는지, 장애 때 기존 업무로 돌아갈 수 있는지 검토해야 합니다. 답변 품질과 비용을 누가 점검할지도 필요합니다.
NIST의 AI RMF Playbook은 설계·개발·배포·사용에 신뢰성 고려를 반영하기 위한 자율적 지침이며 Govern·Map·Measure·Manage의 네 기능을 다룹니다.[4] 법적 의무나 인증 요건을 제시하는 자료는 아닙니다.
이 글에서는 그 취지를 적용해 위험·운영 검토를 초기 대안 비교에 넣을 것을 제안합니다. 외부 AI 서비스라면 데이터 처리 조건, 모델 변경 시 재평가, 서비스 종료 시 대안도 검토 대상입니다. 기술 기획자가 모두 심사하는 대신 보안·법무·운영 담당자가 판단할 질문과 시점을 연결해야 합니다.
4. AI 시대 기술 기획자에게 필요한 역량
기술 이해
모든 모델을 구현할 필요는 없지만 선택한 방식의 작동 조건과 한계는 이해해야 합니다. 가상 상담원 도구의 답이 틀렸다면 문서가 없었는지, 잘못 검색했는지, 맞는 문서를 찾고도 답을 잘못 만들었는지 구분해야 다음 실험이 달라집니다. 기술 이해는 개발자에게 정답을 지시하기보다 원인과 검증 방법을 함께 논의하기 위한 지식입니다.
사업 판단
검색 시간이 줄어도 답변 확인이 길어졌다면 검색 시간만으로 비용 절감을 주장하면 안 됩니다. 도구 사용료 외에 문서 정비, 연동, 품질 점검에 드는 일도 비교해야 합니다. 절약한 시간이 고객의 불편을 줄이거나 더 중요한 업무에 쓰이는지 확인하고, 어떤 조건이면 투자할 만한지 설명할 수 있어야 합니다.
실험과 데이터 검증
쉬운 질문만 평가하면 운영에서의 실패를 놓칠 수 있습니다. 가상 사례의 평가 자료에는 답이 없는 질문이나 최근 정책이 바뀐 질문도 포함할 필요가 있습니다. 평균 점수가 좋아도 중요한 유형에서 반복해서 실패하면 범위를 제한해야 합니다. 비교 자료와 사람의 개입, 제외한 사례를 기록하고, 결과가 나쁘면 기준을 바꾸는 대신 대안을 다시 검토할 수 있어야 합니다.
소통과 의사결정
개발자는 유지보수를, 현업은 업무 적합성을, 보안 담당자는 데이터와 권한을 우선해서 볼 수 있습니다. “상담봇을 출시할 것인가”를 한 번에 묻기보다 “상담원용으로만 시험할 것인가”, “어떤 문의를 제외할 것인가”, “어떤 결과면 확대할 것인가”로 나누면 합의할 대상이 구체적입니다. 각 결정의 책임자와 이견, 재검토 조건도 남깁니다.
AI로 대안이나 실험용 코드의 초안을 만들 수는 있습니다. 그래도 설명에 실제 자료가 연결되는지, 제약이 빠지지 않았는지 확인할 책임은 남습니다. 결과를 그대로 전달하기보다 근거를 대조하고 결정 이유를 설명하는 능력이 필요합니다.
5. 결론: 기획서에서 실행과 검증으로
AI로 구현 속도를 높일 수 있어도 무엇을 만들 가치가 있는지와 실제로 운영할 수 있는지는 별도로 판단해야 합니다. 구현 가능한 선택지가 많아질수록 기술 기획은 제한된 자원을 어디에 투자할지 결정하고, 그 판단을 실험으로 확인할 수 있게 해야 합니다.
기획서는 여전히 필요합니다. 다만 문제와 대안, 불확실한 가정, 실험의 수용·중단 기준을 적은 뒤 누가 무엇을 시험하고 결과에 따라 어떤 결정을 내릴지까지 이어져야 합니다. 가상 고객지원 사례에서도 전면 출시보다 문서를 정비하고 상담원용 도구부터 시험하는 선택이 가능합니다.
기술 기획의 성과는 채택한 기술의 수보다 투자 전에 중요한 불확실성을 줄였는지, 그 결과로 계속할 일과 중단할 일을 실제로 정했는지로 평가하는 편이 낫습니다.
Sources
[1] NBER · Generative AI at Work · 2023년 4월 발행 · 2023년 11월 개정 워킹페이퍼
[2] METR · Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity · 2025년 7월 10일 발표 · 현재 원문에 노후 경고 표시
[3] METR · We are Changing our Developer Productivity Experiment Design · 2026년 2월 24일 발표
[4] NIST · NIST AI RMF Playbook · 2026년 6월 10일 페이지 수정 · 자율적 지침