“도구를 끄면 실력이 드러난다.
더 정확히는, 어디에 시간을 버리고 있었는지가 드러난다.”
[Read More]
「더 위자드 오브 라이즈」와 「인턴」 사이 — AI 과신을 피하고 어시스턴트를 쓰는 법
영화 두 편을 이어 보니, 기술보다 먼저 신뢰의 구조가 보였다.
검증 없는 신뢰는 붕괴로 가고, 경계가 있는 보조는 실행력을 만든다.
[Read More]
스레드 합의를 티켓 한 문단으로 옮기는 습관 — 휘발을 줄이는 운영
“합의는 채팅에서 시작해도 된다.
다만 기록은 티켓으로 닫아야 팀이 같은 지도를 본다.”
[Read More]
주니어의 첫 레버 — 이번 주는 PR 3단락만 통일해도 충분하다
“처음부터 잘 쓰는 사람은 없다.
대신 항상 같은 순서로 설명하는 사람은 빨리 는다.”
[Read More]
비밀번호 이후의 로그인: WebAuthn Immediate UI를 붙일 때 놓치기 쉬운 것들
이 글의 요점은 단순하다.
로그인 UX의 경쟁력은 이제 "입력을 잘 받는 폼"보다 "입력을 덜 하게 만드는 인증"에서 나온다.
[Read More]
로컬에서 확인할 것, QA에서 확인할 것 — Browser MCP E2E의 판단
Browser MCP의 가치는 클릭 자동화가 아니다.
어느 환경에서 무엇을 증명할지 고르는 데 있다.
[Read More]
비싼 실수는 AI가 아니라 검증 부재 — geohot의 Sloptember를 읽고
10배 아웃풋은 싸지 않다.
10배 검증이 붙을 때만 싸다.
[Read More]
Harness engineering을 읽었을 때 — 계층·중앙·도구 의존은 왜 틀린가
Fowler가 말하는 harness는 조직도가 아니다.
계층으로 쌓거나, 중앙이 독점하거나, 모델·툴에 매달리면 — 그 순간 harness engineering이 아니라 이름만 남는다.
[Read More]
문제 퍼스트 — AI 시대에 툴보다 먼저 정의할 것
좋은 엔지니어링은 도구 선택으로 시작하지 않는다.
문제 정의와 성공 기준으로 시작한다.
[Read More]
테스트와 CI가 진짜 생산성인 이유 — 빠르게 쓰는 것보다 빠르게 안심하는 것
“빠른 팀은 코드를 빨리 쓰는 팀이 아니라,
변경 후에도 괜찮다는 확신을 빨리 얻는 팀이다.”
[Read More]
208초의 판단, 208분의 재심 — 「설리」가 말해주는 장애 대응의 역설
새벽에 영화를 보고 장애 채널이 떠올랐다.
살린 것은 판단이었는데, 나중에 재심받는 것은 그 판단이었다.
[Read More]
「하네스 다 했어요」는 아직 시작 — Claude Code가 대규모 코드베이스에서 말하는 것
Claude로 한 번 문서 뽑고 “하네스 세팅 끝”이라고 말하는 순간,
실제로는 하네스 유지보수가 시작되지 않은 것일 수 있다.
[Read More]