AI로 개발하는데, 왜 만들수록 할 일이 늘어날까?

기능 비대화에 대해

2026.10.19 | 조회 58 |
0
|
첨부 이미지

 

안녕하세요. 쇼들리로그입니다!

요즘 AI를 활용하면 아이디어 하나만으로도 서비스를 꽤 빠르게 만들어볼 수 있죠. 예전에는 개발에 많은 시간과 노력이 필요했던 기능도 AI에게 설명하면 생각보다 쉽게 구현되는 경우가 많습니다.

그런데 막상 AI와 함께 서비스를 만들다 보면 조금 이상한 상황을 경험하게 됩니다.

처음에는 몇 가지 기능만 만들면 금방 완성할 수 있을 것 같았는데, 개발이 진행될수록 할 일이 줄어들기는커녕 오히려 계속 늘어나는 겁니다.

코드는 이미 수천, 수만 줄이 쌓였고 화면도 제법 그럴듯하게 만들어졌습니다. 그런데 아직 구현해야 할 기능도 많고, 수정해야 할 문제도 계속 발견됩니다.

분명 처음보다 훨씬 많은 것을 만들었는데, 왜 완성까지 남은 거리는 좀처럼 줄어들지 않는 걸까요?

이번에는 AI로 서비스를 개발하면서 경험할 수 있는 기능 비대화, 두서없는 작업 지시, 반복되는 오류에 대해 이야기해 보려고 합니다.

AI가 개발을 쉽게 만들어준 것은 분명하지만, 그만큼 우리가 새롭게 신경 써야 할 부분도 생겼다는 이야기입니다.

그럼 시작해 볼게요!


처음에는 분명 간단한 서비스였는데

예를 들어 간단한 할 일 관리 서비스를 만든다고 가정해 보겠습니다.

설레는 마음으로 AI와 첫 기획을 시작하는 나
설레는 마음으로 AI와 첫 기획을 시작하는 나

처음 기획은 아주 단순합니다.

할 일을 등록하고, 완료하면 체크하고, 필요 없는 항목은 삭제하는 정도입니다.

이 정도면 충분히 쓸 만한 서비스가 될 것 같습니다.

AI에게 기획을 설명하고 개발을 시작합니다. 생각보다 빠르게 화면이 만들어지고, 기본적인 기능도 잘 동작합니다.

여기까지는 순조롭습니다.

그런데 실제로 사용해 보니 한 가지 아쉬운 점이 보입니다.

"할 일이 많아지면 검색 기능도 필요하지 않을까?"

AI에게 검색 기능을 추가해 달라고 요청합니다.

검색 기능을 만들고 나니 이번에는 카테고리별로 구분할 수 있으면 좋겠습니다. 카테고리를 추가하고 나면 태그 기능도 있으면 편리할 것 같고, 태그를 만들고 보니 필터 기능도 필요해 보입니다.

여기서 끝나지 않습니다.

매일 반복하는 할 일을 자동으로 등록하면 좋겠고, 마감일이 다가오면 알림을 보내주면 좋겠습니다. 달력에서도 할 일을 확인할 수 있다면 더 편리하겠죠.

처음에는 등록, 완료, 삭제 정도만 생각했던 서비스였는데 어느 순간 검색, 태그, 필터, 반복 일정, 알림, 캘린더까지 갖춘 서비스가 되어 있습니다.

각각의 기능만 놓고 보면 나쁜 아이디어는 아닙니다. 실제로 사용자에게 도움이 될 만한 기능들이기도 합니다.

그런데 한 가지 질문이 남습니다.

이 기능들이 정말 처음부터 필요했던 기능일까요?

기능 비대화(Feature Creep)

이렇게 개발 과정에서 처음 정했던 범위를 넘어 기능이 점점 추가되는 현상을 흔히 기능 비대화, 즉 Feature Creep이라고 부릅니다.

물론 이런 현상은 AI가 등장하기 전부터 있었습니다.

개발을 진행하면서 요구사항이 바뀌거나 새로운 아이디어가 떠오르는 일은 흔하니까요.

다만 AI를 활용하면서 기능을 추가하는 진입장벽이 낮아진 것은 분명합니다.

예전 같으면 개발 일정이나 비용을 생각해 보류했을 기능도 이제는 가볍게 시도해 볼 수 있습니다.

그리고 그 편리함이 때로는 기능을 무분별하게 늘리는 원인이 되기도 합니다.


만들기 쉬워지니 포기하기가 어려워졌다

예전에는 기능 하나를 추가하려고 해도 생각할 것이 많았습니다.

구현하는 데 얼마나 시간이 걸릴지, 현재 구조에서 가능한지, 기존 기능에 영향을 주지는 않을지 따져봐야 했습니다.

기능을 추가하기 전에 고민할 시간이 자연스럽게 생겼던 셈입니다.

그런데 AI와 개발할 때는 상황이 조금 달라집니다.

생각보다 구현이 잘 되자 점점 욕심이 커지는 나
생각보다 구현이 잘 되자 점점 욕심이 커지는 나

새로운 아이디어가 떠오르면 일단 물어봅니다.

"이런 기능도 추가할 수 있을까?"

대부분의 경우 AI는 구현 방법을 설명하고 필요한 코드를 작성해 줍니다.

실제로 몇 번의 대화만으로 기능이 동작하는 모습을 보면 꽤 재미있습니다.

그러다 보면 생각이 달라집니다.

"어? 이것도 되네?"

"그럼 저것도 가능하겠는데?"

"이왕 만드는 거 이것까지 넣어볼까?"

처음에는 꼭 필요한 기능만 만들려고 했는데, 어느 순간부터는 떠오르는 아이디어를 하나씩 구현하는 것 자체가 재미있어집니다.

심지어 아직 완성하지 않은 기능이 있는데도 새로운 기능을 만들고 싶어집니다.

여기에 AI가 먼저 새로운 기능을 제안하기도 합니다.

"이 서비스에 추가하면 좋을 기능이 있을까?"

이렇게 물어보면 AI는 검색, 통계, 알림, 협업, 자동화 등 여러 아이디어를 제시합니다.

설명을 읽다 보면 하나같이 그럴듯합니다.

하지만 AI가 제안한 기능이 실제 사용자에게 꼭 필요한 기능이라는 의미는 아닙니다.

일반적으로 유용한 기능과 지금 만들고 있는 서비스에 필요한 기능은 다를 수 있으니까요.

만들 수 있다는 것과 만들어야 한다는 것은 다른 문제입니다.

그런데 막상 AI와 개발하고 있을 때는 이 둘을 구분하기가 생각보다 쉽지 않습니다.


생각나는 대로 AI에게 작업을 시키기 시작하면

여기서 또 다른 문제가 생깁니다.

기능이 계속 늘어나는 것도 문제지만, 그 기능들을 어떤 순서로 개발하느냐도 중요하기 때문입니다.

AI로 개발하다 보면 생각나는 것을 그때그때 요청하게 되는 경우가 많습니다.



버그 고치랴, 기능 추가하랴, AI에게 정신없이 명령을 하달하는 나
버그 고치랴, 기능 추가하랴, AI에게 정신없이 명령을 하달하는 나

예를 들어 로그인 기능을 만들고 있다고 해보겠습니다.

로그인 화면을 만들다가 프로필 화면도 필요할 것 같아 작업을 요청합니다.

프로필 화면을 만들던 중에는 이미지 업로드 기능이 생각납니다.

이미지 업로드를 구현하다 보니 외부 스토리지 연동이 필요해지고, 이번에는 파일 저장 방식까지 변경합니다.

그러다가 다시 로그인 화면으로 돌아옵니다.

"아까 만들었던 로그인 방식도 조금 바꿔줘."

AI는 요청에 따라 기존 코드를 수정합니다.

그런데 이미 다른 기능과 연결된 부분을 충분히 확인하지 않은 채 변경하면 문제가 생길 수 있습니다.

여기서 중요한 건 AI가 일을 못해서만 발생하는 문제가 아니라는 점입니다.

사람이 직접 개발하더라도 작업 순서가 계속 바뀌고 요구사항이 수시로 변경되면 프로젝트를 관리하기 어려워집니다.

AI는 요청한 일을 빠르게 처리해 주지만, 지금 요청한 일이 전체 프로젝트에서 어떤 우선순위를 가져야 하는지까지 항상 올바르게 판단해 주는 것은 아닙니다.

결국 작업을 지시하는 사람이 방향을 잡아줘야 합니다.

그런데 그 방향을 잡아야 할 사람이 새로운 기능을 추가하는 재미에 빠져 계속 다른 일을 시키고 있다면 어떨까요?

AI는 열심히 일하고 있는데 정작 프로젝트는 점점 복잡해질 수 있습니다.

AI가 일을 빠르게 처리하는 것과 프로젝트가 체계적으로 진행되는 것은 별개의 문제입니다.


분명 고쳤는데 왜 다른 곳이 또 안 될까?

여러 기능을 오가며 개발하다 보면 이전에 정상적으로 동작하던 기능에 문제가 생기는 경우가 있습니다.

예를 들어 어떤 버튼을 눌렀을 때 화면이 전환되지 않는 문제가 발생했다고 해보겠습니다.

AI에게 수정을 요청합니다.

"이 버튼을 누르면 화면이 전환되지 않아. 확인해서 수정해 줘."

AI가 코드를 수정하고 다시 실행해 보니 정상적으로 동작합니다.

문제가 해결된 것 같습니다.

그런데 새로운 기능을 추가하고 나서 확인해 보니 이전에 잘 동작하던 다른 화면에서 오류가 발생합니다.

알고 보니 여러 화면에서 공통으로 사용하던 코드를 수정하면서 예상하지 못한 영향이 생긴 겁니다.

이처럼 기존에 정상적으로 동작하던 기능이 코드 변경 이후 다시 문제가 되는 현상을 회귀 버그(Regression Bug)라고 합니다.

물론 AI 개발에서만 발생하는 문제는 아닙니다. 일반적인 소프트웨어 개발에서도 흔히 발생합니다.

다만 AI를 활용하면 여러 파일의 코드가 짧은 시간에 변경될 수 있기 때문에, 변경 내용을 충분히 확인하지 않고 다음 작업으로 넘어간다면 문제가 더 복잡해질 수 있습니다.

특히 코드의 구조를 충분히 이해하지 못한 상태에서 AI에게 수정 작업을 계속 요청한다면 어떤 부분이 왜 변경됐는지 파악하기 어려워질 수도 있습니다.

문제 하나를 해결했는데 다른 문제가 발생하고, 그 문제를 해결하다가 또 다른 부분을 수정하는 상황이 반복됩니다.

처음에는 개발이 빠르게 진행되는 것 같았는데 어느 순간부터는 새로운 기능보다 기존 기능을 수정하는 데 더 많은 시간을 쓰게 되는 겁니다.


"아니, 아까 고쳤는데 왜 또 이러는 거야?"

AI를 처음 활용해 개발할 때 개인적으로 가장 답답했던 부분 중 하나가 있습니다.

바로 같은 문제가 반복되는 상황이었습니다.

어떤 기능을 개발하다가 오류가 발생해서 AI에게 수정을 요청합니다.

AI가 코드를 수정하고, 다시 실행해 보니 정상적으로 동작합니다.

"이제 해결됐네."

그렇게 다음 작업으로 넘어갑니다.

그런데 한참 개발하다 보면 조금 전에 수정했던 문제가 또 발생하는 겁니다.

처음에는 그러려니 하고 다시 수정을 요청합니다.

그런데 이런 일이 몇 번씩 반복되다 보면 슬슬 짜증이 나기 시작합니다.

"아니, 아까 이거 수정했는데 왜 또 이러는 거야?"

"방금 고쳤잖아. 왜 똑같은 실수를 반복해?"

AI를 다그치듯 이야기했던 적도 있습니다.

그러면 AI는 다시 문제를 확인하고 수정하겠다고 답합니다.

그런데 생각해 보면 조금 이상합니다.

분명 같은 프로젝트에서 작업하고 있고, 이전에 문제를 해결하기까지 했는데 왜 비슷한 실수가 반복되는 걸까요?

  잘 되던 기능이 자꾸 말썽을 부리자, AI에 대한 불안과 불신이 점점 쌓여가는 나  
  잘 되던 기능이 자꾸 말썽을 부리자, AI에 대한 불안과 불신이 점점 쌓여가는 나  

AI는 이전에 수정한 내용을 기억하지 못하는 걸까?

처음에는 AI가 이전 작업을 당연히 알고 있을 거라고 생각했습니다.

같은 프로젝트에서 계속 작업하고 있고, 조금 전에도 해당 문제를 수정했으니까요.

하지만 AI 코딩 도구가 작업하는 방식은 사람이 프로젝트를 경험하고 기억하는 방식과 차이가 있습니다.

AI는 현재 전달받은 대화와 코드, 프로젝트 파일, 작업 지침 등을 바탕으로 작업을 수행합니다.

문제는 이전에 수정했던 이유와 주의사항이 현재 작업에서 항상 충분히 참고되는 것은 아니라는 점입니다.

대화가 길어지면 오래된 내용이 요약되거나 현재 작업 맥락에서 제외될 수 있습니다. 새로운 세션을 시작했다면 이전 대화가 그대로 전달되지 않을 수도 있습니다.

또 코드에는 이전 수정 결과가 남아 있더라도 왜 그런 코드를 작성했는지에 대한 설명까지 남아 있는 것은 아닙니다.

예를 들어 특정 상황에서 오류가 발생하지 않도록 예외 처리를 추가했다고 가정해 보겠습니다.

이후 새로운 기능을 구현하면서 AI가 관련 코드를 다시 수정할 때, 기존 예외 처리가 왜 필요한지 충분히 파악하지 못하면 그 부분을 변경할 가능성이 있습니다.

코드를 읽을 수 있다는 것과 그 코드가 만들어진 이유를 이해하는 것은 다른 문제인 셈입니다.

사실 처음부터 제대로 해결되지 않았을 수도 있습니다

또 다른 가능성도 있습니다.

애초에 문제가 완전히 해결된 것이 아니었을 수도 있다는 겁니다.

특정 화면에서 오류가 발생했을 때 AI가 해당 화면의 코드만 수정했다고 해보겠습니다.

수정 후에는 정상적으로 동작하니 문제가 해결된 것처럼 보입니다.

그런데 실제 원인이 여러 화면에서 사용하는 공통 함수에 있었다면 어떨까요?

당장은 문제가 사라졌더라도 다른 화면이나 특정 조건에서는 다시 발생할 수 있습니다.

즉, AI가 이전 수정 내용을 잊어버린 것이 아니라 처음부터 근본적인 원인을 해결하지 못했던 것일 수도 있습니다.

또 새로운 기능을 추가하는 과정에서 이전 수정 사항을 다시 변경했을 수도 있습니다.

따라서 같은 문제가 반복된다고 해서 AI가 이전 작업을 기억하지 못했기 때문이라고 단정할 수는 없습니다.

중요한 건 반복되는 오류의 원인을 확인하는 과정입니다.

AI를 다그친다고 해결되는 문제는 아니었습니다

당시에는 같은 문제가 발생할 때마다 AI에게 다시 수정하라고 요청하는 경우가 많았습니다.

이전에 이미 고쳤던 문제라는 사실을 강조하기도 했죠.

그런데 시간이 지나면서 생각이 조금 달라졌습니다.

AI에게 얼마나 강하게 이야기하느냐보다 중요한 것은 같은 문제가 반복되지 않도록 어떤 조치를 해두었느냐였습니다.

예를 들어 단순히 오류를 수정해 달라고 요청하는 대신 이렇게 요청할 수 있습니다.

"이번 오류가 발생한 근본적인 원인을 분석해 줘."

"같은 문제가 다시 발생할 가능성이 있는 부분도 확인해 줘."

"수정한 기능을 검증할 수 있는 테스트를 추가해 줘."

"이번 문제의 원인과 해결 방법을 프로젝트 문서에 기록해 줘."

이렇게 하면 당장의 문제를 해결하는 데서 한 단계 더 나아갈 수 있습니다.

특히 자동화된 테스트는 이후 다른 기능을 수정했을 때 이전 문제가 다시 발생했는지 확인하는 데 도움이 됩니다.

프로젝트에서 반복적으로 지켜야 할 규칙은 사용하는 도구가 지원하는 작업 지침 파일에 기록할 수도 있습니다. 예를 들어 AGENTS.md 같은 파일을 활용하는 방법이 있습니다.

물론 이런 방법으로 모든 실수를 막을 수 있는 것은 아닙니다.

그래도 대화 속에서 몇 번이나 강조했던 주의사항에만 의존하는 것보다는 더 안정적인 방법입니다.

돌이켜 보면 당시에는 AI가 같은 실수를 반복한다고 생각했지만, 저 역시 문제가 해결된 이유를 제대로 확인하지 않고 다음 작업으로 넘어가는 경우가 있었습니다.

AI가 코드를 빠르게 수정해 준다고 해서 그 문제가 완전히 해결되었다는 의미는 아니었던 겁니다.





“아까 고쳤다면서?”를 연신 외치다 결국 AI에게 폭발하고 마는 나
“아까 고쳤다면서?”를 연신 외치다 결국 AI에게 폭발하고 마는 나

코드는 늘어나는데 완성은 왜 멀어질까?

여기까지 개발을 진행했다면 처음에 비해 상당히 많은 코드가 쌓였을 겁니다.

처음에는 몇 개의 화면과 간단한 기능으로 시작했지만, 이제는 여러 기능이 서로 연결되어 있고 관리해야 할 파일도 많아졌을 수 있습니다.

그런데 이상하게도 완성까지 남은 일은 별로 줄어들지 않은 것처럼 느껴집니다.

이유 중 하나는 기능이 추가될수록 구현해야 할 것뿐 아니라 확인하고 관리해야 할 부분도 함께 늘어나기 때문입니다.

예를 들어 이미지 업로드 기능을 추가한다고 해보겠습니다.

화면에 업로드 버튼을 만들고 파일을 선택하도록 구현하는 것만으로는 끝나지 않습니다.

어떤 이미지 형식을 허용할지, 파일 크기는 어디까지 제한할지, 저장 공간은 어떻게 관리할지 결정해야 합니다.

업로드 도중 오류가 발생하면 어떻게 처리할지, 사용자가 이미지를 삭제하면 서버에 저장된 파일도 함께 삭제할지 고민해야 합니다.

여기에 파일 접근 권한, 보안, 저장 비용 같은 문제도 따라올 수 있습니다.

사용자에게는 작은 기능 하나지만 개발하고 운영하는 입장에서는 관리해야 할 항목이 여러 개 늘어나는 셈입니다.

게다가 새로운 기능은 기존 기능과 연결되기도 합니다.

로그인 기능에 문제가 생기면 프로필이나 사용자 설정에도 영향을 줄 수 있고, 데이터 저장 구조를 변경하면 여러 화면을 함께 수정해야 할 수도 있습니다.

기능이 늘어날수록 이런 연결 관계도 복잡해질 수 있습니다.

AI는 새로운 코드를 빠르게 작성해 줄 수 있습니다.

하지만 코드가 작성되었다는 사실만으로 테스트, 보안, 사용자 경험, 운영에 관한 문제가 모두 해결되는 것은 아닙니다.

코드의 양이 늘어나는 속도와 제품의 완성도가 높아지는 속도는 반드시 같지 않습니다.

  코드는 산더미처럼 쌓였는데, 할 일은 오히려 더 늘어나 절망에 빠진 나  
  코드는 산더미처럼 쌓였는데, 할 일은 오히려 더 늘어나 절망에 빠진 나  

기능이 많아질수록 사용하기 좋은 서비스가 될까?

기능이 늘어나면 서비스를 만드는 입장에서는 완성도가 높아진 것처럼 느껴질 수 있습니다.

할 수 있는 일이 많아지고 화면도 풍성해지니까요.

그런데 사용자 입장에서는 조금 다를 수 있습니다.

간단하게 메모를 작성하려고 들어왔는데 화면에 카테고리, 태그, 템플릿, 공유 설정, 보기 방식, 정렬 옵션까지 있다면 어떨까요?

모든 기능을 잘 활용하는 사람에게는 편리할 수도 있습니다.

하지만 빠르게 메모를 작성하고 싶은 사용자에게는 오히려 무엇부터 해야 할지 고민하게 만드는 요소가 될 수도 있습니다.

물론 기능이 많다고 무조건 복잡한 서비스가 되는 것은 아닙니다.

잘 설계된 화면이라면 다양한 기능을 자연스럽게 제공할 수 있습니다.

다만 기능을 추가할 때는 그 기능이 사용자에게 어떤 가치를 주는지, 기존 사용 흐름을 방해하지는 않는지 함께 고민해야 합니다.

처음에는 단순하고 편리한 서비스를 만들려고 했는데 기능을 계속 추가하다 보니 오히려 그 장점이 사라질 수도 있으니까요.


그렇다면 AI에게 어떻게 일을 시키는 게 좋을까?

그렇다고 처음부터 모든 기능을 완벽하게 기획한 뒤 개발해야 한다는 이야기는 아닙니다.

AI와 개발하는 과정에서 새로운 아이디어를 발견하는 것도 큰 장점입니다.

직접 구현해 보면서 더 좋은 방향을 찾을 수도 있고, 처음에는 생각하지 못했던 사용자의 불편함을 발견할 수도 있습니다.

다만 떠오르는 아이디어를 모두 즉시 구현하는 것과, 아이디어를 정리한 뒤 필요한 순서대로 작업하는 것은 차이가 있습니다.

1. 지금 하고 있는 작업부터 마무리하기

새로운 아이디어가 떠오르더라도 현재 진행 중인 작업을 먼저 끝내는 겁니다.

하나의 기능을 구현했다면 정상적으로 동작하는지 확인하고, 필요한 테스트까지 마친 뒤 다음 작업으로 넘어가는 편이 좋습니다.

작업이 계속 바뀌면 무엇을 완료했고 무엇을 확인해야 하는지 놓치기 쉬우니까요.

2. 새로운 아이디어는 일단 기록해 두기

개발하다 보면 갑자기 좋은 아이디어가 떠오를 수 있습니다.

그럴 때마다 바로 구현하기보다는 별도의 목록에 정리해 두는 겁니다.

며칠 뒤 다시 보면 꼭 필요하다고 생각했던 기능이 생각보다 중요하지 않게 느껴질 수도 있습니다.

반대로 시간이 지나도 계속 필요하다면 그때 우선순위를 정해 구현하면 됩니다.

3. 수정하기 전에 영향 범위부터 확인하기

AI에게 곧바로 코드를 수정하도록 요청하기보다는 먼저 어떤 부분에 영향을 주는지 분석하도록 하는 것도 좋습니다.

예를 들어 이렇게 요청할 수 있습니다.

"이 기능을 추가하려면 어떤 파일을 수정해야 하는지 먼저 확인해 줘."

"기존 기능에 영향을 줄 수 있는 부분을 분석해 줘."

"현재 구조를 최대한 유지하면서 구현할 방법을 제안해 줘."

물론 AI가 분석한 결과도 확인이 필요합니다.

하지만 변경 범위를 먼저 파악하는 과정은 무작정 코드를 수정하는 것보다 문제를 줄이는 데 도움이 됩니다.

4. 정상적으로 동작하는 상태를 자주 저장하기

기능을 수정하다 보면 이전 상태로 돌아가고 싶을 때가 있습니다.

Git 같은 버전 관리 도구를 활용해 정상적으로 동작하는 상태를 자주 저장해 두면 좋습니다.

특히 공통 기능이나 데이터 구조처럼 영향 범위가 큰 부분을 수정하기 전에는 현재 상태를 커밋해 두는 편이 안전합니다.

문제가 발생했을 때 어떤 부분이 변경되었는지 비교하기도 수월합니다.

5. 같은 문제가 반복되지 않도록 테스트와 기록을 남기기

오류를 수정했다면 단순히 화면에서 정상적으로 동작하는지만 확인하고 끝내지 않는 것이 좋습니다.

가능하다면 같은 오류를 재현할 수 있는 테스트를 만들어 두고, 이후 변경 작업에서도 해당 테스트를 실행하도록 하는 겁니다.

중요한 설계 결정이나 반복적으로 발생했던 문제는 문서에 남겨두는 것도 도움이 됩니다.

AI가 다음 작업에서도 필요한 맥락을 참고할 수 있도록 하기 위해서입니다.

6. AI에게 기능을 추가하지 말아야 할 이유도 물어보기

이 방법도 한번 활용해 볼 만합니다.

보통은 AI에게 새로운 기능을 추천해 달라고 요청하지만, 반대로 물어보는 겁니다.

"현재 서비스에서 굳이 추가하지 않아도 되는 기능은 무엇일까?"

"이 기능을 추가하면 오히려 복잡해지는 부분은 없을까?"

"지금은 구현하지 않고 나중으로 미뤄도 괜찮을까?"

AI의 답이 반드시 정답은 아니겠지만 기능을 추가하는 방향으로만 생각하던 시야를 넓히는 데 도움이 될 수 있습니다.


만들 수 있다고 모두 만들 필요는 없다

AI 덕분에 개인이 서비스를 만드는 과정은 이전보다 훨씬 수월해졌습니다.

혼자서도 다양한 기능을 시도할 수 있고, 전문 지식이 부족한 영역에서도 AI의 도움을 받아 개발을 시작할 수 있습니다.

이런 변화는 분명 반가운 일입니다.

하지만 만들 수 있는 것이 많아졌다고 해서 모두 만들어야 하는 것은 아닙니다.

기능을 추가하는 것은 비교적 쉬워졌지만, 그 기능이 정말 필요한지 판단하고 안정적으로 관리하는 일은 여전히 중요합니다.

AI에게 일을 시키는 방식도 마찬가지입니다.

생각나는 대로 작업을 요청하는 것은 쉽지만, 그 작업들이 하나의 완성된 제품으로 이어지게 하려면 방향과 우선순위가 필요합니다.

새로운 기능을 만드는 데만 집중하다 보면 정작 기존 기능을 제대로 검증하거나 서비스를 출시하기 위한 준비는 뒤로 밀릴 수도 있습니다.

어쩌면 그래서 코드가 수만 줄까지 늘어났는데도 여전히 완성이 멀게 느껴지는 것인지도 모르겠습니다.

저 역시 AI와 개발하다 보면 새로운 아이디어가 떠오를 때마다 바로 구현해 보고 싶은 마음이 듭니다.

특히 AI가 "구현할 수 있습니다"라고 답하면 더 그렇습니다.

하지만 이제는 그럴 때 한 번쯤 생각해 볼 필요가 있다고 느낍니다.

"이 기능을 만들 수 있는 건 알겠는데, 정말 지금 만들어야 할까?"

서비스의 완성은 모든 아이디어를 구현했을 때 찾아오는 것이 아니라, 핵심 기능이 충분히 동작하고 사용자가 실제로 사용할 수 있는 상태에 도달했을 때 가능해지는 것일 테니까요.

결국 중요한 건 얼마나 많은 코드를 작성했느냐가 아니라, 처음 해결하려고 했던 문제를 얼마나 잘 해결했느냐일 겁니다.

AI로 빠르게 만드는 능력만큼, 무엇을 만들지 않고 남겨둘지 결정하는 능력도 중요해진 것 같습니다.

여러분은 AI로 개발하면서 처음 기획에 없던 기능을 계속 추가한 경험이 있으신가요?

혹은 같은 오류를 여러 번 수정하면서 AI에게 답답함을 느꼈던 적은 없으신가요?

비슷한 경험이 있다면 함께 이야기 나눠봐도 좋겠습니다.

 


제가 운영하는 AI 창작자 커뮤니티 Showdly를 소개합니다. AI로 만든 웹서비스, 앱, 게임, 이미지, 영상, 음악을 소개하고, 만드는 과정과 AI 활용 경험을 나누는 공간이에요.

직접 만든 작품을 올려주셔도 좋고, 아직 작품이 없어도 편하게 구경하고 이야기 나누러 오세요!

Showdly 구경하기 🚀 → https://showdly.com

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

✉️

이번 뉴스레터 어떠셨나요?

쇼들리로그 님에게 ☕️ 커피와 ✉️ 쪽지를 보내보세요!

댓글

의견을 남겨주세요

확인
의견이 있으신가요? 제일 먼저 댓글을 달아보세요 !

다른 뉴스레터

이웃 뉴스레터 Beta

비슷한 이야기를 하는 다른 뉴스레터의 글이에요.

© 2026 쇼들리로그

AI로 직접 만들고 운영하며 겪은 시행착오부터 새로운 AI 도구와 흥미로운 소식까지 함께 나눕니다.

메일리 로고

도움말 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so 채팅으로 문의하기

메일리 사업자 정보

메일리 (대표자: 이한결) | 대표번호: 070-8027-1409 | 사업자번호: 717-47-00705 | 서울특별시 송파구 위례광장로 199, 5층 501-2-31호

이용약관 | 개인정보처리방침 | 정기결제 이용약관 | 라이선스