AI를 업무에 어떻게 쓰고 있나

24년 말을 마지막으로 블로그에 글을 안 쓴 지 1년 반쯤 됐다. 바빴다는 핑계가 절반, 딱히 정리해서 남길 만한 게 없다는 핑계가 절반이었다. 근데 막상 지난 1년 반을 돌아보니 내 업무 방식에서 가장 크게 바뀐 게 하나 있었다. AI랑 일하는 방식이다. 그 얘기를 해보려 한다.

처음엔 그냥 시켰다#

AI를 업무에 쓴 건 꽤 됐다. 22년쯤 Copilot을 쓰긴 했지만 그건 다음 줄을 슬쩍 제안해주는 자동완성에 가까웠다. 24년쯤부터 Cursor를 이용해서 이것저것 시켜보긴 했어도 본격적이라기보단 부가적인 도구 느낌이었다. 코드는 여전히 내가 짰고, AI는 옆에서 거들 뿐이었다. 그러다 맡기는 비중이 슬슬 늘었다. 처음엔 다들 그렇듯 그냥 시켰다. "이거 만들어줘", "이 버그 고쳐줘"라고 채팅창에 던지고 나온 결과를 적당히 손보는 식이었다. 잘 될 때는 정말 잘 됐다. 근데 그 "잘 될 때"가 내 마음대로 안 됐다.

같은 작업을 시켜도 어제 받은 코드랑 오늘 받은 코드의 스타일이 달랐다. 어떤 날은 내 프로젝트 컨벤션을 잘 따라줬고, 어떤 날은 멋대로 새로운 폴더 구조를 만들거나 우리 쪽에선 안 쓰기로 한 패턴을 가져왔다. 자동 생성되는 코드를 직접 고쳐서 다음 빌드 때 그 변경분이 통째로 날아가게 만든 적도 있고, 시키지도 않은 리팩토링을 슬쩍 끼워 넣어서 리뷰를 어렵게 만든 적도 있었다.

제일 골치 아팠던 건 할루시네이션이었다. 안 한 걸 했다고 하거나, 테스트가 실패했는데 통과한 것처럼 말하는 경우다. 그걸 한두 번 놓치고 나니 결과물을 매번 처음부터 다시 검수하게 됐고, 그럴 거면 직접 짜는 게 빠른 거 아닌가 싶은 순간이 자주 왔다.

문제는 AI가 아니라 내 입력이었다#

한동안은 모델 탓을 했다. 근데 가만히 보니 출력이 흔들리는 진짜 이유는 내 입력이었다. AI의 결과물은 내가 어떻게 묻느냐에 따라 매번 달라진다. 같은 작업도 그날 내 컨디션이나 프롬프트 길이에 따라 결과가 출렁였고, 팀원마다 묻는 방식이 다르니 같은 코드베이스에 들어오는 코드의 편차는 더 컸다.

생각해보면 신입이 한 명 들어온 거랑 비슷하다. 아무리 똑똑한 신입이어도 팀 컨벤션 문서를 안 보면 자기 스타일대로 짠다. 그럼 문서를 주면 된다. AI한테도 똑같이 해주면 되는 거였다.

그래서 규칙(Rules)부터 적었다#

25년 들어선 매번 같은 잔소리를 반복하는 대신, 작업할 때마다 머릿속으로 묻던 질문들을 글로 적기 시작했다. 대충 이런 것들이다.

1. 이 작업에서 반드시 지켜야 할 프로젝트 규칙은 무엇인가?
2. 테스트를 새로 만들거나 고쳐야 하는가?
3. 코드 스타일·파일 구조·네이밍이 기존 패턴과 일치하는가?
4. 끝나고 무엇으로 검증할 것인가?

좋은 코드란 뭔가 같은 추상적인 얘기는 일부러 안 적었다. 대신 매 상황에서 어느 쪽을 고를지 정해주는 규칙으로 적었다. AI가 헷갈릴 여지를 줄이는 게 목적이었으니까.

그리고 규칙 중에서도 절대 어기면 안 되는 것들은 따로 "절대 금지" 목록으로 빼뒀다. 예를 들면 이런 것들이다.

• 모르면 추측해서 짜지 말고 관련 파일을 읽어라. 그래도 모호하면 나한테 물어봐라.
• 내가 시키지 않은 리팩토링·포맷팅을 끼워 넣지 마라.
• 안 한 걸 했다고 보고하지 마라. 실패는 실패라고 말해라.

이 목록을 작업 맥락에 항상 깔아두니 앞에서 겪은 사고가 눈에 띄게 줄었다.

한 덩어리로 두면 안 됐다#

근데 규칙을 적다 보니 양이 금방 불어났다. 프레임워크 규칙, 파일 배치 규칙, 커밋 규칙, 테스트 규칙... 이걸 전부 한 파일에 넣고 매 작업마다 통째로 읽히면, 정작 그 작업에 필요한 규칙은 묻히고 맥락만 잡아먹는다. AI한테도 필요 없는 정보를 잔뜩 읽는 건 비용이고 노이즈다.

규칙이 이렇게 자라는 동안 도구도 같이 옮겨갔다. 25년 중순까지는 주로 Cursor를 썼는데, 규칙이 하나의 환경으로 굳어질수록 그걸 더 잘 받아주는 Claude Code 쪽으로 점점 기울었다. 옮겨가는 동안엔 두 도구가 같은 규칙을 보도록 원본을 가리키기만 하는 얇은 파일을 도구마다 하나씩 만들어 뒀다.

그렇게 Claude Code로 기울던 25년 가을, Anthropic이 Agent Skills를 발표했다. 필요한 규칙만 그때그때 꺼내 읽도록 영역별로 묶어두는, 이른바 점진적 공개(progressive disclosure)라는 발상이었다. 비대해진 규칙 파일을 앞에 두고 내가 어렴풋이 더듬던 구조와 거의 그대로 맞아떨어졌다.

그래서 코딩 컨벤션부터 그 형식에 맞춰 스킬 하나로 다시 짰다. 진입점이 되는 요약 문서 하나를 짧게 두고, 상세 규칙은 영역별로 파일을 쪼갰다. 요약 문서에는 "이 영역 코드를 건드릴 거면 그때 이 상세 파일을 읽어라"라는 지도만 박아뒀다. 테스트 작업이면 테스트 규칙만, 파일을 새로 만드는 작업이면 파일 배치 규칙만 펼쳐 읽는 식이다.

규칙에도 강약이 있다#

스킬이 규칙을 묶은 덩어리라면, 정작 손이 많이 간 건 그 안의 규칙 하나하나였다. 처음엔 모든 규칙을 다 "무조건 지켜"로 적었는데 그게 오히려 독이었다. 진짜로 어기면 빌드가 깨지는 규칙과 그냥 우리가 선호하는 스타일일 뿐인 규칙이 같은 무게로 적혀 있으니, AI가 더 나은 선택지가 명백한 상황에서도 어설픈 규칙에 발이 묶였다.

그래서 규칙마다 강약을 표시했다. 반드시 지켜야 하는 것, 기본적으로 따르되 더 나은 이유가 있으면 바꿔도 되는 것, 그냥 점검만 하면 되는 것. 대신 선호 규칙을 어겼으면 왜 어겼는지를 보고에 남기게 했다. 무조건 따르라고만 하면 판단을 멈추고, 다 알아서 하라고 하면 제멋대로 간다. 결국 그 사이 어디쯤을 내가 계속 만져줘야 했다.

이렇게 규칙을 스킬 형식으로 다시 짜고 강약까지 정리하고 나니, 25년 말엔 도구도 거의 Claude Code로 굳었다.

어느새 작은 시스템이 됐다#

이렇게 정리한 코딩 컨벤션 스킬이 잘 돌아가니까 비슷한 게 자꾸 늘었다. 변경사항을 커밋 전에 스스로 점검하는 리뷰용 스킬, 화면 만들 때 어떤 UI 컴포넌트를 고를지 정해주는 스킬, 코드 작업 전에 스펙 문서를 먼저 확인하게 하는 스킬도 생겼다. 어떤 상황에서도 항상 깔려 있어야 하는 절대 규칙은 따로 빼서 늘 읽히게 해뒀다.

정신 차려보니 이게 규칙 몇 개가 아니라 AI가 일할 환경을 통째로 만드는 일이 돼 있었다.

그렇게 환경을 갖추고 나니 26년 들어선 코드를 거의 직접 안 짜게 됐다. 예전 같으면 못 미더워서 결국 내가 다시 손댔을 일도 이제는 어지간하면 믿고 맡긴다. 24년에 부가적인 도구로 가끔 쓰던 걸 생각하면 2년 만에 꽤 멀리 온 셈이다.

바이브 코딩에서 하네스로#

요즘 나오는 얘기를 보면 이게 나 혼자만의 경험은 아닌 것 같다.

화두가 바뀌는 속도가 특히 빠르다. 23 ~ 24년쯤엔 프롬프트를 얼마나 잘 쓰냐(prompt engineering)가 전부였다. 그러다 25년 초, 채팅창에 떠오르는 대로 던지고 결과를 받아 쓰는, 이른바 바이브 코딩(vibe coding)이 유행했다. 빠르고 재밌지만 내가 앞에서 겪은 사고들이 딱 이 방식의 한계다. 그리고 25년 하반기부터는 그 반작용으로, 코드를 그냥 믿고 던지는 대신 규칙·테스트·문서로 둘러싸자는 흐름이 떴다. Simon Willison은 이걸 바이브 엔지니어링(vibe engineering)이라 부르기도 했다. prompt에서 vibe로, 다시 그 너머로. 2 ~ 3년 사이에 화두가 두 번이나 갈린 셈이다.

내가 만든 것 같은 환경을 좀 더 넓게 보면 하네스(harness)라고 부른다. 똑똑한 모델 하나로 끝내는 게 아니라 걔한테 뭘 읽히고 어떤 규칙·검증·도구로 둘러쌀지까지 같이 설계하자는 얘기다. 모델을 둘러싼 그 환경 전체가 하네스고, 거기에 무엇을 어떻게 채울지 다루는 일을 컨텍스트 엔지니어링(context engineering)이라 부른다. 모델은 어차피 계속 좋아질 테니 결국 손댈 데는 그 바깥이라는 거다.

물론 이 규칙들도 완성된 건 아니다. 새 프로젝트 사정이 생기면 고치고, AI가 엉뚱하게 해석하는 규칙이 보이면 문구를 다듬는다. 컨벤션 문서를 사람이 아니라 AI를 1차 독자로 두고 계속 손보는 셈인데, 이 작업이 생각보다 재밌다.

키워드는 이렇게 빠르게 갈렸지만, 그 사이 내가 실제로 한 일은 늘 비슷했다. 그때그때 가장 잘 먹히는 방식으로 갈아타며 일하는 환경을 새로 맞춘 것뿐이다. 결국 어떤 기법 하나를 끝까지 파고드는 것보다, 판이 이렇게 빨리 바뀐다는 걸 받아들이고 그 흐름을 계속 따라가는 쪽이 진짜 관건 아닐까 싶다.

다음 1년은 이게 또 어떻게 바뀌어 있을지 궁금하다. 그때에도 내가 또 새로운 환경에 적응해있길 바랄뿐이다.