입사 3개월, 3차원을 넘어 AI차원으로 — ‘AI로 안 되는 건 없다’는 말을 실제로 증명하다

— AI Lab 인턴 권장순님이 AI-Native한 방식으로 일해온 기록

권장순님은 일을 시작할 때 하나의 전제를 둡니다 — “AI로 안 되는 건 없다고 믿는다”.

이 말은 결과를 낙관하는 선언이라기보다, 문제를 대하는 사고 순서에 가까웠습니다.

가능한지부터 따지기보다, 어떻게 하면 가능하게 만들 수 있을지를 먼저 고민하는 방식이었죠.

이 글은 장순님이 AI Lab 인턴으로 일하며 AI를 단순한 도구가 아니라 일의 전제 조건이자 시스템으로 다루기 시작한 과정을 정리한 기록입니다.

그리고 그 과정은 생각보다 훨씬 기술적인 선택들의 연속이었습니다.

AI를 쓰는 것이 아니라, AI를 기준으로 다시 나누다

초기에는 장순님 역시 일반적인 방식으로 AI를 사용했습니다. 문서를 정리하고, 아이디어를 보조하는 정도였죠.

하지만 곧 한계가 드러났습니다. AI를 쓰고 있음에도, 일의 구조는 크게 달라지지 않았기 때문입니다.

그래서 접근 방식을 바꿨습니다. AI를 어디에 “붙일지” 고민하는 대신, 기존 업무를 AI 기준으로 다시 분해하기 시작했습니다. 그리고 그 결과, 업무는 크게 두 축으로 나뉘었습니다.

하나는 비개발 영역이었고, 다른 하나는 개발 영역이었습니다.

중요한 점은 두 영역 모두에서 AI가 개입하는 지점과 역할을 명확히 정의했다는 점이었습니다.

비개발: 결과물이 아니라 입력 파이프라인을 설계하다

비개발 업무에서 장순님이 가장 먼저 손댄 것은 결과물이 아닌, 바로 입력이었습니다.

AI의 출력은 입력에 전적으로 의존했습니다. 그래서 문서 작성, 정보 정리, 아이디어 구상 과정을 그대로 AI에게 맡기지 않았습니다. 대신, AI가 오해하지 않도록 입력 구조를 먼저 만들었습니다.

이 과정에서 장순님은 정보 탐색 — 정리 — 질문이라는 기존 흐름을 유지하지 않고 AI가 이미 컨텍스트를 이해한 상태에서 대화를 시작하는 구조를 선택했죠.

이를 가능하게 한 것이 OpenAI Atlas였습니다. Atlas는 단순히 GPT가 붙은 브라우저가 아니라, 현재 보고 있는 페이지를 그대로 맥락으로 삼는 환경이었습니다.

덕분에 페이지 내용을 복사해 설명하는 과정이 사라졌고, 질문은 항상 “이 문맥에서 무엇을 의미하는가”라는 수준에서 시작됐습니다. 정보 탐색은 사람이 아닌, 브라우저의 에이전트가 담당하게 됐죠.

이 선택은 이후 자동화로 이어지는 기반이 됐습니다.

대화를 끊지 않기 위해, 자동화를 설계하다

장순님이 자동화를 본격적으로 체감한 지점은 Claude Chrome Extension과 Slack 연동 이후였습니다.

슬랙에서 나눈 대화는 더 이상 휘발되지 않았죠.

대화는 즉시 요약됐고, 요약은 이슈 단위로 정리됐으며, 이슈는 곧바로 Jira 티켓으로 이어졌습니다.

이 과정에서 중요한 것은 “무엇을 자동화했는가”가 아니라, 대화가 끊기지 않도록 흐름을 설계했다는 점이었습니다.

회의 이후 정리 → 티켓 생성 → 다음 액션 정의라는 기존의 수작업 체인은 하나의 연속된 자동화 파이프라인으로 재구성됐습니다.

이때부터 자동화는 부가 기능이 아니라, 업무 흐름의 기본값이 됐습니다.

개발: AI 코딩을 ‘단계’로 쪼개다

개발 영역에서는 더욱 명확한 구조가 필요했습니다. 장순님은 AI 코딩을 한 번의 프롬프트로 끝내지 않았습니다. 대신, 개발 전체를 단계로 나눴습니다.

첫 단계는 기획이었습니다.

Gemini와 GPT를 활용해 문제 정의를 확장했고, 그 결과를 1-pager 문서로 정리했습니다. 이 문서는 개발자가 아니어도 이해할 수 있는 수준을 기준으로 삼았습니다.

다음은 설계 단계였습니다.

기술 스택과 구조를 tech-spec 문서로 명확히 정리했고, Claude가 항상 이 문서들을 참조하도록 Custom Instruction을 설정했습니다. AI가 맥락을 잃지 않도록 하기 위한 장치였죠.

그 다음은 계획 단계였습니다.

Codex의 /init 명령을 활용해 전체 작업 계획을 생성했고, 이를 agent.md로 고정했습니다. AI가 즉흥적으로 코드를 생성하지 않도록, 항상 계획을 먼저 읽고 움직이게 만들기 위한 선택이었습니다.

구현과 검증은 분리

구현 단계에서는 TDD 방식을 채택했습니다. 테스트 코드를 먼저 정의했고, AI가 생성한 코드는 반드시 이 테스트를 통과해야만 의미가 있었습니다.

구현 이후에는 검증 단계가 이어졌습니다. Codex를 활용해 코드 리뷰를 진행했고, 테스트 실패 시 다시 Claude에 피드백을 주며 수정했습니다.

이 과정은 한 번으로 끝나지 않았고, 계획 — 구현 — 검증이 반복되는 사이클로 굴러갔습니다.

그리고 이 구조 덕분에 AI는 자유롭게 코드를 생성하면서도, 정해진 가드레일 안에서만 움직이게 됐습니다.

AI를 잘 쓰기 위해, 제약을 일부러 두다

아이러니하게도, 장순님이 가장 공을 들인 부분은 AI의 자유를 넓히는 것이 아니라, 제약을 명확히 하는 일이었습니다.

테스트 코드, 명확한 에러 메시지, 고정된 문서 구조는 AI가 스스로 문제를 인식하고 수정하도록 돕는 장치였습니다.

필요한 경우에는 더 많은 토큰을 사용하는 모델을 선택했고, 추론이 중요한 작업에는 사고를 길게 하도록 유도했습니다.

장순님은 이 부분을 명확히 인지하고 있었습니다 — AI는 알아서 잘하지 않고, 잘 하도록 설계해야 한다는 걸.

이 과정에서 시행착오는 줄지 않았습니다. 오히려 더 많아졌죠.

하지만 그 시행착오는 매번 기록됐고, 다음 사이클의 입력값이 됐습니다. 오늘의 실패는 내일의 워크플로우를 개선하는 재료가 됐습니다.

그래서 장순님에게 “AI로 안 되는 건 없다”는 말은 결과를 보장하는 문장이 아니었습니다.

가능성을 구조로 바꾸겠다는 선언에 가까웠던 거죠.

한 사람의 구조가, 팀의 방식이 되기까지

장순님이 설계한 AI-Native 워크플로우는 개인의 생산성을 높이기 위한 요령에 머물지 않았습니다.

업무를 어떻게 나누고, 어디에 AI를 개입시키며, 어떤 지점에 사람의 판단을 남길 것인지에 대한 하나의 기준으로 작동하기 시작했죠.

문서로 남은 기획과 설계, 자동화로 연결된 대화와 실행 흐름은 특정 작업을 빠르게 처리하기 위한 장치가 아니라, 팀이 참고할 수 있는 작업 방식의 골격이 됐습니다.

이 과정에서 AI는 특정 직무를 돕는 도구가 아니라, 일의 순서와 역할을 다시 정의하게 만드는 환경으로 자리 잡았습니다.

장순님은 이렇게 AI-Native 워크플로우를 구축해 가며, 월 수십만 라인에 이르는 코드를 AI와 함께 작성했습니다. 그리고 그 결과, 마이리얼트립 송년회에서 ‘올해의 코딩왕’으로 선정돼 허먼밀러 의자를 선물로 받았죠.

물론 이 의자는 결과였고, 그 앞에는 수없이 많은 선택과 구조 설계의 시간이 있었습니다.