AI 유행 따라가보기 1편 - 프로젝트 기획과 선입견 깨기

목차

 

※ 제 생각이나 편향이 많이 들어가 있는 글입니다. 사실이나 일반적인 개발자분들의 생각과 다를 수 있습니다.

 

서론

  난 현재 백엔드 개발자로 일을 하고 있다. 경력상 주니어 중간~끝지점 정도라고 보면 될 것 같다. 구현 뿐 아니라 일부 시스템 아키텍쳐 설계나, 일부 인프라도 다루고 있다. 최근까지 난 AI를 사용한 개발에 다소 회의적인 입장이었다. 이건 내가 그동안 경험해본 AI 사용 경험에 따라 생겨난 내 선입견이다. 그래서 특히 ‘바이브 코딩’ 관련해 ‘100% 바이브 코딩으로 짰어요’ 같은 내용은 바이럴 마케팅 정도로 생각하고 있었다.

 

  하지만 이런 선입견은 자칫 “개발은 어셈블리로 해야지 C 같은 편한걸로 하면 안돼!” 이런 -꼰- 느낌이 될 수 있다. 시점상 현재가 머신러닝에서 LLM 쪽으로 유행이 넘어오면서 진입장벽이 낮아졌고, CURSOR 같은 협업 툴도 완전히 유행으로 자리잡은 시점이다. 이 시점에서 직접 AI 관련 프로젝트를 진행해보고, AI와 협업을 해보며 직접 판단을 해보기 위해 프로젝트를 하나 기획했다.

 

  이 글에서는 내 AI에 대한 생각 및 내가 AI 유행을 따라가보고자 진행중인 프로젝트에 대해 얘기해보고자 한다.

 

배경

  AI 쪽에 아예 관심히 없었던건 아니었다. 약 2년전 정도에도 관심을 가지고자 인강 등을 찾아보았다. 당시 대부분 LLM 보다는 머신러닝쪽에 대한 얘기였던걸로 기억한다. 인프런에서 3~4편정도 보면서 난 그냥 나와 ‘다른 업종’ 정도로 인식하고 넘어갔다. 백엔드 개발자와 기술 스택이 달라보였기 때문이다.

 

  요즘엔 사내에서도 그렇고, 여러 방면에서 AI, 특히 LLM을 중심으로 빠르게 유행이 퍼지는 것 같다. 머신러닝에 비해 ‘백엔드 개발자’인 내가 보더라도 활용할 수 있는 영역이 많아보였고, 진입장벽도 낮아보였다. 또한 ‘바이브 코딩’ 등 개발 자체에 대한 LLM과의 협업도 좋아보였다.

 

  내 경우 chatgpt는 2023년 2월, copilot은 2023년 5월부터 꾸준히 유료로 구독하며 사용중이었다. (copilot은 2025-07 부터 사용중단)

 

  기존 왜 개발에 AI 사용이 다소 회의적인 입장이었을지 생각해보면, 초기에 copilot은 내 입장에서 뭔가 반복적인 작업에 유용한 정도라고 판단했다. 난 신입때부터 ‘노가다는 컴퓨터에게’ 마인드였기 때문에, 단순히 ‘매크로 만드는 수고를 덜어준다’ 정도의 느낌이었다. 물론 함수 껍데기 작성하면 자동완성 형태로 구현부를 만들어주긴 했었지만, 솔직히 단순한 코드는 내 입장에서 크게 의미가 없었다.

 

  또한 초기 chatgpt는 그냥 ‘재밌는 장난감’ 느낌이었다. 하지만 점점 발전하고, 최근 몇개월간 사용하면서 느낀 바로는 가끔 거짓말도 하지만(할루시네이션), 논리적 판단이 사람보다 매우 뛰어나다는 점이 좋았다. 하지만 역시 마찬가지로 내 개발에 사용할 정도의 수준은 아니라고 생각했다. ‘단순히 동작하는 코드’는 사실 원래도 쉬웠다. 내게 필요한건 ‘이렇게 짠’ 명분이 있고, 설계적으로 아름다우며, 전체적으로 일관성이 있는 코드다. 그래서 코드쪽으론 거의 쓰지 않고 그냥 개인 생각 정리용도, 즉 사고 파트너로써 사용했다.

예시 : 질문은 LLM이, 답은 내가 - LLM을 활용한 사고확장 자기계발 방법 추천 (Prompted by AI, Answered by Me)

질문은 LLM이, 답은 내가 - LLM을 활용한 사고확장 자기계발 방법 추천 (Prompted by AI, Answered by Me)

 

 

AI 유행을 따라가보기 위한 프로젝트 기획

  뭐 내가 평소에도 개발 관련하여 유행에 빠르게 따라가는 편이 아니란건 스스로도 알고 있다. 아주 좋게 말해야 신중한거고, 일반적으론 뒤쳐진 셈이다. 어쨌든 변화가 빠른 시기에 2.5년 전의 선입견으로 멈춰있을 순 없으니, 선입견을 없애기도 하고 반강제성을 가지고 내가 공부할 수 있도록 AI 관련 서비스를, 주로 AI를 활용하여 코딩을 해볼 생각으로 기획안을 만들었다.

 

  통과되면 업무시간에 진행할 수 있는거고, 통과 안되면 토이프로젝트로 진행할 생각이었다. 주제는 실제 회사에서 서비스로 쓸 수 있을만한 시스템으로 구성했다. 사실 토이프로젝트로 진행되었다면 전체 아키텍쳐를 공유하고 진행하며 코드 공유도 가능했겠지만, 기획안이 통과되어 버리면서 구체적인 공유는 어렵다.

 

기획안의 명분은 이하와 같았다.

• 대외적 : 신규 기술스택 및 AI 관련 개발 내제화. 또한 실제 사용할 수 있는 플랫폼 서비스에 대한 R&D.
• 대내적 : AI 유행 따라가고 내 선입견에 대해 직접 판단하보기 위해 내가 공부할 명분 만들기, 사실 그냥 재밌을 것 같았음. 즉, 업무시간에 사심 채우기

 

  기획안은 3차 개발 계획으로 되어있었는데, 1차는 MVP(최소 기능 제품)를 만들어 2,3차를 더 진행해도 될지 판단하기 위한 목적이다. 2차는 실제 서비스화, 3차는 스택 고도화로 잡았다. 1,2,3차 각각 일정 끝난 후 한방에 보여주면 기대보다 실망이 클 수도 있다. 그래서 매주 관심있는 다른 팀들을 초청해 스프린트 리뷰를 하기로 했다.

 

  1차는 우선 꼭 혼자 해보고 싶었다. ‘대내적’ 명분에 따라 내가 공부를 할 수 있어야하기 때문이다. 그래서 기획안에 인력 구성을 ‘제안자 황세영이 진행’ 라고 박아두었다 ㅋㅋ 속 뜻은 “이거 초반은 혼자 좀 해볼께요” 였다. ‘업무 환경 요청’으로 ‘기존 업무는 유지하나, 해당 기간 50%이상 기획안 개발에 집중할 수 있는 환경’ 이라고 적어두었다. 역시 속 뜻은 “당분간 건드리지 말아주시죠” 였다. ㅋㅋ

 

  사실 윗분들이 쓰시는 제안서나 기획서 이런거에 비하면 초라한 기획서지만, 다행히 통과되었고 현재 2주차 스프린트 리뷰까지 진행했다.

 

축약된 아키텍처

  축약된 아키텍처는 위 이미지처럼 생겼다. 실제론 MVP 더라도 주변에서 "혼자 하기 힘들껄요?" 소리 나올 사이즈긴 했다.

간단히 말하면, LLM을 컴포넌트로 보고 내 아키텍처에 어떻게 녹여낼 것인가가 핵심 과제였다. 이를 위해 도메인 레이어의 다양한 동작을 수행하기 위해 다양한 종류의 저장소를 사용했다. AI model을 사용하는 도메인도 있고, RAG를 사용하는 도메인도 있고 이런식이다. 즉 저 감쳐둔 도메인 레이어부분이 사실 꽤 크다.

 

프로젝트 진행

우선, 엄청 재밌다 ㅋㅋ

(조언을 구하기위해 AI 리서쳐인 친구와 대화 중 내 발언)

 

  사실 사이드 프로젝트로 할 부분을 업무시간에 할 수 있다는게 가장 크다. R&D 이므로, 아무런 제약 없이 사양 좋은 컴퓨터를 받아서 전체적으로 시스템 구성부터 진행했다. 그리고 최대한 LLM을 활용해 코딩을 하며 (현재 CURSOR + GPT5 / IntelliJ + ClaudeCode / IntelliJ + Gemini code assist 등 다양하게 비교해보고 있다.) 마음대로 진행하고 있다.

 

  실제로 재미를 느끼며 하다보니, 생각보다 진행이 엄청 잘되고 있다. 시연마다 호평을 받고 있어서 나도 더러 더 재밌어지는 것 같다. 솔직히 현재 시점에서 다른 복잡한 시스템보다 제일 걱정되는건, 이후 React+ts로 만들겠다고 한 프론트엔드 부분이다. 사실 프론트엔드 지식이 거의 없다. 만들 순 있는데 그냥 신입수준이다. 백엔드만 해도 시스템 아키텍처, 성능 최적화, 보안, 인프라 등 깊이 파야할 분야가 산더미다. 그래서 난 의도적으로 프론트엔드 보다는 벡엔드에 집중하는 편이다. 이번 프로젝트에서는 그 부분을 LLM이 얼마나 메워줄 수 있는지도 기대된다.

 

  진행 중 기록은 다음과 같은 방식으로 정리해보고있다. 필요할 때 마다 카테고리는 추가하고 있는데, ‘바이브 한계점’, ‘바이브 좋았던점’, ‘내 생각’, ‘학습 테스트’, ‘코드/구현’, ‘코드/리팩토링’, ‘리서치’, ‘기획 및 설계’, ‘아이디어’, ‘인프라 구축’ 으로 나누어서 각각마다 ‘사용AI’, ‘기술스택’, ‘설명/요약’, ‘인사이트’, ‘상세내용’을 작성중이다.

 

예를들어 ‘바이브 한계점’ 부분 중 하나의 ‘설명/요약’은 다음과 같다.

- 요청 : 프론트엔드와의 접점 API 생성 요청
- 결과 : 기존 동일한 기능을 하는 API가 이미 있음에도, 새로 Controller와 Service를 만들어서 중복된 동작 생성.
- 예상원인 : 화면상에 유사도, 점수를 출력해달라고 한 요청을 맞추기 위해, 기존 API를 바로 안쓰고 새로 만든 것으로 보임. 

 

  물론 사내 룰셋을 적용하면 많은 부분에서 해결이 될 수 있다. 하지만 내가 느껴보고 싶어서, 우선은 아무런 룰 설정 없이 해보고 있다. 이후 중간정도 넘어가면 룰셋 적용해서 어떠한 문제점이 해결되는지 확인하는 것도 이번 프로젝트 진행 중 내 목표다.

 

  이런식으로 하나씩 기록을 쌓아가다보니, 서론에서 말했던 내 선입견들이 하나씩 깨지거나 혹은 더 견고해지는 것을 느낄 수 있었다.

 

2주만에 내 생각은 변했을까?

  현재 2주정도 기획한걸 만들어보고 있다. 기존 회의적인 입장에서 내 생각은 변했을까?

 

  확실히 변했다. 일단, LLM이 2년반 전 내가 chatgpt를 처음 쓸 때 보다 현재 많이 잘한다. ‘아무튼 동작하는 것’을 기준으로 하자면, 기본적인 개발 업무를 독립적으로 수행할 수 있는 수준 정도는 충분히 되는 것 같다.

 

  바이브 코딩도 단순 바이럴이 아닐 수 있다는 점도 느꼈다. 다만 조건이 붙는데, ‘전체 서비스에 대한 요구사항을 한방에 넣고, 한방에 프로젝트 코드가 딱 하고 나오는’ 수준은 아직은 안된다고 생각한다. 적어도 코드 리뷰에서 ‘왜 이렇게 짰는지’ 질문할 수 있고, 그 답변을 평가할 수 있는 수준의 개발자가 그냥 ‘자기가 직접 코딩안하고, LLM에게 세세하게 명령해서 개발한다’라는 개념에서라면 90%이상의 바이브코딩도 충분히 가능하다고 생각된다.

 

  다만, 결국 '특정 부분'에 대한 코딩은 뛰어나지만, 전체 설계구조에 대해서는 아직인 것 같다. 사용자가 설계적 문제점이나, 도메인 로직의 세세한 사항을 지적해주지 않을 경우 LLM이 먼저 능동적으로 판단할 수 없는 부분들이 많이 보인다. 또한, 사용자가 검증하지 않고 생성된 코드를 바로 사용할 경우, 전체적으로 코드 퀄리티가 떨어지고 어떠한 장애가 발생하게 될지 알 수 없게 될 것 같다.

 

  그래서 어떤 부분은 기존 생각이 더 확고해졌다. 결국 예전이나 지금이나 중요한건 변하지 않았다는 점이다. 원래도 ‘동작만 하는 코드’는 쉬웠다. 중요했던건 설계능력, CS 지식, 논리력 이런것이었다. 현재 AI와 협업하여 코딩을 하는 시대에도, 결국 중요한건 설계능력, CS지식, 논리력 이런 것들인 것 같다.

 

  한편으론, 현재 대학생들이 좀 불쌍하다는 생각이 들었다. 본인의 실력을 쌓기 전에 너무 좋은 도구를 빠른 시기에 얻어버렸다. 직접 혼자서 공부하면서 혼자서 뭔가를 하면 현타올 것 같다. 내가 더 열심히 하는데 왜 점수가 안나오지? 이런 상황에 빠질 것 같다. 하지만 결국 살아남는건 ‘AI라는 편하고 강력한 도구를 사용하면서도, 그 결과물을 비판적으로 검토하고 더 나은 구조를 제시할 수 있는 기본기를 갖춘’ 학생일 것 같다. 하지만 이건 쉽지 않다. 그리고 이 얘긴 대학생 뿐 아니라 나한테도 적용되고, 현재 일을 하는 사람들에게도 적용된다고 생각한다.

 

  결국 AI도 하나의 ‘기술 스택’일 뿐이라 생각한다. 기술과 능력은 다르다. 도구에 끌려가는 사람보다는(기술 지향), 도구를 잘 쓰는 사람이 되는게(능력) 더 중요하다고 생각한다.

 

마치며

  AI와의 협업이 생각보다 엄청 뛰어나서 놀라웠다. 하지만 역시 중요한건 변하지 않았다는 점도 다시금 마음 속에 새겼다.

 

  우선은 2주 정도 진행해보며 내 생각을 써봤다. 사내 업무로 잡히면서, 실제 진행 과정을 블로그에 공유하기 어렵게 된 점은 아쉽긴하다. 그렇더라도 내 생각이나 LLM과의 협업 단계의 좋았던점이나 별로였던 점은 이후 공유할만한 부분인 것 같다. 다음번엔 이런 내용을 더 중점적으로 공유해볼까 한다.