AI 도구를 많이 쓰면 일이 저절로 빨라질까? 내가 몇 년간 직접 써본 결론은 “그렇지 않다”에 가깝다. 현재 유료로 사용하는 AI는 ChatGPT, Claude, Gemini, Perplexity 네 가지다. 이 가운데 실제 업무와 취미 프로젝트에서 가장 자주 여는 것은 ChatGPT와 Claude다.
나는 40대 직장인이고, 회사명과 실명은 공개하지 않는다. AI를 주로 법령 검토, 논리 점검, 문서 검토에 사용하고 취미로는 arbiterOS를 만들며 바이브코딩을 배우고 있다. 예전에는 AI에게 질문하고 답변을 복사하는 데 그쳤지만, 이제는 에이전트에게 파일을 살펴보고 코드를 수정하고 결과를 검증하게 한다.
그 과정에서 배운 가장 중요한 사실은 이것이다. AI 시대의 실력은 답을 빨리 받는 능력보다, 작업을 작게 정의하고 마지막 판단을 직접 하는 능력에 가깝다.
AI 구독 유지 판단, 자동화의 완료 검증, 개인정보 보호의 상세 사례는 본문의 관련 글에서 이어집니다.
- 도구의 개수보다 역할 분담이 중요하다.
- 법령과 사실관계는 AI 답변이 아니라 원문으로 끝낸다.
- 프롬프트에는 목적·자료·출력 형식·검증 기준을 함께 넣는다.
- 바이브코딩은 큰 서비스를 한 번에 만들기보다 작은 기능을 구현·실행·확인하는 방식이 안전하다.
1. 네 가지 AI를 써도 주력 도구는 두 개면 충분했다
처음에는 각 서비스의 차이를 놓칠까 봐 여러 도구를 오갔다. 하지만 실제 업무에서는 도구를 바꿀 때마다 대화 맥락과 자료를 다시 넣어야 했다. 비교 자체가 일이 되는 순간도 있었다. 그래서 지금은 다음처럼 역할을 단순화했다.
| 도구 | 내가 주로 맡기는 일 | 주의점 |
|---|---|---|
| ChatGPT | 쟁점 정리, 논리 검증, 초안 구조화, 대화형 탐색 | 법령·통계·인용은 원문 확인 |
| Claude | 긴 문서 검토, 코드베이스 탐색, 에이전틱 코딩 | 파일 변경 범위와 완료 기준을 먼저 지정 |
| Gemini | 다른 관점의 답변 비교 | 두 번째 의견이지 자동 정답은 아님 |
| Perplexity | 검색 출발점과 출처 후보 찾기 | 요약문 대신 연결된 원문을 직접 읽기 |
이 구분은 제품의 절대적인 우열이 아니다. 내가 반복하는 업무에 맞춘 개인적인 배치다. 중요한 것은 “어떤 AI가 최고인가”가 아니라 어떤 단계에서 무엇을 맡기고, 어디서 사람이 확인할 것인가다.
구독 비용과 실제 사용 결과를 분리해 판단하는 방법은 매달 AI 구독을 유지·축소·중단하는 점검표에서 구체적으로 정리했습니다.
2. ‘잘 시키기’는 멋진 프롬프트보다 작업 명세에 가깝다
“이 문서 검토해줘”라고만 하면 그럴듯하지만 다시 손봐야 하는 답이 나오기 쉽다. 반면 목적과 판단 기준을 적으면 결과가 안정된다. Anthropic의 공식 프롬프트 안내도 명확한 지시, 충분한 맥락, 원하는 출력의 구체화를 권한다. 내가 실제로 쓰는 기본 틀은 다음과 같다.
목적: 이 검토 결과를 어디에 사용할 것인가
자료: 판단에 사용해도 되는 문서와 기준일은 무엇인가
작업: 요약, 비교, 반론, 누락 확인 중 무엇을 원하는가
출력: 표, 체크리스트, 수정안 등 어떤 형태가 필요한가
검증: 사실·해석·추정을 구분하고 출처 URL과 조문을 표시할 것
금지: 확인하지 못한 조문·판례·수치를 만들어내지 말고 불확실성을 표시할 것
이 방식의 장점은 특정 모델에 덜 의존한다는 점이다. 같은 명세를 ChatGPT와 Claude에 넣어 결과 차이를 비교할 수 있고, 나중에 틀린 부분이 발견되면 어느 단계에서 문제가 생겼는지도 찾기 쉽다.
3. 법령 검토에서는 AI 답변을 ‘초안’으로만 취급한다
과거에 법령을 물었을 때 이미 바뀐 규정을 기준으로 답하거나, 실제 조문과 맞지 않는 설명을 받은 적이 있다. 문장은 자신감 있게 쓰였지만 근거를 따라가면 현재 법령과 어긋났다. 이 경험 이후 법령 검토의 마지막 단계는 항상 내 눈으로 원문을 확인하는 것으로 정했다.
내가 법령을 검토할 때 사용하는 순서는 다음과 같다.
- 사실관계를 먼저 고정한다. 누가, 언제, 어떤 행위를 했는지 AI가 임의로 채우지 못하게 적는다.
- 쟁점을 질문형으로 나눈다. 적용 법령, 요건, 예외, 절차, 기준일을 분리한다.
- AI에게 후보 조문과 반대 논리를 찾게 한다. 결론 하나만 요구하지 않고 다른 해석 가능성도 요청한다.
- 법제처 국가법령정보센터에서 현행 조문과 시행일을 확인한다. 개정 전후가 중요한 경우 연혁도 함께 본다.
- 최종 문서에는 사실·법령 원문·해석·남은 불확실성을 구분한다.
법제처의 국가법령정보센터는 현행법령과 연혁, 행정규칙 등을 확인할 수 있는 공식 출발점이다. AI가 출처 링크를 제시하더라도 실제 페이지가 존재하는지, 조문 번호와 시행일이 맞는지는 다시 확인한다.
내가 복사해서 쓰는 법령 검토 요청문
아래 사실관계를 바꾸거나 추정하지 말고 쟁점을 정리해줘. 기준일 현재 적용 가능한 법령 후보를 제시하되, 조문 번호·시행일·공식 원문 URL을 함께 적어줘. 확인하지 못한 내용은 ‘확인 필요’로 표시하고, 사실관계·법령 원문·해석·반대 논리를 별도 항목으로 구분해줘. 마지막에 내가 직접 확인해야 할 체크리스트를 만들어줘.
이 요청문도 정답을 보장하지 않는다. 다만 AI가 무엇을 모르는지 숨기지 못하게 하고, 내가 확인할 지점을 선명하게 만드는 데 도움이 된다.
4. 왜 출처 확인을 업무 흐름에 넣어야 하는가
미국 NIST의 생성형 AI 위험관리 프로필은 생성형 AI가 잘못된 내용을 자신 있게 제시하는 현상을 ‘confabulation’으로 설명한다. 잘못된 논리나 존재하지 않는 인용이 답변을 더 믿을 만하게 보이게 만들 수도 있다고 지적한다. 특히 법률처럼 맥락과 전문성이 필요한 영역에서는 열린 질문에 대한 장문 답변을 그대로 신뢰하기 어렵다.
그래서 나는 AI 답변을 세 단계로 나눈다.
- 아이디어 단계: 쟁점, 검색어, 빠진 관점 찾기
- 작업 단계: 표와 초안, 비교안 만들기
- 판단 단계: 원문 확인 후 사람이 채택·수정·폐기하기
AI의 가치는 판단을 없애는 데 있지 않다. 사람이 검토해야 할 범위를 빠르게 드러내는 데 있다. 관련 내용은 AI 시대의 창의성과 판단에서도 더 자세히 다뤘다.
5. 바이브코딩은 대화가 아니라 ‘작동하는 결과물’로 끝낸다
취미로 arbiterOS를 만들기 전에는 코딩 질문을 하면 설명을 읽고 끝나는 경우가 많았다. 지금은 에이전트에게 프로젝트 구조를 살펴보게 하고, 관련 파일을 수정하고, 실행하거나 테스트한 결과를 보고하게 한다. Anthropic은 Claude Code를 파일 편집, 명령 실행, 코드 검증을 수행하는 에이전틱 코딩 도구로 설명한다.
하지만 “앱 하나 만들어줘”처럼 크게 던지면 어디까지 완성됐는지 판단하기 어렵다. 내가 더 신뢰하게 된 방식은 작은 기능 계약을 만드는 것이다.
| 이전 방식 | 지금 방식 |
|---|---|
| “이 기능 만들어줘” | 대상 사용자·입력·출력·완료 기준을 먼저 적기 |
| 코드를 답변으로 받기 | 관련 파일을 직접 수정하고 변경 목록 받기 |
| 보기 좋아 보이면 종료 | 실행·테스트·오류 확인까지 완료 |
| 한 번에 큰 범위 요청 | 되돌릴 수 있는 작은 단위로 반복 |
작은 기능 계약의 다섯 항목
- 목표: 사용자가 무엇을 할 수 있어야 하는가
- 범위: 이번 작업에서 바꿀 파일과 바꾸지 않을 부분은 무엇인가
- 완료 기준: 어떤 화면·명령·테스트가 통과하면 끝인가
- 안전장치: 삭제, 배포, 결제, 권한 변경은 별도 확인할 것
- 검증 기록: 변경한 파일과 테스트 결과, 남은 문제를 보고할 것
이 원칙은 개발자가 아닌 사람에게도 중요하다. 자연어로 코딩할 수 있어도 결과를 확인할 기준이 없으면 우연히 작동한 데모와 유지 가능한 도구를 구분하기 어렵다.
실행 성공 표시와 실제 사용자 결과가 달랐던 사례는 개인 자동화 장애에서 완료 조건을 다시 세운 기록에서 확인할 수 있습니다.
6. 실제로 잘 안 됐던 네 가지 방식
“알아서 가장 좋은 방법으로 해줘”
맥락이 없으면 AI는 내가 중요하게 여기는 기준을 추정한다. 추정이 맞을 때도 있지만, 법령 기준일이나 코드 변경 범위처럼 중요한 조건이 빠지기 쉽다.
출처만 달라고 하고 링크를 열어보지 않기
링크가 있다는 사실과 그 링크가 주장을 뒷받침한다는 사실은 다르다. 제목, 발행기관, 기준일, 실제 문장을 확인해야 한다.
첫 답변을 최종안으로 쓰기
첫 답변은 쟁점 지도를 그리는 데 유용하다. 최종 문서는 반론 요청, 원문 대조, 표현 완화 과정을 거쳐야 한다.
너무 큰 기능을 한 번에 맡기기
범위가 커지면 중간에 잘못된 방향으로 가도 알아차리기 어렵다. 화면 하나, 데이터 흐름 하나, 테스트 하나처럼 작은 단위가 수정과 학습에 유리했다.
7. 직장인이 바로 적용할 수 있는 30분 루틴
- 5분: 반복 업무 하나를 고르고 현재 입력과 결과를 적는다.
- 5분: 목적·자료·작업·출력·검증 기준을 한 줄씩 쓴다.
- 10분: AI로 초안이나 작은 기능을 만든다.
- 5분: 다른 AI 또는 공식 원문으로 핵심 주장 하나를 교차 확인한다.
- 5분: 다음에도 쓸 수 있도록 프롬프트와 체크리스트를 저장한다.
이 루틴의 목표는 30분 만에 완벽한 자동화를 만드는 것이 아니다. 반복할 수 있는 최소 단위를 하나 남기는 것이다. 일주일에 한 번만 해도 한 달 뒤에는 네 개의 작은 업무 자산이 생긴다.
8. 부업 가능성도 ‘작은 문제 해결’에서 시작한다
바이브코딩으로 수익을 만들 수 있다는 말은 버튼 몇 번이면 돈이 생긴다는 뜻이 아니다. 내가 보기에는 가능성이 생기는 지점이 더 현실적이다. 자신이 반복해서 겪은 문제를 해결하는 작은 도구를 만들고, 다른 사람도 같은 문제를 겪는지 확인하는 것이다.
- 법령 또는 문서 검토 체크리스트
- 반복 보고서의 입력 형식을 정리하는 도구
- 개인 지식과 작업 기록을 연결하는 arbiterOS의 작은 기능
- 특정 업무의 누락을 줄이는 템플릿
처음부터 판매를 전제로 과장하기보다 내가 실제로 쓰고, 오류를 고치고, 한두 사람에게 피드백을 받는 편이 낫다. 수익은 그 다음 문제다. AI 시대의 일과 소득에 대한 넓은 판단 기준은 AI 시대의 일과 소득에서 이어서 볼 수 있다.
9. 지금 내가 지키는 기준
- AI는 초안과 대안을 만들고, 중요한 결론은 내가 고른다.
- 법령·통계·인용은 실제 원문과 기준일을 확인한다.
- 사실, 해석, 추정을 문서에서 구분한다.
- 에이전트에게는 변경 범위와 완료 기준을 먼저 준다.
- 작은 기능을 실행하고 검증한 뒤 다음 단계로 간다.
- 회사명, 실명, 내부 문서와 민감정보는 공개 AI에 넣지 않는다.
결국 커리어를 바꾸는 습관은 화려한 프롬프트를 외우는 일이 아니었다. 작업을 명확히 정의하고, 작은 결과물을 만들고, 출처와 작동 여부를 직접 확인하는 일이었다. AI가 강해질수록 이 마지막 확인은 더 중요해진다.
공식 참고자료
- 법제처 국가법령정보센터 — 현행법령·연혁·행정규칙 확인
- NIST AI 600-1: 생성형 AI 위험관리 프로필 — confabulation과 인간 검증 위험
- Anthropic Claude 프롬프트 엔지니어링 모범 사례 — 명확한 지시·맥락·출력 구체화
- Anthropic Claude Code 개요 — 에이전틱 코딩의 파일 편집·실행·검증 방식
- OpenAI 공식 프롬프트 가이드 — 지시 구조와 에이전트 작업 설계 참고
최종 검토일: 2026년 8월 29일. 이 글은 40대 직장인의 개인적인 업무·프로젝트 적용 기록이며, 특정 제품의 유료 광고나 법률 자문이 아닙니다. 사이트의 작성·검증 원칙은 소개 및 운영 원칙에서 확인할 수 있습니다.