대니
danny's blog@dannywon_dev
발행 135 · 대기 183

1인 개발자. 클로드 코드를 팀처럼 굴린다. 매일 겪은 것만 쓴다.

← 클로드 코드

classNo: null 이 반 값을 지웠다 — 페르소나 4개 점검

이름만 고쳤는데 반 값이 null로 지워졌다. 코드를 다시 읽어도 안 보였던 버그를 페르소나 4개가 잡았다

학생 이름의 오타 한 글자를 고치고 저장했다. 그런데 그 학생의 반이 "2-2"에서 빈 값이 됐다. 에러도 없고 경고도 없다. 이름만 바꿨는데 다른 칸이 조용히 사라졌다.

2026-08-24, newbie_school(방과후 e스포츠 코칭 관리 앱)에서 학생 등록칸을 이름만 받던 걸 학번·학년까지 받도록 확장했다. 등록·수정 모달을 만들고, tsc 통과에 브라우저로 등록·수정·삭제까지 직접 눌러 확인한 뒤 "다 됐다"고 여겼다. 그 상태로 넘어가기 전에 페르소나 4개(코치 · 대표님 · 신규 사용자 · QA)를 병렬로 돌려 마지막 점검을 시켰다.

QA 페르소나가 코드를 읽다가 EditModal(학생 정보 수정 창)이 서버로 보내는 값에 classNo: null 이 항상 박혀 있는 걸 발견했다. 데모 DB를 직접 조회해 확인했더니 학생 "권민재"의 반 값이 "2-2"로 들어 있었고, 이름 한 글자만 고쳐도 그 값이 null로 지워졌다.

"안 받는다"를 "지운다"로 짜놨다

이번 기능은 "학번·학년을 새로 받는다"였지 "반을 다룬다"가 아니었다. 그래서 수정 모달에서 classNo 를 아예 안 받고 그냥 null 로 고정해서 보냈다. 내 머릿속에서 그 코드의 뜻은 "이 필드는 이번에 안 건드린다"였다.

그런데 서버 쪽 update 문은 받은 필드를 실제로 덮어쓰는 구조였다. 코드 레벨에서 null 은 "안 건드림"이 아니라 "이 값으로 바꿔라"다. "안 받는다"와 "지운다"가 만든 사람 눈에는 같은 문장처럼 보였다. 내가 직접 등록·수정·삭제를 눌러가며 테스트했는데도 못 봤다 — 새로 넣은 학생에는 애초에 반 값이 없었으니 지워질 것도 없었다.

나머지 세 페르소나는 다른 층을 짚었다

같은 점검에서 코치 페르소나는 입력 흐름을 잡았다. 이름 칸에서 엔터를 치면 학번·학년 없이 그 즉시 등록되는 흐름이었다. 옛 "이름만 치고 엔터" 습관이 그대로 남아 있어서 새로 만든 필드를 건너뛰기가 쉬웠다.

대표님·QA 페르소나는 또 다른 자리에서, 학년에 "abc" 같은 숫자 아닌 값을 넣으면 에러 없이 조용히 빈 값으로 저장되는 걸 짚었다.

네 개가 잡은 문제는 각자 다른 층에 있었다 — 데이터 무결성(QA) · 입력 흐름(코치) · 검증 누락(대표님/QA). 혼자 코드를 다시 읽었다면 "이름만 고쳤는데 반이 왜 지워지지"를 스스로 물을 이유가 없었을 것이다. 내가 짠 의도를 내가 알고 있으니까.

바꾼 것

  • 수정 모달이 반 값을 서버로 그대로 되돌려보내게 고쳤다. 원래 값 유지만 하고, 반을 편집하는 UI는 만들지 않았다
  • 학년 입력에 1~3 범위 검증을 추가해 잘못된 값이 조용히 사라지지 않게 했다
  • 이름 칸의 엔터는 다음 칸(학번)으로 포커스만 옮기고, 마지막 칸에서만 실제 제출되게 흐름을 바꿨다
  • 수정할 때도 학번 중복을 막는 검사를 추가했다. 등록할 땐 있었는데 수정엔 빠져 있었다

서로 다른 관점을 명시적으로 세우고 각자의 눈으로 같은 화면을 보게 하는 것이, 한 번의 검토가 놓치는 자리를 메우는 방법이었다.

← 목록으로