🔍 AI에게 코딩을 맡기며 배운 것 — '고쳤습니다'를 믿으면 안 되는 이유

혼자 웹 도구를 만들어 운영하고 있습니다. PDF 압축기, 이미지 편집기, 생활 계산기까지 세 개를 배포했고 네 번째를 준비 중인데, 코드 대부분은 AI에게 맡겼습니다. 그 과정에서 가장 크게 배운 건 프로그래밍 지식이 아니라 “AI가 고쳤다고 말할 때 그걸 어떻게 확인하는가” 였습니다.

AI 코딩 도구 사용법을 다루는 글은 많지만, 대부분 “이렇게 시키면 잘 만들어줍니다”에서 끝납니다. 정작 실무에서 시간을 잡아먹는 건 그다음이었어요. 실제로 겪은 오진 세 건을 그대로 적습니다.

사례 1 — “코드는 정상입니다”가 맞았지만 문제는 남아 있었다

이미지 압축 도구를 만들고 첫 테스트를 했습니다. 5960×3973 크기 사진(1.6MB)을 올리고 품질을 25로 낮췄는데, 결과가 1.7MB로 오히려 커졌습니다.

AI에게 물었더니 코드를 확인하고 이렇게 답했습니다. “품질 값이 0~100에서 0~1로 정상 변환되고 있고, 인코더에도 정확히 전달됩니다. 코드 결함이 아닙니다.” 그리고 다른 이미지로 품질 5/50/95를 실측해 62배 차이가 나는 표까지 보여줬습니다. 논리적으로 완벽한 답변이었죠.

그런데 여기엔 함정이 있었습니다. 62배 차이는 “다른 이미지”로 검증한 것이었고, 정작 문제가 된 그 사진 그 설정(품질 25)은 재현하지 않았어요. 제가 그 조건 그대로 다시 확인해 달라고 요청하자, 진짜 원인이 나왔습니다.

압축률 표시 카드가 설정을 바꾼 직후 아직 재처리가 끝나지 않았는데도 이전 결과를 최종값처럼 보여주고 있었습니다. 코드(인코딩 로직)는 정말 정상이었지만, 화면이 옛날 숫자를 붙잡고 있었던 거죠. 수정 후 같은 조작에서 +16.2% → −79.5% 로 바뀌었습니다.

교훈: “코드는 정상”이 “문제가 없다”는 뜻은 아닙니다. 사용자가 본 화면과 코드의 동작은 다를 수 있습니다.

사례 2 — 픽셀이 5분의 1로 줄었는데 파일이 2.6배 커졌다

같은 도구에서 리사이즈를 45%로 설정했습니다. 5960×3973 → 2682×1788이니 **픽셀 총량은 약 20%**로 줄어든 셈인데, 결과 파일은 1.6MB에서 4.2MB로 늘었습니다.

이건 앞선 사례와 성격이 달랐습니다. 픽셀이 5분의 1이 됐는데 파일이 커지는 건 어떤 인코딩 방식으로도 설명되지 않으니까요. 원인을 찾아보니 이랬습니다.

설정을 빠르게 연속으로 바꾸면 같은 이미지에 대해 여러 인코딩 작업이 동시에 돌아갔고, 가장 늦게 끝난 작업이 무조건 최종 결과가 됐습니다. 풀해상도 인코딩(느림)이 축소본(빠름)보다 늦게 끝나면, 정답인 작은 결과를 큰 결과가 덮어쓰는 구조였던 겁니다. 이른바 경쟁 상태(race condition)였어요.

수정 후 같은 조작에서 16.0MB(+184%) → 981.8KB(−82.9%) 로 정상화됐습니다.

이 버그가 무서운 건 재현이 확률적이라는 점입니다. 천천히 조작하면 멀쩡하고, 빠르게 누를 때만 나타나요. “한 번 해봤는데 괜찮던데요”로 넘어가면 놓칩니다.

사례 3 — 배포했는데 왜 옛날 코드가 돌고 있지

환율 계산기에서 실시간 환율이 안 뜨고 계속 “저장된 참고용 환율”만 표시됐습니다. AI가 원인을 찾아 고쳤고, 로컬 검증까지 통과했다고 했습니다. 그런데 배포된 사이트에서는 여전히 같은 증상이었어요.

원인은 코드가 아니었습니다. 수정된 코드가 올라간 곳이 실제 서비스가 바라보는 브랜치가 아니었고, 심지어 그 사이 배포 플랫폼과 저장소 연결이 끊겨 있었습니다. 코드는 멀쩡히 고쳐졌는데 그게 사용자에게 도달하지 못한 상태였던 거죠.

참고로 진짜 원인은 나중에 정확히 밝혀졌습니다. 호출하던 환율 API 주소가 구버전이라 새 주소로 301 리다이렉트되고 있었는데, 브라우저는 리다이렉트되는 요청을 보안 정책상 차단합니다. 그래서 개발자 도구에서만 실행하면 되는데 실제 사이트에서는 실패하는 현상이 났어요.

교훈: “고쳤다”와 “사용자가 그걸 쓸 수 있다” 사이에는 배포라는 단계가 하나 더 있습니다.

그래서 지금은 이렇게 확인합니다

세 번 데이고 나서 굳어진 습관입니다. 특별할 건 없지만, 이걸 지키면 헛도는 시간이 확 줄었습니다.

① “원래 그 조건 그대로” 재현시키기

AI는 검증할 때 자기가 편한 케이스를 고르는 경향이 있습니다. 사례 1이 딱 그랬어요. 그래서 요청할 때 조건을 못 박습니다. “그 파일, 그 설정, 그 화면에서 다시 해보고 결과를 보여주세요.”

② 수정 전/후 숫자를 나란히 요구하기

“고쳤습니다”보다 “16.0MB → 981.8KB”가 훨씬 유용합니다. 숫자를 요구하면 AI도 실제로 실행해서 확인하게 되고, 저도 납득 여부를 판단할 수 있습니다.

③ 회귀 확인을 같이 시키기

버그를 고치다 멀쩡한 걸 깨뜨리는 경우가 흔합니다. 예를 들어 크롭 기능에서 “박스 안을 드래그하면 이동”을 추가했다면, **“박스 바깥 드래그로 새로 그리기는 여전히 되는지”**도 같이 확인해 달라고 합니다.

④ 고치기 전에 원인부터 설명시키기

바로 수정에 들어가면 엉뚱한 곳을 건드릴 때가 있습니다. “고치지 말고 원인부터 조사해서 어느 파일 몇 번째 줄이 문제인지 먼저 설명해 주세요”라고 하면, 정확도가 눈에 띄게 올라갑니다. 실제로 이렇게 물었더니 “이건 버그가 아니라 원래 구현된 적 없는 기능입니다” 라는 답이 나온 적도 있어요. 고쳐달라고 할 게 아니라 만들어달라고 해야 하는 상황이었던 거죠.

⑤ 내가 모르는 이름이 나와도 바로 의심하지 않기

이건 반대 방향의 교훈입니다. AI가 처음 듣는 기능 이름을 쓰길래 “지어낸 거 아니냐”고 의심했는데, 찾아보니 실제로 존재하는 최신 기능이었습니다. 제가 알던 정보가 낡았던 거예요. 그래서 판단 기준을 “내 지식”이 아니라 “검색해서 확인되는가”로 바꿨습니다.

정리

AI에게 코딩을 맡기면 만드는 속도는 확실히 빨라집니다. 다만 그 속도만큼 검증을 건너뛰고 싶은 유혹도 같이 커져요. 세 번 다 “고쳤습니다”를 그대로 믿었으면 사용자가 먼저 발견했을 버그들이었습니다.

결국 혼자 만들고 혼자 운영하는 입장에서 제 역할은 코드를 짜는 사람이 아니라 “진짜 고쳐졌는지 확인하는 사람” 쪽에 가까워졌습니다. 그게 생각보다 훨씬 중요한 일이더군요.

여기서 다룬 도구들은 홀로라도 도구 모음에서 직접 써보실 수 있습니다.