5년 전 기획자였던 내가 개발자가 되기까지

지난 5년간 개발자로서의 회고

“이 기능은 구현하기 어려울 것 같습니다.”

“일정 내에 개발이 불가능할 것 같네요.”

“기술적으로 복잡한 문제가 있어서…”

기획자로 일하던 초기, 이런 답변들은 제 아이디어의 무덤이 되곤 했습니다. 아마 많은 기획자, PM, 비개발 직군 분들이 한 번쯤은 경험해 보셨을 상황일 겁니다. 제품에 대한 비전은 명확한데, 그것을 현실로 만드는 과정에서 마주하는 ‘기술적 한계’라는 벽 말이죠.

처음에는 단순히 “개발팀이 귀찮아서 그러나?” 하는 의심도 들었습니다. 하지만 시간이 지나며 깨달았습니다. 진짜 불가능한 일도 있고, 가능하지만 우선순위에서 밀리는 일도 있으며, 때로는 소통의 부재가 만든 오해도 있었습니다. 그리고 어느 쪽이든 결과는 비슷했습니다. 제가 그린 제품의 청사진과 실제 구현물 사이의 간극은 좀처럼 좁혀지지 않았거든요.

그러다 결정적인 순간이 찾아왔습니다. 어느 날 제가 구상한 기능에 대해 또다시 불가능하다라는 답변을 받았을 때, 제 안에서 무언가 결심이 섰습니다. 심지어 저는 엑셀로 프로토타입을 만들어 “이렇게 하면 가능하지 않을까요?”라고 제안했는데, “그건 엑셀에서만 되는 거예요.”라는 답변을 들었죠. 그 순간 깨달았습니다.

“그럼 제가 직접 배워서 해보겠습니다.”

말은 쉽게 했지만, 비전공자로서 개발의 세계에 발을 들이는 것은 쉽지 않았습니다. 다행히 개발자였던 사촌의 도움을 받을 수 있었습니다. 퇴근 후와 주말마다 사촌에게 직접 개발 수업을 받고, 과제도 수행하면서 점차 개발자로서의 경험을 쌓았습니다.

처음에는 리액트(React)로 간단한 컴포넌트를 만들 때도 개념적인 부분에서 어려움을 겪었습니다. ‘훅’이라는 개념이 특히 이해하기 어려웠죠. 함수인데 어떻게 이전에 변경했던 값을 기억하는 걸까? 클로저라는 개념도 생소했고, React의 렌더링 라이프사이클을 이해하는 데 꽤 시간이 걸렸습니다. Spring으로 첫 API를 만들 때는 의존성 주입(DI)이라는 개념부터 공부해야 했고, 엔드포인트 설계 규칙도 꼼꼼히 배워야 했습니다. 기획자의 눈으로 본 ‘간단한 기능’이 실제로는 얼마나 복잡한 작업이 필요한지 몸소 체험하게 되었습니다.

그러나 가장 큰 수확은 개발 자체를 배운 것보다, 문제를 바라보는 관점이 바뀐 것이었습니다. 이제는 기획과 개발 양쪽의 언어를 모두 이해하게 되었고, 처음부터 구현 가능성을 고려한 기획을 할 수 있게 되었습니다.

그렇게 5년이 지난 지금, 저는 AI 회사에서 CPO로 일하며 개발과 제품 총괄을 함께 담당하고 있습니다. 놀랍게도 비전공자로서의 제 배경은 AI 시대에 오히려 강점이 되었습니다. 개발 세부 지식의 부재를 AI의 힘으로 많이 메울 수 있었기 때문입니다. 요즘은 ‘바이브 코딩’이라 불리는 AI 활용 개발을 하고 있는데, 이는 제가 추구하던 ‘가이드 코딩’과 매우 닮아 있습니다.

이번 글은 비전공자 기획자에서 개발자로, 그리고 CPO가 되기까지의 5년간의 회고입니다. 동시에 AI 시대에 개발자의 역할이 어떻게 변화하고 있는지, 그리고 비전공자들에게 어떤 새로운 기회가 열리고 있는지에 대한 제 생각을 담았습니다. 만약 지금 기획과 개발 사이의 간극으로 답답함을 느끼고 계신다면, 혹은 비전공자임에도 개발에 도전해 보고 싶으신 분이라면, 이 글이 작은 용기와 인사이트를 드릴 수 있기를 바랍니다.

개발자로서의 첫 발걸음

개발을 시작하고 처음 마주한 것은 막막함이었습니다. 어디서부터 시작해야 할지, 어떤 기술을 배워야 할지, 비전공자인 제가 과연 이 길을 걸어갈 수 있을지, 질문은 많았지만 답은 명확하지 않았습니다.

처음 Pull Request를 올렸을 때의 기억이 생생합니다. 자신 있게 제출했던 코드가 무려 5번이나 반려되었습니다. 코드 리뷰 댓글이 30개 넘게 달렸고, 그때 비로소 깨달았죠. 제가 얼마나 배울 것이 많은지를. 다음번에는 반드시 한 번에 통과하겠다는 일념으로 이를 악물었습니다.

이대로는 안 되겠다 싶었습니다. 카카오와 토스의 기술 세미나를 찾아보기 시작했고, 놓쳤던 컴퓨터공학 기초를 하나씩 채워나갔습니다. SQL은 어떻게 작성해야 효율적인지, 테이블은 어떤 원칙으로 설계해야 하는지, 클라우드 서비스들은 어떤 상황에서 써야 하는지, 기초부터 차근차근 공부했습니다.

디자인 패턴 책도 구해 읽기 시작했습니다. 처음에는 무슨 말인지 하나도 이해가 되지 않았지만, 반복해서 읽고 실제 코드에 적용해 보면서 조금씩 이해하기 시작했습니다. 개발은 단순히 코드를 작성하는 것이 아니라, 문제를 어떻게 구조화하고 해결해 나가는지에 대한 사고방식이라는 것을 깨달았습니다.

코드 읽기는 또 다른 도전이었습니다. 차트 라이브러리에서 지원하지 않는 기능이 필요해 코드를 살펴봤는데, 예상보다 훨씬 어려웠습니다. 라이브러리 코드를 이해하려면 다양한 디자인 패턴과 그 의도를 파악해야 했죠. 한 줄을 읽다가 모르는 개념이 나오면 구글링하고, 또 그 설명에서 모르는 게 나오면 다시 찾아보는 끝없는 여정이었습니다.

솔직히 컴퓨터공학을 전공하지 않은 것이 후회되기도 했습니다. 동료들이 당연하게 알고 있는 개념을 저는 하나하나 찾아봐야 했으니까요. 하지만 이 과정이 오히려 더 깊은 이해로 이어지기도 했습니다.

기술 스택도 가리지 않고 모두 경험해 보려 했습니다. 프론트엔드에서는 리액트부터 시작해서 스벨트까지, 백엔드는 스프링부터 NestJS까지 닥치는 대로 사용해 봤죠. 각각의 기술이 가진 철학과 특징을 이해하면서, 점차 기술에 대한 안목도 생겨났습니다. 특히 스벨트를 배우면서(지금도 스벨트전도사로 활동 중입니다) 프레임워크들의 장단점을 더 깊이 이해하게 되었습니다. Kotlin도 경험해보면서 Java와는 다른 접근 방식에 새로운 인사이트를 얻었고요.

가장 어려웠던 것은 쿠버네티스였습니다. 개발자로 성장하면서 도커는 비교적 쉽게 익힐 수 있었지만, 쿠버네티스는 다른 차원이었습니다. 이론적으로는 각 구성 요소의 역할을 이해했지만, 로컬 환경에서 직접 구성해 보려니 문제가 한두 개가 아니었습니다. 무엇을 잘못했는지 알 수 없어 며칠을 헤맸던 기억이 납니다. 솔직히 말하면 지금도 이 부분은 완전히 숙달하지 못한 영역입니다. 그 외에도 백엔드가 준비되지 않았을 때 프론트를 먼저 개발하는 방법, 폴더 구조를 어떻게 나누는 것이 효율적인지 등 실무적인 지식도 하나하나 쌓아갔습니다.

시연용 프로토타입이 필요했을 땐 로컬 스토리지를 활용해 백엔드 없이도 동작하는 데모를 만들었습니다. 피그마의 디자인을 빠르게 코드로 옮기기 위한 VSCode 플러그인도 찾아 활용했고요. 모든 가능한 방법을 동원해 개발 역량을 키워나갔습니다.

처음에는 기술과 지식을 쌓는 것만으로도 충분하다고 생각했지만, 곧 또 다른 현실의 벽을 마주하게 되었습니다. 바로 이런 성장을 보여줄 객관적인 증거가 없다는 것이었죠. 개발자로서 인정받기 위해서는 이력서에 적을 수 있는 무언가가 필요했습니다.

깃허브를 포트폴리오로

개발 실력을 쌓기 위해 밤낮으로 고군분투했지만, 그 노력을 증명하는 건 또 다른 문제였습니다. 첫 이직을 준비하면서 이를 뼈저리게 깨달았죠. 서류 탈락의 연속이었습니다. “신입 수준의 실무 경험 2년이요? 죄송하지만 저희는 더 검증된 개발자를 찾고 있습니다.” 수많은 회사에서 비슷한 답변을 들었습니다.

면접에도 어려움이 많았습니다. 특정 프레임워크를 몇 년 써봤는지, 특정 상태 라이브러리로 어떤 문제 상황을 겪어봤는지 등 세부적인 질문들이 쏟아졌습니다. 이런 건 가서 적응하면서 배워도 충분하다고 생각했지만, 한편으로는 저를 판단할 객관적인 근거가 부족하니, 세부적인 지식을 물어볼 수밖에 없다는 것도 이해하게 되었습니다.

특히 회사 프로젝트만으로는 한계가 있었습니다. 보안 이슈로 코드를 공개할 수도 없었고, 실력을 객관적으로 증명하기도 어려웠죠. 이대로는 안 되겠다는 생각이 들었습니다. 제 실력을 보여주고 동시에 더 성장할 수 있는 방법이 필요했습니다.

처음에는 사이드 프로젝트를 시작해볼까 고민했는데요. 그런데 사람을 모으는 것부터가 일이었고, 여러 명이 함께하는 프로젝트는 코드를 얼마나 잘 짰느냐보다는 비즈니스적 성과가 중요해지는 문제가 있었습니다. 저는 순수하게 제 코딩 실력을 평가받고 성장할 수 있는 무언가가 필요했습니다. 이 과정에서 사이드 프로젝트와 오픈소스의 근본적인 차이점에 대해 깊이 생각해 보게 되었습니다. 개발자로서 우리는 항상 성장을 추구합니다. 그 과정에서 많은 이들이 사이드 프로젝트를 시작하거나, 오픈소스에 기여하는 길을 선택하는데, 이 두 접근 방식은 본질적으로 다른 특성을 가지고 있죠.

사이드 프로젝트는 주로 개인의 아이디어를 실현하거나 특정 문제를 해결하기 위해 시작됩니다. 성공의 척도는 주로 비즈니스적 성과, 즉 사용자 수나 수익에 의해 결정되죠. 이는 뛰어난 개발 능력보다는 기획력과 마케팅 스킬이 더 중요할 수 있음을 의미합니다. 반면, 오픈소스 프로젝트는 순수한 기술적 가치와 커뮤니티 기여에 초점을 맞춥니다. 깃허브 스타 수나 기여자 수와 같은 객관적인 지표로 그 가치를 인정받을 수 있죠.

이러한 차이점을 고려할 때, 저는 오픈소스 프로젝트가 개발자로서의 기술적 성장에 더욱 효과적인 방법이라고 판단했습니다. 무엇보다 오픈소스는 혼자서도 할 수 있었습니다. 저는 디자인을 잘 못하기도 했고, “그냥 혼자 하자”는 마음으로 오픈소스를 시작하게 되었습니다. 물론 이것만으로 오픈소스를 한 것은 아니고, 절반은 제 순수한 재미를 위한 것이었습니다.

그 당시에 저는 플러터에 관심이 많았습니다. 플러터로 만들면 쉽게 애니메이션이 들어간 수려한 앱을 만들 수 있다고 생각했거든요. 그러다 문득 생각이 들었습니다. “플러터 코드를 분석해 보면 어떨까? 코드 읽는 능력도 높이고, 이걸 자바스크립트로 옮기면 나만의 렌더링 엔진이 되는 거잖아!”

그렇게 시작한 것이 ‘플리터’ 프로젝트였습니다. 플러터에서 영감을 받아 시작했지만, 제 방식대로 자바스크립트로 재해석한 렌더링 엔진이었죠. 이 과정에서 다양한 디자인 패턴을 직접 적용해보고, 성능 최적화도 시도해 보면서 실력이 눈에 띄게 성장했습니다. 특히 기술 문서를 영어로 작성하면서 제가 왜 이런 설계를 했는지, 어떤 고민 끝에 이런 구조를 선택했는지 상세히 설명했더니, 이게 나중에 제 실력을 입증하는 결정적인 자료가 되었습니다.

예상치 못한 변화가 찾아온 건 프로젝트가 어느 정도 궤도에 오른 후였습니다. 처음엔 스타 몇 개 받은 것에 들떠있었는데, 어느 날부터 링크드인으로 메시지가 오기 시작했습니다. “라이브러리 코드를 보니 객체지향 설계 실력이 꽤 괜찮으신 것 같습니다”, “기술 문서 작성이 체계적이신데, 우리 회사의 개발 문서화도 맡아주실 수 있을까요?” 같은 내용이었죠. 깃허브가 정말 최고의 이력서가 된 순간이었습니다.

오픈소스는 제 성장 과정을 기록하는 포트폴리오이자 실력을 투명하게 증명하는 수단이 되었습니다. 단순히 코드만 작성한 것이 아니라, 문서화, 사용자 지원, 커뮤니티 관리 등 다양한 역할을 경험하며, 더 나은 개발자로 성장할 수 있었습니다. “남들이 나를 평가할 수 있는 자료를 만들자”라는 전략이 생각보다 큰 효과를 가져온 셈이었죠.

오픈소스의 세계를 경험하면서 개발은 단순한 직업이 아닌, 끊임없이 배우고 성장하는 여정임을 깨달았습니다. 그러던 와중 AI, 정확히는 LLM이 새로운 흐름으로 부상했습니다.

LLM이 급부상하다

사실 AI와의 첫 만남은 탭나인(TabNine)과 같은 코드 자동완성 도구였습니다. 제가 코드를 작성하면 뒤에 작성할 코드를 추측해 주는 서비스였죠. 그 당시에는 코드를 온전히 작성하는 건 무리였지만, 저에게는 신세계였습니다. “이런 게 가능하다니…”라는 경이로움을 느꼈던 기억이 납니다.

2024년에 저는 클로드 서비스를 본격적으로 사용하기 시작하면서, 놀라운 경험을 했습니다. 한 라이브러리를 만들 때 제가 직접 코드를 한 줄도 작성하지 않고, 클로드와의 대화만으로 완성했던 거죠. 이건 단순히 테트리스 같은 미니 프로젝트가 아니라, 실무에서 사용할 수 있는 코드였습니다. 토이 프로젝트를 넘어 온전한 라이브러리까지 가능해진 거죠. 현재도 AI를 활용하면서 제가 직접 코드를 짜는 경우는 손에 꼽습니다.

그런데 제가 “AI로 제대로 된 코드를 짤 수 있다”라고 말했을 때, 주변에서는 “LLM은 그 정도 수준이 아니다”라는 목소리가 많았습니다. 현재도 그런 의견이 있죠. 그런데 이 말은 사실이기도 하고 틀리기도 합니다.

몇몇 개발자분들은 LLM에 한 번의 요청으로 완벽한 결과를 기대하는 경향이 있었습니다. 원하는 결과가 바로 나오지 않으면 ‘아직 AI는 이 수준’이라고 판단하고 다른 방법을 찾아가는 것이 자연스러운 과정이었죠. 저는 조금 다른 접근법을 택했습니다. 처음부터 LLM이 한 번에 내 의도를 완벽히 이해할 거라 기대하지 않고, 점진적인 소통을 통해 결과를 개선해 나가는 방식이었습니다.

이건 아마도 제 교육학 배경과 오랜 과외 경험에서 비롯된 접근법이었을 겁니다. 수학 과외를 하면서 학생이 “이해했어요”라고 말해도 항상 의심스럽게 접근했거든요. 다른 질문을 던져보고, 오개념을 발견하면 수정해 주는 과정이 습관화되어 있었습니다. 저는 이를 우스갯소리로 ‘제로 트러스트 프롬프트’라고 부릅니다. “쟤가 내 말을 제대로 이해할 리가 없다”라는 전제에서 시작하는 거죠.

저는 LLM을 ‘매우 유능하지만 아직 배우는 중인 주니어 개발자’라고 생각하면 접근법이 달라진다고 느꼈습니다. 주니어 개발자에게 코드를 설명하듯, 맥락을 충분히 제공하고 명확한 방향을 제시해 주면 놀라운 결과물을 만들어내죠. 핵심은 피드백이라고 생각합니다. LLM의 응답을 보고, “아, 내가 이렇게 설명했어야 했구나”를 깨닫고, 피드백을 주는 것이죠. 

저는 오히려 LLM과 대화할 때 답답함이 아닌 편안함을 느꼈습니다. 일반적인 코드 리뷰에서는 상대방의 감정을 고려해 말을 돌려야 하지만, LLM에는 직설적으로 “이 부분은 이렇게 구현해야 해”라고 명확하게 말할 수 있어서 오히려 소통이 수월했습니다. 이렇게 생각을 잘 전달하고 LLM에게 적절히 위임하면 시간도 벌고 피로도 줄어 더 다양한 일에 집중할 수 있습니다.

이러한 LLM과의 소통 방식이 효과적이었던 데는 개인적인 배경도 영향이 있었던 것 같습니다. 직접 말하기엔 쑥스럽지만, 기획자분들이 ‘제 설명은 이해하기 쉽다’라고 말해주십니다. 기술 발표도 나름 괜찮게 한다는 평을 받고요. 생각을 조각내서 전달하고, 상대방의 반응을 보며 제 설명을 조정하는 이런 역량이 LLM과의 소통에서도 큰 도움이 되었습니다.

이런 경험을 바탕으로 저는 개인적으로 LLM의 발전을 누구보다 기대하고 있습니다. 설명을 잘하는 제 역량이 있으니, 부족한 기술 지식은 LLM만 잘 활용하면 메꿀 수 있겠다는 생각이 들었거든요. “이제 라이브러리의 세부 조작법은 몰라도 LLM이 대신 작성해 주겠구나, 늦게 개발을 시작한 간극을 좁힐 수 있는 기회다!”라고 생각했습니다. 좋은 소통 능력과 AI의 기술적 전문성이 결합하면, 비전공자의 한계를 크게 극복할 수 있다는 가능성을 발견한 거죠.

현재 저는 PO 역할을 맡고 있지만, 이런 생산성 향상 도구 덕분에 필요할 때 직접 개발에 뛰어들기도 합니다. 디자인 없이도 AI와 협업하며 기획부터 제품까지 함께 개발하고 있죠. 회사 CTO는 윈드서프를 3개 동시에 켜서, 세 개의 프로젝트를 동시에 작업하는 기염을 토하기도 했습니다. 이전에는 상상도 할 수 없었던 효율성이죠.

이러면서 한편으로는 AI의 발전과 개발자의 역할에 대해 고민하게 되었습니다. AI가 결국 개발자를 대체할 것인가? 아니면 새로운 형태의 개발자가 등장할 것인가? 이에 대한 제 생각도 나눠보겠습니다.

바이브 코딩이란 뭘까?

‘바이브 코딩’은 최근 IT 업계에서 주목받고 있는 개발 방식입니다. AI를 활용해 코드를 작성하는 새로운 패러다임으로, 개발자가 직접 키보드를 두드려 코딩하는 대신 AI와의 대화를 통해 코드를 생성하는 방식을 말합니다. 이름에서 느껴지듯 ‘느낌(vibe)’으로 코딩한다는 뉘앙스가 있지만, 제 경험으로는 실제로 개발자의 의도와 방향성을 AI에 효과적으로 전달하는 고도의 소통 기술이 필요합니다.

저는 바이브 코딩에 중요한 한계가 있다고 생각합니다. 추리소설에서 탐정의 지능은 작가의 지능을 넘을 수 없다는 말처럼, AI는 프롬프터의 이해도와 지시를 넘어설 수 없습니다. AI는 세부적인 라이브러리 사용법이나 타이핑 실수 같은 꼼꼼한 작업에는 탁월하지만, 언제나 요청을 받아야만 움직이는 수동적 도구입니다. 따라서 제 관점에서 요청을 전달하는 사람의 역량이 결과물의 품질을 결정하는 상한선이 됩니다.

제가 보기에 생산성 도구로서의 AI는 내 능력의 상한치를 높이는 것이 아니라, 내가 할 수 있는 일에서 소요 시간을 줄여주는 역할을 합니다. 제가 개발자로 성장하면서 쌓아온 경험 - 라이브러리 코드 분석 방법, API 연동 패턴, BFF 개념 적용, 컴포넌트 분리의 원칙 등 - 이 바이브 코딩의 품질을 결정하는 핵심 요소가 됩니다. 이런 면에서 저는 바이브 코딩보다 ‘가이드 코딩’이라는 표현이 더 적절하다고 생각합니다.

저는 다양한 회의와 서류 작업으로 문맥 전환이 잦은 환경에서 일하다 보니, 대부분의 코드를 AI를 통해 작성합니다. 제 바이브 코딩 방식은 크게 세 가지 형태로 나눌 수 있습니다.

첫째, 구체적인 지시형입니다. 참고할 파일, 코드 스타일 등을 포함한 10~15줄의 프롬프트를 작성해 윈드서프와 같은 에이전트 기반 AI 툴에 지시합니다.

둘째, 사소한 수정 위임형입니다. border-radius 값 변경과 같은 단순 작업도 AI에 맡깁니다. 이렇게 하면 의외로 실수를 줄일 수 있는데, AI가 맥락의 일관성을 유지하면서 제가 놓친 부분(예: 모바일 반응형 설정)까지 함께 반영하기 때문입니다. 또한 단순 작업이라도 직접 하면 발생하는 인지적 피로를 줄일 수 있습니다.

셋째, 사고 정리형입니다. 불명확한 아이디어를 다듬을 때 AI와 대화합니다. 이때는 바로 코드 작성을 목적으로 하지 않고, AI가 저에게 질문을 던지도록 유도하며 제 생각을 구체화합니다. 윈드서프의 ‘chat 모드’를 활용해 코드 수정을 하지 말라고 명시하고, 아이디어가 완성되면 다시 ‘write 모드’로 전환해 코드 작성을 지시합니다.

흥미롭게도 경험에 따르면 바이브 코딩 시대에 개발 역량이 오히려 더 중요해진다고 느낍니다. 주니어 개발자와 시니어 개발자가 AI를 사용할 때 생산성 향상의 폭에 큰 차이가 있었습니다. 코드의 본질적인 부분에 대한 이해와 다양한 경험이 AI 툴의 효과를 극대화하는 요소가 되기 때문입니다. 제가 관찰한 바로는 AI는 단순히 개발의 진입장벽을 낮추는 것보다, 경험 많은 개발자의 생산성을 비약적으로 향상시키는 데 더 강력한 효과를 발휘합니다.

결국 바이브 코딩 시대에 개발자의 역할이 코드 작성자에서, AI 프롬프팅 전문가이자 검증자로 변화하고 있습니다. 그러나 이 새로운 역할을 효과적으로 수행하기 위해서는 여전히 탄탄한 개발 지식과 경험이 필수적입니다. 바이브 코딩은 개발자를 대체하는 것이 아니라, 개발자에게 더 높은 수준의 사고와 효율성을 요구하는 새로운 도전이 되고 있습니다.

지금까지의 여정, 그리고 앞으로는?

비전공자에서 개발자로, 그리고 CPO로 일하면서 제가 경험한 5년의 여정은 끊임없는 변화와 학습의 연속이었습니다. 그리고 지금은 또 한 번의 큰 변곡점을 지나고 있다고 느끼는데요. 개발자의 역할이 코드를 직접 타이핑하는 사람에서 ‘코드 오케스트레이터’로 진화하고 있는 것 같습니다.

“LLM을 활용하는 개발자 한 명이 활용하지 않는 개발자 세 명의 생산성을 내고 있습니다.” 제가 링크드인에서 한 말입니다. 이런 말이 다소 충격적으로 들릴 수 있지만, 제가 보기에 실제 현장에서는 이미 현실이 되어가는 것 같습니다. 자연어로 개발하는 시대가 생각보다 빠르게 도래하고 있다고 생각합니다.

이러한 변화는 개발자의 역할을 근본적으로 재정의한다고 봅니다. 전통적인 의미의 코딩 테스트나 특정 프레임워크 경험의 가치가 달라지고 있다고 느끼는데, 앞으로 어떤 역량이 더 중요해질까요?

첫째, 문제 정의 능력입니다. AI가 코드 작성을 도와도 무엇을 만들어야 할지, 어떤 문제를 해결해야 할지 정의하는 것은 여전히 사람의 몫이라고 생각합니다. 역설적으로 다양한 코드를 직접 짜보며 쌓은 경험이 이런 지시 능력의 바탕이 되는 것 같습니다.

둘째, 비개발자와 개발자의 경계가 흐려지고 있습니다. 제가 아는 디자이너 지인은 AI를 활용해 직접 퍼블리싱을 합니다. 자신이 만든 디자인을 토대로 피드백을 주고받으며, 프롬프팅으로 코드를 생성하는 것이죠. 개발자는 이제 원하는 결과를 정의하고 검토할 줄 아는 가이드로서의 역할이 강화되는 것 같습니다.

누군가는 바이브 코딩을 ‘입코딩’이라며 한계가 있다고 합니다. 어느 정도는 동의합니다. 아무것도 모르는 사람이 말 한두 마디 한다고 수려한 웹 서비스가 나오지는 않을 테니까요. 하지만 이런 한계가 시니어 개발자에게도 똑같이 적용되는 건 아니라고 생각합니다. 분명 이 방법에 익숙해지면 저보다 더 뛰어난 개발자들은 이런 코딩 방식으로 생산성을 폭발적으로 높일 수 있을 겁니다.

5년 전, 답답함에 직접 개발자의 길을 택했던 제가 지금은 AI와 함께 개발하는 방식에 적응하며, 또 다른 변화를 맞이하고 있습니다. 그동안의 여정에서 얻은 가장 큰 깨달음은 변화를 두려워하지 않는 자세가 가장 중요하다는 것입니다. 기획자에서 개발자로, 그리고 이제는 AI와 함께 일하는 코드 오케스트레이터로, 계속해서 진화하는 과정에서 유연함과 끊임없는 학습이 제 성장의 원동력이 되었습니다.

앞으로 저는 두 가지 방향으로 나아가려고 합니다. 하나는 AI와의 협업 방식을 더 고도화하는 것입니다. 단순히 코드를 생성하는 것을 넘어, 기획과 설계 단계에서부터 AI를 적극 활용하는 방법을 연구하고 싶습니다. 다른 하나는 이런 경험을 바탕으로 더 많은 비전공자들이 개발의 세계로 진입할 수 있도록 돕는 일입니다. AI가 개발의 진입 장벽을 낮추고 있지만, 여전히 갈 길은 멀다고 생각합니다. 저처럼 기획과 개발 사이의 간극에 고민하는 이들에게 AI를 활용한 개발 방법론을 공유하고 싶습니다.

저는 5년 전 기획자에서 개발자로 전환하면서 많은 불확실성을 느꼈지만, 그 선택이 더 다양한 기회를 열어줬습니다. AI와 함께하는 개발도 처음엔 낯설었지만, 이제는 제 업무의 핵심이 되었고요. 변화는 언제나 도전을 불러오지만, 그 속에서 성장의 기회를 찾을 수 있다고 생각합니다.

여러분은 지금, 어떤 방식으로 AI와 함께 일하고 계신가요? 또 어떻게 커리어를 확장해 가고 싶나요?

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.