AI로 업무 도구를 직접 만들 때 필요한 전주기 역량 — 협업 대기 시간과 DevSecOps

작은 업무 도구 하나를 만든다고 해보자. 매주 여러 엑셀 파일을 합치는 일을 줄이고 싶다.

개발 담당자에게 설명하고 일정을 기다린다. 결과를 받아보니 원하는 방식과 달라 다시 설명한다. 항목 하나를 바꾸려 해도 수정 요청부터 해야 한다.

이때 “차라리 AI로 내가 끝까지 만들어보자”는 생각이 든다면 협업을 싫어해서만은 아닐 것이다. 만드는 일보다 넘겨주고 기다리는 일이 더 길어졌기 때문이다.

AI가 바꾸는 분업의 경계

Atlassian도 2026년 분석에서 코드 작성의 속도만 높여서는 부족하다고 짚었다. 불명확한 요구사항과 반복 협의 등 업무를 연결하는 과정에 병목이 남아 있다는 것이다.

AI는 그 분업의 경계를 바꿀 가능성을 보여준다.

P&G 전문가 791명이 참여한 무작위 실험에서는 AI를 쓴 개인이 AI 없이 일한 2인 팀과 비슷한 수준의 신제품 제안을 만들었다. 기술 담당자와 사업 담당자가 각자의 전문 분야에 치우치는 경향도 줄었다. 다만 신제품 아이디어 과제의 결과이지 모든 협업을 대체한다는 뜻은 아니다.

창업에서도 변화가 보인다. Carta가 집계한 신규 스타트업 중 단독 창업자 비중은 2024년 31%에서 2025년 약 36%로 늘었다. 공동창업자가 없다는 뜻이지 직원이 없다는 뜻은 아니다. 증가 원인을 모두 AI로 돌릴 수도 없다.

혼자 끝낼 수 있는 일의 범위: 전주기 역량

나는 여기서 한 사람이 끝낼 수 있는 일의 범위를 다시 보게 된다.

엑셀 취합 도구라면 필요한 기능을 정하고 AI로 만들어본다. 중복과 누락이 없는지 시험하고 접근 권한을 확인한다. 실제로 사용하면서 오류를 고치고 양식이 바뀌면 수정한다.

기획부터 제작·검증·운영·개선까지 이어가는 능력이다. 화면만 만들고 오류가 나면 손을 놓는다면 결국 다음 단계에서 다시 멈춘다.

개발·보안·운영을 전 과정에서 연결하는 DevSecOps도 본래는 협업의 방식이다. 나는 그 전주기 관점을 개인의 AI 역량에도 적용해보고 싶다.

전문 검토는 유지하되 일을 나누는 방식은 다시 설계해야

물론 전문 검토와 필요한 승인은 유지해야 한다. 작은 도구를 만드는 것과 회사의 핵심 시스템을 혼자 운영하는 것은 다르다. 회사도 안전한 실행 환경과 전문가의 지원을 제공해야 한다.

중요한 것은 모두에게 더 많은 일을 떠맡기는 게 아니다. 담당자가 자기 업무의 작은 개선을 끝까지 완성할 수 있게 하는 것이다.

AI 전환은 각자의 작업을 빨리하는 데서 끝나서는 안 된다. 일을 나누는 방식도 다시 설계해야 한다.

혼자 모든 책임을 떠안으라는 뜻이 아니다.
혼자 끝낼 수 있는 일까지 여러 사람 사이를 떠돌게 하지 말자는 뜻이다.

[출처]
Dell’Acqua 외, "「The Cybernetic Teammate」", Organization Science (2026.6.).

Carta, "「Founder Ownership Report 2026」" (2026.3.).

Atlassian, "AI와 팀 생산성 분석" (2026.1.).

GitLab, "「What is DevSecOps?」"

이 글은 리멤버에 2026. 10. 10. 처음 게시했습니다.

---

공공안전 AI 랩(PSAIL) · https://publicsafetyai.org
공공부문 AI 도입을 기술이 아니라 조직·데이터·책임의 문제로 봅니다.
『거대한 코끼리를 춤추게 하라』(박영사) → http://product.kyobobook.co.kr/detail/S000221189485
강의 문의: [강의 문의] 공지에 비밀댓글로 남겨 주세요.
이 글은 필자 개인의 견해이며, 소속 기관의 공식 입장이 아닙니다.