바이브 코딩 - 기획만 하던 테이블오더 "직접 개발"해보기 2편 (회고)
이전 글은, 바이브 코딩을 활용해 프로젝트 과정에서 어떻게 구체적으로 설계하고 개발했는지에 대한 글이었다.
이번 글은 그 과정에서의 다양한 느낀 점(AI에 대해서, 기획자로서 등)에 대해 간략히 적어보고자 한다.
1. 놀라운 AI의 개발속도, 하지만 사람 손이 아직까진 필요하다.
상세한 기획 및 개발 문서(ex. ERD, API 명세, 기능명세 등)를 참고자료로 제시하고, 구체적인 개발 프롬프트를 제시할 수 있다면
정말 자연어만으로도 코딩을 할 수 있다는 것을 느꼈다. 실제로 이번 개발을 하면서 직접 코드를 작성한 것은 5% 가 채 되지 않았다. 어떻게 돌아가야 한다는 로직만 잘 설계한다면, 기본적인 CRUD 성 코드나 아주 복잡한 로직이 아닌 코드들은 따로 손대지 않고 바로 넣어도 될 정도로 구조를 맞춰 코드를 전달해 줬다.
하지만 무조건 완벽한 것만은 아니었다. 조금 복잡한 로직을 타는 경우 AI가 불완전한 코드를 전달해주는 경우가 꽤 있었다. (ex. 외부 Open API 연결, 프론트엔드 단에서의 localstorage 등을 통한 유저 입력값 들고 있기). 또 미세한 버그가 발생했을 때 수정하는데 있어, AI가 혼자 해결 못하는 경우도 꽤 있었다.
이런 케이스에선, AI에게만 의존할 순 없었고 코드를 직접 하나씩 읽어보며 로직상 빈 곳을 찾아 코드를 수정해야 했다. 정말 단순한 프로그램, 비슷하게만 돌아가면 되는 프로그램이야 기획서만 혹은 바이브코딩에서 말하는 소위 "느낌만" 던져준 후 "AI야, 처음부터 다 짜줘!"라고 해도 될 거다. 하지만, 조금 더 복잡한 프로그램은 아직까지는 사람의 손이 어느 정도는 필요하다고 느꼈다.
2. AI가 개발도 해주는 세상, 그렇기에 개발/설계 공부를 더 하고 싶어졌다.
앞서 말한 내용과 이어지는 내용이다.
AI에게 개발을 부탁하더라도, 미세한 부분의 수정을 해나감에 있어 어느정도의 개발지식이 필요할 수밖에 없다. 구체적으로 어떻게 만들어달라고 전달해야, AI는 더 퀄리티 있는 코드를 전달해 준다. 직접 코드를 전체다 짜진 못하더라도, 코드를 어느 정도 읽고 이해할 수 있어야 AI가 만들어낸 결과물을 이해하고 수정요청을 할 수 있으며, AI가 놓치는 부분들은 직접 고칠 수도 있을 것이다. AI의 개발능력을 더 많이 잘 활용하려면 역설적으로 내가 개발에 대한 지식을 더 많이 가지고 있어야 한다고 느꼈다.
또 코드를 직접 짜는 것보다도 설계(아키텍처)에 대한 지식이 오히려 중요해질 거라고 느꼈다. 구현은 AI가 해주더라도, 어떻게 만들어줘 라는 명령은 사람이 내려야 한다. 아이디어도 중요하겠지만, "구체적으로 이런 식으로 설계해 줘"(단순한 아이디어를 넘어선 개발적인 설계)라는 명령이 있어야 AI는 더 안정적으로, 더 퀄리티 있는 코드로 개발을 해나간다. 이를 위해선 설계(아키텍처)에 대한 지식이 있어야 한다고 느꼈다.
"단순히 모놀리식 구조로만 짜는게 아니라 MSA 구조가 필요한 서비스엔 MSA를 적용한다거나, 한 파일에 코드를 몰아넣는 것이 아닌 디버깅이 쉽게 코드를 구조화해서 파일을 나누는 것 (ex. mvc 구조), 동기가 아닌 비동기로 돌리는 것이 더 효율적인 구간을 찾고, 의도적인 컬럼 반정규화를 하는 등... " 몇 가지 예시로 적었지만, 구체적인 설계에 대한 관점 및 지식이 있을 때 AI는 더 고퀄리티의, 바로 활용할 수 있는 코드를 제시한다는 것을 느꼈다. 또한 설계에 대한 지식이 있다면 AI가 전달해 준 결과물을 가지고, AI와 논리적인 토론을 해갈 수 있다는 점에서 더 유용하다고 느꼈다. (ex. 여기는 이러한 방식으로 쓰는 게 디버깅에 더 효율적인 구조 아닐까? 등)
결론적으로 말하면, AI가 만든 결과물들을 더 잘 활용하기 위해서, 그리고 더 잘 지시하기 위해서 개발/설계 지식이 어느정도 필요하다고 느꼈다. 이전까지는 코드작성이라는 "구현" 부분이 개발에 도전하는 데 내게 가장 큰 허들이었다. (문법 하나하나를 익히고, 외우고, 알고리즘을 배우고 등). 이제는 AI가 코드작성이라는 구현에 대한 짐을 꽤 덜어주는 방향으로 바뀌고 있는 만큼, 그보다 윗단에 있는 설계에 대한 지식들, 개발 자체에 대한 지식들을 키워나가게 됐을 때 나한테도 개발이라는 무기가 생길 수 있을 거 같다는 생각을 하게 됐다. 그래서 틈틈이 개발/설계 쪽 공부를 좀 더 해보려고 한다. 교육을 들으며 관심이 좀 더 생긴 쪽은 특히 MSA라, 이쪽 관련된 내용도 틈틈이 공부해보고자 한다 ㅎㅎ
3. 시장에서 기획자의 역할 범위가 더 넓어지게 될지도?
이렇게 개발에 대한 허들이 낮아지는 상황 속에서, 시장에서 기획자/PM/PO에게 요구하는 역할 범위는 기존 보다 더 넓어질 것이라는 생각을 했다. 기존의 IT 기획자의 역량이라고 한다면 고객의 니즈를 발굴하고, 가설 검증을 해나가는 과정에서 MVP/프로토타입 등을 기획하고 실행하는 역량이 중요했다. 이를 위해 이전에는 피그마 등 디자인 툴을 통한 프로토타이핑, 혹은 노코드 툴을 통한 서비스 제작 등을 할 수 있는가? 정도가 기획자에게 하나의 플러스 요인이자 무기였다면, 이제는 생성형 AI를 활용해서 실제 생각하고 있는 MVP를 간단히 구현하고 테스트하는 역할까지도 요구하게 되지 않을까 생각했다.
최근에 들어간 회사에선 B2B AI 서비스의 PO부서에 배치 됐기에, B2B SI사업 쪽에 대해서도 생각해봤다. 일반 B2C 서비스가 아닌, B2B 사업 쪽에서도 형태가 약간은 다를 수 있어도 비슷한 흐름이 되지 않을까 생각했다. 최근의 B2B 사업에선 PoC, BMT 등의 용어로 B2B 고객들의 [1)제안요청서(RFP) 전달 전 or 2) 우선협상대상자 선정 후 계약 전] 제안 사업에 대한 시범 서비스/테스트 등을 요구하는 경우가 점점 많아지고 있다. (B2B고객 입장에선 문서 형태로만 멋들어지게 쓴 제안서가 아닌, 실제로 제대로 된 상품을 납품하고 수행할 수 있는 역량이 있는지를 테스트하기 위함일 거다.)
기존까지는 이런 PoC, BMT를 해나가는 게 개발부서만의 역할이고, 이를 준비하기 위해선 무조건 개발 부서의 도움을 받아야만 했을 것이다. 하지만, AI기술이 점점 고도화될수록 점점 이런 역할까지도 사업부서/기획부서 쪽으로 넘어올 가능성도 높지 않을까 싶다. (사업부서/기획부서에서도 인력을 뽑을 때, 간단한 PoC, BMT용 개발은 직접 돌릴 수 있는 인력을 원하게 될 수도 있지 않을까..?)
그런 점에서 이런 시장에서의 요구에 대응해 "개발은 내 영역이 아니야"라고 단정 짓기보단 계속 시도를 해나가야, 앞으로 좀 더 대체되지 않는 인력이 되지 않을까 라는 생각을 하게 됐다.
실제로 아래 사진의 링크드인 글처럼, 해외에서는 PO/PM 직무 대신 *엔지니어링 PM이라는 직무를 뽑는 기업들도 생겨나고 있다고 한다. (*엔지니어링 PM: 최소한의 MVP 기능을 AI를 활용해 디자인하고, 개발까지 하여 배포할 수 있는 PM)
이런 부분이 속도의 차이는 있더라도 점점 한국으로 넘어올 것이라고 생각한다.
물론 누군가에게 기획도 벅찬데 이것까지 해야 한다고? 느낄 수도 있을 거다.
하지만 한편으론 다르게 생각한다면 기획자에게 무기가 늘어난다고도 할 수 있지 않을까?
이전엔 아이디어에 대한 검증을 위해서 굉장히 많은 시간과 비용이 들었다. 또한, it 서비스의 경우 MVP를 돌리고 싶어도 개발자에게의 의존성이 있는 경우들도 꽤 있었다. 그 허들을 1차적으로 낮춰줬던 게 디자인 프로토타이핑 툴(ex. 프로토파이, 피그마 등)이나, 노코드 툴(ex. 버블, 윅스 등)이었다면 이제 그다음은 AI 코딩 툴이 되지 않을까? 지금보다도 더 빠르고 쉽게 기획자 혼자서도 검증을 해나갈 수 있게 바뀌는 것이기에 기획자에겐 도전이자 하나의 기회가 생긴 거라고 생각한다. (노력할 수밖에 없지 뭐 ㅎㅎ)
4. 기획자일 땐 쉽게 말했던 "잘라서 나가자", 직접 개발자의 입장이 되어보니...
지금까지의 나는 계속 스타트업, 창업 등의 영역에서 기획자로 있었다 보니 "(핵심기능 우선으로) 잘라서 나가자"라는 말이 나에겐 너무 익숙하고, 소프트웨어를 만들어가는 데 달고 살았던 말 중에 하나였다.
한정된 리소스가 있는 스타트업 환경에선 소위 말하는 "린 스타트업"처럼, 일단 서비스를 내보내고 고객의 반응에 따라 서비스를 점차 보완해 나가는 방식이 중요했기 때문이다.
기획자의 관점에선 그래서 "잘라서 나가자"라는 말이 너무나도 당연했고, 그런 말들을 개발자에게 쉽게 해 왔던 거 같다.
하지만 개발자의 관점에선 그게 쉽지만은 않다는 걸 이번 프로젝트를 통해 느꼈다. 직접 개발을 해보니, 어느 정도 수준까지 만족을 하고 다음으로 넘어가야 할지에 대한 선이 정말 어려웠다. (머릿속으로는 마이너 한 부분인걸 알지만, 실제 개발하는 사람 입장에선 그 디테일들을 포기하고 넘어가기 더 힘들달까...). 물론 내가 약간의 완벽주의 성향이 있어서 더 그랬던 거일 수도 있지만, 어쨌든 프로덕트를 직접 만드는 메이커인 개발자 입장에선, 어느 선까지 만족하고 넘길지를 정하기 어렵다는 걸 느꼈다. 그래서 조금은 쉽게 "잘라서 나가자"라고 개발자들에게 얘기했던 나 자신의 과거 모습을 반성을 하는 기회였었다. (나는 쉽게 말했었지만, 직접 그 얘기를 듣는 개발자들에겐 어려운 사항이었겠다...라는 느낌)
또 한편으론, 이런 "선"을 잘 정의하고 개발해 나가는 사람들이 진짜 잘하는 사람이라는 생각도 느꼈던 거 같다. 조금 더 중요한 게 무엇인지, 그에 따라 개발하는 과정에서 덜 중요한 부분에는 조금은 욕심을 낮출 수 있는 사람들. 그런 사람들이 진짜 실력 있는 사람들이고, 어찌 보면 주니어와 시니어를 나누는 기준이 될 수도 있겠다는 생각을 했다.
그리고 직접 개발을 해보며, 돌아가게끔 하는 것과 실제로 유저에게 배포할 수준으로(여러 예외케이스들을 다 고려하고 처리) 만드는 것의 차이는 작업 속도, 작업 범위 차이가 엄청나게 크다는 걸 느꼈다. 조금 더 개발자들의 개발일정 관련 시각을 느낄 수 있던 기회였달까. 기획자입장에서 단순해 보이는 기능이 있을 때, 개발자들은 생각하는 것보다도 좀 더 많은 개발일정을 요구하는 경우가 꽤 있었다. 개발자 입장에선 구현자체는 단순할지라도 배포할 정도까지 완성도를 끌어올리는 건 다른 문제이기 때문에 더 그랬지 않나 싶다. 이런 개발자 관점의 시각을 느껴볼 수 있는 기회가 이번 프로젝트였다.
5. 세심한 기획자가 되기 위한 개발문서/설계/인프라 이해도 중요성
이전까지는 PO/기획자로 일했다곤 해도 ERD, API 명세 같은 개발문서나, 코드작성 부분까지 내가 건드리진 않았다. (스타트업에서 10개월간 일할 때도, 사이드 프로젝트로 앱을 만들 때도) 이번 프로젝트를 진행하며 ERD/API 명세서와 같은 개발문서는 물론 직접 개발까지 진행해 보며, 실제 개발 구조까지 고려해 기능명세를 작성하는 것과, 상위 기획정도로만 기능명세를 작성하는 것은 큰 차이가 있다는 것을 알게 되었다. 개발하는 입장에서 마주하게 되는 난이도, 소요시간(소통비용으로 인한) 차이가 정말 크다고 느꼈다.
단순히 "이 버튼을 눌렀을 때 주문이 들어가야 해" 정도로만 정의하는 게 아니라, DB 구조에 대한 이해를 통해 그때 프론트엔드에서 백엔드 쪽으로 넘겨야 하는 데이터들은 어떤 데이터들이고, 그 데이터들은 프론트엔드 화면 어디서 저장하고 있기에 백엔드 쪽으로 줄 수 있고, 그 과정에서 어떤 API를 어떤 식으로 작동시킬지 등을 같이 정의하는 건 큰 차이가 있다고 느꼈다. 개발자가 바로 개발할 수 있는 수준과, 한번 더 물어봐가면서 개발에 필요한 요소들을 재정의 해야 하는 수준의 차이랄까. 물론 실제 기획 시에는, 개발자들에게 구체적 구현의 자유도를 맡기는 부분이 많기 때문에 너무 디테일하게 지정을 하지는 않겠지만 (오히려 더 효율적인 구조로 코드를 짤 수 있는 기회를 날리게 되므로), 적어도 뒷단에서 어떤 구조로 돌아가고 있는지에 대해 이해를 하고 있어야 개발자들에게 더 세심한 기획서를 줄 수 있을 거다. 기획자 선배들이 많은 책이나 강의에서 왜 기획자들에게, 개발은 못하더라도 "정보의 흐름이 어떻게 오고 가는지"를 잘 정의해야 한다라고 하는지를 직접 개발문서를 만들고 그를 바탕으로 개발해 보며 느꼈던 거 같다.
또 여기서 한 발짝 더 나아가서, 개발자 친구들과 팀프로젝트를 진행하는 과정에서 설계/인프라적인 관점의 중요성도 크다고 느꼈다. 저번 글과 이번 글에 주로 기재한 내용인 바이브코딩으로 5일간 테이블오더를 만드는 개인 프로젝트를 완료한 이후엔, 약 3주 간 AM + 인프라 part 교육을 들었었다. 그 후에 동기들과 팀프로젝트를 진행할 기회가 있었다. 그때는, 내가 5일간 만들었던 테이블오더 서비스를 MSA 구조로 전환시켜 애저 클라우드를 활용해 배포까지 하는 게 과제였다. 이때 인프라적인 영역 (CI/CD, 카프카 활용, API G/W, 도커/쿠버네티스) 은 개발자 동기들이 주로 했었는데, 만약 내가 3주간 AM + 인프라 part 교육을 아예 안 들었다면 해당 영역은 아예 무지한 영역이었을 것이며 더 그냥 방관만 했었을 수도 있겠다는 생각을 했다. 특정 로직을 kafka를 활용한 비동기식을 처리하는 게 좋을지 그냥 동기 구조를 유지할지, 어떤 기준으로 micro service들을 나눌지, 지금 우리 서비스에서 인증/인가 등이 필요할지, 우리 서비스의 DB는 어떻게 관리하고 이미지 데이터들은 어디에 저장할지, Azure 클라우드는 어떻게 활용할지 등. 직접적인 구현은 다른 영역이라고 하더라도, 설계 과정에서 개발자들이 해당 아키텍처/인프라 논의를 해감에 있어 비즈니스 요구사항을 잘 아는 입장에서의 의견을 전달하기 위해선 어느 정도의 지식은 필요하다고 느꼈다.
PM이 어느정도 이해도가 있어, 개발자들과 인프라/아키텍처 관점에서도 토의를 할 수 있냐/없냐 자체가 굉장히 중요하달까. 결국 과 투입이 아니라, 우리가 하려는 서비스/비즈니스에 맞는 수준을 구축하는 게 중요한 거니까. (ex. 굳이 MSA로 안 나눈 게 더 효율적인 곳도 있을 수 있고, 그렇게 까지 로그인이 필요한 서비스가 아니라 인증/인가를 안 만드는 게 나을 수도 있다. 또한 정석적으론 이미지를 blob 스토리지에 나눠서 저장하는 게 좋을 수도 있지만, 개발 속도상 어쩔 수 없이 이번 시연 범위에선 그 부분을 포기하자고 의사결정할 수도 있을 것이다.) 이런 논의와/의사결정을 위해서 인프라/아키텍처 적인 지식도 중요하다고 느꼈다.
또 특히, 지금 내가 몸담고 있는 B2B SI 사업의 경우엔 고객사 미팅을 나갔을 때, 고객사의 현업부서가 아닌 IT 부서들을 상대해야 할 경우도 많다. 이때 IT 담당자들은 단순히 기능적 차원뿐 아니라, infra 적인 차원, 아키텍처 적인 차원들도(sw/hw 구성도, 그에 따른 견적 등) 정말 많이 물어본다. 또 수주를 위해 제안서를 작성하는 과정에서도, 아키텍처/인프라 적인 차원까지 작성이 필요하다. 물론 이런 부분은 해당 부분 전문가들이 또 있긴 하지만, B2B AI/IT 서비스들을 계속해나갈 거라면 이런 아키텍처/인프라 차원을 아예 놓는 것이 아닌 전문가들과 같이 논의할 수 있는 수준까지 끌어올려보고 싶다는 생각을 하게 됐다.
6. 어느 공간에서도 못할 건 없다
이번에 프로젝트를 진행하며 가장 크게 느낀 건 어느 공간에서나 최선을 다하면 못할 건 없다는 거였다.
1) 5일간 진행해 만든 개인프로젝트, 그리고 2) 3주 뒤 진행된 팀프로젝트에서 모두 1등이라는 성과를 낼 수 있었다.
처음 입사할 때, 대기업에서 일해봤던 경험은 없었고 스타트업 영역에서만 활동했던 나였기에 마음속에 약간은 "대기업에서도 잘할 수 있을까?"라는 두려움이 없진 않았던 거 같다. 또, 개발을 많이 해봤던 친구들도 있었기에 2달간의 개발교육에서 잘 적응해 나갈 수 있을까 하는 생각도 있었다. 그래도 최선을 다해서 교육을 듣고, 프로젝트에서 최선을 다해보려 했다.
그 결과로써, 개인/팀프로젝트 모두 1등이라는 작은 성공을 얻어볼 수 있었다. 그 과정에서, "어느 공간에서든 내가 해오던 것처럼 최선을 다한다면 못할 건 없다. 어느 공간에서든 최선을 다한다면 성취를 이루고 인정을 받을 수 있는 거구나"라는 마음을 얻을 수 있게 된 기회였던 거 같다.
물론 실제 업무는 이 교육과는 상황이 많이 다를 것이다. 상대적으로 개인의 노력으로 성취를 이룰 수 있는 교육공간과는 달리, 실제 업무공간에서는 다양한 외적인 상황들이 있을 거다. 또, 아무래도 신입이다 보니 많이 미숙할 수밖에 없기에 마음만큼 잘 안 되는 경우도 많을 거다. 그래도, 이번 교육기간/프로젝트 기간 동안 거뒀던 작은 성공은 어느 공간에서든 최선을 다하면 된다라는 걸 깨닫게 해 줬던 거 같다.
부서에 가서도 결과를 떠나서, 나는 내가 컨트롤 할 수 있는 영역인 "나 자신이 최선을 다하는 것"에만 집중해 봐야겠다.
마무리하며
이번 글에선 신입사원 개발교육에서 바이브코딩을 활용해 프로젝트를 진행해 보면서 느꼈던 점들에 대해서 적었다. (항상 그렇지만쓰다 보니 꽤 길어져 버렸다...ㅎㅎ)
앞으로 어떤 내용으로 더 블로그를 써 내려갈지는 고민이지만, 기술공부를 한 내용이 됐건, 회사생활에서의 느낀 것이 됐건 어떤 소재가 됐건 글은 계속 종종 써 내려가보려 한다.
(읽어주셔서 감사하고 다음 글에서 뵙겠습니다..!!)
Profile: