Agent 개발 시대, 팀 개발은 어떻게 달라질까?
개발은 빨라졌는데, 팀도 같이 빨라졌을까요?
요즘 팀에서 이런 말을 자주 듣습니다.
“PR이 빠르게 올라오네?”
“오늘만 몇 개야…”
“기획자님, 더 개발할 것 있나요?”
에이전트를 쓰면 코드를 만드는 속도는 빨라집니다.
예전에는 며칠 걸리던 일도 몇 시간 안에 끝냅니다.
그런데 팀 개발은 조금 다릅니다.
코드를 빨리 만드는 것만으로는 부족합니다.
누군가는 그 코드를 읽고 확인해야 합니다.
다른 코드와 잘 맞는지도 봐야 합니다.
PR은 계속 올라오는데 리뷰할 사람은 그대로라면 어떨까요?
“PR 언제 다 보냐?”
“리뷰 에이전트를 하나 더 쓰자.”
“그러면 그 리뷰가 맞는지도 확인해야 하는 거 아냐?”
개발 속도는 빨라졌습니다.
이번에는 확인하는 일이 많아졌습니다.
PR이 늘면서 리뷰가 지연되는 상황
같은 팀인데 AI를 쓰는 방법은 다릅니다
같은 팀에서도 에이전트를 쓰는 방법은 모두 다릅니다.
윤 개발자는 여러 에이전트를 동시에 사용합니다.
“저는 병렬 에이전트 방식으로 해요.”
김 개발자는 설계와 인터페이스를 직접 정합니다.
구현만 에이전트에 맡깁니다.
홍 개발자는 에이전트와 계속 대화합니다.
코드를 한 줄씩 확인하면서 진행합니다.
누가 맞고 누가 틀린 문제는 아닙니다.
일의 종류와 개발자의 경험이 다르니까요.
문제는 서로 어떻게 일하는지 모를 때 생깁니다.
한 사람은 에이전트가 만든 코드를 거의 믿지 않습니다.
“난 사실 잘 안 믿어요.”
다른 사람은 에이전트의 결과를 그대로 사용합니다.
“이걸 또 검사한다고? 충분하지 않아?”
이 차이가 크면 리뷰 기준도 달라집니다.
PR을 올리는 기준도 달라집니다.
팀에서 합의하지 않으면 같은 저장소 안에 서로 다른 기준이 섞입니다.
같은 팀에서도 AI 사용법이 다른 사례
FE와 BE를 나누던 기준도 달라집니다
에이전트를 쓰면 해보지 않은 일도 시도하기 쉬워집니다.
프론트엔드 개발자가 API를 만듭니다.
“API 생성은 제가 해도 되나요?”
백엔드 개발자가 React로 백오피스를 만듭니다.
“간단한 화면이라 제가 만들었어요.”
이 변화 자체는 나쁘지 않습니다.
기다리지 않고 직접 끝낼 수 있으니까요.
다만 익숙하지 않은 분야에서는 놓치는 부분이 생깁니다.
화면은 동작하지만 사용하기 불편할 수 있습니다.
API는 응답하지만 인증 처리가 부족할 수 있습니다.
그래서 예전처럼 “이건 FE 일, 저건 BE 일”만 따지기 어렵습니다.
대신 누가 만들든 해당 분야의 기준으로 확인하는 방법이 필요합니다.
코드도 조금씩 달라집니다
어제는 이렇게 만들었습니다.
export function activeUsers(users) {
return users.filter(user => user.active)
}
오늘은 같은 일을 이렇게 만들었습니다.
const getActiveUsers = (list) =>
list.filter(({ active }) => active === true)
두 코드 모두 동작합니다.
하지만 이런 차이가 계속 늘어나면 코드 읽기가 어려워집니다.
비슷한 함수가 여러 곳에 생길 수도 있습니다.
“기존 코드를 고치지 말고 새로 만드는 게 빠르겠네요.”
에이전트는 이런 선택을 쉽게 합니다.
기존 코드를 충분히 찾지 않고 새 코드를 만들기도 합니다.
GitClear가 2026년에 공개한 분석에서는
중복된 코드 블록이 2023년보다 81% 늘었습니다.
이 수치가 모든 AI 코드를 나쁘다고 말하지는 않습니다.
다만 코드를 만드는 속도만 보고 안심하면 안 된다는 뜻은 분명합니다.
출처: GitClear, The AI Code Quality Maintainability Gap, 2026
날마다 달라진 코드 작성 방식
아주 긴 표준부터 만들 필요는 없습니다
이쯤 되면 이런 생각이 듭니다.
“회사 전체가 따를 AI 개발 표준을 만들자!”
TF 이름도 길어집니다.
“더 이상 제각각 개발하지 않고
품질을 보장하는 전사 표준 AI 개발 방식 만들기 TF”
한 달 동안 열심히 정리합니다.
그런데 한 달 뒤에 이런 말을 들을 수 있습니다.
“클로드 코드에서 이 기능을 새로 지원하고 있습니다.”
AI 도구는 자주 바뀝니다.
처음부터 큰 표준을 완성하려 하면 금방 고칠 일이 생깁니다.
그래서 저는 표준을 먼저 만들기보다 경험을 먼저 공유하는 방법을 추천합니다.
1. 표준보다 먼저 경험을 공유해보세요
지난주에 에이전트로 개발한 사례를 하나씩 가져옵니다.
어떤 문제가 있었는지 말합니다.
무엇을 시도했는지 말합니다.
결과가 어땠는지도 확인합니다.
가능하면 느낌만 말하지 않습니다.
작업 시간이 얼마나 줄었는지 봅니다.
리뷰에서 수정한 내용이 몇 개였는지도 봅니다.
테스트를 몇 번 다시 실행했는지도 봅니다.
여러 사람이 비슷한 방법으로 좋은 결과를 냈다면
그때 팀의 방법으로 사용해봅니다.
순서는 단순합니다.
- 실제 사례 공유하기
- 결과를 함께 확인하기
- 여러 번 효과가 있던 방법을 팀에서 써보기
- 다시 사례를 모으고 고치기
누군가 한 번 잘됐다고 바로 규칙으로 만들 필요는 없습니다.
여러 번 확인한 방법부터 넣으면 됩니다.
사례 공유에서 팀 기준으로 이어지는 순서
2. 팀 규칙은 적게 시작하세요
팀에서 반복해서 나온 방법은 파일에 적습니다.
AGENTS.md나 CLAUDE.md 같은 파일을 쓸 수 있습니다.
처음부터 많은 규칙을 넣을 필요는 없습니다.
예를 들면 이 정도로 시작할 수 있습니다.
# AGENTS.md
- 인증과 결제 코드는 사람이 꼭 확인한다.
- 새 API를 만들면 테스트도 함께 작성한다.
- 기존 코드를 먼저 찾고, 비슷한 함수를 새로 만들지 않는다.
- PR에는 AI가 만든 부분을 적는다.
중요한 규칙은 에이전트가 작업할 때마다 확인하게 합니다.
테스트나 검사 명령으로 확인할 수 있다면 작업 순서에도 넣습니다.
규칙을 고치는 방법도 정해야 합니다.
한 사람이 몰래 바꾸지 않습니다.
PR을 올리고 팀원이 함께 봅니다.
“이번에도 같은 문제가 나왔네.”
“그럼 이제 규칙에 추가하자.”
이 정도면 충분합니다.
3. 사람과 AI가 할 일을 정해두세요
팀원마다 에이전트에 맡기는 범위가 다릅니다.
어떤 사람은 코드 전체를 맡깁니다.
어떤 사람은 테스트만 맡깁니다.
어떤 사람은 코드 설명에만 씁니다.
모든 사람이 똑같이 쓸 필요는 없습니다.
다만 세 가지는 함께 정하는 편이 좋습니다.
첫째, 에이전트에 맡겨도 되는 범위입니다.
둘째, 사람이 꼭 확인할 부분입니다.
셋째, 작업을 끝냈다고 판단할 기준입니다.
인증, 결제, 개인정보, 복잡한 조건문은
사람이 꼭 확인할 부분으로 정할 수 있습니다.
반복 작업이나 테스트 초안은
에이전트에 더 많이 맡길 수 있습니다.
테스트 커버리지 80%처럼 숫자로 정할 수도 있습니다.
하지만 숫자 하나만 맞추고 끝내면 안 됩니다.
중요한 기능이 실제로 동작하는지도 봐야 합니다.
4. 무엇을 확인할지도 함께 맞추세요
“확인했습니다.”
이 말만으로는 무엇을 봤는지 알 수 없습니다.
팀에서 중요한 확인 항목을 정해두면 좋습니다.
- 요구사항대로 동작하는지 확인하기
- 팀의 코드 작성 규칙을 지켰는지 확인하기
- 인증과 데이터 처리가 안전한지 확인하기
- 중요한 테스트를 실행했는지 확인하기
모든 PR을 똑같이 볼 필요는 없습니다.
문구 수정과 결제 로직은 위험이 다릅니다.
위험한 작업일수록 사람이 더 자세히 봅니다.
PR에 위험도를 적는 방법도 쓸 수 있습니다.
위험도: 높음
이유: 결제 실패 뒤 환불 처리 방식이 바뀜
사람이 꼭 볼 부분: 중복 결제와 부분 환불
이렇게 적으면 리뷰어가 어디부터 봐야 하는지 바로 압니다.
팀이 함께 맞출 네 가지 검증 항목
5. 결론만 남기지 말고 이유도 남기세요
몇 달 뒤에 이런 질문이 나옵니다.
“왜 우리가 이 방법으로 하기로 했죠?”
그때 결론만 남아 있으면 다시 처음부터 확인해야 합니다.
중요한 선택은 과정과 이유를 함께 적습니다.
결론: 환불 요청은 비동기로 처리한다.
확인한 내용:
- 결제 회사의 응답이 늦을 수 있음
- 같은 요청이 두 번 들어올 수 있음
이 방법을 고른 이유:
- API 응답이 오래 걸리는 문제를 줄일 수 있음
- 중복 요청을 따로 처리하기 쉬움
모든 결정을 이렇게 길게 적을 필요는 없습니다.
나중에 다시 물을 가능성이 있는 결정만 남깁니다.
되돌리기 어려운 결정도 이유를 남깁니다.
6. 직접 설명하는 시간도 필요합니다
문서만으로 충분하지 않을 때가 있습니다.
화이트보드 앞에서 구조를 직접 그려봅니다.
왜 이 구조를 골랐는지 동료에게 설명합니다.
설명하다가 막히면 아직 이해하지 못한 부분이 있다는 뜻입니다.
에이전트가 만든 내용을 그대로 받아들였는지도 알 수 있습니다.
본인이 이해했다면 다른 사람에게도 설명할 수 있습니다.
긴 회의가 꼭 필요한 것은 아닙니다.
변경이 큰 날에 20분만 함께 봐도 됩니다.
PR을 올린 사람이 구조와 선택 이유를 설명하면 됩니다.
이 시간은 코드를 다시 읽는 데만 쓰지 않습니다.
서로 무엇을 알고 있는지 확인하는 데 씁니다.
7. 낯선 분야는 전문가에게 물어보세요
백엔드 개발자가 프론트엔드 코드를 만들 수 있습니다.
프론트엔드 개발자가 배포 설정을 만들 수도 있습니다.
못 하게 막을 필요는 없습니다.
대신 그 분야를 잘 아는 사람이 확인을 도와주면 좋습니다.
“이 화면은 키보드로도 사용할 수 있나요?”
“이 API는 같은 요청이 두 번 들어오면 어떻게 되나요?”
전문가는 모든 일을 대신하지 않습니다.
모든 PR을 승인하는 사람도 아닙니다.
기준과 주의할 점을 알려주는 역할이면 충분합니다.
그래야 새로운 일을 맡은 개발자도 배울 수 있습니다.
8. PR에는 솔직하게 적으세요
에이전트로 만든 PR일수록 설명이 더 필요합니다.
코드가 많으면 리뷰어가 모든 배경을 다시 확인하기 어렵습니다.
PR에는 다음 내용을 적어두세요.
- 이 PR의 목적
- 다른 방법 대신 이 방법을 고른 이유
- 에이전트가 만든 부분
- 사람이 꼭 확인해야 할 부분
- 실행한 테스트와 결과
PR에 함께 적을 내용
예를 들면 이렇습니다.
## 목적
결제 실패 뒤 재시도할 수 있게 합니다.
## 선택 이유
새 결제 요청을 만들지 않고 기존 요청 상태를 다시 확인합니다.
## AI가 만든 부분
재시도 API와 단위 테스트 초안
## 사람이 꼭 볼 부분
중복 결제 가능성과 실패 횟수 제한
## 확인
- 단위 테스트 18개 통과
- 결제 실패 뒤 재시도 확인
리뷰어는 코드를 만든 과정을 모두 볼 수 없습니다.
그래서 작성자가 먼저 알려줘야 합니다.
어디를 조심해서 봐야 하는지 솔직하게 적어야 합니다.
9. 에이전트의 작업 기록도 남기세요
에이전트가 무엇을 바꿨는지 남깁니다.
어려운 문제를 어떻게 풀었는지도 남깁니다.
어떤 테스트를 실행했는지도 남깁니다.
기록이 있으면 문제가 생겼을 때 다시 확인하기 쉽습니다.
작업 내용:
- PaymentService 재시도 로직 수정
- 중복 요청 검사 추가
특이사항:
- 기존 테스트 2개가 현재 정책과 맞지 않아 별도 표시
실행한 확인:
- pnpm test payment
- pnpm lint
에이전트 작업에서 남길 세 가지 기록
기록을 길게 만들 필요는 없습니다.
다음 사람이 작업을 이어갈 수 있을 만큼만 남기면 됩니다.
결국 중요한 것은 개발자끼리의 소통입니다
에이전트와 대화하는 시간은 늘었습니다.
그렇다고 팀원끼리 대화하는 시간을 줄이면 안 됩니다.
각자 에이전트와만 이야기하면
다른 팀원이 어떤 방법으로 일하는지 알 수 없습니다.
팀이 함께 정해야 할 것이 있습니다.
어디까지 에이전트에 맡길지 정해야 합니다.
무엇을 사람이 꼭 확인할지 정해야 합니다.
어떤 결과를 팀의 좋은 사례로 삼을지도 정해야 합니다.
처음부터 완성된 표준은 필요 없습니다.
실제 사례를 공유합니다.
효과를 확인합니다.
여러 번 맞았던 방법을 규칙에 추가합니다.
그리고 중요한 결정은 이유와 함께 남깁니다.
에이전트가 코드를 빨리 만들수록
개발자끼리 더 자주 설명하고 확인해야 합니다.
참고 영상
