태그

engineering-leadership

32

같은 도구를 깔아도 결과가 갈린다 — 조직 운영과 부서 자동화 18문답

AI를 조직에 들일 때 반복되는 열여덟 문항에 결론부터 답한다. 무엇부터 바꾸고 생산성을 무엇으로 재는지, 강제와 채택 설계가 어떻게 갈리고 자동화를 어디서 멈추는지를 정리하고, 「도구를 깔면 생산성이 오른다」·「개인이 잘 쓰면 조직도 잘 쓴다」·「에이전트 개수가 규모를 말해 준다」는 세 직관을 교정한다.

사람 게이트는 루프의 종료조건이 아니라 단계의 경계다 — 요구사항에서 운영까지 여섯 게이트와 개발·QA·배포 각론

요구사항에서 운영까지 여섯 단계마다 「AI가 처리하는 것 / 사람이 승인하는 게이트 / 통과 기준」을 규칙으로 고정한 자료를 옮긴다. 관통 원칙과 공통 안전장치 넷, 로컬과 서버사이드의 강제 경계, 여섯 단계 파이프라인을 먼저 싣고, 같은 여섯 단계를 원 자료가 두 번 적은 두 판본을 항목 단위로 대 본다. 이어서 개발·QA·배포 세 영역의 각론으로 내려가 도구 열여섯 종과 선택 기준, JetBrains에서 Copilot을 자동완성 너머로 쓰는 일곱 기능, 매니지드 PR 리뷰가 막힌 AWS CodeCommit 환경의 세 선택지, 그리고 세 영역의 KPI와 함정을 함께 싣는다.

AI 전환 조직수정 2026-08-17

개인이 AI를 잘 쓰는 것은 조직 역량이 아니다 — 빌더에서 오케스트레이터로 가는 조직 설계

AI 전환 조직을 인력 감축이 아니라 생산 함수의 교체로 정의하는 원 자료를 정리한다. 개인기·팀 시스템·조직 역량 3단 모델, 다섯 직무의 빌더→오케스트레이터 재정의, 중앙 이네이블먼트와 분산 스쿼드의 하이브리드 구조, NIST AI RMF를 다섯 가드레일로 옮긴 체크리스트, 그리고 Klarna·Shopify·Duolingo부터 당근·토스·CJ올리브영·카카오까지 실제 기업 사례 열한 개를 U턴 반례와 시점 표기까지 함께 싣는다.

조직도의 인계 화살표마다 라벨이 달려 있다 — 여섯 부서 26종 에이전트 정의서

7개 부서 30에이전트 세트에서 개발기술 4종을 뺀 여섯 부서 26종을 부서별로 펼친다. 각 부서의 위임 흐름 도식은 인계 화살표 35개마다 라벨을 달고 있고, 그중 여덟 개가 부서 밖으로 나간다. 절마다 정리된 프롬프트 설계 기법 39가지를 모델의 재량을 어디서 좁히는지에 따라 여섯 갈래로 전수 배정하고, 이미 발행된 카탈로그·품질 편과 겹치는 자리를 자리별로 표시한다.

권한은 프론트매터로 좁히고 통합은 Bash 한 구멍으로 — 30개 에이전트 카탈로그

7개 부서 30개 에이전트 정의서를 한 장의 표로 펼친다. 모델은 opus 10 : sonnet 20으로 갈리고 도구 변형은 세 가지뿐인데, 정작 외부 시스템 연동은 프론트매터에 드러나지 않는다. 사람 검수 필요도의 요약값과 카탈로그를 세어 본 값이 어긋나는 자리, 그리고 같은 카테고리의 다른 글에 있는 30에이전트 표와 이 표가 같은 세트가 아니라는 근거도 함께 짚는다.

규칙 문서부터 쓰면 막힌다 — 합격선 5축과 60줄 원칙

에이전트를 만든 다음이 아니라 만들기 전에 정해야 하는 것 — 무엇을 자동화 대상으로 고를지 판단하는 두 도구와, 「끝났다」를 판정하는 5축 정량 루브릭, 그리고 조직 규칙 문서를 60줄로 유지하는 이유를 정리한다. 같은 문서의 분량을 이 카테고리의 다른 글이 200줄로 부른 것과의 관계도 함께 짚는다.

에이전트 개수는 자산이 아니라 부채로 시작한다 — 개발조직에 옮길 것과 비어 있는 여섯 자리

7개 부서 30에이전트 세트에서 개발기술 4종을 자세히 보고, 나머지 26종 중 개발조직 실무로 옮길 수 있는 것과 참고만 할 것을 가른다. 재사용 후보 10종이 실제로 옮기는 것은 에이전트가 아니라 그 에이전트가 강제하던 형식이며, 도입 순서를 개수로 끊는 근거는 트리거 키워드 충돌이다. 마지막으로 이 세트에 아예 자리가 없는 여섯 영역을 짚는다.

잠재 경로는 개수의 제곱으로 는다 — 확장 구간별 운영 모델과 반복 실패 4가지

에이전트가 10개를 넘을 때 라우팅·비용·디버깅이 동시에 무너지는 메커니즘과, 5개에서 100개까지 구간별로 갈아타야 하는 운영 모델을 정리한다. 재사용 라이브러리와 권한 등급, 비용을 축별로 나누는 방법, 그리고 「그래서 효과가 얼마였나」에 답하는 증명 3종과 반복 실패 패턴 4가지까지 잇는다.

형식은 템플릿이 복제하지만 안전장치는 복제되지 않는다 — 정의서 스키마와 30종의 품질 편차

에이전트 정의서 한 개의 구조를 프론트매터 4필드와 본문 7섹션으로 분해하고, 같은 스키마로 쓰인 30종에서 관찰된 품질 편차를 대조표로 본다. 형식 항목은 30/30으로 균질한데 권한 축소·승인 게이트·면책은 5/30, 3/30, 1/30으로 떨어진다. 그리고 경계 섹션이 실재하지 않는 이름을 지목한 건수가 원 자료의 산문과 표에서 갈린다는 점도 짚는다.

되돌릴 수 있어야 권한을 넓힌다 — CLAUDE.md 규약과 실패 모드 3분류

에이전트에게 줄 권한의 상한을 정하는 것은 신뢰가 아니라 복구 가능성이다. Git이 안전망이자 컨텍스트 공급원이 되는 구조, 검증 가능한 규약 파일이 갖춰야 할 다섯 요소, 그리고 환경 문제 20여 건이 수렴하는 세 가지 원인을 정리한다.

백엔드 엔지니어링수정 2026-08-19

「되돌린다」는 한 가지 명령이 아니다 — 형상관리가 CI/CD의 전제인 이유

CI/CD 일곱 편 중 둘째다. 파이프라인이 서 있는 첫 전제인 형상관리를 연다. CD가 사람 손을 어디까지 뗄 수 있는지 그 경계를 먼저 긋고, Git이 파일을 Working Directory · Stage(Index) · Repository 세 곳에 나눠 두는 구조에서 「되돌린다」가 왜 두 번 갈리는지, 그리고 실무 배포의 기준이 왜 브랜치가 아니라 태그인지까지 간다.

에이전틱 코딩수정 2026-08-13

에러 없이 실패하는 배포가 있다 — 운영·거버넌스 17문답

권한을 어디까지 좁히고 무엇을 첫날부터 남기는지, 장애가 나면 어떤 순서로 좁히는지를 결론부터 정리한다. 비용 폭주를 끊는 자리와 도입 성공을 판정하는 5축, 그리고 「퍼미션 모드가 몇 개인가」에 개수로 답하지 않는 이유까지 열일곱 문항.