전체 글 (28) 썸네일형 리스트형 사내 지식 AI 에이전트가 틀렸을 때, 고칠 곳을 나누는 법 사내 지식을 읽는 AI 에이전트가 틀렸다고 해서, 검색 문서를 더 넣거나 프롬프트를 길게 만드는 것이 바로 답은 아니다. 이미 가진 자료를 잘못 적용한 것인지, 필요한 지식이 빠진 것인지, 사람도 아직 결론을 못 낸 문제인지를 먼저 나눠야 수정이 쌓인다.Meta가 특정 compliance 업무에 적용한 지식 에이전트 사례는 이 구분을 시스템 구조로 만들었다. 이들은 정답과 근거를 담는 지식 파일, 그 자료를 읽는 절차, 사람 검토, 수정 검증을 서로 다른 층으로 두고 교정 한 건이 다음 변경의 테스트가 되게 했다.이 글은 그 시스템을 그대로 도입하자는 제안이 아니다. 사내 문서 기반 에이전트가 틀렸을 때, 어떤 수정이 지식 파일로 가야 하고 어떤 수정이 절차나 사람 판단으로 남아야 하는지 가르는 기준을 .. 도구 출력을 줄였는데 에이전트 비용이 늘어나는 순간 AI 코딩 에이전트의 비용은 도구 응답을 짧게 만든다고 바로 줄지 않는다. 빠진 정보를 다시 읽거나 명령을 재실행하면, 응답 하나는 짧아져도 한 작업에 든 토큰과 시간은 오히려 커질 수 있다.GitHub가 Copilot CLI에서 진행한 비용 최적화 사례는 이 차이를 꽤 선명하게 보여 준다. 네 가지 변경은 모두 오프라인 에이전트 벤치마크와 통제된 온라인 실험을 거쳐 검토됐지만, 그중에는 초기 실험에서 되돌려야 했던 압축도 있었다.이 글에서 가져갈 것은 Copilot의 설정값이 아니다. 도구 출력, 프롬프트, 백그라운드 작업 결과를 줄이려 할 때 무엇을 남기고, 어떤 회수 행동을 비용으로 잡고, 어느 품질 회귀를 따로 시험할지를 정하는 기준이다.짧은 응답 뒤에 붙는 재실행가장 단순한 비용 절감안은 셸 출.. Kubernetes에서 오래된 CRD 버전을 지우기 전, 데이터가 새 형식인지 확인하는 법 CRD의 storage version을 v1로 바꿨다고 해서, etcd에 있던 객체까지 v1로 바뀌는 것은 아니다. Kubernetes 1.37에서는 이를 다시 쓰는 StorageVersionMigration이 기본 제공된다.Kubernetes는 1.37에서 StorageVersionMigration API와 컨트롤러가 GA가 되었고 기본 활성화된다고 설명한다. 오래된 API 버전을 정말 없앨 수 있는지는 설정 화면이 아니라, 마이그레이션 완료 상태와 CRD에 남은 저장 버전을 함께 본 뒤에 판단해야 한다.이 글은 CRD 버전 전환을 예로 든다. 같은 구조는 저장 형식 변경이나 암호화 키 교체처럼, 앞으로 쓸 형식과 이미 저장된 객체의 형식이 어긋날 수 있는 작업에도 적용된다.저장 버전만 바꾸면 새 객체.. 코딩 에이전트 모델을 고를 때, 해결률 다음에 봐야 할 네 가지 코딩 에이전트 모델은 해결률만으로 고르기 어렵다. 같은 이슈를 해결해도 어떤 모델은 짧고 좁은 변경으로 끝내고, 다른 모델은 더 많은 탐색과 검증을 거칠 수 있어서다. 팀이 감당할 비용과 리뷰 방식까지 다르면 ‘가장 높은 점수’가 곧 가장 맞는 선택은 아니다.JetBrains의 Junie 평가 사례는 그 차이를 구체적으로 보여 준다. 이들은 이슈·저장소·생성 패치·테스트 결과·실행 기록을 함께 보며, 코딩 에이전트를 결과뿐 아니라 실행 과정까지 네 방향에서 비교했다.이 글에서 가져갈 것은 특정 모델의 순위가 아니다. 다음 평가를 할 때 해결했는지, 얼마나 썼는지, 무엇을 바꿨는지, 어떻게 검증했는지를 분리해 남기면 모델을 바꾸거나 프롬프트를 손볼 근거가 생긴다.해결률이 같아도 작업 비용은 같지 않다Jet.. AI가 만든 PR이 쏟아질 때, 유지보수자가 먼저 확인할 것 AI 생성 PR이 빠르게 쌓일 때, 유지보수자가 먼저 볼 것은 코드 작성 주체가 아니라 변경을 이해하고 검증했다는 증거다. 테스트 결과·스크린샷·작업 과정·중복 여부를 함께 보면, 자동 리뷰가 놓치는 병합 판단의 경계를 더 빨리 찾을 수 있다.GitHub가 소개한 OpenClaw 유지보수자 사례는 이 변화가 추상이 아니라는 점을 보여 준다. 수천 건의 PR과 이슈가 들어오고, 일부 기여자가 수백 건의 PR을 한꺼번에 올리는 상황에서 팀은 기여 수만으로는 신뢰를 가늠하기 어렵다는 문제를 만났다.여기서 쓸 만한 결론은 “AI가 작성한 PR을 피하자”가 아니다. 변경을 왜 했는지, 실제로 어디까지 확인했는지, 제출자가 무엇을 이해하고 있는지를 코드와 함께 읽을 수 있게 만드는 편이 리뷰 병목을 줄이는 데 더 .. AI 개발 도구 도입 전 확인할 다섯 신호 AI 개발 도구를 팀에 넣기 전에는 기능 수보다 실행 권한, 운영 지표, 에이전트 신원, 실제 사용 범위, 워크플로 가시성을 먼저 확인해야 한다. 다섯 자료는 이 질문을 팀 도입 기준으로 바꾸는 데 쓸 만하다.다섯 자료가 다루는 제품과 독자는 서로 다르다. 그러나 팀에 AI 도구를 넣은 뒤 무엇을 통제하고 어떤 수치를 남기며 어디까지 믿을지 결정하게 해 준다는 공통점이 있다. 기능 목록보다 그 판단에 바로 쓸 수 있는 신호를 중심으로 묶었다.다섯 신호를 한 번에 보는 방법도입 전에는 ‘무슨 기능이 나왔나’보다 다섯 질문을 따로 봐야 한다. 설정이 실제 실행 범위를 바꾸는지, 운영 지표가 청구와 용량을 구분하는지, 에이전트가 자신을 증명할 수 있는지, 개발자의 사용 비율을 어떤 조사로 말하는지, 파이프라인.. Claude Code restricted mode가 막는 것, 별도로 남는 경계 Claude Code v2.1.248의 restricted mode는 명령·코드 실행 도구와 WebFetch, 설정 파일, bypassPermissions의 영향을 함께 제한한다. 무엇을 막고 sandbox·권한 규칙으로 별도 설계해야 하는지 공식 문서를 기준으로 정리한다.v2.1.248 릴리스는 --restricted와 CLAUDE_CODE_RESTRICTED=1을 새로 추가했다. 에이전트에게 작업 폴더의 파일을 다루게 하면서도, 명령 실행이나 웹 가져오기는 기본 경로에서 빼고 싶은 상황을 겨냥한 변화다.이 플래그를 ‘안전 모드’라는 한 단어로 이해하면 중요한 선택이 사라진다. restricted mode가 줄이는 것은 도구 표면과 설정 영향 범위다. 명령이 꼭 필요한 작업의 filesystem·net.. 점진 배포에서 1% 오류를 핫픽스로 고칠지 판단하는 기준 점진 배포 중 1%에서 발견된 오류는 비율만으로 핫픽스 여부를 정할 수 없다. 배포 확대 위험, 기능 손상, 수정 배포의 새 위험, 재현 근거를 한 사건 단위로 확인해야 실행과 보류를 납득할 수 있다.토스 QA Platform 팀의 핫픽스 사례는 이 판단이 왜 필요한지 잘 보여 준다. 일부 사용자에게 먼저 배포한 버전에서 발견된 오류는 아직 받지 않은 사용자에게도 퍼질 신호일 수 있고, 아주 특정한 조건에서만 일어난 제한된 문제일 수도 있다. 두 경우 모두 화면에 보이는 비율은 1%지만, 다음 행동은 달라진다.이 글에서 가져갈 것은 토스의 내부 승인 규칙 자체가 아니다. 같은 낮은 비율의 오류를 만났을 때, 무엇을 확인하고 어떤 사유를 남겨야 다음 배포에서도 판단이 흔들리지 않는지에 있다.1%는 영향도도.. 이전 1 2 3 4 다음
