AX 를 맡기면
무엇이 남나

업무 자동화(AX)를 외부 전문가에게 맡기면 빠르다. 그런데 만든 사람이 떠나는 날, 고객에게 무엇이 남는지는 따로 물어야 한다.

전문가의 머릿속을
시스템에 옮겨 담았다

Brie 는 AX 를 대신 해 주지 않는다.
고객이 스스로 하게 만든다.

처음 하는 사람이 혼자 해낼 수 있는 이유는 그가 전문가가 되어서가 아니다. 전문가가 하나씩 답하던 질문들의 답을 출발점·부품·일하는 방식·검사기·서버 도구·교훈으로 미리 만들어 두었기 때문이다. 사람은 질문마다 공부하는 대신 무엇을 만들지 정하고, 승인하고, 확인한다.

이 자료는 처음 하는 사람이 부딪히는 벽을 하나씩 짚고, 각 벽에서 standarda 가 무엇을 대신 정해 두었는지를 실제 화면·명령·기록으로 보여 준다. 각 장 뒤의 "안 들여다보기" 쪽은 그 장치가 실제로 어떻게 생겼는지 궁금한 사람을 위한 것이다.

처음 하는 사람이 부딪히는
7개의 벽

standarda 는
여섯 층으로 되어 있다

각 층은 처음 하는 사람이 혼자 답하기 어려운 질문 묶음 하나를 맡는다. 어느 층도 사람에게 공부를 요구하지 않는다 — 정해 둔 답을 쓰게 한다.

첫 화면을 띄우기도 전에
정해야 할 것이 너무 많다

요즘은 말로 시키면 된다. "앱 만들어 줘. 회원가입·로그인 만들어 줘. DB 만들어 줘. 서버 주소 준비해 줘." 맞다 — standarda 도 말로 시킨다. 문제는 그 말 한마디 뒤에 숨은 질문들이다.

AI 는 이 질문마다 그럴듯한 답을 골라 만들어 준다. 처음 해 보는 사람은 그 답이 맞는지, 무엇을 더 물어야 하는지 알 수 없다. 그래서 남는 길은 둘이다.

그 질문들의 답이 든 출발점을
세 번의 요청으로 연다

standarda 의 출발점에는 앞 쪽 질문들의 답이 이미 정해져 들어 있다. 그래서 사람은 질문마다 공부하는 대신, 그 출발점을 여는 세 가지만 한다.

업무 기능이 하나도 없어도
이미 쓸 수 있는 앱이다

실측 때 만든 프로젝트를 바로 열어 본 화면이다. 업무 기능은 아직 하나도 만들지 않았지만, 가입·로그인부터 견본 업무 화면까지 이미 동작한다. 사람이 할 일은 여기에 "우리 업무"를 얹는 것뿐이다.

https://timing-check-dev.brie.co.kr/login/

https://timing-check-dev.brie.co.kr/projects/

널리 쓰는 기술만으로,
한 사람이 화면부터 DB 까지 다룬다

화면·서버·데이터베이스를 따로 다른 기술로 나누지 않는다. 서버 하나(Django)가 화면도 그리고 API 도 내보내므로, 업무를 아는 한 사람이 AI 와 함께 처음부터 끝까지 고칠 수 있다.

계정 흐름 다섯 가지가
처음부터 한 세트로 동작한다

벽 1 의 "로그인 만들어 줘" 뒤에 숨은 질문들에 대해, 출발점은 아래처럼 답을 정해 두었다. 아이디는 이메일이다.

모든 업무 데이터가
견본 하나와 같은 모양으로 만들어진다

출발점에는 목록·상세·등록·수정·삭제를 모두 갖춘 견본 업무 앱이 들어 있다. 새 업무 앱은 이 견본을 통째로 복사해 시작하므로, 데이터 구조·API·관리 화면이 프로젝트마다 같은 약속을 따른다.

데이터(모델) — 모든 표가 가진 기본 칸

API — 주소 다섯 개로 끝난다

응답은 늘 같은 모양 — 성공 {"success": true, "data": …}, 입력 오류 {"success": false, "errors": …}. 화면 쪽 JS 는 이 모양 하나만 알면 된다.

화면 한 장 = 템플릿 하나 + JS 하나,
부품은 이미 만들어져 있다

화면마다 파일 구성이 같고, 버튼·입력창·표·모달 같은 부품은 디자인 시스템에 이미 들어 있다. 그래서 새 화면은 부품을 조립하고 그 화면의 동작만 쓰면 된다.

디자인 시스템 base.css 에 들어 있는 부품

색은 직접 값 대신 변수로 쓴다 — 회사 색으로 바꿀 때 한 곳만 고치면 된다.

모든 화면이 함께 쓰는 api.js

화면 동작은 늘 같은 순서로 쓴다 — 입력 확인 → 버튼을 "처리 중"으로 → 서버 호출 → 결과 그리기 → 버튼 되돌리기.

코드와 파일을 나눠 두고,
개발과 운영에서 내보내는 길만 다르다

CSS·JS·이미지 같은 정적 파일과 사용자가 올린 파일은 코드 폴더 밖, 프로젝트 폴더 옆에 따로 모인다. 코드를 새로 받아도 올린 파일이 섞이거나 사라지지 않는다.

~/settle_helper/                 ← 프로젝트 (파이썬 환경 포함)
    └── src/                     ← 코드 (GitHub 에 올라가는 곳)
          ├── static/            ← 내가 만든 CSS · JS · 이미지
          └── templates/
~/settle_helper_static_cdn/      ← 코드 밖, 프로젝트 옆
    ├── static/                  ← 운영용으로 모은 정적 파일
    └── media/                   ← 사용자가 올린 파일

폴더는 프로젝트를 만들 때(setup.sh) 자동으로 생긴다. 출발점에 들어 있는 업로드 칸은 프로필 이미지 하나이며, 날짜별 폴더에 겹치지 않는 이름으로 저장된다.

프로젝트마다 반복되는 일은
함수 하나로 끝낸다

utils/ 에는 거의 모든 프로젝트가 똑같이 필요로 하는 일을 미리 만들어 둔 함수가 모여 있다. 화면과 API 를 만들 때는 이 함수들을 가져다 쓰고, 같은 코드를 다시 쓰지 않는다.

3분 24초는 이렇게 쟀다

"이 PDF 읽어서 정리해 줘" 한 줄에
정해야 할 것이 줄줄이 따라온다

업무 자동화의 대부분은 문서를 읽고, AI 에게 묻고, 결과를 어딘가에 남기는 일이다. 말로 시키면 AI 가 코드를 써 준다. 하지만 그 코드가 실제 업무에서 매일 돌아가려면 아래 질문들에 먼저 답해야 한다.

벽 1 과 같다. AI 는 질문마다 그럴듯한 답을 골라 만들어 준다. 처음 하는 사람은 그 답이 맞는지 알 수 없고, 질문마다 찾아보고 공부하거나, 업무에 쓰는 날 막히고 나서야 안다.

답이 정해진 부품 52개를,
AI 가 알아서 꺼내 쓴다

앞 쪽 질문들의 답은 공용 부품 묶음 standarda-core 에 함수로 들어 있다. 그리고 출발점의 AI 작업 규칙이 "AI 기능은 core 부품으로만 만든다"고 정해 두었다. 그래서 사람은 부품 이름을 몰라도 된다.

부품 묶음 — 공개 함수 52개 + 구글 서비스 연결 43개

한 곳에서 고치면,
모든 프로젝트가 함께 고쳐진다

AI 는 몇 달마다 새 모델이 나오고, 그때마다 예전엔 되던 것이 갑자기 안 된다. 프로젝트마다 AI 코드를 따로 갖고 있으면 그 원인을 각자 찾아야 한다. standarda 에서는 부품 한 곳을 고치고, 각 프로젝트는 부품 버전만 올린다.

잘 만든 것은 부품으로 올라온다

한 프로젝트에서 검증된 기능은 core 로 올라와 모두의 부품이 된다. 슬라이드 PDF 만들기, 회의 녹음 받아쓰기, 결과 검증 함수가 그렇게 올라왔다. core 는 2026년 2월 이후 버전 30개를 냈고, 이 서버의 프로젝트 13개가 core 를 버전으로 고정해 쓰고 있다.

모델 네 곳을 같은 방법으로 부르고,
바꿀 때는 설정만 고친다

어느 회사의 AI 든 함수 하나로 연결한다. 코드에는 "AI 를 쓴다"만 적고, 어떤 모델을 쓸지는 설정 파일이 정한다.

모델을 정하는 순서

모델이 바뀔 때마다 생기는 차이를 부품이 흡수한다

모든 연결에 응답 대기 시간·재시도 횟수를 정할 수 있고, 호출 기록은 추적 도구(LangSmith)에 자동으로 남는다 — 어느 단계에서 무엇을 묻고 무엇을 받았는지 나중에 볼 수 있다.

문서는 성격에 맞는 길로 읽고,
AI 답은 바로 쓸 수 있는 모양으로 받는다

PDF 와 엑셀에는 읽는 길이 두 가지씩 있다. 문서가 깔끔한 글자 위주면 글자로, 표·도장·스캔본이면 그림으로 읽는다. 어느 쪽이든 함수 하나다.

글자 인식(OCR) 프로그램은 따로 두지 않는다 — 스캔본도 AI 가 그림으로 읽는다.

AI 답 다루기 — 가장 많이 쓰이는 부품

사람이 이 코드를 쓰지 않는다 — "이 계약서에서 금액과 기간을 뽑아 줘"라고 하면 AI 가 이 부품들로 조립한다.

회사가 이미 쓰는 도구에
결과를 바로 남긴다

자동화의 결과는 새 화면이 아니라 늘 쓰던 곳에 남을 때 쓰인다. 구글 업무 도구 네 가지를 부품으로 연결해 두었다.

연결 방식은 두 가지 — 회사 계정 하나로 쓰거나, 사용자마다 자기 구글 계정으로 동의하고 쓴다(내 메일·내 드라이브를 대상으로 하는 업무).

아끼고, 돌리고, 확인하는 일도
부품으로 해 둔다

AI 를 매일 업무에 쓰기 시작하면 세 가지가 남는다. 비용이 얼마나 드는지, 여러 단계를 스스로 처리하는 에이전트를 어떻게 돌리는지, 결과를 어떻게 믿을지.

비용

에이전트 — build_tool_loop_graph()

AI 가 도구(검색·조회·계산 등)를 골라 쓰고, 결과를 보고, 다시 판단하는 반복 구조의 뼈대다. 도구를 순서대로 실행하고, 대화가 길어져도 캐시를 이어 붙이고, 반복 횟수 상한과 마지막 답 꺼내기까지 정해져 있다. 프로젝트는 도구만 만들어 끼운다.

결과 검증 — 3단계

AI 가 "다 처리했다"고 말하는 것과 실제로 맞게 처리된 것은 다르다. 검증 부품은 그 차이를 숫자로 보여 준다 — 사람은 다른 것만 보면 된다.

부품을 고쳐도
쓰는 쪽은 한 줄도 바꾸지 않는다

여러 사람이 만든 여러 프로젝트가 같은 부품을 쓴다. 그래서 부품은 "쓰는 쪽 코드는 그대로, 버전만 올리면 좋아진다"는 약속을 지킨다.

버전 흐름 — 2026년 2월 ~ 11월, 버전 30개

AI 에게 일을 맡기는 순간,
맡긴 사람이 답해야 할 것이 생긴다

AI 는 시키면 만든다. 문제는 그다음이다. 결과를 판단하고, 이어서 고치고, 남에게 넘기는 일은 여전히 사람의 몫인데, 코드를 읽지 못하면 그 판단을 할 근거가 없다.

이 질문들은 코드 지식이 아니라 일하는 방식의 문제다. 숙련된 개발자는 경험으로 답하지만, 처음 하는 사람에게는 답할 근거가 없다.

개발 요청은 늘 같은 순서로 돌고,
사람은 쉬운 말 요약을 한 번 승인한다

"만들어 줘", "고쳐 줘" 같은 개발 요청은 따로 말하지 않아도 /develop 이라는 정해진 흐름으로 처리된다. 흐름 안에서 사람이 하는 일은 한 번의 승인뿐이고, 나머지 확인은 AI 와 검증 에이전트가 한다.

오타·문구·설정값처럼 자명한 변경은 이 흐름 없이 바로 고친다. 회원가입·로그인 요청은 이미 있는 기능이므로 먼저 /signup 으로 확인한다.

판단은 사람이 쉬운 말로 하고,
확인은 시스템이 한다

앞 쪽의 질문들은 숙련자라면 경험으로 답한다. standarda 는 그 경험을 흐름과 규칙으로 바꿔, 처음 하는 사람도 같은 답을 갖고 일하게 한다.

이 흐름은 실제로 쓰면서 다듬어졌다

• 스펙을 두 층으로 — 처음 스펙은 개발자용 명세뿐이었다. 비개발자가 승인할 수 있도록 맨 위에 쉬운 말 요약 층을 더했다.
• "모든 개발 요청에 기본" — 요청할 때만 쓰던 흐름을, 따로 말하지 않아도 적용되도록 바꿨다. 쓰는 사람이 흐름을 기억할 필요가 없다.
• 확인은 한 번으로 — 교육 리허설에서 단계마다 묻고 답하느라 시간이 걸렸다. 질문을 한 메시지로 모으고, 검증도 한 번 돌린 결과를 합치기 단계가 그대로 쓰도록 줄였다.
• 검증은 메인 AI 가 직접 — 2026-11-13 교육 리허설에서 검증을 맡긴 하위 에이전트가 멈춰 7분을 기다렸다. 그날 바로 스펙 대조와 합치기 전 점검을 메인 AI 가 따르는 점검표로 바꾸고, 남은 하위 에이전트에는 "5분 안에 보고가 없으면 멈추고 메인이 직접" 규칙을 걸었다.

AI 는 매번 같은 규칙집을 읽고
같은 방식으로 일한다

CLAUDE.md 는 AI 가 대화를 시작할 때마다 자동으로 읽는 문서다. 사람마다 AI 에게 다르게 설명하던 "이 프로젝트에서는 이렇게 한다"가 여기 한곳에 적혀 있어, 누가 시키든 AI 가 같은 기준으로 일한다.

코드 규칙에 들어 있는 것 — 한 번씩 겪은 일이 규칙이 됐다

• AI 기능은 core 부품으로만 — 모델 연결은 get_*_llm(), AI 답은 response_text()·parse_json_from_llm(), PDF·엑셀은 글자/그림 중 골라서, 받아쓰기는 transcribe_audio()
• 날짜는 서울 시각으로 — 저장·표시를 정해진 함수로. 아니면 9시간이 어긋난다
• 오류를 조용히 넘기지 않는다 — 문제가 생기면 대충 다른 값으로 때우지 말고, 기록을 남기고 드러낸다
• 시트 범위는 그때그때 계산 — 행이 늘어도 빠지는 데이터가 없게
• 메일은 정해진 방식으로 — 주소·본문 만드는 함수를 하나로. 본문이 한 줄로 뭉개지는 일이 반복됐다
• 글자 맞추기로 분기하지 않는다 — "이 단어가 있으면 A" 대신 글 전체를 AI 에게 맡긴다
• 새 업무 앱은 견본을 복사해서 — 목록·상세·등록·수정·삭제를 한 번에

오류는 증거로 고치고,
교훈은 다음 프로젝트로 넘긴다

디버깅 규칙 — 5단계

Git 규칙 — 정본은 하나

• 작업은 늘 최신 정본에서 갈라진 사본에서 한다. 끝나면 정본에 합치고, 원격 저장소에 올리고, 사본을 지운다 — 사람이 따로 시키지 않아도.
• 정본은 앞으로만 나아간다. 되돌릴 때는 "되돌리는 기록"을 새로 쌓는다.

문서 규칙 — 교훈이 도는 고리

버그를 고치면 원인·해결·교훈을 담은 이슈 문서를 남기고, 그 교훈을 어디까지 퍼뜨릴지 네 층 중 하나로 고른다.

서버 켜기부터 회원가입까지,
자주 하는 일은 매뉴얼이 있다

스킬은 AI 에게 주는 업무 매뉴얼이다. 슬래시(/dev)로 불러도 되고 "서버 켜 줘"처럼 말로 해도 된다. 개발 흐름 /develop 은 앞에서 보았으므로, 나머지를 본다.

메일과 운영 절차도
처음 하는 사람이 끝까지 갈 수 있게

만든 것을 고객에게 넘길 자료도
스킬이 만든다

업무 시스템은 만들고 끝나지 않는다. 쓰는 사람에게 사용법을, 확인하는 사람에게 테스트 방법을 넘겨야 한다. 이 자료들을 실제 코드와 화면을 기준으로 만든다.

문서·보고서·화면 점검까지,
형식이 정해진 일은 형식대로

프로젝트에서 좋아진 것은 템플릿으로,
템플릿의 개선은 프로젝트로

한 프로젝트에서 찾은 더 나은 방법이 그 프로젝트에만 남으면 다음 프로젝트는 같은 시행착오를 다시 겪는다. 두 스킬이 출발점(템플릿)과 프로젝트 사이를 양쪽으로 잇는다.

"다 했다"는 말을
다른 눈이 확인한다

에이전트는 메인 AI 가 일을 나눠 맡기는 전문 보조원이다. 대부분 읽기만 하고 결과를 보고하며, 일부는 더 가볍고 빠른 모델로 돈다. 검증 에이전트는 메인 AI 가 만든 것을 다른 눈으로 본다.

과거의 교훈을 찾고,
오류의 증거를 모은다

문서 요청은 맞는 곳으로 보내고,
할 일은 파일 하나씩 관리한다

확인이 오래 걸리는 일은
필요할 때만, 정해진 방식으로

사람은 말하고 결정하고,
스킬과 에이전트는 서로를 부른다

하루 동안 오가는 요청이 어느 스킬로 들어가고, 그 스킬이 어떤 에이전트를 부르는지 한 장에 모았다. 사람이 외워야 할 명령은 없다 — 말로 하면 규칙집이 맞는 흐름으로 보낸다.

실수라는 걸 모르면,
조심할 수도 없다

AI 와 함께 처음 무언가를 만드는 사람은 아래 일들이 문제라는 것 자체를 모른다. 화면은 멀쩡하게 돌아가므로, 문제는 한참 뒤 다른 사람이 이어받을 때나 무언가 어긋났을 때 드러난다.

실수하는 순간에 멈추는
검사기 11개가 처음부터 들어 있다

검사기(hook)는 정해진 순간에 자동으로 돌아 규칙에 어긋나면 그 동작을 멈춘다. 프로젝트를 만들 때 이미 설치돼 있어서, 쓰는 사람은 존재를 몰라도 보호를 받는다.

Claude hook 과 git hook 이 같은 실수를 두 번 막는 곳이 있다 — AI 가 아닌 사람이 직접 커밋해도 git 단계에서 한 번 더 걸리게 하기 위해서다.

오류 고침·엉뚱한 저장소·정본 되돌리기,
세 가지 모두 실행되지 않았다

standarda 로 새로 만든 프로젝트(settle_helper)에서 실제로 시도한 결과다. 아래 출력은 손대지 않은 그대로다.

AI 가 실수하려는 순간,
이유와 고칠 방법이 같이 돌아온다

AI 가 명령을 실행하거나 파일을 쓰기 직전에 Claude Code 가 검사기에 넘기는 것과 같은 입력을 넣어 받은 응답이다. AI 는 이 응답을 읽고 스스로 고쳐 다시 시도한다.

정본은 앞으로만 움직이고,
되돌리는 것도 기록으로 남긴다

여러 사람과 여러 AI 대화가 같은 정본에 작업을 합친다. 그중 하나가 정본을 되돌리면, 이미 "끝났다"고 보고된 다른 작업이 사라진다. 그래서 정본은 앞으로만 움직이게 했다.

고칠 줄 몰라도,
처음부터 맞게 되어 있다

검사기가 "하면 안 되는 것"을 막는다면, 기본값은 "해야 하는데 모르는 것"을 미리 해 둔다. 아래는 모두 누군가 한 번 겪은 일을 출발점의 기본값으로 바꾼 것이다.

검사기와 기본값은 짝이다 — 기본값은 처음부터 맞게 해 두고, 검사기는 그 기본값에서 벗어나려는 순간을 잡는다.

안전장치가 조용히 꺼져 있으면
안전장치가 아니다

실수를 막는 장치가 있어도, 그 장치가 고장 난 걸 아무도 모르면 없는 것과 같다. standarda 는 검사기 자체도 검사한다.

AI 가 커밋하려 할 때
네 가지를 본다

원격 명령과 스킬 이름표는
보내기 전에 확인한다

사람이 직접 해도 걸리는 다섯 개 —
그중 셋은 정본을 지킨다

"실제로 막힌 장면"은
이렇게 만들었다

개발 서버에서 되는 앱을
매일 쓰게 만드는 일은 따로 있다

개발 서버에서 잘 돌아가는 것과 동료·고객이 매일 쓰는 것은 다른 일이다. 운영에 올리는 순간 아래 질문들에 답해야 한다. 대부분 서버 관리자의 경험으로 답하던 것들이다.

보통은 이 질문마다 서버 관리자에게 부탁한다. 그러면 관리자가 병목이 되고, 처음 하는 사람은 "내가 만든 것을 내가 올리는" 경험을 하지 못한다.

개발과 운영을 나누고,
각자 자기 앱을 직접 다룬다

서버는 두 대다. 개발 중에 DB 구조를 바꾸거나 서버를 다시 켜도 운영 중인 앱과 데이터에는 아무 영향이 없다. 두 서버 모두 사람마다 자기 계정으로 들어가 자기 앱만 다룬다.

"배포해 줘" 한 마디 안에서
스냅샷·확인·되돌리기가 돈다

운영 배포는 /release 스킬이 이끌고, 실제 작업은 서버의 배포 헬퍼(brie-prod-deploy)가 한다. 헬퍼는 정해진 순서를 매번 똑같이 밟고, 중간에 문제가 생기면 스스로 직전 상태로 돌아간다.

처음 한 번 — 운영 서버에 자리 만들기

운영 서버 접속 확인 → 코드 받기·설치 → brie-prod-init(DB·서비스·주소·인증서·등록을 한 번에, 실패하면 만든 것을 스스로 정리) → 운영 설정 파일 자동 생성 → 운영 관리자 계정 생성(비밀번호는 한 번만 보여 줌)

그다음부터 — 배포할 때마다

배포·정지·삭제는 모두 운영 서버의 기록(로그)에 누가·언제·무엇을 남긴다. 다음 쪽의 기록이 그것이다.

일부러 실패시킨 배포는
스스로 되돌아왔다

셀프 배포를 만들며 테스트 계정으로 시험한 운영 서버의 실제 배포 기록이다(가독성을 위해 칸만 맞췄다).

기록의 devtest·sergei 는 팀원 권한을 시험하는 테스트 계정이다 — 관리자가 아니어도 이 모든 것을 본인이 직접 했다는 뜻이다.

한 서버를 같이 써도
서로의 자원을 빼앗지 않는다

여러 사람이 각자 만든 앱이 한 운영 서버에 모인다. 한 앱이 문제를 일으켜도 다른 앱이 함께 쓰러지지 않게, 그리고 잊힌 앱이 자원을 계속 차지하지 않게 했다.

같은 서버를 써도
내 설정과 데이터는 나만 본다

여러 사람이 한 서버에서 일하면 실수로라도 남의 비밀번호·키·데이터를 볼 수 있으면 안 된다. standarda 의 서버는 사람마다 따로 들어가고, 할 수 있는 일을 검증된 명령으로만 제한하고, 비밀 파일은 주인만 읽게 한다.

확인을 묻는 대신,
되돌릴 수단을 남긴다

처음 하는 사람을 배포하게 만드는 것은 서버 지식이 아니다. "잘못돼도 되돌릴 수 있다"는 사실이다.

자리를 고르고, 주소를 열고,
사람을 들이는 명령

자리 만들기·배포·관리·정리,
네 개의 명령

아무도 신경 쓰지 않아도
서버가 스스로 챙기는 일

고친 사람만 알고,
다음 사람은 또 넘어진다

여러 사람이 각자 업무 자동화를 만들기 시작하면 같은 함정이 프로젝트마다 반복된다. 시행착오는 쌓이는데 지식은 쌓이지 않는다.

배운 것이 도는 고리 다섯 개

오류를 고친 순간부터 그 교훈이 다른 프로젝트의 출발점이 될 때까지, 각 단계를 맡는 장치가 있다. 사람이 기억해서 챙기지 않아도 고리가 돈다.

"엑셀을 AI 로 분석해 시트에 쓰는 기능"을 시작하자,
7개 프로젝트의 교훈 10개가 따라왔다

standarda 로 만든 새 프로젝트에서 실제 lesson-finder 에이전트(가장 가벼운 모델)에게 작업 하나를 주고 결과를 받았다. 걸린 시간 103초. 아래는 돌려준 10개를 한 줄씩 옮긴 것이다(원문은 교훈마다 "이번 작업에 적용할 방법"과 원문 경로가 함께 온다).

에이전트는 끝에 "보류한 후보 5개"와 "제목 훑기로 좁혔으므로 누락 가능성이 있다"까지 밝혔다. 처음 하는 사람은 이 10가지 중 대부분을 문제가 생긴 뒤에야 알았을 것이다.

한 프로젝트의 문제가
모든 프로젝트의 부품이 되기까지

리허설의 실수는 다음 날의 기본값이 되고,
빠진 개선은 다시 찾아 넣는다

④는 고리가 끊긴 사례다. 고리도 끊길 수 있다 — 그래서 끊긴 곳을 찾는 일(수집·정리·대조)까지 장치로 만들었다.

혼자 공부한 시간이
팀의 기본값이 된다

처음 하는 사람이 혼자 해낼 수 있는 이유는 그가 특별해서가 아니라, 앞 사람들의 시행착오를 갖고 시작하기 때문이다.

오류를 고치면
교훈이 갈 곳까지 정한다

비자명한 오류를 고치면 같은 커밋에 docs/issues/번호_제목.md 를 넣는다(빠지면 검사기가 막는다 — 벽 4). 형식은 정해져 있다.

wiki 는 관리자만 고친다. 팀원 프로젝트에서 2·3층이 나오면 이슈 문서에 "wiki 교훈 후보"로 남기고 관리자에게 알린다 — 관리자가 옮긴다.

교훈은 AI 가 찾을 수 있게
"언제 보면 되나"와 함께 남는다

합계 436개 · 출처 프로젝트 53개(가장 많은 곳 popax 45개)

교훈 파일 하나

색인 한 줄 → lesson-finder

교훈마다 색인(lessons/INDEX.md)에 분야 · 제목 · 적용 조건 · 출처 · 경로 한 줄이 붙는다. lesson-finder 는 가장 가벼운 모델로 돌며 ① 색인만 읽고 ② 공통 + 이번 작업 분야 행 중 적용 조건이 맞는 것만 골라 ③ 걸린 교훈의 본문만 열어 ④ "이번 작업에 적용할 방법"으로 바꿔 돌려준다. 색인은 늘, 본문은 걸린 것만 — 교훈이 늘어도 비용이 폭주하지 않는다.

그래서 색인 한 줄이 빠지면 그 교훈은 영영 안 찾힌다 — 이 장을 쓰며 11개를 찾아 정리 거리로 올렸다.

기본값으로 올라간 것은
기록과 함께 모든 프로젝트로 간다

올리기

기록하기 — 변경 기록 114건, 건마다 교육 포인트

출발점 93 · 공용 부품 20 · 서버 헬퍼 1. "무엇이 바뀌었나"뿐 아니라 "왜·무엇을 배웠나"를 남겨 리뷰와 교육 자료의 원천이 된다.

기존 프로젝트로 퍼뜨리기

남의 서버에서만 도는 체계는
우리 것이 되지 않는다

업체의 서버와 계정 위에서 만든 업무 자동화는 업체와의 관계가 끝나는 날 같이 멈춘다. 그렇다고 우리 서버에 옮겨 세우려면 또 다른 전문가가 필요하다.

코드는 하나, 값은 박스마다

회사마다 달라야 하는 것은 전부 박스마다 한 파일(/etc/brie/site.env)에 모았다. 출발점·개발 도구·서버 헬퍼는 모두 이 파일을 읽는다. 다른 회사에 세울 때 바꾸는 것은 이 파일뿐이다.

두 박스의 프로그램은 같다. 위 값만 다르다.

다른 회사의 dev·prod 서버를
하루 만에 같은 체계로 맞췄다

다웰은 자기 AWS 계정에 개발 서버와 운영 서버를 두고 standarda 로 일한다. 2026-08 첫 구축 때는 회사 값을 코드에 직접 바꿔 넣는 방식이었다. 10월에 값 파일이 생기자, Brie 와 같은 체계로 하루 만에 다시 맞췄다.

2026-11-14 다웰 개발 서버 실측. 오늘 기준 그 회사 조직의 출발점·공용 부품·개발 도구는 Brie 의 최신과 같은 버전이다.

"돌아간다"가 아니라
"같다"를 숫자로 확인했다

맞추기를 끝낸 뒤 Brie 와 다웰의 박스에서 같은 검사(brie-parity-check)를 돌려 나란히 비교했다(2026-10-27). 다른 줄은 하나씩 이유를 확인했다.

옮기면 빠지는 것 — 실제로 겪은 일

이 체계 자체도 2026-09 다른 회사의 인프라에서 Brie 의 AWS·도메인·GitHub 로 통째로 옮겨 왔다. 코드와 데이터는 다 왔는데, 옮긴 직후 DB 백업이 0개였다. 백업·자동 서버 이미지·권한 역할 같은 클라우드 쪽 자동화는 복사로 따라오지 않는다. 문서에는 백업 절차가 있어 "있다"고 착각하기 쉬웠다.

그래서 — 옮긴 뒤 "다시 만들어야 하는 것" 체크리스트와 같은지 검사가 절차에 들어갔다.

체계가 고객 소유가 되어야
고객이 스스로 한다

고객이 스스로 하려면 도구뿐 아니라 그 도구가 도는 자리까지 고객의 것이어야 한다.

회사가 바뀌면
이 20줄만 바뀐다

비밀값(키·비밀번호)은 넣지 않는다 — 누구나 알아도 되는 공개 정보만. 비밀은 관리자만 읽는 파일과 서버 권한 역할에 따로 둔다.

누가 읽나

고객 쪽은 15분마다 최신이 되고,
다른 점은 목록으로 드러난다

받아 오기 — brie-upstream-mirror

고객 서버의 관리자 예약 작업으로 15분마다 돈다. 상위 조직(Brie)의 출발점·공용 부품·개발 도구·인프라 안내서에서 기본 브랜치와 버전 태그만 고객 조직으로 옮긴다. 앞으로만 나아가고 덮어쓰지 않는다 — 고객 쪽이 갈라져 있으면 멈추고 알림 메일 한 통, 복구되면 한 통.

출발점 안의 모든 회사 값은 값 파일에서 오므로, 받아 온 코드를 고객 쪽에서 고칠 일이 없다 — 그래서 "그대로 옮기기"만으로 충분하다.

같은지 검사 — brie-parity-check

박스의 작동 방식을 항목=값 목록으로 뽑는다. 회사 이름·주소 같은 값은 빼고 "어떻게 도는가"만 남기므로, 같은 역할의 두 박스는 목록이 같아야 한다.

고객은 6가지만 하고,
나머지는 정해진 순서대로 간다

실제로 겪고 절차에 박아 둔 함정 (16개 중)

사람이 하는 말은 네 문장,
나머지는 장치가 한다

7개의 장치는 따로 도는 것이 아니라 한 흐름으로 이어진다. 업무 앱 하나가 생겨서 동료가 매일 쓰기까지, 사람이 하는 일과 시스템이 하는 일을 나란히 놓았다.

이미 돌고 있는 체계다

아래 숫자는 이 자료를 쓰며 실제 서버·저장소에서 다시 센 것이다(2026-11 기준). 자세한 근거는 각 장에 있다.

standarda 는 한 번에 설계된 것이 아니다. 실제 프로젝트에서 넘어진 자리마다 장치를 하나씩 세웠고, 그 기록이 이 자료의 근거다.