AI 시대, 처음 팀 리드를 맡은 1년

AI를 들이는 일과, 그 안에서 사람을 지키는 일

회사를 나오기 전 마지막으로 한 일은, 글과 코드를 지우는 것이었다.

오래 다닌 회사일수록 떠나는 순간 모든 자료에 영원히 접근할 수 없게 된다. 그래서 지워지기 전에, 4년 가까이 쌓아둔 글과 프로젝트 코드를 하나씩 다시 열어봤다. 백업을 위해서가 아니라 한 번은 제대로 들여다보고 싶었다. 그러다 한 가지가 눈에 들어왔다. 1년 전의 나는 한 명의 팀원이었는데, 지금 정리하고 있는 건 리드로 보낸 1년의 기록이라는 것.

2022년에 입사했을 때만 해도 AI로 코드를 짠다는 개념은 없었다. 모든 코드를 직접 썼고, 직접 검증했고, 동료의 날카로운 리뷰에 PR이 리젝되기도 했다. 그런데 퇴사를 계획하던 2025년 중순, 리드 직무를 제안받았다. 하필 그 시점이 AI가 막 팀에 들어오기 시작하던 때였다.

돌아보면 그 타이밍은 운이 좋았다. 회사도 팀도 아직 AI가 들어오지 않은 상태였고, 나는 그걸 내 손으로 들여서 팀을 바꿔보고 싶은 호기심이 컸다. 그동안 인력이 부족하다는 이유로 미뤄둔 수많은 일을, AI로 자동화해 직접 풀어볼 기회라고 느꼈다.

그래서 리드로서의 1년은 두 가지를 동시에 떠안는 일이었다. AI를 가장 적극적으로 팀에 들이고 싶어 한 사람도 나였고, 그게 팀의 성장을 갉아먹지 않을지 가장 신경 쓴 사람도 나였다. 이 글은 그 둘을 어떻게 한 손에 쥐고 갔는지에 대한 기록이다.

리드가 되며 가장 먼저 바뀐 건 시선이었다. 팀원일 때는 내게 주어진 일을 잘 해내면 됐다. 리드가 되자 내 일이 아니라 팀이 내놓는 결과물 전체를 봐야 했다. 팀원은 자연스럽게 자기 업무 범위 안에서만 생각하게 된다. 그 시선에서 벗어나 조직 단위로 보는 사람이 리드라는 걸, 자리에 앉고 나서야 알았다.

더 빨라진 팀에서, 품질은 누가 다루느냐에 따라 갈렸다

우리 팀은 사내 모든 팀 중 AI를 가장 먼저 들였다. 더 적은 인원으로 더 많은 걸 만들었다. 그런데 그 속도의 그늘에서 품질 문제가 쌓이기 시작했다.

원인의 상당수는 AI의 구현 실수였고, 그게 제대로 걸러지지 않은 채 넘어간 검증의 공백이었다. 더 신경 쓰인 건 따로 있었다. 같은 AI를 써도, 막 온보딩한 팀원과 연차 있는 팀원이 내놓는 코드의 품질이 갈렸다. 도구는 같은데 결과물이 달랐다.

생각해보면 당연했다. 업무는 요구사항대로 구현했다고 끝나는 게 아니다. 정책이 덜 정해진 채 내려온 건 아닌지 요구사항 정리 단계에서 짚어야 하고, 그러려면 도메인 지식과 회사의 업무 룰을 알고 있어야 한다. 우리 코드가 올라타는 네이티브 팀의 코드 상황, 인프라 상황 같은 코드베이스 바깥의 맥락도 머리에 넣고 있어야 한다. 결국 이 맥락을 얼마나 쥐고 있느냐가 품질을 갈랐고, 그건 연차에 따라 다를 수밖에 없었다.

그래서 리드로서 풀 문제가 분명해졌다. 품질을 개인기에서 떼어내는 것. 누가 AI를 다루든 비슷한 품질이 나오는 구조를 짜는 것이었다.

처음엔 모든 걸 자연어로 통제하려 했다. 지켜야 할 규칙을 문서로 정리해 AI에게 쥐여주는 식이었다. 그런데 AI가 그걸 항상 일관되게 따르지는 않았다. 오히려 규칙이 많아질수록 AI는 흐트러졌고, 관리되지 않는 규칙은 그 자체로 품질을 끌어내렸다.

여기서 방향을 바꿨다. 통제를 두 종류로 나눴다. 비결정적으로 판단이 필요한 영역만 자연어로 정리하고, 결정론적으로 처리할 수 있는 건 스크립트가 실행되게 했다. 사람의 판단이 필요한 곳엔 말로 된 맥락을, 기계적으로 처리되는 곳엔 코드를 둔 것이다. 그러자 속도만 빨라진 게 아니라 정확도까지 같이 올라갔다. 규칙은 많을수록 좋아지는 게 아니라, 자연어로 둘 것과 코드로 둘 것을 가르는 데서 좋아진다.

그 위에서 워크플로 자체를 하나의 파이프라인으로 세웠다. Claude Code 기반으로 hooks와 rules, skills를 엮어 업무 룰이 자동으로 AI에 주입되고 통제되는 환경을 만드는 데 가장 많은 공을 들였다. 배포는 Claude 플러그인 형태로 했다. 모든 팀원이 같은 플러그인을 켜고, 플러그인 배포만으로 최신 워크플로가 반영되게 했다.

흐름은 이렇다. 디자인닥이 나오면 킥오프 미팅으로 요구사항을 정리하는 게 우리 팀의 문화인데, 이때 팀원은 kickoff 스킬을 쓴다. 문서 포맷을 이해한 AI가 연결된 업무 지식을 자동으로 끌어와, 소크라테스식 질문으로 팀원이 시작 단계에서 반드시 챙겨야 할 것들을 스스로 짚게 한다. 거기서 정리된 내용이 Jira 티켓이 되고, 짧은 팀원 리뷰를 거친다. 코드가 아니라 업무 내용이라 리뷰는 길지 않았다. 그다음 implement 스킬이 요구사항 기준으로 태스크를 쪼개 서브에이전트 구조로 구현하는데, 이 에이전트는 우리 디자인 시스템과 코드 구조·패턴·스타일을 학습한 상태다. 구현이 끝나면 self-review 스킬이 킥오프에서 만든 문서를 기준으로 결과물을 검토하고, 셀프 리뷰 결과지와 함께 사람이 직접 돌려야 할 테스트 시나리오를 뽑아준다. 웹뷰 기반이라 실기기 테스트는 사람 몫이기 때문이다. 마지막으로 PR을 템플릿에 맞춰 올리면 GitHub App으로 등록된 리뷰 봇이 정해진 프로세스대로 코멘트를 달고, 그 위에 동료의 코드리뷰가 한 번 더 얹힌 뒤 운영에 배포된다.

이 파이프라인을 짜면서 내가 가장 신경 쓴 건, 자동화의 매 단계마다 사람이 멈춰 서는 지점을 남겨둔 것이다. 업무 정리는 사람이 리뷰하고, 실기기 테스트는 사람이 돌리고, 봇 리뷰 위엔 동료의 눈이 한 번 더 얹힌다. 결국 나는 “AI에게 어디까지 맡길까”보다 “사람이 어디서 멈춰야 하는가”를 정하는 데 더 많은 시간을 썼다. 자동화의 완성도는 얼마나 많이 맡기느냐가 아니라, 어디서 멈출지를 얼마나 정확히 정하느냐에서 나온다.

스크럼에서 단순 작업이 빠지자, 진짜 병목이 보였다

가장 많이 신경 쓴 건 거의 매일 진행한 아침 스크럼과 2주 단위 플래닝, 그리고 스프린트 끝의 회고였다.

매일 스크럼을 해도 시간이 자잘한 업무 공유나 티켓 관리 같은 단순 반복 싱크에 새어 나갔다. 정작 중요한 리스크나 아키텍처 논의에는 집중하기 어려웠다. “어제 뭐 했고 오늘 뭐 할지”를 돌아가며 읊는 시간이 스크럼의 대부분을 차지했다.

앞서 만든 워크플로가 이 단순 작업의 상당 부분을 걷어내줬다. 업무 정리와 티켓 생성, 컨텍스트 주입이 파이프라인 안에서 처리되니, 스크럼에서 그걸 일일이 맞출 필요가 줄었다. 그러자 비로소 시간이 남았다. 나는 그 시간을, 팀원들이 지금 겪는 진짜 병목이 무엇인지, 비즈니스 우선순위가 흔들리고 있지는 않은지 확인하는 데 온전히 썼다.

회고도 비슷한 고민에서 출발했다. 빡센 스프린트가 끝나면 팀원도 나도 지친다. 그런 상태에서 시간을 내 회고를 하는 건 쉽지 않았고, 그렇다고 형식만 채우는 회고는 정말 하기 싫었다. 그래서 팀에 도움이 될 만한 여러 방식의 회고를 번갈아 시도했다. 회고가 왜 필요한지 초기에 팀원들을 설득하는 일부터가 일이었지만, 자리 잡고 나니 팀이 같은 실수를 반복하지 않게 잡아주는 장치가 됐다.

리드를 하면서 내가 잡으려 한 균형이 여기 있었다. 기술적 효율과 사람 중심의 매니지먼트. 도구로 단순 작업을 줄이는 건 효율의 문제지만, 그렇게 번 시간을 무엇에 쓰느냐는 매니지먼트의 문제다. 효율은 사람을 위한 시간을 벌기 위한 수단이지, 그 자체가 목적은 아니었다.

“어차피 AI가 다 짜는데요”

AI를 들이면서 팀원들에게서 예상치 못한 고민을 들었다. 개발이 재미없어졌다는 것이다. 어차피 AI가 다 짜주는데, 내가 하는 일에 무슨 의미가 있느냐는 물음이었다.

나는 그 말에 동의하지 않았다. 우리가 일하면서 마주치는 사건들에는 생각보다 배울 게 많다. AI가 구현을 대신해줄수록, 그 구현 뒤에 숨은 배울 거리를 누가 집어주느냐가 오히려 더 중요해진다고 봤다.

한 가지 예가 기억에 남는다. 모바일에서 사용자가 OS의 폰트 설정을 키우면 화면의 폰트도 따라 커지는 요구사항을 팀원이 맡았다. 팀원은 AI를 써서 요구사항대로 충실히 구현했고, 겉으로는 아무 문제가 없어 보였다. 그런데 경우에 따라 초기 로딩에서 폰트가 한 번 바뀌어 보이는 FOUT 문제가 생길 수 있었다. 이걸 파고들면 브라우저가 화면을 그리는 과정을 짚어볼 수 있고, 해결 방법도 여러 갈래로 갈린다. 폰트가 동적으로 바뀌는 경우까지 요구사항을 넓히면 고려할 게 더 늘어난다. 팀원이 맡은 건 실험적인 기능이라 코드베이스 전체에 적용하는 일은 아니었지만, 그걸 전체에서 지원하려 들면 고민거리는 훨씬 많아진다. 요구사항대로 동작하는 코드 한 줄 뒤에, 이만큼의 배울 거리가 숨어 있었다.

이런 주제를 집어내 함께 파고드는 자리를 만들었다. 1년 동안 회당 한 시간이 넘는 스터디를 스물다섯 번 했다. 발표는 주로 내가 했지만 팀원들도 점차 함께했고, 그러면서 분위기가 달라졌다. 일에 대한 흥미가 올라갔다. 단순히 주어진 걸 쳐내는 게 아니라, 일 자체에서 재미를 찾을 수 있다는 걸 보여주고 싶었다.

스터디만으로 그치지 않고 TFT를 꾸려 팀원이 직접 주도하게 했다. 코드리뷰 문화를 개선하는 TFT를 돌렸고, 성능 개선 TFT에서는 팀원이 직접 리드를 맡고 나는 방향만 조언했다. 주어진 업무만 하는 게 아니라 자기가 주도해 딥다이브하고 성장하는 경험이었다고, 그 팀원은 말했다. 나에게도 그 말이 오래 남았다.

자동화가 늘수록, 원칙이 더 중요해졌다

워크플로가 자리를 잡을수록 한 가지가 분명해졌다. 절차가 자동화될수록, 그 절차를 왜 지켜야 하는지에 대한 원칙이 더 중요해진다는 것이다.

AI 리뷰 봇은 PR마다 빠짐없이 코멘트를 단다. 그러다 보면 “AI가 리뷰까지 해주는데 사람이 또 볼 필요가 있나”라는 생각이 들 수 있다. 하지만 봇의 코멘트만 보고 그대로 넘기기 시작하면, 정작 그 코드를 책임지는 사람이 사라진다. 봇은 비결정적이라 매번 모든 걸 꼼꼼히 짚어준다고 믿기 어렵고, 결국 책임은 AI가 아니라 사람이 진다. 그래서 우리 팀에서 봇의 리뷰는 끝이 아니라 1차 필터였다. 조직의 상황을 가장 많이 아는 사람이 마지막에 한 번 더 보는 구조를 고집했다.

이런 건 강압으로 지켜지지 않는다. 원칙이 납득되지 않으면 팀원은 자기 업무 안에서 가장 편한 방법으로 절차를 건너뛰게 된다. 그래서 나는 규칙을 강제하기보다 왜 이 절차가 필요한지를 설명하고 스스로 따를 수 있게 만드는 데 시간을 더 썼다. 팀원은 자기 업무 범위 안에서 생각하기 마련이고, 그 시야를 넘어 팀이 내놓는 것 전체를 책임지는 게 리드의 자리다. 리드가 지켜야 할 건 팀의 속도 지표만이 아니라, 팀이 생산한 것을 끝까지 책임질 수 있는 상태였다.

1년 동안 나에 대해 알게 된 것

리드를 하며 팀에 대해 배운 만큼, 나 자신에 대해서도 알게 됐다.

나는 일에 관해서는 늘 남의 평가를 구하는 편이다. 팀원이든 상사든 가리지 않고 나에 대한 평가를 물었다. 칭찬을 들으면 기분이 좋고, 피드백을 들으면 오히려 마음이 편해진다. 모르는 채로 두는 것보다 알고 고치는 쪽이 편한 성격인 것 같다.

그렇게 물어 모은 평가 중 기억에 남는 게 있다. 문제가 생겼을 때 단순히 해결하고 넘어가는 게 아니라, 집요하게 원인을 파고드는 걸 좋아하는 것처럼 보인다는 말이었다. 그 집요함이 팀에 좋은 영향을 줬다고 했다. 개발 자체를 좋아하는 사람처럼 보였다는 말도 들었다.

반대로 아픈 피드백도 있었다. 전반적으로 일은 잘 해내지만, 일이 많아지면 집중력을 잃고 놓치는 게 있다는 것이었다. 내 리드가 준 피드백인데, 듣고 인정했다.

그 뒤로 여러 시도 끝에 정착한 습관이 하나 있다. 어떤 내용이든 머릿속에 담아두지 않는 것이다. 컴퓨터도 메모리가 부족하면 느려지니까, 프로세스를 정리하듯 머리에서 빼내 메모로 옮긴다. 단순히 까먹지 않으려는 것만은 아니다. 그 이상으로, 머리에 짐을 들고 있지 않으면 불안하지 않다. 그리고 불안하지 않으면 정작 집중해야 할 것에 더 집중하게 된다.

마치며

리드로 보낸 1년은, 결국 두 가지를 한 손에 쥐는 일이었다. AI로 팀의 바닥을 받치는 일과, 그 안에서 사람이 마르지 않게 천장을 지키는 일. 둘 중 하나만 택했다면 더 쉬웠을 것이다. AI만 들였다면 빨랐을 테고, 사람만 챙겼다면 익숙했을 것이다. 그 둘을 같이 끌고 가려 한 1년이, 지금까지 가장 일에 몰입한 시간으로 남았다.

이제 그 자료들은 곧 지워진다. 하지만 그 안에서 무엇을 했고 무엇을 배웠는지는 이렇게 글로 남는다. 다음 자리에서도, 나는 같은 두 가지를 한 손에 쥐려 할 것 같다.