Dropbox 보안팀이 설계 단계 위협 모델과 실제 코드 리뷰 사이의 단절을 해결하기 위해 MCP(Model Context Protocol), LLM, Dash를 결합한 자동화 시스템을 구축했다. 구현 PR의 12%만이 원래 보안 설계 문서를 명시적으로 참조하고, 54%는 설계 리뷰 후 한 달 이상 뒤에 열린다는 분석에서 출발했다.

코드 리뷰어가 "이거 실제로 돌아가?"를 검증하는 데 인지 부담이 쏠려 설계 품질 검토가 뒤로 밀린다.

AI 코딩 에이전트 도입으로 코드 생성 속도는 빨라졌지만, 리뷰·검증 결정이 폭증하며 개발자 의사결정 피로가 새 병목으로 부상했다.

AI 기반 개발 생명주기(AI-DLC)를 Brownfield(기존 코드 개선)와 Greenfield(신규 개발) 두 프로젝트에 동시에 적용해야 한다.

AI 코딩 도구가 만들어내는 코드 양이 많아지면서 사람 리뷰어의 병목이 심해진다.

PR 리뷰가 적체되면 개발 속도가 느려진다. 큰 조직일수록 리뷰어 병목 심함.

기존 SAST/DAST 보안 도구는 비즈니스 로직 결함을 못 잡는다. false positive 도 많다.

AI 가 코드를 만들지만 인간이 일일이 다 읽지 않는 시대가 온다. 그러면 코드 리뷰 / 품질 보증은 어떻게 바뀌어야 하나.

큰 조직에서 PR 코드 리뷰 품질을 일관되게 유지하기 어렵다. 리뷰어마다 기준이 다르고 누락도 잦다.

로컬·원격 데이터 동기화 클래스에서 ID 집합 비교 결과를 `localEntryIds`, `remoteEntryIds` 변수에 담아 추가·업데이트·삭제 분기를 만들면, 변수 하나로 여러 의미가 묶여 "고르디우스 변수" 가 된다.

Kotlin 에서 `IntArray` 의 박싱 회피 이점을 살리려 `List<Int>` 를 구현한 `ImmutableIntList` 같은 래퍼를 만들면, 상위 인터페이스의 기본 메서드가 그대로 따라와 의도치 않은 가변 동작·성능 저하가 발생한다.

Vercel Agent가 이제 코드 리뷰를 수행할 때 저장소의 코드 가이드라인 파일을 자동으로 읽고 따른다. AGENTS.md, CLAUDE.md, .cursorrules, .github/copilot-instructions.md 중 존재하는 파일을 모두 읽어 리뷰 기준으로 삼는다. 별도 설정 없이 파일만 저장소에 두면 된다.

`LatestNewsSnippetUseCase` 같이 작은 유스케이스도 리포지터리·포매터·팩토리 등 의존성을 하나씩 추가하다 보면 6~7개가 쌓여 테스트·재사용·이해 비용이 누적된다.

문서화 주석이 함수의 동작을 절차적으로 길게 나열하면 독자는 끝까지 읽어야 의도를 파악한다. 결과적으로 주석이 길어도 이해 비용이 줄지 않는다.

Kotlin data class 의 일부 필드가 자주 변하는 상태라는 이유로 `var` 로 선언되면, 동일 객체를 공유한 여러 곳에서 의도하지 않은 변경이 발생해 버그가 새어 나간다.

UI 요소의 테마 적용 로직을 `FooScreenThemeStrategy` 같은 전용 인터페이스로 추상화하면, 비슷한 다른 화면마다 또 다른 strategy 가 생겨 코드가 늘어난다.

조기 반환(early return)을 남용해 빈 리스트, 1개 원소 같은 에지 케이스마다 별도 분기를 만들면, 주 로직과 동일한 일을 두 번 작성하게 돼 중복·버그가 늘어난다.

`UserProfileViewData` 같은 UI 데이터 모델이 자체 `equals` / `hashCode` 를 직접 오버라이딩하면, 비교 키 선택·해시 계산이 실수로 한쪽만 바뀌어 컬렉션·캐시 동작이 깨진다.

PR 리뷰에 필요한 컨텍스트(Slack 스레드, Jira 이슈, Notion 문서)를 개발자가 직접 수집해야 해 AI가 자율적으로 정보를 탐색하지 못했다.

배포 빈도 증가에 따라 코드 리뷰 부담이 커지면서 기술적 검토와 비즈니스 요구사항 검토를 분리할 필요가 생김.