YDMmobile / oss
KOEN

만들며 배운 것을 남깁니다.

Category
  1. 61

    A Green Gate Only Proves What Its Reader Can See

    Four localization gates were green. The English screen was still wrong. The key existed. The value was non-empty. The interpolation compiled. The test suite passed. The navigation title still ended in an ellipsis because the correct English phrase did not fit the toolbar. Nothing in the gate had lied. I had asked it…

    EN2026-08-30

  2. 62

    Your Vary Test Passed. Production Still Dropped Accept

    I had a content-negotiation test that passed. Then I asked production the same question. Production gave me the right body and the wrong evidence. That is an uncomfortable category of bug because the application appears to work. A client asking for HTML receives HTML. A client asking for Markdown receives Markdown. An…

    EN2026-08-29

  3. 63

    A Rendered Line Is Not Delivered Until write() Completes

    My renderer produced the right line. My CLI tried to write it. The output stream rejected it. Then the next state report arrived, the renderer produced the same line again, and the CLI skipped it as a duplicate. Nothing had been duplicated. The line had never made it out. This is the small, unpleasant gap between…

    EN2026-08-29

  4. 64

    StoreKit 거래 리스너는 Sheet보다 오래 살아야 합니다

    팁 항아리 화면을 닫았습니다. 결제 승인은 그 뒤에 도착할 수 있습니다. 이 두 문장만 나란히 놓아도 거래 리스너를 어디에 두어야 하는지는 거의 정해집니다. 화면에 두면 안 됩니다. 정확히는, 화면의 생명주기에 거래 수신과 정리의 책임을 묶으면 안 됩니다. SwiftUI의 Sheet는 열렸다가 닫힙니다. Transaction.updates는 그 사정을 봐주지 않습니다. Ask to Buy 승인이나 중단됐다가 재개된 구매 결과는 원래 구매 버튼을 눌렀던 화면이 사라진 뒤에도 올 수 있습니다. 결제 결과가 화면보다 오래 사는 셈입니다. TODO Slayer 저장소의…

    KO2026-08-28

  5. 65

    Create the AsyncStream Before the Producer Can Publish

    I had a StoreKit listener. I had an AsyncStream. I had a SwiftUI .task consuming that stream. I also had a transaction result that vanished between all three. Nothing crashed. No continuation threw an error. The purchase was settled. The stream consumer was about to begin. It was just not there yet. That last word did…

    EN2026-08-28

  6. 66

    A Snapshot Hash Is a Contract, Not a Device Test

    There is a wonderfully dangerous moment in cross-platform work. One test produces the same hash you expected. The hexadecimal string sits there looking official. It is fixed-width. It has numbers and letters. It practically arrives wearing a tiny lab coat. Then the sentence grows. “The snapshot hash matched” becomes…

    EN2026-08-27

  7. 67

    Don't Animate a Guess. Let the Rules Engine Return the Replay.

    My game engine knew that one piece had moved, another had been pushed, a tile had cracked, and perhaps somebody had left the board at speed. The Flutter UI knew that the board looked different now. That left a tempting little gap. The UI could compare the old board with the new one, infer what probably happened, and…

    EN2026-08-27

  8. 68

    The Newer Bash Hung. The Fix Was to Stop Generating Shell Code.

    I expected the old system Bash to be the suspicious interpreter. This machine produced the opposite result. This time, macOS Bash 3.2 finished the command in about ten milliseconds. Homebrew Bash 5.3.15 did not return before the timeout. The command was not a build, an install, or a network request. It printed a zsh…

    EN2026-08-26

  9. 69

    합계가 맞는데 품목은 틀렸습니다: 열로 평탄화된 OCR의 name–amount pairing 검증

    OCR가 영수증 표를 읽으면 row가 그대로 나오지 않을 때가 있습니다. 사람 눈에는 다음처럼 보이는 표입니다. 그런데 OCR text는 column을 먼저 읽어 다음처럼 평평하게 만들 수 있습니다. 상품명과 금액이 여러 line 떨어졌습니다. 첫 번째 이름과 첫 번째 금액, 두 번째 이름과 두 번째 금액을 묶으면 원래 row를 복원할 수 있습니다. 하지만 모델이 다음처럼 짝을 바꿔도 각 조각은 모두 진짜입니다. 두 상품명은 영수증에 있습니다. 두 금액도 영수증에 있습니다. 합계도 여전히 3,600입니다. evidence 존재 검사도, value 존재 검사도,…

    KO2026-08-26

  10. 70

    근거를 한 줄로 제한했더니 정답이 탈락했습니다: OCR excerpt를 네 줄까지 허용한 이유

    evidence는 짧을수록 좋아 보입니다. 영수증에서 값을 읽었다면 그 값이 있는 한 줄만 인용하면 될 것 같습니다. 저도 처음에는 그렇게 만들었습니다. excerpt는 OCR page의 정확히 한 line 안에 있어야 했습니다. 규칙은 단순했고, 멀리 떨어진 label과 amount를 이어 붙이는 hallucination도 막았습니다. 그러다 실제 한국 영수증 capture가 들어왔습니다. 한 품목이 이런 모양으로 인식됐습니다. 첫 줄은 상품명입니다. 둘째 줄은 barcode입니다. 셋째 줄은 수량입니다. 넷째 줄은 금액입니다. 모델이 네 줄을 그대로 인용하고…

    KO2026-08-25

  11. 71

    검증에 실패한 값을 지우지 않았습니다: `verified: false`가 필요한 이유

    영수증에서 purchaseDate: 1999-01-01을 추출했다고 해보겠습니다. 모델이 근거라고 내민 줄은 BLUE BOTTLE입니다. 날짜는 어디에도 없습니다. 이때 API가 할 수 있는 일은 대략 셋입니다. 첫 번째는 곤란합니다. 영수증에 없는 날짜를 사실처럼 내보내기 때문입니다. 두 번째는 깔끔해 보입니다. 하지만 사용자는 모델이 뭔가 읽었으나 검증에 실패했다는 사실조차 볼 수 없습니다. 제가 receipt-evidence에서 선택한 것은 세 번째였습니다. 응답의 unverified 배열에는 경로도 함께 남깁니다. 이 설계의 핵심은 “틀린 값을 친절하게…

    KO2026-08-25

  12. 72

    합계 9,300, 카드 4,300, 상품권 5,000: 영수증 total은 덧셈 문제가 아니었습니다

    영수증 OCR에서 total을 찾는 가장 단순한 방법은 무엇일까요? 가장 큰 숫자를 고르면 될 것 같습니다. 아니면 아래쪽에 있는 마지막 금액을 고르면 될 것 같습니다. 다음처럼 synthetic test input을 만들면 그 규칙의 빈틈이 드러납니다. 가장 마지막 숫자는 4,300입니다. 카드와 상품권 금액을 더하면 9,300이 됩니다. 그렇다면 total은 무엇일까요? 현재 parser contract가 고르는 정답은 명시적으로 적힌 합계 9,300입니다. 이 test에서 카드 4,300과 상품권 5,000은 total이 아니라 결제 기여분으로 취급됩니다.…

    KO2026-08-24