코딩 에이전트는 셸 명령을 실행하는 도구를 통해 파일을 고치고 서버를 다룬다. 그런데 에이전트가 "실행하려던 명령"과 "실제로 실행된 명령"이 다를 때가 있다. 에이전트는 자기가 보낸 내용이 그대로 실행됐다고 믿기 때문에, 이런 문제는 엉뚱한 곳을 한참 디버깅하게 만든다. 내 환경(Windows 에서 유닉스 계열 셸을 쓰는 구성)에서 겪은 것들을 모았다.
1. 백슬래시가 줄어든다
에이전트가 셸에서 한 줄짜리 스크립트로 파일을 고치게 했더니, 정규식의 \\d 가 \d 로, 경로의 이중 백슬래시가 단일 백슬래시로 바뀌어 저장됐다. 명령이 도구를 거치고 셸을 거치면서 이스케이프가 한 겹씩 벗겨진 것이다. 설정 파일의 경로가 깨지고 정규식이 엉뚱한 것을 찾았다.
대책: 백슬래시가 들어가는 내용은 셸 명령에 싣지 않는다. 에이전트의 파일 쓰기·편집 도구로 직접 쓰게 하거나, 스크립트를 파일로 저장한 뒤 그 파일을 실행하게 한다.
2. 긴 명령은 잘린다
한 번에 보낸 명령이 10KB 를 넘자 뒷부분이 잘린 채 실행됐다. 긴 패치를 셸 명령 하나에 통째로 넣는 방식에서 생겼다. 오류가 나면 다행이고, 잘린 지점이 하필 문법상 유효한 곳이면 절반만 적용된 채 "성공"한다.
대책: 긴 내용은 파일로 쓰고 실행은 짧은 명령으로. 적용 뒤에는 기대한 문자열이 실제로 파일에 있는지 확인하게 한다.
3. 안전 검사가 정상 명령을 막는다
달러 기호가 든 여러 줄 입력(heredoc)이 도구의 안전 검사에 걸려 거부된 적이 있다. 변수 치환을 이용한 위험한 명령과 구분하기 어렵기 때문일 것이다. 에이전트는 표현을 바꿔 가며 여러 번 재시도하다 시간을 썼다.
대책: 이것도 답은 같다. 스크립트를 파일로 만들고 그 파일을 실행한다.
4. 한글이 깨진다
한글이 든 JSON 을 명령줄 인자로 넘겨 API 에 보냈더니 서버에 깨진 글자가 저장됐다. Windows 에서는 명령줄 인자가 프로세스로 넘어가며 코드 페이지 변환을 거친다. 영문만 보낼 때는 멀쩡해서 한참 뒤에 발견했다.
대책: 본문은 UTF-8 파일로 저장하고 파일에서 읽어 보내게 한다.
5. 줄 끝이 바뀐다
Windows 에서 만든 스크립트를 리눅스 서버에 올리면 줄 끝이 CRLF 일 수 있다. 직접 실행하면 얼추 돌다가 예약 실행에서만 "찾을 수 없음"으로 조용히 실패한다.
대책: 저장소에 줄 끝 규칙을 고정한다(* text=auto eol=lf).
6. 원격 명령이 자기 자신을 죽인다
에이전트가 원격 서버에 "이 이름이 들어간 프로세스를 종료"하는 명령을 한 줄로 보냈더니 접속이 끊겼다. 명령줄 전체에서 이름을 찾는 옵션을 쓴 탓에, 그 명령을 실행하던 원격 셸 자신도 대상이 된 것이다.
대책: 전체 일치 옵션을 쓰거나 프로세스 번호로 종료한다.
7. 고쳤는데 그대로다
에이전트가 코드를 고치고 "강제 새로 고침"으로 확인했는데 옛 동작이 그대로였다. 개발 서버가 고치기 전 모듈을 메모리에 들고 있었다. 에이전트는 수정이 반영됐다고 가정하고 다른 원인을 찾아 헤맸다.
대책: 서버 쪽 코드를 고친 뒤에는 프로세스를 재시작하고 확인하는 것을 규칙으로 적어 둔다.
공통된 교훈
- "보낸 것"이 아니라 "남은 것"을 확인하게 한다. 편집 뒤에는 파일을 다시 읽거나 검색해서 실제 내용을 본다. 이 한 단계가 위 문제의 대부분을 일찍 잡는다.
- 내용은 파일로, 명령은 짧게. 셸을 통과하는 문자열이 짧고 단순할수록 변형될 여지가 없다.
- 겪은 함정은 프로젝트 메모에 적는다. 이 글의 항목 대부분은 지금 내 프로젝트 메모의 맨 위에 있고, 그 뒤로는 같은 문제로 시간을 쓰지 않았다. 에이전트는 자기 도구의 한계를 스스로 기억하지 못한다.
정리
에이전트가 이상한 버그를 쫓고 있다면, 코드보다 먼저 "에이전트의 명령이 온전히 전달됐는가"를 의심해 볼 만하다. 도구와 셸 사이에서 조용히 바뀐 한 글자가 원인인 경우가 생각보다 많았다.
댓글 없음:
댓글 쓰기