2026-10-21 (수) 개발일지
오늘은 세 프로젝트를 동시에 돌리면서 각각 다른 성격의 문제들을 정리했다. 하네스에서는 테스트 픽스처를 실제 eval로 검증하는 과정에서 규칙 수정의 필요성을 판단했고, 자동이력서지원에서는 9/21 결제 건의 추적 경로를 복원하던 중 시간 제약을 마주쳤으며, 사주 프로젝트에서는 push 전 민감정보 노출을 체계적으로 차단했다.
하네스 — 규칙 수정 필요성을 eval 결과로 판단한 이유
기존 테스트는 모두 통과했는데, 진짜 문제는 수정한 규칙이 실제 동작에서 필요한지 여부였다. N7 케이스(기획 수정 시 contracts/ 까지 고치는 규칙)를 두고 고민이 많았다.
처음엔 규칙 텍스트를 수정해서 모든 케이스를 통과시키려는 접근이었다. 하지만 이건 본질적 질문을 놓치고 있었다 — 이 규칙 수정이 정말 필요한가? 단순히 테스트를 통과시키는 것과 실제 동작 개선은 다르니까.
그래서 방향을 바꿨다. red 실행(수정 전 규칙, 2케이스×2회)을 돌려 기존 상태를 확인했다. 그 결과가 나올 때까지 규칙 텍스트는 건드리지 않았다 — 진행 중인 eval 이 규칙 파일을 읽고 있었기 때문이다. 결과를 받은 뒤 green 실행(수정 후 규칙)을 돌렸다.
N7은 수정 전후 모두 3/3 통과했다. 즉, 규칙 수정이 없어도 충분했다는 뜻이다.
이 발견이 중요했다. 회귀 방지 케이스로는 커밋했지만(40c697a), 규칙 자체 변경은 기각했다. 규칙을 고치면 다른 케이스에 영향을 미칠 수 있고, 이미 통과하는 것을 건드릴 이유가 없었다.
검증 방식: red/green 두 번의 eval 을 순차 실행해서 수정 전후 동작을 객관적으로 비교했다. 테스트 통과만으로는 알 수 없는 “규칙 변경의 필요성” 을 데이터로 판단했다.
남은 과제: P1의 다른 케이스들도 같은 방식으로 검증해야 한다. 지금까지는 N8·N7 두 건만 완료.
자동이력서지원 — 9/21 결제 건 추적 중 시간 한도 마주침
9/21 15:30 무렵 한 활동을 복원하려고 Chrome 방문 기록과 Gmail 임시보관함을 대조했다. 결제처를 특정하는 게 목표였다.
단서 수집:
- 13:11~14:18: Aside 설정의 Plan & Usage(요금제 결제) 화면을 네 번 열었다
- 15:25~15:31: Gmail 임시보관함에서 중국은행 메일, 그리고 인증번호 546367을 SK에코플랜트 머티리얼즈 세션에 넘겼다
인증번호는 11:12에 발송되고 유효시간이 3분이었다. 그 사이에 뭔가 일어났는데, 만료됐으면 화면의 ‘시간연장’을 누르거나 새로 발송받아야 한다는 걸 알았다.
하지만 codex 검수 한도가 20:26까지 막혀있었다. 16:30에 돌린 검수는 16문항 중 3개만 처리했다. 9/21 건의 결제처를 완전히 확정하려면 더 깊이 파야 하는데, 지금은 한도 때문에 못 한다.
현황: 지원 대상 12건이 동시에 진행 중이다. 메리츠증권과 딜로는 회원가입 단계에 있고, 메리츠증권은 자소서 3문항 초안까지 썼다. 근거 자료와의 대조 검수도 시작했지만, 한도 제약이 병목이다.
남은 과제: 한도가 풀린 뒤 9/21 건을 다시 추적하고, 16문항 중 미처리된 13개를 codex 검수로 마무리해야 한다.
사주 프로젝트 — push 전 민감정보 노출 체계적 차단
release_st 브랜치에 커밋(459ef94)하고 원격에 push 하기 전에, 올라갈 변경분 전체에서 민감정보 패턴을 검사했다.
커밋 내용:
docs/창업지원서_수정본.md한 파일만 포함- 추가 줄: 261줄
- 함께 올라간 것:
release_st는tr-test스냅샷 커밋 위에서 만든 브랜치라, 그 커밋까지 원격에 함께 올라갔다
민감정보 검사:
.env파일은 추적되지 않고.env.example만 올라간다 — 이미 안전하게 설정되어 있었다- push 전에 올라갈 커밋들에서 API 키·토큰·개인키 패턴을 전체 스캔했다
- 폴더에 원래 있던 미추적 파일들(
.omc/,src/, 이미지 등)은 커밋에 넣지 않았다
검사 결과: 민감정보 패턴이 나오지 않았다. 올라갈 변경분이 깨끗한 상태였다.
검증: 로컬 브랜치가 origin/release_st를 정확히 따라가는 상태를 확인했다. 이제 원격과 로컬이 동기화됐다.
남은 과제: 다른 브랜치의 미처리 커밋들도 push 전에 같은 검사를 돌릴 필요가 있다.
오늘의 한줄
eval 결과로 규칙 수정의 필요성을 판단하고, 한도 제약 속에서 우선순위를 정하고, push 전에 민감정보를 체계적으로 차단하는 — 세 프로젝트가 각각 다른 방식의 검증 문화를 보여줬다.