2026-10-08 (목) 개발일지
오늘의 회고 — Godot 게임 머지, 자소서 피드백, 토지 분석 UI까지 세 프로젝트를 동시에 돌렸다
오늘은 세 프로젝트를 병렬로 처리했다. mongle-ranch 게임의 머지 작업 마무리, 자동이력서지원 루틴 정비, 토지이음 등기부등본 분석 UI 고도화가 동시에 진행됐다. 가장 큰 고비는 Godot 쪽에서 pytest 환경이 아예 동작하지 않는 걸 인정하고 NOT VERIFIED로 기록한 결정이었다.
mongle-ranch Task 15 — pytest가 안 도는 환경을 정직하게 보고하기까지
증상
Task 15는 머지된 슬라이스가 자기 검증 기준을 통과하는지 확인하는 최종 태스크였다. farm_runtime_test.gd 13개 체크를 포함한 전체 Godot 스크립트 스위트가 전부 통과했지만, pytest 스위트는 아예 실행할 수 없었다.
단서 수집 + 첫 가설
처음엔 .env.local의 접근 권한 문제라고 생각했다. 실제로 docker ps를 찍어보니 app-db 컨테이너가 healthy 상태로 떠 있었고 “accepting connections” 로그도 찍히고 있었다. 그래서 compose 스택이 정상이라고 판단하고 localhost:5433으로 연결을 시도했다.
원인 추적 — 사고의 진화
연결이 실패했다. 이 compose 설정은 호스트 포트를 공개하지 않았다. 5433이 아니라 컨테이너 내부 포트만 열려 있어서, pytest가 DB에 붙으려면 compose 네트워크 안에서 실행돼야 했다.
여기서 두 가지 선택지가 있었다:
- compose
exec으로 pytest를 컨테이너 안에서 직접 돌린다 migrate이미지에 pytest를 설치해서 실행한다
migrate 이미지를 확인해보니 런타임 이미지라 dev 의존성이 전혀 없었다. pytest를 설치하려면 Dockerfile을 고치거나 별도 이미지를 만들어야 했는데, 그건 태스크 범위를 넘어선다.
핵심 전환점: “pytest가 안 돌아간다”는 사실을 고치려고 하지 말고, 정직하게 NOT VERIFIED로 기록하는 게 맞다는 판단을 내렸다. 남은 컨텍스트를 docker 배관에 쓰면 최종 보고서를 못 낸다.
해결
task-15-report.md에 두 가지 기준을 NOT VERIFIED로 명시했다:
- pytest 전체 패스: 환경이 실행 불가
- 검증 절(clause) 중 compose 의존 항목: 동일한 이유
대신 검증 가능한 항목은 전부 실제로 돌렸다:
- Godot 스크립트 스위트 21개 전부 0 failed
farm_runtime_test.gd13개 체크 0 failedAppShell을 실제 부팅해서 launcher 타일 클릭 후AppState.current_route와 마운트된 화면을 읽는 probe 실행- before/after 라인 수 측정: 10,382줄(42파일) → 20,080줄(77파일)
검증 + 남은 과제
NOT VERIFIED로 기록한 두 항목은 누군가 compose 환경을 갖춘 머신에서 다시 확인해야 한다. task-15-report.md에 “환경이 access-denied여서 읽지 않았다”고 정직하게 적어뒀다.
Task 12 — 라우터 변경이 내 작업 아래에서 일어난 경우 대처
증상
Task 12를 구현하는 도중 c8a56af 커밋이 내 작업 아래에서 다른 사람(혹은 다른 에이전트)에 의해 랜딩됐다. 이 커밋은 app_state.gd의 라우터 pop-to-existing 로직을 바꾼 변경이었다.
단서 수집
HEAD가 f366f74에서 c8a56af로 움직인 걸 발견했다. git log로 확인하니 내가 작업 중인 브랜치에 외부 커밋이 들어온 상태였다. git diff --stat으로 변경된 파일을 확인했다: app_state.gd, settings.gd, app_navigation_test.gd.
원인 추적
처음엔 단순히 rebase로 해결하려 했다. 하지만 문제는 이 라우터 변경이 내가 만든 shell_content_fit_test.gd의 동작 조건을 바꿨을 가능성이었다. pop-to-existing 로직이 바뀌면 네비게이션 스택의 히스토리 정책이 달라지고, 내 테스트가 검증하는 “chip row가 스크롤되는지” 같은 동작이 영향을 받을 수 있다.
해결
rebase 대신 변경된 베이스 위에서 풀 스위트를 재실행했다. 19개 스크립트 전부 0 failed를 확인한 후에야 내 변경사항이 여전히 유효하다는 확신을 얻었다. task-12-report.md에 “베이스가 작업 중에 움직였다”는 사실과 “재확인 후 이상 없음”을 기록했다.
검증
shell_content_fit_test.gd 90개 체크가 변경 전 코드에서 9개 실패하던 게, 변경 후에는 전부 통과했다. 캡처 이미지도 before/after로 남겨서 시각적 검증을 마쳤다.
자동이력서지원 — 자소서 톤 피드백을 룰로 정리한 과정
증상
데이원 FDE 자소서 원고에 대해 “너무 수준 떨어진다”는 피드백이 들어왔다. 구체적으로 “폐쇄망에서 LLM을 작동시키는 일”, “여기서 만들고 싶은 것” 같은 제목이 자소서 맥락에 맞지 않았고, ACL 제출·미채택이 반복적으로 등장하는 문제가 있었다.
단서 수집 + 첫 가설
처음엔 단순히 해당 문장들을 찾아서 바꾸면 된다고 생각했다. 실제로 Gmail에서 예전 자소서 원문을 찾아 비교해보니, “ACL 제출, 미채택”이 3군데에서 등장했다. 이것들을 “LLM 채점 편향 보정 연구를 논문으로 작성했다”로 바꾸는 식으로 수정했다.
원인 추적
하지만 문제는 더 근본적이었다. 자소서 전체의 톤이 “할 수 있는 것”보다 “한계 고백”에 치우쳐 있었다. 예: “어려웠지만”, “부족했지만” 같은 수동적 표현이 많았다.
핵심 전환점: 문장 단위 수정이 아니라 톤 가이드라인 자체를 문서화해야 한다는 판단을 내렸다. 그래야 다음 자소서에서 같은 실수를 반복하지 않는다.
해결
feedback_essay_tone_can_do.md를 작성했다. 핵심 규칙은:
- ACL은 아예 쓰지 않는다 (제출도 미채택도)
- “한 일·할 수 있는 것” 중심으로 쓴다
- 어색한 소제목·과한 보수성 금지
- 애매하면 사용자에게 묻는다
검증
데이원 자소서를 위 규칙에 맞게 재작성해서 PDF로 빌드했다. 지원이력.md에도 반영했다.
토지이음 등기부등본 — 근거 재현 UI의 v2 계획 수립
증상
사용자가 요구한 것은 “최종 5건을 남긴 근거를 수동으로 찾아갈 수 있을 정도로 정교한 다변수 필터 검색 UI”였다. 기존 v1은 단순한 규칙 토글 패널만 있었고, 내가 어떤 판단 과정을 거쳐 최종 5건에 도달했는지 재현할 수 있는 경로가 없었다.
단서 수집 + 첫 가설
처음엔 단순히 필터 조건을 UI에 추가하면 된다고 생각했다. 규칙 토글 패널에 편입비율 슬라이더, 지목 필터, 가액 하한 등을 추가하는 식이었다.
원인 추적
하지만 실제 DB를 열어보니 candidates 테이블이 2,509,056행이었다. 단순 필터로는 5건까지 좁히는 경로를 재현할 수 없다. 내가 실제로 사용한 단계적 퍼널(funnel) 을 UI에 그대로 구현해야 했다.
rulebook.py를 확인해보니 S0부터 S13까지 14단계의 퍼널이 있었다. 각 단계마다 특정 규칙이 적용되고, 그 규칙이 어떤 조건으로 얼마나 많은 후보를 걸러냈는지 기록돼 있었다.
핵심 전환점: “필터”가 아니라 “재현 경로”를 UI로 만들어야 한다. 각 단계를 하나씩 밟아가면서 내가 내린 판단을 사용자가 직접 따라갈 수 있어야 한다.
해결
2026-10-08-evidence-ui.md에 v2 계획을 작성했다:
- FUNNEL 상수를
rulebook.py에 정의: S0~S13 각 단계의 규칙과 기록값 - /api/explore 엔드포인트: cfg 파라미터로 규칙 ON/OFF + 임계값 전달
- /api/funnel: 단계별 현재 카운트와 기록값 비교
- 성능 목표: p95 < 1.5초 (실DB 기준 250만 행)
검증 + 남은 과제
계획 단계에서 멈췄다. 실제 구현은 다음 작업으로 넘어갔다. DESIGN.md에 v2 섹션을 추가하고, scripts/bench_explore.py로 성능 측정 기준을 세웠다.
오늘의 한줄
“안 돌아가는 건 고치려 하지 말고 정직하게 NOT VERIFIED로 기록하라 — 남은 컨텍스트를 배관에 쓰면 최종 보고를 못 낸다.”