DataCook DataCook

컴퓨터 작업을 돕는 AI에게 매번 같은 지침을 말하는 대신, 그 지침을 문서로 저장해 둘 수 있습니다. 이 문서를 짧게 유지하려고 ‘300줄까지만 쓴다’고 정했다면 무엇을 세어야 할까요? 화면에서 보이는 줄, 저장된 줄, 그 안에 들어 있는 글자의 양은 서로 다릅니다.규칙 파일의 분량은 실제 내용이 담긴 파일에서 줄 수·한 줄 길이·전체 글자 수를 같은 방식으로 함께 재어 판단해야 합니다.보관된 한 규칙 문서에서는 줄 수가 거의 그대로인 동안 글자가 늘었습니다. 어느 문서를 재었고, 무엇을 한 줄이나 한 글자로 셌는지 따라가면 ‘300줄 이내’라는 판정이 알려 주는 범위도 구별됩니다. 이 글은 과거 측정 자료를 다시 설명하며, 새로 측정한 결과를 다루지 않습니다.처음 여는 문서에 실제 내용이 다 들어 있..

AI에게 두 곳의 내용을 함께 고치라고 맡긴 작업이 실패로 끝났어도, 먼저 고친 내용까지 사라졌다는 뜻은 아닙니다. 컴퓨터는 글이나 작동 지시를 이름 붙은 묶음인 파일에 보관합니다. 한 파일을 바꾼 뒤 다른 파일에 쓰지 못하고 멈췄다면, 재시도는 처음과 다른 상태에서 시작합니다.두 곳에 쓰다가 막혔다면 재시도 전에 이미 바뀐 파일과 실제 쓰기 허용 경로부터 확인해야 합니다. 권한에 맞춰 작업을 나눈 뒤에도 두 변경이 함께 작동하는지는 따로 확인해야 합니다.보관된 예제에는 A 쪽에 v2라는 글자를 쓴 뒤 B 쪽 쓰기가 거절된 결과가 있습니다. 실제 AI 작업의 회고와 달리, 이 예제는 AI에게 일을 맡기지 않고 컴퓨터에 두 위치의 파일 쓰기를 시켜 비교한 기록입니다.파일의 주소를 알려 줘도 고칠 권한은 생..

리포트 생성 버튼을 눌렀다면, 그다음에는 만들어진 글을 열어 읽을 수 있어야 합니다. 그런데 화면에 ‘생성 완료’가 떠도 읽을 내용은 없을 수 있습니다. 화면이 완료라고 표시하는 일과 리포트 본문을 보관하는 일이 따로 이뤄지기 때문입니다.완료라고 표시하기 전에 응답에 나온 번호로 리포트를 다시 열어, 기대한 본문이 저장됐는지 확인해야 합니다.이 차이를 보여 주는 자료가 2026-10-11에 만든 작은 예제입니다. 실제 서비스와 분리해 한 컴퓨터 안에서 요청을 주고받도록 만든 모형입니다. 아래에서는 그때 보관한 실행 출력을 따라갑니다. 원래 서비스에서 버튼을 누른 사건이나 현재 동작을 입증하는 기록은 아닙니다.받은 번호로 찾아가자 두 결과가 갈렸습니다사람이 화면에서 생성을 요청하면, 그 요청을 처리하고 답..

HTTP 200과 빈 배열을 함께 받았을 때, 오류 화면과 빈 화면 중 어느 쪽을 보여 줘야 할까요? 응답 모양만으로는 결정되지 않습니다. 같은 빈 배열도 조회 조건에 맞는 데이터가 없다는 뜻일 수 있고, 권한 필터나 구현 오류 때문에 기대한 데이터가 빠진 결과일 수 있습니다.API의 빈 응답은 상태 코드와 스키마를 확인한 뒤, 해당 계정·권한·필터에서 기대한 데이터와 대조해 빈 화면 처리 여부를 정하세요.여기서는 2026-10-11에 만든 합성 API 예제의 판정 방식을 검토합니다. 실제 엔드포인트를 점검한 과거 건수나 서비스의 정상 여부를 입증하는 글은 아닙니다. 예제에 쓰인 주소와 응답도 설명용으로 만든 값입니다.200이 아닌 응답부터 모두 장애로 묶으면 안 됩니다RFC 9110 §15.3과 MDN..

사진을 저장한 사람에게 몇 건을 저장했는지, 어디에서 다시 볼 수 있는지 알려 주는 안내를 만든다고 가정하겠습니다. 컴퓨터가 정해진 일을 하도록 만든 지시 묶음을 프로그램이라고 합니다. 이 프로그램이 내놓은 안내를 미리 정한 조건과 자동으로 비교하는 검사가 테스트입니다. 안내를 더 자세히 썼는데 테스트가 실패했다면, 안내가 잘못됐는지 검사 조건이 허용할 변경까지 막았는지 나눠 봐야 합니다.문구를 검사할 때는 문장 전체를 그대로 지켜야 하는지, 같은 정보를 전달하면 표현은 바꿔도 되는지에 따라 비교 방식을 고릅니다.실패했다는 표시만 보고 기대 문구를 새 문구로 바꾸면, 검사가 무엇을 지키려 했는지 놓칩니다. 반대로 글자가 달라졌다는 이유로 새 문구를 모두 거부하면 허용된 수정도 막습니다. 같은 저장 안내를..

글에 넣은 이미지가 사라졌는지 확인하려고 편집 화면의 이미지 부분을 찍었습니다. 돌아온 캡처 파일은 비어 있었습니다. 이때 확인해야 할 것은 두 가지입니다. 실제 글에 이미지가 없는지, 아니면 글을 확인하려고 만든 사진이 잘못됐는지입니다. 최근 개인 원고 작업 기록은 후자의 가능성을 보여 줍니다. 빈 캡처를 증거에서 제외했고, 편집 화면에서는 이미지가 보였습니다. 하지만 그것만으로 저장 뒤 복원까지 말할 수는 없어서 다른 글로 전환한 뒤 다시 여는 확인이 이어졌습니다. 이 기록의 대상은 이 글이 아닌 다른 개인 원고입니다. 아래의 보관 코드 예제 또한 이 캡처의 원인이 아닙니다.코드에서 찾은 문구만으로 현재 화면의 문제를 확정하지 말고, 지금 선택되는 파일과 실제 표시 결과를 맞춰 확인해야 합니다. 촬영..

블로그 편집기에 고친 글을 넣었다고 해서, 블로그에 보관된 글까지 바뀐 것은 아닙니다. 내용을 옮겨 놓은 화면과 실제로 저장된 글은 다를 수 있습니다. 이번에 확인한 작업 기록에는 그 간격이 그대로 남아 있습니다. 저장 전 검사 결과는 READY였고 편집기에 넣은 내용도 원고와 일치했습니다. 그런데 작업자는 저장 버튼을 누르기 전에 멈췄습니다. 뒤에 읽은 저장 목록에는 여전히 예전 제목과 저장 시각이 있었습니다.그 사이에 무엇이 달랐을까요. 검사 결과, 옮긴 내용, 반드시 충족해야 할 조건, 실제 저장 결과가 각기 다른 질문에 답했습니다. 코드 수정에서도 이름 검색이나 자동 진행 표시가 곧 수정 허가가 되지 않는 이유를, 별도로 만든 세 가지 작은 예제로 이어서 살펴보겠습니다. 자동 진행으로 표시된 수정..

보낸 ZIP은 내 컴퓨터에서 열리는데 상대방은 ‘지원하지 않는 압축 방식’ 오류를 봅니다. 다시 전송하기 전에 ZIP 안의 파일별 압축 방식과 상대 프로그램의 지원 여부를 확인하세요. 같은 .zip 확장자라도 안에 든 파일을 모두 같은 알고리즘으로 압축한 것은 아닐 수 있습니다.파일 목록을 읽는 것과 내용을 푸는 것은 다릅니다ZIP에는 항목 이름, 크기뿐 아니라 각 항목의 압축 방식도 기록됩니다. 프로그램이 ZIP 구조를 읽어 목록을 보여 줄 수 있어도, 그 안에 기록된 특정 압축 방식을 지원하지 않으면 파일 내용을 꺼내는 데 실패할 수 있습니다. PKWARE ZIP 형식 명세가령 문서 두 개를 넣은 묶음에서 하나는 Deflate, 다른 하나는 Zstandard로 저장했다고 가정해 보겠습니다. 받는 프로..