AI-native하게 일한다는 것: 업무를 소프트웨어처럼 다루는 능력

에이전트 워크플로를 만들다 보면, 내가 매일 하는 작업과 주변에서 AI를 쓰는 방식 사이의 간극이 자주 눈에 띈다. AI 도구는 이렇게 많이 나왔는데, 실제 업무에 깊게 녹여서 쓰는 사람은 생각보다 많지 않다. 처음에는 도구 문제라고 생각했다. 아직 불안정하고, 회사에서 막고, 보안이 애매하니까.

그런데 조사 수치를 몇 개 따라가 보면 다른 쪽이 더 커 보인다. 문제는 AI를 쓰느냐가 아니라, 어떤 방식으로 쓰느냐에 있었다.

1. 문제는 "쓰느냐"가 아니라 "얼마나 끌어들였느냐"

AI를 한 번쯤 써본 사람은 빠르게 늘고 있다. 미국 기준으로 업무에 AI를 쓴다는 응답은 이제 절반 안팎까지 왔다. 문제는 그 안의 분포다.

사용 단계	비율
써봤다 / 가끔 쓴다	절반 가까이
매일 쓴다	약 13%
워크플로에 통합했다	약 16~19%

Gallup 조사에서 미국 근로자의 매일 AI 사용률은 12~13% 수준이고, 주간 수 회까지 더해도 40% 안팎이다. Microsoft가 2만 명을 조사한 2026 Work Trend Index에서, AI 에이전트로 복합 작업을 처리하고 워크플로를 재설계한 이른바 "Frontier" 사용자는 16%에 그쳤다. Pew Research 기준으로는 업무에 AI를 쓴다는 응답 자체가 아직 21%다.

숫자의 정의는 조사마다 다르지만, 방향은 일치한다. "한 번 써봤다"와 "매일 업무 흐름에 넣었다" 사이에는 두 배가 넘는 낙차가 있다. 그러니 질문을 "AI를 쓰느냐"로 두면 절반이 보이고, "얼마나 일하는 방식 안으로 끌어들였느냐"로 바꾸면 6분의 1이 보인다. 진짜 격차는 두 번째 질문에서 열린다.

2. 한 번 써보기와 워크플로에 넣기는 다른 일이다

이 낙차는 개인만의 것이 아니다. 조직 단위에서 더 선명하게 드러난다.

McKinsey의 2025 State of AI에 따르면 조직의 88%가 이미 AI를 정기적으로 쓴다. 그런데 업무 워크플로를 근본적으로 재설계했다는 조직은 21%뿐이고, AI가 전사 EBIT에 5% 이상 기여한다는 조직은 6%에 불과하다. BCG 조사에서도 AI를 일상 업무에 깊게 통합한 조직은 13%, 나머지 56%는 여전히 파일럿 단계에 머문다. Deloitte는 37%가 "프로세스 변경 없는 표면적 사용"에 그친다고 봤다.

조직 단계	비율
AI를 쓴다	88%
워크플로를 재설계했다	21%
성과(EBIT)로 이어졌다	6%

여기서 BCG가 붙인 관찰이 핵심이다. AI 도입 노력에서 기술 구현이 차지하는 비중은 30%고, 나머지 70%는 워크플로 적응과 조직 재편이다. 도구를 켜는 일은 30%짜리 문제고, 일을 다시 짜는 일이 70%짜리 문제다. 대부분은 30%에서 멈춘다.

한 번 써보는 것은 쉽다. 회의록을 요약하고, 이메일 초안을 만들고, 아이디어를 몇 개 뽑는 일은 누구나 금방 한다. 그런데 그걸 매일의 업무 리듬 안에 상수로 넣는 순간 질문의 성격이 바뀐다. 어떤 작업을 넘길지, 어떤 작업은 내가 먼저 구조화해야 하는지, 결과를 어디까지 신뢰할지, 팀 안에서 어떻게 공유하고 검수할지. 도구 사용법의 문제가 업무 운영 설계의 문제로 옮겨간다.

3. AI-native work는 개발자적 실무를 요구한다

업무 운영을 설계하는 감각. 이걸 이미 직업으로 해온 사람들이 있다. 개발자다.

흥미로운 건, AI를 잘 쓰는 실무의 언어가 최근 몇 년 사이 개발자의 언어로 수렴했다는 점이다. Anthropic은 2025년에 이미 "프롬프트 엔지니어링"이라는 말을 "컨텍스트 엔지니어링"으로 대체했다. 좋은 질문 문장을 쓰는 문제가 아니라, 시스템 프롬프트와 도구 정의와 컨텍스트 상태와 이력 전체를 정보 아키텍처로 설계하는 문제라는 것이다. 같은 회사의 "Building Effective Agents"는 prompt chaining, routing, orchestrator-workers, evaluator-optimizer 같은 패턴을 제시하면서, "측정 가능한 성능 개선이 입증될 때만 복잡성을 추가하라"는 원칙을 붙인다. 이건 소프트웨어 엔지니어링의 문법 그대로다.

그리고 이 문법이 비개발 직군으로 번지고 있다. IBM이 인용한 조사에서 지식노동자는 하루 업무 시간의 27.4%를 AI 관련 작업에 쓰는데, 그 안을 뜯어보면 프롬프트 정제 9.2%, 출력 검증 11.3%, 모델 커스터마이징 6.9%다. 절반 이상이 검증과 조정이다. 답을 받는 시간보다, 받은 답이 맞는지 확인하고 다시 맞추는 시간이 더 크다.

이걸 역량으로 정리한 프레임워크도 나왔다. AI Fluency Framework는 네 가지 D를 든다.

역량	내용
Delegation	무엇을 AI에 넘기고 무엇을 내가 할지 나눈다
Description	원하는 것을 명세로 분명히 기술한다
Discernment	나온 결과를 판별한다
Diligence	검증하고 책임진다

작업 분해, 명세, 판별, 검증. 이름만 바꾸면 그대로 개발자의 작업 감각이다. AI를 제대로 쓰려면 질문을 잘 던지는 것만으로는 부족하다. 작업을 단위로 쪼개고, 입력과 출력을 정의하고, 컨텍스트를 준비하고, 산출물의 형태를 명시해야 한다. 결과가 틀리면 어느 단계에서 어긋났는지 역추적한다. 한 번에 완성품을 받는 게 아니라 버전 1을 만들고, 고치고, 다시 돌린다. 반복하다 절차가 안정되면 재사용 가능한 흐름으로 굳혀 자동화한다. 명세, 디버깅, 반복, 자동화. 문서 작성자도, 기획자도, 마케터도, 리서처도 점점 이 감각을 요구받는다.

4. 프롬프트에서 루프까지, 역량은 쌓인다

이 실무의 이름은 몇 년 사이 계속 옮겨왔다. 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로, 다시 하네스 엔지니어링으로, 2026년 들어 루프 엔지니어링으로. 좋은 질문을 쓰는 법에서, 맥락 전체를 설계하는 법으로, 에이전트가 돌아갈 환경을 짜는 법으로, 그 에이전트를 반복해 돌리는 루프를 설계하는 법으로 무게 중심이 이동했다. 핵심은 방향이 아니라 누적이다. 새 층이 온다고 이전 층이 사라지지 않는다. 루프를 설계하려면 여전히 좋은 프롬프트를 쓰고, 컨텍스트를 다루고, 하네스를 짤 줄 알아야 한다. 그래서 이 진화는 동시에 진입장벽이 된다. 이제는 네 겹을 함께 다뤄야 하고, 앞에서 본 6분의 1과 나머지의 간극도 결국 이 누적된 문법을 익혔느냐의 문제에 가깝다.

층이 쌓이는 방향에는 이유가 있다. 프롬프트도 컨텍스트도 하네스도 결국 "좋은 결과 하나를 잘 만드는 법"에 가까웠다. 루프는 거기서 한 걸음 더 간다. 좋은 결과가 반복해서 나오고 스스로 나아지는 순환을 만드는 일이다. 무게가 답을 잘 얻는 것에서, 답이 계속 개선되는 구조를 만드는 것으로 옮겨간다.

나는 이 변화를 의도 분류(intent classification)를 만들면서 실감했다. 예전에는 라벨링, 학습, 평가, 재라벨링이 순서대로 돌아갔다. 지금은 운영 중 나온 오분류를 놓고 에이전트가 반복해서 돈다. 정규식 후보를 만들어 개선하고, 테스트셋을 돌리고, BERT 계열 모델과 비교하고, 새 학습 데이터 후보를 만든다. 바뀌는 건 기술이 아니라 기획 방식이다. 예전에는 시도 비용이 커서 하나의 방법을 고르고 맞기를 기대했다면, 지금은 정규식 중심, BERT 중심, 하이브리드, 새 프롬프트를 동시에 만들어 같은 기준으로 돌리고 가장 좋은 걸 채택한다. 반복 개선 비용이 낮아지면 태도가 바뀐다. 확실한 방법만 고르던 자리에서, 부담 없이 여러 가설에 도전하고 실패하면 고쳐 다시 비교하는 자리로. 생산성이 조금 오르는 문제가 아니라 무언가를 만드는 방식 자체가 바뀌는 문제다.

5. 그래서 많은 사람이 멈춘다

여기서 멈추는 이유는 AI 사용이 어려워서가 아니다. 이 방식이 기존 업무 습관과 근본적으로 다르고, 그 차이가 사람을 불편하게 만들기 때문이다.

지금까지의 업무는 암묵지 위에서 굴러갔다. 대충 맥락을 말하고, 회의에서 조율하고, 문서를 쓰면서 생각을 정리해도 빈 곳은 사람이 알아서 메웠다. 그런데 AI와 일하려면 그 암묵지를 밖으로 꺼내 명시해야 한다. 내가 원하는 것, 하지 말아야 할 것, 판단 기준, 예외 조건, 산출물 형식까지. 사람 사이에서는 생략해도 통하던 것들이 AI 앞에서는 전부 입력으로 정의되어야 한다. 이 과정은 번거롭고, 동시에 드러낸다. 요구사항을 실은 명확히 생각해두지 않았다는 것, 검수 기준이 없었다는 것, "알아서 잘"에 기대고 있었다는 것이 노출된다.

그 불편함은 수치로도 잡힌다. AI 사용을 숨기는 현상이 광범위하다. Ivanti 조사에서 생성형 AI를 쓰는 직원의 32%가 그 사실을 고용주에게 숨겼고, 이유로는 경쟁 우위 유지(36%), 일자리 상실 우려(30%), 그리고 역량을 의심받을까 하는 두려움(27%)이 꼽혔다. Microsoft는 공식 승인 없이 AI를 쓰는 이른바 "섀도우 AI" 사용자가 34%라고 봤고, Glean의 Work AI Index에서는 고성과자의 54%가 승인되지 않은 도구나 비규준 방식으로 AI를 쓴다고 답했다.

주목할 지점은 저항의 성격이다. 이건 AI가 싫어서 안 쓰는 저항이 아니다. 쓰면서도 숨기는 저항이다. AI를 쓴다고 밝히면 무능해 보이거나 부정행위처럼 비칠까 봐, 혹은 내 일이 그만큼 쉬웠다는 게 드러날까 봐 숨긴다. 그래서 어떤 사람에게 AI는 생산성 도구라기보다 자기 사고의 해상도를 재는 장치처럼 작동한다. 좋은 프롬프트를 못 쓰는 게 문제가 아니라, 좋은 요청을 구성할 만큼 생각이 정리돼 있지 않았다는 걸 확인하게 되는 것이다.

6. 프롬프트 스킬이 아니라, 업무를 소프트웨어처럼 다루는 능력

이렇게 보면 AI-native 역량을 "프롬프트 스킬"이라고 부르는 건 너무 좁다. 프롬프트는 그 능력의 표면일 뿐이다.

실제로 필요한 건 업무를 소프트웨어처럼 다루는 능력이다. 일의 입력과 처리와 출력을 나누고, 검수와 배포와 회고의 루프를 설계하는 감각. 그걸 코드 없이 수행하는 능력이다. 코드를 짜야 한다는 뜻은 아니다. 다만 사고의 형태가 개발자의 것을 닮아간다. 문제를 구조화하고, 절차를 만들고, 실패를 관찰하고, 재현 가능한 단위로 나누고, 그 단위를 다시 연결한다.

여기서 흔히 나오는 반문이 있다. 나는 개발자가 아닌데 왜 이렇게까지 해야 하나, AI가 알아서 해주는 것 아니었나. 그런데 방향은 반대인 것 같다. AI가 좋아질수록 사람에게 요구되는 태도는 더 개발자적이 된다. AI가 처리하는 영역은 넓어지지만, 무엇을 시킬지, 어떤 기준으로 받을지, 어떤 흐름에 배치할지는 여전히 사람이 설계해야 하기 때문이다. 자동화가 늘어날수록 설계의 몫이 사람 쪽으로 응축된다.

7. 격차는 개인이 아니라 운영모델에서 갈린다

그렇다면 이 격차는 개인의 의지 문제인가. 데이터는 그렇지 않다고 말한다.

BCG 조사에서 직원의 72%는 자기 일에 필요한 스킬이 바뀌었다고 느끼지만, 적절한 업스킬링을 받았다는 응답은 36%에 그친다. 절반은 변화를 감지하고도 건너갈 다리를 받지 못한 셈이다. 그리고 그 다리를 놓은 조직과 아닌 조직의 결과는 갈린다. AI를 기존 워크플로에 임베드한 조직은 채택률 60~80%를 달성한 반면, 도구만 스탠드얼론으로 던져둔 조직은 30~40%에서 멈춘다는 분석이 있다.

즉 개인에게 "개발자처럼 생각하라"고 요구하는 것만으로는 격차가 닫히지 않는다. 무엇을 AI에 넘기고, 어떻게 검증하고, 어떤 흐름으로 재사용할지를 조직이 워크플로 수준에서 설계해 줄 때 개인의 태도 전환도 따라온다. 태도는 개인의 것이지만, 그 태도가 자랄 구조는 운영모델의 것이다.

8. 정리

AI-native하게 일한다는 것은 더 빠르게 쓰거나 더 많이 뽑는 일이 아니다. 자신이 하던 일을 입력과 출력과 검수가 정의된 절차로 다시 쓰는 일이다.

층위	표면	실제 요구
개인	프롬프트를 잘 쓴다	작업을 분해하고 명세·검증·반복으로 다룬다
실무	좋은 답 하나를 얻는다	답이 계속 나아지는 루프를 설계한다
조직	AI 도구를 도입한다	워크플로를 재설계하고 검증 루프를 심는다
격차	AI를 아느냐 모르느냐	업무를 AI가 작동할 형태로 재구성했느냐

수치가 반복해서 말하는 건 하나다. 도입은 절반, 워크플로 통합은 6분의 1. 그 사이의 간극이 앞으로 몇 년의 진짜 격차다. 그리고 그 간극을 건너는 데 필요한 건 더 좋은 도구가 아니라, 비개발자에게도 개발자의 작업 감각을 요구하는 새로운 업무 문법이다.

그리고 이 문법의 끝은 기술이 아니라 결과물이다. 분류기의 정확도를 몇 퍼센트 올리는 일이 결국 더 나은 대화를 설계하는 일로 이어지듯, AI-native하게 일한다는 것도 결국 더 나은 산출물, 더 나은 제품, 사용자에게 실제로 닿는 가치로 이어진다. 높은 정확도의 모델이라도 대화를 이해하지 못하면 좋은 상담이 되지 않는다. 그러니 마지막 질문은 늘 도구 바깥에 있다. 도구를 얼마나 잘 다루느냐가 아니라, 그 끝에서 무엇이 실제로 나아졌느냐. 결국 그것이 기준이다.

나도 워크플로를 하나씩 만들면서 이 문법을 더듬거리며 익히는 중이다. 그리고 매번 제일 오래 막히는 건 프롬프트를 다듬는 단계가 아니라, 내가 무엇을 원하는지 나부터 명세로 옮기는 첫 단계다. 결국 AI를 잘 쓰는 문제는 자꾸 그 앞의 문제로 돌아온다. 나는 내 일을 얼마나 분명하게 알고 있었나.