[개발 회고] 설계의 구조적 취약점을 버그로 만나다
설계의 구조적 취약점을 버그로 만나다
개발 회고 — 2026-07-31 (수)
오늘 작업 요약
기능 완성 마무리 세션으로, 대규모 리팩토링 브랜치의 최종 점검 및 버그 수정을 진행했다. 단위테스트 작성 시도, 두 차례 전체 코드 리뷰, 발견된 버그의 근본 원인 분석, 리뷰 프로세스 자기평가를 거쳐, 같은 종류의 버그가 반복되는 패턴에서 설계 단계의 구조적 취약점을 식별했다.
- 상태 저장 로직의 단위테스트 작성 시도 → 컴포넌트 순환 참조로 격리 불가능, 라이브 검증으로 전환
- 전체 브랜치 코드 리뷰 1차(AI 모델) — 15개 커밋 검토, 중대 버그 1건(배열/스칼라 동기화 어긋남) 발견 및 즉시 수정, 부수 항목 3건 정리
- 페이지 제목이 표시되지 않는 버그 진단 — 반응형 상태 선언 누락 원인 파악, 3가지 해결 방안 제시 및 구현
- 전체 브랜치 코드 리뷰 2차(효율성 관점) — 중대 버그 없음 확인, 부수 항목 3건 정리
- 프레임 접기/펼치기 시 로더 반복 표시 버그 진단 — 근본 원인과 해결책의 트레이드오프 분석 후 현 단계에서는 보류
- 병합 요청(MR) 준비 — 문서 정리, 사용자 직접 병합 요청 오픈
- 사람 리뷰어 피드백 2건 수신 → 동기화 순서 버그 2건 확인 및 수정
- 리뷰 프로세스 자기평가 및 개선점 식별
커밋 요약: 15개 커밋(이전 9개 + 오늘 버그 수정/리뷰 6개)
STAR 정리
Situation (상황)
대규모 리팩토링 브랜치의 최종 검토 단계에서, 복합적인 상태 관리 로직에 여러 종류의 버그가 발견되고 있었다. 처음에는 개별 버그로 보였으나, 같은 종류의 동기화 어긋남이 여러 곳에서 반복되는 패턴을 확인하게 됐다. 또한 상태 관리 계층의 테스트 격리가 불가능하고, 부분 시간 기반 UI 업데이트(제목 반응형)가 조용히 깨지는 문제도 있었다.
Task (과제)
- 상태 저장 로직의 신뢰성을 테스트로 검증
- 전체 브랜치를 시스템 수준에서 검토
- 발견된 버그의 근본 원인을 설계 관점에서 분석
- 반응형 상태 선언 문제 해결
- 로더 표시 문제의 성능 트레이드오프 분석
- 리뷰 프로세스 개선
Action (행동)
- 상태 저장 함수의 동작을 단위테스트로 검증하려 했으나, 컴포넌트 간 순환 참조가 심해서 테스트 격리가 거의 불가능함을 확인함. 테스트 격리를 포기하고 라이브 브라우저 검증으로 전환함
- AI 모델을 사용해 15개 커밋을 전수 검토하고, 프레임 편집 취소 시 배열과 스칼라 상태가 동기화되지 않는 중대 버그를 발견해 즉시 수정함. 동시에 부수적 정리 항목 3건(중복 조건, 불필요한 초기화, 로더 비대칭)도 수정
- 페이지 제목 필드가 여러 상태 관리 모듈에서 일반 필드(반응형 아님)로 선언되어 있는 것을 발견. “단일 소스를 반응형으로 통일”, “모든 필드를 반응형으로 선언”, “전용 접근 함수 경로 추가” 중 세 번째 방안을 선택해 구현
- 2차 리뷰에서 효율성 관점의 추가 정리 항목 3건 확인 및 수정
- 프레임을 접고 펼칠 때마다 데이터 로드 인디케이터가 표시되는 현상을 분석. 레이아웃 크기 변경과 달리, 접기/펼치기는 실제 컴포넌트를 언마운트/리마운트하는 작업이라는 것을 확인하고, 근본 해결책(CSS 숨김, 언마운트 제거)의 백그라운드 리소스 지속 비용을 설명한 뒤 현 단계에서는 보류 결정
- MR 준비 과정에서 문서를 정리하고, 인증 문제로 사용자가 직접 병합 요청을 오픈하기로 함
- 사람 리뷰어의 피드백을 검토한 결과, 프레임 접기 상태 설정 함수의 조기 반환이 스칼라 동기화보다 먼저 실행되는 버그, 페이지 편집 모드 함수의 순서 문제 두 건을 확인하고 즉시 수정
- 리뷰 프로세스를 자기평가하면서, AI 리뷰가 사람 리뷰보다 못 잡은 동기화 순서 버그, 반대로 AI가 먼저 발견했지만 심각도를 잘못 매긴 버그를 분류함. 향후 “동기화 순서 의존성과 조기 반환 뒤의 로직 명시적 추적” 패턴을 리뷰 체크리스트에 추가하기로 결정
Result (결과)
- 상태 저장 로직의 단위테스트는 순환 참조로 격리 불가능하므로, 향후 리팩토링 대상으로 기술 부채 등록
- 배열/스칼라 동기화 어긋남 버그 2건 수정, 반응형 상태 선언 누락 문제 해결
- 로더 반복 표시 버그는 근본 원인 파악했으나 성능 비용으로 인해 현 단계에서는 보류, 향후 계획으로 이월
- 리뷰 프로세스의 개선점(배열/스칼라 이중 표현의 동기화 순서 체크, 반응형 상태 선언 검증, 조기 반환 뒤의 로직 추적) 식별됨
- 병합 요청이 최종 검토 단계까지 진행됨
실제 측정 가능한 지표
| 지표 | 확인 방법 | 비고 |
|---|---|---|
| 검토 대상 커밋 수 | 병합 요청 로그 | 15개 |
| AI 리뷰에서 발견된 버그 | 1차/2차 리뷰 리포트 | 중대 1건, 부수 3건 |
| 사람 리뷰에서 발견된 버그 | 병합 요청 코멘트 | 동기화 순서 버그 2건 |
| 수정된 버그 총 개수 | 오늘 추가 커밋 | 4건 |
| 단위테스트 격리 불가 모듈 | 테스트 시도 분석 | 상태 관리 계층 |
| 반응형 선언 누락 개소 | 코드 검사 | 3개 모듈 |
| 새로 추가될 리뷰 체크리스트 항목 | 자기평가 결과 | 2개 항목 |
추정 가능한 효과 (근거 포함)
- 배열/스칼라 이중 표현 구조 리팩토링으로 버그 원천 차단 (장기 효과, 추정): 현재는 같은 정보를 두 가지 형태로 관리해서 동기화 버그가 반복되는 상태. 향후 단일 소스(배열)로 통합하면, 이런 클래스의 버그가 원천적으로 차단될 것으로 예상됨. 근거: 오늘만 동일한 패턴의 버그 2건 발견, 이전에도 유사 패턴 반복 확인. 실제 리팩토링 후 회귀 빈도 추적 필요
- 리뷰 체크리스트 개선으로 버그 발견율 향상 (추정): 동기화 순서 의존성과 반응형 상태 선언을 명시적으로 확인하는 항목을 추가하면, 다음 리뷰에서 유사 버그를 더 빨리 발견할 가능성이 높아질 것으로 예상됨. 근거: 이번 리뷰에서 이 두 패턴이 각각 AI와 사람 리뷰에서 다르게 발견됨. 다음 리뷰 라운드에서 효과 검증 가능
더 측정하면 좋은 지표
- AI vs 사람 리뷰의 보완성 분석: 여러 브랜치에서 누적 데이터 수집해 두 리뷰 방식의 상호 보완 패턴 분석
- 순환 참조 제거 후 테스트 격리 재검토: 구조 개선 후 단위테스트 작성 가능 여부 확인
- 배열/스칼라 통합 리팩토링의 실제 효과: 단일 소스로 통합한 후 버그 발생 빈도 추적
- 로더 반복 표시의 사용자 불편도 vs 성능 비용: 사용자 피드백 수집해 우선순위 재평가
- 개선된 리뷰 체크리스트의 실제 효과: 차기 주요 리뷰에서 발견율 개선 측정
오늘 배운 것
- 같은 정보를 배열과 스칼라 두 가지 형태로 동시에 관리하면, 동기화 순서에 따라 버그가 반복 발생하는 구조적 취약점이 생긴다는 것을 명확히 확인함. 이는 구현 실수가 아니라 설계 단계의 문제
- 반응형 상태 선언 누락처럼 “조용하게” 기능이 깨지는 버그는 정적 분석보다 명시적 체크리스트 기반 검증이 필요하다는 것을 배움
- AI 전체 코드 리뷰와 사람 리뷰어의 동시 활용이 상호 보완적임을 실감함. 각각 다른 버그를 발견하므로 둘 다 거치는 가치가 높음
- 동기화 순서 어긋남처럼 미묘한 버그는 단순 조건 검사로는 놓치기 쉽고, “조기 반환 뒤의 로직도 함께 추적”하는 명시적 패턴이 리뷰에 필수라는 것을 배움
- 근본 해결책이 있어도 성능/리소스 비용이 있으면 우선순위를 재평가하고 트레이드오프를 명확히 해야 한다는 점
어려웠던 점 / 막힌 부분
- 상태 관리 계층의 단위테스트 작성을 시도했으나, 컴포넌트 간 순환 참조가 깊어서 mock 설정이 거의 불가능했음. 테스트 격리를 포기하고 라이브 검증으로 방향을 바꾸게 됨. 기술 부채로 등록 필요
- 배열/스칼라 동기화 버그의 근본 원인은 “조기 반환이 동기화 로직보다 먼저 실행”이라는 순서 문제지만, 코드상 1줄 위치 차이라서 직관적으로 발견하기 어려웠음
- 로더 반복 표시 버그의 근본 해결책이 백그라운드에서 계속 렌더링 비용을 발생시킨다는 트레이드오프 때문에, 현 단계에서 보류하기로 결정하는 과정에서 비용/효과의 명확한 수치화가 어려웠음
- AI 리뷰가 사람 리뷰보다 동기화 순서 버그를 못 잡은 것에 대한 자기평가. “우회 쓰기 확인” 항목이 동기화 순서 의존성의 사각지대였던 것으로 분석됨
내일 하면 좋은 작업
- 기능 완성 병합 요청 검토 후 메인 브랜치 병합
- 메인 브랜치 통합 후 상태 확인
- 구조적 위험 메모 — “배열 + 스칼라 이중 표현” 전수조사 및 리팩토링 우선순위 논의
- 단위테스트 격리 불가 문제(순환 참조) — 기술 부채로 등록 검토
- 리뷰 체크리스트 갱신 — 조기 반환 뒤 동기화/상태 업데이트 명시적 추적 항목 추가
한 줄 요약
기능 완성 마무리 세션으로 동기화 버그 4건을 발견/수정하고, 같은 패턴의 반복 버그에서 설계 자체의 구조적 취약점을 발견한 하루였다.
댓글남기기