바이브 코딩, 학습 관리 에이전트 – 기능 구현 vs 서비스 개발

작성자:

얼마 전 아들2호가 바이브 코딩으로 만든 웹페이지를 하나 보여주었습니다. 자기가 만들고 싶은 내용을 말했더니 5분 만에 그럴듯한 화면이 나왔고, 대충 잘 동작하는 것 같으니, 휴대폰에서도 볼 수 있게만 ‘조금만’ 도와달라고 했습니다.

그 말이 틀린 건 아닙니다. 화면은 있었고, 필요한 기능도 눈앞에서 동작했습니다. 예전 같으면 HTML 파일 하나를 만들어 브라우저에서 열어 보는 데도 한참이 걸렸을 텐데, 이제는 아이가 자기 생각을 말로 설명하고 바로 결과를 확인합니다.

그런데 아이의 말을 듣는 순간 제 머릿속에는 수많은 후속 질문들이 떠올랐습니다. 휴대폰에서도 보기 위해서는 어떤 서버에 올려야 할까? 데이터는 어디에 저장할까? 보안을 위해 계정은 어떻게 연결할까? 알림이 필요하다면 누가, 언제, 어떤 방식으로 보낼까? 문제가 생겼을 때 무엇을 확인할 수 있을까?

아마 이것은 오랜 기간 개발 과제에 참여하고 과제를 운영해 온 전문가의 반사작용일 겁니다. 아이의 눈에는 오직 기능만 보였고, 저에게는 그 기능이 계속 동작하기 위해 뒤따라야 할 질문들이 보였습니다.

원래는 아이가 직접 모든 과정을 마무리할 수 있도록 가이드하려고 했으나, 개인 사정상, 이번에는 아이의 원래 요구사항을 바탕으로 제가 다시 앱을 만들어 주기로 했습니다. 요구사항을 정리하는 데 한 시간, 초기 버전을 만드는 데 두 시간, 그리고 그것을 매일 쓸 수 있게 만드는 데 하루 반을 더 썼습니다. 이 글에서는 그 과정을 정리했습니다.

앞서 「AI시대: 바이브 코딩으로 웹앱 만들기」와 「바이브 코딩, 주식 거래 에이전트 개발」에서 AI와의 협업을 다뤘는데, 이번에는 그 이후 과정에 초점을 맞췄습니다. AI는 기능 구현의 문턱을 크게 낮춰 주었지만, 여전히 기능을 지속 가능한 서비스로 키우는 질문까지 대신해 주지는 않았습니다.

한 시간의 질문, 두 시간의 기능 구현

이번에는 “학습 관리 에이전트”를 만들기로 했습니다. 아이가 학교/학원 등에서 공부를 하다가 숙제나 복습할 내용이 생기면 학습 계획을 등록하고, 필요한 때에 학습 계획을 확인하고, 알림도 받는 간단한 서비스입니다.

처음에는 저도 아이가 만든 웹페이지를 살펴보면서 간단하게 해 줄 수 있을 거라고 생각했습니다. 하지만 바로 구현에 들어가지 않았고, 요구사항을 다시 들여다보며 한 시간쯤 고민했습니다. 누가 쓰는 서비스인지, 매일 반복해서 쓸 때 무엇이 가장 불편한지, 일정은 어디에 남겨야 하는지, PC와 모바일에서 같은 정보를 보려면 어떤 구조를 가져야 하는지 먼저 정리했습니다.

이 과정은 다소 구시대적으로 보일지도 모릅니다. 이제는 막히면 AI에게 물어보고, 화면이 필요하면 바로 만들어 보면 됩니다. 실제로 그 방식이 훨씬 빠른 경우도 많습니다. 하지만 서비스의 방향을 정하는 일은 조금 다릅니다. 기능을 하나 더 붙일 때보다, 무엇을 저장하고 무엇을 나중에 바꿀 수 있게 할지 정할 때 되돌리는 비용이 더 크기 때문입니다.

저는 학습 일정의 원본을 Google Calendar에 두기로 하고, 여러 기기에서 같은 정보를 볼 수 있는 방향으로 출발점을 잡았습니다. 이렇게 하면 별도의 뷰어가 없어도 캘린더 앱을 통해서 확인이 가능합니다. 당초 AI는 별도의 DB를 제안했으나 그렇게 하면 DB 관리 때문에 배보다 배꼽이 더 커질 것 같았습니다.

방향을 정한 뒤에는 Gemini와 약 두 시간 동안 대화하며 초기 버전을 만들었습니다. 학습 일정 조회와 등록, 과목과 할 일의 구분, 사용자의 상태에 맞는 화면처럼, 사용자가 바로 써볼 수 있는 기능은 빠르게 모습을 갖췄습니다.

기능만 놓고 보면 놀라운 경험이었습니다. 낯선 도구와 API를 하나씩 찾아 문서를 읽고 화면을 연결하던 시간을 크게 줄일 수 있었습니다. 혼자서 처음부터 만들었다면 며칠은 걸렸을 법한 일을, 일단 사용할 수 있는 기능 구현 수준까지는 두 시간 만에 끝낼 수 있었습니다.

기능 구현 이후의 시간

짐작대로 개발은 거기서 끝나지 않았습니다. 초기 기능을 만든 뒤, 실제로 계속 사용할 수 있게 만드는 데만 하루 반 정도를 더 썼습니다. 이 시간은 새 기능 목록을 늘리는 시간이기보다, 이미 만든 기능이 서비스로 동작하게 만드는 시간이었습니다.

Google Calendar 최적화

Google Calendar를 일정의 원본으로 쓰면 사용자가 따로 데이터를 입력하고 옮길 필요가 없습니다. 이미 쓰고 있는 캘린더 앱을 그대로 활용할 수 있다는 점은 큰 장점이었습니다.

반대로 화면을 열 때마다 Calendar API를 통해 일정을 읽어 오면, 화면의 반응이 느려질 수 있습니다. 간단한 일정표인데도 사용자는 기다려야 하고, 모바일에서는 그 지연이 더 크게 느껴집니다. 그래서 필요한 범위의 데이터를 미리 가져오고, 메모리에 캐시를 두고, 먼저 화면을 보여준 뒤 최신 데이터를 갱신하는 방식을 붙였습니다.

같은 기능이라도 데이터를 어디에서 읽고, 언제 갱신하며, 사용자가 무엇을 먼저 보게 할지에 따라 서비스 경험은 달라집니다.

알림 기능 구현

아이의 주요 요구사항 중에 알림 기능이 있었습니다. 하지만 “매일 카카오톡으로 알려줘”는 메시지를 보내는 코드 한 줄로 끝나는 요구사항이 아니었습니다.

어떤 계정으로 인증할지, 누구에게 보낼지, 권한은 어떻게 유지할지, 정해진 시간에 실행할 작업은 어디에 둘지, 실패했을 때 다시 보낼지 같은 결정이 뒤따릅니다. 화면에서 보기 좋은 버튼을 만드는 일과, 실제 사용자의 계정과 연결해 매일 동작하게 만드는 일은 다른 종류의 일입니다.

AI는 이 과정에서도 여러 선택지를 빠르게 보여주었습니다. 다만 선택지를 실제 서비스의 조건에 맞게 고르고, 공식 문서와 실제 실행 결과를 대조하는 일은 결국 사람이 해야 했습니다. API가 있다고 해서 지금의 계정 조건에서 바로 쓸 수 있는 것은 아니기 때문입니다.

상대적으로 구현이 편한 텔레그램을 쓸까 고민도 했지만 아이에게 새로운 앱을 설치하게 하는 건 답이 아니었습니다. 그래서 가장 많이 쓰는 카카오톡을 이용하기로 했습니다. 다음으로 카카오톡의 “나와의 채팅” 기능을 이용하려고 했는데 나와의 채팅은 카톡 알림이 울리지 않더군요. 알림 기능인데 알림이 울리질 않는다면, 사용자 경험으로 보면 치명적입니다. 결국 별도의 카카오톡 계정을 만들고 해당 계정에서 아이의 카카오톡으로 메시지를 보내는 방식으로 구현을 했습니다.

기능 진단 화면 추가

후반에 붙인 기능 중 하나는 진단 화면이었습니다. 인증을 위한 토큰이 유효한지, 수신자 연결이 맞는지, 예약 작업이 살아 있는지처럼 평소에는 보이지 않는 상태를 확인할 수 있게 했습니다.

외부 서비스와 연결하고 기능이 잘 동작하지 않을 때 진단 화면의 필요성을 인식했고, 이를 추가했습니다. 가령 알림이 오지 않을 때 “왜 안 되지?”라고 추측하는 대신, 진단 화면을 통해 어느 단계에서 멈췄는지 확인할 수 있기 때문입니다.

여기까지 오고 나서야 제가 처음 떠올렸던 질문들이 하나씩 기능의 형태를 갖췄습니다. 계정 연결, 데이터 저장, 성능, 알림, 진단은 사용자의 첫 요구사항에는 잘 드러나지 않습니다. 그러나 이런 것들이 있어야 화면 속 기능이 며칠 뒤에도, 다른 기기에서도, 문제가 생긴 날에도 계속 쓸 수 있습니다.

기능 구현 vs 서비스 개발

이번 경험을 통해 기능 구현과 서비스 개발을 조금 더 분명하게 구분하게 되었습니다.

기능 구현은 사용자가 원하는 동작을 눈앞에 만드는 일입니다. 입력하면 결과가 나오고, 버튼을 누르면 화면이 바뀌고, 일정이 등록되는 상태까지 가는 일입니다. 바이브 코딩은 이 단계의 문턱을 놀라울 만큼 낮춰 주었습니다. 아이가 5분 만에 만든 웹페이지를 보면 그 자체로 충분히 의미 있는 결과입니다.

하지만 서비스 개발은 그 기능이 반복해서 쓰이는 상황을 준비하는 일입니다. 누가 쓰는지, 데이터는 어디에 남는지, 기기와 계정이 바뀌면 어떻게 유지할지, 기능에 문제가 생기면 어떻게 확인할지, 나중에 기능을 고칠 수 있는지를 함께 고려해야 하는 일입니다.

둘 중 어느 하나가 더 중요하다는 이야기가 아닙니다. 프로토타입이 필요한 순간에는 빠르게 기능을 만드는 것이 맞습니다. 다만 프로토타입을 서비스로 쓰기 시작하는 순간에는 질문의 종류가 달라진다는 것을 알아야 합니다. 그 전환을 제대로 보지 못하면, 기능 구현이 완성된 상태를 개발이 끝난 상태로 오해하기 쉽습니다.

완성의 기준

그래서 “다 만들었다”는 말에는 언제나 범위를 붙여야 합니다. 내 컴퓨터에서 한 번 써보는 웹페이지라면 화면이 동작하는 순간 완성일 수 있습니다. 가족이 매일 쓰는 도구라면 계정과 데이터, 알림까지 포함되어야 완성에 가까워집니다.

서비스의 크기가 커질수록 요구사항도 늘어납니다. 하지만 처음부터 모든 것을 갖춘 시스템을 만들자는 뜻은 아닙니다. 지금 만들고 있는 것이 실험인지, 개인 도구인지, 다른 사람에게 맡길 서비스인지 먼저 정하고, 그 범위에 맞는 질문을 추가하자는 뜻입니다.

이 구분이 있으면 필요한 일을 과하게 만들지도, 꼭 필요한 일을 놓치지도 않게 됩니다. 작은 프로토타입에 운영 체계를 모두 붙일 필요는 없습니다. 반대로 매일 쓰기 시작한 도구라면, 기능 목록에 없다는 이유로 데이터 보존과 진단을 뒤로 미루기 어렵습니다.

바이브 코딩이 잘하는 일

바이브 코딩의 가장 큰 장점은 생각을 결과물로 옮기는 노력을 줄여준다는 점입니다. 모호한 아이디어를 대화로 구체화하고, 처음 보는 API도 사용법을 쉽게 확인하며, 화면과 데이터 흐름을 빠르게 연결할 수 있습니다.

이번에도 AI는 학습 관리라는 요구를 기능 단위로 쪼개고, 낯선 도구의 예시를 만들고, 오류가 난 지점을 함께 추적하는 데 큰 도움이 되었습니다. 개발자만 할 수 있던 첫 번째 구현의 문턱이 낮아진 것은 분명합니다.

이 변화가 무척 중요합니다. 아이가 “만들고 싶다”는 생각을 코드 문법을 몇 달 배우는 일보다 먼저 시험해 볼 수 있기 때문입니다. 결과를 만든 뒤에 더 좋은 질문을 하게 되는 순서도 충분히 가능합니다.

이번 작업에서도 AI는 단순히 코드를 대신 쓰는 도구보다, 생각을 빠르게 검증하는 대화 상대에 가까웠습니다. 일정 원본을 어디에 둘지, 알림을 어떤 흐름으로 만들지, 느린 화면을 어떻게 다룰지 질문을 던지면 선택지와 구현의 출발점을 빠르게 얻을 수 있었습니다. 방향을 정한 뒤의 실행 속도는 분명히 달라집니다.

바이브 코딩이 놓치는 일

AI는 아직 묻지 않은 질문까지 항상 먼저 꺼내 주지는 않습니다. 대화에서 요청한 기능을 성실하게 만들지만, 사용자가 계정 연결이나 데이터 보존, 장애 상황을 말하지 않았다면 그 범위를 스스로 서비스 요구사항으로 확장하지는 않습니다.

이것은 AI의 부족함만은 아닙니다. 사람이 개발할 때도 화면이 먼저 보이면 끝난 것처럼 느끼기 쉽습니다. 다만 AI가 첫 결과를 너무 빨리 만들어 주기 때문에, 그 착각이 더 빨리 찾아옵니다. 동작하는 화면은 강한 성공 신호이지만, 그것만으로 서비스가 운영 가능한 상태라는 뜻은 아닙니다.

저는 이전 바이브 코딩 경험에서 “동작한다”와 “옳게 구현됐다”가 다르다는 점을 여러 번 보았습니다. 이번에는 그다음 단계를 이야기하고 싶습니다. 기능이 동작하고, 요구에 맞게 구현된 뒤에도, 그것이 사용자의 일상 안에서 계속 동작하게 만드는 일은 전혀 다른 일이라는 점입니다.

경험 많은 개발자의 역할도 여기에서 더 중요합니다. 더 빨리 코드를 쓰는 사람이기보다, 기능이 나온 다음에 무엇을 더 물어야 하는지 질문을 설계하는 사람에 가깝습니다. 과거의 장애와 재작업 경험은 기술 목록보다 질문 목록으로 남습니다.

AI와의 협업에서도 역할은 나뉩니다. AI는 가능한 구현을 넓게 제안하고, 사람은 이 서비스에서 무엇을 포기할 수 없으며 어떤 실패가 치명적인지 판단합니다. AI가 빠르게 만든 답을 바로 채택하는 것보다, 그 답이 어떤 조건에서 동작하는지 다시 묻는 순간 서비스의 품질이 달라집니다.

다음 세대에게 전할 질문

저와 아들1호는 시대는 다르지만 그래도 비교적 비슷한 방식으로 코딩을 배웠습니다. 문법을 익히고, 작은 프로그램을 만들고, 오류를 만나며 조금씩 범위를 넓혔습니다. 아들2호도 문법을 배우고 손으로 코딩하는 경험을 했고, 여전히 관련 공부를 하고 있습니다. 다만 그 사이 AI가 급격하게 발달하면서, 지금은 AI와 대화로 화면을 만들고 바로 써보는 일이 훨씬 자연스러워졌습니다.

두 방식은 배우는 순서가 다를 뿐입니다. 아이가 5분 만에 만든 화면을 보고 예전 방식부터 다시 배우라고 말할 필요는 없습니다. 그 화면은 그 범위 안에서는 완성된 결과이기 때문입니다.

대신 전해주고 싶은 것은 방식이 아니라 질문입니다.

  • 이 구현은 기능 확인용인가, 일상에서 반복해서 쓸 용도인가?
  • 데이터는 어디에 남고, 다른 기기와 다른 계정에서도 같은 상태를 볼 수 있는가?
  • 기능 동작이 실패했을 때, 어디서 어떻게 이유를 확인할 수 있는가?
  • 이후 기능 확장을 고려하고 있는가?

이 질문들은 아이디어를 더 오래, 더 넓게 쓰기 위한 질문입니다. 바이브 코딩 시대에는 코드를 만드는 법만큼, 만든 것을 어느 범위까지 책임질 것인지 정하는 법도 중요해집니다.

맺음말

AI는 누구나 기능을 만들 수 있게 합니다. 그러나 기능을 계속 쓸 수 있는 서비스로 키우려면, 기능 구현 이후의 질문에 답해야 합니다.

기능 구현과 서비스 개발은 다른 목적입니다. 그래서 질문도 달라야 합니다.

ChulJoo Kim (김철주)

※ 참고문헌

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기