AI와 암묵지
AI가 나를 대체할 수 있게 일하기
AI Coding Harness를 쓰면서 가장 크게 느낀 것은 AI를 잘 쓰는 능력이 “AI에게 많이 맡기는 능력”이 아니라는 점이다. 오히려 내가 문제를 더 잘 이해하고 맥락을 더 정확히 알고 결과물의 기준을 더 분명하게 가질수록 AI를 더 잘 드라이브할 수 있었다.
AI Coding Harness를 쓰는 경험은 나에게 “위임”이라는 일을 다시 생각하게 만들었다.
AI는 내가 아는 만큼 더 잘 움직인다
처음에는 AI를 잘 쓰는 사람이 프롬프트를 잘 쓰는 사람이라고 생각하기 쉽다. 물론 프롬프트도 중요하다. 하지만 실제로 써보면 프롬프트 문장보다 그 안에 들어가는 맥락의 질이 더 중요하다.
내가 도메인을 잘 모르면 AI에게도 애매하게 말하게 된다.
“이거 좀 고쳐줘.” “아까 말한 방식으로 해줘.” “적당히 분리해줘.” “이 부분 자연스럽게 바꿔줘.”
사람에게도 이런 말은 어렵다. 듣는 사람은 “이거”가 무엇인지, “아까 말한 방식”이 정확히 어떤 기준인지 계속 추측해야 한다. AI와 일할 때는 이 문제가 더 노골적으로 드러난다. AI는 내가 생략한 맥락을 알아서 정확히 복원하지 못하고, 복원하더라도 그것은 어디까지나 확률적인 추측이다.
그래서 AI를 잘 드라이브하려면 내가 먼저 명확해야 한다. 무엇을 왜 바꾸는지, 어떤 제약이 있으며 좋은 결과와 나쁜 결과가 어디서 갈리는지, 이번 작업에서 절대 건드리면 안 되는 게 무엇인지, 어디까지는 AI가 결정해도 되고 어디부터는 내가 판단해야 하는지를 정리해두고 말해야 한다.
AI Coding Harness는 내가 가진 판단과 맥락을 실행 가능한 형태로 증폭해주는 도구에 가깝다.
애매한 지시대명사는 위임을 망친다
AI와 일하면서 가장 많이 체감한 것은 애매한 말의 비용이다.
사람과 일할 때도 우리는 생각보다 많은 암묵지를 지시대명사 뒤에 숨긴다.
“그거는 좀 별로예요.” “저번처럼 하면 될 것 같아요.” “느낌은 맞는데 조금 더 자연스럽게요.”
이런 말은 대화에서는 편하다. 서로 어느 정도 맥락을 공유하고 있다면 빠르게 넘어갈 수도 있다. 하지만 위임의 관점에서는 위험하다. 상대가 나와 같은 장면을 떠올리고 있다는 보장이 없기 때문이다.
AI와 일하면 이 문제가 훨씬 빨리 드러난다. AI는 “그거”를 모르고 “저번처럼”의 기준을 정확히 기억하지 못한다. “자연스럽게”라는 말 안에 들어 있는 내 취향, 제품 맥락, 팀의 기준, 독자의 기대를 자동으로 알지 못한다.
애매한 지시어는 결국 상대에게 추측을 떠넘기는 말이다. 내가 명확하게 말하지 않으면 AI는 빈칸을 채우는데, 그 빈칸은 내가 원한 것과 미묘하게 다를 가능성이 높다. 그 차이가 처음에는 작아 보여도 작은 추측들이 쌓이면 결과물은 어느 순간 내가 원한 방향과 멀어진다.
그래서 AI Coding Harness를 잘 쓰는 과정은 내 언어를 다듬는 과정이기도 했다. “이거 고쳐줘” 수준의 지시 대신 이렇게 말해야 한다.
study-operations.commands.ts에서 명령 핸들러의 책임이 도메인 로직까지 침범하지 않도록 분리해줘.
도메인 규칙은study-operations.domain.ts에 남기고, command layer는 입력 검증과 orchestration에 집중하게 해줘.
기존 테스트 의도는 유지하고, 실패하는 테스트가 있으면 어떤 책임 경계가 깨졌는지 설명해줘.
말이 길어지는 이유는 추측해야 하는 부분을 줄이기 위해서다.
암묵지를 드러내야 워크플로우가 된다
AI에게 일을 맡기다 보면 내가 평소에 얼마나 많은 것을 “그냥 알고 있다”고 처리했는지 보이기 시작한다. 어떤 코드는 건드리면 안 되고, 어떤 변경은 테스트를 먼저 봐야 하며, 어떤 구조는 우리 팀이 선호하지 않고, 어떤 수정은 지금 좋아 보여도 나중에 운영 비용을 만든다는 판단들이다.
이런 판단은 보통 머릿속에 있고, 머릿속에 있는 동안에는 나만 쓸 수 있다. 다른 사람에게도 AI에게도 위임하기 어렵다.
하지만 이것을 말로 꺼내는 순간 달라진다.
“우리는 이 레이어에서 비즈니스 규칙을 판단하지 않는다.” “이 테스트는 구현 세부사항보다 사용자 시나리오를 보호해야 한다.” “이 변경은 빠르게 끝내는 것보다 다음 사람이 읽을 수 있는 구조가 더 중요하다.” “이 작업은 먼저 현재 동작을 고정하고, 그 다음에 리팩터링한다.”
암묵지가 문장이 되면 체크리스트가 되고, 체크리스트가 쌓여 반복 가능한 절차가 되면 워크플로우가 되어 위임할 수 있다.
이 지점이 중요하다. AI를 잘 쓰는 일은 명령을 잘 내리는 기술이라기보다 내가 일하는 방식을 외부화하는 일이다. 내 머릿속에 있던 판단 기준을 꺼내 실행 가능한 순서로 바꾸고 다시 사용할 수 있는 형태로 만드는 일이다.
이 과정은 AI에게만 유용하지 않다. 사람과 일할 때도 똑같이 유용하다. 내가 AI에게 명확히 위임할 수 있는 일은 대체로 사람에게도 명확히 위임할 수 있고, AI에게 설명하기 어려운 일은 사람에게도 대부분 애매하게 전달되고 있었을 가능성이 높다.
AI는 나쁜 위임 습관을 빠르게 보여주는 거울에 가깝다.
판단 기준을 함께 넘기는 위임
많은 사람이 위임을 “작업을 쪼개서 넘기는 것”이라고 생각한다. 작업을 작게 나누는 것도 중요하지만 거기에 판단 기준이 함께 넘어가지 않으면 결과가 흔들린다.
예를 들어 “테스트를 추가해줘”라는 말은 작업을 넘긴 것 같지만 실제로는 많은 판단을 생략하고 있다. 어떤 동작을 보호해야 하는지, 회귀를 막기 위한 테스트인지 설계를 설명하기 위한 테스트인지, 단위 테스트인지 통합 테스트인지 같은 판단들이다.
이 기준 없이 일을 맡기면 결과물은 나올 수 있다. 하지만 그 결과물이 내가 원한 것인지 판단하려면 다시 많은 검토 비용이 든다. 그래서 좋은 위임의 핵심은 판단 기준을 드러내는 쪽에 있다.
AI Coding Harness를 쓸 때도 마찬가지다. AI에게 단순히 작업 목록을 주는 대신 그 작업을 수행할 때 따라야 할 원칙과 경계, 검증 방법을 같이 준다.
예를 들면 이런 식이다.
목표: 이 기능의 책임 경계를 명확히 한다.
원칙: 도메인 규칙은 domain layer에 둔다. command layer는 흐름 제어만 담당한다.
제약: public API는 바꾸지 않는다. 기존 테스트의 의미는 유지한다.
검증: 관련 테스트를 실행하고, 실패하면 변경이 잘못된 것인지 테스트가 낡은 것인지 구분해서 설명한다.
보고: 어떤 파일을 왜 바꿨는지, 남은 리스크는 무엇인지 정리한다.
이 정도로 말하면 AI는 내가 정한 기준 안에서 움직이는 실행자가 된다.
결국 위임의 품질은 “얼마나 많은 일을 넘겼는가”가 아니라, 얼마나 적은 추측으로 일하게 만들었는가로 결정된다.
AI가 나를 대체할 수 있게 만드는 태도
AI의 변화는 빠르다. 지금 익숙한 도구도 금방 바뀔 수 있고 오늘 어렵던 일이 내일은 훨씬 쉬워질 수 있다. 이런 변화를 보면 자연스럽게 방어적인 마음이 생긴다.
“AI가 내 일을 대체하면 어떡하지?” “내 역할은 어디에 남지?”
하지만 요즘은 조금 다르게 생각하게 된다. AI가 나를 대체하지 못하게 막는 것보다, AI가 나를 더 빨리 대체할 수 있을 정도로 내 일을 명확하게 만드는 것이 더 나은 전략일 수 있다.
처음에는 이상하게 들린다. 나를 대체할 수 있게 만든다는 말은 내 자리를 없애는 것처럼 느껴지기 때문이다. 하지만 실제로는 반대에 가깝다.
내가 하는 일을 설명할 수 없다면 그 일을 반복해서 직접 해야 하고, 내 판단 기준이 머릿속에만 있다면 매번 내가 병목이 된다. 내가 없어도 일이 굴러가게 만들 수 없다면 나는 더 큰 문제로 이동하기 어렵다.
반대로 내가 하는 일을 명확하게 설명하고 위임하고 워크플로우로 만들 수 있다면 나는 특정 작업에 갇히지 않는다. 그 일은 AI에게 맡길 수도 있고 동료에게 맡기거나 시스템으로 자동화할 수도 있다. 그러면 나는 다음 단계의 문제로 이동할 수 있다.
AI가 나를 대체할 수 있게 만드는 건 내가 하던 일을 나만 할 수 있는 형태로 붙잡아두지 않겠다는 뜻이다.
변화가 빠를수록 닫힌 자세로 버티기는 어렵다. 도구는 계속 좋아지고 자동화 가능한 영역은 계속 넓어진다. 이때 필요한 태도는 “그럼 어디까지 넘길 수 있고, 나는 다음에 무엇을 해야 하지?”라고 묻는 쪽이다.
마무리
AI Coding Harness를 쓰면서 위임에 대한 생각이 바뀌었다. AI를 잘 쓰는 사람은 도구를 많이 써본 사람이라기보다 자신이 아는 것을 명확하게 드러낼 수 있는 사람에 가깝다.
돌아보고 싶은 질문은 남는다. 내가 당연하게 여기는 판단 중에서 문장으로 꺼내지 못한 것은 무엇인가. 그걸 워크플로우로 만들어 나와 팀, 그리고 AI에게까지 맡길 수 있는가.
도구가 바뀔 때마다 이 질문에 다시 답하게 된다. 그래서 한 번 정해두고 끝나는 질문이 아니라 일하면서 계속 다듬어야 하는 질문으로 두려고 한다.