개발자는 더 이상 코드를 짜는 사람이 아닙니다

Claude Code와 함께한 AI 시대 백엔드 개발자의 일하는 방식 변화

무신사 WMS팀에서 물류시스템을 만들고 있습니다.

1. 새로운 팀, 새로운 프로젝트, 그리고 낯선 코드

이번에 WCS 자동화 장비 프로젝트를 진행하게 되었습니다. 팀에 합류한 지는 한 달도 채 되지 않은 시점이었습니다.

이 시점에서 제가 알고 있던 것은 물류 도메인에 대한 기본적인 이해 정도였습니다. 도메인 자체는 낯설지 않았지만, 문제는 그 위에 얹혀 있는 시스템과 코드였습니다.

이번 프로젝트는 단순한 신규 개발이 아니었습니다. WCS 자동화 장비와 연동되는 신규 프로젝트를 처음부터 구축해야 했고, 동시에 기존 WMS 프로젝트에 대한 수정 작업도 병행해야 하는 상황이었습니다.

새로운 팀, 방대한 코드베이스, 복잡한 업무 정책과 프로세스. 이 조합은 개발자에게 상당한 부담으로 다가왔습니다. 특히 이런 상황에서 가장 큰 비용은 기능 구현이 아니라 기존 시스템의 구조와 흐름을 이해하는 데 드는 시간이었습니다.

2. AI Agent를 ‘도입’이 아닌 ‘업무 방식’으로 바라보다

마침 회사에서 AI Agent를 제공받을 수 있었고, 저는 이를 단순한 보조 도구가 아니라 업무 방식 자체를 바꿀 수 있는 도구로 활용해 보기로 했습니다.

보통 AI 도입이라 하면 코드 자동 생성이나 생산성 향상을 먼저 떠올리기 쉽습니다. 하지만 제가 마주한 문제는 다른 곳에 있었습니다.

“이 방대한 코드와 시스템을 더 빠르고 안정적으로 이해할 수는 없을까?”

물류 도메인에 대한 기본적인 이해가 있었기 때문에 업무 흐름 자체는 어느 정도 예측할 수 있었습니다. 그래서 코드 분석과 구조 파악을 AI의 도움으로 빠르게 정리하고, 저는 그 결과를 바탕으로 판단과 방향성을 잡는 역할에 집중하기로 했습니다.

중요한 점은 AI에게 코드를 맡기는 것이 아니라, AI와 함께 코드를 ‘이해’하는 방식을 선택했다는 것입니다.

3. Claude Skill을 활용한 코드·업무 분석의 정형화

Claude Code를 활용하며 가장 먼저 시도한 것은 분석 기준을 정형화하는 작업이었습니다.

기존에는 코드 분석이 개발자의 경험과 감각에 크게 의존하는 경우가 많았습니다. 하지만 프로젝트 규모가 커질수록 이러한 방식은 일관성을 유지하기 어렵습니다.

그래서 Claude Skill을 활용해 항상 동일한 기준으로 코드와 업무를 분석하도록 시도했습니다.

• 이 코드는 어떤 역할을 담당하는가
• 어떤 비즈니스 흐름의 일부인가
• 변경 시 영향을 받는 범위는 어디까지인가
• 외부 시스템과의 접점은 무엇인가

이 기준을 반복적으로 적용하면서 분석 결과는 점점 정형화된 형태로 쌓이기 시작했습니다.

그 결과, “누가 분석했느냐”보다 “어떤 기준으로 분석했느냐”가 더 중요해졌고, 코드 이해의 속도와 정확도도 함께 향상되었습니다.

4. 시작점·종료점·Flow 중심의 구조 이해

시스템을 이해할 때 제가 가장 중요하게 본 접점은 다음 세 가지였습니다.

• 시작 지점: 요청 또는 이벤트는 어디서 시작되는가
• 종료 지점: 처리 흐름은 어디에서 종료되는가
• Flow 시퀀스: 그 사이에서 어떤 순서와 조건으로 흐르는가

AI에게 클래스 목록이나 메서드 설명을 요청하는 대신, 위 세 가지 관점을 중심으로 시스템의 흐름을 시퀀스 형태로 정리하도록 했습니다.

이 방식 덕분에 코드를 단순히 “읽는 것”이 아니라, 시스템 전체를 하나의 흐름으로 이해할 수 있었습니다. 특히 기존 시스템을 수정해야 하는 상황에서 어디를 변경해야 하고, 어디는 그대로 두어야 하는지 판단하는 데 큰 도움이 되었습니다.

5. 분석과 판단, 그리고 명령의 분리

AI를 활용한 분석이 쌓이면서 역할 분리가 자연스럽게 이루어졌습니다.

분석 = AI + 사람

판단 = 사람

실행 = AI의 도움을 받은 사람

AI가 정리한 분석 결과를 그대로 실행하지는 않았습니다. 분석을 바탕으로 어떤 작업을 먼저 진행해야 하는지, 변경 시 리스크가 있는 영역은 어디인지 판단한 뒤 명확한 의도를 담아 AI에게 작업을 요청했습니다.

이러한 방식은 단순히 개발 속도를 높이는 것을 넘어 업무의 안정성을 높이는 데도 큰 도움이 되었습니다.

또한 Claude Skill을 통해 코드·업무 분석을 정형화하면서 시작점, 종료지점, Flow 분석 시퀀스 등을 AI가 일관된 형식으로 정리하도록 했습니다. 이를 종합해 어떤 명령을 내릴지 판단하며 작업을 진행했고, 그 결과 타이트한 업무 일정도 비교적 안정적으로 커버할 수 있었습니다.

5–1. 실전 적용: Git Worktree와 병렬 세션을 활용한 일정 단축

WCS 자동화 장비 프로젝트는 촉박한 일정 속에서 다수의 티켓을 동시에 처리해야 하는 상황이었습니다. 기존 방식대로라면 한 티켓을 완료한 뒤 다음 티켓으로 넘어가는 순차 작업이 불가피했습니다.

하지만 AI를 활용한 새로운 접근법을 시도했습니다.

기존 방식의 한계

기존에는 하나의 티켓 작업을 마친 뒤에야 다음 티켓으로 넘어갈 수 있었습니다. 단일 브랜치에서 작업하다 보니 컨텍스트 전환 비용이 컸고, 하나의 AI 세션에서 모든 작업을 처리하려니 병목이 발생했습니다. 결국 개발자의 시간이 곧 프로젝트의 속도를 결정하는 구조였습니다.

새로운 접근: 병렬 작업 아키텍처

이 한계를 극복하기 위해 작업 구조 자체를 바꿨습니다.

먼저 티켓들을 분석해 병렬 처리가 가능한 단위로 분리했습니다. 의존성이 없는 티켓들을 식별하고, 각각을 독립적으로 진행할 수 있도록 설계했습니다.

다음으로 Git Worktree를 활용해 티켓별 독립 작업 환경을 구성했습니다. 하나의 저장소에서 여러 브랜치를 동시에 체크아웃할 수 있는 Git Worktree 덕분에, 각 티켓은 완전히 격리된 환경에서 작업할 수 있었습니다.

• git worktree add ../ticket-A feature/ticket-A
• git worktree add ../ticket-B feature/ticket-B
• git worktree add ../ticket-C feature/ticket-C

그리고 티켓 수만큼 Claude 세션을 생성했습니다. 각 세션에는 해당 티켓의 요구사항, 관련 코드 컨텍스트, 제약 조건을 주입했습니다. AI가 각 티켓의 분석과 초안 작성을 동시에 진행하는 동안, 저는 결과물을 순회하며 검토하고 판단하고 피드백을 주는 역할에 집중했습니다.

무엇이 달라졌는가

5개의 티켓을 순차적으로 처리해야 했던 상황에서, 병렬 처리가 가능해졌습니다. 예상 일정보다 조기에 개발을 완료할 수 있었고, 그 덕분에 여유 시간이 생겼습니다.

하지만 진짜 가치는 단순한 속도 향상이 아니었습니다.

확보한 시간을 비즈니스 로직의 빈틈을 찾고, 시스템 간 정합성을 검증하는 데 투자할 수 있었습니다.

기존이라면 일정에 쫓겨 놓쳤을 수도 있는 엣지 케이스들을 발견했고, 데이터 흐름의 정합성을 꼼꼼히 점검할 수 있었습니다. AI가 반복적인 분석과 초안 작성을 병렬로 처리하는 동안, 개발자는 더 중요한 판단과 검증에 집중할 수 있었던 것입니다.

핵심 인사이트

이 경험을 통해 깨달은 것이 있습니다.

AI는 단순히 시간을 단축시키는 도구가 아닙니다. 더 중요한 일에 집중할 시간을 만들어주는 도구입니다.

빠르게 코드를 만들어내는 것보다, 그렇게 확보한 시간으로 무엇을 할 수 있는지가 더 중요합니다. 저는 그 시간을 비즈니스 로직의 품질을 높이는 데 사용했고, 결과적으로 더 안정적인 시스템을 만들 수 있었습니다.

“AI는 시간을 단축시키는 도구가 아니라, 더 중요한 일에 집중할 시간을 만들어주는 도구입니다.”

6. 기존 WMS 수정 작업과 AI의 한계

기존 WMS 프로젝트 수정 작업에서는 AI의 한계도 분명하게 드러났습니다.

초기에는 AI의 도움만으로 작업을 진행했고, 그 결과를 코드 리뷰를 통해 확인받았습니다. 처음부터 완벽할 수는 없었습니다. 이 과정을 통해 다시 한 번 느낀 점은 분명했습니다. 개발은 결국 사람이 하는 일이라는 사실입니다.

하지만 중요한 점은 AI를 포기하는 것이 아니라, AI가 더 잘 이해할 수 있도록 입력을 개선하는 것이었습니다.

리뷰에서 지적받은 내용을 다시 정리해 전달하고, 기존 코드의 의도와 제약 조건을 설명하면서 AI가 프로젝트의 맥락을 더 잘 이해하도록 만들었습니다.

핵심 인사이트: AI의 Output은 결국 Input의 질에 따라 달라집니다.

그 결과 리뷰 개수는 점점 줄어들었고, 작업 품질도 함께 안정되었습니다.

7. 개발자를 넘어, 다른 직군을 돕는 도구로 확장되다

AI를 개발 업무에 활용하면서 자연스럽게 한 가지 질문이 떠올랐습니다.

“이 방식은 개발자에게만 필요한 걸까?”

현재 저는 AI를 활용해 개발자가 아닌 다른 직군의 사람들에게도 업무적으로 도움이 되는 툴을 별도로 제작하고 있습니다.

이 과정에서 항상 구현 방법을 알고 시작하지는 않았습니다. 오히려 구현 방법을 몰랐던 부분들을 AI와 논의하며 새로운 방법을 찾아내고 문제를 해결해 나가고 있습니다.

AI는 정답을 주는 존재라기보다 사고의 범위를 넓혀주는 파트너에 가깝습니다.

7–1. 1시간 만에 탄생한 업무용 도구들

놀라운 점은 이러한 도구들이 만들어지는 데 걸린 시간입니다. 아이디어에서 실제 동작하는 데스크톱 애플리케이션까지, 단 1시간이면 충분했습니다.

🛠️ MWMS Helper — Slack 자동 응답 도구

Slack에서 멘션이 오면 Claude Code가 자동으로 응답하는 도구입니다. 팀원들의 질문에 AI가 먼저 답변을 준비해두면, 제가 확인하고 보완하는 방식으로 운영됩니다. 단순 반복 질문에 대한 응답 부담이 크게 줄었습니다.

• Claude, Code, Skill, Mem 연동 상태 실시간 확인
• 받은 멘션과 보낸 응답 현황 추적
• 활동 로그 100건 이상 기록

🧪 MWMS Test Bot — Mock 데이터 생성기

QA 팀과 운영팀이 테스트 데이터를 직접 생성할 수 있는 도구입니다. 개발자에게 요청하지 않아도 출고지시, 입고지시 등의 Mock 데이터를 즉시 만들 수 있습니다.

• 출고지시/입고지시 생성 (단포/합포, 수량 선택)
• DEV 환경 DB 직접 연결
• 21개 센터, 92개 화주 데이터 지원
• PR 테스트 자동화 기능

이 도구들은 모두 Electron + React 기반으로 제작되었습니다. 평소라면 프론트엔드 기술 스택을 깊이 알아야 가능한 작업이지만, AI와 함께라면 백엔드 개발자도 충분히 만들어낼 수 있습니다.

중요한 것은 기술적 구현 능력이 아니었습니다. 어떤 문제가 있는지 파악하고, 어떻게 해결하면 좋을지 방향을 제시하는 것. 그것이 핵심이었습니다.

8. 이제 개발자는 코드를 짜는 사람이 아닙니다

AI와 함께 일하면서 개발자의 역할에 대한 인식은 크게 바뀌었습니다.

이제 개발자는 단순히 코드를 작성하는 사람이 아니라, 비즈니스의 문제를 이해하고 그 문제를 해결하기 위한 시스템을 구축하는 사람에 가깝습니다.

AI는 코드를 빠르게 만들어 줄 수 있습니다. 하지만 어떤 문제가 중요한지, 무엇을 먼저 해결해야 하는지는 판단하지 못합니다. 그래서 앞으로의 개발자는 비즈니스적으로 어려운 문제를 기술로 풀어내는 전문가로서의 역량이 더욱 중요해질 것이라 생각합니다.

8–1. “아이디어만 있으면 누구나 만들 수 있다”는 말에 대하여

요즘은 “아이디어만 있으면, AI 툴만 있으면 누구나 만들 수 있다”는 이야기도 자주 들립니다. 기획자, MD, 사업부 등에서도 그렇게 느낄 수 있을 것입니다.

하지만 현재 기준으로는 그 말에 동의하기 어렵습니다.

단순한 기능 구현이나 화면 수준의 결과물은 만들 수 있을지 모르지만, 실제로 운영 가능한 시스템은 전혀 다른 차원의 문제입니다. 인프라를 어떻게 구성할지, 확장성과 안정성을 어떻게 확보할지, 운영과 유지보수를 어떻게 감당할지는 개발자들의 노하우와 CS 지식에서 출발합니다.

단순한 바이브 코딩만으로 안정적인 시스템을 구축하기는 어렵다고 생각합니다.

8–2. 개발자는 AI를 더 잘 다룰 수 있는 직군입니다

만약 인프라 구성, 확장성, 안정성, 운영까지 모두 스스로 판단해 주는 AI가 등장한다면 이야기는 달라질 수 있습니다. 하지만 현재의 AI는 그렇지 않습니다.

AI는 결국 사람이 어떤 맥락과 지식을 주입하느냐에 따라 결과가 달라집니다.

CS 지식과 시스템 설계 경험을 바탕으로 AI에게 무엇을 전달해야 하는지 알고 있는 개발자는 다른 직군보다 AI를 훨씬 더 잘 활용할 수 있는 위치에 있습니다.

9. 기술은 수단, 문제 해결이 목적

언어, 프레임워크, 인프라는 점점 덜 중요해지고 있습니다. 중요한 것은 다음과 같습니다.

• 이 문제가 왜 발생했는지
• 해결되지 않으면 어떤 비용이 발생하는지
• 어떤 방식이 조직에 가장 도움이 되는지

AI는 구현을 돕고 기술적 선택지를 넓혀주지만, 문제의 본질을 정의하는 역할은 여전히 사람의 몫입니다.

10. 마치며

AI는 앞으로도 계속 발전할 것입니다. 하지만 그럴수록 개발자는 더 나은 질문을 던지고, 더 좋은 방향을 제시하는 역할로 진화할 것입니다.

AI를 두려워하지 말고, 업무 방식에 자연스럽게 녹여 함께 일하는 법을 익히는 것. 그것이 지금 개발자에게 가장 중요한 역량이라고 생각합니다.

마지막으로 제가 가장 강하게 느낀 한 줄은 다음과 같습니다.

AI는 개발자의 자리를 빼앗지 않습니다.

하지만 AI와 함께 일하는 개발자는, 그렇지 않은 개발자를 빠르게 앞지릅니다.

MUSINSA WMS #PBO #Claude Code #AI Agent #Backend-Engineer

Platform Business Operation 조직 및 팀 소개

무신사 플랫폼 비즈니스 오퍼레이션 조직은 국내외 물류 서비스, 재고 관리, 스토어 운영을 위한 물류 프로덕트를 구축하고 다양한 오프라인 비즈니스 모델에 맞춘 스토어 관리 시스템을 개발·고도화하고 있습니다. 또한, 무배당발 서비스를 포함한 무신사의 차별화된 고객 경험을 브랜딩하고 확장할 수 있는 멤버십 구조를 설계하며, 온·오프라인을 넘나드는 통합 커머스 경험을 기술로 실현하고 있습니다.

저희 팀은 OMS(주문관리시스템)를 기반으로 온라인 주문부터 재고·출고·배송·정산에 이르는 전 과정을 유기적으로 연결하고, 무신사의 다양한 오프라인 스토어를 효과적으로 운영할 수 있는 관리 시스템을 구축하여 고객이 온라인(무신사 스토어, 29CM 등)과 오프라인(무신사 스탠다드, 편집숍 등)에서 끊김 없는 쇼핑 경험을 누릴 수 있도록 지원합니다.

*🚀 Platform Business Operation 한걸음 더 알아보기*

*🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요)*

🚀 팀 무신사 테크 소식을 받아보는 링크드인

🚀 팀 무신사 뉴스룸