대 AI 시대, 1인 개발자에게 정말 필요한 것

요즘 세상이 참 좋아졌다. 프롬프트 한 줄이면 코드가 나오고, 한 줄 더 치면 리팩토링까지 해준다.
이른바 '딸깍' 시대. 누군가는 이제 개발자가 필요 없다고 하고, 또 누군가는 AI만 있으면 혼자서 뭐든 만들 수 있다고 한다.

나도 그렇게 믿었다. 한동안은.

'딸깍'의 환상

최근에 프로젝트를 하나 진행하면서 기획을 GPT에게 맡겨본 적이 있다.
러프하게 "이런 기능이 있어야 할 것 같아"라고 던졌더니, 전체적인 프로젝트 컨텍스트를 알고 있던 녀석이 세부 기획을 주루룩 토해냈다.
항목별로 깔끔하게 정리된 기획 문서. 주어진 문서를 훑어봤을 때 이미 그것만으로 충분해 보였다.

그런데 정작 개발에 들어가니 이야기가 달라졌다.

엣지케이스가 끊임없이 튀어나왔다.
기획에서 결정하지 않은 수 많은 것들이 코드를 짜는 순간 결정을 요구했다.

"이 상태에서 사용자가 뒤로 가기를 누르면?"
"이 데이터가 null이면 어떤 화면을 보여주지?"
"이 두 기능이 동시에 호출되면?"

기획 문서에는 없던 질문들이 쏟아졌다.

아무리 애자일 애자일 하더라도 이건 빈틈이 너무 많았다.
그리고 그 빈틈을 누덕누덕 메꾸다 보니 메운 것들끼리 또 충돌이 났다. UX 플로우를 다시 짜야 했고, DB 스키마와 비즈니스 로직이 서로 물어뜯었다.
PR 하나가 100개의 파일 체인지, 40여 개의 커밋이 쌓인 괴물이 되었다.
누가 봐도 형태를 알아볼 수 없는.

결국 해당 태스크는 기획을 재정의하고 기능을 쪼개서 재배포하는 것으로 마무리했다.
해결은 했지만, 생각보다 '딸깍'과는 거리가 먼 경험이었다.

신은 비결정적이다

이 경험을 하고 나서, "AI는 신이야!"라고 외치던 신자의 마음은 잠시 내려두었다.
그리고 이 거대한 기계장치로 된 신을 제대로 굴리려면 내게 무엇이 필요한지를 생각해봤다.

핵심은 바로 "AI는 비결정적이다"는 것이다.

같은 프롬프트를 줘도 매번 다른 결과가 나온다.
이건 창의적인 글쓰기에서는 장점이 될 수 있지만, 개발에서는 무서운 가정이다.
기획에 구멍이 있으면 AI는 그 구멍을 추론으로 메운다.
문제는 그 추론이 매번 달라진다는 것이다.
오늘은 A 방향으로 메우고, 내일은 B 방향으로 메운다.
기획의 빈자리를 내가 모르는 블랙박스가 매번 다른 방식으로 채우고 있는 셈이다.

이렇게 되면 같은 기획으로 만든 제품인데 부분마다 전제가 다른 기괴한 결과물이 탄생한다.
내가 겪은 것이 정확히 이것이었다.
기획이 결정하지 않은 부분을 AI가 각자의 맥락에서 알아서 해석했고, 그 해석들이 모이니 서로 물어뜯었던 것이다.

또한 기획이 약하면 테스트도 만들 수 없다.
기대하는 동작이 정의되지 않았는데 뭘 검증하겠는가.
테스트가 없으면 결국 사람이 직접 QA를 해야 한다.
AI가 만든 코드를 사람이 한 줄씩 눈으로 검증한다? 그거야말로 딸깍 시대를 역행하는 일이다.

What에서 How로, How에서 Why로

그런데 이 경험을 곱씹으면서 한 가지 흥미로운 변화를 느끼고 있다.

예전의 AI는 철저히 What의 영역에 있었다.
"이거 만들어줘." 그러면 만들어준다.
그게 전부였다. 입력과 출력. 시키면 하는 기계.

그런데 요즘의 AI는 다르다.
"이걸 어떤 방식으로 처리할까요?"라고 먼저 묻는다. How의 영역으로 올라온 것이다.
더 나아가, planning 문서를 참조하고, 나와의 대화 맥락을 기억하면서 "이 기능이 왜 필요한 건지"까지 이해하려 한다.
Why에 접근하고 있는 셈이다.

예전에 사이먼 시넥의 "스타트 위드 와이"를 읽으며 골든서클이라는 개념을 접한 적이 있다.
WHY → HOW → WHAT. 안에서 바깥으로.
대부분의 조직은 이 순서를 뒤집어서 실패한다는 이야기였다.
이는 AI와의 협업에도 똑같이 적용되는 구조였다.

AI가 What만 처리하던 Tool의 시절에는 사람이 기획을 대충 해도 어차피 실행만 시키면 됐다.
하지만 AI가 Agent의 역할을 하며 How를 묻고 Why를 참조하기 시작하면서, 역설적으로 사람의 Why가 더 선명해져야 하는 시대가 됐다.

왜냐하면, AI가 Why를 "묻는" 것과 AI가 Why를 "아는" 것은 완전히 다른 문제이기 때문이다.
AI가 아무리 맥락을 파악하려 해도 그 맥락 자체가 모호하면 결국 추론으로 채운다.
그리고 그 추론은 비결정적이다. 내가 겪었던 바로 그 문제로 돌아온다.

AI가 "왜 이 기능이 필요해요?"라고 물어왔을 때, 내가 명확하게 답할 수 있느냐.
이게 딸깍의 진짜 전제조건이었다.

1인 Product Owner의 시대

그래서 나는 이제 '1인 개발자'라는 말보다 '1인 Product Owner'라는 표현이 더 맞다고 생각한다.

코드를 치는 행위 자체는 점점 AI가 대신해주고 있다.
AI가 How를 묻고, Why를 참조하는 시대가 왔다.
하지만 그 Why를 정의하는 것, 엣지케이스에서 어떤 방향을 택할지 판단하는 것, 그 결정들이 서로 모순되지 않는지 확인하는 것.
이건 여전히 사람의 몫이다. 아니, AI가 똑똑해질수록 오히려 더 중요해진다.

AI에게 큰 그림만 던지고 "알아서 해줘"가 아니라, 같이 앉아서 디테일을 파고들어야 한다.

"여기서 사용자가 이탈하면 어떻게 되지?"
"이 상태값이 꼬이면?"
"이 API가 실패하면 프론트는 뭘 보여주지?" 이런 질문들을 내가 먼저 던지고, AI와 함께 답을 만들어가는 과정.
그래야 단단한 기획이 나오고, 그 기획 위에서 테스트가 만들어지고, AI가 짠 코드를 검증하는 사이클이 돌아간다.

AI를 감시해야 한다는 게 아니다.
AI와 함께 빈틈을 찾아내야 한다는 것이다.
다만, 그 과정의 주도권은 반드시 내가 쥐고 있어야 한다.
왜냐하면 이 제품이 어떤 모습이어야 하는지를, 즉 Why를 결정하는 건 결국 나니까.

---

딸깍 시대는 분명 왔다.
AI는 정말 대단하고, 혼자서 할 수 있는 일의 범위는 비교할 수 없이 넓어졌다.
하지만 딸깍의 전제조건은 생각보다 까다롭다.
AI가 What을 넘어 How와 Why의 영역으로 올라온 지금, 아이러니하게도 사람에게 남는 가장 중요한 능력은 코딩이 아니라, 자기 자신의 Why를 선명하게 정의하는 힘이다.

결국 딸깍의 품질은, 딸깍 이전에 결정된다.