AI 4분 소요

AI와 일해보니 코딩이 아니라 '팀장 노릇'이었습니다

요즘 개발자 커뮤니티에서 반복해서 나오는 말이 있습니다. “AI랑 일하다 보니 내가 코딩을 안 하고 있더라.” 그럼 뭘 하냐고 물으면 답이 다 비슷합니다. 일을 쪼개서 던지고 결과물 받아서 검수하고, 다시 지시를 내린다고요. 그건 코딩이 아니라 팀장이 하는 일입니다.

솔직히 이 주제는 아직 커뮤니티에 쌓인 데이터가 많지 않습니다. 스레드 하나가 크게 터져서 화제가 된 게 아니라, 여기저기서 비슷한 감각이 조금씩 새어 나오는 중이거든요. 그래서 숫자보다는 이 변화가 어떤 모양인지를 짚어보려 합니다.

하루 일과가 통째로 바뀌었습니다

예전 개발자의 하루는 단순했습니다. 이슈를 잡고 에디터를 열고 코드를 씁니다. 막히면 검색해서 다시 씁니다. 붙들고 있는 건 코드 그 자체였습니다.

지금은 다릅니다. 아침에 앉아서 하는 첫 일이 “오늘 이 기능을 어떻게 3~4개 작업으로 쪼갤까"입니다. 쪼갠 다음엔 각각을 에이전트에게 맡깁니다. 어떤 건 백그라운드로 돌려놓고 어떤 건 옆에서 지켜봅니다. 결과물이 하나씩 돌아오면 읽고 판단합니다. 이거 머지할까, 다시 시킬까, 아니면 내가 직접 손댈까.

이 흐름에서 에이전트 자리에 사람을 넣어보세요. 주니어 세 명한테 티켓 나눠주고 PR 올라오면 리뷰하는 팀장의 하루와 똑같습니다. 손에 쥔 게 사람에서 모델로 바뀌었을 뿐입니다.

위임에도 실력이 필요합니다

“AI한테 시키면 되는 거 아니냐"는 말이 얼마나 순진한지는 해보면 압니다. 위임은 그 자체로 기술입니다.

지시를 너무 뭉뚱그리면 엉뚱한 걸 만들어 옵니다. “로그인 기능 만들어줘"라고 하면 세션 방식인지 토큰 방식인지, 기존 유저 테이블은 어떻게 쓸 건지 알아서 결정해버립니다. 반대로 너무 잘게 쪼개면 내가 코드를 말로 받아쓰게 하는 꼴이라 그냥 직접 치는 게 빠릅니다.

적절한 크기의 덩어리를 찾는 감각. 이건 사람 팀을 굴려본 사람이라면 익숙한 고민입니다. 신입에게 어디까지 맡기고 어디부터 붙잡아줄지 재는 것과 똑같습니다. 다른 점이 하나 있다면 AI는 컨텍스트를 사람처럼 쌓아두지 않습니다. 어제 알려준 팀 컨벤션을 오늘도 알고 있으리라 기대하면 안 됩니다. 그러니 다들 규칙 파일을 만들고 프롬프트 템플릿을 모아둡니다. 팀 위키 정리하는 일과 다를 게 없습니다.

코드 리뷰가 병목이 되었습니다

여기가 진짜 문제입니다. 코드를 만들어내는 속도는 몇 배로 뛰었는데, 읽고 판단하는 속도는 그대로거든요.

에이전트 세 개를 돌리면 세 배의 diff가 쏟아집니다. 그런데 그걸 읽는 눈은 하나입니다. 병목이 자연히 리뷰로 옮겨갑니다. AI가 쓴 코드는 사람이 쓴 코드와 결도 다릅니다. 문법도 깔끔하고 변수명도 그럴듯한데 요구사항을 미묘하게 비껴간 게 섞여 있습니다. 대충 훑으면 통과시키기 딱 좋은 형태입니다.

여기서 자주 빠지는 함정이 있습니다. 리뷰 피로가 쌓이면 검수 기준이 슬금슬금 내려갑니다. “테스트 통과했으니까 됐겠지"로 넘어가기 시작합니다. 사람 팀도 리뷰가 형식만 남으면 똑같아지죠. 다만 AI는 지치지 않고 계속 코드를 뽑아내서 그 압박이 훨씬 셉니다.

신뢰를 어디까지 줄 것인가

관리자가 되면 피할 수 없는 질문이 생깁니다. 이 사람 결과물을 어디까지 믿을 것인가.

AI한테도 똑같습니다. 테스트 코드 작성이나 리팩터링처럼 실수해도 금방 드러나는 쪽은 믿는 범위를 넓혀도 괜찮습니다. 인증, 결제, 데이터 마이그레이션처럼 틀렸을 때 조용히 망하는 쪽은 한 줄씩 봐야 하고요.

다만 이 구분은 사람 팀에 쓰던 것과 좀 다릅니다. 사람은 시간이 지나면 실력이 늡니다. 작년에 못 믿던 주니어를 올해는 믿게 되죠. AI는 그렇게 크지 않습니다. 모델이 업데이트되면 갑자기 잘하고 컨텍스트가 길어지면 갑자기 헤맵니다. 신뢰가 쌓이는 게 아니라 상황마다 재계산되는 구조입니다. 사람 관리 경험이 그대로 넘어오지 않는 대목이 여기입니다.

“그래서 나는 무엇을 잃는가”

여기까지는 좋게 본 이야기입니다. 반대쪽 목소리도 만만치 않습니다.

가장 자주 나오는 우려는 감각의 퇴화입니다. 코드를 직접 쓰면서 얻는 게 있습니다. 이 함수가 왜 느린지, 이 구조가 나중에 왜 발목을 잡을지는 손으로 만져봐야 압니다. 리뷰만 하는 사람은 이 감각이 무뎌지고, 감각이 무뎌지면 리뷰 능력도 같이 떨어집니다. 좋은 리뷰어가 되려면 좋은 작성자여야 하니까요. 자기 발등을 찍는 셈입니다.

신입 개발자 문제도 있습니다. 관리자로 시작하는 커리어는 없습니다. 팀장이 팀장 노릇을 할 수 있는 건 예전에 실무를 해봤기 때문이죠. 그런데 지금 막 시작하는 사람은 AI에게 위임하는 것부터 배웁니다. 검수할 실력은 어디서 쌓을까요. 여기엔 아직 아무도 시원한 답을 못 내놨습니다.

마지막은 좀 감정적인 얘긴데, 그래서 더 무거울 수 있습니다. 재미가 줄었다는 고백이 꽤 많습니다. 애초에 개발에 빠진 이유는 문제를 붙들고 씨름하다 풀리는 순간의 쾌감이었습니다. 그걸 통째로 위임하고 나면 남는 건 검수 업무입니다. 승진했는데 일이 재미없어진 팀장의 심정과 비슷하죠.

결국 직무 정의가 바뀌는 중입니다

AI 에이전트는 개발자를 대체하는 게 아니라 직무 내용을 교체하고 있습니다. 코드를 쓰는 시간은 줄고 쪼개고 맡기고 읽고 판단하는 시간이 늡니다. 그런데 이 새 업무는 대부분의 개발자가 제대로 배운 적이 없습니다.

앞으로 갈리는 지점도 여기일 겁니다. 위임을 잘하는 사람과 리뷰 기준을 끝까지 지켜내는 사람. 어디까지 믿을지 스스로 정할 줄 아는 사람. 코딩 실력과는 다른 축의 능력입니다.

지난 한 주만 놓고 보죠. 직접 코드를 쓴 시간과 AI 결과물을 읽고 고친 시간, 어느 쪽이 길었나요. 이미 뒤집혔다면 원하든 원치 않든 팀장 노릇은 벌써 시작된 겁니다. 그럼 오늘 연습해야 할 건 코딩이 아니라 그쪽이겠죠.

AI 개발자 AI에이전트 코드리뷰 생산성 커리어

댓글

    댓글을 불러오는 중...