AI와 일하는 건 코딩보다 리더십에 더 가깝다

지금까지 일해 온 대부분의 기간 동안 코드는 내게 확실성을 줬다. 프로그램은 명령받은 대로 작동했다. 같은 입력에서 다른 결과가 나오면 우리는 그것을 버그라고 불렀다.

사람은 결코 그렇지 않았다. 리더로서 업무를 설명하면 내가 요청한 바로 그 결과를 받을 수 있다. 동료가 요청에 담긴 의도를 이해해 더 나은 결과를 내놓기도 한다. 때로는 결과를 보고 내가 생각만큼 명확하게 설명하지 못했다는 사실을 깨닫는다.

AI와 일하는 경험은 두 번째에 더 가깝다.

AI는 소프트웨어로 작동하지만, AI와의 작업을 완전히 예측할 수는 없다. 똑같이 요청해도 다른 답을 내놓을 수 있다. 유용한 연결고리를 찾아내기도 하고, 명백한 요점을 놓치기도 하며, 내가 생각하지 못한 접근법으로 놀라게 하기도 한다.

AI를 컴파일러처럼 대하면 이런 특성이 답답하다. 하지만 AI와 주고받는 과정을 협업의 한 형태로 받아들이면 훨씬 유용해진다.

그렇다고 AI가 사람이라는 뜻은 아니다. AI에는 실제 삶의 경험도, 책임도, 인간의 판단력도 없다. 이 비교는 우리가 일하는 방식에 관한 것이다. 훌륭한 리더는 지시만 내리지 않는다. 맥락을 공유하고, 원하는 결과를 설명하고, 경계를 정한 뒤 돌아온 결과에 맞춰 대응한다.

이런 습관은 AI와 일할 때도 도움이 된다. 좋은 프롬프트도 유용하지만, 함께 참고할 작업 맥락은 훨씬 더 큰 도움이 된다. 예시와 수정 사항, 재사용할 수 있는 지침을 제공하면 오해가 줄어든다. 시간이 지나면서 시스템은 내가 생각하는 방식과 내가 필요로 하는 결과에 더 잘 맞춰진다.

여기서 들여야 할 노력은 AI를 인간인 척 대하는 데 있지 않다. 의도를 더 잘 표현하는 능력을 기르는 데 있다.

우리는 컴퓨터에 무엇을 해야 하는지 정확히 지시하는 법을 배우는 데 오랜 시간을 보냈다. 이제는 그 일이 왜 중요한지, 좋은 결과가 어떤 모습인지, 어느 지점에서 판단이 필요한지도 설명해야 한다.

내가 느끼는 변화는 바로 이것이다. AI는 소프트웨어 작업을 기계에 명령하는 일보다 대화를 통해 이끄는 일에 더 가깝게 바꾸고 있다. 기술은 새롭지만, 필요한 리더십 역량은 새롭지 않다.

이 글을 계기로 Hacker News에서 깊이 있는 토론이 이어졌다. 댓글을 모두 읽어보길 권한다. 동의와 비판, 서로 다른 경험이 더해지면서 내가 이 글에 담을 수 있었던 것보다 생각이 한층 풍부해진다.

^{source https://allen.bargi.org/notes/working-with-ai-feels-like-leadership/}

HN에서는 AI 코딩을 리더십이라 부르기보다 관리·조율·코드 리뷰에 가깝다고 보는 반응이 두드러졌다. 목표와 맥락을 설명하고 결과를 교정하는 능력이 중요해졌다는 데에는 공감대가 있었다. 다만 인간의 동기와 감정, 책임까지 다루는 리더십과 같은 개념으로 묶기에는 차이가 크다는 지적이 이어졌다. 요구사항을 정리하고 동료와 소통하는 일은 원래도 개발자의 몫이었다는 반론도 나왔다.

효과를 본 사람들은 여러 에이전트에 작업을 나누고, 질문에 답하고, 산출물을 평가하는 과정에서 관리 경험이 도움이 된다고 했다. 예상과 다른 결과를 받아들인 뒤 방향을 다시 잡는 데 익숙할수록 AI의 비결정성에도 잘 대응했다. 반대로 기술 이해 없이 결과를 그대로 믿으면 짧은 시간에 코드만 불어나고, 요구사항은 충족하지 못한 채 일정 지연과 기술 부채가 커질 수 있다는 경험도 제시됐다.

직접 코드를 입력하는 양이 줄어도 개발자는 도메인 모델과 구조, 책임 분리, 시스템의 일관성을 계속 판단해야 한다. 그래서 AI를 독립적인 팀원보다는 제한된 작업을 맡기는 도구나 대량의 코드를 빠르게 내놓는 생성기로 보는 시각도 강했다. 작업을 작게 나누고 기준을 명확히 세운 뒤 엄격하게 검토할 때는 생산성이 높아졌지만, 에이전트를 오래 돌리는 것 자체를 성과로 삼으면 쓰지 않을 결과물만 늘어났다.

결국 따져야 할 것은 AI를 사람처럼 대하느냐가 아니라 누가 기술적 판단과 결과의 책임을 지느냐다. 목표 설정과 병렬 조율 능력은 중요해졌지만, 산출물을 이해하고 검증하는 역량을 대신하지는 못한다. 생성 속도보다 작업 범위를 얼마나 잘 제한하는지, 계획을 먼저 검토하는지, 작은 변경으로 나눠 확인하는지, 운영할 사람이 코드를 감당할 수 있는지를 먼저 살펴야 한다.