AI 뉴스가 계속 쌓이면 읽기 목록이 지식의 저장소보다 미뤄 둔 일의 목록처럼 느껴질 수 있다. 매일 새 모델과 도구가 나오는데 지난주에 저장한 글도 읽지 못했다는 감각이다. 이럴 때는 더 빨리 읽는 방법보다 무엇을 읽지 않아도 되는지부터 정할 필요가 있다. Francis가 ...
API null·빈 문자열·필드 생략: 값 없음을 설계하는 법
API에서 ‘값이 없다’는 말은 하나의 상태처럼 들린다. 하지만 사용자는 값을 그대로 두려는 것일 수도, 기존 값을 지우려는 것일 수도, 아직 입력을 끝내지 못한 것일 수도 있다. null과 빈 문자열과 필드 생략을 같은 것으로 처리하면 서로 다른 의도가 저장 단계에서 합쳐질 ...
브라우저 AI 설계: 취소·재시도·전송 경계를 나누는 법
브라우저 안에서 AI를 실행하는 기능을 설계한다면 결과가 잘 나오는 장면만 볼 수는 없다. 사용자가 기다리다 취소했을 때, 입력을 고쳤을 때, AI 없이 직접 제출하려 할 때도 흐름이 자연스러워야 한다. 취소 버튼은 작은 편의 기능이 아니라 실제 작업 상태를 드러내는 계약이다. ...
사이드 프로젝트 기능 추가 기준: 유지보수 비용까지 계산하기
사이드 프로젝트에 기능 하나를 추가하는 일은 버튼 하나를 만드는 일보다 크다. 사용자가 알아야 할 개념이 늘고, 저장해야 할 상태가 늘며, 오류가 났을 때 설명해야 할 경우도 늘어난다. 개발 시간이 짧다는 이유만으로 유지 비용까지 작다고 말하기는 어렵다. Karri Saarinen의 Someone Behind ...
AI 버그 수정, 재현 테스트부터 준비해야 하는 이유
AI에게 버그를 고쳐 달라고 할 때 긴 상황 설명부터 쓰기 쉽다. 그러나 수정의 성공을 판단하려면 작은 실패 입력 하나가 먼저 필요하다. 지금 무엇이 잘못되는지, 고친 뒤 어떤 결과가 나와야 하는지를 함께 적어 두면 그럴듯한 설명과 실제 수정을 구분하기 쉬워진다. The ...
AI 에이전트 중단 조건: 도구보다 먼저 정할 실행 경계
AI 에이전트에 도구를 연결하면 할 수 있는 일이 늘어난다. 그때 같이 늘어나야 하는 것은 멈출 수 있는 조건이다. 작업이 끝났는지, 권한이 없는지, 같은 실패를 반복하고 있는지를 구분하지 못하면 도구의 개수만으로 신뢰할 수 있는 자동화가 되기는 어렵다. Harness Engineering 101은 모델 ...
개발자 코딩 폰트 고르는 법: 식별자와 오류 메시지로 비교하기
코딩 폰트를 고를 때 샘플 화면을 오래 보게 된다. 하지만 매일 읽는 것은 정돈된 소개 페이지보다 작은 식별자와 길게 이어진 오류 메시지다. 좋은 코딩 폰트를 찾으려면 예쁜 문장과 함께 가장 헷갈리는 문자도 같은 자리에 놓아 보아야 한다. Nordwand Mono 같은 ...
사이드 프로젝트 백업: 서버 복구에 필요한 기록과 복원 연습
사이드 프로젝트의 백업을 점검할 때 가장 먼저 떠올릴 질문은 ‘파일이 어디에 있는가’보다 ‘서버가 사라지면 무엇으로 다시 시작하는가’다. 데이터베이스 복사본은 있어도 실행 설정을 모르거나, 도메인에 접근할 수 없으면 사용자가 보던 서비스로 돌아가기 어렵다. kqr는 NixOS를 사용하면서 인프라를 다루는 두려움이 줄어든 경험을 ...
TypeScript 컴파일러 전환: 속도보다 먼저 비교할 호환성
TypeScript 컴파일러가 빨라졌다는 소식을 보면 빌드 시간을 먼저 재 보고 싶어진다. 하지만 전환 여부를 결정할 때 먼저 물어야 할 것은 ‘우리 코드가 같은 뜻으로 처리되는가’다. 더 빨리 끝나더라도 필요한 오류를 놓치거나 기존에 허용되던 코드를 거부하면, 절약한 시간과 별개의 문제가 생긴다. ...
아이패드 발표 화면 공유: 발표자 노트 노출을 점검하는 방법
발표 화면 공유를 점검할 때는 첫 슬라이드보다 앱을 바꾸는 순간을 먼저 볼 필요가 있다. 슬라이드가 잘 보인다는 사실과 비공개 메모가 끝까지 보이지 않는다는 사실은 서로 다른 확인이기 때문이다. 발표자 노트를 따로 열어 두는 아이패드 발표라면 이 차이가 더 중요해진다. Teddy ...