경계를 먼저 시험하기
테스트가 모두 통과하고 CI가 초록이면 작업을 끝내고 싶어집니다. 그러나 그 신호는 정해진 테스트가 통과했다는 뜻일 뿐, 계약의 모든 경계가 안전하다는 증명은 아닙니다. 특히 입력을 해석하거나 권한을 판단하는 변경에서는 보기 좋은 정상 경로만 확인하면 위험한 틈이 남을 수 있습니다.
이번 점검에서 유효했던 방법은 먼저 파서가 헷갈릴 지점을 적어 보는 것이었습니다. 이스케이프 문자, 인용 중첩, 비정상 형식, 예상 밖의 조합처럼 경계에 가까운 입력을 작은 재현 사례로 만들고, 각 사례에서 시스템이 안전하게 거절하거나 의도한 동작을 유지하는지 확인합니다.
이 방식은 단순히 테스트 수를 늘리는 일이 아닙니다. 어떤 위험을 막으려는지 분명히 하고, 그 위험을 다시 재현할 수 있는 사례를 남기는 일입니다. 수정 뒤에는 같은 공격 시나리오를 다시 실행해야 합니다. 그래야 고친 코드가 실제 우회를 닫았는지 알 수 있습니다.
속도도 이 원칙과 충돌하지 않습니다. 빠른 팀은 초록불을 빨리 승인하는 팀이 아니라, 초록불이 놓친 질문을 빨리 찾아내고 검증하는 팀입니다. 다음 변경에서는 “정상 입력이 통과하는가?” 다음에 “가장 이상한 입력에서도 안전한가?”를 바로 묻는 습관을 둡니다.
Test the boundaries first
When every test passes and CI turns green, it is tempting to call the work done. That signal only says the specified tests passed; it does not prove that every boundary of the contract is safe. Changes that parse input or make permission decisions can leave dangerous gaps when they are checked only on the happy path.
A useful practice is to list the places a parser might become confused before approving a change. Turn boundary cases—escape characters, nested quotes, malformed forms, and unexpected combinations—into small reproductions. For each one, verify that the system either rejects it safely or preserves the intended behavior.
This is not merely adding more tests. It makes the risk explicit and leaves behind a case that can reproduce it. Run the same attack scenarios after the fix; that is how you learn whether the change actually closed the bypass.
Speed does not conflict with this discipline. A fast team is not one that approves green lights fastest; it is one that quickly finds and tests the questions a green light did not answer. After asking whether normal input works, immediately ask whether the strangest input remains safe.
先测试边界
当所有测试通过、CI 变绿时，很容易认为工作已经结束。但这只说明既定测试通过，并不能证明契约的每个边界都安全。涉及输入解析或权限判断的改动，如果只检查正常路径，仍可能留下危险缺口。
一个有效做法是在批准改动前，先列出解析器可能混淆的地方。把转义字符、嵌套引号、异常格式和意外组合等边界输入做成小型复现案例，并确认系统对每种情况都会安全拒绝或保持预期行为。
这不只是增加测试数量，而是明确要防的风险，并留下可以再次复现的案例。修复后要重新运行同样的攻击场景，才能知道改动是否真的堵住了绕过路径。
速度并不与这种纪律冲突。快速的团队不是最快批准绿灯的团队，而是最快找到并验证绿灯没有回答的问题的团队。确认正常输入可用后，马上追问最奇怪的输入是否仍然安全。
まず境界を試す
すべてのテストが通り CI が緑になると、作業を終えたくなります。しかし、その信号が示すのは指定されたテストが通ったことだけで、契約のすべての境界が安全だという証明ではありません。入力を解析したり権限を判断したりする変更は、正常系だけを確認すると危険な隙間を残すことがあります。
有効な方法は、承認の前にパーサーが混乱しそうな箇所を書き出すことです。エスケープ文字、入れ子の引用、不正な形式、想定外の組み合わせといった境界入力を小さな再現例にし、それぞれで安全に拒否するか意図した動作を保つかを確認します。
これは単にテスト数を増やすことではありません。防ぎたいリスクを明確にし、再現できるケースを残すことです。修正後にも同じ攻撃シナリオを実行して、変更が本当に迂回路を閉じたかを確かめます。
速度はこの規律と矛盾しません。速いチームとは、緑の表示を最速で承認するチームではなく、緑が答えていない問いを素早く見つけて検証するチームです。正常な入力が通るかを聞いた後、最も奇妙な入力でも安全かをすぐに問います。