지난 3년간 LLM기반 코딩 어시스턴트 툴의 발전 속도는 눈부시다.

이런 변화를 보며 의뢰인들은 기대감을 품는다. 이제 AI가 있으니 개발자들이 더 이상 날림으로 일하지 않겠지, 누구나 높은 퀄리티의 소프트웨어를 만들 수 있겠지.

즉 AI 발전 수준에 비례해서 프로덕트의 퀄리티가 상승할 것이라고 많은 사람들이 믿고 있지만 현실은 그렇지 못하다. AI가 아무리 발전해도 대충 일하는 개발자는 더 효율적인 방식으로 대충 일한다.

이걸 해석하는 몇가지 이론이 있는데 여기서는 나만의 관점으로 원인을 짚어보겠다.

그건 AI가 아무리 발전해도 인간 본성을 바꿔주지는 못한다는 전제에서 출발한다.

그 인간 본성이란 무엇인가. 바로 일은 최대한 적게 하고 돈은 최대한 많이 벌고 싶은 지극히 당연한 본성이다.

만일 일을 한 시간을 하든 두 시간을 하든 세 시간을 하든 클라이언트가 느끼는 만족도가 똑같다면 대부분의 사람들은 당연히 한시간을 일할 것이다. 최소한의 자기 할일만 한다는 것이다.

이것이 가능한 이유는 클라이언트가 느끼는 주관적인 만족도와 제품의 퀄리티 사이에 생각보다 상관관계가 적기 때문이다.

실제 사례를 들어보겠다. 지난 2025년, 어떤 고객에게 의뢰를 받았다. 강의 예약 플랫폼을 웹사이트로 구현해 놓았는데 대부분의 개발이 끝났으니 마무리를 부탁한다는 것이었다. 그런데 본인이 실제 테스트를 수행해 본 바, 결제 기능같은 극도로 중요한 기능조차 제대로 구현되어 있지 않았다. 결제에 트랜잭션이 적용되어 있지 않아서 결제 도중 에러가 발생하면 DB의 데이터가 미완성인 상태로 꼬여버릴 수도 있었다. 그리고 여러 사용자가 동시에 단 하나의 남은 자리를 예약할 때 생기는 레이스 컨디션 처리가 되어있지 않아서 초과된 인원을 예약 받을수도 있는 상황이었다. 환불 기능은 전혀 구현되어 있지 않았다.

그 조직에는 전문적인 QA 팀이 없었고 외주 개발자가 만든 코드의 테스트를 일반 직원이 수행했는데, 그 테스트 수준이 처참하여 기본적인 기능이 제대로 돌아가고 있는지조차 체크를 못한 것이었다. 그들 체감상으로는 약 95% 정도 구현이 되어 있는 것으로 생각했지만 내가 테스트해보니 70%도 구현되어 있지 않았다.

개발자들이 이렇게 개발을 대충 하는 데에는 크게 두 가지 이유가 있다. 첫 번째는 개발자로서 개념이 부족하여 이런 세세한 사항을 고려해야 한다는 개념조차 없는 경우이다. 이 경우에는 악의는 없는 셈이다. 두 번째가 중요한데 이런 세세한 디테일을 고려해야 한다는 것을 알고 있음에도 고의적으로 개발을 하지 않는 경우이다.

다시 말해서 내가 개발 완성도를 다소 낮춘다고 해도 평판이 훼손되는 리스크가 없고 소득에서 손해를 볼 일이 없는 경우에 대부분의 개발자는 대충 개발하는게 이득이라는 매우 합리적인 판단을 한다. 이건 당연하다.

그거 그냥 프롬프트에 타이핑 몇번 하면 해결되는 간단한 일인데 뭐가 어려워서 그것마저 안하냐고 나이브하게 생각하는 사람이 있을텐데, 그렇게 타이핑 하는것 마저도 시간과 에너지가 소비되는 일이고 프롬프트에 어떤 입력값을 넣을지 생각하는 것도 경우에 따라서 상당한 인지적 부하를 야기하는 스트레스 작업이다. 특히나 논리적으로 장문의 타이핑을 하는 것이 평상시에 습관화되지 않은 사람이라면 더욱 더 그렇다.

그리고 얼마나 개발을 대충 하는지는 클라이언트의 수준에 따라 좌우되는데 의뢰인이 개발 문외한이라 개발적 지식이 전혀 없거나 테스트를 대충한다고 판단이 들면 십중팔구 개발도 그만큼 대충한다. 딱 의뢰인이 눈치채지 못할 수준으로 겉으로 보기에는 정상 작동하는 것처럼 딱 그만큼만 개발한다. 반대로 개발 지식이 풍부하거나 테스트를 꼼꼼히 하는 스타일이라고 판단되면 개발을 그만큼 타이트하게 한다. 사람 봐가면서 개발 퀄리티가 들쭉날쭉한다는 것이다.

누군가는 이렇게 반문할 것이다. 그건 그냥 니 추측과 가설이 아니냐? 네가 그걸 어떻게 아냐? 글쎄, 적어도 내 의뢰인들은 전부 다 이랬다. 처음엔 다른 개발자에게 일을 맡겼다가 이후 나에게 의뢰를 맡긴 경우를 보면 예외없이 이러했다. 그리고 솔직히 말하면 나조차도 가끔 그런 유혹을 받는데 다른 개발자들은 오죽할까.

이건 외주 개발뿐만 아니라 회사의 정직원도 마찬가지다. 어떤 상황을 가정해보자. 한 개발자가 코드를 구현했는데 이렇게 개발했다가는 문제가 생길 것 같다고 뒤늦게 자각을 한 상황이다. 그런데 그 문제가 당장 발생하지는 않을 것 같고 최소 1년 후에는 수면위로 드러날 것 같다. 이걸 지금 해결하는 것이 최선의 선택이지만 거기에 드는 시간과 정신적인 에너지 소비도 번거롭고 무엇보다도 1년 후에 이 회사에 남아 있을 것 같지도 않다. 이런 경우에 대부분의 개발자는 그냥 적당히 넘어가는 선택을 할 것이다. 그 개발자가 특별히 나쁜 사람이라서 그런것도 아니고 대부분은 이런 선택을 당연히 한다. 왜냐하면 내가 지금 이 일을 처리하려고 시간과 에너지를 투입한다고 하더라도 당장 얻을 수 있는 것이 없고 잃을 것도 없다고 판단하기 때문이다.

정직원의 경우도 이러한데 프리랜서의 경우에는 훨씬 더 심하다. 대부분의 경우는 한번 보고 의뢰가 끝나면 안 볼 사이이기 때문이다. 그리고 장기적으로 상대하는 고객이라면 더 좋은데 한참 뒤에 문제가 생기면 유지보수라는 명목으로 비용을 청구할 수 있기 때문이다.

이런 문제는 GPT 5.6이 아니라 GPT 56이 나와도, 아니 이 세상이 멸망하기 전까지 절대로 변하지 않는 인간의 본성이다. 돈을 똑같이 벌 수 있다면 일을 더 적게하는 선택을 한다는 인간본성 말이다.

그렇기 때문에 개발자 후기에서 평점이 높은 개발자라고 하더라도 그 평점이 꼭 제품 퀄리티로 연결되지 않는다는 것을 의뢰인들은 알아야 할 것이다. 물론 평점이 낮은 것보다 높은 게 좋겠지만 평점이 높다고 안심할 수 있는것도 아니란 말이다.

그렇다면 개발자의 어떤 면을 봐야 하는가? 여기에는 두가지 측면이 있다. 기질적인 면을 보는 게 좋다고 생각하는데 천성적으로 꼼꼼한 사람들이 있다. 이런 사람들은 어떤 일을 꼼꼼히 체크하지 않고 지나가는 게 성격상 잘 안된다. 그게 이득인지 손해인지를 따지기 이전에 성격상 대충 넘어가는게 잘 안 되는 사람들이 있다. 이런 사람들에게 일을 맡기는게 좋다고 생각한다. 이런 기질을 알아보려면 대화를 해봐야 한다. 대화로 해봐서 판단하는 방법 외에는 없다.

두 번째는 소위 말하는 개발자 부심이 있는 경우인데 자기가 만드는 소프트웨어의 퀄리티가 높다는 곤조가 있는 부류이다. 이 경우는 자기가 개발자라는 프라이드가 있는 케이스인데 이런 사람들이 허접한 소프트웨어를 만들었다가는 인지 부조화가 오기 때문에 좀처럼 개발 꼼수를 부릴 가능성이 낮은 성격이다. 이런 성향인지 파악하는 것도 그 사람과 대화를 해봐야 한다.

결론적으로 어떤 개발자가 일을 꼼꼼하게 마무리 지을 것인지 판단하는 기준으로는 기질과 성격적인 측면이 크게 좌우한다고 생각한다. 연차가 10년이 되었든 20년이 되었든 그런 정보로는 일을 끝까지 제대로 마무리하리라는 단서를 얻을 수가 없다.