본문으로 건너뛰기
Hooney
English

AI를 왜 쓰는가: 판단은 사람이, 반복은 AI가

중요한 문제를 고르고, AI로 실행하고, 실제 효과를 확인하는 나의 업무 방식을 정리했다.

  • AI
  • 개발
  • 일하는 방식
주황색 판단 경로가 필드노트 조각을 지나 검증 반복을 거쳐 명확한 끝점에 도착하는 장면.

AI를 왜 쓰느냐는 질문에 가장 쉽게 붙는 답은 속도다. 문서를 빨리 요약하고 코드를 빨리 만들고 반복 작업을 줄일 수 있다. 모두 맞는 말이지만 내가 AI를 계속 쓰는 이유를 충분히 설명하지는 못한다.

나는 개발자로 일을 시작했고, 지금은 직접 만들고 실행하는 일을 하고 있다. 더 나은 방법을 찾으면서도 삶의 여유를 잃고 싶지는 않았다. 감정은 오가도 해야 할 일은 이어진다. 내게 AI는 그 일을 대신 살아주는 존재가 아니라 내가 바라던 것을 만들어 가게 해주는 고마운 도구다.

그래서 내가 AI를 쓰는 이유는 더 나은 결정을 실행으로 옮기고, 원하던 결과가 실제로 만들어졌는지 확인하기 위해서다. 처리 속도보다 중요한 것은 무엇을 해결할지 정하고, 어디까지 맡길지 결정하고, 실제 효과를 끝까지 확인하는 일이다.

AI 시대에 더 중요해진 것은 판단이다

지식정보화 사회에서는 아는 것이 경쟁력이었다. AI가 넓은 자료를 읽고 답을 만드는 시대에는 지식을 어디에 정확히 적용할지 아는 판단이 더 중요해진다.

망치질 자체보다 어디를 쳐야 하는지 진단하는 일이 더 큰 가치를 만들 수 있다는 비유가 있다. AI는 망치를 빠르게 움직인다. 하지만 잘못된 곳을 치면 결과가 빨리 쌓일 뿐이다. AI를 쓰면 비용이 사라지는 것도 아니다. 호출 비용이 청구되고, 결과를 확인하고 고치는 시간도 든다.

결국 먼저 물어야 할 것은 “AI로 무엇을 할 수 있나?”가 아니다. “이 문제가 사라진다면 나는, 또는 누군가는 얼마까지 지불할 수 있나?”에 가깝다.

빠르게 실행하기 전에 문제를 하나 고른다

AI는 모호한 요청도 그럴듯한 결과로 바꿔 준다. 그래서 오히려 문제가 생긴다. 방향이 틀렸다면 잘못된 결과가 더 빠르게 늘어난다.

나는 일을 맡기기 전에 세 가지를 먼저 본다.

  • 얼마나 자주 반복되는가
  • 실패했을 때 부담이 얼마나 큰가
  • 그 결과가 나와 다른 사람에게 얼마나 큰 영향을 주는가

자주 반복되는 일인지, 실제 서비스에 바로 반영되는지, 실패하면 되돌리기 어려운지, 나만 쓰는지 외부 고객에게까지 영향을 주는지를 본다. 이 기준은 AI에 맡길 범위와 사람이 직접 결정할 범위를 함께 정하는 기준이기도 하다.

예를 들어 보고서를 자동화한다는 너무 넓다. 이번 주 원본 12건을 빠짐없이 요약하고 숫자를 대조한다고 하면 범위와 검증 방법이 생긴다. 문제 하나를 좁히는 순간 실험이 시작된다. AI가 할 수 있는 일을 찾기 전에, 지금 해결할 가치가 있는 문제를 고르는 이유다.

일을 맡기기 전에 사람이 네 가지를 연결한다

사람에게 자료와 권한을 주지 않은 채 결과만 요구할 수는 없다. AI도 마찬가지다. 일을 맡기기 전에 사람이 업무의 조건을 먼저 연결해야 한다.

  1. 맥락: 어떤 원본, 규칙, 좋은 예시를 참고해야 하는가
  2. 도구: 파일, GitHub, Jira, 문서처럼 무엇을 읽고 어디에 저장해야 하는가
  3. 권한: 읽기만 가능한가, 초안까지 저장할 수 있는가, 외부 전송은 승인 후에 해야 하는가
  4. 결과: 무엇이 남으면 이 일이 끝났다고 판단할 수 있는가

이 조건이 빠진 채로 “알아서 잘해 줘”라고 요청하면 결과의 품질도 우연에 맡기게 된다. 반대로 작업 순서를 지나치게 자세히 정해주면, 예상과 다른 상황에서 AI가 다음 일을 이어가기 어려워진다. AI가 참고할 자료와 지켜야 할 기준, 어디까지 처리할 수 있는지, 무엇을 완료로 볼지 미리 정해야 한다.

주간 보고서 초안을 만든다고 해보자. 이번 주 원본만 사용하고 읽지 못한 자료가 있으면 먼저 알려달라고 한다. 결과에는 ID·요약·금액·출처를 표로 넣고, 합계와 확인할 항목을 따로 둔다. 원본과 결과의 ID와 금액을 대조해 누락·중복·합계 차이를 표시한다. 초안과 검사표를 저장하는 데서 멈추고, 실제 공유는 하지 않는다.

프로젝트별로 업무 맥락을 모아두는 것도 같은 일이다. 나는 다음처럼 원본과 결과를 연결하는 구조를 생각한다.

  • 01_원본: 이번 범위의 자료
  • 02_규칙.md: 반드시 지켜야 할 기준
  • 03_좋은예시: 완료된 결과의 참고
  • 04_결과: AI가 만든 초안
  • 05_검사: 다시 확인할 방법과 미확인 목록

폴더와 터미널을 쓰든, 문서와 프로젝트 공간을 쓰든 방법은 달라도 된다. 중요한 것은 “이 자료만 참고하고, 이 기준에 맞춰 작성해줘”처럼 참고할 자료와 기준, AI가 할 수 있는 일을 정하는 것이다. 원본은 읽기만 하고 결과만 작성하도록 도구의 접근 권한도 설정한다.

사람은 설계하고, AI와 반복하고, 사람이 완료한다

내가 사용하는 흐름은 단순하다.

설계부터 검사와 완료까지
AI와 함께 일하는 여섯 단계설계, 실행, 검사, 수정, 재검사를 거쳐 완료한다.

01 설계

02 실행

03 검사

04 수정

05 재검사

06 완료

사람이 목표와 범위, 완료 기준을 설계한다. AI는 자료를 읽고 변환하고 초안을 만든다. 검사 단계에서는 AI가 전체를 대조하고 누락·오류·불확실성을 표시한다. 차이가 발견되면 AI와 수정하고 같은 기준으로 다시 검사한다. 마지막에는 사람이 중요한 예외와 근거를 확인하고 완료를 결정한다.

실행 전에는 토론으로 기준을 정한다. 사실과 제약을 공유하고, 사람과 AI가 선택지와 위험을 정리하고, 권한 있는 사람이 범위·우선순위·실행을 결정한다. AI는 근거를 모으고 선택지를 비교할 수 있지만 승인 권한과 최종 결정은 사람에게 있다. 반복되는 결정은 Spec에 남기고, 검증 방법은 다음 작업에서 다시 쓸 수 있게 한다.

여기서 사람의 역할은 AI가 만든 모든 내용을 처음부터 다시 읽는 것이 아니다. 사람이 반드시 판단해야 하는 지점을 정하고 나머지 검사는 반복 가능한 구조로 만드는 것이다. 개발에서는 테스트와 브라우저 검사가 그 역할을 할 수 있다. 일반 업무에서는 Excel 수식이나 체크리스트만으로도 시작할 수 있다.

AI가 “완료했습니다”라고 말하는 것은 완료의 근거가 아니다. 처음에 정한 기준을 충족한 결과와 확인할 수 있는 근거가 있어야 한다. 고쳤다고 했는데 달라진 것이 설명뿐이라면, 그것은 완료가 아니다. 문제를 발견한 뒤 표현만 바꿔 신기능이라고 발표하는 것도 마찬가지다. 업무 정의와 Spec이 없으면 버그가 기능으로 포장될 수 있다.

로드맵은 우선순위와 순서를 정하고 Spec은 범위와 완료 기준을 구체화한다. 올바른 방향을 결정하고 결과를 끝까지 마무리하는 능력이 AI 시대에도 사람에게 남는 중요한 일이다.

아침 업무를 시작하는 방식도 달라졌다

예전에는 아침마다 여러 곳에 흩어진 상태를 다시 읽었다. 이전 기록에서 이어갈 일을 찾고, Jira 티켓과 GitHub의 코드 변경 및 리뷰를 확인했다. 자료를 다 읽고 나서야 오늘 무엇부터 할지 생각할 수 있었다.

지금은 자료를 모으고 대조하는 반복을 AI에 맡긴다. 이전 daily와 로컬 Git, Jira와 GitHub의 현재 상태를 읽어 오늘의 체크리스트와 오늘 범위 밖의 항목을 정리하게 한다. 나는 우선순위가 맞는지, 빠진 맥락은 없는지, 오늘 하지 않기로 한 이유가 타당한지를 확인하고 수정한다. 그 뒤에야 daily 기록으로 남긴다.

짧은 요청 하나가 업무를 마법처럼 이해하는 것은 아니다. 그 뒤에는 읽을 자료, 정리 순서, 완료 기준과 저장 조건이 있다. 내가 쓰는 skill의 이름은 skill- 접두사로 시작한다. 이 사례에서는 skill-sprint가 반복해서 사용할 절차와 기준을 저장하고 daily가 그 절차로 오늘의 업무를 정리하는 단계다.

실행 전에는 읽기 권한과 날짜를 확인한다. 결과를 자동으로 발행하거나 메시지를 보내지 않는다. 사람이 우선순위와 맥락을 확인하고 저장 여부를 결정한다. 이 경계를 포함해야 자동화가 편리함을 넘어 업무의 책임을 흐리지 않는다.

나는 이 흐름을 다른 업무에도 적용할 수 있다고 본다. 각자의 업무에서 다음 세 가지를 연결해보면 된다.

  1. 입력: 원본 자료는 어디에 있는가? 메일·문서·Excel 중 하나를 먼저 고른다.
  2. 판단: 어떤 기준으로 정리하고 무엇을 사람이 확인해야 하는가?
  3. 전달: 결과를 누구에게 어떤 형식으로 남길 것인가? 채널과 권한은 무엇인가?

“이 자료를, 이 기준으로 정리해서, 이곳에 전달하려면?”이라는 질문에서 구체적인 적용이 시작된다.

AI의 복리는 다음 일을 처음부터 시작하지 않는 데서 생긴다

한 번 잘된 요청보다 더 가치 있는 것은 그 과정에서 배운 것을 남기는 일이다. 어떤 자료가 필요했는지, 무엇을 놓쳤는지, 어떤 검사로 오류를 발견했는지 기록한다. 다음 일에서는 이전 경험을 불러오고 달라진 조건만 고친다.

AI가 저절로 내 업무를 학습해 준다는 뜻은 아니다. 내가 시도하고 확인하고 기준을 수정한 경험을 다시 쓸 수 있는 형태로 남겨야 한다. 나는 그 자산을 네 가지로 나눠 생각한다.

  • 기술: 도구를 연결하고 실행하는 방법
  • 노하우: 잘된 요청과 실수를 잡는 요령
  • 지식: 업무 규칙과 좋은 결과의 예시
  • 경험: 실제로 해보고 확인한 결과

매번 처음부터 설명하고 탐색하고 시행착오를 겪는 대신, 지난 경험 위에서 불러오고 실행하며 새로운 문제에 집중한다. 재사용할수록 기술·지식·경험이 갱신되는 것, 이것이 내가 말하는 AI 복리다.

AI에 투자해 나만의 업무 환경을 만든다

유료 AI를 결제하는 것은 시작일 뿐이다. 사람을 고용하듯 실제 업무를 위임하고 결과를 확인하고, 내 자료와 기준을 정리하고, 매일 쓰는 문서와 메일과 Excel 같은 도구를 필요한 만큼 연결해야 한다. 결제한 금액보다 중요한 것은 내 업무에 맞게 환경을 만드는 일이다.

발표에서 나는 월급의 10%를 AI 활용에 투자해보자고 개인적으로 제안했다. 모든 사람에게 적용되는 기준은 아니다. 내가 말하고 싶은 것은 큰 도구를 한 번에 사라는 뜻이 아니다. 반복되는 업무 하나를 골라 실제로 써보고 그 업무에 필요한 비용과 시간을 함께 들여보자는 뜻이다.

그래서 내가 생각하는 AI 활용의 핵심은 한 문장으로 정리된다.

판단과 책임은 사람이, 반복은 AI가, 검사는 시스템으로.

문제를 발견하고, 맡길 범위를 정하고, 필요한 도구를 연결하고, 결과를 검증하고, 배운 것을 다시 쓰는 흐름이다. AI를 잘 쓰는 것은 사람의 판단을 없애는 일이 아니다. 반복에 쓰던 시간을 줄여 더 중요한 문제를 고르고, 결정한 일을 실제 결과로 끝내는 데 집중하는 일이다.

나는 AI가 일에서는 더 나은 결과를, 삶에서는 조금 더 많은 여유를 만들어주기를 바란다. 아직 AI에 무엇을 맡기고 무엇을 결정할지 고민하고 있다면, 내 업무에서 반복되는 문제 하나를 골라보면 된다. 그 문제의 입력·판단·전달을 연결하고 작은 결과 하나를 끝까지 검사해보는 것에서 시작할 수 있다.

의견과 대화

댓글은 누구나 읽을 수 있습니다. 의견을 남기려면 GitHub 계정으로 로그인해 주세요.

댓글이 보이지 않나요? GitHub에서 대화 찾기 ↗

댓글과 반응