[Tech] 에이피알 개발팀의 AI Native 운영기

안녕하세요, 에이피알 개발1팀에서 근무하고 있는 한기찬이라고 합니다. 👋

이번엔 저희 개발팀의 AI 운영 방식에 대해 이야기를 나눠보고 싶어 글을 쓰게 됐어요.

에이피알 개발팀은 시장 변화와 고객 반응 속도가 매우 빠른 환경에서 성장해온 조직이에요. 아이디어를 실행으로 옮기는 속도, 고객 반응을 제품에 반영하는 속도, 그 과정에서 생기는 문제를 빠르게 정리하고 개선하는 속도가 성장의 큰 원동력이죠.

그런데 속도가 빨라질수록 작은 마찰도 함께 늘었어요. 보안 점검이 담당자의 컨디션에 따라 흔들리고, 디자이너에게 같은 질문을 반복하고, 커밋 메시지 형식을 리뷰에서 또 고쳐달라는 코멘트를 달게 되고. 하나하나는 작지만, 쌓이면 팀의 속도를 갉아먹는 것들이었습니다.

저희 팀도 처음에는 AI를 개인 생산성 도구로 썼는데요. 반복 코드를 빠르게 작성하고, 문서를 요약하고, 디버깅을 돕는 데는 분명 효과가 있었어요. 그런데 이 방식은 개인 단위의 속도만 조금 높여줄 뿐, 팀이 더 빠르게 결정하고 실행하고 학습하는 구조로는 이어지지 않았던 것 같아요.

이 글의 결론을 먼저 말하면, 중요한 것은 AI를 얼마나 많이 쓰는가가 아니라, 팀의 기준과 판단이 재사용 가능한 형태로 쌓이는가예요. 그래서 에이피알 개발팀은 도구를 더 잘 쓰는 수준을 넘어, 일하는 방식 자체를 AI를 전제로 다시 설계하기 시작했어요. 이 글은 그 재설계가 실제로 어떤 운영 방식으로 자리 잡아가고 있는지 보여주는 기록이라고 봐주시면 됩니다. 🗂️

AI Native 조직이란 무엇인가

에이피알 개발팀이 말하는 AI Native 조직은 이렇게 정의하고 싶습니다.😊

AI Native 조직은 단순히 AI를 쓰는 조직이 아니라, 반복 판단과 루틴을 팀의 기본 동작으로 바꾸는 조직이에요.

사람은 책임, 우선순위, 예외 판단을 맡고, 도구는 반복 검증, 기본값 적용, 기록 축적을 맡는 방식이라고 할 수 있어요. "다 자동화하자"가 아니라, 자동화할 영역과 사람의 판단을 남길 영역을 구분하는 균형 잡기에 가까워요.

이 정의를 기준으로 보면, 아래에 말씀드릴 세가지 사례도 결국은 같은 방향성을 지닌 이야기라고 할 수 있습니다. 사람이 매번 직접 확인하거나 설명해야 했던 작업들을 시스템 안으로 옮기고, 담당자마다 달라질 수 있었던 작업 흐름을 가능한 한 공통된 기본 동작으로 바꿔간 사례들이죠.

사례 1. 보안 점검을 '체크리스트'가 아니라 '기본 동작'으로 만들기

문제

저희 팀은 배포 빈도가 높아지면서 보안 점검이 담당자 숙련도와 체크리스트 이행 여부에 따라 흔들리는 문제를 겪었어요. 일이 늘어날수록 누락 가능성이 커지는 구조였고, 이슈가 생겨도 "언제 누가 확인했는지"를 추적하기 어려웠어요. 체크리스트가 있어도, 사람이 직접 확인해야 시작되는 구조에서는 한계가 있었습니다.

에이피알 개발팀이 바꾼 기본값

그래서 저희는 "더 꼼꼼해지자" 보다는, PR이 올라오는 순간부터 보안 점검이 자동으로 시작되는 흐름을 만들기로 했습니다.

1. PR이 올라오면 CI가 빌드·린트·타입체크·테스트를 통과시킨 뒤, Docker 이미지를 빌드하고 Trivy(컨테이너와 의존성 취약점을 점검하는 스캐너)로 CRITICAL/HIGH 취약점을 스캔해요.

2. 취약점이 발견되면 CVE 번호·패키지명·현재 버전·수정 가능 버전을 정리한 GitHub Issue가 자동 생성돼요.

3. 이 이슈를 받은 Claude가 취약점을 분석하고, 수정 PR을 만들어요. PR에는 업그레이드한 패키지 목록뿐 아니라, 개발자가 확인해야 할 breaking changes와 영향받는 파일 경로도 함께 정리돼요.

4. 원본 PR에는 Closes #이슈번호가 자동으로 추가되어, 머지 시 관련 이슈가 함께 닫혀요.

   
   

AI를 이 흐름에 넣을 때 저희가 가장 먼저 한 일은 기준을 명확히 만드는 것이었어요. 이 기준은 워크플로우 안에 코드로 들어가 있어요.

• 실제 위험: package.json에 명시된 직접 의존성이거나, 웹 애플리케이션에서 실행 경로가 있는 전이 의존성은 패치된 버전으로 올려요.

• 무시 가능: OS 레벨 패키지(zlib, libcrypto 등)나, 런타임에 호출되지 않는 도구(apk, wget 등), 컨테이너 환경에서 이미 완화된 취약점은 .trivyignore에 사유와 함께 추가해요.

• 업그레이드 정책: 마이너·패치를 우선하고, 정말 불가할 때만 메이저를 검토해요.

사람이 남긴 판단

허용·차단·업그레이드 범위·ignore 여부는 사람이 직접 책임집니다.

Claude가 만든 수정 PR에는 "개발자 확인 필요 사항" 섹션이 포함돼요. 패키지별 breaking changes, 영향받는 코드 경로, 수동 테스트 체크리스트가 정리되어 있어서, 사람은 "이 업그레이드가 안전한가?"를 판단하는 데 집중할 수 있어요. 무시 처리한 취약점도 .trivyignore에 사유가 한 줄로 남아요.

CVE-2024-XXXXX # OS-level package, not invoked at runtime, mitigated by container network config

담당자가 바뀌어도 "왜 이걸 무시했는지"가 기록에 남아 있으니, 다음 사람이 같은 고민을 처음부터 반복하지 않아도 되죠.

저희 팀에서 달라진 것

자동화의 첫 단계는 코드가 아니라 기준이에요. 같은 원칙은 협업의 마찰을 줄이는 데도 그대로 적용돼요.

사례 2. 디자인-개발 간격을 '질문'이 아니라 '컨텍스트 호출'로 줄이기

문제

디자인과 개발 사이의 비용 대부분은 작업량 자체가 아니라 질문·정렬·확인에서 생겨요. 저희 팀에서는 이런 일이 반복됐어요.

• 이 컴포넌트는 어떤 토큰을 쓰지?

• 선택한 노드의 실제 구조는 어떻게 생겼지?

• 지금 보고 있는 화면의 전체 트리는 어떻게 돼 있지?

디자인 의도와 구조가 Figma 안에 갇혀 있으면, 결국 "추측으로 빠르게 만들거나, DM으로 확인하고 나서야 정확하게 만드는" 선택을 반복하게 돼요.

APR 개발팀이 바꾼 기본값

한마디로 요약하면, 디자이너의 Figma 화면을 AI가 직접 들여다볼 수 있는 창문을 만든 거예요.

Figma에도 REST API가 있지만 저희 용도에는 한계가 있었어요.

저희는 REST API를 우회하고, Figma 플러그인의 내부 API로 데이터를 직접 읽어 WebSocket으로 전달하는 구조를 만들었어요. 여기에는 Figma 플러그인 아키텍처의 제약을 풀어야 하는 문제가 있었어요. Figma 플러그인의 Main Thread는 디자인 데이터에 접근할 수 있지만 네트워크를 쓸 수 없고, UI Thread(iframe)는 네트워크를 쓸 수 있지만 디자인 데이터에 접근할 수 없어요. 그래서 UI iframe이 두 세계를 연결하는 WebSocket 릴레이 역할을 맡는 구조로 설계했어요.

MCP 서버는 8개 도구를 제공해요. AI 도구에서 자연어로 요청하면 적절한 도구가 호출되는 방식이에요.

• get_document — 현재 페이지 전체 트리 (페이지 구조 파악)

• get_selection — 선택된 노드 (특정 컴포넌트 분석)

• get_node — ID로 노드 조회 (드릴다운 탐색)

• get_styles — 로컬 스타일 목록 (디자인 시스템 추출)

• get_variable_defs — 디자인 토큰/변수 (색상·타이포 토큰 추출)

• get_design_context — AI 컨텍스트 최적화 트리 (기본 depth=2)

• get_metadata — 파일·페이지 정보

• save_screenshots — 노드를 이미지로 저장

예를 들어 "선택한 컴포넌트를 React 코드로 변환해줘"라고 하면 get_selection이, "이 디자인의 색상 팔레트를 추출해줘"라고 하면 get_styles + get_variable_defs가 호출돼요.

이때 저희가 중요하게 여긴 원칙은 "많이 주는 것"이 아니라 "필요한 만큼만 주는 것"이에요. Figma 문서는 수천 개의 노드로 커질 수 있어서, get_design_context는 기본 depth=2로 트리를 잘라서 AI 컨텍스트 윈도우를 절약해요. 깊이 제한에 걸린 노드는 자식 전체 대신 childCount만 반환해서, AI가 구조를 파악하되 토큰을 낭비하지 않도록 했어요.

사람이 남긴 판단

어떤 경험을 우선할지, 어떤 트레이드오프를 감수할지, 디자인 의도를 최종적으로 어떻게 해석할지는 사람이 맡아요.

도구는 디자인 데이터라는 근거를 제공하고, 그 데이터를 바탕으로 제품 경험을 어떻게 만들지는 사람이 판단해요.

저희 팀에서 달라진 것

부수적인 변화도 있었어요. 원래 프론트를 주로 하지 않던 엔지니어도 디자인 데이터를 근거로 UI를 구현할 수 있게 되면서, 작은 제품 개선을 더 많은 사람이 병렬로 처리할 수 있게 됐어요. 프론트엔드 엔지니어는 디자인 시스템·성능·DX 같은 더 어려운 문제에 집중할 수 있고요.

Figma MCP 브릿지의 설계와 구현에 대해서는 다음 글에서 더 자세히 다뤄볼 예정이에요.

좋은 자동화는 "많이 주는 것"이 아니라 "필요한 만큼만 주는 것"이에요. 이 발상은 디자인 데이터에만 머물지 않아요. 팀 규칙과 컨벤션을 전달하는 방식도 같은 원리로 다시 설계할 수 있어요.

사례 3. '컨벤션' 전달을 문서에서 플러그인으로 옮기기

문제

APR 개발팀은 새로운 기술 스택·도메인·레포지토리를 빠르게 만나는 조직이에요. 팀이 커지고 프로젝트가 늘어나면서 작은 불일치가 계속 생겼어요.

• 커밋 메시지 형식이 제각각이에요.

• 브랜치 네이밍이 사람마다 달라요.

• PR 템플릿이 있어도 형식적으로만 작성돼요.

문서로 규칙을 공유하면 프로젝트가 늘어날수록 규칙도 복제되고, 결국 관리가 어려워져요. 새로 합류한 사람은 문서를 여러 개 찾아 읽고 "이건 왜 이렇게 해요?"라고 묻고, 낯선 레포지토리를 만난 팀원은 기존 코드에서 패턴을 역추적해야 했어요.

APR 개발팀이 바꾼 기본값

저희 팀은 팀 컨벤션을 Claude Code 플러그인으로 만들고, 마켓플레이스를 통해 배포했어요. 설치는 세 줄이에요.

/plugin marketplace add APR-CORP/apr-claude-marketplace
/plugin install apr-claude-plugin@apr-claude-marketplace
/apr-setup

플러그인은 세 가지 요소로 구성돼요.

Skills — 슬래시 커맨드로 호출하는 워크플로우 20개예요. FE/BE별 브랜치 생성(/apr-fe-create-branch), 커밋 메시지 생성(/apr-fe-create-commit), PR 생성(/apr-fe-create-pr), 한 번에 브랜치부터 PR까지 처리하는 통합 커맨드(/apr-fe-branch-to-pr)가 있어요. 그 외에도 Swagger 스펙에서 FE 타입과 API 코드를 생성하는 /apr-fe-api-sync, 컴포넌트 변경의 영향 범위를 3단계까지 추적하는 /apr-fe-impact-analysis 같은 도구도 있어요.

예를 들어 커밋 메시지는 git diff를 분석해 type(scope): subject 형태로 자동 생성해요.

feat(auth): 소셜 로그인 카카오 연동 추가
fix(social-feed): 무한 스크롤 중복 요청 수정
refac(api): axios 인터셉터 에러 처리 통합

type은 변경 내용에서, scope는 변경 경로에서 추론해요.

Agents — 특정 요청에서 자동으로 붙는 전문 역할 7개예요. 구현 담당(executor), 검증 담당(verifier), 코드 리뷰어(code-reviewer), 아키텍트(architect), 디버거(debugger), 보안 리뷰어(security-reviewer), 테스트 엔지니어(test-engineer)가 있어요. 특히 구현과 검증을 분리해서, 코드를 작성한 에이전트가 스스로 검증하지 않도록 설계했어요.

Hooks — 위험한 동작을 사전에 막는 안전장치예요. .env, credentials.json, *.pem, *.key 같은 민감 파일의 읽기·수정을 차단하고, main, stage, dev, release/* 브랜치에 직접 커밋하는 것을 막아요. 세션이 시작될 때 프로젝트의 기술 스택(Next.js, NestJS, Go 등)을 자동 감지해서 표시해주기도 해요.

규칙이 바뀌면 플러그인을 업데이트하고, 팀원은 /plugin update로 반영해요.

사람이 남긴 판단

무엇을 바꾸는지, 왜 그렇게 바꾸는지, 어떤 맥락에서 리뷰해야 하는지는 사람이 맡아요.

플러그인은 판단을 대신하는 게 아니라, 판단이 정해진 이후 실행을 일관되게 만드는 역할이에요. 커밋 type 분류 기준, 보호 대상 브랜치 목록, 민감 파일 패턴은 팀이 논의해서 결정하고, 그 결정이 플러그인 설정으로 들어가요.

저희 팀에서 달라진 것

이건 신규 입사자뿐 아니라 처음 보는 레포지토리나 낯선 프레임워크를 만난 기존 팀원에게도 똑같이 작동해요.

개발팀이 실제로 바꾼 일하는 방식

세 사례가 다루는 대상은 다르지만, 바꾸려는 것은 모두 팀의 기본 동작이에요. 묶어보면 운영 원칙이 하나로 보여요.

1. 기본값 우선: 반복되는 일은 "누가 잘하느냐"의 문제가 아니라 기본값으로 만들어요.

2. 근거와 기록: AI가 움직일 때는 반드시 근거와 기록이 남도록 설계해요.

3. 컨텍스트 공유: 팀의 대화는 설명보다 컨텍스트를 공유하는 쪽으로 바꿔요.

4. 워크플로우에 내장: 규칙은 문서로 끝내지 않고, 가능한 한 워크플로우에 넣어버려요.

   
   

저희 내부에서 자주 공유되는 원칙이 있어요. "일의 우선순위를 잘 정해서, 가장 큰 기대효과를 낼 수 있는 일에서 사람이 성과를 내야 한다." 반복 업무와 기본 검증을 자동화하는 이유는 결국 팀이 가치 있는 판단과 실행에 시간을 쓰게 만들기 위해서예요.

마치며

AI Native의 본질은 모델 자체가 아니라, 일하는 방식의 재설계에 있어요. 에이피알 개발팀이 만들고 싶은 건 몇 가지 도구가 아니라, 팀의 기준과 판단이 쌓이고 재사용되는 구조예요.

솔직히 말하면, 지금 확장하고 있는 실험들 중에는 이 글에서 다루지 못한 것들이 많은데요. 재미있고 효과가 큰 부분일수록 더 민감해서 더 조심스러워야 한다는 점이 아이러니하기도 하고요. 😅 그래서 이 글은 끝이 아니라, 저희가 공유할 수 있는 것부터 하나씩 꺼내놓는 시작이에요.

저도 이렇게 글을 정리하면서 팀이 지난 몇 년 동안 쌓아온 변화들을 다시 돌아보게 됐어요. 처음 이 방향을 고민하던 때와 비교하면, 일하는 방식도 많이 달라졌고 그 과정에서 팀도 함께 성장해온 것 같아 감회가 새롭네요. 앞으로도 들려드릴 이야기들이 무궁무진하니, 종종 찾아뵐게요! 🙌

그리고 저희와 함께 다음 기본값을 함께 설계할 엔지니어분도 기다리고 있겠습니다. 😊

에이피알에 합류하고 싶으신 분이라면, 아래 버튼을 클릭해서 오픈된 포지션을 확인해보세요!