「AI에게 일을 맡기는 능력」으로부터 단련하기 — AI 시대에 현장에 투입되는 신입을 위한 사고 실험

AI 시대에 현장에 투입된다면, 코드를 작성하는 것 자체보다 먼저 **「AI에게 일을 맡기는 능력」**을 의식적으로 단련하고 싶다는 사고 실험입니다 (미래 예측이 아닙니다). - 현장에서 몸에 익힌 패턴(차분 설계(Difference Design)·리뷰·외주 조정·현장 도입·가시화)이 그대로 AI 협업 방식에 유효하다는 회고입니다. - 연령대에 따라 강점은 다르지만, 「경험을 AI에게 전달할 수 있는 형태로 변환하는」 구조는 동일하다는 정리입니다.

현장 중심의 업무(네트워크 검증, 설계 리뷰, 벤더 조정, 거점 구축, 모니터링, 업무 플로우 정리 등)를 오랫동안 해왔습니다. 코드를 쓰는 것보다, 사양을 분해하고, 전제와 제약을 맞추고, 검증하여 인계하는 것이 업무의 중심에 가까웠다는 감각이 있습니다.

업무의 휴면기에 루틴한 업무 효율화를 AI와 시도해 볼 여유가 생겼을 때, 지금까지 당연하게 해왔던 일들이 그대로 AI에게 전달하는 방식과 겹쳐졌습니다. 후배에게 설명할 자료로도 쓰일 것 같아, 우선 스스로 사용해 보면서 이 글에 정리하고 있습니다. 단순한 툴 제작이 아니라, 경험을 AI에게 전달할 수 있는 형태로 변환하는 훈련이 되고 있다는 감각입니다.

이것들은 AI 시대가 되어서야 처음 중요해진 것이 아니라, 일을 맡기기 시작하면 갑자기 표면으로 드러나는 타입의 능력이라고 생각합니다. 지난번 'AI 소담 — 끝나지 않는 대화의 구조'보다 조금 더 무거운 정리입니다.

**「AI에게 일을 맡기는 능력」**은 프롬프트 기술이 아니라, 다음의 7가지를 세트로 다룰 수 있는 것입니다.

업무를 분해하기 / 입력과 출력을 결정하기 / 제약을 전달하기 / 판단 기준을 결정하기 / 검증 방법을 준비하기 / 나온 결과물을 받아 확인하기 / 마지막으로, 사람에게 전달할 수 있는 형태로 정리하기

실제로 이 7가지 항목에 따라 "이 순서대로 하나씩 작업을 진행해 주세요"라고 AI에게 지시하는 것만으로도 작업이 상당히 수월해집니다. 제1부에서는 왜 제가 그런 결론에 도달했는지, 저의 현장 경험을 통해 되돌아봅니다.

첫 커리어는 통신 인프라 계열의 현장이었습니다.

네트워크 장비 검증, 절차서 작성, 서비스 접속, 설계 리뷰.

큰 조직 안에서 여러 회사가 관여하는 하청 구조의 현장에 들어가, 기존 서비스를 유용하면서 새로운 서비스를 어떻게 네트워크 기능으로 구현할지를 고민했습니다.

여기서 단련된 것은 단순히 라우터나 스위치에 대한 지식이 아닙니다.

가장 컸던 것은, **「기존의 메커니즘을 보고, 차분(Difference)을 생각하고, 이번에 필요한 형태로 떨어뜨리는 것」**이었습니다.

신규 서비스라고 해서 모든 것을 제로 베이스에서 만드는 것은 아닙니다.

기존의 패킷 처리, 기존의 경로, 기존의 설계 사상, 기존의 운용을 보고, 무엇을 유용할 수 있고 어디만 다른지를 생각합니다.

이것은 지금 AI에게 일을 맡길 때도 그대로 사용하고 있습니다.

AI에게 "전부 만들어줘"라고 부탁하기보다,

기존의 이 메커니즘을 유용할 것 / 이번에 다른 점은 여기 / 입력은 이것 / 출력은 이렇게 / 판정 기준은 이것 / 검증용 샘플은 이것

이라고 전달하는 편이 훨씬 안정적입니다.

커리어를 통해 수행해 온 설계 리뷰 경험도 컸습니다.

베테랑의 리뷰를 받으면 단순히 "맞는지 틀린지"뿐만 아니라, **「상대방에게 전달되는 형태인가」**를 보게 됩니다.

또한, 신입의 리뷰를 수행하면 리뷰의 전제 조건을 맞추는 것의 중요성을 깨닫게 됩니다.

정보가 부족하면 당연히 안 됩니다. 하지만, 정보가 너무 많아도 안 됩니다.

리뷰하는 쪽은 모든 배경을 다 쫓고 싶은 것이 아닙니다.

판단에 필요한 정보, 리스크, 차분, 전제, 확인해 주었으면 하는 점을 보고 싶어 합니다.

이 **「정보를 깎아내는 능력」**은 AI 협업에서도 상당히 중요합니다.

AI에게는 대량의 정보를 전달할 수 있습니다. 하지만, 대량으로 전달할 수 있는 것과 잘 전달하는 것은 다릅니다.

인간에게 리뷰를 받을 때와 마찬가지로, AI에게도 다음과 같이 전달하는 것이 좋습니다.

배경 / 목적 / 제약 / 입력 / 출력 / 판단 기준 / 건드려도 되는 범위 / 건드리면 안 되는 범위 / 검증 방법

이것은 프롬프트 기술이라기보다, 일을 전달하는 방식입니다.

현장에서는 네트워크 장비나 서버 등의 판매 회사와의 조정도 많았습니다.

스터디회라는 형태로 설계 내용을 조율하거나, 상대방의 이해도에 맞춰 자료를 만들거나, 우리의 요구가 전달될 수 있도록 전제를 정돈하는 일.

이 경험은 AI를 사용할 때도 상당히 유효합니다.

저는 AI를 마법의 상자라기보다 **「외주 엔지니어 (Outsourced Engineer)」**에 가까운 감각으로 다루고 있습니다 (별도 기사 「AI를 『외주 엔지니어』로 다루는 이야기」에서도 정리하고 있습니다).

외주 엔지니어에게 일을 맡길 때, 보통은 다음과 같이 합니다.

무엇을 만들고 싶은지 설명한다기존 자료를 전달한다제약 사항을 전달한다결과물의 형식을 지정한다도중에 리뷰한다필요하다면 재작업 (rework)을 시킨다마지막으로 인수 확인을 한다

AI에게도 똑같은 일을 합니다. 다른 점은 비용과 시간의 감각입니다.

인간 외주처라면, 몇 번이고 재작업을 시키면 비용이 불어납니다. 상대의 시간도 빼앗게 됩니다.

AI의 경우, 그 제약이 상당히 작아서 재작업을 발생시켜도 거의 비용이 들지 않습니다.

그렇기에, 자신이 다루기 쉬운 속도까지 일부러 작업 속도를 늦출 수 있습니다.

한번에 만들게 하는 것이 아니라,

• 우선 상황을 정리하게 한다
• 다음에 설계를 하게 한다
• 그것을 리뷰한다
• 작게 구현하게 한다
• 검증하게 한다
• 문서화 (Documentation)하게 한다

라는 방식으로 진행할 수 있습니다. 이는 AI가 빠르기 때문에, 오히려 인간 측이 제어하기 쉬운 속도로 늦춘다는 발상입니다.

기업 오피스의 신규 구축, 철수, 축소에 관여했던 시기도 있었습니다.

단순히 우리 기기를 어떻게 들여올지만 보고 끝날 일이 아닙니다.

빌딩 설계 PM과의 협상 (Negotiation), LAN 케이블 배선 업체 확보, 내장·천장·플로어·집기 업체와의 스케줄 조정.

나아가 관리 조합의 제약 사항 파악, 열쇠 보관 규칙, 복수 사업자의 회선 예약까지 확인해야 합니다.

스케줄 조정을 할 수 있어도, 현장에 들어가지 못하면 의미가 없습니다.

기기를 확보해도, 타이밍이 맞지 않으면 설치할 수 없습니다.

설정이 올바르더라도, 회선이 연결되어 있지 않으면 통신할 수 없습니다.

애초에 전원이 없다면, 기기는 작동하지 않습니다.

여기서 몸에 익힌 것은, **「결과물은 그것이 사용되는 장소까지 포함하여 설계한다」**는 감각입니다.

코드가 돌아가는 것만으로는 부족합니다.

누가 사용하는가어느 폴더에 두는가어떤 순서로 조작하는가에러가 발생하면 누가 보는가입력 파일명은 어떻게 하는가출력 결과를 어떻게 판단하는가인수인계할 때 무엇을 읽어야 하는가

여기까지 생각해야 비로소 현장에서 쓸 수 있는 것이 됩니다.

AI에게 코드를 쓰게 하는 것 자체는 상당히 쉬워졌습니다.

하지만, 현장에서 쓸 수 있는 형태로 만들기 위해서는 지금도 운용 설계 (Operational Design)가 필요합니다.

경력 후반에는 모니터링 도구의 운용이나 네트워크 상황의 가시화(Visualization)도 수행했습니다.

모니터링 도구의 매뉴얼을 숙독하고, 직장의 사용 방식에 맞춰 설정한다.

Excel VBA나 배치 파일 (Batch file)을 사용하여 모니터링 도구의 기능이나 API로부터 데이터를 가져와, 그래프화하여 사업부에 보여준다.

AI에게 무언가를 만들게 할 때, 마지막으로 필요한 것은 **「정말로 좋아졌는가」**를 확인하는 것입니다.

예를 들어 업무 도구라면,

처리 건수에러 건수차이 건수사람이 확인해야 할 건수작업 시간의 변화****오판하기 쉬운 패턴

이러한 것들을 눈에 보이는 형태로 만들면, 개선에 관한 대화를 할 수 있습니다.

AI는 코드를 쓸 수 있습니다. 하지만, 무엇을 성공으로 간주할지는 인간이 정의할 필요가 있습니다.

돌이켜보면, 제가 자주 사용했던 것은 **아날로지 (Analogy, 유추)**였다고 생각합니다. 어떤 현장에서 배운 구조를 다른 현장으로 옮기는 힘입니다.

경력에서 배운 것	AI 협업에서의 사용법
기존 서비스를 유용하고 차이점을 설계하기	업무 효율화 도구의 설계
...

즉, AI 시대라서 완전히 새로운 능력이 필요해졌다기보다, 과거의 현장 경험을 다른 대상으로 옮겨 심을 수 있는 사람이 강해지고 있는 것이라고 생각합니다.

지금까지의 경력을 바탕으로, 지금 시대에 현장에 들어가는 신입에게 전한다면, 구체적으로 다음과 같이 움직여 주길 바랍니다 (저 자신은 이미 다른 길을 선택했으므로, 어디까지나 사고 실험입니다).

먼저, 눈앞의 일을 절차로 분해합니다.

예를 들어, Excel로 매일 하고 있는 집계라도 좋습니다.

파일을 받고, 열(Column)을 확인하고, 불필요한 행을 지우고, 정렬하고, 다른 표와 대조하고, 결과를 누군가에게 보낸다.

그것을 일본어로 절차화합니다.

이 시점에서는 코드를 쓰지 못해도 상관없습니다.

중요한 것은, 「자신이 무엇을 판단하고 있는가」를 언어화하는 것입니다.

다음으로, 입력과 출력을 결정합니다.

AI에게 일을 맡길 때, 가장 중요한 것은 바로 이 부분입니다.

입력 파일은 무엇인가필수 열은 무엇인가출력 파일은 무엇인가어떤 열을 추가할 것인가어떤 조건이라면 OK인가****어떤 조건이라면 인간의 확인이 필요한가

이것들을 결정할 수 있는 것만으로도 AI에게 맡길 수 있는 업무의 질이 올라갑니다.

다음으로, VBA, PowerShell, Python, 배치 파일(Batch file) 중 무엇이든 좋으니 작은 스크립트(Script)를 접해 보세요.

처음부터 커다란 애플리케이션을 만들 필요는 없습니다.

• 파일명을 통일하기
• CSV 읽어오기
• Excel 서식 정리하기
• API에서 데이터 가져오기
• 폴더 정리하기
• 로그(Log) 남기기

중요한 것은, "수작업은 어느 정도까지 자동화할 수 있다"는 것을 체감하는 것입니다.

GitHub나 Cursor의 Skills와 같은 메커니즘은 상당히 프로그래머(Programmer)에 가깝습니다. 경력이 있는 사람이 갑자기 뛰어들면 문화 차이 때문에 지칠지도 모릅니다.

실제로 저는 모든 것을 GitHub에 올리지는 않습니다. 파일 공유나 작업 관리는 Google 드라이브의 웹 버전 및 데스크톱 버전을 사용하며, Skills도 자신에게 필요하다고 느낀 것만 조사한 뒤에 독자적으로 도입하고 있습니다.

프로그래머의 로직(Logic)에 억지로 맞추기보다, 현장 중심의 로직으로 AI를 접하는 것이 자신에게 다루기 쉽기 때문입니다. 예를 들어, 환경에 의존하게 하지 않거나, 설정의 원본(Source of truth)을 코드와 분리하는 것과 같은 사고방식입니다.

반면, 젊은 사람이라면 일찍부터 프로그래머의 로직을 접해 보는 것도 좋다고 생각합니다. 목적은 유행하는 도구를 사용하는 것이 아닙니다. 작업을 일회성으로 끝내지 않고, 재사용할 수 있는 형태로 만드는 감각을 익히는 것입니다.

• 절차를 README로 만들기
• 자주 사용하는 처리를 스크립트로 만들기
• 변경 이력 남기기
• 타인이나 AI가 읽을 수 있는 형태로 만들기
• 다음번의 내가 편해지는 형태로 만들기

AI에게 일을 맡기는 능력에는 **수락 확인(Acceptance)**도 포함됩니다. AI가 내놓은 결과물을 보고,

목적에 부합하는가입력의 가정이 맞는가출력이 확인하기 쉬운가예외 상황(Exception)은 어떻게 되는가절차서가 이용자가 읽을 수 있는 형태인가****다음에 수정할 사람이 곤란해하지 않겠는가

를 확인하는 것입니다. 이는 외주 결과물을 검수하는 것과 같습니다.

AI가 편리해질수록, 인간 측의 책임은 **"만드는 것"에서 "전달하는 법과 받아들이는 법"**으로 옮겨갑니다.

20대, 30대, 40대가 가진 경험의 양은 다릅니다. 입장도 다릅니다.

다만, AI에게 전달하는 연습의 **틀(Pattern)**은 같습니다. 이하에서는 연령대별로 조금씩 다른 읽기 방식을 적겠습니다.

솔직히 지금 20대 사람들의 생각을 다 이해한다고는 생각하지 않습니다.

그래서 여기서는, 내 안의 20대를 끄집어내어 그 시절의 나에게 전달하는 형식으로 쓰겠습니다.

당시의 나에게 전달한다면, "프로그래머인가, 인프라 엔지니어인가"라는 고민을 지금이라면 그렇게 빨리 결정하지 않아도 된다는 것입니다.

인프라 현장에서 일하면서 코드의 세계를 동경하던 시절이 있었습니다. 어느 한쪽만을 선택해 깊게 파고들어야 한다는 분위기도 있었습니다. AI가 있다는 전제라면, 양쪽의 틀을 무리 없이 흡수할 여지는 상당히 넓어져 있다고 생각합니다.

현장에서 익히는 분해·검증·절차화의 능력을 토대로, 스크립트나 작은 자동화는 AI와 함께 가져가면 됩니다. 프로그래머에 가까운 작성 방식이나 자산화 습관도 현장 업무에 연결하여 시도할 수 있습니다. 직함으로 한 번 결정하기보다, 일을 전달할 수 있는 형태로 떨어뜨리는 연습을 빨리 시작하는 것이 더 효과적입니다.

영업이든, 사무든, 운용이든, 기획이든, 현장의 업무를 분해하여 AI나 스크립트에 넘길 수 있는 사람은 강해질 것이라고 생각합니다. 중요한 것은, 프로그래밍 사고를 다른 업무에 도입하는 것입니다.

업무를 분해하기입력과 출력을 결정하기예외를 생각하기검증하기절차를 남기기****타인에게 전달할 수 있는 형태로 만들기

첫걸음은 눈앞의 Excel 작업을 일본어(언어)로 절차화하는 것입니다. 다음의 구체적인 예시는 그 이미지를 보여줍니다.

가상의 사무 작업입니다. 실제 고객명이나 금액은 사용하지 않았습니다.

수행하는 일

매일 아침 매출 CSV를 받아, 불필요한 행을 삭제·정렬하고, 별도의 표와 대조하며, 임계값 미만의 행을 육안으로 찾아 담당자에게 연락한다.

AI에게 전달한 정의

입력:sales_YYYYMMDD.csv
(열: 날짜, 점포 ID, 금액, 상태)

출력:summary_YYYYMMDD.xlsx

(열: 점포 ID, 합계, 확인 필요 플래그) -
OK 조건: 확인 필요 플래그는 「합계가 임계값 미만」일 때만 1 -
인간 확인: 플래그=1인 행만 육안 확인 -
검증: 샘플 3일분으로 수작업 결과와 대조하여 차분 0건

결과

코드를 한 줄씩 읽기보다, 대조 결과와 로그를 보는 운용 방식으로 정했다.

「전부 자동화」하기보다 「사람이 보는 행을 줄이는」 설계가 현장에서는 더 수용되기 쉬웠다.

이것이 본 기사 서두에서 언급한 7개 항목의 축소판이다.

30대는 지금까지 쌓아온 업무 지식이 비로소 형태를 갖추기 시작하는 시기라고 생각한다.

현장의 흐름도 안다. 사람의 움직임도 안다. 어디가 번거롭고, 어디가 개인의 역량에 의존(属人化, Silo)하고 있는지, 어디를 고치면 효과가 있을지도 보이기 시작한다.

그렇기에 이 시기에는 AI나 자동화 쪽으로 상당히 무게를 두어도 좋다고 생각한다.

20대처럼 기초를 넓게 다지러 다니기보다는, 자신의 업무 지식을 재료로 삼아 AI에게 일을 넘기는 연습을 하는 것이다. 지금 바로 가지고 있는 현장 지식을 스크립트(Script), 절차서, 업무 플로우(Workflow), 검증 샘플로 변환해 나간다.

방향 전환도 아직 늦지 않았다.

그러면서도 완전한 신입은 아니기에, AI에게 넘겨줄 업무의 소재도 가지고 있다.

이 시기에 「자신의 현장 지식을 AI에게 넘길 수 있는 형태로 바꾸는」 경험을 쌓을 수 있다면, 그 이후에는 훨씬 움직이기 수월해질 것이다.

40대 분들과는, 과거의 경험을 상당히 활용할 수 있다는 감각을 공유하고 싶다.

다만, 이름 그대로 사용하기는 어렵다.

과거의 직함이나 담당 시스템명이 아니라, 그 안에서 무엇을 했는가를 추상화(Abstraction)해 보면 AI에게 넘길 수 있는 형태가 보인다.

장애 대응을 했다면, 원인 분리(Troubleshooting) 능력 -
절차서를 작성했다면, 재현 가능성을 만드는 능력 -
벤더 조율을 했다면, 일을 넘기는 능력 -
모니터링을 했다면, 상태를 가시화(Visualization)하는 능력 -
현장 도입을 했다면, 사용자 관점의 동선 설계

이렇게 추상화하면 과거의 경험이 지금의 AI 협업에도 사용할 수 있는 형태가 된다.

AI는 젊은 사람만의 도구가 아니다.

오히려 현장에서 다양한 실패와 조율을 경험해 온 사람일수록, AI에게 넘길 업무의 입도(Granularity)를 만들기 쉬운 면이 있다.

50대 이상에 대해서는 내가 아직 경험해 보지 못했기에 잘 모르겠다.

다만 적어도 40대까지의 실감으로는, 과거의 현장 경험을 추상화할 수 있다면 AI 협업에 상당히 연결될 수 있다.

나 자신은 통신 인프라, 설계 리뷰, 벤더 조율, 물리 공사 PM, 모니터링 가시화, 타 업종 업무의 효율화 과정 속에서 꽤 멀리 돌아오며 「넘기는 유형」을 익혔다. 나중에 돌이켜보니 조금 더 의식적으로 가져갈 수 있었던 부분도 있다.

적어도 지금의 업무에서는, AI에게 일을 넘길 수 있는 사람이 강하다.

그리고 그 능력은 프로그래머만의 것이 아니다.

현장을 잘 아는 사람일수록 업무를 AI에게 넘길 수 있는 형태로 변환할 가능성이 크다.

앞으로 단련해야 할 것은 **「AI를 사용하는 능력」**이라기보다, **「AI에게 넘길 수 있는 업무를 설계하는 능력」**이라고 생각한다.

• AI 소담 — 끝나지 않는 대화의 구조 — 지난번 경량 기사 (대화 끊기)
• AI를 「외주 엔지니어」로 취급하는 이야기 — 본 기사의 「벤더 조율」 절 상세판
• AI 코딩에 「운용 엔지니어의 규율」을 도입하는 이야기 — 분해·검증·절차화의 규율
• 나의 AI 협업의 하루 — 실황 (단시간에 업무 툴을 만드는 흐름)
• AI 코딩은 「연금술」이다 — 사고를 포기하지 않는다는 전제