더이상 사람이 코딩하지 않는 시대, 개발자는 무엇을 해야 할까?

이 글은 GDC 강연과 loop클럽에서 진행했던 강연 내용을 바탕으로 작성하였습니다. 소중한 기회를 주셔서 감사합니다.

프롤로그

불과 작년만 하더라도, 강연에서는 주로 이런 이야기를 했습니다. “아직은 사람이 코딩을 해야 한다.” “AI가 코드를 잘 짜는 것처럼 보여도, 환각을 하고 실수를 하기에 결국에는 사람이 봐야 한다.” “LLM은 실수를 하고, 환각도 있고, 위험하기 때문에 오히려 개발자의 역할이 더 중요해질 것이다.” 그때는 꽤나 자신 있게 그렇게 말했습니다. AI가 좋아지고 있는 건 맞지만, 그래도 마지막에는 사람이 봐야 하고, 판단해야 하고, 책임져야 한다고 생각했습니다.

그런데 올해 세상이 바뀌어버렸습니다. AI의 성능이 임계치를 넘겨버리면서 이제는 정말로 사람이 직접 코딩하지 않아도 되는 시대가 와버렸습니다. 처음에는 그 변화가 일순간 쇼크처럼 왔습니다. “어, 이게 진짜 되네?” 싶은 순간들이 계속 생겼습니다. 그런데 사람은 또 적응의 동물이라, 이내 곧 그 쇼크에 적응하고 나니 너무 재밌는 시기가 되었습니다.

누군가 그런 얘기를 하더라고요. 바이브 코딩은 가챠와 같다. 그 말을 듣고 웃었는데, 막상 해보면 정말 그렇습니다. 돌리면 뭔가 나옵니다. 마음에 안 들면 다시 돌립니다. 그러다 가끔 대박이 나옵니다. 그러다보면 도파민이 팡팡 터집니다. 개발자란 직업은 참 멋진 직업입니다. 이제는 합법적으로 24시간 유사도박을 할 수 있는 직업이 되었으니까요.

AI를 시켜보면 뭔가 되고, 또 뭔가 되고, 내가 반복하던 일을 얘가 대신 해주기 시작하니까 너무 신났습니다. 그러던 시기에 감사하게도 강연 제안을 받게 되었습니다. AI 시대와 개발자. 저는 자연스럽게 다음과 같은 주제를 떠올렸습니다. 더이상 사람이 코딩하지 않는 시대, 개발자는 무엇을 해야 할까?

처음 이 강연을 준비할 때만 해도, 저는 나름 답을 갖고 있다고 생각했습니다. 바이브 코딩을 하면서 “이제는 정말 된다”는 것을 느끼고 있었고, 시행착오를 겪어가며 스킬을 작성하고 에이전트를 만들면서 전과 확연히 달라진 개발 문화와 생산성을 체감하고 있었습니다. 코딩이 아닌 영역에서 더 잘하는 방법은 여전히 존재하고, 오히려 AI를 더 잘 쓰기 위해서는 개발 지식이 더 필요하다는 것도 느꼈습니다. 그래서 강연에서는 이런 이야기를 하려고 했습니다.

“여러분, AI 시대에는 하네스 엔지니어링을 이렇게 해야 합니다.”
“제가 현업에서 해보니까 AI로 이런 게 되더라고요.”
“이렇게 하면 개발 생산성이 올라가고, 이런 식으로 스킬을 만들면 됩니다.”

그런데 강연을 준비하는 동안 그 마음이 계속 흔들렸습니다. 팁과 인사이트를 정리하고 알려주는 속도보다 상황이 바뀌는 속도가 더 빨랐습니다. 새로운 변화를 따라가다 보니 제가 발표하려던 내용은 금세 낡은 것이 되어버렸고, 저는 매일같이 장표를 고치고 또 고치고 있었습니다. 그러다 문득 이런 생각이 들었습니다.

내가 지금 뭘 더 안다고 알려줄 수 있지?

게임으로 치면 대규모 업데이트가 온 느낌이었습니다. 단순히 밸런스 패치가 조금 된 정도가 아니라, 게임의 룰 자체가 바뀌어버린 업데이트에 가까웠습니다. 지난 시즌에 잘 통하던 공략이 이번 시즌에도 그대로 통할지 알 수 없고, 익숙했던 메타와 빌드가 더 이상 정답이 아닐 수 있는 상태가 된 겁니다. 거의 하드 리셋에 가까웠습니다. 기존 시즌에서 쌓아두었던 레벨과 장비가 완전히 사라진 것은 아니지만, 적어도 그것만 믿고 플레이하기는 어려워졌습니다. 경험은 남아 있지만, 그 경험을 어떻게 다시 써야 하는지는 새로 배워야 했습니다.

지금 개발자에게 AI가 딱 그런 느낌이었습니다. 분명 어제까지는 제가 알고 있던 개발자의 기준이 있었는데, 어느 순간 그 기준이 잘 안 먹히는 새 시즌이 시작되어버렸습니다.

분명 시작의 질문은 “사람이 코딩하지 않는 시대, 개발자는 무엇을 해야 할까?”였고, 처음에는 프론트엔드의 하네스 엔지니어링에 대한 이야기를 준비했지만, 시대를 따라잡아가며 장표는 계속 변했고, 그렇게 변하고 변한 이야기의 흐름은 제가 처음 준비했던 답과는 조금 다른 곳에 도착하게 됐습니다.

이 글은 “이렇게 하면 됩니다”를 알려주는 글이라기보다는, 새 시즌에 같이 던져진 사람이 먼저 조금 굴러본 기록에 가깝습니다. 어디서 신났고, 어디서 당황했고, 어디서 현타가 왔고, 어디서 생각이 바뀌었는지를 남겨보려 합니다. 누군가에게는 먼저 넘어져본 사람의 이야기일 수도 있고, 이미 같은 변화를 겪고 있는 사람에게는 공감의 이야기일 수도 있고, 또 누군가에게는 비슷한 시행착오를 줄이는 데 도움이 되는 기록이 되기를 바랍니다.

---

2026년 1월, 특이점이 왔다

2026년 1월, 특이점이 왔습니다. 이렇게 빨리 올 줄은 몰랐는데 와버렸습니다. 이전에도 AI가 코드를 잘 짜는 것처럼 보이는 순간은 있었지만 그때까지는 어디까지나 사람이 옆에서 붙잡고 있는 형태였습니다. 물어보고 이상하면 멈추고, 방향을 다시 잡고, 잘못된 코드는 확인 후 걷어내는 방식. AI가 코드를 쓰긴 하지만, 결국 사람이 계속 브레이크를 잡고 있어야 하는 도구에 가까웠습니다.

그런데 AI의 성능이 올해부터 비약적으로 달라졌습니다. 이때부터는 완전히 체감되는 감각이 달랐습니다. 단순히 코드 조각을 잘 만들어주는 정도가 아니라 이슈를 읽고, 관련 파일을 찾고, 수정하고, 테스트를 통과시키는 흐름까지 매끄럽게 문제가 없이 돌아가기 시작했습니다.

“어, 정말로 바이브 코딩이 되는데?”

그 체감을 숫자로 보여주는 지표 중 하나가 SWE Bench 입니다. GitHub issue 기반의 software engineering task를 평가하는 대표 벤치마크입니다. 실제 저장소의 이슈가 주어졌을 때, AI가 그 문제를 해결하는 코드를 만들어낼 수 있는지를 측정하는 방식입니다.

예전에는 상위 모델도 50%를 넘지 못하던 시기가 있었습니다. 그말인즉슨 AI가 하면 할 수록 실패한다는 의미이기에 성공보다 실패가 더 많다면 오래 굴릴수록 위험해집니다. 그래서 옆에서 보다가 아니다 싶으면 빨리 멈출 수 있게 ESC를 잘 누르는 능력이 실력이었습니다. AI가 뭔가를 잘하는 것처럼 보여도, 실패할 가능성을 항상 먼저 생각해야 했습니다.

그런데 이제는 상위 모델이 70% 후반, 조건에 따라 80% 안팎까지 올라오기 시작했습니다. SWE Bench 공식 리더보드 기준으로 Claude 4.5 Opus high reasoning은 76.8%를 기록했고, Anthropic은 Claude Opus 4.6 발표에서 프롬프트 수정 시 SWE-bench Verified 81.42%를 봤다고 설명했습니다. 지금의 GPT5.5와 Opus는 4.8는 훨씬 더 높은 수준의 모델이며 새로운 모델인 Fable도 잠깐이지만 경험했습니다.

당시 출시된 Opus 4.5의 성공확률이 76.8%. 처음 시도가 만일 실패했다면? 그러면 이제는 한번 더 시키면 그만입니다. 두 번 시켰을 때 한 번 이상 성공할 확률은 94.6%입니다. 물론 실제 작업이 완전히 독립 시행처럼 돌아가지는 않겠지만, 이 숫자가 주는 감각은 분명했습니다. 그리고 이제는 문법적으로 오류가 있는 동작을 할거라는 걱정을 하지 않게 되었습니다.

이때 1차 쇼크가 왔습니다. 이제는 AI에게 코드를 시킬 때 “어차피 안 될 수도 있으니 사람이 옆에서 붙잡고 있어야 한다”는 전제가 아니라, “내 의도와 다를지언정 어떻게든 일단 동작하는 코드가 나올 것이다”라는 신뢰가 생기고 나니 완전히 다른 경험으로 코딩을 할 수가 있게 되었습니다. 코드가 동작할지 의심하면서 옆에서 감시하며 AI를 쓰는 것과 AI가 동작할 거라고 믿고 일을 맡긴 뒤 결과를 확인하는 것은 완전히 다른 개발 경험이었습니다.

저는 이때 처음으로, 정말로 사람이 말로 코딩하는 시대가 왔다고 느꼈습니다. 그리고 그 느낌은 점점 확신이 되었습니다. 이제는 정말로 단 한줄의 코드를 직접 타이핑하지 않고 개발을 하고 있고 현업 수준의 개발도 그렇게 하고 있습니다. 우리는 이제 새로운 패러다임에서 개발을 하게 되었습니다.

그런데 항상 성공하는 건 아니더라

AI가 될 거라는 전제로 굴러가기 시작하니까, 에러를 대하는 태도가 달라졌습니다. 예전에는 에러가 나면 제가 읽고, 원인을 찾고, 코드를 뒤지고, 어디서 잘못됐는지 파악하는 수순을 밟게되죠. 그러나 지금은 에러 메시지를 발견했다? 그러면 그냥 복사해서 일단 AI에게 던지면 됩니다. 그러면 AI가 다시 고칩니다. 예전에도 이렇게 했지만 AI의 성능이 떨어졌을때에는 내가 분석을 하기 위한 초벌 단계였다면, 지금은 알아서 해결을 바라고 하는 행위가 되었습니다.

물론 항상 다 성공하는 건 아닙니다. 확률이 그렇게 높아도 실패할 때는 실패합니다. 그런데 이제는 그 실패조차 별문제가 되지 않습니다. 에러가 또나면? 또 다시 던지면 됩니다. 이제 해결될 확률은 무지 높으니까요. 브라우저의 에러를 보면 지체없이 CTRL+C, CTRL+V를 합니다. AI가 “수정했습니다”라고 합니다. 다시 확인합니다. 또 에러가 나면? 또 CTRL+C, CTRL+V를 합니다.

캬, 세상 좋아졌다. 이제 에러를 만나도 내가 할 일은 복사해서 붙여넣는 것뿐이구나

근데 간혹 그럴때가 있습니다. 이게 한 번 안 되기 시작하면, 왠지 모르겠지만 갑자기 계속 안 되는 경우, 특히나 AI가 “다했습니다. 브라우저에서 한번 테스트해보세요.” 라고 해서 열었는데 여전히 안되는 경우에는 솔직히 너무 화가 납니다. 그래도 에러를 복사해서 붙여넣습니다. AI가 말합니다. “앗, 제가 실수했네요. 수정했습니다. 다시 확인해보세요.” 다시 확인합니다. 또 안 됩니다. 다시 복사해서 붙여넣습니다. AI가 또 말합니다. “이번에는 정말 수정했습니다.” 다시 확인합니다. ...

사람은 적응의 동물이라고 복붙만해서 해결이 되는 감사함은 이미 사라졌고 이렇게 몇 번 반복되니 슬슬 열이 받았습니다. "아니, 안 된다고. 아니, 이게 좀 잘하면 안 되나. 방금 고쳤다며. 아까도 다 했다며!!" 저는 어느 순간 브라우저와 AI 사이에서 에러 메시지를 배달하는 사람이 되어 있었습니다. "아니, 안 된다고. 아니, 이게 좀 잘하면 안 되나." 그래서 결국 한마디 하게 됐습니다.

“아, 답답하네. 네가 좀 알아서 에러가 안날때 까지 테스트를 하면 안 돼? 실제로 좀 눈으로 확인하고 대답해.”

그러자 AI가 말했습니다.

“됩니다.”

그래, 내가 그렇게 시킨 적이 없었지

응? 된다고? 그냥 짜증나서 던진 말이었는데 된다고 합니다. Playwright를 설치하면 브라우저를 직접 열고, 에러를 확인하고, 테스트를 돌릴 수 있다고 합니다. 그러더니 갑자기 Playwright를 설치하고, 브라우저를 켜고, 직접 확인을 하더니 말합니다.

“아, 여기가 문제였네요. 수정했습니다. 지금은 잘 될 거예요. 확인해보세요.”

그리고 진짜로 고쳐졌습니다. 제가 그동안 브라우저에서 에러를 보고, 복사하고, AI에게 붙여넣고, 다시 확인하고, 또 복사하고, 또 붙여넣던 일을 이제는 자기가 스스로 몇 번 반복하더니 해결해버린 겁니다. 저는 그걸 보고 기뻤다기보다는 조금 멍해졌습니다. '어? 되는 거였어? 나는 그동안 왜 옆에서 에러 메시지를 복붙해주고 있었던거지? 그냥 시키면 되는걸?' 이때 두 번째 쇼크가 왔습니다.

생각해보면 제가 Playwright를 몰랐던 게 아닙니다. E2E 테스트를 몰랐던 것도 아닙니다. 브라우저에서 테스트를 자동화할 수 있다는 것도 알고 있었습니다. 그런데 AI에게 브라우저를 직접 보게 하고, 에러를 확인하게 하고, 다시 고치게 할 생각을 안 해봤습니다. 분명 알고 있던 기술인데, 그 기술을 AI에게 맡길 수 있다는 생각으로 연결하지 못했던 겁니다. 그래서 물어봤습니다.

“근데 왜 처음부터 그렇게 안 했어?”

AI가 말했습니다.

“사용자님이 그렇게 시킨 적은 없었습니다.”

아.. 그치.. 뭐 맞는 말이었습니다. 만약 사람이 이렇게 말했으면 꽤 열받았을 것 같은데, AI가 말하니까 할 말이 없었습니다. 그래, 내가 그렇게 시킨 적이 없었지. 그렇게 해달라는 생각도 안 해봤지. 저는 AI가 못한다고 생각하고 있었는데, 사실은 제가 안 시킨 거였습니다.

그때부터 조금 무서워졌습니다. 표현이 이상한데... AI가 무서웠다기보다는, 제가 생각하지 못한 것들이 너무 많다는 사실이 무서웠습니다. 내가 직접 하고 있는 일들 중에 사실은 AI에게 시킬 수 있는 일이 얼마나 많았을까. 내가 당연하게 받아들이고 있는 불편함 중에, 사실은 그냥 물어보거나 시키면 되는 것이 얼마나 많았을까. 내가 AI의 한계라고 생각했던 것 중에, 사실은 내 상상력의 한계였던 것이 얼마나 많았을까.

그 전까지 저는 AI를 잘 쓰고 있다고 생각했습니다. GPT에게 물어보고, 답을 받고, 코드를 복사해서 붙이고, Cursor나 Claude Code에게 “이거 고쳐줘”라고 시키고, 결과가 나오면 제가 확인하고 다시 시키는 방식이었습니다. 그리고 빠르게 문제 해결을 했죠. 저는 분명 AI를 잘 쓰고 있었다 생각했습니다. 그런데 지금와서 보면 AI를 아주 좁게만 쓰고 있었습니다. 결국 제가 하던 일의 일부를 도와주는 도구로만 활용하고 있었던거죠.

이때 이후로 질문이 바뀌었습니다. “내가 이걸 할 수 있을까?”가 아니라 “어떻게 하면 얘한테 하게 만들 수 있을까?”가 되었습니다. 브라우저 에러를 사람이 복사해서 붙여넣는 게 귀찮으면, 브라우저를 직접 보게 하면 됩니다. 개발이 끝난 다음 매번 테스트를 돌리는 게 귀찮으면, 개발이 끝나면 테스트까지 돌리게 하면 됩니다. 매번 같은 방식으로 확인하는 게 귀찮으면, 그 확인 방식을 하나의 절차로 만들면 됩니다.

그렇지만 절대 AI가 알아서 먼저 해주는 법은 없습니다. 근데 또 물어보면 대부분 “됩니다”라고 합니다. 그런데 먼저 하지는 않습니다. 참 열받는 지점입니다. 할 수 있는데, 시키기 전까지는 안 합니다. “이거 브라우저에서 확인할 수 있어?”라고 물으면 “됩니다”라고 합니다. “그럼 앞으로 개발 끝나면 브라우저에서 확인하면 되지 않아?”라고 물으면 또 “됩니다”라고 합니다. “그럼 그걸 매번 하게 만들 수 있어?”라고 물으면 또 “됩니다”라고 합니다.

분명 AI는 가능한 일이었는데, 저는 그 가능성을 생각지도 않은 채 그냥 내가 할 수 있는 북붙만 하고 있었습니다. 복붙만이 아니라 AI는 더 할 수 있는게 많은데 저는 시키지 않았습니다. 더 정확히는, 시킬 수 있다는 생각 자체를 못 했었습니다.

이 순간이 저에게는 AI Tool에서 AI Native로 감각이 바뀐 순간이었습니다. AI의 도움을 받아서 내가 할 생각을 하는 게 아니라, 내가 하던 절차 모두를 AI가 하게 만들 수 있겠다는 감각. 내가 직접 하던 일을 조금 편하게 만드는 것이 아니라, 나 대신 일을 다하게 만들 수 있겠다. 일의 단위를 다시 나눠볼 수 있게 된 겁니다.

그래서 그때부터 뭔가를 할 때마다 한 번씩 물어보기 시작했습니다. 이렇게 이거해가 아니라 "어떻게 하면 이걸 할 수 있는데? 이것도 네가 할 수 있어? 이것도 자동화할 수 있어? 이것도 매번 기억하게 할 수 있어? 이것도 하나의 절차로 만들 수 있어?" 그러면 대부분 이렇게 답했습니다. “할 수 있습니다. 어쩌고 저쩌고...”

이 경험이 쌓이고 나니 정말로 나 대신 일을 할 수 있겠다라는 생각이 들었습니다. 내가 매번 하는 일들을 전부 시켜볼 수 있지 않을까. 내가 개발할 때 생각하는 방식도 얘한테 알려줄 수 있지 않을까. 내가 리뷰할 때 보는 기준도 넣을 수 있지 않을까. 물론 스스로 하진 않을테니 내가 하는 법을 한번은 전부다 일일히 다 알려줘야겠지만 그렇게 되면 그 이후로는 알아서 하지 않을까?

나를 클로닝해보기, 암묵지의 명세화

AI에게 일을 하나씩 시키는 것이 아니라, 아예 내가 일하는 방식을 통째로 넘기기 프로젝트 가동. 그때 한창 유행하던 말이 있었습니다. 암묵지를 명세화해야 한다는 말. 그래서 내가 평소에 어떻게 코딩하는지, 이슈를 받으면 어떤 순서로 확인하는지, 코드를 보기 전에 어떤 문서를 남기는지, 개발이 끝나면 어떤 테스트를 돌리는지, 리뷰할 때 무엇을 보는지. 그런 것들을 하나하나 문서로 프롬프트로 만들기 시작했습니다.

처음에는 직접 커맨드를 만들었습니다. 그런데 커맨드를 입력한다는 것은 생각보다 훨씬 힘들었습니다. 내가 뭘 어떻게 하는지 하나하나 다 작성해야 했으니까요. 그냥 습관적으로 하던 일을 말로 풀어야 하는데, 그게 좀 처럼 잘 되지 않았습니다. 저는 분명 매일 일을 하고 있고, 나름의 방식으로 판단하고 있다고 생각했는데, 막상 그걸 AI가 따라 할 수 있을 정도로 쓰려고 하니 잘 안 됐습니다. 내가 이슈를 볼 때 무엇을 먼저 보는지, 코드를 고칠 때 왜 이 파일을 먼저 여는지, 리뷰할 때 어떤 지점을 보고 “이건 좀 위험한데”라고 느끼는지, 그런 것들이 전부 제 안에서는 당연한데 밖으로 꺼내려니 생각보다 흐릿했습니다.

그래서 또 생각했습니다. 커맨드를 만드는 커맨드를 만들면 되지 않을까. 내가 대충 말해도 작성해주고 모르면 하나씩 질문하면 나는 대답만 해주면 알아서 작성하는 형태였습니다. 이때도 저는 나름대로 되게 뿌듯했습니다.

'와, 멋진데. 나 이제는 메타 사고를 하고 있네. 커맨드를 만드는 커맨드라니.'

그렇게 /create-command를 만들고, 그때부터 필요한 것들을 하나씩 찍어내기 시작했습니다. /plan, /prd, /tdd, /refactor, /retrospect, /inbox, /para, /research, /fix, /debug, /issue, /pr 같은 것들이 생겼습니다. 계획을 세우는 커맨드, 문서를 작성하는 커맨드, 이슈를 확인하는 커맨드, 개발 전에 요구사항을 정리하는 커맨드, 개발이 끝나면 테스트를 돌리는 커맨드, 실패하면 원인을 정리하는 커맨드. 필요할 때마다 딸깍딸깍 누르면 되었습니다.

처음에는 이게 정말 신세계처럼 느껴졌습니다. 매번 같은 설명을 반복하지 않아도 됩니다. “이슈 먼저 확인하고, 관련 문서 보고, 계획 세우고, 작업 전에 요구사항 정리하고, 테스트까지 챙겨줘” 같은 말을 매번 길게 하지 않아도 됩니다. 한 번 절차를 만들어두면 다시 꺼내 쓸 수 있습니다. 내가 매번 손으로 하던 반복이 하나씩 절차가 되고, 그 절차가 커맨드가 되고, 커맨드가 쌓이니까 정말 내가 일하는 방식이 조금씩 AI 안으로 들어가는 것 같았습니다.

물론 그렇게 쉽게만 되지는 않았습니다. AI에게 “이거 어떻게 생각해?”라고 물어보면, 얘가 갑자기 “이건 좋지 않은 방법이네요. ... 수정하겠습니다.” 하면서 후루루룩 코드를 짜기 시작합니다. 저는 그냥 생각을 물어본 건데, 얘는 코드를 짜고 싶어서 안달이 나 있습니다. 그럴 때마다 화가 났습니다.

아니, 그렇게 하는 게 아니라고. 그냥 모르면 좀 물어봐라. 제발 내가 원하는 게 뭔지 다 듣기 전까지는 코딩하지 마. 내가 개떡같이 말해도 네가 먼저 내가 뭘 원하는지 맞춰봐. 못 맞추면 질문해. 내가 맞다고 하기 전까지는 시작하지 마.

그래서 /discuss 같은 커맨드도 만들었습니다. 바로 코딩하지 말고, 먼저 내가 원하는 걸 맞춰봐. 모르면 계속 물어봐. 그러면 조금 나아졌습니다. 이제 AI가 바로 코딩하지 않고, 먼저 질문하고, 제가 원하는 것을 추측하고, 제가 맞다고 하면 그때부터 코딩을 시작합니다. 이것도 또 하나의 스킬이 됩니다. 단순히 코드를 짜게 하는 것이 아니라, 언제 멈추고, 언제 묻고, 언제 실행해야 하는지를 정하는 것도 스킬이었습니다. AI가 제대로된 행동을 하기전 내 의도를 정확하게 정렬하는 것이 너무 너무 중요하다는 것을 알게 되었습니다.

그렇게 의도를 맞추고 나니, 그다음부터는 커맨드를 연결하는 흐름이 보이기 시작했습니다. 먼저 /discuss로 의도를 맞춥니다. 그다음 /plan으로 계획을 세웁니다. 필요하면 /prd로 요구사항을 문서화합니다. 구현할 때는 /red, /green, /refactor 같은 식으로 테스트와 리팩터링을 엮어봅니다. 마지막에는 /verify로 확인하고, /deploy로 배포하고, /next-task로 다음 일을 고르게 합니다. 처음에는 하나씩 편해지려고 만든 커맨드였는데, 어느 순간 개발 전체 흐름을 작은 공장처럼 굴리는 느낌이 되었습니다.

그러다 보니 이제는 상황에 맞는 다음 커맨드를 매번 골라야 하는 것도 귀찮아졌습니다. 지금은 /plan을 써야 하나, /prd를 써야 하나, /debug를 써야 하나. 이런 걸 매번 제가 판단하는 것도 일입니다. 예전 같았으면 “이런 건 알아서 못하나?” 하고 말았을 텐데, 이제는 질문이 바뀌어 있었습니다. “어떻게 하면 되는데?” 그래서 /go 같은 커맨드를 만들었습니다. 지금 상태를 보고, 다음에 무엇을 해야 할지 판단하고, 필요한 커맨드를 알아서 이어서 실행하게 하는 방식이었습니다.

물론 마음에 들 때도 있고, 마음에 들지 않을 때도 있었습니다. 잘 굴러갈 때는 진짜 공장처럼 돌아갑니다. 계획하고, 만들고, 테스트하고, 고치고, 다시 확인합니다. 그런데 마음에 안 들 때는 또 이상한 방향으로 갑니다. 그러면 ESC를 연타하고 잡도리 타임을 가집니다. “너 지금 뭐 잘못했는지 알아?” “방금 네가 한 거 한 번 읊어봐.” “그중에서 뭐가 문제였어?” 그러면 AI가 반성문을 씁니다. 그 반성문을 보면서 제가 다시 말합니다. 아니, 그건 잘못한 게 아니고, 이게 진짜 문제고, 다음부터는 이렇게 해야 해. 그렇게 /retrospect도 만들었습니다. 회고해. 반성하고 다음부터 안 그래야 할 것을 정리해.

실패한 작업을 그냥 버리는 게 아니라, 어떤 판단이 틀렸는지, 어떤 절차가 빠졌는지, 다음에는 어떤 기준을 추가해야 하는지를 남기게 했습니다. 이렇게 하다 보니 AI에게 일을 시킨다는 게 단순히 “이 코드 짜줘”가 아니게 되었습니다. 의도를 맞추고, 계획하고, 실행하고, 검증하고, 실패하면 회고하고, 다시 절차에 반영하는 흐름을 만드는 일이 되었습니다.

그리고 실제로 효과가 있었습니다. 매번 같은 설명을 반복하지 않아도 됐고, 제가 놓치던 확인 절차를 AI가 대신 챙기기 시작했습니다. 바로 코딩하지 말고 먼저 의도를 맞추게 하고, 개발이 끝나면 테스트를 돌리게 하고, 실패하면 회고하게 하니, 정말 개발 방식이 바뀌는 것처럼 느껴졌습니다. 이전에는 제가 계속 옆에서 지시하고 확인하고 복사해주고 붙여넣어주던 느낌이었다면, 이제는 일정한 절차 안에서 AI가 스스로 움직이게 만드는 느낌에 가까워졌습니다.

그래서 저는 이걸 강연의 핵심으로 삼으려고 했습니다. AI 시대에는 단순히 프롬프트를 잘 쓰는 것이 아니라, 내가 일하는 방식을 커맨드로 만들고, 스킬로 만들고, 워크플로우로 엮어야 한다. 내가 무의식적으로 하던 판단과 절차를 밖으로 꺼내서 AI가 따라 할 수 있게 만들어야 한다. 꼭 개발이 아니어도 좋으니, 내가 잘했다 못했다를 판단할 수 있는 영역에서 나만의 스킬은 무조건 꼭 한번 만들어봐야 한다. 그때 저는 정말 이게 사람들에게 알려줄 만한 이야기라고 생각했습니다.

나의 인사이트가 이름을 얻기 시작했다

그런데 강연을 준비하는 동안, 제가 해오던 노하우들이 하나씩 이름을 얻기 시작했습니다.

강연을 준비하던 도중 먼저 반복 작업을 하나의 작업 단위로 묶어두는 Skill이라는 기능이 출시 되었습니다. 그리고 그 Skill 자체를 만들어주는 /skill-creator가 나왔습니다. 매번 다시 설명하던 프로젝트의 규칙과 맥락은 memory나 CLAUDE.md 같은 방식으로 정리되기 시작했습니다. “끝나면 테스트는 무조건 돌려”처럼 특정 순간에 반드시 실행되어야 하는 절차는 hooks가 출시 되었습니다. 제가 /go로 만들고 싶었던 자동 주행은 loop와 오케스트레이션이라는 이름을 달기 시작했고, /retrospect로 시키던 반성문은 memory나 compound engineering 같은 개념으로 더 정교하게 이론이 되었습니다.

처음에는 신기했습니다. 내가 완전히 헛다리를 짚은 건 아니었구나. 내가 불편했던 지점은 다른 사람들도 불편했던 거고, 제가 필요하다고 느낀 구조는 도구를 만드는 사람들도 필요하다고 느끼고 있었던 겁니다. 혼자 삽질하면서 겨우 찾아낸 것들이 제품 업데이트를 따라 하나씩 공식적인 기능과 개념이 되어가면서, 오히려 제가 붙잡고 있던 문제가 더 선명해지는 느낌이었습니다.

그러면서 블로그와 링크드인과 유튜브에도 관련 이야기들이 쏟아지기 시작했습니다. 제 딴에는 시행착오를 겪어가며 겨우 찾아낸 인사이트였기에 강연에서 “여러분, 이런 것들이 있습니다”라고 말하려고 했던 내용들이었는데, 제가 그걸 정리하는 동안 그 이야기들은 어느새 하나씩 기능이 되고, 개념이 되고, 다른 사람들의 블로그와 유튜브 제목이 되어갔습니다.

이제까지는 제가 발견한 것 같았는데, 어느새 "md를 많이 만들어 두면 좋아요.. 그게 말이죠..." “아, LLM wiki 말하는 거죠?”가 되어버리는 느낌이랄까? 구루에서 한낱 범부가 되어버린 기분. 물론 생각해보면 당연했습니다. 제가 불편했던 건 다른 사람들도 불편했을 테고, 도구를 만드는 사람들은 그 문제를 더 가까이에서 보고 있었을 겁니다. 그래, 사람 마음이 다 똑같지. 그렇게 생각하면서도 뭔가 속상했습니다.

그 순간 질문이 조금 바뀌었습니다. AI를 잘 쓰는 방법론을 안다는 것, 그리고 그걸 알려준다는 건 어떤 의미가 있을까? 이제는 그냥 찾아보기만 해도 다 나오는데? AI 방법론이 중요하지 않다는 뜻은 아닙니다. 오히려 중요하기에 빨리 기능이 되었습니다. 사람들이 반복해서 쓰는 좋은 패턴은 곧 도구 안으로 들어갑니다. 매번 쓰던 프롬프트는 커맨드가 되고, 반복 작업은 Skill이 되고, 검증 절차는 hooks가 되고, 회고와 맥락 관리는 memory나 compound의 형태가 됩니다. 나의 노하우는 조금만 시간이 지나면 아무나 쓸 수 있는 버튼 같은 것이 된다는 걸 느꼈습니다.

결국 어제까지는 “제가 해보니 이렇게 하면 좋더라고요”였던 나의 인사이트는 금세 “이런 기능이 나왔습니다”가 되어버렸습니다. 방법론은 분명 필요하지만, 효과가 있을수록 오래 개인의 노하우로 남아 있기 어렵다고 생각했습니다. 이름이 붙고, 기능이 되고, 문서가 되고, 모두가 쓰는 기본값이 됩니다. 앞으로는 AI를 잘 쓰는 방법론을 아는 것만으로는 오래 차별화되기 어렵겠다는 생각이 들었습니다.

그때부터 강연에서 무엇을 말해야 하는가 혼란에 빠졌습니다. “AI를 어떻게 쓰면 좋은가”로는 부족했습니다. 강연날까지도 그 방법들은 계속 더 좋아지고, 더 쉬워지고, 더 많은 사람에게 열릴 테니까요. 실제로 강연하기 하루전에도 새로운 기능이 나와서 장표를 수정을 했었습니다.

그렇게 강연의 방향은 조금씩 바뀌어갔습니다. 방법 자체를 설명하는 것보다, 그 방법을 가지고 실제로 무엇을 해봤는지를 말해줘야 겠구나. AI로 어디까지 만들 수 있고, 어디서부터 막히고, 무엇은 생각보다 잘됐고, 무엇은 여전히 어려웠는지. 결국 제가 말해야 할 것도 사용법의 정리가 아니라, 그 사용법을 실제로 굴려본 경험이어야겠다는 생각이 들었습니다.

내가 던져볼 수 있는 문제의 크기가 커졌다

프론트엔드는 제가 너무 좋아하는 영역입니다. 화면과 상호작용을 다루는 일은 재밌고, 오래 해왔고, 여전히 관심이 많습니다. 그런데 프론트엔드라는 말 안에는 굉장히 넓은 스펙트럼이 들어 있습니다. 단순한 화면 구현도 프론트엔드고, Notion이나 Figma처럼 에디터, 캔버스, 상태 관리, 협업, 렌더링, 인터랙션이 복잡하게 얽힌 제품도 프론트엔드입니다. 둘 다 같은 이름으로 불리지만, 요구되는 기술의 깊이는 전혀 다릅니다.

그래서 마음 한편에는 늘 갈증이 있었습니다. 프론트엔드가 상대적으로 쉬운 영역처럼 취급될 때마다 조금 아쉬웠고, 언젠가는 프론트엔드의 기술력이 정말 필요한 것을 만들어보고 싶었습니다. 다만 일은 제가 원하는 것만 골라서 할 수 있는 게 아니기에, 회사에서 필요한 일을 해야 하고, 주어진 제품과 우선순위 안에서 움직여야 합니다. 만들고 싶은 것은 있었지만, 그런 규모의 개발에는 너무 많은 집중력과 시간이 필요했습니다. 본업만 해도 시간이 부족한데, 사이드로 그런 걸 한다는 건 늘 엄두가 나지 않았습니다.

주 업무가 대규모 레거시 코드 개편과 운영이 중심이 되면서, 그 갈증을 회사 일 안에서 어떻게 풀 수 있을지 계속 고민하게 됐습니다. 내가 좋아하는 프론트엔드의 깊이를 꼭 새로운 제품이나 사이드 프로젝트에서만 찾을 필요는 없지 않을까. 지금 맡고 있는 일 안에서도 충분히 복잡한 문제가 있고, 그 문제를 더 잘 풀 수 있는 화면과 도구를 만들 수 있지 않을까 싶었습니다. AI에게 코드를 시키면 분명 빠르게 고칩니다. 그런데 깨지는 것도 많았고, 야금야금 고치다 보니 전체가 잘 보이지 않았습니다. 코드가 커지면 사람이 모든 것을 머릿속에 넣고 움직이기 어렵습니다. 그러다 보니 텍스트 파일을 하나씩 여는 대신, Figma처럼 캔버스 위에 코드를 펼쳐놓고 전체 구조와 관계를 볼 수 있는 도구가 있으면 좋겠다고 생각했습니다. 에이전트 시대에는 코드를 보고 관리하는 UI도 달라져야 하지 않을까 싶었습니다.

예전 같으면 여기서 멈췄을 겁니다. 아이디어는 재밌지만, 만들기에는 너무 크니까요. 캔버스가 있고, 코드가 있고, 문서가 있고, AI와의 대화가 있고, 그 모든 것이 한 화면 안에서 연결되는 도구를 혼자 만든다는 건 생각만 해도 부담스러운 일이었습니다. 언젠가 시간이 많아지면 해봐야지, 혹은 같이할 사람이 생기면 해봐야지 하고 넘겼을 겁니다. 기술적으로 완전히 불가능해서가 아니라, 시작하기도 전에 마음속에서 이미 비용 계산이 끝나버리는 겁니다.

그런데 AI와 함께 만들기 시작하니 며칠 만에 형태가 나오기 시작했습니다. 캔버스가 생기고, 노드가 생기고, 파일을 읽고, 관계를 보여주고, 코드와 문서를 연결하는 화면이 생겼습니다. 완성도가 높다는 뜻은 아닙니다. 하지만 예전에는 상상으로만 남아 있던 것이 실제로 작업 가능한 문제처럼 보이기 시작했습니다. 예전부터 만들고 싶었던 프론트엔드 SaaS SuperApp 같은 것, Notion과 VSCode와 채팅을 결합한 IDE 같은 것, AI와 함께 코드를 만들고, 문서를 보고, 작업을 이어가고, 생각을 정리할 수 있는 도구가 더 이상 막연한 아이디어로만 느껴지지 않았습니다.

하지만 저에게 더 크게 다가온 것은 속도보다 시작의 허들이었습니다. 마음의 허들이랄까요? 예전에는 어떤 아이디어를 떠올리면, 자연스럽게 비용을 먼저 계산했습니다. 이걸 만들려면 화면이 몇 개 필요하지. 상태는 얼마나 복잡하지. 캔버스는 어떻게 구현하지. 파일 시스템은 어떻게 연결하지. 테스트는 어떻게 하지. 이걸 혼자서 하려면 몇 주, 몇 달이 걸리겠지. 그렇게 계산하다 보면 시작하기도 전에 마음이 접히는 일이 많았습니다. 정말 못 해서가 아니라, 해보기도 전에 너무 크다고 느껴졌습니다.

그런데 AI와 함께하니 계산 방식이 조금 바뀌었습니다. 완성까지 얼마나 걸릴지를 생각하기 전에, 일단 첫 형태를 만들어볼 수 있었습니다. 처음부터 완벽한 제품을 만들 필요는 없었습니다. 캔버스가 필요하면 캔버스를 만들고, 파일 관계를 보고 싶으면 파일을 읽어오게 하고, 문서와 코드를 연결하고 싶으면 그 연결부터 만들어보면 됐습니다. 거대한 제품을 한 번에 만드는 것이 아니라, 큰 문제를 실제로 만져볼 수 있는 작은 발판들이 생긴 겁니다.

그때 문득 그런 생각이 들었습니다. 왜 나는 이걸 지금까지 해보지도 않았을까. 이렇게 쉽게 첫 모양을 볼 수 있는데, 왜 머릿속에서 비용만 계산하다가 접고 있었을까. 물론 첫 모양이 곧 완성은 아닙니다. 만들어봤다고 해서 바로 제품이 되는 것도 아닙니다. 하지만 시작해보지 않으면 어디서 막히는지도 알 수 없습니다. 내가 상상하던 문제가 정말 어려운 문제인지, 아니면 그냥 한 번도 만져보지 않아서 커 보였던 문제인지조차 알 수 없습니다.

AI가 저 대신 코드를 써준다는 사실보다, 제가 예전에는 던져보지 못했던 질문을 던져볼 수 있게 됐다는 사실이 더 컸습니다. “이걸 내가 만들 수 있을까?”에서 “일단 어디까지 만들어볼 수 있을까?”로 질문이 바뀌었습니다. 아이디어가 머릿속에서만 맴도는 것이 아니라, 실제 화면과 코드와 동작으로 빠르게 내려오기 시작했습니다.

큰 문제를 굴리자, 개발의 나머지가 드러났다

그런데 볼륨이 조금씩 커지자 다른 문제가 생겼습니다. 코드가 5만 줄을 넘어가고, 파일이 늘어나고, 기능이 붙기 시작하니 더 이상 코드를 전부 따라가기가 어려웠습니다. 제가 직접 코딩할 때는 코드를 쓰면서 머릿속에 맥락이 남습니다. 어느 파일을 왜 고쳤는지, 어떤 흐름이 어디로 이어지는지, 다음에 어디를 봐야 하는지가 몸에 남습니다. 그런데 AI가 코드를 만들고 저는 결과를 받는 입장이 되자 그 감각이 끊겼습니다. 코드는 생기는데, 제가 그 코드를 다 본 것은 아니었습니다.

그래서 이후부터는 코드가 아니라 문서와 테스트부터 붙잡기 시작했습니다. 코드를 전부 따라갈 수 없다면, 적어도 무엇을 했는지 문서로 남아 있어야 했고, 제가 직접 모든 동작을 확인할 수 없다면 테스트가 그 일부를 대신 확인해줘야 했습니다. 작업이 끝나면 무엇을 바꿨는지, 왜 그렇게 했는지, 어떤 문제가 남았는지를 md로 정리하게 했고, 주요 흐름은 테스트로 확인하게 했습니다. 처음부터 거창하게 PRD와 요구사항 체계를 만들려고 한 것은 아니었습니다. 그냥 더 이상 머릿속으로만 감당할 수 없어서, 문서와 테스트라는 손잡이를 만든 것에 가까웠습니다.

이때 스킬도 정말 많이 만들었습니다. 작업이 끝나면 보고서를 남기는 스킬, 테스트를 돌리고 실패 원인을 정리하는 스킬, 변경 내용을 요약하는 스킬, 다음 작업을 뽑아내는 스킬, 이전 문서를 읽고 현재 상태를 정리하는 스킬 같은 것들이 하나씩 생겼습니다. 처음에는 반복 지시를 줄이기 위한 장치였는데, 어느 순간 그 스킬들이 제가 이 큰 작업을 놓치지 않게 붙잡아주는 구조가 되었습니다.

처음에는 이것도 신세계였습니다. 코드를 직접 다 읽지 않아도 진행 상황을 따라갈 수 있을 것 같았습니다. 그런데 작업이 늘어나자 이번에는 md 파일이 감당이 안 될 정도로 쌓이기 시작했습니다. 작업 보고, 변경 요약, 테스트 결과, 실패 원인, 회고, 코드 분석 리포트가 계속 생겼습니다. 코드 대신 문서를 보려고 했는데, 이제는 그 문서 자체를 관리해야 하는 상황이 된 겁니다.

그래서 md 뷰어를 만들기 시작했습니다. 사실 Obsidian을 쓰면 됩니다. 저도 Obsidian을 씁니다. 예전 같으면 여기서 끝났을 겁니다. 이미 좋은 도구가 있는데, 굳이 내가 다시 만들 이유가 없으니까요. 그런데 AI와 함께 만들다 보니 생각이 조금 달라졌습니다. Obsidian 전체를 다시 만들 필요는 없었습니다. 제가 필요한 것은 작업 중인 md 파일의 변화를 바로 보고, 코드와 문서를 제가 원하는 방식으로 연결해서 보고, 지금 AI가 만든 산출물을 한눈에 확인하는 정도였습니다.

그러면 그 정도만 만들면 됐습니다. 완성된 제품으로서의 Obsidian을 다시 만드는 것이 아니라, 지금 제 문제를 풀 수 있을 만큼의 md 뷰어를 만드는 것. 이게 되니까 감각이 달라졌습니다. 다 완성하지 않아도, 필요한 부분만 만족하면 의미가 생겼습니다. 예전에는 “이미 있는 도구를 쓰면 되지”라고 생각했을 일을, 이제는 “내 흐름에 맞게 필요한 만큼 만들면 되지”라고 생각하게 됐습니다.

그렇게 하나를 만들다 보니 또 다른 것이 필요해졌습니다. 코드가 잘 안 보이면 코드 분석 도구를 만들고, 흐름이 안 보이면 캔버스 기반 코드 뷰어를 만들고, 디버깅이 답답하면 필요한 devtool을 만들고, 테스트가 불편하면 테스트를 더 잘 돌리기 위한 장치를 만들었습니다. 만들다가 어렵다 싶으면 또 생각이 바뀝니다. 이걸 직접 풀기 어렵다면, 이 문제를 푸는 걸 도와주는 도구를 만들면 되지 않을까. 예전 같으면 배보다 배꼽이 더 크다고 생각했을 일입니다. 그런데 AI와 함께 하다 보니 그런 우회로도 실제 선택지가 되었습니다.

이 감각이 꽤 컸습니다. 필요한 것은 그냥 만들면 되는구나. 문제를 풀다 막히면, 그 문제를 푸는 도구를 만들면 되는구나. 도구를 만드는 일이 더 이상 최종 제품을 하나 더 만드는 일이 아니라, 지금 문제를 풀기 위한 중간 발판이 될 수 있었습니다.

그렇게 문서와 테스트로 붙잡기 시작한 작업은 점점 더 체계화되었습니다. 처음에는 “무엇을 했는지 남겨줘” 정도였는데, 나중에는 작업을 시작하기 전에 무엇을 만들 것인지 정리해야 했고, 기능이 커지면 요구사항을 나눠야 했고, 변경 단위가 커지면 이슈가 필요했고, 결과물을 받을 때는 리뷰 기준이 필요했습니다. 그렇게 하다 보니 어느새 PRD를 쓰고, 요구사항을 정리하고, 이슈를 따고, 보고서를 남기고, 리뷰하고, 테스트 코드를 붙이고 있었습니다.

그제야 조금 다른 생각이 들었습니다. 그래 맞아, 개발에는 코딩 말고도 해야 할 일이 참 많았지. 사실 새삼스러운 말은 아니었습니다. 개발을 오래 하다 보면, 개발이 코딩만으로 이루어지지 않는다는 건 너무 당연한 이야기였습니다. 그런데 AI에게 코딩이라는 행위를 전적으로 맡기다 보니, 새삼 개발에서 코딩 외의 영역들이 보이기 시작했습니다.

코드를 직접 칠 때는 그 많은 일들이 코딩 안에 자연스럽게 섞여 있었습니다. 코드를 쓰면서 구조를 고민하고, 상태의 의미를 정리하고, 이상한 흐름을 감으로 잡고, 다음에 손봐야 할 곳을 몸에 남깁니다. 문서로 다 남기지 않아도 어느 정도는 머릿속에 남고, 요구사항이 조금 흐려도 코드를 쓰는 과정에서 몸에 체화됩니다. 나는 회사에서 걸어 다니는 인간 히스토리였고 그 히스토리들이 모여 개발이 굴러갔었습니다.

그런데 코딩을 AI에게 넘기자, 분명 제가 개발을 시켰고 지시했는데도 제 몸과 머릿속에는 히스토리와 맥락과 구조가 예전만큼 남지 않았습니다. 코드는 빠르게 생기는데, 제가 코딩하면서 같이 흡수하던 판단들은 자연스럽게 쌓이지 않았습니다. 왜 이 파일을 고쳤는지, 이 구조가 왜 이렇게 되었는지, 어떤 흐름이 위험한지, 다음 변경에서 무엇을 조심해야 하는지. 직접 손으로 짤 때는 몸에 남던 것들이, AI가 만든 결과물을 받는 순간에는 따로 붙잡아두지 않으면 그냥 흘러가버렸습니다.

그래서 문서와 테스트와 이슈와 보고서가 전보다 더 많이 필요해졌습니다. 멋진 개발 프로세스를 만들기 위해서가 아니라, 예전에는 코딩을 하면서 자연스럽게 몸에 새겨지던 맥락과 히스토리를 다른 방식으로 남기기 위해서였습니다. 직접 코드를 작성할 때는 왜 이런 선택을 했는지, 어떤 시행착오를 거쳤는지, 어디가 위험한 지점인지 같은 것들이 작업 과정 자체를 통해 머릿속에 축적되었습니다. 하지만 AI가 코드를 대신 만들어주기 시작하자 그런 축적은 더 이상 "자동"으로 일어나지 않았습니다.

결국 AI 시대의 개발에서는 코딩 능력보다 맥락과 판단을 보존하는 기술이 더 중요해졌습니다. AI로 인해 당겨진 속도에 맞춰 요구사항을 정리하고, 의사결정 과정을 기록하고, 변경의 이유와 검증 기준을 남겨두는 일들이 단순한 관리 업무가 아니라 개발을 잘하기 위한 핵심 작업이 된 것입니다. 잘하는 개발자의 역할이란 좋은 코드를 만드는 일도 중요하지만, 그 과정에서 얻어지던 이해와 히스토리를 AI의 속도에 맞춰 별도로 쌓아야 하는 시대가 되었다고 생각합니다.

커밋은 쌓이는데, 제품은 커지지 않는다

그렇게 문서도 붙이고, 테스트도 붙이고, 작업 보고서도 남기기 시작했습니다. 작업을 시작하기 전에 무엇을 만들지 정리하고, 작업이 끝나면 무엇을 바꿨는지 남기고, 테스트도 돌리고, 실패하면 원인도 정리했습니다. 겉으로 보기에는 훨씬 그럴듯한 개발 프로세스가 만들어진 것 같았습니다.

커밋은 계속 쌓였습니다. 기능도 늘어났습니다. 테스트도 많아졌습니다. 문서도 늘어났습니다. 어떤 날은 하루에 커밋이 100개를 넘기도 했고, 어느 순간 테스트 코드도 700개를 넘어갔습니다. 숫자만 보면 든든했습니다. 예전 같으면 혼자서 며칠씩 붙잡고 있었을 일들이 몇 시간 만에 밀려 나갔고, 하루 종일 AI를 돌리고 있으면 결과물이 계속 커지는 것처럼 보였습니다.

그런데 어느 순간부터 이상한 느낌이 들기 시작했습니다. 분명히 커밋은 쌓이고 있었습니다. 파일도 늘어나고, 테스트도 늘어나고, 문서도 늘어나고 있었습니다. 그런데 제품이 앞으로 나아간다는 느낌은 점점 약해졌습니다. 기능 하나를 붙였는데 기대했던 만큼 좋아진 것 같지 않았고, 작은 버그 하나를 고쳤는데 다른 흐름이 어색해졌고, 테스트는 통과했다고 하는데 실제 화면에서 보면 뭔가 이상했습니다.

자.. 왼쪽 패널에서 SharedButton을 클릭하고, 그 안에 있는 Box의 내용을 선택한 다음에, 중앙 캔버스 안쪽의 특정 컨테이너에 붙여넣으면, 자식 노드가 원래 들어가야 하는 위치가 아니라 형제 노드 위치로 들어가는데 그게 아니라… 아오.

말로 설명하고 있는 순간부터 이미 피곤합니다. 개발자라면 코드를 열고 구조를 보면 될 것 같은데, 저는 이 복잡한 상태를 자연어로 설명하고 있었습니다. AI는 그 설명을 바탕으로 어딘가를 고칩니다. 그런데 다시 해보면 또 미묘하게 다릅니다. 화면은 나오고, 동작도 하고, 테스트도 통과하는데 제품으로 보면 이상한 상태가 계속 생겼습니다.

그래서 저는 너무 자연스럽게 코드를 보기 시작했습니다. 개발자니까요. 제품이 커지지 않고, 기능을 붙일수록 흔들리고, 작은 수정 하나에 다른 곳이 깨진다면, 당연히 코드 구조에 문제가 있다고 생각했습니다. 실제로 코드를 열어보면 문제가 보였습니다. 상태가 여기저기 흩어져 있고, 컴포넌트의 책임이 애매하고, 비슷한 로직이 여러 곳에 있고, 테스트는 많은데 무엇을 보장하는지 잘 모르겠고, 이름만 봐서는 이 코드가 어떤 맥락에서 생겼는지 알기 어려운 것들이 있었습니다.

그래서 저는 이 벽을 코드와 구조로 뚫으려고 했습니다. 상태 흐름을 정리해줘. 컴포넌트 책임을 나눠줘. 중복 로직을 걷어내줘. 테스트 가능한 구조로 바꿔줘. 나중에 유지보수하기 좋게 리팩터링해줘. 처음에는 기능을 만들라고 시켰다면, 이때부터는 구조를 고치라고 시키기 시작했습니다.

물론 효과는 있었습니다. 상태 흐름을 정리하면 AI가 어디를 고쳐야 하는지 조금 더 잘 찾았습니다. 컴포넌트 책임을 나눠주면 수정 범위가 줄었습니다. 이름을 제대로 붙이고, 폴더 구조를 정리하고, 테스트할 수 있는 단위를 만들어주면 이전보다 덜 헤맸습니다. 어떤 문제들은 실제로 앞으로 나아갔습니다. 아까는 같은 자리에서 맴돌던 버그가 구조를 조금 정리하고 나니 풀리기도 했습니다.

그래서 한동안은 답을 찾은 것 같았습니다. 역시 코드 품질이 중요하구나. AI가 만든 코드일수록 더 빨리 더러워지고, 더러워진 코드는 AI도 더 못 다루는구나. 그러면 내가 해야 할 일은 명확하다고 생각했습니다. AI가 잘 달릴 수 있게 길을 닦아줘야 한다. 컨벤션을 만들고, 구조를 정리하고, 테스트를 붙이고, 나쁜 패턴을 막고, AI가 수정할 수 있는 단위로 코드를 쪼개야 한다. 그렇게 하면 이 문제를 뚫을 수 있을 것 같았습니다.

그런데 이상하게도 그것만으로는 제품이 원하는 만큼 좋아지지 않았습니다. 코드가 조금 나아져도 화면은 여전히 어색했고, 테스트가 통과해도 사용해보면 말이 안 되는 흐름이 있었고, 구조를 정리해도 사용자의 경험이 좋아졌다는 느낌은 별개였습니다. 코드가 문제인 것은 맞았습니다. 구조가 흐리면 AI도 사람도 길을 잃고, 테스트가 없으면 다음 변경을 믿고 맡길 수 없습니다. 하지만 코드만 닦는다고 제품이 저절로 좋아지지는 않았습니다.

이때 처음으로 제품성의 벽 같은 것을 느꼈습니다. AI가 코드를 못 짜는 것은 아니었습니다. 오히려 너무 잘 짰습니다. 너무 많이 짰습니다. 문제는 그 코드들이 계속 쌓였을 때였습니다. 커밋은 쌓이고, 테스트도 늘고, 문서도 늘고 있었지만, 어느 순간부터 제가 보고 싶었던 것은 숫자가 아니었습니다. 정말 이 제품이 더 좋아지고 있는가. 사용자가 할 수 있는 일이 늘고 있는가. 다음 기능을 붙일 수 있을 만큼 구조가 버티고 있는가. 문제가 생겼을 때 다시 찾아가 고칠 수 있는가.

AI는 코드를 빠르게 늘려주었습니다. 하지만 코드가 늘어나는 것과 제품이 앞으로 나아가는 것은 같은 일이 아니었습니다. 그리고 저는 그 차이를 처음에는 코드와 구조의 문제로만 풀려고 했습니다.

AI로 프론트엔드를 만들기 어려운 이유

처음에는 제가 너무 복잡한 걸 만들고 있어서 그런가 싶었습니다. 캔버스도 있고, 노드도 있고, 문서도 있고, 코드도 있고, 상태도 많고, 화면도 많으니까요. 그런데 계속 해보다 보니 단순히 규모의 문제만은 아니었습니다. 프론트엔드라는 영역 자체가 LLM에게 유독 흔들리기 쉬운 지점들을 가지고 있었습니다.

LLM이 프론트엔드를 아예 못한다는 뜻은 아닙니다. 오히려 처음 화면은 꽤 잘 만듭니다. “대시보드 만들어줘”, “랜딩 페이지 만들어줘”, “관리자 화면 만들어줘”라고 하면 그럴싸한 결과물이 빠르게 나옵니다. 예전 같으면 HTML 구조를 잡고, CSS를 붙이고, 상태를 연결하고, 빈 화면을 채우는 데 꽤 걸렸을 일들이 순식간에 생깁니다. 처음 보면 감탄이 나옵니다. 와, 이 정도면 프론트엔드도 정말 많이 쉬워졌네 싶습니다.

그런데 문제는 그다음부터였습니다. 처음 그럴싸한 화면을 만드는 것과, 그 화면을 제품으로 계속 다듬는 것은 달랐습니다. 조금만 더 구체적인 기준을 넣기 시작하면 흔들리기 시작했습니다. 우리 디자인 시스템을 따라야 하고, 특정 상태에서는 버튼이 비활성화되어야 하고, 로딩 중에는 이 흐름이 막혀야 하고, 키보드로도 조작되어야 하고, 데이터가 없을 때와 많을 때의 화면도 달라야 했습니다. 처음 화면은 빠르게 나오지만, 제품으로 들어가기 시작하면 요구가 갑자기 촘촘해집니다.

그리고 그 요구들은 대부분 말로 설명하기가 애매합니다. “조금 더 자연스럽게”, “덜 튀게”, “선택된 느낌이 나게”, “우리 제품답게”, “흐름이 어색하지 않게” 같은 말들입니다. 사람끼리도 이런 말은 한 번에 정확히 맞추기 어렵습니다. 같은 “자연스럽게”라는 말도 어떤 화면에서는 애니메이션의 문제이고, 어떤 화면에서는 상태 전환의 문제이고, 어떤 화면에서는 정보 구조의 문제일 수 있습니다. 프론트엔드는 생각보다 많은 판단이 이런 모호한 언어 위에서 움직입니다.

사람끼리는 그 모호함을 화면과 맥락으로 좁혀왔습니다. 같은 화면을 보고, 이전에 합의한 패턴을 떠올리고, 팀의 취향과 제품의 결을 공유하면서 “이건 좀 어색한데요”라는 말을 조금씩 해석합니다. 말 자체가 정확해서 통하는 것이 아니라, 같은 것을 보면서 의미를 좁혀가기 때문에 통하는 것입니다.

그런데 LLM에게는 그 모호한 말을 매번 실행 가능한 코드로 바꾸라고 시키게 됩니다. “간격을 정리해줘”라고 하면 margin을 줄일 수도 있고, padding을 키울 수도 있고, 레이아웃 구조를 바꿀 수도 있습니다. “선택 상태를 명확하게 해줘”라고 하면 배경색을 바꿀 수도 있고, border를 넣을 수도 있고, 아이콘을 추가할 수도 있습니다. 각각은 틀린 답이 아닙니다. 문제는 그럴싸한 선택들이 계속 쌓이면 제품이 한 방향으로 수렴하지 않고 조금씩 흩어진다는 점입니다.

그래서 프론트엔드에서는 실패 신호도 흐립니다. 타입 에러처럼 바로 실패하지 않습니다. 빌드는 통과하고, 테스트도 통과하고, 화면도 나옵니다. 그런데 사용해보면 이상합니다. 디자인은 어딘가 평균적인 AI 화면으로 돌아가고, 상태는 임시 상태와 저장 상태가 섞이고, 클릭은 되지만 키보드와 포커스는 빠지고, 테스트는 구현을 확인하지만 사용자의 실제 흐름을 보장하지 못합니다. 각각은 작은 문제처럼 보이지만, 결국 같은 문제였습니다. 모호한 요구가 실행 가능한 기준으로 고정되지 않아서 결과물이 발산하는 것입니다.

이걸 겪다 보니 LLM과 일하는 감각이 주사위 게임처럼 느껴졌습니다. 여러 개의 주사위를 한 번에 던지고, 원하는 눈이 나온 주사위는 그대로 고정한 뒤, 마음에 들지 않는 주사위만 다시 던져서 최종적으로 원하는 조합을 만드는 게임입니다. 처음부터 모든 주사위가 원하는 대로 나오는 경우는 거의 없습니다. 어떤 주사위는 6이 나오고, 어떤 주사위는 1이나 2가 나옵니다. 중요한 것은 전부 다시 던지는 것이 아니라, 잘 나온 6은 고정하고 부족한 주사위만 다시 던지는 것입니다.

LLM과 함께 프론트엔드를 만들 때도 비슷했습니다. 한 번 시키면 디자인, 상태, 인터랙션, 접근성, 테스트, 코드 구조가 한꺼번에 굴러갑니다. 디자인은 괜찮은데 상태가 위험할 수도 있고, 구조는 나쁘지 않은데 사용 흐름이 어색할 수도 있고, 테스트는 통과하지만 제품 경험은 이상할 수도 있습니다. 문제는 LLM이 스스로 만든 결과물에 대해 “이건 6이고, 이건 1입니다”라고 알려주지 않는다는 점입니다. 무엇이 잘 나왔고 무엇이 빗나갔는지 알아보는 눈이 필요했습니다.

그래도 안되느건 아닙니다. 사실 모르면 그냥 마음에 들 때까지 계속 다시 던지면 됩니다. 실제로 그렇게 해도 언젠가는 됩니다. 하지만 그 방식은 비용이 큽니다. 잘 나온 것까지 다시 흔들어버리기도 하고, 정작 다시 던져야 할 것을 그대로 고정해버리기도 합니다. 내가 모호하게 지시하면 잘 뜬 6까지 다시 던져버리는 일이 생깁니다. 그래서 원하는 만큼, 원하는 곳의 주사위만 효율적으로 다시 던지려면 결국 이 분야를 알아야 하고, 도메인을 알아야 하고, 내가 원하는 결과가 무엇인지 알아야 합니다.

그때 AI를 잘한다는 말이 조금 다르게 보였습니다. AI를 잘한다는 것은 좋은 프롬프트 한 번으로 정답을 뽑아내는 능력이 아니었습니다. 결과물 안에서 무엇이 이미 맞고, 무엇이 아직 틀렸는지 알아보고, 잘 나온 것은 고정하고, 빗나간 것만 다시 던지게 만드는 능력에 가까웠습니다. 잘하는 사람은 뭐가 6인지 압니다. 그리고 될 때까지 합니다. 더 잘하는 사람은 될 때까지 하되, 아무 주사위나 다시 던지지 않고 원하는 눈이 나오지 않은 주사위만 골라 다시 던집니다.

결국 프론트엔드에서 AI가 어려운 이유는 단순히 CSS를 못 짜거나 상태 관리를 못해서가 아니었습니다. 프론트엔드는 원래도 모호한 감각을 구체적인 결과물로 수렴시키는 일이었고, AI와 함께하면 그 모호함이 더 쉽게 발산했습니다. 그래서 AI 시대에 프론트엔드를 잘한다는 것은 AI에게 코드를 많이 쓰게 만드는 일이 아니었습니다. 사람이 감각으로 알아차리던 것을 기준으로 고정하고, 결과물이 발산하지 않도록 잘 나온 것은 붙잡고 빗나간 것만 다시 시키는 일이었습니다.

그래서 이때의 통찰은 이것이었습니다. AI 시대에 프론트엔드를 잘한다는 것은, AI에게 코드를 많이 쓰게 만드는 일이 아니었습니다. AI가 만든 결과물이 일관성 있게 수렴할 수 있는 환경을 만드는 일이었습니다. 그리고 그건 제가 생각했던 것보다 훨씬 어려운 일이었습니다.

될 때까지 하니까 되던데요

그렇게 한동안 저는 프론트엔드가 LLM에게 어려운 영역이라고 생각했습니다. 그럴싸한 화면은 빨리 만들 수 있지만, 제품으로 계속 다듬어가기는 어렵다. 디자인은 평균값으로 돌아가고, 상태는 꼬이고, 접근성은 빠지고, 테스트는 믿기 어렵고, 화면의 어색함은 피드백으로 잘 드러나지 않는다. 그래서 AI 시대에 프론트엔드를 잘하려면, AI가 일관성 있게 수렴할 수 있는 환경을 만들어야 한다고 생각했습니다.

나는 이렇게나 어려운데 세상에서는 점점 “이제 프론트엔드도 AI로 쉽게 만들 수 있다”는 말이 많아지고 있었습니다. 저에게는 그 말이 상당히 싫었습니다. 물론 AI로 만든 화면은 빠르게 나옵니다. 대시보드, 랜딩 페이지, 관리자 화면 같은 것들은 몇 번만 시켜도 꽤 그럴싸하게 생깁니다. 그런데 제가 보기에는 어딘가에서 본 듯한 카드와 사이드바와 그라데이션이 있고, 화면은 있지만 디테일은 부족하고, 동작은 하지만 제품이라고 하기에는 애매했습니다. 하지만 사람들에게는 그 정도만 되어도 FE의 결과물에 만족을 할 수 있다는 점이 우리 동네 분식점의 키오스크를 불만없이 잘 사용하는 제 모습이 오버럽되며 FE 개발자로써의 초조함이 더해져 갔습니다.

그래서 정말로 보여주고 싶었습니다. AI로 화면을 만드는 일이 그냥 그럴싸한 UI를 뽑는 일이 아니라는 것. 프론트엔드를 오래 해온 사람이 만들면 확실히 다르다는 것. 좋은 화면과 좋은 상호작용과 오래 갈 수 있는 구조를 만드는 일은 여전히 어렵다는 것을 보여주고 싶었습니다. 그런데 막상 저도 원하는 만큼 잘 되지는 않았습니다. 디자인은 계속 평균값으로 돌아가고, 기능 하나는 생각보다 오래 걸리고, 상태는 자꾸 꼬였습니다. 남들이 만든 결과물을 보며 “저건 제품이라고 하기 어렵지”라고 생각하면서도, 정작 저 역시 제가 원하는 수준의 결과물을 쉽게 만들지는 못하고 있었습니다.

그러던 중 기획자분이 AI로 만든 프로토타입을 가져와서, “제가 프로토타입을 만들어왔는데요. 이렇게해서 우리 쪽에도 반영해주면 좋겠어요”라고 말했습니다. 요새 기획자분들도 이제는 기획을 AI로 작업하고 대개 AI Slop한 결과물로 만들어오시기에 AI스러운 그런 프로토타입을 기대했는데 막상 열어보니 생각보다 훨씬 좋았습니다. 디자인도 너무 괜찮았고, 화면의 흐름과 기능도 대부분이 구현이 되어 있었습니다. mock데이터의 활용과 심지어 기획서 내용까지도 하나의 프로토타입에 다 담겨 있어서 사용자가 무엇을 해야 하는지 예외랑 조심해야 하는 것까지 정리되어 있었습니다. 나는 그렇게 해도 잘 안되던 디자인과 기능 완성도를 갖춘 프로토타입을 보니 감탄을 하며 이내 궁금해졌습니다. 어떻게 이렇게까지 한거지?

“와! 이거 어떻게 하셨어요? AI로 하면 디자인이랑 기능 구현이 쉽게 안 될텐데 대단하시네요?” 뭔가 특별한 프롬프트가 있는지, 어떤 도구 조합을 썼는지, 어떤 방식으로 구조를 잡았는지 궁금했습니다. 저는 그동안 AI가 프론트엔드에서 흔들리지 않으려면 좋은 구조와 좋은 하네스가 먼저 필요하다고 생각하고 있었습니다. 분명 뭔가 다른 방법이 있을 것 같았습니다.

그런데 돌아온 답은 생각보다 단순했습니다. “그냥 될 때까지 하니까 되던데요.” 그리고 웃으면서 덧붙였습니다. “... 아! 당연히 바로 안 되죠. 어떨 때는 기능 완성하는데에 1주일도 걸린 적 있어요.”

그 말을 듣고 조금 멈칫했습니다. 저는 AI로 프론트엔드가 쉬워졌다는 말을 싫어했지만, 정작 저도 AI로 만든 좋은 결과물은 빠르게 나와야 한다는 기대에서 완전히 자유롭지 않았던 것 같습니다. AI가 이상한 코드를 짜면 “아직 멀었네”라고 생각했고, 디자인이 평균값으로 돌아가면 “역시 프론트엔드는 어렵네”라고 생각했습니다. 기능 하나가 계속 안 되면 “이걸 한 번에 잘하게 만들 방법이 없을까”를 먼저 생각했습니다. 좋은 스킬을 만들고, 좋은 하네스를 만들고, 좋은 절차를 만들면 처음부터 더 좋은 결과가 나와야 한다고 생각했습니다.

그런데 그 사람은 한 번에 좋은 결과를 뽑아낸 것이 아니었습니다. 안 되는 것을 계속 붙잡고 있었던 겁니다. 마음에 안 들면 다시 말하고, 이상하면 다시 고치고, 원하는 느낌이 나올 때까지 계속 밀어붙였습니다. AI가 한 번에 잘해주기를 기대한 것이 아니라, AI와 함께 될 때까지 수렴시킨 것이었습니다.

될 때까지 한다는 건 그냥 무작정 많이 돌린다는 뜻이 아니었습니다. 지금 나온 결과가 내가 원하는 것과 어떻게 다른지 볼 수 있어야 하고, 어디가 어색한지 느낄 수 있어야 하고, 무엇을 다시 요구해야 하는지 말할 수 있어야 합니다. 마음에 안 드는 결과를 보고도 “이 정도면 됐나?” 하고 넘기지 않아야 하고, 원하는 수준이 나올 때까지 계속 붙잡고 있어야 합니다. 때로는 기능 하나를 붙이는 데 며칠이 걸리고, 일주일이 걸려도 계속 물고 있어야 합니다.

그때 조금 알 것 같았습니다. AI가 모두에게 주어졌다고 해서 결과물이 평준화되는 것은 아니구나. 같은 도구를 써도 어떤 사람은 평균적인 AI 화면에서 멈추고, 어떤 사람은 거기서 계속 더 밀고 갑니다. 차이는 대단한 방법론에만 있지 않았습니다. 무엇이 아직 부족한지 보는 눈, “이게 아니야”라고 말할 수 있는 기준, 그리고 될 때까지 다시 시키는 집요함이 결과물의 차이를 만들고 있었습니다.

저는 즐거운 마음으로 그 결과물을 실제 제품에 반영해보려고 코드를 열었습니다. 그리고 바로 당황했습니다. '아... html과 css와 js의 범벅 그 자체... 이걸 어떻게 쓰지?' 결과물은 좋았는데, 안쪽은 꽤 거칠었습니다. 상태는 애매하게 섞여 있었고, 컴포넌트의 책임은 거의 없다시피 했고, 나중에 요구사항이 바뀌면 분명 힘들겠다 싶은 부분들이 보였습니다. 겉으로 보기에는 잘 움직이는데, 개발자인 제 눈에는 여기저기 위험해 보이는 지점들이 보였습니다.

예전 같으면 여기서 바로 “역시 이건 제대로 만든 게 아니야”라고 생각했을겁니다. 코드가 이렇게 되어 있으면 오래 못 간다. 이건 결국 다시 만들어야 한다. 이건 프로토타입이지 제품은 아니다. 그런데 이번에는 그렇게 쉽게 말하기가 어려웠습니다. 왜냐하면 코드를 보기 전 결과물이 너무 좋았기 때문입니다.

그때 제가 붙잡고 있던 생각도 조금 달라졌습니다. 저는 그동안 좋은 코드와 좋은 구조를 만들면 좋은 결과물로 수렴할 수 있다고 생각했습니다. 물론 여전히 맞는 말입니다. 구조가 나쁘면 오래 못 가고, 상태가 흐리면 금방 막히고, 테스트가 없으면 다음 변경을 믿고 맡길 수 없습니다. 그런데 좋은 결과물이 꼭 좋은 코드에서 먼저 나오는 것은 아닐 수도 있었습니다.

그 전까지 저는 AI 시대에 프론트엔드를 잘한다는 것이 일관성 있게 수렴하는 환경을 만드는 일이라고 생각했습니다. 그런데 이 경험을 통해 한 가지를 더 보게 됐습니다. 환경도 중요하지만, 결국 수렴은 사람이 시키는 것이었습니다. 좋은 결과물은 AI가 한 번에 뽑아준 것이 아니라, 누군가가 계속 보고, 다시 말하고, 물고 늘어진 끝에 만들어진 것이었습니다.

나는 끝까지 만드는 사람이 아니라, 잘 넘어가게 닦는 사람

AI로 FE를 몰라도 화면을 잘만드는 사람이나 결과를 보면서 조금 불편했습니다. 저는 AI로 만든 결과물을 보면 자꾸 코드가 눈에 밟혔습니다. 화면이 괜찮아 보여도 상태가 불안해 보이고, 동작은 하지만 구조가 오래 못 갈 것 같고, 지금은 되지만 다음 요구사항이 들어오면 깨질 것 같은 부분들이 보였습니다. 그래서 계속 멈칫했습니다. 이걸 그냥 밀고 가도 되나. 이 구조로 계속 쌓아도 되나. 지금은 좋아 보여도 나중에 수습이 안 되는 건 아닐까. 그런 생각이 먼저 들었습니다.

반대로 어떤 사람들은 결과물을 더 잘 밀고 갔습니다. 코드가 조금 거칠어도 일단 사용자가 보는 흐름을 만들고, 화면을 다듬고, 빠진 상태를 찾아내고, 원하는 모습이 나올 때까지 계속 다시 시켰습니다. 저는 그걸 보면서 부럽기도 했고, 이상하게 초조하기도 했습니다. 나는 왜 저렇게 못하지. 왜 자꾸 코드를 열어보지. 왜 결과물을 밀기보다 구조를 먼저 걱정하지. AI 시대에는 저렇게 될 때까지 밀어붙이는 사람이 더 잘하는 건가 싶었습니다.

그런데 계속 보다 보니 다른 장면도 보였습니다. 결과물을 잘 밀고 가던 사람도 어느 순간 막힙니다. 처음에는 화면이 빠르게 나오고, 기능도 붙고, 원하는 흐름도 만들어집니다. 그런데 조금만 더 복잡해지면 수정이 어려워집니다. 버튼 하나의 동작을 바꾸려고 했는데 다른 상태가 깨지고, 새로운 플로우를 추가하려고 하면 기존 흐름이 흔들리고, AI에게 계속 시켜도 같은 자리에서 맴돕니다. 겉으로는 작은 수정처럼 보이는데 안쪽 구조가 버티지 못하는 순간이 옵니다.

그때 코드를 열어보면 이유가 보입니다. 상태가 너무 넓게 퍼져 있거나, 컴포넌트가 너무 많은 책임을 가지고 있거나, 이름이 맥락을 설명하지 못하거나, 테스트가 실제 흐름을 보장하지 못하거나, 문서가 없어 왜 이렇게 만들었는지 알 수 없는 경우들이 있었습니다. 결과물의 감각은 좋은데, 그 결과물이 계속 앞으로 가기 위한 길이 정리되어 있지 않은 겁니다.

그런 순간에 제가 코드를 조금 닦아주면 다시 앞으로 가는 일이 있었습니다. 상태를 나누고, 책임을 정리하고, 이름을 붙이고, 중복을 걷어내고, 테스트할 수 있는 단위를 만들고, 다음 작업에서 참고할 맥락을 남깁니다. 그러면 방금 전까지 같은 자리에서 맴돌던 작업이 다시 움직이기 시작합니다. AI도 어디를 고쳐야 하는지 조금 더 잘 찾고, 결과물을 밀고 가던 사람도 다시 원하는 방향으로 요구할 수 있게 됩니다.

그때 제 코드 강박이 조금 다르게 보였습니다. 처음에는 그게 저를 못 나아가게 만드는 것 같았습니다. 나는 왜 이렇게 코드가 눈에 밟히지. 왜 결과물을 더 빠르게 밀지 못하지. 그런데 막상 다른 사람이 만든 좋은 결과물이 코드의 벽 앞에서 멈추는 걸 보니, 제가 보던 것들이 완전히 쓸모없는 걱정은 아니었습니다. 그건 결과물을 더 멀리 보내기 위해 필요한 정리이기도 했습니다.

물론 그렇다고 모든 코드를 완벽하게 만들어야 한다는 뜻은 아니었습니다. 그 생각으로 가면 또 앞으로 못 갑니다. AI가 만든 결과물은 처음부터 완벽할 수 없고, 빠르게 만든 프로토타입에는 어느 정도 거친 부분이 있을 수밖에 없습니다. 중요한 것은 모든 것을 깨끗하게 만드는 것이 아니라, 다음 사람이 이어받을 수 있을 만큼, 다음 요구사항을 붙일 수 있을 만큼, AI가 다시 수정할 수 있을 만큼 길을 내는 일이었습니다.

예전에는 개발자가 처음부터 끝까지 만드는 사람에 가까웠습니다. 요구사항을 듣고, 설계하고, 구현하고, 테스트하고, 배포하고, 유지보수했습니다. 물론 지금도 그런 일은 필요합니다. 하지만 AI가 코드를 만들고, 기획자와 디자이너와 PM이 직접 프로토타입을 만들어오는 장면을 보면서, 모든 결과물이 개발자에게서 시작하지는 않을 수 있겠다는 생각이 들었습니다. 누군가는 문제를 가장 잘 알고, 누군가는 결과물의 감각을 가장 잘 보고, 누군가는 그것을 계속 제품으로 이어갈 수 있게 정리합니다.

그렇게 보면 제가 해야 할 일도 조금 달라졌습니다. AI가 만든 결과물을 무조건 낮게 보거나, 코드가 별로라고 버리는 것이 아니었습니다. 그렇다고 그 결과물을 그대로 믿고 제품이라고 말할 수도 없었습니다. 그 사이에 일이 있었습니다. 가능성 있는 결과물이 버려지지 않게, 동시에 그대로 쌓이다가 무너지지 않게, 다음 단계로 넘어갈 수 있게 닦아주는 일입니다.

상태를 정리하고, 구조를 나누고, 위험한 부분을 표시하고, 테스트할 수 있는 지점을 만들고, 왜 이렇게 만들었는지 맥락을 남기고, 다음 사람이 어디서부터 보면 되는지 정리하는 것. AI가 다시 작업하기 좋은 형태로 만들고, 사람이 이어받아도 길을 잃지 않게 만드는 것. 결과물의 감각과 코드의 지속 가능성 사이를 이어주는 것. 그게 생각보다 중요한 일이었습니다.

그제야 조금 마음이 편해졌습니다. AI가 코딩을 다 해줄 수 있어도 저 혼자 AI로 끝까지 다 만들어야만 하는건아니었습니다. 누군가는 나보다 훨씬 더 만들고자 하는것이 선명하기에 내가 하는 것보다 더 잘만들어 낼 수 있습니다. 대신 저는 그 동안 해왔던 FE의 전문성으로 인해 결과물이 더 멀리 갈 수 있게 닦는 사람일 수 있었습니다. 코드가 눈에 밟히는 감각은 저를 느리게 만드는 약점이기도 했지만, 동시에 누군가가 만든 가능성을 제품 쪽으로 이어가게 만드는 능력이기도 했습니다.

AI 시대에 모든 사람이 같은 방식으로 개발할 필요는 없었습니다. 어떤 사람은 문제를 잘 보고, 어떤 사람은 결과물의 감각을 잘 보고, 어떤 사람은 구조와 지속 가능성을 잘 봅니다. AI가 코드를 만들어주기 시작하자, 오히려 그 차이가 더 잘 보였습니다. 저는 그 안에서 제가 할 수 있는 일을 조금 발견했습니다. 끝까지 혼자 다 만드는 사람이 아니라, 좋은 결과물이 다음 단계로 넘어갈 수 있게 닦아주는 사람. 그게 그때 제가 처음으로 붙잡은 역할이었습니다.

개발도 유튜브처럼 다양해지겠구나

개발의 허들이 낮아지면, 개발을 하는 사람의 종류도 많아집니다. 예전에는 코드를 직접 쓸 수 있는 사람만 무언가를 만들 수 있었습니다. 기획자는 기획서를 쓰고, 디자이너는 화면을 그리고, 개발자는 그것을 구현했습니다. 그런데 이제는 기획자가 직접 프로토타입을 만들고, 디자이너가 인터랙션을 붙이고, PM이 내부 도구를 만들고, 고객의 문제를 가장 잘 아는 사람이 직접 어느 정도 동작하는 결과물을 만들어옵니다. 그 결과물이 완벽한 제품은 아니더라도, 적어도 “이런 걸 원한다”를 훨씬 더 구체적으로 보여줄 수 있게 되었습니다.

이 생각을 하고 나니 개발자의 역할도 조금 다르게 보였습니다. 예전에는 개발을 잘한다는 말에 어느 정도 정해진 이미지가 있었습니다. 좋은 코드를 쓰고, 구조를 잘 잡고, 테스트를 붙이고, 요구사항을 구현하고, 운영 중인 제품을 안정적으로 유지하는 사람. 물론 지금도 여전히 중요합니다. 아니, 오히려 더 중요해질 수도 있습니다. 다만 그것만이 개발을 잘하는 유일한 방식이라고 말하기는 점점 어려워지고 있었습니다.

이 장면을 보면서 저는 유튜브를 떠올렸습니다. 예전에는 영상을 만든다는 것도 전문적인 일이었습니다. 방송국이 있고, PD가 있고, 작가가 있고, 카메라가 있고, 편집자가 있고, 송출 시스템이 있었습니다. 그런데 유튜브와 스마트폰과 편집 도구가 나오면서 영상의 허들이 크게 낮아졌습니다. 그렇다고 영상 전문가가 사라진 것은 아닙니다. 오히려 역할이 더 다양해졌습니다. 누군가는 직접 출연하고, 누군가는 기획을 잘하고, 누군가는 편집을 잘하고, 누군가는 썸네일을 잘 만들고, 누군가는 채널 운영을 잘하고, 누군가는 장비와 스튜디오를 제공하고, 누군가는 플랫폼을 만듭니다.

개발도 비슷한 방향으로 갈 수 있겠다는 생각이 들었습니다. 코딩의 허들이 낮아지면 개발자가 필요 없어지는 것이 아니라, 개발과 관련된 역할이 더 다양해질 수 있습니다. 누군가는 문제를 직접 해결하는 사람이 될 것이고, 누군가는 AI로 빠르게 프로토타입을 만드는 사람이 될 것이고, 누군가는 그 결과물을 제품으로 다듬는 사람이 될 것이고, 누군가는 그런 사람들이 더 잘 만들 수 있는 레이어와 플랫폼을 만드는 사람이 될 것입니다. 예전에는 개발자라는 이름 안에 묶여 있던 역할들이 조금씩 풀려나오는 느낌이었습니다.

처음에는 그게 조금 불편했습니다. 특히 코드가 별로인데 결과물은 좋은 사람들을 볼 때 그랬습니다. 개발자인 저는 자꾸 속으로 생각했습니다. 저 구조로는 오래 못 갈 텐데. 나중에 유지보수하기 힘들 텐데. 요구사항이 조금만 바뀌면 무너질 텐데. 그런데 동시에 인정할 수밖에 없었습니다. 그 사람은 문제를 풀고 있었습니다. 사용자가 보는 결과물을 만들고 있었고, 자기 문제를 앞으로 밀고 있었습니다. 코드는 별로였지만, 아무것도 만들지 않는 것보다는 훨씬 멀리 가고 있었습니다.

과거의 저라면 그 결과물을 조금 낮게 봤을지도 모릅니다. “이건 제대로 만든 게 아니야.” “이건 나중에 다 갈아엎어야 해.” “이건 개발이라고 부르기 어렵지.” 그런데 AI 시대에는 그 말을 조심해야겠다고 생각했습니다. 유튜브 초창기에도 비슷했을 겁니다. 방송의 기준으로 보면 부족한 영상들이 많았을 것입니다. 음향도 부족하고, 조명도 부족하고, 편집도 거칠고, 포맷도 정제되어 있지 않았을 겁니다. 그런데 그 안에서 새로운 형식이 나오고, 새로운 창작자가 나오고, 새로운 시장이 생겼습니다. 처음부터 기존 방송의 기준으로만 판단했다면 보이지 않았을 것들이 있었을 겁니다.

개발도 그럴 수 있습니다. AI로 만든 결과물 중에는 당연히 거친 것이 많을 것입니다. 동작은 하지만 구조는 엉성하고, 화면은 있지만 유지보수는 어렵고, 기능은 있지만 테스트는 부족한 것들이 많을 것입니다. 하지만 그 안에서 실제 문제를 푸는 사람도 나올 것입니다. 개발자가 아니라서 오히려 문제에 더 가까운 사람이 만들 수도 있습니다. 코드를 잘 모르지만, 사용자의 불편은 누구보다 잘 아는 사람이 AI를 가지고 필요한 도구를 만들 수도 있습니다. 그런 결과물을 모두 “개발을 모르는 사람이 만든 장난감”으로만 볼 수는 없었습니다.

그렇다고 전통적인 개발 역량이 덜 중요해진다는 뜻은 아니었습니다. 오히려 반대에 가까웠습니다. 결과물이 많아질수록, 그것을 오래 갈 수 있게 만드는 사람의 역할도 커질 것입니다. 유튜브가 생겼다고 촬영, 편집, 기획, 제작의 전문성이 사라지지 않은 것처럼, AI로 누구나 코드를 만들 수 있게 된다고 해서 설계, 구조화, 테스트, 운영, 보안, 접근성, 성능 같은 역량이 사라지지는 않습니다. 다만 그 역량이 쓰이는 위치가 바뀔 수 있습니다. 처음부터 모든 것을 만드는 사람에서, 누군가가 만든 가능성을 이어받아 더 멀리 가게 만드는 사람으로 이동할 수 있습니다.

이제는 감히 제가 배운 방식만이 개발의 정답이라고 말하기 어려워졌습니다. 부트캠프를 가고, 코딩 테스트를 준비하고, 과제를 풀고, 면접을 보고, 좋은 회사에 들어가고, 좋은 팀에서 좋은 코드를 쓰는 방식. 그 길은 여전히 중요합니다. 하지만 그 길만이 개발자가 되는 유일한 길은 아닐 수 있습니다. 누군가는 자기 문제를 풀기 위해 AI로 개발을 시작할 것이고, 누군가는 회사 안에서 필요한 도구를 직접 만들면서 개발에 가까워질 것이고, 누군가는 디자인과 개발 사이에서, 누군가는 기획과 구현 사이에서, 누군가는 운영과 자동화 사이에서 새로운 역할을 만들 것입니다.

그래서 AI 시대의 개발자는 하나의 모습으로 수렴하지 않을 것 같습니다. 오히려 더 많이 갈라질 것 같습니다. 어떤 사람은 여전히 깊은 시스템을 만들고, 어떤 사람은 복잡한 제품을 안정적으로 운영하고, 어떤 사람은 비개발자가 만든 프로토타입을 제품으로 이어주고, 어떤 사람은 AI가 쓰기 좋은 컴포넌트와 레이어를 만들고, 어떤 사람은 문제를 가장 잘 아는 사람으로서 직접 결과물을 만들어낼 것입니다. 모두가 같은 방식으로 코드를 잘 써야 하는 시대가 아니라, 각자가 잘 보는 문제를 AI와 함께 더 구체적인 결과물로 밀어붙이는 시대에 가까워질 것 같았습니다.

이렇게 생각하니 마음이 조금 편해졌습니다. 처음에는 AI가 개발자의 일을 빼앗는 것처럼 느껴졌습니다. 누군가 AI로 화면을 만들어오면, 프론트엔드 개발자인 나는 뭐 하지 싶은 마음도 들었습니다. 그런데 조금 지나고 보니, 그건 내 일이 사라진다는 신호라기보다 개발이라는 일이 더 넓어지고 있다는 신호에 가까웠습니다. 예전에는 개발자가 아니면 시작하기 어려웠던 일이 이제는 더 많은 사람에게 열리고 있었고, 그만큼 그 결과물을 이어받고, 다듬고, 확장하고, 오래 가게 만드는 일도 더 많아질 수 있었습니다.

물론 모든 사람이 다 좋은 결과물을 만들지는 않을 것입니다. AI가 있다고 해서 누구나 좋은 제품을 만드는 것도 아닙니다. 유튜브가 있다고 해서 누구나 좋은 영상을 만드는 것은 아닌 것처럼요. 하지만 분명한 것은, 이제 더 많은 사람이 만들 수 있게 되었다는 점입니다. 그리고 더 많은 사람이 만들 수 있게 되면, 좋은 것을 고르고, 다듬고, 이어주고, 키우는 사람의 역할도 함께 생깁니다.

그때부터 제가 해야 할 질문도 조금 달라졌습니다. “AI가 개발자를 대체할까?”보다 “이 넓어진 개발의 장에서 나는 어떤 문제를 더 낫게 만들 사람인가?”가 더 중요해졌습니다. 내가 코드를 잘 짜는 사람인지, 결과물을 잘 보는 사람인지, 문제를 잘 정의하는 사람인지, 구조를 잘 닦는 사람인지, 아니면 사람들이 더 잘 만들 수 있는 레이어를 만드는 사람인지. AI 시대에는 개발자의 길이 하나로 줄어드는 것이 아니라, 오히려 더 많이 열릴지도 모르겠다고 생각했습니다.

기대보다 못하지만, 생각보다 더 잘한다

결국 몇 달 동안 AI와 함께 개발을 하면서 가장 많이 느낀 것은 이상한 양가감정이었습니다. AI는 제 기대보다 못했습니다. 동시에 제 생각보다 훨씬 잘했습니다.

처음에는 너무 기대가 컸습니다. 벤치마크 숫자도 좋아졌고, 실제로 코드를 시켜보면 예전과는 다르게 잘했습니다. 브라우저를 직접 열게 할 수 있었고, 테스트도 돌리게 할 수 있었고, 커맨드도 만들고, 스킬도 만들고, 문서도 쓰게 하고, 회고도 시킬 수 있었습니다. 예전 같으면 제가 직접 하던 많은 일을 AI에게 넘길 수 있었습니다. 그러다 보니 어느 순간 기대가 너무 커졌습니다. 이 정도면 그냥 다 해주는 것 아닌가. 내가 말만 잘하면 제품까지 알아서 가는 것 아닌가. 그런 마음이 생겼습니다.

그런데 당연히 그렇게 되지는 않았습니다. 다 했다고 했는데 아니었고, 테스트가 통과했다고 했는데 화면은 이상했고, 구조를 정리했다고 했는데 다른 곳이 깨졌습니다. 디자인은 그럴싸한 평균값으로 돌아갔고, 상태는 조금씩 꼬였고, 접근성과 키보드 인터랙션은 빠졌고, 시각적으로 어색한 문제는 잘 알아차리지 못했습니다. 작은 기능 하나를 고치려고 했는데 몇 시간을 붙잡고 있는 일도 있었고, 기능 하나를 제대로 만들기 위해 일주일씩 물고 늘어지는 일도 있었습니다.

AI는 기대보다 못했습니다. 제가 상상한 것처럼 한 번에 원하는 제품을 만들어주는 존재는 아니었습니다. “다 했습니다”라는 말을 그대로 믿을 수도 없었고, 결과물을 받으면 결국 보고, 확인하고, 검수하고, 다시 시켜야 했습니다. AI가 코드를 쓴다고 해서 제품이 저절로 좋아지는 것도 아니었고, 커밋이 쌓인다고 제품이 앞으로 나아가는 것도 아니었습니다. 그럴싸한 데모와 오래 갈 제품 사이에는 여전히 꽤 큰 간격이 있었습니다.

그런데 AI는 제 생각보다 훨씬 더 많은 일을 할 수 있었습니다. 제가 시킬 수 있다고 생각하지 못했던 일들을 시킬 수 있었습니다. 브라우저 에러를 제가 복사해서 붙여넣지 않아도 직접 확인하게 할 수 있었고, 반복하던 작업을 스킬로 만들 수 있었고, 코드 분석 도구나 md 뷰어처럼 예전 같으면 ROI 때문에 만들지 않았을 도구도 필요한 만큼 만들 수 있었습니다. 엄두가 나지 않던 규모의 문제를 실제로 시작해볼 수 있었고, 제가 오래 미뤄두었던 아이디어를 다시 꺼내볼 수 있었습니다.

AI는 한 번에 제가 원하는 수준으로 데려다주지는 않았지만, 제가 갈 수 있는 거리 자체를 늘려주었습니다. 혼자서는 시작하지 않았을 문제를 시작하게 했고, 비용 때문에 생략하던 절차를 해보게 했고, 개발의 정석을 다시 꺼내보게 했습니다. 문서를 남기고, 테스트를 붙이고, 요구사항을 정리하고, 결과물을 검수하고, 필요한 도구를 만들고, 다시 그 도구로 더 큰 문제를 푸는 경험을 하게 했습니다. 제가 직접 코딩하지 않는 순간에도 개발에는 할 일이 참 많다는 것도 새삼 알게 됐습니다.

처음에는 AI가 잘하면 불안했고, 못하면 화가 났습니다. 잘하면 “그럼 나는 뭐 하지?” 싶었고, 못하면 “아직도 이것밖에 못해?” 싶었습니다. 기대보다 못하면 실망했고, 생각보다 잘하면 초조했습니다. 어느 쪽이든 마음이 편하지 않았습니다. 그런데 몇 번의 시행착오를 지나고 나니, 이 둘을 동시에 받아들이는 쪽이 더 현실적이었습니다.

AI는 분명 내 기대보다 못하지만 내 생각보다 훨씬 더 잘합니다.

그래서 개발자는 무엇을 해야 할까

처음의 질문은 단순했습니다. 사람이 코딩하지 않는 시대, 개발자는 무엇을 해야 할까. 그런데 몇 달 동안 AI와 함께 개발을 해보니, 이 질문은 생각보다 단순하지 않았습니다. 코딩을 계속 해야 한다고 말하기도 어렵고, 그렇다고 코딩은 이제 중요하지 않다고 말하기도 어려웠습니다. AI가 코드를 쓰는 것은 분명해졌지만, 코드가 생긴다고 곧바로 제품이 되는 것은 아니었기 때문입니다.

처음에는 AI를 잘 쓰는 방법을 찾으면 답이 나올 줄 알았습니다. 어떤 프롬프트를 쓰면 좋은지, 어떤 커맨드를 만들면 좋은지, 어떤 스킬과 워크플로우를 만들면 생산성이 올라가는지. 그런 것들을 정리하면 개발자의 역할도 자연스럽게 설명할 수 있을 거라고 생각했습니다. 그런데 그 방법들은 너무 빨리 기능이 되었습니다. 어제까지 제가 발견한 것 같던 것이 오늘은 제품 업데이트가 되고, 내일은 누군가의 블로그 제목이 되었습니다. AI를 잘 쓰는 방법론만으로는 오래 붙잡을 수 있는 답이 되기 어려웠습니다.

그래서 직접 더 큰 것을 만들어봤습니다. 예전에는 엄두도 못 내던 규모의 문제를 AI와 함께 굴려보았습니다. 그러자 개발 속도는 분명 달라졌습니다. 필요한 도구를 만들고, 문서를 남기고, 테스트를 붙이고, 코드 분석 도구를 만들고, md 뷰어도 만들었습니다. 예전에는 ROI 때문에 하지 않았을 일들을 할 수 있게 되었습니다. 그건 정말 신기했고, 고마운 경험이었습니다. AI는 제가 던져볼 수 있는 문제의 크기를 키워주었습니다.

그런데 문제가 커지자, 코딩 바깥에 있던 개발의 일들도 같이 커졌습니다. 요구사항을 정리해야 했고, 작업을 나눠야 했고, 문서를 남겨야 했고, 테스트를 믿을 수 있게 만들어야 했고, 결과물을 검수해야 했습니다. 제가 직접 코드를 칠 때는 머릿속에서 같이 처리되던 일들이, AI에게 코딩을 맡기자 전부 바깥으로 드러났습니다. 그때 새삼 느꼈습니다. 개발에는 코딩 말고도 할 일이 참 많았습니다.

제품을 크게 만들어보려고 하자 또 다른 벽도 보였습니다. 커밋은 쌓이고, 파일은 늘고, 테스트도 많아졌지만, 그것이 곧 제품이 좋아지는 것은 아니었습니다. 코드가 늘어나는 것과 제품이 앞으로 나아가는 것은 달랐습니다. 구조가 나쁘면 빨리 막혔고, 상태가 꼬이면 AI도 사람도 길을 잃었습니다. 그래서 코드를 닦고, 구조를 정리하고, 하네스를 만들고, 테스트와 문서를 붙였습니다. 효과는 있었습니다. 하지만 그것만으로도 충분하지는 않았습니다.

프론트엔드에서는 그 어려움이 더 선명했습니다. AI는 그럴싸한 화면을 빨리 만들었습니다. 하지만 제품으로 계속 수렴시키는 일은 어려웠습니다. 디자인은 평균값으로 돌아가고, 상태는 꼬이고, 접근성은 빠지고, 테스트는 많은데 안심이 되지 않았습니다. 그래서 프론트엔드를 잘한다는 말도 조금 다르게 보이기 시작했습니다. AI 시대에 프론트엔드를 잘한다는 것은, AI가 만든 결과물이 일관성 있게 수렴할 수 있는 환경을 만드는 일이었습니다. 그런데 그것은 생각보다 훨씬 어려운 일이었습니다.

그러다 잘하는 사람들을 보았습니다. 그들은 특별한 마법을 쓴 것이 아니었습니다. “될 때까지 하니까 되던데요” 처음에는 허탈했지만, 곧 알 것 같았습니다. 될 때까지 한다는 것은 아무 생각 없이 많이 돌린다는 뜻이 아니었습니다. 무엇이 부족한지 보고, 무엇이 원하는 것과 다른지 말하고, 원하는 수준이 나올 때까지 계속 밀어붙이는 일이었습니다. 결국 좋은 결과물은 한 번에 나오는 것이 아니라, 누군가가 계속 보고, 다시 말하고, 물고 늘어진 끝에 나오는 것이었습니다.

그 과정에서 제 역할도 조금 보였습니다. 저는 끝까지 결과물을 밀어붙이는 사람은 아닐지도 모릅니다. 저는 코드가 눈에 밟히고, 상태가 보이고, 구조가 보이고, 나중에 터질 지점이 보입니다. 처음에는 그게 저를 느리게 만드는 약점처럼 느껴졌습니다. 그런데 누군가가 만든 좋은 결과물이 코드의 벽 앞에서 멈추는 것을 보면서, 그 감각이 다른 방식으로 쓰일 수 있겠다고 생각했습니다. 가능성 있는 결과물이 더 멀리 갈 수 있게 닦아주는 일. AI와 사람이 만든 결과물이 버려지지 않고 제품으로 이어질 수 있게 구조와 맥락을 만들어주는 일. 그건 제가 할 수 있는 일이었습니다.

그렇게 생각하고 나니 개발자의 역할도 하나로 수렴하지 않을 것 같았습니다. 누군가는 문제를 가장 잘 아는 사람으로서 AI와 함께 직접 결과물을 만들 것입니다. 누군가는 그 결과물을 끝까지 밀어붙일 것입니다. 누군가는 그것이 오래 갈 수 있게 구조를 닦을 것입니다. 누군가는 AI가 더 잘 만들 수 있는 레이어와 도구를 만들 것입니다. 개발의 허들이 낮아질수록 개발자의 길이 좁아지는 것이 아니라, 오히려 더 여러 갈래로 벌어질지도 모르겠습니다.

사람이 코딩하지 않는 시대, 개발자는 무엇을 해야 할까. 지금의 저는 이 질문에 하나의 정답을 말하기보다, 몇 가지 해볼 만한 일을 말하고 싶습니다. 코딩을 계속 붙잡고 버티라는 이야기도 아니고, 코딩을 전부 내려놓으라는 이야기도 아닙니다. 다만 AI가 코딩을 할 수 있게 된 지금, 개발자는 자신이 AI에게 무엇을 맡길 수 있고, 무엇을 직접 봐야 하고, 어떤 기준으로 결과를 더 낫게 만들 수 있는지 직접 경험해봐야 한다고 생각합니다.

먼저 조금 아니 훨씬 더 큰 문제를 잡아보면 좋겠습니다. AI에게 작은 일을 시켜보는 것도 좋지만, 너무 작은 문제에서는 많은 것이 드러나지 않습니다. 작은 화면 하나, 작은 함수 하나, 작은 자동화 하나는 금방 됩니다. 그런데 조금 더 큰 문제를 잡으면 그때부터 다른 것들이 보입니다. 요구사항이 필요해지고, 문서가 필요해지고, 테스트가 필요해지고, 결과를 검수하는 기준이 필요해집니다. 코딩 말고도 개발 안에 있던 일들이 바깥으로 드러납니다.

스킬 하나는 반드시 직접 만들어보면 좋겠습니다. 그래서 나로 인해 AI가 더 나아진다는 것이 무엇인지 경험하기를 바랍니다. 거창한 것이 아니어도 됩니다. 꼭 개발과 관련된 것이 아니어도 됩니다. 내가 자주 반복하는 일, 매번 비슷하게 설명하는 일, 할 때마다 조금씩 귀찮은 일 하나를 골라서 AI가 더 잘하게 만들어보는 겁니다. 중요한 것은 스킬 자체가 아니라, 만들기 전과 만든 뒤의 차이를 느껴보는 일입니다. 같은 AI인데, 내가 절차를 정리하고, 기준을 넣고, 반복되는 맥락을 남기면 결과가 달라집니다. AI가 더 일을 잘하게 되는 감각, 내가 만든 구조 때문에 결과가 조금 더 나아지는 감각을 한 번은 몸으로 겪어보면 좋겠습니다.

AI에게 코드만 시키지 말고, 개발의 전 과정과 흐름도 함께 시켜보면 좋겠습니다. 무엇을 만들지 정리하게 하고, 요구사항을 나누게 하고, 작업 계획을 세우게 하고, 테스트를 붙이게 하고, 끝나면 무엇을 했는지 보고하게 해보세요. 그리고 그 결과를 그냥 믿지 말고 직접 봐야 합니다. 어디가 이상한지, 무엇이 빠졌는지, 무엇을 다시 시켜야 하는지 확인해야 합니다. AI가 코딩을 대신할수록, 사람에게는 결과를 보는 기준이 더 필요해집니다.

또 하나는 채팅과 코드에서 시야를 조금 벗어나보는 것입니다. 많은 사람이 AI를 채팅창에서 질문하고 답을 받는 도구로 쓰거나, IDE 안에서 코드를 생성하는 도구로만 씁니다. 그런데 AI가 만질 수 있는 범위는 생각보다 훨씬 큽니다. 잘 모르겠다면 GitHub를 더 깊게 써보는 것부터 시작해도 좋습니다. 이슈를 만들고, 댓글로 맥락을 남기고, PR로 변경을 묶고, Wiki로 지식을 쌓는 흐름을 익히면, AI에게 일을 맡기는 방식도 달라집니다. GitHub에는 단순히 코드 저장소가 아니라, 일을 나누고, 논의하고, 검수하고, 지식을 확장하는 구조가 들어 있습니다.

GitHub에 익숙해졌다면 그다음에는 Notion, Google Calendar, Slack, Sheets 같은 도구로 시야를 넓혀보면 좋겠습니다. AI는 코드만 만질 수 있는 것이 아닙니다. 회의록을 정리하고, 캘린더를 보고, 할 일을 나누고, 시트를 갱신하고, 슬랙의 논의를 요약하고, 문서와 이슈를 연결할 수 있습니다. 개발이 코드 파일 안에서만 일어나는 것이 아니듯이, AI와 함께 일하는 범위도 코드 안에만 갇힐 필요가 없습니다.

막히면 그 막힘을 그냥 참지 말고 도구로 만들어보는 것도 좋습니다. 문서가 너무 많이 쌓이면 문서를 보는 도구를 만들고, 코드가 안 보이면 코드 분석 도구를 만들고, 테스트가 불편하면 테스트를 더 잘 돌리는 장치를 만들고, 디버깅이 답답하면 devtool을 만들어보는 겁니다. 예전에는 ROI가 맞지 않아 넘겼던 일들이 이제는 생각보다 해볼 만한 일이 되었습니다. 완성된 제품을 만들 필요는 없습니다. 지금 내 문제를 풀 수 있을 만큼만 만들어도 의미가 생깁니다.

그리고 한 번에 안 된다고 너무 빨리 결론 내리지 않았으면 좋겠습니다. 잘하는 사람들은 특별한 주문을 알고 있어서 잘하는 게 아니었습니다. 될 때까지 보았고, 다시 말했고, 고쳤고, 또 시켰습니다. AI가 만든 결과가 마음에 들지 않을 때 “역시 안 되네”라고 끝내는 대신, 무엇이 부족한지 보고, 원하는 방향을 다시 말하고, 필요한 기준을 만들고, 될 때까지 수렴시켜보는 경험이 필요합니다.

AI가 본격적이 되면서 불과 6개월간의 경험치의 변화는 이루 말할 수 없이 많은 변화였습니다. 이러한 경험치를 말로 설명하는 일은 참 어렵다 생각이 듭니다. 같은 모델을 쓰고, 같은 도구를 쓰고, 같은 기능을 켜도 사람마다 만들어내는 결과는 너무나 많이 달랐습니다. 모델이 나아지면 다 해결될거야라고 하지만 잘하는 사람은 같은 도구가 주어져도 결과를 만들어내는 것이 달랐습니다. 어디까지 시켜볼 수 있다고 상상하는지, 무엇을 맡기고 무엇을 직접 봐야 하는지, 막혔을 때 어디까지 우회해볼 수 있는지, 결과가 마음에 들지 않을 때 무엇을 다시 요구할 수 있는지. 그런 사고의 범위와 경험의 차이가 생각보다 크게 느껴졌습니다.

저는 이 글이 무엇보다 AI의 벽보다 먼저, 우리 사고의 벽을 조금 넘어보는 계기가 되는데 도움이 되기를 바랍니다. AI가 못한다고 생각했던 것들 중에는 아직 시켜보지 않은 것들이 있었고, AI가 쉽게 해준다고 생각했던 것들 뒤에는 여전히 사람이 봐야 하는 기준과 집요함이 있었습니다. 결국 중요한 것은 어떤 도구를 쓰느냐만이 아니라, 그 도구로 어디까지 생각을 확장하고 무엇을 더 낫게 만들 수 있느냐였습니다.

다음 글에서는 이번 글에서 다 담지 못한 구체적인 방법과 시행착오를 정리해보려 합니다. 스킬을 어떻게 만들었는지, 문서와 테스트를 어떻게 붙였는지, AI가 더 잘 일하게 만들기 위해 어떤 구조를 시도했는지, 무엇은 효과가 있었고 무엇은 애매했는지. 아직은 저도 계속 배우는 중입니다.

긴 글 읽어주셔서 감사합니다. 다들 AI를 쓰는 경험이 더 큰 재미와 시야로 이어지기를 바랍니다. :)