들어가며
최근 AI 코드 에디터를 업무에 자주 활용해 볼 수 있는 기회가 제공되어 커서를 이리저리 체감해 볼 수 있었습니다. 그중 Notepads(이하 노트패드)라는 기능을 마주하게 되었는데, 아직 베타 버전이다 보니 인터넷을 검색해도 정보가 많지 않아 어떤 기능인지, 어떻게 활용해야 좋은지에 대해 궁금한 점이 생겼고 실무를 통해서 나름의 방법으로 이용해 본 경험을 공유해 보려고 합니다.
또한, AI와의 협업이 어떠했는지, 개발자의 입장에서 만나본 바이브 코딩의 경험은 어떤 느낌이었는지도 공유해 보려고 합니다.
노트패드를 경험해보자
아래는 최근 작업을 수행하면서 노트패드를 활용해 본 경험 사례입니다. 이 경험담이 올바른 사용법이 아닐 수 있기에 참고 용도로만 읽어주길 바랍니다.
경험 1. 플러그인으로 추출한 디자인 시스템의 점검 문서로 활용.
PXD의 피그마 디자인 시스템이 있습니다.
프로젝트별로 주요 컬러, 타이포그라피 배리에이션 등이 정의된 파운데이션 문서를 발행하기도 하죠.
그리고 XE 그룹은 자체 제작 플러그인을 통해서 발행된 파운데이션 문서의 토큰 값을 프로젝트 컨벤션에 맞는 SCSS 변수로 변환 추출합니다. 해당 추출 값들은 보통 아래와 같은 형식으로 변환되죠.
현재 진행 중인 프로젝트의 경우 테마 변환이 필요하여 scss 변수뿐 아니라 테마에 맞는 자체 컬러 값을 가지는 css3 변수도 필요했습니다. 그리하여 추출된 내용들을 scss 폴더의 _variables.scss 파일로 저장하고, 테마 변환용 스타일 역할을 담당할 _theme.scss 파일에도 세팅했습니다.
// _variables.scss
$dark-gray-0: #131313;
$dark-gray-100: #1f1f1f;
$dark-gray-200: #2d2d2d;
$dark-gray-300: #3d3d3d;
$dark-gray-400: #505050;
$dark-gray-500: #666;
// ...중략// _theme.scss
// 라이트 테마 컬러 맵
$theme-light: (
--bg-basic: to-rgb(#dadde1),
--bg-brand-primary-default: to-rgb(#03a94d),
// 중략
)
// 다크 테마 컬러 맵
$theme-dark: (
--bg-basic: to-rgb(#3d4146),
--bg-brand-primary-default: to-rgb(#03c75a),
// 중략
)이렇게 세팅이 된 이유는 scss 변수의 경우 컴파일 시점에 값이 정해지므로 동적으로 테마를 변경하는 방법에 부적절했기 때문입니다. 관리 포인트가 늘어나는 것은 어쩔 수 없었지만 테마 변화 대응뿐 아니라 scss 변수를 직접 사용해야 할 케이스에도 유연하게 대응하고자 결정된 사항이었습니다.
이후, 정의된 각 값들이 테마별로 올바르게 매칭되고, 오타는 없는지, 컨벤션에 맞게 잘 네이밍 되었는지, 변숫값에 맞는 컬러 코드가 잘 들어가 있는지 최종 점검을 진행했는데요. 오타, 중복 코드 점검만을 위해서는 커서에게 해당 파일만 맨션을 걸고 요청을 하면 제대로 잘 진행되었습니다.
하지만 각 변수의 컬러 값들이 피그마에 정의된 컬러와 잘 일치하게 적용되었는지는 두 가지 파일의 비교만으로는 제대로 된 점검을 진행할 수 없었죠. 게다가 추출한 문서는 몇천 줄이나 되는 방대한 내용을 담고 있었기에 chat을 통한 대화만으로는 한계가 있었습니다.
이런 경우 노트패드가 큰 도움이 되었습니다. 원문 링크로도 접근이 어려운 제3의 문서를 기록해두고 커서가 참조할 수 있게 해주면 간단히 해결되는 문제였죠!
경험 2. 복잡한 요구사항은 노트패드에 정리하기
AI를 이용해서 코드 생산을 해본 경험자라면 누구라도 빈번하게 겪는 상황이죠. AI가 내 요청사항을 정확하게 인지해서 결과물을 내놓는다면 괜찮지만 대부분의 상황에서는 여러 번의 시행착오를 거치게 됩니다. 또는 내 요청사항을 비꼬아 해석하거나 다른 코드와의 맥락을 파악하지 못한 채로 코드를 생산해서 전혀 다른 방향의 결과물을 내놓는 경우가 많습니다.
특히, 미사여구가 많고 표현이 다양한 한국어의 특성은 이 문제를 더욱 도드라지게 만드는 경향이 있어 보입니다. 질문이 복잡하면 복잡할수록 이 현상은 더욱 심해지죠.
이렇게 한번 잘못된 AI 코딩이 누적되면 나중에는 되돌리기에도 힘든 지경까지 이르게 되고 결국 이전 커밋으로 롤백 해야 하는 경우도 종종 있습니다.
이런 경우에는 노트패드를 활용해서 내 요청 사항을 상세하게 기록하고 AI가 맥락을 잘 파악할 수 있도록 해주면 도움이 많이 되었습니다. 노트패드에는 링크도 걸어둘 수 있고 md 문서 형식으로 작성도 가능하며 샘플 코드를 삽입하여 올바른 예, 나쁜 예를 구분해 줄 수 있는 등 요구사항을 세분화해서 정리할 수 있기 때문에 chat에 장문의 텍스트로 질문하는 것보다 AI가 훨씬 명확하게 요구사항을 이해할 수 있습니다.
AI와 함께 개발하기
잘 쓰면 너무 좋은 AI
반복 대량 생산에서는 확실히 비약적인 생산량 증가를 가져옵니다. 직접 생산하기 어렵거나 번거로운 것들 (예를 들면 API 응답 더미 데이터 같은) 을 쉽게 만들어낼 수 있어서 좋았습니다. 이런 종류의 산출물들은 번거로움에 비해서 실제 개발 코드의 부피에서 차지하는 비중이 적기에 제작을 건너뛰거나 소량으로만 다루었었는데 AI를 이용하면 대량 제작이 가능해져서 좀 더 로직적인 부분에 집중할 수 있게 됩니다.
또한, 단순 코드 정리에도 탁월한 성능을 보여주고 디버깅 준비도 잘 도와주기도 하죠. 스토리북 파일 생성이라든지 각종 케이스에 대한 샘플 제작에도 효과적이라고 생각됩니다.
그리고, 풀리지 않는 문제를 해결하기 위해 인터넷을 검색하는 시간을 효과적으로 줄일 수 있었습니다. 사실 상, 이 부분이 AI와의 개발에서 가장 큰 이점이지 않을까 싶네요.
여러모로 AI가 없었다면 비효율적으로 사용되었을 시간들을 아낄 수 있다는 점에서 너무 좋았습니다.
개발자 입장에서 경험해 본 바이브 코딩
모든 코딩을 인간의 말로 진행할 수 있다는 것은 큰 매력이긴 합니다. 진정한 입코딩을 이루었다고 볼 수 있죠. 머릿속에 떠오르는 설계와 모양을 설명하는 것만으로도 프로그래밍이 가능하다는 점은 업계 전반을 뒤흔들기에 충분했습니다. 저도 대세의 흐름에 따라보고자 AI와 함께하는 입코딩을 십분 경험해 보기로 했습니다. 그리고, 정말로 개발 지식이 전무한 상태에서도 바이브 코딩만으로도 개발이 가능할지 스스로 실험해 보기로 했습니다.
바이브 코딩의 편리함
우선, 빠르게 아이데이션 할 수 있는 기반을 만들기에는 더없이 좋았습니다. 기획/디자인의 요구사항을 프로토타입으로 만들어 의사결정을 빠르게 할 수 있도록 도울 수 있었습니다. 이런 양상은 개발 진행을 아주 편리하게 도와주기도 했는데요.
“윈도우 스크롤을 감지해서 구성요소들에 인터렉션을 부여할 거야.”라는 요청사항을 던지니 AI가 기특하게도 자주 사용되는 스크롤 이벤트 유형을 알아서 커스텀 훅으로 만들고 스크롤 감지 이벤트를 컨텍스트로 제작해 줍니다. 코드 검증이 필요하긴 하지만 요청한 내용에만 머물지 않고 사용자가 어떤 작업을 하려는지 예측해서 좀 더 필요하지 않을까 싶은 결과물을 추가로 생산한다는 사실에 놀라웠습니다.
“개발이 용이하도록 곳곳에 콘솔 로그를 확인할 수 있게 해줘.“라고 추가로 요청하니 아예 개발 모드에서만 작동하는 디버깅 패널을 만들어서 화면에 띄워주네요.
그리고 PXD 포스팅에서도 볼 수 있듯 소규모 정적 사이트나 라이브러리, 플러그인 등은 바이브 코딩만으로도 온전하게 제작은 가능하죠. 기획자나 디자이너의 손길이 필요하지만 도움을 받지 못하는 경우에도 AI가 대신 역할을 해주기도 했습니다. 괜히 요즘 난리가 아니구나 하는 생각이 많이 들었습니다.
개발 지식을 몰라도 정말 앱을 만들 수 있나요?
그런데, 진짜로 개발 지식이 없어도 온전한 프로그램을 만들어서 상용화할 수 있을까 하는 의문에는 좀 회의적이었습니다.
우선, 복잡한 UI나 사용자 경험 측면을 고려하여 머릿속에 떠오르는 개념을 AI에게 설명하는 것부터가 어려웠습니다. 이건 개개인의 차이가 있겠지만, 필자의 경우 AI에게 효과적으로 요청하기 위해서 고민을하는 시간이 더 길어졌습니다. 내 시간을 절약하기 위해 사용하는 건데 이를 위해 고민하는 시간이 더 소요되는 것에 아이러니함을 느꼈습니다. 나는 개발자인데 작가가 된 거처럼 AI를 이해시키기 위한 효과적인 어휘와 문장을 고민하는 이 상황에 가끔은 실소가 나오기도 했습니다. 그리고 내 질문을 잘못 이해한 경우를 바로잡기 위해서 AI와 씨름을 하는 상황은 사람을 매우 피곤하게 만들었습니다. 차라리 전체적인 로직은 직접 설계해서 기반을 마련해 주고 AI와 함께 부분 부분 기능을 다듬어 가는 것이 훨씬 나았습니다.
그리고, 개발 규모가 커지면 커질수록 AI가 참조해야 하는 컨텍스트의 범위가 넓어지고 유연한 대처가 쉽지 않았습니다. AI는 갈수록 멍청해지고 이전 질문도 기억하지 못하는 등의 상황도 벌어집니다. 오류를 잡겠다고 멀쩡한 부분을 손대는 바람에 잘 되던 기능도 망가트리는 경우도 심심치 않았죠. 이러한 상황에서는 개인의 개발 지식 보유 유무가 중요하다고 느껴졌습니다. AI가 실수를 했거나 놓친 부분이 있거나 많은 위험성을 내포하고 있는 코드를 생산했을 때 최대한 빠르게 잡아주어야 하는데 개발 지식이 없다면 이를 파악하기가 쉽지 않을 겁니다.
현실적인 문제도 존재했습니다. 본인의 개발 지식이 적으면 적을수록 AI와 합을 맞춰야 하는 커뮤니케이션 비용은 증가할 것이고 이는 오롯이 월 사용량의 빠른 소진으로 이어질 겁니다. 고성능의 모델은 비싸고 느리며 낮은 성능의 AI와 대화로만 개발을 이어가는 것은 오히려 스트레스만 증가시켰습니다.
어쩔 수 없이 사람의 손을 탈 수밖에 없는 상황도 존재합니다. 어떠한 프로젝트는 보안상의 사유로 은밀하게 취급되어야 하며 제한적인 정보만으로 코딩해야 하는 상황도 분명히 있습니다. 아니면, 아예 AI를 사용하지 못하는 환경도 있습니다. 이런 모든 상황에 온전하게 대응할 수 있는 존재는 현재로서는 사람밖에는 없다고 생각합니다.
정리하자면 소규모 프로그램, 정적 사이트, 프로토타입 버전, 개인 포트폴리오를 위한 사이드 프로젝트, 토이 프로젝트 정도의 개발은 바이브 코딩만으로도 충분히 가능하다고 보입니다만, 상용화를 목표로 하는 고도화된 프로그램을 개발하는 것은 아직 바이브 코딩만으로는 불가능하지 않을까 생각되네요. 바이브 코딩의 편리함과 명확한 한계를 경험할 수 있었던 귀중한 시간이었습니다.
마치며
지금 우리는 AI의 시대를 맞이하여 급격한 변화를 온몸으로 맞고 있습니다. 어느 서비스를 봐도 AI가 붙어있지 않은 곳이 없으며 SNS나 UCC 콘텐츠들은 AI가 생산한 이미지와 영상으로 가득 차 있죠. 현실과 구분하기도 어려운 고퀄리티의 콘텐츠들은 혹시나 나쁜 일에 쓰이지는 않을지 무서워지기까지 합니다.
그러나 업무적인 면에서 보자면 저 역시도 AI가 가져다주는 편리함을 외면하지는 못합니다. 소위 “딸깍” 한 번으로 나의 1시간을 줄여주는데 사용하지 않을 이유가 없죠.
그럼에도 불구하고 여전히 개발의 주도권은 내가 직접 쥐어야 합니다. AI에게 너무 의존하려는 자세를 버리고 AI를 효과적으로 활용해서 내 개발 능력을 극대화하는 것을 훈련하며, 내 업무를 “대신해 주는” 존재가 아닌 내 업무를 “보좌해 주는” 존재로써 함께 협업해 나가야 하지 않을까 생각해 보며 글을 마칩니다.
