AI로 개발할 때 '비효율'이란 무엇일까?
AI로 개발할 때 ‘비효율’이란 무엇일까?
AskStock을 만들면서 하나의 실험을 했다.
내가 개입하는 시간을 줄이면 더 빨라질까?
이전 프로덕트 개발에서는 내가 자주 들어갔다.
기획/조사 후에 한 번 더 타당성을 확인하고, 설계를 다시 보고, 구현 중간중간 결과를 확인하고, 필요하면 로직/코드까지 내려가서 판단했다. 그 구간이 늘 느렸다. 흐름이 끊겼다. 그래서 나는 그 시간을 “비효율”이라고 정리해두었다.
AskStock에서는 그 비효율을 줄였다.
아이디어는 내가 잡고, 빌드업과 구현은 최대한 AI 쪽으로 넘겼다. 내가 끊지 않으면 더 매끄럽게 굴러갈 거라고 생각했다.
MVP까지는 성공처럼 보였다.
진척이 빨랐고, 결과물이 쌓였다. “이 방식이 맞네”라는 느낌도 들었다.
그런데 릴리즈 구간에서 일이 달라졌다.
“내가 줄인 시간”은 사라진 게 아니었다
릴리즈 단계에서 자주 반복된 장면들이 있다.
- “고쳤다”라고 해서 확인하면 결과물이 이전과 같거나, 오히려 망가져 있다.
- 조금만 다른 케이스가 들어오면 이상해진다.
- 한 부분을 손보면 다른 부분이 조용히 깨진다.
- 결국 내가 로직과 코딩까지 관여하게 된다.
그리고 여기서 완성도가 갈렸다.
내가 어느 정도 알고 있느냐에 따라, 프로덕트가 상용 수준으로 “수습 가능”해지기도 하고, “계속 흔들리는 상태”로 남기도 했다.
이때 깨달은 건 단순했다.
내가 줄였다고 생각했던 시간은 사라진 게 아니다.
MVP 구간에서 보이지 않게 밀려 있다가, 릴리즈 순간 더 큰 덩어리로 돌아왔다.
그래서 “비효율”이란 단어를 다시 의심하게 됐다
내가 비효율이라고 부르던 시간은 대부분 “확인”에 쓰였다.
그런데 확인이라는 말이 너무 약하다.
릴리즈 구간에서 내가 실제로 하던 일은 대충 이런 것들이었다.
- 이 기능이 “되는 척”이 아니라 “진짜로” 되는지 확인
- 조금만 다른 케이스에서도 같은 품질이 유지되는지 확인
- 문제가 터졌을 때 원인을 잡을 수 있는 구조인지 확인
- 이후 변경에서 다시 망가지지 않게 만들 수 있는지 확인
즉, 그 시간은 단순한 확인이 아니라 판정에 가까웠다.
겉으로는 느리고 답답하지만, 서비스가 성립하려면 필요한 종류의 시간.
AskStock에서 내가 줄인 건 “시간”이라기보다 그 시간이 등장하는 타이밍이었다.
내 실험은 성공했고, 질문이 남았다
“내 개입 시간을 줄이면 더 빨라질까?”
MVP까지는 분명히 그렇다.
하지만 릴리즈 단계에서 질문이 바뀌었다.
빨라진 결과물을 서비스로 성립시키는 데 필요한 시간은 무엇인가?
내가 비효율이라고 부르던 시간은 정말 비효율이었나?
아니면, 릴리즈 순간 반드시 치러야 하는 필요 비용이었나?
결론: 요즘은 ‘비효율 제거’보다 ‘옥석 가리기’에 가깝다
예전에는 “비효율을 없애야 한다”는 생각이 먼저였다.
그런데 지금은 조금 다르다.
비효율처럼 보이는 시간 안에는,
- 진짜로 줄여야 하는 낭비도 있고
- 느리지만 반드시 필요한 시간도 섞여 있다.
그래서 나는 이제 “비효율”이라는 단어를 쉽게 쓰지 않으려 한다.
비효율을 없애는 게 아니라, 무엇이 비효율인지 옥석을 가리는 중이기 때문이다.