AI에게 일을 시켜보니, 프롬프트보다 리더십이 중요했다

AI를 처음 쓰기 시작했을 땐 저도 도구가 하나 늘었다고만 생각했습니다.

예전에는 개발자가 직접 코드를 썼고, 지금은 AI에게 코드를 만들어 달라고 요청합니다. 차이는 그게 전부라고 봤습니다.

그래서 이런 생각을 했습니다.

"앞으로는 프롬프트를 잘 쓰는 사람이 일을 잘하겠구나."

솔직히 저는 그 생각으로 몇 달을 보냈습니다. 문장만 잘 다듬으면 결과가 좋아질 거라고 믿었거든요. 지금 돌아보면 그 시기에 제가 붙잡고 있던 건 대부분 껍데기였습니다.

밤늦게 작업 창을 네다섯 개 띄워놓고 각각에 다른 일을 시키던 날, 제가 하고 있는 게 뭔지 다시 봤습니다. 문장을 다듬는 일이 아니었습니다.

AI를 잘 쓰는 능력은 프롬프트 작성보다 리더십 쪽에 가까웠습니다.

일을 잘 시키는 것도 능력입니다

회사에서 리더가 하는 일을 떠올려 봅니다.

좋은 리더는 모든 일을 직접 하지 않습니다.

먼저 목표를 정합니다. 그다음 그 목표에 닿는 데 필요한 일을 나눕니다. 각 업무는 가장 잘할 사람에게 넘깁니다. 중간 결과를 확인하고, 방향이 틀렸으면 잡고, 문제가 생기면 배분을 다시 짭니다. 마지막에는 여러 사람이 만든 결과를 하나로 붙입니다.

순서로 늘어놓으면 이렇습니다.

목표 설정 → 업무 분해 → 역할 배분 → 실행 → 관찰 → 검토 → 재조정 → 통합

어느 순간 알았습니다. 제가 AI에게 하고 있던 행동이 정확히 이것이었습니다.

AI를 잘 쓴다는 건 질문을 잘한다는 뜻만은 아닙니다

새로운 서비스를 하나 만든다고 해보겠습니다.

AI에게 이렇게 말해도 됩니다.

"이 서비스 하나 만들어줘."

무언가는 나옵니다. 그런데 저는 이 방식보다 일을 먼저 쪼갭니다.

시장과 사용자를 조사해야 합니다. 요구사항을 정리해야 하고, 서비스 구조를 설계해야 하고, 데이터 모델도 필요합니다. 구현과 테스트가 따라붙고, 보안과 운영 관점의 검토도 남습니다.

그러면 하나의 커다란 문제가 여러 개의 작은 문제로 바뀝니다.

그다음에야 AI에게 역할을 맡깁니다. 한쪽에는 시장을 분석시키고, 다른 작업에서는 요구사항을 정리시킵니다. 또 다른 쪽에는 아키텍처를 검토시키고, 구현 결과를 별도의 관점에서 다시 물어뜯게 만들기도 합니다.

AI가 몇 개냐는 중요하지 않습니다.

무엇을 누구에게 맡기고, 어떤 순서로 돌리고, 어느 지점에서 결과를 검증할지를 사람이 정한다는 것. 여기서 갈립니다.

이쯤 되면 이걸 프롬프트 엔지니어링이라고 부르기에는 좀 부족합니다. 조직 운영에 더 가깝습니다.

좋은 리더는 모든 일을 위임하지 않습니다

여기서 짚고 갈 게 하나 있습니다.

리더십을 "일을 남에게 시키는 능력"으로만 읽으면 곤란합니다.

AI도 같습니다.

직접 하면 10분이면 끝나는 일을 AI에게 20분 동안 설명하고, 결과를 검증하는 데 다시 10분을 쓴다면 위임할 이유가 없습니다. 저도 이걸 몇 번 겪고 나서야 손을 뗐습니다. 30분이면 끝났을 스크립트를 두 시간 동안 설명하고 있던 날의 기분은 지금도 남아 있습니다.

반대로 조사 3시간, 개발 5시간, 테스트 2시간이 필요한 일을 적절히 쪼개서 병렬로 돌린다면 이야기가 달라집니다.

그래서 AI를 쓰는 데 의외로 중요한 능력이 하나 생깁니다.

배분입니다.

무엇을 내가 직접 할 것인가. 무엇을 AI에게 맡길 것인가. 무엇을 동시에 굴릴 것인가. 어떤 결과는 반드시 내가 뜯어봐야 하는가.

AI를 잘 쓰는 사람은 모든 것을 AI에게 시키는 사람이 아닙니다. 직접 할 일과 넘길 일을 잘 가르는 사람입니다.

좋은 리더가 조직에서 하는 일과 같습니다.

개발자로 일하던 방식과 지금 일하는 방식은 달랐습니다

저는 개발자로 시작했습니다.

프론트엔드와 백엔드를 만들었고, 금융 시스템과 API, 플랫폼, MSA, 클라우드와 Kubernetes까지 넘어왔습니다.

경력이 쌓이면서 역할은 조금씩 옮겨갔습니다. 직접 만드는 것뿐 아니라 AA와 SA 관점에서 구조를 보고, PM 자리에서 업무를 나누고, ISP와 컨설팅에서는 문제 자체를 정의해야 했습니다.

생각하는 순서도 그때 바뀌었습니다.

예전에는 문제가 생기면 "이걸 어떻게 구현하지?"부터 떠올렸는데, 지금은 "이 문제를 어떻게 나누지?"가 먼저 나오는 경우가 많습니다.

누가 해야 하는가. 어디까지 맡길 것인가. 어떤 작업끼리 병렬로 갈 것인가. 어디에 의존성이 걸려 있는가. 어떤 결과를 받아야 다음 단계로 넘어가는가.

AI를 쓰다 보니 이 사고방식이 그대로 옮겨 붙었습니다.

그래서 저는 AI를 검색도구나 코딩도구보다 같이 일하는 작업자에 가깝게 쓰고 있는지도 모르겠습니다.

혼자 일해도 리더가 됩니다

AI 에이전트가 더 발전하면 이 변화는 훨씬 커질 겁니다. 한 사람이 여러 에이전트를 동시에 굴리기 때문입니다.

한쪽은 조사하고, 한쪽은 개발하고, 다른 쪽은 테스트하고, 또 다른 쪽은 그 결과를 물고 늘어집니다.

그러면 사람은 모든 작업을 직접 수행하는 Worker보다, 여러 작업을 조율하는 자리로 옮겨갑니다.

개발자에게 익숙한 말로 바꾸면, 사람이 Worker에서 Control Plane으로 이동하는 셈입니다.

Control Plane은 워크로드를 직접 처리하지 않습니다. 어디에서 무엇을 실행할지 정하고, 상태를 관찰하고, 원하는 상태와 실제 상태가 어긋나면 다시 맞춥니다.

AI 에이전트를 다루는 사람도 점점 비슷해집니다. 목표 상태를 정의하고, 작업을 배치하고, 결과를 보고, 실패하면 다시 조정합니다.

Kubernetes를 오래 만져온 제 눈에는 이 그림이 묘하게 익숙합니다.

그래서 리더십의 값이 오히려 오를지도 모릅니다

AI가 발전하면 리더가 덜 필요해질 거라는 말도 있습니다.

저는 반대로 봅니다.

실행 비용이 내려갈수록 무엇을 실행할지 정하는 능력의 값이 올라갑니다.

코드를 만드는 비용이 100에서 10으로 떨어졌다고 해봅시다. 그러면 병목은 코드를 만드는 속도가 아닙니다. 무엇을 만들지 정하는 능력이 병목이 됩니다.

에이전트가 10개 있다고 생산성이 자동으로 10배가 되지도 않습니다. 방향이 틀린 채로 10개를 동시에 움직이면 틀린 결과를 10배 빠르게 뽑습니다.

그래서 사람 몫이 남습니다.

문제를 정의하는 것. 업무를 나누는 것. 우선순위를 정하는 것. 배분하는 것. 결과를 검증하는 것. 틀린 방향을 잡아채는 것.

지금까지 리더십이라고 불러온 능력들입니다.

지능의 조직화

산업혁명은 인간에게 더 강한 힘을 줬습니다. 컴퓨터는 더 빠른 계산을 줬고, 인터넷은 거의 무한한 정보 접근을 줬습니다.

AI는 좀 다른 걸 줍니다.

필요할 때 꺼내 쓰는 지능입니다.

그렇다면 다음 경쟁은 누가 더 많이 외우고 있느냐로 갈리지 않습니다. 누가 AI를 더 많이 쓰느냐도 아닐 겁니다.

여러 개의 지능을 하나의 목표로 얼마나 잘 움직이게 하느냐. 저는 여기서 갈릴 거라고 봅니다.

AI 시대의 리더십은 CEO나 임원에게만 붙는 능력이 아닙니다. 개발자 한 명도 여러 에이전트를 굴리는 순간 작은 조직의 리더가 됩니다. 기획자도, 디자이너도, 연구자도 마찬가지입니다.

AI가 사람의 리더십을 지우는 게 아니라, 지금까지 일부 관리자에게만 요구되던 걸 개인 전부에게 요구하는 쪽으로 가고 있는 건 아닌지. 아직 확신은 없습니다. 다만 제 모니터 앞에서는 이미 그렇게 흘러가고 있습니다.