AI를 업무에 써보니 작업 기록 방식부터 달라졌다
AI를 업무에 쓰기 전에는 보통 필요한 순간에만 질문을 던졌습니다. 오류가 나면 오류 메시지를 붙여 넣고, 글을 써야 하면 초안을 부탁하고, 설정이 막히면 해결 방법을 물어보는 식이었습니다. 답은 빨리 나왔지만, 시간이 지나면 같은 질문을 또 하게 되는 일이 많았습니다.
실제로 써보니 AI 활용에서 더 중요한 부분은 질문 한 번을 잘하는 것이 아니었습니다. 작업이 어떻게 진행됐고, 어디서 막혔고, 어떤 선택지는 버렸는지를 남기는 방식이 더 중요했습니다. 기록이 남아 있으면 AI에게 다시 설명할 일이 줄고, 다음 작업의 출발점도 훨씬 빨라졌습니다.
이 글은 “AI로 블로그를 자동화했다”는 이야기가 아닙니다. 제가 AI를 실제 작업에 붙여 쓰면서 느낀 작업 기록 방식의 변화, 좋았던 점, 조심해야 했던 점을 정리한 글입니다.
AI에게 다시 설명하는 시간이 줄었습니다
가장 먼저 체감한 장점은 반복 설명이 줄어든다는 점이었습니다. 예전에는 같은 문제가 생겨도 매번 처음부터 설명해야 했습니다. 어떤 환경인지, 무엇을 시도했는지, 어디까지 확인했는지를 다시 적어야 했습니다.
작업 기록을 남기기 시작하니 이 과정이 줄었습니다. 예를 들어 오류를 해결할 때 단순히 “고쳤다”라고 남기지 않고, 아래처럼 짧게 적어둡니다.
- 처음 의심한 원인
- 확인해 본 순서
- 틀렸던 가정
- 실제로 효과가 있었던 조치
- 다음에 같은 문제가 생기면 먼저 볼 것
이렇게 남겨두면 다음에는 AI에게 상황을 길게 설명하지 않아도 됩니다. “지난번에는 입력 경로와 실행 상태를 먼저 나눠 봤다”처럼 맥락을 바로 이어갈 수 있습니다. AI의 답변 품질도 그만큼 안정적으로 느껴졌습니다.
좋았던 점은 문제를 잘게 나누게 된다는 것입니다
AI를 쓰면 답을 빨리 얻는 데 집중하기 쉽습니다. 그런데 실제 작업에서는 답보다 문제가 어디에 속하는지 나누는 일이 더 중요했습니다.
예를 들어 자동화가 멈췄다고 해서 바로 “AI가 이상하다”고 보면 원인을 늦게 찾습니다. 입력이 안 들어온 것인지, 실행 중인 프로세스가 멈춘 것인지, 권한이나 인증이 막힌 것인지 나눠 봐야 합니다. 저는 AI에게도 이런 식으로 물을 때 결과가 더 좋았습니다.
“자동화가 응답하지 않는다”라고 묻기보다, “입력 수신, 실행 상태, 권한 문제 중 어디부터 확인해야 할지 나눠서 보자”라고 묻는 편이 더 빨랐습니다.
이 방식은 글쓰기에도 비슷하게 적용됩니다. “이 글 좀 좋게 써줘”보다 “도입부가 상황 설명이 약한지, 독자가 가져갈 기준이 있는지, 너무 내부 이야기처럼 보이지 않는지 나눠 봐줘”라고 물으면 훨씬 쓸 만한 피드백이 나옵니다.
하지만 기록을 많이 남긴다고 항상 좋은 것은 아니었습니다
장점만 있는 것은 아니었습니다. 기록이 많아질수록 오히려 헷갈리는 순간도 생겼습니다. 그때그때의 임시 판단, 이미 버린 설정, 지금은 쓰지 않는 기준이 같이 남아 있으면 AI도 사람도 잘못된 맥락을 잡을 수 있습니다.
그래서 저는 작업 기록을 남길 때 “나중에 다시 써먹을 정보”와 “그 순간만 필요했던 정보”를 구분하려고 합니다. 모든 과정을 길게 저장하는 것보다, 다음 작업에 도움이 되는 판단만 남기는 편이 더 낫습니다.
특히 아래 내용은 조심합니다.
- 지금은 쓰지 않는 예전 설정
- 그날만 통했던 임시 지시
- 계정명, 경로, 토큰 위치처럼 민감한 단서
- 대화 원문처럼 외부 독자에게 맥락이 없는 기록
- AI가 만든 문장을 그대로 붙여 넣은 흔적
AI는 맥락을 잘 활용하지만, 오래된 맥락까지 알아서 구분해 주지는 않습니다. 그래서 기록을 남기는 일만큼이나 정리하는 일이 중요했습니다.
민감정보를 빼는 습관도 같이 필요했습니다
AI 활용 기록에는 의외로 민감한 조각이 쉽게 섞입니다. 비밀번호나 토큰을 직접 쓰지 않아도, 파일 경로와 계정명, 채널명만으로 내부 구조가 드러날 수 있습니다. 이 부분은 블로그 글을 쓸 때뿐 아니라 AI에게 맥락을 줄 때도 조심해야 했습니다.
저는 AI에게 작업 맥락을 줄 때 실제 값보다 구조를 설명하려고 합니다. 예를 들어 특정 경로를 그대로 넣기보다 “공유 작업 폴더 아래 설정 파일”처럼 바꿉니다. 계정명이나 메시지 ID도 그대로 넣지 않습니다. 해결에 꼭 필요한 정보가 아니라면 일반화하는 편이 안전했습니다.
이렇게 하면 AI가 이해를 못 할까 걱정될 수 있지만, 실제로는 대부분 충분했습니다. 중요한 것은 정확한 내부 이름이 아니라 문제의 구조였기 때문입니다.
제가 쓰기 편했던 기록 형식
여러 번 해보니 너무 긴 양식은 오래 못 갔습니다. 지금은 간단하게 네 줄 정도만 남기는 방식이 제일 편했습니다.
- 문제: 무엇이 안 됐는가
- 시도: 무엇을 먼저 확인했는가
- 결과: 무엇이 맞고 무엇이 아니었는가
- 다음 기준: 다음에는 무엇부터 볼 것인가
이 정도만 있어도 다음에 AI에게 다시 물어볼 때 훨씬 편합니다. “지난번에 여기까지 확인했다”는 출발점이 생기기 때문입니다. 작업 기록이 잘 남아 있으면 AI는 단순 검색 도구보다, 이어서 생각을 정리해 주는 보조 도구에 가까워집니다.
결국 AI 활용은 답을 받는 일이 아니라 맥락을 관리하는 일이었습니다
AI를 써보며 느낀 가장 큰 장점은 속도였습니다. 초안, 요약, 점검, 비교 같은 작업이 빨라졌습니다. 하지만 시간이 지나면서 더 크게 느낀 장점은 맥락을 다시 꺼내 쓰기 쉬워졌다는 점입니다.
반대로 단점도 분명했습니다. 기록이 정리되지 않으면 AI가 오래된 기준을 따라가기도 하고, 너무 많은 맥락을 주면 핵심을 놓치기도 했습니다. 민감정보를 빼는 습관도 필요했습니다.
그래서 FMNOTE에서는 앞으로 AI를 “어떻게 자동화했는지”보다, 실제로 써보니 어떤 방식이 도움이 됐고 어디서 조심해야 했는지를 더 많이 기록하려고 합니다. AI 활용법은 멋진 프롬프트 하나보다, 내 작업 방식에 맞게 맥락을 남기고 다시 쓰는 방법에 더 가까웠습니다.
관련 기준은 FMNOTE 콘텐츠 기준과 광고·제휴·AI 활용 고지에서도 확인할 수 있습니다.
