DataCook DataCook

AI 에이전트는 빠르게 많이 바꿀 수 있습니다.그래서 편합니다.동시에 위험합니다.사람이 직접 했다면 한참 걸릴 양의 변경이 짧은 시간에 쌓입니다.문제가 생겼을 때 어디까지 되돌릴지 정해 놓지 않았다면, 빠르게 만든 산출물은 빠르게 정리되지 않습니다.되돌릴 경계는 실패한 뒤에 정하면 늦습니다.이미 파일이 섞이고, 예약이 걸리고, manifest가 바뀌고, 다른 사람의 작업까지 같은 상태에 들어갑니다.그래서 에이전트에게 일을 주기 전에 “이 작업의 소유 범위는 어디까지인가”를 먼저 정해야 합니다.파일 경계와 외부 경계를 따로 봅니다로컬 파일을 되돌리는 것과 외부 서비스 상태를 되돌리는 것은 다릅니다.파일은 diff로 확인할 수 있지만, 블로그 예약이나 발행은 외부 상태입니다.이미지 파일을 삭제하는 것과 이미..

긴 작업을 하다 보면 언젠가 세션이 끊기거나 사람이 바뀝니다.이때 남는 인수인계가 “많이 진행했습니다” 수준이면 다음 작업자는 다시 조사해야 합니다.AI 에이전트도 마찬가지입니다.요약은 친절해 보이지만, 재시작할 수 없으면 운영 문서가 아닙니다.좋은 인수인계는 읽는 사람이 바로 다음 명령을 실행할 수 있게 합니다.무엇이 끝났고, 무엇이 제외됐고, 어떤 파일이 기준이고, 어디부터 이어가야 하는지가 있어야 합니다.특히 대량 생산 작업에서는 숫자가 중요합니다.100개 중 몇 개가 진짜 완료인지 애매하면 전체 계획이 흔들립니다.끝난 일과 세면 안 되는 일을 같이 적습니다인수인계에는 완료 목록만 있으면 부족합니다.세면 안 되는 목록도 필요합니다.이미 발행된 글, 다른 에이전트가 맡은 글, 삭제한 글, 실패한 글을..

AI 도구 비용을 볼 때 가장 먼저 눈에 들어오는 것은 토큰 가격입니다.입력이 얼마고 출력이 얼마인지 계산하게 됩니다.이 계산은 필요합니다.하지만 실제로 더 크게 새는 비용은 따로 있습니다.잘못 만든 결과를 다시 확인하고, 다시 지시하고, 다시 고치는 재작업 비용입니다.에이전트가 한 번에 많은 글을 만들거나 많은 파일을 고칠수록 이 차이는 커집니다.토큰 비용은 영수증에 보이지만, 재작업 비용은 오후 시간을 통째로 가져갑니다.그래서 AI 에이전트 비용 관리는 싸게 쓰는 문제가 아니라 다시 하지 않게 만드는 문제에 가깝습니다.가장 비싼 출력은 거의 맞는 출력입니다완전히 틀린 결과는 빨리 버릴 수 있습니다.오히려 위험한 것은 거의 맞는 결과입니다.제목은 좋고 구조도 괜찮은데 이미지가 빠져 있거나, 예약 시간이..

한 줄짜리 수정에 검증자를 세 명 붙인 적이 있습니다.말만 들으면 꼼꼼해 보입니다.실제로는 낭비였습니다.바뀐 건 오타 하나였고, 확인은 파일 한 번 열어보면 끝나는 일이었습니다.그런데 저는 절차를 믿고 싶어서 작은 일까지 게이트를 붙였습니다.그때 화면에는 대기 중인 리뷰가 세 개 떠 있었습니다.한 명은 맞춤법을 봤고, 한 명은 구조를 봤고, 한 명은 위험도를 봤습니다.결과는 전부 비슷했습니다."문제 없음." 근데 그 사이 저는 다음 글을 못 쓰고 있었습니다.아, 이건 검증이 아니라 병목이구나.그날 배운 건 조금 불편했습니다.검증도 과하면 버그입니다.모든 작업이 게이트를 필요로 하진 않았습니다한동안 저는 검증 부족에 데인 뒤라 반대로 갔습니다.어떤 작업이든 독립 리뷰어를 붙이고, 보고서를 요구하고, PAS..

AI 에이전트와 오래 일하다 보면 컨텍스트 창을 기억처럼 다루고 싶어집니다.앞에서 설명했으니 알고 있겠지, 어제 말했으니 이어서 하겠지, 파일을 읽었으니 계속 기억하겠지 생각합니다.하지만 실제 작업에서는 이 기대가 자주 깨집니다.컨텍스트는 영구 기억이 아니라 지금 펼쳐 놓은 작업대에 가깝습니다.작업대에는 물건을 올릴 수 있지만 무한히 올릴 수는 없습니다.오래된 종이는 밀려나고, 비슷한 문서는 섞이고, 방금 읽은 내용이라도 어디에 쓰는 정보인지 분명하지 않으면 잡음이 됩니다.그래서 에이전트 작업에서는 무엇을 컨텍스트에 넣을지보다 무엇을 빼고 유지할지가 더 중요합니다.컨텍스트는 많을수록 좋은 것이 아닙니다초보적인 실수는 자료를 전부 넣는 것입니다.모든 문서, 모든 로그, 모든 회의록을 주면 에이전트가 더 정..

처음엔 스크립트 하나면 된다고 생각했습니다.읽고, 바꾸고, 저장한다.데이터가 많지 않을 때는 그게 제일 빠르게 보입니다.실제로 빠릅니다.한 번 실행하면 끝나는 작업처럼 보입니다.그런데 마이그레이션은 실행하는 순간부터 질문이 달라졌습니다.실패하면 어디까지 됐는지 알 수 있나요.다시 돌려도 안전한가요.되돌릴 수 있나요.그 질문에 답이 없으면 스크립트가 아니라 도박에 가까웠습니다.dry-run은 말로 하면 안 믿었습니다“dry-run만 했습니다.”이 말도 처음엔 믿었습니다.근데 멀티에이전트나 긴 자동화에서는 말만으로 부족했습니다.dry-run 전후로 레코드 수가 같은지, 대상 범위가 맞는지, 실제 write가 없었는지 봐야 했습니다.제가 지금 좋아하는 형태는 이런 겁니다.target_count_before: ..

처음엔 기록이라는 단어가 하나면 충분해 보였습니다.진행 중인 기록도 기록이고, 끝난 기록도 기록이고, 보여주는 카드도 기록이었습니다.이름을 나누면 괜히 복잡해 보였습니다.초기 제품에서는 그 단순함이 꽤 편했습니다.문제는 세 번째 맥락이 들어온 날 시작됐습니다.같은 단어를 쓰는 세 개념이 서로 다른 규칙을 요구했습니다.이름이 같아서 더 늦게 알아챘습니다처음엔 타입을 합치고 싶었습니다.필드가 비슷했습니다.ID도 비슷했고, 화면에서 보이는 값도 비슷했습니다.그래서 하나의 모델로 처리하면 빠를 것 같았습니다.하지만 시간이 지나자 이상한 조건문이 늘었습니다.if active:if archived:if displayOnly:if ownerMode:처음엔 자연스러운 분기라고 생각했습니다.제품이 커지면 조건이 생기니까..

AI 에이전트가 “완료했습니다”라고 말하는 순간이 있습니다.문제는 그 말이 생각보다 약하다는 점입니다.에이전트는 파일을 만들었을 수도 있고, 일부만 고쳤을 수도 있고, 테스트를 실행하지 않았는데 실행한 것처럼 착각했을 수도 있습니다.악의가 있어서가 아니라 완료라는 단어의 기준이 사람마다, 작업마다 다르기 때문입니다.그래서 저는 에이전트 작업에는 검증 계약이 필요하다고 봅니다.검증 계약은 “어떤 증거가 있어야 완료로 인정할 것인가”를 작업 전에 정하는 약속입니다.이 약속이 없으면 완료 보고는 상태 보고가 아니라 희망 사항에 가까워집니다.완료는 말이 아니라 재현 가능한 출력입니다검증 계약의 첫 번째 조건은 재현성입니다.“확인했습니다”보다 “이 명령을 실행했고 이런 결과가 나왔습니다”가 강합니다.블로그 작업이..