AI가 코드를 빨리 만들수록 개발자는 사용자의 삶을 봐야 해요

AI가 코드를 빨리 만들수록 개발자는 사용자의 삶을 봐야 해요

AI 뉴스 썸네일

AI 코딩 도구는 구현에 드는 시간을 빠르게 줄이고 있어요. 곽지욱 개발자는 이렇게 확보한 시간을 기능 개수를 늘리는 데만 쓰면 사용자가 원하지 않는 제품을 더 빨리 만들 수 있다고 짚어요. 개발자는 코드의 완성도와 함께 사용자의 하루를 이해하는 일까지 맡아야 한다는 제안이에요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
문제 정의	공급자가 그럴듯하다고 여긴 기능과 사용자가 절실하게 필요로 하는 해결책은 다를 수 있어요	구현 속도가 빨라질수록 잘못 잡은 문제도 더 빠르게 제품이 돼요
개발자 역할	코드 작성에 머물지 않고 고객 문의와 실제 업무 과정을 가까이서 봐야 해요	작은 관찰이 기능 우선순위와 운영 방식을 바꿀 수 있어요
AI 활용	에이전트가 아껴 준 시간은 자동으로 사용자 가치가 되지 않아요	더 많은 기능과 더 나은 문제 이해 가운데 어디에 시간을 쓸지 팀이 정해야 해요
기본 역량	코드 품질과 변경 영향 검증은 여전히 개발자의 기본기예요	검증 능력이 약하면 빨라진 개발 속도만큼 오류도 빠르게 쌓일 수 있어요

1. 빠른 구현보다 먼저 사용자의 하루를 봐야 해요

글은 다큐멘터리 〈말하는 건축가〉에 나온 건축가 정기용의 일화에서 출발해요. 한 농촌 지역에 새 면사무소를 지으려 하자 주민들은 건물 대신 목욕탕을 원했어요. 집에서 물이 충분히 나오지 않아 목욕을 하려면 차를 빌려 대전까지 가야 했기 때문이에요. 행정기관이 준비한 면사무소보다 주민의 생활 문제를 푸는 목욕탕이 더 절실했던 셈이에요. 1

곽지욱 개발자는 이 장면을 제품 개발에 대입해요. 팀이 필요하다고 판단한 기능은 새 면사무소처럼 합리적으로 보일 수 있어요. 하지만 사용자의 업무와 생활을 직접 보지 않았다면 가장 불편한 지점을 비껴갈 수 있어요. 좋은 아키텍처와 깔끔한 코드는 필요하지만, 무엇을 만들지 잘못 정하면 기술적 완성도가 높아도 사용자의 문제는 남아요.

728x90

AI 코딩 에이전트는 이 간격을 더 크게 만들 수 있어요. 요구사항을 코드로 바꾸는 시간이 짧아지면 팀은 이전보다 많은 기능을 만들 수 있어요. 문제 정의가 틀렸을 때는 필요 없는 기능도 같은 속도로 늘어나요. 글이 경계하는 지점은 AI 도구 자체보다 개발 속도를 곧바로 제품 가치로 받아들이는 태도에 있어요.

코드 역량이 덜 중요해졌다는 뜻은 아니에요. 에이전트가 작성한 코드를 검토하지 못하거나 작은 수정이 서비스 전체에 미칠 영향을 읽지 못하면 빠른 구현이 오히려 부담돼요. 테스트, 리뷰, 장애 대응 같은 기본기를 갖춰야 사용자를 관찰하고 제품 방향을 고민할 시간도 생겨요. 기술 기본기를 낮추기보다 그 위에 제품 판단을 더하자는 주장에 가까워요. 2

사용자를 이해하는 데 거대한 조사 프로젝트가 꼭 필요한 것도 아니에요. 고객 문의 한 건을 개발자가 직접 읽을 수 있어요. 사용자가 주문을 접수하거나 비용을 정산하는 과정을 옆에서 보는 방법도 있어요. 팀이 편의를 위해 없앤 입력 단계가 누군가에게는 내용을 확인하는 마지막 기회였을 수 있어요. 상담 자동화가 비용을 줄이는 동안 도움이 급한 사용자의 연결 통로를 막지는 않았는지도 살펴야 해요.

이 관점은 기능 우선순위를 정할 때 바로 써볼 수 있어요. 새 기능을 제안하기 전에 어떤 사용자가 언제 불편을 겪는지 적어요. 지금 쓰는 우회 방법과 그 과정에 드는 시간도 확인해요. 기능을 공개한 뒤에는 사용량만 세지 말고 실제 처리 시간이 줄었는지, 문의가 다른 단계로 옮겨 갔는지까지 봐야 해요. 사용자의 행동을 확인하면 기능 목록보다 해결해야 할 문제가 먼저 보여요.

AI가 아껴 준 시간을 어디에 배분할지도 팀의 선택이에요. 같은 기간에 기능을 2배 더 만들 수도 있고, 고객 인터뷰와 현장 관찰에 시간을 남길 수도 있어요. 전자는 산출량을 빠르게 보여 줘요. 후자는 만들지 않아도 될 기능을 걸러 내고 기존 제품의 마찰을 찾는 데 도움이 돼요. 두 활동의 균형은 제품 단계마다 달라지지만, 구현 속도만 성과로 삼으면 사용자 이해에 쓸 시간은 쉽게 밀려나요.

개발자에게 필요한 지식의 범위도 넓어져요. 철학이나 인문학, 심리학을 전공 수준으로 배워야 한다는 말은 아니에요. 사용자가 왜 특정 행동을 반복하는지, 기술적 효율이 누구에게 비용을 넘기는지 질문할 수 있는 시야가 필요하다는 뜻이에요. 제품 엔지니어가 기획자나 연구자의 역할을 대신하기보다 코드와 사용자 경험 사이의 연결을 더 자주 확인하는 방식이에요.

왜 중요한가요

생성 속도가 빨라진 팀에서는 문제를 고르는 기준이 이전보다 더 중요해져요. 개발 공수가 컸던 시기에는 구현 비용이 자연스럽게 기능 수를 제한했어요. AI 도구가 그 제한을 낮추면 실험을 더 많이 할 수 있지만, 검토되지 않은 요구사항도 제품에 쉽게 들어갈 수 있어요. 사용자 관찰과 우선순위 판단이 개발 과정 앞단의 병목으로 남아요. 2

팀은 개발 생산성을 평가하는 지표도 함께 바꿔야 해요. 생성한 코드 줄 수, 완료한 티켓 수, 출시한 기능 수만으로는 사용자의 문제가 줄었는지 알기 어려워요. 처리 시간, 이탈 단계, 반복 문의, 수동 우회 작업처럼 사용자의 행동이 달라졌는지 확인할 지표가 필요해요. 기능을 많이 공개했는데 문의와 우회 작업이 그대로라면 구현 속도와 별개로 문제 정의를 다시 봐야 해요.

개발자가 고객 접점을 가까이 두면 설계 판단도 구체적으로 달라질 수 있어요. 오류 메시지 한 줄, 입력 순서, 상담 연결 방식처럼 작은 결정이 실제 업무의 중단 여부를 가르기도 해요. 고객지원팀이 정리한 요약만 받는 데서 끝내지 않고 원문 문의와 사용 화면을 함께 보면 맥락 손실을 줄일 수 있어요. 에이전트가 반복 구현을 맡는 동안 개발자는 이런 판단에 시간을 더 쓸 수 있어요.

이 글은 개인 개발자의 경험과 문제의식을 담은 에세이예요. AI 도입 효과를 수치로 검증한 연구 결과는 아니에요. 다만 "더 빨리 만들 수 있다"와 "더 필요한 것을 만들고 있다"를 분리해서 보자는 질문은 제품 팀이 바로 점검해 볼 만해요. 빠른 구현을 유지하면서 사용자와 만나는 시간을 일정에 넣는지가 AI 시대 개발 문화의 차이를 만들 수 있어요.

참고 자료

1. AI 시대, 개발자는 면사무소가 아니라 목욕탕을 만들어야 한다 — GeekNews
2. 면사무소와 목욕탕 — 곽지욱