개발팀 기술 논쟁 줄이는 법: 코드 리뷰·ADR·작은 실험으로 결정하기

개발 회의에서 “A가 더 깔끔하다”와 “B가 더 빠르다”가 부딪히면 말이 센 사람이 이기기 쉽다. 하지만 좋은 기술 결정은 사람의 확신이 아니라 사용자 요구, 측정 기준, 작은 실험, 되돌릴 방법으로 설명할 수 있어야 한다. 논쟁을 없애는 것이 아니라 논쟁이 코드와 기록을 개선하게 만드는 과정이 필요하다.

실전 상황

관리자 화면의 검색 기능을 서버에서 처리할지 브라우저에서 처리할지 팀 의견이 갈렸다. “요즘은 클라이언트가 빠르다”와 “서버가 안전하다”는 주장만 오갔지만 데이터 건수, 권한, 응답시간, 운영 비용은 아무도 적지 않았다.

목차

1. 사람과 아이디어를 분리하는 리뷰 문장
2. 의견을 비교 기준으로 바꾸는 법
3. 작은 실험으로 불확실성을 줄이는 법
4. ADR에 결정과 되돌림 조건을 남기는 법
5. 의사결정 트리를 사용할 때와 피할 때

1. 리뷰는 개발자가 아니라 변경을 다룬다

Google의 코드 리뷰 지침은 친절하면서도 명확하게 말하고, 왜 바꿔야 하는지 설명하며, 사람 대신 코드를 대상으로 의견을 쓰라고 권한다. “왜 이렇게 했어요?”보다 관찰한 위험과 사용자 영향을 적으면 방어적인 대화를 줄일 수 있다.

피할 표현	바꾼 표현	달라지는 점
이 설계는 잘못됐어요.	현재 구조에서는 권한 필터가 브라우저에 남아 다른 사용자의 데이터가 노출될 수 있습니다.	사람 평가를 구체적인 위험으로 바꾼다.
무조건 서버에서 해야죠.	권한 검사는 서버에 두고, 정렬만 브라우저에서 처리하는 안을 비교해 보면 어떨까요?	대안을 검증 가능한 단위로 나눈다.
이건 별로예요.	Blocking: 권한 우회 가능성. Optional: 함수명 개선.	필수 수정과 선호를 분리한다.

리뷰 댓글의 기본 구조

관찰 → 영향 → 근거 → 제안. “현재 필터가 클라이언트에만 있습니다 → URL을 바꾸면 다른 데이터가 보일 수 있습니다 → 권한 테스트가 실패합니다 → 서버 쿼리에 사용자 조건을 추가해 주세요.”

합의가 안 되면 논점을 한 단계씩 좁힌다

댓글을 길게 주고받기 전에 서로 같은 문제를 보고 있는지 확인한다. 보안처럼 반드시 막아야 하는 위험인지, 성능처럼 측정할 수 있는 가설인지, 팀 규칙으로 이미 정해진 스타일인지, 개인 선호인지 구분한다. Google의 코드 리뷰 기준도 기술적 사실과 데이터가 의견과 개인 선호보다 우선한다고 설명한다.

• 필수 위험이면 테스트와 정책 근거를 제시한다.
• 성능 주장이라면 같은 조건의 짧은 벤치마크를 만든다.
• 유효한 선택지가 여러 개라면 기존 코드와의 일관성을 따른다.
• 그래도 결정되지 않으면 대면으로 논의하고 결론을 리뷰 기록에 남긴다.

728x90

2. 의견을 측정 가능한 기준으로 바꾼다

기술 선택표의 목적은 숫자로 정답을 꾸미는 것이 아니다. 무엇을 중요하게 보는지 드러내고, 빠진 조건을 찾는 데 있다. 기준과 가중치는 실험 전에 합의한다.

기준	서버 검색	브라우저 검색	확인 방법
권한 경계	서버 쿼리에서 강제	전체 데이터 전달 시 위험	다른 사용자 ID로 API 테스트
데이터 규모	페이지 단위 조회	초기 다운로드 증가	1천·10만 건 응답 크기 비교
응답성	네트워크 왕복 필요	이미 받은 데이터는 즉시	p50·p95 입력 응답시간 측정
운영 복잡도	인덱스와 API 관리	상태·메모리 관리	코드량보다 실패 지점과 관측성 비교
되돌림	API 버전으로 전환	기능 플래그로 전환	롤백 절차를 실제로 실행

3. 작은 실험은 승자를 고르는 행사가 아니다

질문기준최소 구현측정결정 기록

두 방식을 완성품 수준으로 모두 만드는 것은 낭비다. 가장 불확실하고 치명적인 가정 하나를 먼저 검증한다. 검색 사례라면 10만 건에서의 p95 응답시간과 권한 우회 여부만으로도 많은 선택지를 제거할 수 있다.

가설: 서버 검색은 10만 건에서도 p95 300ms 안에 응답한다.
고정 조건: 같은 데이터, 같은 검색어 50개, 같은 네트워크
측정: p50/p95, 응답 크기, DB CPU, 권한 테스트
중단 조건: 권한 우회 1건 또는 p95 500ms 초과
결과: 수치와 실패 로그를 저장하고 결정 회의 전에 공유

벤치마크도 질문이 틀리면 답이 틀린다.

작은 샘플의 평균만 비교하거나 서로 다른 캐시 상태를 사용하면 원하는 결론을 만드는 숫자가 된다. 데이터 규모, 워밍업, 반복 횟수, 실패 조건을 함께 기록한다.

4. ADR은 결정의 ‘왜’를 미래 팀원에게 남긴다

Architecture Decision Record는 중요한 설계 선택과 근거, 대안, 결과를 한 문서에 남긴다. 긴 회의록과 다르다. 결정 하나를 다루고 언제 다시 검토할지도 적는다.

# ADR-004: 관리자 검색은 서버에서 처리한다

## 상태
승인 — 2026-07-28

## 맥락
최대 10만 건, 행 단위 권한 필요, 목표 p95 300ms

## 선택
서버 검색 + 커서 페이지네이션 + 사용자 권한 조건

## 대안
- 브라우저 전체 검색: 초기 전송량과 권한 경계 때문에 제외
- 외부 검색엔진: 현재 규모에는 운영 비용이 큼

## 결과
서버 인덱스 관리 필요. 브라우저 메모리 사용 감소.

## 재검토 조건
p95 500ms 초과가 7일 지속되거나 데이터가 100만 건을 넘을 때

결정이 바뀌면 예전 ADR을 지우지 않고 대체된 상태로 표시하고 새 ADR을 연결한다. 그래야 같은 논쟁을 다시 시작하지 않고 당시 조건이 달라졌는지 확인할 수 있다.

5. 의사결정 트리는 규칙이 명확할 때만 쓴다

기존 글에서 소개한 트리 시각화는 복잡한 분기와 모델 판단 경로를 설명할 때 유용하다. scikit-learn의 plot_tree는 특성명, 클래스명, 깊이, 표본 수 등을 표시할 수 있다. 그러나 팀의 모든 결정을 트리로 만들 필요는 없다.

• 잘 맞는 경우: 입력 조건이 반복되고 분기 기준을 명확히 설명해야 할 때
• 맞지 않는 경우: 가치 판단과 장기 비용처럼 숫자 하나로 나누기 어려울 때
• 주의: 학습된 트리의 분기는 인과관계가 아니라 데이터에서 찾은 분할 규칙이다.

핵심 요약

• 리뷰는 사람 대신 코드의 관찰 가능한 위험과 사용자 영향을 말한다.
• 기술 의견은 권한, 성능, 비용, 운영, 되돌림 기준으로 바꾼다.
• 가장 불확실한 가정 하나를 작은 실험으로 먼저 확인한다.
• ADR에는 선택뿐 아니라 대안, 결과, 재검토 조건을 남긴다.

참고한 공식 자료

• Google Engineering Practices: 리뷰 댓글 작성법
• Google Engineering Practices: 코드 리뷰 기준
• Architectural Decision Records
• scikit-learn: plot_tree

확인 기준일: 2026년 7월 28일. 기존 글의 검증되지 않은 PlayStation 디스크 종료 주장은 보존하지 않았다.