AI는 과연 코딩에서 만능인가 #1

"이거 기능 왜 이상하게 작동하지?"

AI에게 코드를 맡긴 그날은 아무 문제가 없었다. 요구한 대로 동작했고, 배포도 했다.

문제는 그 뒤 기능 추가였다. 붙이려던 기능이 예상과 다르게 굴었고, 원인을 찾으려고 들어갔는데 어디부터 봐야 할지를 모르겠는 것이다. 코드는 멀쩡했다. 문법도 구조도 흠잡을 데가 없었다. 그런데 왜 그렇게 되어 있는지를 내가 모르는 상태였다.

적지 않은 프로젝트를 이렇게 굴려보고 나서 내린 결론은, 이게 가독성 문제도 기억력 문제도 아니라는 거였다. 문제는 하나 였다.

통제 불가한 영역이 생긴다.

AI에게 코드와 DB 작업을 전부 맡겼더니, 코드 레벨부터 데이터 레벨까지 통제력을 잃었다. 코드는 그나마 읽으면 된다. 데이터는 아니다. 스키마가 언제 어떤 이유로 바뀌었는지, 지금 저 테이블에 뭐가 어떤 상태로 들어가 있는지 — 내가 승인한 적 없는 결정들이 이미 쌓여 있었다.

역설 하나

원래 프로젝트를 가장 잘 아는 사람은 그 코드를 개발한 사람이다. 당연한 얘기다. 설계하면서 고민했고, 대안을 버렸고, 트레이드오프를 감수한 사람이니까.

그런데 이제 개발을 우리가 안 한다. AI가 한다.

그러면 이런 역설이 생긴다.

도구가 프로젝트를 가장 잘 아는 주체가 된다.

이건 그냥 불편한 정도의 얘기가 아니다. 도구가 더 잘 알고, 실제로 실행하고 책임지는 사람이 통제력을 잃는 순간, 프로젝트 자체가 통제력을 잃는다. 운영 중 장애가 나도 원인을 추정만 하게 되고, 요구 사항이 바뀌어도 영향 범위를 자신 있게 말하지 못한다. 결국 매 결정마다 도구에게 다시 물어봐야 하는데, 도구는 지난번에 자기가 왜 그렇게 했는지 기억하지 않는다.

책임은 나한테 남고 앎은 도구한테 있는 상태. 이게 내가 풀려고 한 문제다.

통제력은 어디서 새는가

새는 지점을 찾아보니 네 군데였다. 전부 AI가 구조적으로 못 보는 영역이다.

1. 영향도 이 함수를 고치면 어디가 깨지는지 모른다. 지금 열려 있는 파일 바깥은 존재하지 않는 세계다.

2. 코드 규칙 문서로 규칙을 줘도 대화가 길어지면 잊는다. 같은 프로젝트 안에서 같은 기능이 서로 다른 방식으로 두 번 구현된다.

3. 비즈니스 로직 표면만 이해한다. 코드에 안 적힌 도메인 규칙은 없는 것과 같은데, 중요한 규칙일수록 코드에 안 적혀 있다.

4. 연결성 명시적 호출만 본다. 트리거, 이벤트, 권한 정책, 배치 잡처럼 직접 부르지 않는 연결은 시야 밖이다. 그리고 데이터 레벨 사고는 대부분 여기서 난다.

네 개 전부 "AI가 못한다"로 끝나는 얘기가 아니다. 네 개 전부 원래 내가 쥐고 있던 것이고, 맡기는 순간 아무도 안 쥐게 되는 것들이다.

그래서 목적을 다시 썼다

여기서 한 번 멈춰야 했다. 흔한 대답은 생산성이다. 그런데 통제력을 잃은 채 얻은 속도는 부채다. 지금 30분 아끼고 다음 달에 하루를 쓴다.

목적을 이렇게 바꿔 적었다.

빨리 만들기 위해서가 아니라, 통제력을 유지한 채 설계에만 집중하기 위해서 쓴다.

말장난 같지만 이 한 줄이 이후 모든 선택을 갈랐다. 속도가 목적이면 검증은 낭비다. 통제력이 목적이면 검증은 비용이 아니라 전제 조건이 된다. AI에게 넘길 것과 절대 안 넘길 것의 경계도 여기서 나온다.

중장기 프로젝트에는 맞지 않는 방식..

솔직히 말하면, 만들고 넘기면 끝나는 프로젝트라면 이 고민을 할 이유가 없다. 통제력이고 뭐고 전부 맡기고 동작만 확인하면 된다. 그 코드를 다시 열 일이 없으니까.

내 경우는 아니다. 이건 실제로 운영 중인 서비스고, 기능을 계속 붙여가며 몇 년을 굴릴 물건이다. 그리고 회사의 입장에서도 단발성 프로젝트가 아닌 중장기 프로젝트가 진행되고, 운영과 유지보수 또한 돈을 받을 수 있는 입장이라면, 장기 프로젝트라고 봐도 된다.

기술 부채는 그나마 낫다. 눈에 보이고, 마음먹으면 갚을 수 있다.

망각은 다르다. 이건 안 보인다. 그리고 AI에게 맡긴 프로젝트에서는 훨씬 빨리 쌓인다. 잊어버린 게 아니라 애초에 알았던 적이 없는 결정들이기 때문이다. 잊은 건 더듬으면 되는데, 아무도 안 적어둔 남의 판단은 복원할 방법이 없다.

이걸 만든 나도, 까먹을 지경이라면, 결국 회사에서 특정 신규 입사자한테 인수인계를 하는 시스템이면 오죽할까

이 둘이 같이 쌓이면 결국 한 가지 상태로 수렴한다. 언제 어디서 깨질지 모르는 시스템.

운영 중인 서비스에서 진짜 지표는 속도가 아니다. 안 깨지는 것이다. 속도는 출시 전까지만 유효하고, 그 뒤로는 안정성만 남는다. 고객 입장에서 기능이 2주 늦게 나오는 건 불편이지만, 데이터가 날라가는것은 사고로 남는다, 그리고 그 사고는 신뢰성을 깨뜨리는 중대한 사건으로 남는다.

결국 AI가 도입된다고, 시간이 획기적으로 단축되진 않는다.

시간 비용은 단축되는 효과는 그리 많지 않다, 하지만 기술 비용과 기술 부채는 획기적으로 단축될 뿐이다.

저자는 욕심이 많아서, 프론트, 백엔드, 서버, 배포 등등 여러 이력이 있고, 실제로 회사의 커리어 변화 때문에 그런거라고 하지만, 내심 모두 재미있어서 다 찍먹해보고, 공부해보고 하는 스타일이다.

그때마다 느낀 점이 한계가 명확하구나 라는 것이었다.

하지만 AI가 나오고 나서부터는 내가 설계만 잘한다면, 그 어려운 기술들을 이용해서, AI 가 개발을 어시트스트 해준다. 나는 그 과정에서 QA 와 설계에 대한 테스트만 잘 해준다면, 문제가 없어지는 것이었다.

즉, QA를 어떻게 "잘" 할 것인가, 테스트는 어떻게 잘 할 것인가

이 부분이 나의 결국은 주 고민이었다. 이러한 고민과 해결 과정은 다음 포스팅에서 이어서 작성하도록 하겠습니다.