Engineering
Vibe Coding하는 비개발자는 개발자인가(3)
sue.cream카카오
2026년 6월 16일
원문에서 보기 ↗2편을 쓴 뒤 시간이 꽤 지났습니다. 그 사이 AI 도구들은 더 많은 일을 하게 되었고, 저도 이전보다 훨씬 자주 AI 에이전트와 함께 일하게 되었습니다.
처음에는 업무에 실제적으로 도움을 주는 도구를 직접 만드는 일이 신났습니다. 개선하고 싶은 기능을 설명하면 화면이 생기고, 입력값을 넣으면 일정하게 필요한 결과가 나왔습니다. 이렇게 만든 도구들을 실제 업무에 계속쓰다 보니, 관심사가 자연스럽게 다음 단계로 넘어갔습니다.
혼자 쓰던 도구를 다른 사람에게도 공유하고 싶어졌습니다. 정적인 화면만으로는 아쉬워져서 데이터를 저장하고 싶어졌습니다. 사내 업무 도구와 연결하려고 하니 웹훅과 토큰을 만나야 했습니다. 그러니 보안을 고민하게 되었습니다. 코드와 관계 없이 매주 반복하던 업무에서도 일정한 패턴이 보이고 파이프라인을 생각하기 시작했습니다.
이 글은 그 과정에서 생긴 몇 가지 일들에 대한 기록입니다. 멋진 서비스를 만들었다는 이야기는 아닙니다. 오히려 작고 구체적인 업무들이 AI 에이전트를 만나면서 어떤 식으로 실행 가능한 형태가 되었는지에 대한 이야기입니다.
HTML을 공유하려다가
처음 만든 도구들은 대부분 로컬 HTML 파일이었습니다. 브라우저에서 열고, 필요한 값을 넣고, 결과를 확인하면 되는 정도였습니다. 혼자 쓰기에는 충분했습니다. 파일 하나만 있으면 되었고, 서버도 필요 없었고, 데이터베이스도 필요 없었습니다.
그런데 실제로 쓸 만한 도구가 생기면 자연스럽게 공유하고 싶어집니다. 주소가 필요하고, 배포가 필요하고, 수정했을 때 최신 버전을 어떻게 반영할지도 생각해야 합니다.
정적인 HTML로 충분하지 않은 경우도 생겼습니다. 어제 입력한 값을 다시 보고 싶고, 다른 사람이 입력한 값도 함께 보고 싶고, 상태가 바뀌면 화면도 바뀌어야 했습니다. 그때부터 문제는 UI가 아니라 상태 관리와 데이터 저장까지 확장됩니다. 어디에 데이터를 둘 것인지, 누가 볼 수 있는지, 누가 수정할 수 있는지, 권한을 어떻게 제어할 것인지, 잘못 수정했을 때 되돌릴 수 있는지, 어떻게 백업해둘 것인지 등을 생각해야 했습니다.
처음에는 데이터베이스를 떠올렸습니다. 하지만 비개발자가 모든 문제에 정식 DB를 붙이는 것은 쉽지 않았습니다. 매번 접근 권한을 새로 설계해야 하고, 매일 쓰는 것도 아닌데 운영 부담과 보안의 부담까지 생겼습니다.
그러던 중 하루는 구글 스프레드시트를 단순한 문서가 아니라, 가벼운 공유 데이터 저장소처럼 다시 보게 되었습니다. 스프레드시트는 이미 많은 사람이 쓰고 있고, 안전한 권한 관리와 수정 이력, 협업 UI를 갖고 있습니다. 그래서 스프레드시트를 공용DB로 하는 대시보드를 신나게 생성하기 시작했습니다.
처음에는 에이전트가 작성해준 Apps Script 코드를 텍스트로 붙여넣었고, 수정이 많아짐에 따라 다른 방법이 없을지 AI에게 질문했고, clasp를 통해 Apps Script API로 배포와 실행을 다루는 방식까지 발전했습니다. 물론 가끔 에러가 나면 여전히 수동으로 코드를 붙여넣는 경우가 절반이 넘는 것 같긴 합니다.
여기서 중요한 변화는 ‘코드를 더 많이 쓰게 되었다’가 아니었습니다. 데이터를 어디에 둘지, 어떤 도구가 조직 안에서 이미 자연스럽게 작동하는지, 안전하게 보관하고 공유할 수 있는지, 변경 이력을 어떻게 남길지와 같은 질문을 자연스럽게 하게 되었다는 점이었습니다.
보안을 습관으로
몇 년 전까지만 해도 시도하다가 문턱에서 자꾸만 실패했던 것 중 하나가 웹훅 봇이었는데 AI에이전트 덕분에 드디어 이것을 사용할 수 있게 되었습니다.
그런데 업무 환경에 연동된 웹훅으로 쓰려고 하니 토큰과 웹훅 URL값에 대한 보안을 고민하게 되었습니다. 이 값을 프롬프트, 코드에 그대로 넣지 않고, Git에 올라가지도 않게 하기 위해서 자연스럽게 .env 파일과 .gitignore 같은 것들을 건드리게 되었습니다.
이 과정에서 보안은 작업 습관이 되었습니다. AI에게 코드를 부탁할 때도 ‘토큰을 코드에 직접 넣지 말고 환경변수에서 읽도록’, ‘로그에 민감한 값이 찍히지 않도록’, ‘실제 값 대신 placeholder를 써두도록’ 요청했습니다.
편리하게 연결하고 싶어서 웹훅을 썼는데, 그다음에는 자연스럽게 비밀값 관리, 실행 환경, 접근 권한을 보게 되었습니다. 작은 자동화가 외부 시스템과 연결되는 순간, 숨겨야 할 것과 남겨도 되는 것을 구분하는 일이 같이 따라왔습니다.
손으로 하던 일을 패턴으로
AI 에이전트를 쓰면서 바뀐 것은 코딩 작업만이 아니었습니다. 파일을 복사하고, 폴더를 정리하고, 문서를 변환하고, 영상을 자르고, 영상에서 음성파일이나 요약문을 추출하는 일처럼 원래는 전통적인 소프트웨어와 손으로 하던 작업들도 점점 AI 에이전트에게 맡기게 되었습니다.
직접 할 때는 이런 일들이 별도의 설계 대상처럼 느껴지지 않습니다. 파일명을 보고 적당한 폴더로 옮기고, 필요한 부분만 잘라내고, 결과가 이상하면 다시 하면 됩니다. 그런데 에이전트에게 맡기려면 다르게 설명해야 합니다. 대상 파일은 무엇인지, 결과 파일명은 어떻게 정할지, 기존 파일을 덮어써도 되는지, 실패하면 어디에서 멈춰야 하는지, 결과가 제대로 되었는지 어떻게 확인할지를 말해야 합니다.
직접 할 때는 감으로 처리하던 일이, 맡기려고 하자 형식이 필요해졌습니다. 에이전트가 할 수 있는 일이 많아질수록, 요청은 단순한 부탁이 아니라 작업 명세에 가까워집니다. 맡기는 과정에서 입력, 출력, 예외, 검증 기준이 자연스럽게 드러납니다.
단지 자동화가 아니라, 반복되는 사람의 작업을 에이전트가 수행할 수 있는 업무 단위와 순서로 나누고 변환하는 일에 가까웠습니다. 그 과정에서 제가 실제로 알고 있어야 하는 것은 특정 명령어 하나가 아니라, 한 단계의 작업이 완료되었다고 판단할 수 있는 조건과 적절한input, output 파일의 포맷이었습니다.
Output은 다시 input으로
회의록 정리도 비슷했습니다. 논의 내용을 정리하고, 결정사항과 액션 아이템을 뽑고, 공유하기 좋은 초안을 정리하는 데에 약간의 LLM의 도움을 받았습니다. 그렇지만 제가 또 많은 시간을 들여 이것을 수정하고 검증해야 했습니다.
그런데 같은 종류의 회의를 매주 정리하다 보니 반복되는 작업과 수정 패턴이 보였습니다. 매번 제가 손으로 고치던 것들이 사실은 업무 규칙이었습니다. 그래서 Codex와 Claude의 skill을 만들고 고치기 시작했습니다. 회의록을 어떤 형식으로 정리할지, 액션 아이템은 어떻게 뽑을지, PMO 관점에서 어떤 신호를 봐야 할지 등 각 회의에 맞는 규칙을 남겼습니다.
여기서 skill은 단순한 프롬프트 모음이 아니었습니다. 반복되는 판단 기준을 저장하는 방식에 가까웠습니다. 회의록이라는 입력이 들어왔을 때 어떤 출력이 필요하고, 어떤 항목은 확인해야 하며, 어떤 경우에는 결론을 AI 혼자 내리지 말고 저에게 질문해야 하는지를 정리해두는 것입니다. AI가 문장을 잘 써주는 것보다, 제가 반복 업무의 구조를 더 잘 보게 된 점이 성능 개선에 더 도움이 되었습니다.
그리고 이 skill로 작성된 회의록은 다시 제가 수정한 최종본과 비교하여 개선점을 저의 취향대로 발굴했고, 이것으로 skill을 업데이트하여 매주 더 특화된 skill을 쌓아 갔습니다.
그러던 어느 날은 보안을 위해 불필요한 내부 데이터를 로컬에 쌓아두지 않으려고 일부 데이터를 청소하다가, AI 에이전트와의 소통 실패로, 보존하고 싶었던 대화 기록을 날려버렸습니다. Skill 파일은 남아있었지만 미처 반영되지 않았던 많은 맥락들의 유실로 스킬의 성능이 잠시 저하되는 시행착오도 겪었답니다.
패턴은 역시 AI로
구글 애널리틱스(이하 GA) 리포트 작업도 좋은 예였습니다. 이전에는 GA로 수집되는 데이터를 확인하고, 표를 보고, 인사이트를 뽑기 위해 여러 대시보드 뷰를 만드는 일이 시간도 오래 걸리고 번거로워서 자주 하지 못하는 작업이었습니다. 이제는 MCP로 API를 통해 GA 데이터를 가져오고, skill로 월간 리포트의 구조를 유지하고, 지난달과 달라진 점을 비교하는 식으로 원하는 시기마다 촘촘하게 데이터를 확인할 수 있게 변화했습니다.
데이터 수집은 점점 쉬워지고 있습니다. 하지만 수집된 데이터를 어떤 질문에 연결할지는 여전히 중요합니다. GA MCP는 데이터를 가져오는 통로가 되고, skill은 리포트의 반복 구조를 유지하는 장치가 됩니다. 그 위에서 필요한 것은 단순 요약이 아니라, 지난번과 이번의 차이를 보고 “이 변화는 말할 만한가”를 판단하는 일입니다.
이제 AI 에이전트가 뽑아주는 숫자와 나름의 해석들을 보면서, 제가 가진 맥락 정보와 결합해서 이 부분은 추가 조사가 필요하겠구나 판단하고 질문해서 이전에는 탐지하기 어려웠던 신호들을 준실시간으로 캐치할 수 있게 된 것입니다.
마치며: 개발의 경계에서 생긴 일들
돌아보면 변화는 도구의 개수가 늘었다는 데 있지 않았습니다. 제가 하던 일이 조금씩 다른 형태로 보이기 시작했다는 데 있었습니다.
1편과 2편에서는 AI로 무언가를 만들 수 있다는 경험 자체가 중요했습니다. 지금은 조금 다른 지점에 와 있습니다. AI가 만들어주는 결과물보다, AI와 함께 일하기 위해 제 업무를 어떤 형태로 설명해야 하는지가 더 중요해지고 있습니다.
아마 이 변화는 앞으로 더 많은 업무에서 나타나겠지요. 모든 사람이 같은 방식으로 코드를 쓰게 된다는 뜻은 아닙니다. 다만 더 많은 일이 실행 가능한 형태로 정리되고, 더 많은 사람이 입력과 출력, 권한과 보안, 반복과 검증을 일상적으로 고민하게 될 것 같습니다. 돌아보니 이 여정을 오는 내내 저는 제 일이 어떤 모양으로 움직여야 하는지를 조금씩 구조화해가고 있었습니다.
AI 코딩 에이전트의 시대가 본격적으로 열리면서, 개발자분들은 자신의 일이 어디까지 AI에게 넘어갈지 묻기 시작했습니다. 그런데 이 질문은 당연히 개발자에게만 해당하지 않습니다. 제가 하던 일들도 조금씩 쪼개지고, 맡겨지고, 다시 정의되고 있습니다. 앞으로 제 업무는 어떤 형태로 대체되고, 어떤 형태로 남게 될까요? 아마 다음 글은 그 방향에서 시작해야 할 것 같습니다.