연초에는 AI에게 기존 코드를 읽히는 일이 많았다. 여름부터는 운영 코드의 수정안도 받았다. 설명과 코드를 받는 속도는 빨라졌지만, 그 코드가 기존 서비스에 맞는지 확인할 일은 남았다.
예외를 잡았는데 거래는 계속할 수 없었다
커머스 판매 체인에서 후속 요청이 중복되면 원 회차 결과까지 취소될 수 있는 경로를 봤다. PostgreSQL의 UNIQUE 충돌은 같은 요청을 두 번 넣지 못하게 막는다. 그런데 트랜잭션 안에서 이 오류가 나면, 프로그램에서 예외를 잡는 것만으로 이후 쿼리를 계속할 수는 없었다.
수정안을 볼 때도 예외 처리가 추가됐는지만 읽지 않았다. 충돌을 일으키지 않는 INSERT로 바뀌었는지, 같은 이벤트면 기존 요청을 찾는지, 다른 요청이 같은 대상을 처리 중이면 건너뛰는지 살폈다. 구현 코드의 분기와 DB에 남는 결과가 함께 맞아야 했다.
개발 DB에서 같은 대상에 요청을 두 번 넣고 기존 요청 번호와 건너뛴 상태, 트랜잭션을 계속 사용할 수 있는지를 확인한 기록이 있다. 7월 변경은 회귀 검증 뒤 운영 Batch에 제한 적용했다. 다음 회차의 잔여량이 도중에 바뀌는 문제는 후속 개발 검증으로 나눴다.
파일 이름보다 누가 읽는지 먼저 봤다
별도 고객 과제에서는 Arrow 형식 전환을 요청받았다. 같은 JSONL 확장자라도 운영 원본과 학습용 중간 파일의 사용처가 달랐다. 포맷 변환 코드만 검토하면 두 경로를 함께 바꿀 수 있어, 먼저 읽는 프로그램과 DB 의존성을 확인했다.
운영 원본은 두고 학습용 중간 생성만 없앴다. 새 파일을 쓸 수 있는지, DataLoader로 읽히는지, 학습·API 입력에 맞는지를 실행 결과로 확인했다. 코드 초안의 설명과 실제 출력이 다르면 출력 쪽에서 다시 질문했다.
매일 같은 일에는 매번 판단이 필요하지 않았다
블로그 통계 갱신은 수집할 값과 게시 파일이 정해져 있었다. 구조와 권한을 검토할 때 AI를 썼고, 반복 실행은 스크립트와 예약 작업으로 옮겼다. 매일 같은 파일을 갱신하는 일에 매번 새로운 제안을 받을 필요는 없었다.
아직 숫자로 설명하지 못하는 부분
코드 초안을 받는 시간 외에 검토하고 다시 고치는 시간도 생겼다. 두 시간을 함께 기록해 보자는 생각을 남겼지만, 이 글에는 작업별 비교 결과가 없다. AI를 썼다는 이유만으로 작업 전체가 빨라졌다고 수치로 말하지는 않는다.
내가 확인한 변화는 질문의 대상이다. 수정안이 그럴듯한지에서 시작해, 기존 거래와 사용처가 그대로 남는지까지 보게 됐다.