AI와 일한다는 건 코딩이 아니라 리더십에 가깝다

무엇인가요

개발자 Allen Bargi는 최근 올린 글에서, AI 코딩 에이전트와 일하는 경험이 컴파일러에게 명령을 내리는 것과는 완전히 다르다고 말합니다. 같은 요청을 던져도 AI는 그때그때 다른 결과를 내놓기 때문에, 기계적으로 명령을 전달하는 방식보다는 좋은 리더가 팀원을 대하는 방식—맥락을 공유하고, 의도를 설명하고, 경계를 정하고, 피드백을 반영하는 것—이 훨씬 효과가 좋다는 것입니다. 글쓴이는 이 변화의 본질을 “명령 전달에서 대화를 통한 리더십으로의 전환”이라고 요약합니다.

이 글은 Hacker News에서 500점 가까운 반응과 177개의 댓글을 모으며 뜨거운 토론으로 이어졌습니다. 반박도 상당했습니다. 많은 댓글이 “이건 리더십이 아니라 매니지먼트”라고 정정했고, “AI는 자발적 추종을 하는 게 아니라 명령을 따를 뿐”이라는 지적, “인간 직원은 괴롭힐 수 없지만 AI는 괴롭혀도 된다”는 본질적 차이를 짚는 댓글도 있었습니다. 한 사용자는 관리자가 AI로 3주 만에 6만 줄을 작성시켰지만 결국 프로젝트가 실패했고 책임을 주니어에게 떠넘긴 사례를 들며, 리더십 비유가 과장됐다고 비판했습니다.

왜 주목할까요

• AI 코딩 도구(Claude Code, Cursor 등)를 매일 쓰는 개발자·창업자가 늘면서, “프롬프트를 잘 쓰는 법”이 아니라 “AI를 잘 이끄는 법”이라는 프레임이 설득력을 얻고 있습니다.
• 리더십과 매니지먼트를 구분해야 한다는 반박은, AI 협업 스킬을 과대포장하지 않는 균형 잡힌 시각을 제공합니다.
• 팀을 이끌어본 경험이 있는 사람이 AI 활용도 더 잘한다는 발상은, 비개발자 출신 창업자에게도 힌트가 됩니다.

국내 관점 코멘트

국내에서도 Claude Code, Cursor 같은 AI 코딩 도구를 실무에 들이는 스타트업이 빠르게 늘고 있습니다. 그런데 실제로 “AI를 잘 쓰는 사람”과 “못 쓰는 사람”의 차이를 들여다보면, 이 글의 지적이 꽤 들어맞습니다—같은 도구를 써도 배경 설명 없이 결과물만 요구하는 사람보다, 왜 이 기능이 필요한지 맥락을 먼저 주는 사람이 훨씬 적은 시행착오로 원하는 결과를 얻습니다. 다만 HN 댓글들의 지적처럼 이걸 “리더십”이라고 부르는 순간 사람 관리처럼 신뢰나 동기부여를 기대하게 되는 함정이 있으니, 실무에서는 “팀장처럼 대하되 AI라는 걸 잊지 않는” 균형이 필요해 보입니다. 신입 개발자나 주니어 마케터를 온보딩할 때 쓰는 체크리스트—목표, 제약조건, 예시, 피드백 루프—를 AI 프롬프트 설계에 그대로 옮겨보는 것부터 시작해볼 만합니다.