전투 난수에 기준값을 두어 같은 조건의 결과를 다시 볼 수 있게 하고, 개발 초기에 밸런스를 수치로 확인하는 도구를 먼저 만들었습니다. 출시 뒤 기기 발열 리뷰가 이어지자 같은 전투를 두 엔진에서 돌려 CPU 사용량을 재 보고(약 55% 감소), 웹 기반 앱에서 Godot 엔진으로 전체를 옮겼습니다.

LLM 대화 레이어와 결정론적인 설계 데이터 모델(존·집기·치수)을 분리했습니다. 대화는 의도와 전략을 받고, 평면은 검증 가능한 구조화 데이터로 두어 2D·3D 렌더와 DXF 익스포트가 같은 데이터를 보고 나오게 했습니다. 전략도 하나로 단정하지 않고 여러 안을 근거와 함께 제시해 사람이 고르게 했습니다.

‘엔진 결과를 원본으로 두고 프론트엔드의 재분류·보정을 금지한다’는 경계를 세웠습니다. 결과를 화면에서 손대기 시작하면 어디가 진짜인지 알 수 없게 되기 때문입니다.

오탐이 쌓이면 사람들이 알림을 안 보게 되고, 그러면 알림은 있으나 마나입니다. 그래서 공개 채널에 뿌리는 대신 의심 지점을 몇 건으로 좁혀 담당자에게 조용히 DM으로 보내고, 진단 신뢰도는 퍼센트 대신 세 단계 말(확실·추정·가설)로만 보여주게 했습니다.

‘품질은 더 똑똑한 모델의 문제가 아니라 생성과 검증을 분리하는 구조의 문제’라고 봤습니다. 모델을 바꾸는 대신 Claude Code의 훅·커맨드·에이전트 기능을 조합해, 독립 평가자를 통과하지 못한 코드는 커밋되지 않게 만들었습니다.

이미 MSA로 나뉜 환경에서 제가 판단한 건, 서비스를 더 쪼개는 게 아니라 무엇을 같은 트랜잭션에 둘지·어디서 장애를 격리할지였습니다. 동기 호출을 Coroutine·WebFlux 비동기로 바꾸고, 매물 배치 알림을 순차에서 병렬 처리로 개선해 한 서비스의 지연·블로킹이 옆으로 번지지 않게 했습니다.

행정동 단위로 진행 상태(마지막 위치)를 저장해, 차단이나 중단이 나도 처음이 아니라 마지막 지점부터 재개하게 했습니다. 접속 제한·오류 응답(429·403·5xx)에는 잠시 멈췄다가 요청 간격을 늘려 재시도하고(백오프·서킷브레이커), 차단 신호가 일정 수준 이상 쌓이면 크롤러가 스스로 수집을 멈추게 했습니다.

복잡한 금융 규제(DSR·LTV·취득세·정책대출)를 외부 의존이 없는 순수 TypeScript 함수로 구현했습니다. ‘규제 로직은 테스트로 증명되어야 한다’고 봤기 때문입니다.

건축 계산은 직접 구현하지 않고 외부 설계 엔진에 위임하고, 백엔드는 데이터 통합·좌표계 변환·규제 조회에 집중했습니다. ‘잘하는 곳에 맡기되 경계를 분명히 한다’는 판단이었습니다.

기획서(PRD)에 성공 확신 대신 ‘성공 확률 55%, 이런 조건이 확인되면 계속 진행’이라는 판단 기준을 그대로 적고, 사업 전체를 이 단 하나의 GO/NO-GO 관문에 걸었습니다.

‘파일에 절대 쓰지 않는다(read-only)’를 제품 정체성으로 못박았습니다. 편집은 사용자 에디터에 맡기고, 앱은 발견·열람·재진입에만 집중했습니다.