AI에게 일을 맡기기보다, 검증 가능한 작업 흐름을 설계한다

속도보다 중요해진 것

AI를 개발과 문서 작업에 본격적으로 사용하면서 가장 먼저 체감한 장점은 속도였다. 여러 문서를 한꺼번에 읽고 공통점을 찾거나, Git·SVN 커밋 이력을 분류하거나, 기존 코드의 변경 후보를 정리하는 일은 사람이 처음부터 모두 처리할 때보다 훨씬 빨라졌다. 포트폴리오와 기술 블로그처럼 동일한 사실을 서로 다른 형식으로 다시 구성하는 작업에도 효과가 컸다.

하지만 오래 사용할수록 더 중요하게 보인 것은 속도가 아니었다. AI는 정답뿐 아니라 그럴듯한 오답도 매우 빠르게 만든다. 자료에 없는 역할을 자연스럽게 보충하고, 검토한 기술을 실제 적용한 것처럼 바꾸며, 개발 완료와 운영 반영을 한 문장 안에서 섞기도 한다. 소스 수정 작업에서는 테스트를 실행하지 않았는데도 완료된 것처럼 요약하거나, 내가 요청하지 않은 범위까지 “개선”이라는 이름으로 건드릴 수 있다.

그래서 지금은 AI에게 좋은 답을 한 번 받아내는 것보다, AI가 틀리더라도 어느 단계에서 틀렸는지 확인하고 다시 실행할 수 있는 작업 구조를 만드는 데 더 신경 쓴다. 내가 AI를 사용하는 방식의 핵심은 프롬프트 기법이 아니라 다음 질문에 가깝다.

무엇을 사실로 볼 것인가? AI가 판단해도 되는 범위는 어디까지인가? 작업이 끝났다고 말하려면 어떤 증거가 필요한가?

긴 프롬프트만으로는 해결되지 않았던 문제

처음에는 요청을 자세히 쓰면 결과가 안정될 것이라고 생각했다. 실제로 목적, 배경, 원하는 형식까지 구체적으로 적으면 짧은 요청보다 결과가 좋아졌다. 그러나 자료와 작업이 누적되자 프롬프트의 길이만으로는 해결되지 않는 문제가 나타났다.

첫째, 대화마다 참조하는 시점이 달랐다. 예전 문서와 최신 문서가 함께 있으면 AI는 어느 쪽이 현재 기준인지 스스로 안정적으로 판단하지 못했다. 둘째, 같은 사실이 이력서, 경력기술서, 포트폴리오에 조금씩 다른 문장으로 존재하면서 서로 다른 사실처럼 증식했다. 셋째, 커밋 작성자나 메일 발신자처럼 일부 행위를 보여 주는 증거가 프로젝트 전체의 책임 범위로 확대되기도 했다. 넷째, 계획 수립, 코드 수정, 테스트, 배포, 운영 확인이 모두 “작업 완료”라는 표현 하나로 뭉개졌다.

이 문제를 겪고 나서 신뢰성을 AI의 기억이나 문장 생성 능력에 맡기지 않기로 했다. 대신 AI 바깥에 기준 자료와 상태, 검증 규칙을 두고 AI가 그 안에서 작업하도록 구조를 바꿨다.

원본 증거, 검색 데이터, 사실 원본, 공개 결과물을 분리한다

현재 경력 자료를 다룰 때는 정보를 대략 네 계층으로 나눈다.

이 구조에서 원본 증거와 AI용 검색 데이터는 같은 것이 아니다. 원본 메일, 소스, 커밋 diff는 정확한 확인에 필요하지만 분량이 크고 민감정보를 포함할 수 있다. 반면 AI가 매번 원문 전체를 읽게 하면 비용이 커지고, 필요한 사실보다 노이즈가 많아진다. 따라서 원본은 별도로 보존하고, 검색용 계층에는 저장소, 리비전, 변경 경로, 날짜, 비식별 요약과 같은 정보를 정규화해 넣는다.

검색 결과도 곧바로 사실이 되지는 않는다. 예를 들어 특정 파일을 수정한 커밋은 그 변경에 참여했다는 근거가 될 수 있지만, 프로젝트 전체를 주도했다거나 운영 성과까지 책임졌다는 근거는 아니다. AI가 만드는 경력 연결 정보도 우선은 후보일 뿐이다. 관련 원문과 기존 사실을 확인하고 나서만 마스터에 반영한다.

이렇게 계층을 나누면 파생 문서가 잘못되었을 때 수정 방향도 명확해진다. 표현만 어색하면 포트폴리오나 글을 고치면 된다. 반대로 역할, 기간, 상태가 잘못됐다면 파생 문서 하나만 고치는 것이 아니라 사실 원본을 먼저 바로잡고 관련 결과물을 다시 동기화한다.

사실뿐 아니라 상태도 데이터로 관리한다

AI가 특히 자주 혼동하는 것은 “무엇을 했는가”보다 “어디까지 했는가”였다. 기술을 조사한 것과 도입한 것, 개발한 것과 운영에 반영한 것, 팀이 달성한 것과 내가 직접 수행한 것은 문장만 비슷할 뿐 전혀 다른 사실이다.

그래서 경력 사실에는 confirmed, confirmed_with_limits, pending, excluded 같은 상태를 둔다.

• confirmed: 사실과 수행 범위가 확인된 항목
• confirmed_with_limits: 사실은 확인됐지만 표현하거나 입증할 수 있는 범위에 제한이 있는 항목
• pending: 추가 확인이 필요한 후보
• excluded: 공개 결과물과 경력 문서에서 제외할 항목

프로젝트 역시 완료, 진행 중, 검토만 수행, 제외 상태를 구분한다. 필요하면 not_claimed, open_questions, visibility처럼 주장하지 말아야 할 범위와 남은 질문, 공개 가능 범위도 함께 기록한다.

이 방식의 목적은 JSON을 복잡하게 만드는 것이 아니다. AI가 빈칸을 자연스러운 문장으로 채우는 순간에도 넘지 말아야 할 경계를 데이터로 고정하는 것이다. pending인 사실은 문장이 아무리 좋아도 공개하지 않고, 기술 검토는 구현 성과로 바꾸지 않으며, 내부 증빙이 존재하더라도 공개 가능하다는 별도 근거가 없으면 원문을 노출하지 않는다.

AI가 기억하게 하지 않고, 검색하고 연결하게 한다

대규모 자료를 AI와 함께 다룰 때 가장 효과가 컸던 작업 중 하나는 Git·SVN 커밋 이력을 검색 가능한 구조로 바꾸는 일이었다. 수백 개의 커밋과 긴 diff를 대화창에 그대로 넣는 대신 다음 흐름으로 처리했다.

1. 원본 파일과 체크섬을 보존한다.
2. 저장소, 커밋 또는 리비전, 작성 시각, 변경 경로, 메시지를 구조화한다.
3. 계정, 내부 주소, 고객·주문 식별정보 등 공개에 부적절한 값을 제거하거나 일반화한다.
4. 기존 프로젝트와 연결될 가능성이 있는 항목을 후보로 만든다.
5. 후보가 가리키는 원문과 다른 증빙을 확인한다.
6. 확인된 사실만 기준 원본에 병합한다.

여기서 AI의 역할은 모든 사실을 최종 판정하는 것이 아니라, 사람이 전체 자료를 순서대로 읽을 때 놓치기 쉬운 후보를 빠르게 찾고 관계를 제안하는 것이다. “이 커밋이 어느 프로젝트와 관련될 가능성이 높은가?”, “기존 설명에서 빠진 구현 범위가 있는가?”, “서로 다른 자료가 같은 장애를 가리키는가?” 같은 질문에는 강하다.

반면 “이 사람이 프로젝트를 주도했는가?”, “운영 반영으로 어떤 성과가 확정됐는가?” 같은 질문은 커밋 하나만으로 답할 수 없다. 이 경계를 명확히 할수록 AI의 검색 능력은 활용하면서도 과장된 결론은 줄일 수 있었다.

프롬프트는 질문이 아니라 작업 계약에 가깝다

코드나 사이트를 수정할 때는 “깔끔하게 개선해 줘”와 같은 요청을 거의 사용하지 않는다. 개선의 의미가 사람마다 다르고, AI는 요청하지 않은 변경도 선의의 개선으로 해석할 수 있기 때문이다.

대신 프롬프트에 다음 항목을 넣는다.

• 작업 목적과 사용자가 보게 될 최종 결과
• 수정할 파일과 수정하지 않을 범위
• 반드시 보존할 공개 API, 파일명, 계산식, 처리 순서, 예외 동작
• 참조해야 할 사실 원본과 우선순위
• 작업 전에 확인할 현재 상태
• 변경 순서와 실패 시 중단 조건
• 실행해야 할 전용 테스트와 회귀 테스트
• 커밋·푸시·배포 권한의 범위
• 완료 보고에 포함할 검증 결과

예를 들면 다음과 같은 형태다.

아래 코드는 문제 해결 구조를 설명하기 위한 pseudocode이며 실제 클래스·테이블·설정 이름과는 무관합니다.

지정한 파일만 수정한다.
공개 메서드 시그니처, 호출 순서, 기존 예외 동작은 유지한다.
먼저 실제 소스와 현재 변경사항을 확인한다.
수정 후 전용 테스트와 연관 회귀 테스트를 실행하고 git diff --check를 확인한다.
확인하지 못한 항목은 통과했다고 쓰지 않는다.
명시적으로 요청하지 않은 commit, push, deploy는 수행하지 않는다.

중요한 것은 문장을 길게 쓰는 것이 아니라 불변 조건과 완료 조건을 실행 가능한 형태로 만드는 것이다. 특히 레거시 리팩터링처럼 결과의 모양은 같아야 하지만 내부 책임을 옮겨야 하는 작업에서는 “더 좋은 구조”보다 “무엇이 절대 달라지면 안 되는가”를 먼저 적는다.

작업도 가능한 한 작은 단위로 나눈다. 한 번에 여러 구조를 바꾸면 테스트가 실패했을 때 원인을 찾기 어렵고, AI도 서로 다른 요구사항을 혼합하기 쉽다. 좁은 범위의 변경을 수행하고 검증한 뒤 다음 단계로 넘어가면, 문제가 생겨도 되돌릴 범위가 작아진다.

분석, 수정, 배포는 서로 다른 권한이다

AI 도구는 요청보다 앞서 나가려는 경향이 있다. 원인을 조사해 달라고 했는데 코드를 수정하거나, 로컬 수정을 요청했는데 커밋과 배포까지 진행하면 기술적으로 좋은 결과여도 작업 통제에는 실패한 것이다.

그래서 다음 단계를 명시적으로 구분한다.

1. 현재 상태 조사
2. 원인과 대안 분석
3. 수정 계획 확정
4. 소스 또는 콘텐츠 변경
5. 로컬 검증
6. 커밋과 원격 반영
7. 배포
8. 실제 운영 환경 확인

반대로 처음부터 운영 반영까지 요청한 작업이라면 계획이나 로컬 수정에서 멈추는 것도 완료가 아니다. 사이트 작업의 경우 빌드가 성공했더라도 실제 운영 주소에서 페이지가 열리는지, 모바일 레이아웃과 링크가 정상인지, robots.txt, sitemap, canonical 같은 외부 노출 요소가 의도대로 보이는지까지 확인해야 한다.

즉, AI에게 자율성을 얼마나 줄 것인지는 항상 많이 또는 적게의 문제가 아니다. 이번 요청에서 허용된 단계가 어디까지인지의 문제다.

완료 보고는 설명이 아니라 증거의 색인이어야 한다

AI가 “수정했습니다”, “테스트를 통과했습니다”, “배포했습니다”라고 말하는 것 자체는 증거가 아니다. 그래서 작업 종류마다 완료 조건을 따로 둔다.

코드 작업에서는 git status, git diff, git diff --check, 컴파일, 대상 테스트와 회귀 테스트 결과가 주된 근거가 된다. 콘텐츠 작업에서도 원리는 같다. 최신 기준 원본과 비교했는지, 제외 항목이 다시 들어오지 않았는지, 링크와 화면이 실제로 동작하는지 확인한다.

완료 보고에는 화려한 요약보다 “어떤 파일이 바뀌었고, 무엇을 실행했으며, 무엇은 확인하지 못했는가”가 필요하다. 보고서는 결과를 대신하는 문서가 아니라, 결과를 다시 확인할 수 있게 만드는 색인에 가깝다.

AI의 오답을 예외가 아니라 기본 전제로 둔다

AI를 쓰면서 가장 위험했던 순간은 명백히 틀린 답을 받았을 때가 아니었다. 잘못된 내용이 자연스러운 문장과 자신감 있는 완료 보고 안에 들어 있을 때였다.

이런 경우에는 AI에게 같은 질문을 더 강하게 반복하는 것보다 작업 구조를 고치는 편이 효과적이었다.

1. 실제 파일, 로그, 화면, 명령 결과와 보고가 일치하는지 확인한다.
2. 불일치가 있으면 요약문이 아니라 근거가 생성되는 단계로 돌아간다.
3. 확인되지 않은 항목은 pending 또는 미확인으로 남긴다.
4. 사실 문제라면 파생 결과물만 고치지 않고 기준 원본을 수정한다.
5. 같은 오류가 반복되지 않도록 스키마, 검증 스크립트, 회귀 테스트 또는 체크리스트를 추가한다.

예를 들어 제외하기로 한 경력이 다시 포트폴리오에 나타난다면 해당 문장만 삭제하고 끝내지 않는다. 왜 파생 과정에서 제외 상태가 무시됐는지 확인하고, 다음 생성에서도 자동으로 차단되도록 검증 규칙을 보완한다. AI의 실수를 그때그때 교정하는 데서 끝내지 않고, 실수가 통과한 경로를 닫는 것이다.

결국 중요한 원칙은 단순하다.

AI가 틀리지 않을 것이라고 기대하지 않는다. 틀려도 발견되고, 잘못된 결과가 다음 단계로 넘어가지 않게 만든다.

민감정보는 입력 이후가 아니라 검색 계층을 만들 때부터 통제한다

회사 업무 자료에는 서버명, 사내 주소, 계정, 고객·주문 정보, 연락처, 인증정보처럼 공개하거나 불필요하게 복제해서는 안 되는 값이 섞여 있다. AI에게 자료를 넣은 뒤 출력에서만 지우는 방식은 충분하지 않다. 검색용 데이터를 만드는 단계에서부터 필요한 정보와 불필요한 식별정보를 분리해야 한다.

원본의 복구와 무결성 확인이 필요한 자료는 제한된 보존 계층에 두고, 일반 분석에는 비식별된 정규화 데이터를 사용한다. 공개 글에는 기술적 판단을 이해하는 데 필요한 구조만 남기고 실제 내부 이름, 주소, 고객 식별정보, 비공개 소스와 diff는 사용하지 않는다.

이 원칙은 보안만을 위한 것이 아니다. 구체적인 내부 명칭에 의존하지 않고도 문제, 판단, 구현, 검증 과정을 설명하도록 만들기 때문에 기술 글의 품질도 오히려 좋아진다.

AI가 실제로 잘하는 일과 맡기지 않는 일

이런 통제 구조를 두더라도 AI의 가치가 줄어드는 것은 아니다. 오히려 잘하는 일을 더 적극적으로 맡길 수 있다.

AI는 대량 자료에서 후보를 발굴하고, 서로 다른 문서의 불일치를 찾고, 같은 사실을 포트폴리오·이력서·기술 글의 목적에 맞게 재구성하는 데 유용하다. 코딩에서는 반복적인 수정, 영향 범위 탐색, 테스트 후보 제안, 실패 로그 요약에 강하다. 내가 놓친 예외 조건이나 반대 선택지를 제시하는 검토자로도 가치가 있다.

반면 최종 사실 판정, 공개 가능 여부, 수행 범위의 확정, 위험한 변경의 승인까지 AI에게 넘기지는 않는다. 이 판단들은 자료의 의미와 책임을 함께 고려해야 하기 때문이다. AI는 판단을 대체하는 존재라기보다, 판단에 필요한 자료를 더 빨리 모으고 판단 기준을 더 명시적으로 만들도록 돕는 도구에 가깝다.

모든 작업에 같은 수준의 절차를 적용할 필요도 없다. 단순한 문장 교정에는 바로 결과를 받아도 된다. 영향이 제한된 수정에는 범위와 한두 개의 검증 조건이면 충분하다. 반면 경력 사실, 운영 코드, 배포, 보안 관련 자료처럼 잘못됐을 때 비용이 큰 작업에는 기준 원본, 상태, 테스트, 승인 단계와 운영 확인까지 둔다. 통제 비용 역시 위험에 비례해야 한다.

프롬프트보다 재현 가능한 시스템

AI 활용 능력을 흔히 질문을 잘 쓰는 능력으로 설명한다. 물론 명확한 요청은 중요하다. 하지만 실제 작업을 반복해 보니 더 큰 차이는 프롬프트 한 문장보다 그 앞뒤의 구조에서 생겼다.

• 원본과 파생물을 구분하는가
• 확정 사실과 후보를 구분하는가
• 검색 결과와 최종 판단을 구분하는가
• 분석, 수정, 배포의 권한을 구분하는가
• 완료를 주장할 수 있는 검증 증거가 있는가
• 잘못됐을 때 기준 원본에서 다시 생성할 수 있는가

좋은 AI 활용은 매번 완벽한 답을 받는 것이 아니다. 같은 자료와 규칙으로 다시 실행할 수 있고, 결과가 달라졌을 때 그 이유를 추적할 수 있으며, 틀린 결과가 공개나 운영 단계까지 넘어가기 전에 막을 수 있는 상태를 만드는 것이다.

나는 AI에게 일을 통째로 맡기기보다, AI가 일할 수 있는 경계와 근거, 완료 조건을 먼저 설계한다. 이 방식은 처음에는 번거로워 보이지만 자료와 작업이 쌓일수록 차이가 커진다. 빠르게 만든 결과를 사람이 다시 처음부터 의심하는 대신, 어디를 확인해야 하는지 알 수 있기 때문이다.

결국 내가 AI를 사용하는 방식은 자동화에 판단을 넘기는 것이 아니라, 내 판단 과정을 검토 가능하고 반복 가능한 형태로 바꾸는 일에 가깝다.