빈칸인데 왜 ‘성공’이라고 써버렸을까
비어 있어야 할 결과값에 자동으로 붙은 ‘성공’이라는 한 단어가 기획 의도와 시스템 동작의 차이를 드러냈다.

지난주에 서버 쪽 작업을 하다가 아주 사소해 보이는 문제 하나를 만났다.
프론트엔드 개발자가 결과를 저장하는 항목 하나를 수정해달라고 했다. 처리 결과가 아직 없을 때는 그 자리를 비워두자는 요청이었다.
처음 들었을 때는 별로 복잡한 일처럼 보이지 않았다. 값이 있으면 넣고, 없으면 비워두면 되는 일이라고 생각했다.
AI에게 물었다.
돌아온 답을 읽어보니 굳이 프로그램을 수정할 필요가 없다고 했다. 값을 보내지 않아도 된다는 설명이었다.
그런데 설명을 조금 더 읽다가 이상한 부분이 눈에 들어왔다.
값이 없으면 자동으로 ‘Success’를 넣는다고 했다.
잠깐 멈췄다.
프론트엔드 개발자가 말한 것은 “값을 보내지 않아도 된다”가 아니었다.
“아직 결과가 없으니 비어 있어야 한다”였다.
둘은 전혀 다른 이야기였다.
시험을 아직 치르지도 않았는데 성적표의 결과 칸에 자동으로 ‘합격’이라고 적어놓는 것과 비슷했다. 나중에 실제 결과가 들어오면 바뀔 수 있다고 해도, 처음부터 성공했다고 기록해놓는 것은 이상했다.
그래서 다시 물었다.
“그러니까 기본값이 Success로 들어가면 안 되고 비어 있는 값으로 들어가야 한다는 것입니다.”
그제야 AI의 답도 달라졌다.
기존에는 값이 없으면 자동으로 성공이라고 채워주는 부분이 있으니, 그것을 없애야 한다는 설명이었다.
나는 개발자가 아니다.
그래서 코드 한 줄이 왜 그렇게 동작하는지를 바로 읽어낼 수는 없다. 하지만 이번 문제에서 코드 자체를 이해할 필요는 없었다.
비어 있다는 것과 성공했다는 것은 다르다.
그건 개발 지식의 문제가 아니라 의미의 문제였다.
이런 순간이 생각보다 자주 생긴다.
AI에게 어떤 기능을 설명하면 AI는 그것이 돌아가도록 만드는 데 집중한다. 개발자 역시 구현할 때는 입력값과 반환값, 오류 상황처럼 시스템의 규칙을 먼저 본다.
그런데 서비스를 기획하는 사람에게 중요한 것은 그 값이 실제 사용자에게 무엇을 뜻하느냐다.
‘Success’라는 단어 하나도 시스템에게는 단순한 값이지만, 서비스에서는 이미 어떤 일이 정상적으로 끝났다는 의미가 된다.
아무 일도 끝나지 않았는데 그런 도장을 미리 찍어놓으면 안 된다.
결국 해당 부분을 수정했다.
값을 보내지 않으면 실제로 빈 상태로 남도록 바꾸고, 데이터 구조를 설명하는 문서도 함께 수정했다.
그다음 다시 AI에게 검수를 맡겼다.
코드만 고쳐진 것이 아니라 설명서에도 같은 기준이 적용됐는지 확인하게 했다.
이번에는 둘이 일치했다.
그제야 다음 단계로 넘어갔다.
지난주 처음 AI에게 이 프로젝트를 읽게 할 때도 비슷했다. 한꺼번에 여러 명령을 실행시키지 않고 하나씩 확인했다. 이번에도 결과적으로 같은 방식이었다.
AI가 “문제없다”고 말했을 때 바로 넘어가는 대신, 그 말이 내가 이해한 요구와 같은 뜻인지 한 번 더 확인했다.
내가 코드를 몰라서 생기는 약점도 있지만, 반대로 코드를 모르기 때문에 더 단순하게 볼 수 있는 부분도 있다는 생각이 들었다.
“그래서 이 값은 지금 무엇을 의미하는가?”
“사용자는 아직 아무 결과도 받지 않았는데 왜 성공이라고 되어 있는가?”
이런 질문은 함수 이름을 몰라도 할 수 있다.
앞으로 개발을 더 이해하게 되더라도 이 질문은 놓치고 싶지 않다.
기술적으로 가능한 것과 서비스의 의미가 맞는 것은 같은 이야기가 아니기 때문이다.
그날의 성장 노트
내가 저지른 실수 — 처음에는 “값을 필수로 입력하지 않는다”는 설명을 “값을 비워둔다”는 의미와 같은 것으로 받아들였다.
AI의 맹점 — 요구사항의 문장이 비슷해 보여도 실제 서비스에서 갖는 의미까지 자동으로 구분해주지는 않았다.
비개발자의 원칙 — 코드를 이해하지 못하더라도 값이 무엇을 의미하는지는 확인한다. 기술 설명보다 먼저 “이게 사용자 입장에서 무슨 뜻인가”를 묻는다.
글을 읽고 함께 이야기하고 싶은 일이 생겼다면.
결을 같이 하기