알고리즘 시대의 동료: AI와 공생하는 법

1. AI를 동료라고 부르기까지 걸린 시간

저는 2025년 3월부터 업무용 AI를 본격적으로 쓰기 시작했습니다. 당시에는 회의록을 정리하고 간단한 파이썬 코드를 작성하는 정도라서, 검색창보다 조금 편한 도구라고 여겼습니다. 생각이 바뀐 계기는 4월 둘째 주에 진행한 자동매매 프로젝트였습니다. 혼자 사흘 동안 붙잡던 오류를 AI가 몇 초 만에 찾아냈지만, 그 답을 그대로 적용한 뒤 주문 수량이 예상보다 10배 크게 계산되는 사고도 겪었습니다. 그날 이후 저는 AI를 유능한 비서가 아니라 확인이 필요한 동료로 대하기 시작했습니다.

2. 첫 실패는 엉성한 질문에서 시작됐다

제가 처음 던진 질문은 단순했습니다. 수익률을 높이는 매매 로직을 만들어 달라고 적고 종목과 기간도 제대로 밝히지 않았습니다. AI는 그럴듯한 코드와 설명을 내놓았고, 저는 2025년 5월 2일 모의계좌에 바로 넣었습니다. 백테스트에서는 수익률 18.4%가 나왔지만, 수수료와 체결 지연을 넣자 결과가 -6.7%로 바뀌었습니다. 더 황당했던 점은 AI가 존재하지 않는 라이브러리 함수 이름을 섞어 코드를 만들었다는 사실이었습니다. 이 경험으로 저는 질문을 길게 쓰는 것보다 목적, 입력값, 제한 조건, 실패 기준을 구체적으로 적는 습관을 익혔습니다.

3. 제가 만든 AI 협업 작업 순서

지금은 일을 시작할 때 먼저 제가 판단해야 할 범위를 문장으로 적습니다. 예를 들어 2026년 1월에는 로그 분석을 맡기면서 최근 30일 파일만 사용하고, 개인정보가 들어간 행은 제외하며, 확신이 낮은 항목에는 물음표를 붙이라고 지시했습니다. AI가 첫 결과를 내면 곧바로 저장하지 않고 원본 로그 20개를 무작위로 골라 직접 대조합니다. 그다음 같은 질문을 표현만 바꿔 두 번 더 보내 결과가 달라지는지도 확인합니다. 세 번의 답이 서로 다르면 자동화하지 않고 제가 직접 원인을 찾았습니다. 이 절차를 거치면서 답변 속도는 조금 느려졌지만, 재작업 시간은 한 주에 평균 6시간에서 2시간으로 줄었습니다.

4. 똑똑해 보이는 답을 의심하는 법

AI의 문장이 매끄럽다고 사실까지 맞는 것은 아니었습니다. 2025년 8월, 제가 작성한 사내 기술 문서의 참고 링크를 검토해 달라고 요청했더니 AI는 존재하지 않는 논문 제목과 주소를 네 개나 제시했습니다. 저는 처음에 그 링크를 문서에 넣을 뻔했지만, 브라우저에서 하나씩 확인하다가 모두 잘못된 정보임을 발견했습니다. 이후에는 출처를 요구하는 데서 멈추지 않고, 원문에서 해당 문장을 직접 찾아 인용 범위와 발표 날짜를 확인합니다. 숫자도 마찬가지로 계산기를 따로 사용해 다시 계산하고, 코드라면 작은 입력값 세 개를 넣어 예상 결과와 맞춰 봅니다. 검증 절차를 거치지 않은 답은 아이디어 메모로만 남겨 두고 외부 공유를 미룹니다.

5. AI에게 맡기지 않는 영역을 정했다

저는 한 번의 실수 뒤에 AI에게 맡기지 않을 업무를 따로 적었습니다. 실제 계좌의 주문 승인, 고객에게 보내는 최종 답변, 계약서의 법적 표현, 삭제 명령은 제가 직접 확인하기 전까지 실행되지 않도록 설정했습니다. 2025년 10월에는 자동화 프로그램이 조건문을 잘못 읽어 테스트용 파일 312개를 한꺼번에 이동시킨 일이 있었습니다. 다행히 백업 폴더가 있어 복구했지만, 백업이 없었다면 반나절의 작업 기록을 잃을 뻔했습니다. 그 뒤로는 삭제 대신 격리 폴더 이동을 먼저 적용하고, 실행 전 미리보기와 되돌리기 버튼을 넣었습니다. AI를 믿지 않아서가 아니라, 실수했을 때 피해 범위를 작게 만들기 위해 경계를 둔 셈입니다.

6. 혼자 쓰던 도구를 팀의 동료로 바꾸는 과정

AI를 개인 비서처럼만 사용할 때와 팀에서 함께 사용할 때는 문제가 달랐습니다. 2025년 11월에 동료 세 명과 같은 프롬프트를 공유했는데, 한 사람은 고객 이름을 그대로 붙여 넣었고 다른 사람은 내부 매출표를 통째로 입력했습니다. 저는 그날 오후 입력 금지 항목, 익명화 예시, 보관 기간을 한 장짜리 문서로 만들었습니다. 이후 팀 채팅에는 고객명 대신 A사, 금액 대신 구간을 사용했고, 민감한 파일은 사내 승인 도구 안에서만 처리했습니다. 매주 금요일 20분씩 AI 답변 중 틀린 사례를 함께 기록하면서 개인의 요령이 팀의 작업 규칙으로 바뀌었습니다.

7. 생산성보다 먼저 달라진 제 판단 습관

AI를 쓰기 전에는 초안을 빨리 완성하는 사람을 일 잘하는 사람으로 생각했습니다. 하지만 2026년 2월 프로젝트에서 AI가 작성한 보고서를 그대로 다듬다가, 애초에 질문이 잘못됐다는 사실을 사흘 뒤에 발견했습니다. 표현은 매끈했지만 고객이 묻지 않은 지표를 길게 설명하고 있었습니다. 그 후 저는 작업 시작 전에 왜 이 문서를 만드는지, 누가 읽는지, 읽은 뒤 어떤 행동을 해야 하는지 세 줄로 먼저 적습니다. AI에게 글을 맡기는 시간보다 문제를 정의하는 시간이 길어졌지만, 회의에서 다시 설명하는 횟수는 눈에 띄게 줄었습니다. 제 판단을 AI에게 넘기는 대신, 판단 전에 생각할 틀을 빌리는 방식으로 사용법이 바뀌었습니다.

8. 제가 생각하는 공생의 조건

제가 겪은 시행착오를 돌아보면 AI와 잘 협업하는 사람은 화려한 명령문을 쓰는 사람이 아니었습니다. 자신의 업무를 작은 단계로 나누고, 어느 단계에서 사람의 승인이 필요한지 표시하는 사람이었습니다. 저는 매일 업무가 끝나면 AI가 틀린 답을 낸 사례와 제가 검증을 건너뛴 사례를 각각 한 줄씩 기록합니다. 2025년 6월에는 이 기록이 고작 7줄이었지만, 2026년 3월에는 86줄까지 쌓였고 반복되는 오류 유형도 보였습니다. 그 목록을 바탕으로 질문 양식과 점검표를 고치니 같은 실수가 줄었습니다. AI가 저를 대신해 성장한 것이 아니라, 제가 제 업무 방식을 더 정확히 들여다보게 된 결과에 가깝습니다.

9. 내일부터 적용할 수 있는 작은 출발점

처음부터 거대한 자동화 시스템을 만들 필요는 없다고 느꼈습니다. 저는 내일 처리할 반복 업무 하나를 골라 입력 자료, 원하는 결과, 금지 사항, 검수 방법을 각각 한 줄씩 적어 보려 합니다. AI가 만든 결과에서 원본과 대조할 항목 다섯 개를 정하고, 오류가 나도 원상 복구할 백업 위치도 먼저 확인합니다. 일주일 뒤에는 절약한 시간보다 잘못된 답을 몇 번 걸러냈는지를 기록할 생각입니다. 독자 여러분도 이메일 초안이나 회의록처럼 피해 범위가 작은 일부터 시작해 보시기 바랍니다. AI를 동료로 삼는 첫걸음은 맹신이 아니라, 맡길 일과 직접 확인할 일을 스스로 구분하는 데서 시작됩니다.