커서 ‘Automations’으로 프로젝트 개선한 후기

커서 ‘Automations’으로 사이드 프로젝트를 개선하는 방법과 한 달 사용기

AI와 코딩하면 속도는 빨라집니다. 대신 다른 부담이 생겼습니다. PR이 늘고, 에이전트가 만든 코드를 사람이 다시 리뷰하는 시간이 늘었습니다. 그리고 릴리즈 노트, 버전업, 중복 정리 같은 반복 유지보수는 점점 뒤로 밀리게 됩니다. 한동안 저는 이걸 ‘skills’를 만들어서 틈틈이 정리해 왔습니다. 그런데 이것을 챙기는 것도 꽤 버거운 일이더군요.

그런 와중에 책 ‘아주 작은 습관의 힘(Atomic Habits, 제임스 클리어 저)’를 읽으면서, 반복에 중요한 점은 구체적이고, 자동화된 시스템이라는 것을 알게 되었습니다. 그래서 커서의 Automations 기능을 활용하여, 구체적이고 자동화된 시스템을 만들었습니다. 프로젝트를 반복적으로 개선하는 저만의 워크플로우를 만든 거죠. 이번 글에서는 이 경험을 나누고자 합니다.

AI 에이전트의 피로감, 그리고 Automations

AI 에이전트로 코딩하면 속도는 빨라집니다. 이건 논의할 여지가 없는 현실입니다. 물론 그 빨라짐이 유용한지에 대한 논의는 여전히 활발합니다. 하지만 여기서는 유용함은 잠시 뒤로 두고, 속도감과 피로감에 대해 집중해 보겠습니다.

최근에 저는 동료에게 이런 말을 자주 합니다.

• “OO님, 이거 다음 주까지 리뷰해 드려도 될까요?”
• “OO님 이거 중복코드인데 AA 코드 확인해 보면 좋겠어요.”
• “OO님 이 코드 의도가 무엇인가요?”

이런 말을 자주 하게 되는 근본적인 원인은 아직까지 AI 에이전트의 한계이기도 함과 동시에 속도가 빨라졌기 때문에 발생한다고 생각합니다. 이전에도 일정이 바빠 리뷰가 밀릴 때도 종종 있었고, 중복 코드이니 확인해 달라는 말이나, 코드 의도를 물어보는 말 또한 코드 리뷰할 때 많이 했던 코멘트이기도 합니다.

다만 속도가 빨라짐에 따라 더 자주 발생할 뿐입니다. 그리고 “AI 에이전트의 가장 큰 병목은 사람이다”라는 말이 어느덧 온몸으로 체감되기 시작했죠. 이를 해결하기 위해서 다양한 방법이 시도되고, 사람이 병목이기 때문에 사람의 간섭을 최대한 적게 하는 식으로 프로젝트의 설계가 변경되기도 합니다. 그리고 그 핵심에는 Automations, 즉 자동화가 있습니다.

이전에는 자동화하는 작업은 꽤 고된 작업이었습니다. 별도로 시스템을 띄워서 프로젝트를 연결하고, 관련된 프로그램까지 세팅해야 했죠. 그리고 이 방법조차 학습해야 했습니다. 하지만 각 제품에서 점차 편리한 자동화 기능이 나왔고, 오늘 소개할 커서의 Automations 또한 사용해 보니 매우 편리한 자동화 도구였습니다.

커서의 Automations

커서 공식 홈페이지에 따르면, Automations는 일정이나 이벤트에 맞춰 클라우드 에이전트를 자동 실행해 주는 기능입니다.

구성은 단순합니다.

그리고 만들기도 아주 편하고 직관적입니다. 그중에 만족스러운 부분은 이미 연동한 Tools는 바로 사용할 수 있다는 점이었습니다.

Automations 한 달 활용기

이번에는 제가 한 달 동안 사용했던 Automations를 리뷰해 보겠습니다.

버전업을 자동화하기

이건 Automations이 나오자마자 제가 바로 생성한 Automation입니다. 전문을 공유하는 것은 크게 의미가 없어, 어떤 목적의 지침인지만 정리해 보겠습니다.

• main 브랜치에 머지된 변경 사항을 분석하여 릴리즈 노트를 생성한다.
• dev 브랜치에만 추가된 변경 사항은 무시한다.
• Semantic versioning 기준으로 버전업을 하고, 릴리즈 노트를 생성한다.
• 릴리즈 노트에 넣을 항목과 제외할 항목을 토대로 릴리즈 노트에 생성한다.
• 릴리즈 노트는 Major, Minor까지만 생성한다.

그리고 이 로직을 바탕으로 3주 동안 버전업을 진행해 보았습니다.

우선 확인해 보면 사이드 프로젝트이지만, AI를 최대한 사용하고 있기 때문에 생각보다 변경 사항이 꽤 됩니다. 그래서 1.2.0에서 1.3.0으로 올리는 MINOR 업데이트를 제안했습니다. 그리고 MERGE 버튼을 딸깍하게 되면 배포가 되고 바로 다음과 같은 변경 사항이 배포됩니다.

이에 대한 디자인도 AI한테 적당히 만들어 달라고 요청했습니다. 적당한 카테고리 기준으로 깔끔한 디자인 시스템을 활용해서 만들어주는 것을 확인할 수 있었습니다.

공통 로직을 추출하기

다음으로는 공통 로직을 추출해서 리팩토링하는 Automation입니다. 제가 요새 리팩토링 2판(마틴 파울러 저)을 다시 읽으면서, 저만의 리팩토링 스킬을 만들려고 노력 중입니다. 그리고 이를 조금씩 활용해 보는 차원에서 이 공통 로직 자동화를 해보고 있습니다.

이것도 간략한 지침을 살펴보겠습니다.

• 코드베이스에 중복된 로직, UI, 스키마 등을 찾아, 프로젝트 규칙에 맞게 공용 로직 혹은 모듈로 추출하는 리팩토링 PR을 생성한다.
• PR은 단순히 하나의 논리적인 목적 단위로만 만들어야 한다. (number formatting 통합과 UI 통합은 하나의 PR에 들어갈 수 없다)
• 사전 읽기 규칙으로 해당 마크다운 파일들을 활용한다.
• 리팩토링을 실행하기 앞서 테스트 코드가 부족하다면 테스트 코드를 생성하고, 리팩토링 전후의 동작은 테스트 코드를 동일하게 통과한다.

그리고 이 Automation은 일주일에 한 번씩 돌고 있습니다. 매일 돌면 좋은데, 매일 리팩토링 PR을 리뷰할 자신이 없어서요. 따라서 한 주에 하나씩 개선하는 것만으로 우선 만족하며 사용 중입니다.

첫 번째 주를 보낸 뒤 생성된 PR을 확인해 보니, 6곳에서 중복 사용되던 로직을 공통 로직으로 추출하는 내용이었습니다. 히스토리를 살펴보니 특정 숫자가 입력되면 '○○만원' 형태로 포맷팅하는 간단한 로직이었는데, 이 기능이 개별 파일마다 직접 구현되어 있던 상황이었습니다.

그리고 자동으로 동작을 확인할 수 있도록 타입 체크, 린트, 테스트 코드가 정상 실행되었음을 보여주는 내용도 포함되어 있었습니다. 특히 고무적인 점은 다음 주 작업 후보에 대한 내용도 명시되어 있었다는 사실입니다. 실제로 코드를 살펴보니 바로 리팩토링할 대상이었습니다. 그래서 다음 주까지 기다리지 않고, 후속 PR을 만들어 즉시 처리해 버리기로 했습니다.

Sentry 버그를 자동으로 수정하기

Sentry 버그 자동 수정은 개발자들의 오랜 꿈인데요. 저 역시 '이슈 자동 생성'에서 '자동 해결'로 이어지는 흐름을 매번 꿈꿔왔지만, 수많은 시행착오와 장애물에 막혀 단 한 번도 완성하지 못했던 목표이기도 합니다. (이번에 과연 성공할 수 있을지는 아직 모르겠습니다.)

방법은 간단합니다. 

Triggers 부분에 프로젝트를 연결하고, 아직 unresolved된 이슈가 있다면 Automations를 돌리겠다고 만들면 됩니다. 그리고 이건 다른 Automations와 달리 Tools를 여러 개 붙여주었습니다.

그리고 한번 돌려보았습니다. 이 글을 쓰는 시점에서는 실제로 에러로그가 쌓이지 않아, 로컬에서 강제로 에러를 발생시키는 식으로 동작 방식을 확인했습니다.

실제로 돌려본 결과, 제가 사전에 정의한 Skip 기준에 맞춰 자연스럽게 무시한 것을 확인할 수 있었습니다. 다만 Sentry의 로깅 방식으로 하나의 에러에 대해 2가지 방식의 에러 로그가 쌓였고, 그 결과 중복된 Automation이 돌았습니다.

추가로 저는 이 자동화는 생각보다 위험할 수도 있겠다고 생각했습니다. 현재 연결한 프로젝트는 사이드 프로젝트라서, 일 방문자 수가 아직은 몇 백 명 수준입니다. 따라서 아직까지 Sentry 에러가 많이 발생하지 않았죠. 하지만 실제로 활발히 운영되는 프로젝트라면, Sentry 로그가 무지막지하게 쌓이는 모습을 볼 수 있을 겁니다. 실제로 에러인지 에러가 아닌지, 그 여부에 따지기 전에 모수가 많으면 어디선가는 에러가 터지기 마련이거든요.

그래서 Automations의 실행 주기를 조절할 수 있는 기능이 있으면 좋겠다고 생각했습니다. 맨 처음에는 Trigger에 Scheduled를 붙여 Hourly로 돌리면 가능하지 않을까 했습니다. 하지만 찾고 보니 해당 조건은 AND가 아닌 OR라고 합니다. 따라서 아직까진 제한 방법이 없다고 알고 있는데요. 자칫하다 토큰을 녹이는 대참사가 발생할 수 있으니, 조심해야겠습니다.

만들어진 것을 가져다 쓰자

오랜 격언 중에 “Don't reinvent the wheel(바퀴를 다시 발명하지 마라)”이 있습니다. 이미 누군가 검증하고 완성해 놓은 기존 기술이나, 라이브러리를 처음부터 다시 만들려고 하지 말라는 개발 격언입니다. 

이 격언에 따라, 가장 좋은 방법은 이미 누군가 만들어놓은 Automations를 가져다 사용하는 겁니다.

그리고 이런 잘 만들어진 Automation를 보면서 어떤 식으로 작성하는지, 어떤 식으로 연결하는지 확인하고 이젠 바퀴가 아닌 진정으로 필요한 것을 만들 때 적절하게 활용할 수 있습니다.

제가 알기로는 PR reviewers를 적절하게 할당하는 것은 꽤 어렵습니다. 따라서 일반적으로 그룹을 지정해 놓고 해당 그룹 내에 랜덤으로 분배하는 식으로 많이 합니다.

하지만 이 Automation를 보고, git history를 통해 해당 PR에서 어떤 사람이 가장 많은 연관성을 가지고 있는지 식별할 수 있겠다고 느꼈습니다. 그리고 그 개발자에게 바로 할당하면 굳이 reviewer를 신경 쓰지 않아도, 적합한 사람에게 할당이 될 겁니다. (안타깝게도 제가 하는 사이드 프로젝트는 저 혼자라 reviewer가 필요 없긴 합니다.) 아무튼 이런 방식으로 다른 사람이 만들어둔 Automation를 통해 간단히 시도해 볼 수도 있습니다.

Cursor Automations 후기

한 마디로 정리하면, 커서 Automations는 “매우 편리하니 실무에 바로 적용하자”라고 할 수 있습니다. 요즘 회사에서 많은 시간을 쏟는 부분은 반복되는 업무를 추출하여 자동화하는 일입니다. 하지만 이런 식의 자동화는 결국엔 우리가 직접 호출해야 하는 반자동화에 가깝습니다.

하지만 Cursor Automations는 다릅니다. Instructions를 한 번 써두면, 스케줄이나 이벤트에 맞춰, Cloud Agent가 알아서 실행됩니다. 그리고 사이드 프로젝트에서 한 달 동안 사용해 보니, 그 수준은 이미 충분히 합리적입니다. 또한 위에서 본 Reviewer 할당 예시를 보면, 우리가 평소에 제한적으로 사용했던 자동화를 실용적인 수준으로 확실히 끌어올릴 수 있습니다.

저는 한 달 동안 릴리즈 노트 PR 4개와 중복 코드 추출 PR 3개를 처리했습니다. 월요일마다 버전 업되는 코드와 자동으로 리팩토링을 제안해 주는 PR를 보면서 한 주를 시작합니다. 그리고 머지않아 Sentry 버그 PR을 읽고 나서, PR을 검증해 보고 이슈 해결을 하는 날도 생길 겁니다.

마치며: 진정한 의미의 페어 프로그래밍의 시대

저는 분명히 혼자 사이드프로젝트를 하고 있는데, 자꾸 누군가와 협업하는 느낌이 납니다. 제가 모르는 이슈와 리팩토링 해야 하는 부분을 찾아와, 같이 코드를 살펴보자고 말하는 동료 개발자가 어딘가 숨어있는 느낌입니다.  이전에 40년 차 프린시펄 개발자가 말하기를, 본인은 요새 AI와 페어프로그래밍을 하고 있다는 말을 했습니다. 저는 이번 Automations를 활용해 보면서 그 말에 공감했습니다. 

단순히 코드 라인 단위의 페어프로그래밍을 벗어나, 진정한 의미의 협업, 페어 프로그래밍 이젠 가능한 시대가 되었습니다. 어찌 보면 ‘개발자가 말하지 않아도 코드베이스가 개선된다’라는 건, 개발자 자리를 위협하는 것처럼 들릴 수 있습니다. 

하지만 저는 이 부분을 다르게 봅니다. 원래 개발자들은 그런 사람들입니다. 가장 귀찮았던 일을 찾아내고, 자동화하고, 더 단순하게 만들려는 욕심이 가득한 사람들이죠. 릴리즈 노트 정리, 중복 유틸 추출, 문서화 정리, 버전 업데이트 등 솔직하게 재미없는 일이지만, 꼭 해야 하는 일이기도 했습니다. (Sentry 이슈 해결은 논외입니다. 이건 무조건 해야 하는 일입니다.) 

Automations는 그 귀찮은 구간을 백그라운드로 밀어냅니다. 그리고 그렇게 만들어진 소중한 시간을, 개발자는 원래 하고 싶었던 일에 쏟아낼 수 있습니다. 이 변화는 제가 평소에 생각하는 개발 철학인 “편리함을 추구하는 개발”에 가장 근접한 모습이기도 합니다. 

AI로 인해 제 개발 철학에 가장 가까워진 지금, AI는 축복일까요? 아니면 저주일까요? 적어도 저는 요새 행복하다고 느낍니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.