이번 달에도 AI 뉴스가 끊임없이 쏟아졌지만, 대부분은 당신이 지금 만들고 있는 제품과 직접적인 관련이 없다. [Source: https://www.aiapps.com/blog/top-ai-news-july-breakthroughs-launches-trends/] 하지만 그중에는 개발자라도 잠시 멈춰서 볼 만한 방향이 하나 있다. 바로 Excel 안의 Copilot이다. 마이크로소프트의 설명에 따르면, 프롬프트를 보내면 Copilot은 먼저 작업을 분석하고 단계별 계획을 세운 뒤, 워크시트 안에서 직접 실행하고 결과를 확인하며 원하는 바를 달성했는지 평가한다. [Source: https://support.microsoft.com/en-US/excel/copilot/get-started-with-copilot-in-excel] 다시 말해, 당신이 설명한 상황에 맞춰 데이터를 분석하고 스프레드시트 내용을 생성해줄 뿐, 셀 하나하나를 직접 손으로 만들라고 요구하지 않는다.

사실 진짜 배울 만한 것은 Excel도, 월간 리포트도 아니라 그 뒤에 숨어 있는 패턴이다. 일정 주기마다 반복해야 하는 구조화된 작업이라면 무엇이든, 자연어로 한 번 가르치고 저장해두었다가 다음번에 다시 재생할 수 있다. 월간 리포트는 이 패턴을 가장 이해하기 쉬운 예시일 뿐이다. 거의 모든 사람이 피할 수 없는 일이기 때문이다. 이 글을 「AI 도구와 함께 반복 가능한 흐름을 만드는 법」에 대한 실전 가이드로 받아들이면, 당신 손에 있는 어떤 반복적인 잡무에도 그대로 적용할 수 있다.

진짜 비용은 주기적이고 핵심은 아니지만 끝없이 반복되는 잡무다

월간 리포트를 만들려고 창업한 사람은 아무도 없다. 하지만 매달 여전히 매출을 집계하고, 구독의 성장과 이탈을 계산하고, KPI를 뽑아서 스스로 확인하거나, 숫자를 정리해 파트너와 투자자에게 보내야 한다. 이 장면을 매주 성장 지표, 고객에게 보내는 정기 업데이트, 매번 출시 전에 다시 정리해야 하는 데이터, 반복적으로 같은 형식으로 정리해야 하는 원본 파일로 바꿔도 구조는 똑같다. 규칙은 명확하고, 매번 비슷하지만, 매번 다시 처음부터 해야 한다는 것이다. 이런 일들은 하나하나 보면 어렵지 않지만, 하나같이 원래 build에 써야 할 시간을 갉아먹는다.

게다가 이런 잡무의 진짜 비용은 어떤 수식이 어려워서가 아니라, 「지난번에 정확히 어떻게 했는지」가 전혀 기록으로 남지 않는다는 데 있다. 머릿속에 있는 그 흐름—어떤 표를 먼저 붙여넣을지, 어떤 열을 걸러낼지, 피벗을 어떻게 돌릴지, 어떤 셀을 빨간색으로 표시할지—를 주기마다 다시 처음부터 되풀이한다. 이 작업은 한 덩어리의 완전한 시간을 차지하는 것이 아니라, 반나절 동안 흩어진 자잘한 결정들로 이루어져 있어서, 정신을 차려보면 이미 오후 내내 codebase를 건드리지 못한 뒤다. 이런 비용이 가장 비싼 이유는, 끝내고 나면 아무것도 남지 않아서 다음 주기에는 다시 처음부터 시작해야 하기 때문이다.

직관적으로 「그럼 스크립트를 하나 짜면 되지 않나」라고 생각할 수도 있다. 형식이 절대 바뀌지 않는 작업이라면 스크립트가 확실히 이긴다. 하지만 이런 흐름의 규칙은 보통 분기마다 한 번씩 미세하게 조정된다—부서가 하나 늘거나, 집계 기준이 바뀌거나, 전년 대비 열이 추가되거나, 고객이 그래프를 하나 더 요구하는 식이다. 이럴 때 당신이 유지보수하는 것은 매번 다시 돌아가 고쳐야 하는 일회성 스크립트이며, 그걸 관리하는 비용이 수동 작업보다 반드시 낮다고는 할 수 없다. 자연어 설명은 또 다른 선택지다. 한 문단을 고치는 것이, 시간이 지나면 낡아버리는 코드 한 조각을 고치는 것보다 비용이 적게 든다.

먼저 수동으로 한 번 실행하고, 그다음 매 단계를 「말로」 설명해준다

리본 메뉴에서 [Copilot]을 선택해 채팅 창을 열거나, 셀을 선택한 뒤 옆에 있는 Copilot 아이콘을 클릭해서 들어간다. [Source: https://homepage.ntu.edu.tw/~huangsl/office365/excel/Excel%E8%88%87Copilot%E8%BC%94%E5%8A%A9%E5%8A%9F%E8%83%BD%E6%87%89%E7%94%A8.pdf] 이번에는 Copilot이 알아서 추측하게 두지 말자. 처음부터 끝까지 직접 한 번 해보면서, 동시에 자연어로 각 단계를 설명한다. 「A 탭의 원본 데이터를 부서별로 그룹화하고, 이번 달 매출을 합산한 뒤, 지난달과 비교해 성장률을 계산한다. 특정 임계값을 넘으면 초록색으로, 0보다 낮으면 빨간색으로 표시하고, 마지막으로 요약문을 생성한다.」

이렇게 「한 문장으로 원하는 결과를 설명하는」 방식이 바로 Copilot이 처리하도록 설계된 입력이다—심지어 「이 표를 월간 리포트 형식으로 정리해줘」라고 바로 말해도, 현재 워크시트 내용에 맞춰 해당 작업을 생성해주고 자동 완성까지 도와주며, 이런 기능은 무료 버전에서도 사용할 수 있다. [Source: https://powerappstw.com/zh/blog/page-127] 핵심은 「명확하게 말하는 것」이지 「멋지게 말하는 것」이 아니다. 신입 엔지니어에게 인수인계 문서를 쓴다고 생각하면 된다—설명이 명확하고 암묵적인 가정이 적을수록 결과가 정확해진다. 이 단계를 익히면, 어떤 주기적인 업무로 바꾸더라도 같은 방법을 쓸 수 있다. 수동으로 한 번 해보면서, 동시에 그것을 한 문단의 말로 옮기는 것이다.

그 설명을 버전 관리에 저장해두면, 다음번엔 그대로 붙여넣기만 하면 된다

이 단계가 핵심이다—이번에 들인 시간이 그대로 증발하게 두지 말자. 방금 작성한 설명 전체를 온전히 저장해둔다. repo 안의 .md 파일이든, 메모든, Notion이든 상관없다. 사실 이것 자체가 당신의 흐름 그 자체이며, 단지 실행 가능한 한 문단의 말로 번역되었을 뿐이다. 그리고 이것을 진화하는 문서로 취급해 버전 관리와 함께 두는 편이, 머릿속에 기억해두는 것보다 훨씬 신뢰할 수 있다. 다음 주기에는 새 데이터를 넣고 그 설명을 그대로 붙여넣기만 하면 Copilot이 다시 실행한다. 한 번 가르치고, 그다음부터는 한 문단만 붙여넣으면 된다. 시간이 지나면 손에는 이런 「흐름이 곧 텍스트」인 조각들이 조금씩 쌓이는데, 각 조각은 예전에는 반나절을 잡아먹던 잡무가 이제는 한 문단으로 끝나는 것을 뜻한다.

다만 솔직히 말하자면, Copilot은 현재 매크로처럼 「버튼」 하나를 녹화해주는 것이 아니라, 저장해둔 자연어 설명을 매번 새로 이해하고 새로 생성하는 방식으로 작동한다. 그래서 그 설명이 얼마나 구체적으로 쓰였는지가 다음번에 얼마나 수월할지를 가르는 분수령이 된다. 모호한 설명은 매번 다시 돌아가 수동으로 손봐야 하는 대가를 치르게 되는데, 이는 확정적인 코드를 작성하는 데 익숙한 사람에게 특히 불편하게 느껴질 수 있다.

같은 데이터를 두 번 실행해봐야 무엇이 절약되었는지 알 수 있다

이 글을 포함해서, 누가 알려주는 시간 절약 수치도 그대로 믿지 말자. 엔지니어의 본능은 원래 이래야 한다. 같은 데이터를 한 번은 예전처럼 수동으로 하고, 한 번은 저장해둔 명령으로 실행한 뒤, 둘을 나란히 놓고 대조하는 것이다. 대조할 것은 두 가지다. 하나는 시간 차이(직접 스톱워치로 잰다), 다른 하나는 숫자가 맞는지 여부다. Copilot이 생성한 매출 합계, 성장률은 직접 손으로 계산한 값과 맞아야 비로소 의미가 있다. 맞아야 정식 산출물에 넣을 수 있고, 맞지 않으면 결과가 아니라 그 설명을 고쳐야 한다. 결과를 고치는 것은 문제를 덮는 것이고, 설명을 고치는 것이 근본적인 해결이다—이는 디버깅할 때 출력을 억지로 바꾸는 대신 근본 원인을 고치는 것과 같은 이치다.

참고로 Copilot 자체가 데이터를 분석해 인사이트를 도출해주는 용도로 만들어졌다. [Source: https://support.microsoft.com/zh-tw/office/%E9%96%8B%E5%A7%8B%E4%BD%BF%E7%94%A8-excel-%E4%B8%AD%E7%9A%84-copilot-d7110502-0334-4b4f-a175-a73abdfc118a] 이 기능을 거꾸로 활용해서, Copilot이 주는 답을 일방적으로 신뢰하기보다는 직접 계산한 결과를 교차 검증하는 데 쓸 수도 있다. 이 「먼저 검증하고 그다음에 신뢰한다」는 원칙은, 어떤 AI 도구로 어떤 작업을 실행하든 똑같이 적용된다.

어떤 업무에 적합하고, 어떤 업무는 문제를 일으키는가

맡기기에 적합한 것은 구조가 안정적이고 매번 비슷한 업무—매출 집계, 구독 성장, KPI 추적, 형식이 고정된 데이터 정리처럼 규칙이 명확한 일이다. 적합하지 않은 것은 규칙이 매번 바뀌고 그때그때 판단이 필요한 일이다(예를 들어 특정 이상치를 제외할지, 어떤 환불이 이번 달 MRR에 포함되는지 등). 이런 경우 Copilot은 그럴듯해 보이는 방식으로 대신 결정을 내려버리는데, 바로 그 지점이 가장 위험하다—확신에 찬 태도로 틀리기 때문에 한눈에 알아차리기 어렵다. 이런 애매한 영역은 여전히 스스로 판단해야 한다.

그리고 데이터 문제도 있다. 인디 개발자가 손에 쥐고 있는 것은 생각보다 민감한 경우가 많다—사용자 명단, 자금 흐름 데이터, 아직 공개되지 않은 매출 등이다. 정말로 민감한 데이터를 AI 흐름에 넣을지는 당신이 결정할 문제이지, 기본값으로 정해질 일이 아니다. 시간을 절약하는 것은 분명 만족스럽지만, 되돌릴 수 없는 사용자 데이터 유출과 맞바꿀 가치는 없다.

이렇게 반복되는 잡무에서 가장 치유가 되는 순간은 「끝냈다」는 그 순간이 아니라, 어느 날 문득 그 반나절이 마침내 지금 만들고 있는 제품에게 되돌아왔다는 사실을 깨닫는 순간이다.