AI가 짠 코드, 믿어도 될지 판단하는 법

이 블로그에서 광고 자리 45곳이 3개월간 페이지에서 빠져 있었어요. 코드를 읽는 제가 못 봤고요.

AI에게 기능 하나를 시키면 몇 분 만에 뚝딱 나와요. 문제는 그게 틀렸을 때도 말투가 똑같다는 거죠. AI는 자신 있게 틀려요. 코드를 읽을 줄 알면 어디가 이상한지 눈에 걸리기라도 하는데, 코드를 못 읽으면 그 확신에 찬 결과물을 그냥 믿는 수밖에 없어 보여요.

정말 그럴까요. 저는 아니라고 봐요. 코드를 못 읽어도 판단할 수 있는 지점은 분명히 있거든요.

코드 대신 볼 네 가지

검증이라고 하면 거창하게 들리는데, 사실 순서만 정하면 돼요. 코드를 열어볼 필요 없이, 이 넷만 매번 확인하면 그만이에요.

②의 데이터 확인과 ③의 환각 가려내기는 각각 화면에 목록을 붙이던 편과 에러를 AI로 고치던 편에서 더 풀었어요. 큰 덩어리를 한꺼번에 맡기면 어디서 어긋났는지 찾기 어려우니, 작게 쪼개서 시키는 법도 여기서 그대로 통해요.

그런데 이 넷도 뚫려요

여기까지는 다른 데서도 볼 수 있는 얘기예요. 정작 중요한 건 그다음이라고 봐요. 이 넷을 다 하고도 놓친 적이 있거든요.

제가 겪은 세 장면을 그대로 적을게요. 셋 다 이 블로그에 따로 써둔 것들이에요.

화면을 눌러봤는데 멀쩡했어요

이 블로그에 광고 자리를 넣는 부품이 있는데, 이름 하나를 잘못 써서 글 18편에서 광고 자리 45곳이 페이지에서 통째로 빠졌어요. 그런데 화면은 멀쩡했어요. 에러도 안 났고요. 그래서 3개월을 몰랐습니다.

여기서 배운 게 이거예요. 화면 확인은 “있어야 할 게 없어진 것”을 못 잡아요. 뭔가 잘못되면 눈에 띈다는 건, 잘못된 게 화면에 나올 때만 맞는 말이에요. 조용히 빠진 건 아무 표시가 없어요.

데이터도 맞았는데 순서가 틀렸어요

회사 일이라 자세히는 못 적지만 이런 일이 있었어요. 한 고객사와 세 번 미팅을 했는데, 마지막 컨펌 자리에서 고객이 이의를 제기했어요.

틀린 건 값이 아니라 순서였어요. 보통은 A → B → C로 일하는데 그 회사는 A → C → B로 일하거든요. 그걸 반영하려고 저희를 찾은 거였고요. 데이터를 한 줄씩 보면 다 정상이에요. 순서만 일반적인 쪽으로 돌아가 있었어요.

데이터 확인은 “값이 맞는가”는 잡아도 “내 사정에 맞는가”는 못 잡아요. 그리고 그 사정을 아는 사람이 밖에 있으면, 내부에서는 끝까지 안 잡힙니다. 산출물이 늘어난 얘기에 이 건을 자세히 적었어요.

되물었더니 설명이 너무 매끄러웠어요

친구가 만들던 서비스에서 AI가 비동기 처리와 큐를 권했어요. 이유까지 조리 있게 붙여서요. 틀린 말도 아니었고요. 그래서 친구는 그대로 갔어요.

문제는 그 서비스가 그만큼 크지 않았다는 거예요. 처리가 2초 걸리는 일에 시스템을 하나 더 붙인 셈이었죠. 결국 동기 처리에 로딩 스피너 하나로 바꿨어요.

되묻기는 “말이 되는가”는 잡아도 “지금 나에게 맞는가”는 못 잡아요. 오히려 설명이 매끄러울수록 확인이 끝난 걸로 읽혀요. 반대할 근거가 없으면 사람은 더 복잡한 쪽을 고르거든요. 이 얘기는 설계가 과한지 판단하는 편에 따로 풀었어요.

그래서 하나를 더 붙였어요

세 번 다 같은 자리에서 뚫렸어요. 내 사정이 어디에도 안 적혀 있었다는 것.

광고 자리는 몇 개가 있어야 하는지 적어둔 데가 없었고, 고객사의 예외는 회의록에 적혔지만 산출물이 갱신되는 동안 사라졌고, 친구의 서비스 규모는 첫 대화에만 있다가 뒤로 밀렸어요.

그래서 넷 앞에 하나를 더 뒀어요. 시키기 전에 조건을 대화 밖에 적어두기.

메모장 한 줄이면 돼요. “사용자는 나 포함 다섯 명”, “이 목록은 항상 최신순”, “결제는 안 붙임”. 대화는 길어지면 앞부분이 밀려나지만, 파일에 적어둔 건 안 밀려요. 나중에 대조할 기준도 그때 생기고요.

여기선 멈추고 사람을 불러요

다 거쳐도 안심이 안 되는 순간이 있어요. 이럴 땐 혼자 더 밀어붙이지 말고 멈추는 게 맞죠.

저라면

혼자 쓰는 앱인지, 남이 쓰거나 돈·개인정보가 오가는 서비스인지에 따라 멈출 자리가 달라져요.

유리했던 건 인정하고, 그래도 는다는 것도

솔직히 말하면 제가 개발자라 유리했던 지점은 분명 있었어요. 화면이 어색하게 깨진 걸 남들보다 빨리 알아챘고, 테스트나 타입 같은 관문을 세우는 것 자체가 코드를 아니까 가능했어요. 이걸 없다고 하면 거짓말이죠.

그런데 위 세 장면을 보면 알 수 있듯, 개발자라고 다 잡는 것도 아니에요. 광고 자리 45곳은 제가 3개월간 못 봤고, 고객사 건도 내부에서는 아무도 못 잡았어요. 코드를 읽는 능력이 막아주는 건 생각보다 좁아요.

정답이 아니라 지금 쓰는 기준이에요

코드를 못 읽는다고 검증을 포기할 이유는 없어요. 화면·데이터·AI의 설명·내 의도, 이 넷을 대조하는 습관이면 대부분은 걸러져요.

다만 그 넷이 잡는 건 “돌아가는가”까지예요. “내 사정에 맞는가”는 조건을 미리 적어둬야 잡히고요. 그리고 돈·개인정보가 얽히면 거기선 멈추고 사람을 불러야 해요.

바이브코딩에서 개발자의 무게중심이 타이핑에서 판단으로 옮겨간다면, 그 판단은 코드를 읽는 사람만의 전유물이 아니에요. 화면을 보는 눈과, 내가 뭘 원했는지 적어두는 습관. 그게 시작이라고 봐요.