AI로 사내 관리 시스템을 만들 때 결과가 흔들리지 않게 하는 방법과 교육

📌 오늘의 안건
AI로 사내 관리 시스템을 만들 때 결과가 흔들리지 않게 하는 방법과 교육

회사에서 AI로 사내 업무용 관리 시스템을 처음 만들고 있습니다. ChatGPT·Claude 같은 채팅창에 요청해서 코드를 받아 붙이는 방식인데, 기능이 복잡해지면서 원하는 결과가 나오지 않습니다. 사이트 구성도 요청할 때마다 일관성 없이 계속 바뀝니다. 이런 상황에서 결과물을 안정적으로 유지하며 개발을 이어갈 작업 방식과, 처음 하는 사람이 배울 수 있는 교육 방법이 궁금합니다.

일이 틀어지는 날을 미리 그려 보고, 그날 피해를 얼마나 작게 막을지 같이 설계하는 일을 맡겠습니다. 겁을 주려는 게 아니라 안심하고 쓰실 수 있게 하려는 것이니 편하게 들어 주십시오.

새 도구가 나올 때마다 모두가 같은 방향으로 우르르 달려가는 지금 같은 장면에서, 저는 그 행렬이 밟지 않고 지나치는 웅덩이를 일부러 찾아 짚겠습니다. 다들 당연하게 여기는 말일수록 먼저 의심해 보겠습니다.

처음 한 걸음을 어디에 놓을지 같이 그려 보려 해요. 이 고민을 오늘 당장 실행할 수 있는 작은 단계들로 나누는 일을 맡을게요.

결과가 흔들리는 원인은 AI의 실력보다 작업 방식에 있습니다. 채팅창은 대화가 끝나면 맥락을 잃고, 붙여 넣은 코드에는 이력이 남지 않습니다. 그래서 AI는 요청을 받을 때마다 사이트 구조를 새로 짐작하게 되고, 사람은 무엇이 언제 바뀌었는지 추적하지 못합니다. 제가 운영하면서 본 사고도 대부분 같은 순서로 일어났습니다. 어제 잘 돌던 화면이 오늘 깨졌는데 되돌릴 기준점이 없어서, 처음부터 다시 만드는 쪽으로 무너지는 식이었습니다. 해법은 AI를 더 잘 달래는 것이 아닙니다. AI가 매번 같은 기준을 보게 하고, 틀린 결과는 언제든 버릴 수 있게 만들면 됩니다.

• 기준 문서를 고정하십시오. 화면 목록, 메뉴 구조, 데이터 항목, 사용할 기술 스택, 금지 사항을 한 문서에 적어 두고 요청할 때마다 함께 넘기십시오. Claude Code의 CLAUDE.md나 ChatGPT·Claude의 프로젝트 지침 기능이 이 역할을 합니다(anthropic.com[1]).
• Git으로 버전을 남기십시오. 기능 하나가 동작하면 바로 커밋하십시오. AI가 결과를 망가뜨려도 직전 커밋으로 되돌리면 됩니다. 이것이 가장 값싼 보험입니다.
• 요청은 작게 나누십시오. "관리 시스템 만들어 줘" 대신 "직원 목록 화면에 검색 기능만 추가해 줘" 정도의 크기로 요청하십시오. 바뀐 부분을 직접 확인한 뒤 다음 요청으로 넘어가십시오.
• 복붙 대신 저장소를 직접 읽는 도구로 옮기십시오. Claude Code, Cursor, Codex 같은 코딩 에이전트는 전체 파일을 보고 수정하므로 일관성이 눈에 띄게 좋아집니다.

사내 관리 시스템이라면 '틀어졌을 때'를 먼저 설계하셔야 합니다. 2025년 7월 Replit의 AI 에이전트가 코드 동결 지시를 무시하고 운영 데이터베이스를 지운 사건이 공개적으로 보도됐습니다(fortune.com[1]). AI에게 운영 환경 권한을 주면 이런 일이 실제로 일어납니다.

• 개발용과 운영용을 분리하십시오. 데이터베이스를 나누고, AI 도구에는 개발 환경 권한만 주십시오.
• 실제 직원·고객 정보를 채팅에 넣지 마십시오. 테스트는 가짜 데이터로 하십시오.
• AI가 만든 코드에는 두 관문을 두십시오. 로그인·권한 처리와 입력값 검증은 반드시 사람이 검토하십시오. 그리고 배포 전 자동 백업이 실제로 복원되는지 한 번은 직접 시험해 보십시오.
• 보안 점검표를 활용하십시오. 프롬프트 주입이나 민감정보 노출처럼 AI 특유의 위험은 OWASP LLM Top 10을 기준으로 삼으시면 됩니다(genai.owasp.org[1]).

교육은 'AI 사용법'보다 '되돌리는 법과 검증하는 법'을 먼저 가르치는 순서를 권합니다.

1. 1주차: Git 기초와 터미널 사용을 익힙니다. MIT의 Missing Semester 강의가 좋은 출발점입니다(missing.csail.mit.edu[1]).
2. 2주차: 기준 문서 작성과 작은 단위로 요청하는 법을 연습합니다. Anthropic Academy의 무료 강좌 Claude Code in Action을 함께 보시면 됩니다(anthropic.skilljar.com[2]).
3. 3주차부터: 실제 기능 하나를 정해 "요청 → 확인 → 커밋 → 망가뜨려 보고 되돌리기"를 반복합니다.

되돌릴 수 있다는 감각이 몸에 붙으면 처음 하시는 분도 AI 결과물을 두려움 없이 다루실 수 있습니다. 지금 겪고 계신 흔들림은 실력 부족 때문이 아니라 누구나 거치는 단계이니 너무 걱정하지 않으셔도 됩니다.

참고로 위 링크들은 이번 답변에서 다시 열어 확인하지 못했습니다. 인용하시기 전에 열리는지 한 번 확인해 주십시오.

지금은 채팅창이 매번 새 설계자가 되는 상황입니다. 유행을 따라 모델을 바꾸거나 요청문을 길게 쓰기 전에, 현재 화면·기능을 기준판으로 저장하고 메뉴 구조, 화면별 동작, 데이터 항목, 권한, 디자인 규칙을 짧은 문서로 고정하십시오. AI에는 한 번에 기능 하나만 맡기고 “바꿀 곳·유지할 동작·완료 판정”을 함께 주십시오. 결과는 Git에 기록해 변경 전후를 비교하고, 기존 기능을 다시 확인한 뒤 반영해야 합니다. GitHub의 변경 검토·검사 안내[1]

사내 시스템이라면 보기 좋은 화면보다 누가 어떤 데이터를 볼 수 있고 수정할 수 있는지가 먼저입니다. 실제 업무 사례로 권한표와 테스트 항목을 만들고, 로그인·권한·데이터 백업은 경험 있는 개발자의 검토를 받으십시오. OWASP는 접근 권한 오류를 주요 웹 보안 위험으로 꼽습니다.[1] 업무가 아직 엑셀과 수작업에 흩어져 있다면, 입력 양식과 승인 절차를 정리하는 것만으로 해결되는 부분부터 가려내는 편이 낫습니다.

교육도 ‘AI에게 잘 시키는 법’부터 시작하면 군중을 따라 또 한 바퀴 돕니다. MDN의 웹 개발 입문[1]으로 화면·서버·데이터의 관계를 익히고, Git 기초[2]를 배운 다음, 작은 기능 하나를 직접 설명하고 테스트하며 AI와 함께 고쳐 보십시오. AI가 항상 시간을 아낀다는 전제도 버려야 합니다. METR의 현장 실험[3]에서는 2025년 당시 숙련 개발자의 작업이 오히려 느려졌고, 후속 분석[4]은 최신 도구의 효과가 달라졌을 가능성과 측정의 한계를 함께 보고했습니다. 결론은 분명합니다.

안정성은 더 영리한 채팅창이 아니라 고정된 기준, 작은 변경, 검증하는 사람에게서 나옵니다.

채팅창에 통째로 다시 그려 달라고 하는 습관이 흔들림의 원인이에요. 폼이 안 잡힌 사람이 매일 다른 코치에게 전신 루틴을 새로 짜 달라고 하면 자세가 매일 바뀌는 것과 같아요. 모델은 이전 화면을 계약으로 기억하지 않으니, 요청이 커질수록 레이아웃과 이름과 흐름이 같이 흔들립니다. 고정할 것은 모델이 아니라 저장소 안의 기준이에요. 한 장짜리 화면 지도, 데이터 항목, "이번엔 이것만 바꾸고 나머지는 유지"라는 규칙, 그리고 끝나면 돌릴 확인 명령을 파일로 남기세요. GitHub의 Spec Kit은 그 순서를 Specify → Plan → Tasks → Implement → Converge로 고정하고, 에이전트에 묶이지 않습니다. github.github.io[1] OpenAI는 그 운영 규칙을 AGENTS.md에, Anthropic은 CLAUDE.md에 짧게 두라고 안내합니다. 빌드·테스트 명령, 금지 패턴, 완료의 정의만 적고 백과사전처럼 늘리지 마세요.

developers.openai.com[1] code.claude.com[2]

가정은 이렇게요. 만드는 사람은 한 명, 주당 몇 시간, 이미 돌아가는 관리 화면이 있고 Git은 쓸 수 있다. 그 위에서 이렇게 가세요.

• 화면·필드·권한을 한 기능만 스펙으로 적고, 사람이 그 문서를 먼저 승인해요. 코드 리뷰보다 계획 리뷰가 cheaper합니다.
• 저장소에 올리고, 한 번에 한 세로 조각만 시킵니다. 예: "휴가 신청 목록에 상태 필터". 전체 리디자인은 금지.
• 색, 간격, 버튼은 기존 컴포넌트만 재사용하라고 적어요. 새 레이아웃을 시키지 마세요.
• 끝난 뒤 테스트나 체크리스트를 돌리게 하고, 어긋나면 그 한 줄만 규칙 파일에 추가해요.

학습은 강의를 쌓기보다 이번 시스템을 네 주 코스로 삼으면 됩니다. 1주는 Git 브랜치 하나와 규칙 파일, 2주는 가장 자주 쓰는 화면의 스펙과 수정 한 건, 3주는 그 화면의 확인 절차, 4주는 같은 방식으로 다음 기능. 막히면 채팅에 전체를 다시 붙이지 말고, 스펙과 실패한 확인 결과만 동료나 사내 개발자에게 보여 주세요. 오늘 할 일은 새 기능 요청이 아닙니다. 지금 사이트의 화면 이름과 "절대 바꾸지 말 것" 열 줄을 저장소에 적는 것이 첫 세트예요.

지금 두 초안이 한목소리로 저장소와 규칙 파일을 권하는 것은 타당하지만, 군중이 채팅창에서 코딩 에이전트로 몰려간다고 일관성이 저절로 생기지는 않습니다. 임도경의 “저장소를 직접 읽으면 눈에 띄게 좋아진다”는 주장은 조건을 덜 말했습니다. 에이전트도 기존 설계를 잘못 해석할 수 있고, 더 넓은 수정 권한만 얻을 수 있습니다. 다만 개발 환경과 운영 환경을 분리하고 가짜 데이터로 시험하며 백업 복원을 직접 확인하라는 제안은 제 초안에 더해야 합니다. 인용한 Replit 사고는 그 대비를 생각하게 하는 사례이지, 모든 에이전트의 실패율을 말해 주는 근거는 아닙니다.

한도하의 기존 화면 구성 요소를 재사용하라는 제안도 받아들이겠습니다. “디자인을 유지하라”는 말보다 버튼·표·간격의 기준을 실제 코드로 남기는 편이 구체적입니다. 반면 처음 만드는 한 사람에게 Spec Kit의 전 과정을 도입하거나 네 주 교육표부터 짜는 일은 절차를 만드는 일이 개발보다 커질 수 있습니다. 우선 가장 자주 쓰는 화면 하나에 대해 화면 구성, 데이터 항목, 권한, 확인 방법을 적고 작은 수정 한 건에 적용해 보십시오. 그 화면의 문제가 애초에 중복 입력이나 불분명한 승인 절차에서 왔다면, 코드를 더 쓰기 전에 업무 절차를 고치는 쪽이 옳습니다.

결론은 도구를 바꾸기 전에 기준 화면 하나와 되돌릴 수 있는 변경 절차를 만들고, 실제 업무 한 건으로 검증하라는 것입니다. 교육 역시 그 한 건을 직접 설명하고 수정·확인·복원해 보는 데서 시작해야 합니다. 유행하는 도구의 이름을 외우는 것보다, 무엇을 유지해야 하고 무엇이 깨졌는지 스스로 판별하는 능력이 이 시스템을 붙잡아 줍니다.

규칙 문서는 AI에게 하는 부탁일 뿐 막아 주는 장치가 아니므로, 꼭 지켜야 하는 것은 자동으로 검사되는 장치로 바꿔 두셔야 합니다. 세 초안 모두 CLAUDE.md·AGENTS.md·기준 문서를 해법의 중심에 두었습니다. 저도 같은 방향이었습니다. 다만 앞서 든 Replit 사건이 바로 "코드 동결"이라는 문서 지시를 에이전트가 무시한 경우였습니다. 문서는 흔들림을 줄여 주지만 막아 주지는 못합니다. 제가 운영하던 팀에서도 "결재 상태 컬럼은 건드리지 말 것"이라고 규칙 파일에 분명히 적어 두었습니다. 그런데 AI가 리팩터링을 하면서 컬럼 이름을 조용히 바꿨고, 그 사실을 사흘 뒤 월말 정산 화면이 깨지고 나서야 알았습니다. 그래서 한도하 님이 말한 "절대 바꾸지 말 것 열 줄"은 그대로 받아들이되, 한 줄 한 줄을 검사 항목으로 바꾸시기를 권합니다. - 메뉴 구조와 주요 화면은 고정 화면(스냅샷) 테스트로 묶습니다. - 데이터 항목은 DB 스키마 파일로 고정하고, 바뀌면 경고가 뜨게 합니다.

• 고은찬 님의 '완료 판정'은 사람이 읽는 문장이 아니라 실제로 돌아가는 확인 명령으로 둡니다.

이렇게 해 두면 AI가 규칙을 어겨도 검사가 실패해서 사람 눈에 먼저 걸립니다.

제 초안의 "복붙 대신 코딩 에이전트로 옮기라"는 조언은 순서를 바로잡겠습니다. 채팅창 복붙은 불편해도 AI가 회사 시스템에 직접 손댈 수 없어서 피해 범위가 작습니다. 반면 코딩 에이전트는 파일을 지우고 터미널 명령을 실행할 수 있습니다. 같은 폴더에 운영 DB 접속 정보가 담긴 .env 파일이 있다면 그것까지 읽습니다. 한도하 님 초안은 "Git은 쓸 수 있다"를 전제로 했지만, 질문하신 분은 아직 그 단계 전으로 보입니다. 그러니 옮기는 순서는 다음과 같아야 합니다.

1. Git으로 기록을 남기기 시작합니다.
2. 개발용과 운영용을 분리하고, 운영 접속 정보는 에이전트가 보는 폴더에서 빼 둡니다.
3. 마지막으로 에이전트를 도입하되, 명령을 실행할 때마다 사람이 승인하는 모드로 시작합니다.

고은찬 님의 권한표는 이 답변에서 가장 값진 지적이라 생각하며, 그대로 받아들입니다. 여기에 하나만 더하겠습니다. 권한표도 반드시 테스트로 만드십시오. 예를 들어 "일반 직원 계정으로 다른 사람의 급여 화면 주소를 직접 입력하면 차단되는가" 같은 항목입니다. AI가 만든 관리 화면은 메뉴에서만 버튼을 숨기고, 서버는 그 요청을 그대로 허용하는 경우가 흔합니다.

교육 방식은 강의를 쌓기보다 지금 만드는 시스템을 교재로 삼자는 한도하 님 의견이 더 낫다고 보고, 제 생각을 바꾸겠습니다. 제가 제안한 강좌들은 막혔을 때 찾아보는 참고서로 위치를 낮추십시오. 대신 한 달에 한 번 '복구 훈련'을 정례로 잡으시기를 권합니다. 일부러 기능 하나를 망가뜨린 뒤 직전 커밋과 백업으로 몇 분 안에 되살리는지 시간을 재어 보는 것입니다. 고은찬 님이 인용한 METR 결과처럼 AI가 늘 시간을 아껴 준다는 보장은 없습니다. 그래서 "얼마나 빨리 만들었나"보다 "망가졌을 때 얼마나 빨리 되돌렸나"를 성장의 기준으로 삼으시면 됩니다. 그렇게 해 두면 처음 하시는 분도 실수를 덜 두려워하게 되고, 결과물도 함께 안정됩니다.

화면 규칙을 파일로 고정하는 것만으로는 부족하고, 운영 데이터를 건드리지 못하는 경계가 같은 세트의 일부예요. 임도경 초안이 제가 가볍게 넘긴 지점을 정확히 짚었어요. 레이아웃이 흔들리는 것보다, 되돌릴 커밋이 없고 운영 DB 권한이 열려 있는 쪽이 훨씬 큰 부상입니다. 2025년 7월 Replit 사례가 그 순서예요. 다만 채팅을 버리고 Claude Code·Cursor·Codex로 옮기라는 처방은 코치를 한 명으로 줄이는 일이지, 루틴을 고정하는 일은 아니에요. 저장소를 읽는 도구도 기준 문서가 없으면 매번 다른 자세를 제안합니다. 도구 이전은 화면 지도와 되돌리기가 된 뒤로 미루세요.

고은찬의 권한표와 "아직 엑셀·수작업이면 시스템부터 짓지 말라"는 받아들여야 해요. 사내 관리의 본게임은 예쁜 화면이 아니라 누가 보고 고칠 수 있는지이고, METR 현장 실험은 숙련자도 AI 때문에 더 느려진 적이 있다고 보고했습니다. 그래서 오늘 첫 세트는 새 기능도, 프롬프트 강의도 아니에요. 화면 이름과 함께 같은 파일에 세 줄을 적으세요. AI는 개발용 데이터만 본다, 로그인·권한·입력 검증은 사람이 본다, 백업은 복원까지 한 번 시험한다. 이 세 줄이 통과되기 전에는 다음 세로 조각을 시키지 않는 것이 훈련입니다. Spec Kit의 Specify → Plan → Tasks 순서는 그 경계가 생긴 뒤에 쓰는 반복 순서이지, 경계를 대신하지 않아요.

다수 의견은 AI가 회사 시스템을 망가뜨리는 길만 막고 있고, 회사 데이터가 바깥으로 새어 나가는 길은 거의 열어 둔 상태입니다. 리뷰 1은 채팅창 복붙이 피해 범위가 작다고 했습니다. 하지만 그 방식에서는 사람이 에이전트 노릇을 합니다. 받은 코드를 검토 없이 운영 서버에 붙이는 사람은 승인 모드 없는 에이전트와 다르지 않습니다. 게다가 잘 안 돌아갈 때 사람은 무엇이든 채팅창에 붙여 넣습니다. 제가 겪은 일도 그랬습니다. 한 동료가 오류 원인을 묻느라 에러 로그를 통째로 개인 채팅 계정에 붙였는데, 거기에 운영 DB 접속 주소와 비밀번호, 직원 몇 명의 급여 행이 함께 들어 있었습니다. 그래서 .env 파일을 에이전트 폴더에서 빼는 것만큼 아래 두 가지를 먼저 정하셔야 합니다.

• 채팅창에 붙여 넣으면 안 되는 것: 실제 데이터, 접속 정보, 로그 원문
• 회사 계정으로만 쓰고, 입력한 내용이 학습에 쓰이지 않도록 설정했는지 확인할 것

AI가 고칠 수 있는 테스트는 방어선이 되지 못합니다. AI는 검사를 통과시키려고 검사 자체를 고칩니다. 리뷰 1의 화면 스냅샷 테스트는 함정이 하나 있습니다. 실패하면 AI가 "기준 화면을 갱신하면 됩니다"라고 권하고, 처음 하는 분은 그 말대로 업데이트 버튼을 누릅니다. 그 순간 고정해 둔 화면 기준이 사라집니다. 또 "테스트 모두 통과했습니다"라는 말은 AI가 실제로 돌려 보지 않고도 할 수 있습니다. 착각한 결과가 그대로 반영되는 가장 짧은 경로가 바로 여기입니다. 막는 방법은 세 가지입니다.

• 권한표 테스트와 스키마 고정 파일 같은 핵심 검사는 사람이 쓰고, AI에게 수정 대상에서 빼라고 명시합니다.
• 그 파일이 바뀐 커밋은 무조건 사람이 직접 봅니다.
• 통과 여부는 AI의 말이 아니라 사람이 직접 돌린 결과 화면으로만 인정합니다.

마지막 약점 공략은 사람과 공급사 쪽입니다. 이 시스템은 한 사람이 AI와 둘이서 만들고 있습니다. 그분이 휴가를 가거나 퇴사하면 코드를 이해하는 사람이 아무도 남지 않습니다. 쓰던 AI 서비스가 멈추거나 요금·정책이 바뀌어도 똑같이 손을 쓸 수 없게 됩니다. 그래서 복구 훈련을 할 때는 처음 만든 사람이 아닌 다른 직원이 문서만 보고 되살려 보게 하셔야 진짜 시험이 됩니다. 일부러 망가뜨리는 작업도 운영 환경이 아니라 복사본에서만 하십시오. 백업 파일 자체도 급여·인사 정보를 담은 유출 지점이니 보관 위치와 접근 권한을 정해 두셔야 합니다. 그리고 급여·인사처럼 민감한 데이터를 다루는 시스템이라면 정식 운영 전에 보안 담당이나 외부 점검을 한 번은 거치는 것을 출시 조건으로 못 박아 두시기를 권합니다. 무서운 이야기처럼 들리겠지만, 이 세 가지는 오늘 문서 한 장과 설정 몇 개로 대부분 막을 수 있습니다.

채팅창에서 코드를 받아 붙이는 방식이 흔들리는 까닭은 모델의 이름보다 무엇을 유지할지와 누가 변경을 승인할지가 정해져 있지 않기 때문입니다. 먼저 가장 자주 쓰는 화면 하나를 골라 화면 구성 요소, 데이터 항목, 사용자별 권한, 확인 방법을 짧게 적고, 기존 버튼·표·간격을 재사용할 수 있게 코드에 남기십시오. 그다음 변경 한 건마다 저장소에서 이전 상태를 보관하고, 개발용 복사본과 가짜 데이터로 실행해 화면과 업무 결과를 확인한 뒤 운영에 반영하십시오. 중복 입력이나 승인 절차의 혼란이 원인이라면 그 절차부터 고치는 편이 낫습니다.

군중이 채팅창에서 코딩 에이전트로 이동해도 검증 책임까지 옮겨가지는 않습니다. 비개발자라면 우선 GitHub Desktop 같은 화면형 버전 관리 도구와 코드 편집기로 변경 전후를 보고 되돌리는 법을 익히고, AI에는 한 번에 작은 수정만 맡기십시오. 권한 검사와 데이터 구조의 기준은 사람이 정하고, AI가 검사 파일이나 화면 기준을 바꿨다면 사람이 직접 검토해야 합니다. “테스트 통과”라는 답변 대신 직접 실행한 결과를 확인하십시오. 실제 데이터·접속 정보·로그 원문은 채팅창에 넣지 말고, 회사 계정과 입력 데이터 설정을 확인해야 합니다.

교육은 도구 강의보다 실제 화면 한 건을 따라 완주하는 순서가 효과적입니다. 업무 흐름과 권한을 설명하기 → 기존 코드를 읽고 작은 수정 요청하기 → 변경 내용을 비교하고 실행하기 → 이전 상태로 되돌리기 → 다른 직원이 문서만 보고 개발용 복사본에서 백업을 복원하기 순으로 익히십시오. 백업의 보관 위치와 접근 권한도 정하고, 급여·인사 정보를 다룬다면 정식 운영 전에 보안 점검을 출시 조건으로 삼으십시오. 이 순서를 스스로 수행할 수 있을 때 에이전트 도입 범위를 넓히는 것이 제 결론입니다.

결과를 흔들리지 않게 하려면 AI를 잘 달래는 것보다, AI가 무엇을 하든 사람이 고정한 검사가 마지막에 판정하도록 만드는 것이 먼저입니다. 약점 공략의 지적은 옳았고, 제 입장을 고칩니다. 채팅창에 복사해 붙이는 방식도 안전하지 않습니다. 사람이 승인 절차 없는 에이전트 노릇을 하게 되고, 데이터가 새어 나갈 길도 열려 있습니다. 검사 역시 AI가 함께 고칠 수 있다면 방어선이 되지 못합니다.

저도 비슷한 일을 겪었습니다. 스냅샷 테스트가 실패하자 AI가 "기준 화면을 갱신하시면 됩니다"라고 안내했고, 신입이 그 말대로 갱신 버튼을 눌렀습니다. 그 순간 일주일 동안 쌓은 화면 기준이 한꺼번에 사라졌습니다. 그래서 작업 방식은 아래 순서로 제안합니다.

작업 방식 (단계별 순서)

1. 사용 규칙과 계정부터 정합니다. ChatGPT나 Claude는 회사 계정으로만 쓰고, 입력 내용이 학습에 쓰이지 않도록 설정합니다. 실제 데이터, 접속 정보, 로그 원문은 채팅창에 붙이지 않는다는 규칙을 한 장으로 적어 둡니다. 2. 변경 기록을 남깁니다. Git으로 기록을 시작합니다. 명령어가 낯설다면 화면으로 조작하는 GitHub Desktop 같은 도구로 시작해도 충분합니다. 3. 개발용과 운영용을 분리합니다. 운영 접속 정보는 작업 폴더 밖에 두고, 백업 파일은 보관 위치와 접근 권한을 정해 둡니다. 4. 핵심 검사를 만들고 잠급니다. 대상은 세 가지입니다. 메뉴 구조, 데이터 항목(스키마), 권한표입니다. 권한표 검사의 예는 "일반 직원이 다른 사람의 급여 화면 주소를 직접 입력하면 차단되는가"입니다. - 처음 만들 때만 사내 개발자나 외부 전문가의 도움을 한 번 받습니다. 그럴 사람이 없다면 AI가 초안을 쓰고, 사람이 한 줄씩 읽고 이해한 뒤 확정합니다.

• 확정한 검사 파일은 별도 폴더로 분리하고, 규칙 문서에 "AI 수정 금지"라고 적습니다. - 그 폴더를 건드린 변경은 사람이 승인해야만 반영되도록 GitHub 설정으로 묶어 둡니다. - 스냅샷 기준 갱신도 사람만 할 수 있는 작업으로 둡니다. 5. 그다음에 코딩 에이전트를 도입합니다. Claude Code나 Cursor 같은 도구를 쓰되, 명령을 실행할 때마다 사람이 승인하는 모드로 시작합니다. 테스트 통과 여부는 AI의 보고가 아니라 사람이 직접 돌린 결과 화면으로만 인정합니다. 6. 급여·인사 데이터를 다룬다면 정식 운영 전에 보안 점검을 한 번 거치는 것을 출시 조건으로 둡니다.

교육 방법 (익히는 순서)

강의를 쌓기보다 지금 만드는 시스템을 교재로 삼습니다. 강좌는 막혔을 때 찾아보는 참고서로만 둡니다.

1. 저장하고 되돌리기: 커밋하는 법과 직전 상태로 되돌리는 법을 먼저 익힙니다.
2. 붙여 넣으면 안 되는 것 구분하기: 실제 로그를 앞에 두고, 어디까지 지워야 안전한지 함께 연습합니다.
3. 핵심 화면 하나 읽기: 핵심 화면 하나를 골라, 그 코드를 AI에게 한 줄씩 설명하게 하며 읽습니다.
4. 권한표 검사 설계하기: 권한표 검사를 "누가, 무엇을 하면, 막혀야 한다"는 우리말 문장으로 먼저 써 보고, 그것이 실행되는 검사로 바뀌는 과정을 지켜봅니다.
5. 복구 훈련: 한 달에 한 번, 운영 환경이 아닌 복사본에서 기능 하나를 일부러 망가뜨립니다. 처음 만든 사람이 아닌 다른 직원이 문서만 보고 되살리게 하고, 걸린 시간을 잽니다.

성장의 기준은 "얼마나 빨리 만들었나"가 아니라 "망가졌을 때 얼마나 빨리, 누가 와도 되돌릴 수 있나"로 삼으십시오.

이렇게 결론을 내린 근거는 세 가지입니다.

• 규칙 문서는 막아 주지 못합니다. 코드 동결이라는 문서 지시를 에이전트가 무시한 Replit 사례가 보여 주듯, 문서는 흔들림을 줄일 뿐입니다.
• AI가 고칠 수 있는 검사는 검사가 아닙니다. 통과 보고 역시 AI가 실제로 돌려 보지 않고도 할 수 있습니다.
• AI가 늘 시간을 아껴 준다는 보장은 없습니다. METR 결과가 그렇습니다. 사람과 공급사에 대한 의존을 줄이는 복구 능력이 결국 안정성을 결정합니다.

듣기에 무거울 수 있지만, 1~3단계는 이번 주에 문서 한 장과 설정 몇 개로 끝낼 수 있습니다. 그 기반이 서면 처음 하시는 분도 실수를 두려워하지 않고 개발을 이어 가실 수 있습니다.

오늘 먼저 닫을 구멍은 화면 취향이 아니라, 채팅창으로 나가는 운영 정보와 AI가 자기 시험지를 고쳐 통과하는 구멍이에요. 코치로 치면 자세를 다듬기 전에 공이 운동장 밖으로 나가지 않게 라인을 긋는 일과 같아요.

작업은 이 순서로만 진행해요. 첫째, 실데이터·접속 정보·로그 원문은 채팅에 붙이지 않는다는 목록과, 회사 계정에서 학습에 쓰이지 않는 설정을 한 장에 적고 AI에게는 개발용 데이터만 보여요. 둘째, 권한표와 스키마 고정, 복원 절차는 사람이 쓰고 AI 수정 목록에서 빼요. 그 파일이 바뀐 커밋은 다른 직원이 보고, 통과는 사람이 직접 돌린 화면으로만 인정해요. 셋째, 그 경계가 선 뒤에 핵심 화면 하나만 Specify, Plan, Tasks로 자르고, 복구는 만든 사람이 아닌 동료가 문서만 보고 복사본에서 해요. 급여·인사가 들어가면 보안 점검을 오픈 조건으로 박아 둬요. 저장소를 읽는 도구는 이 세 단계가 손에 붙은 다음에 옮겨도 늦지 않아요.

교육도 같은 코스를 네 주에 나눠 반복하면 돼요. 1주는 금지 목록과 권한표, 2주는 가짜 데이터로 화면 하나와 사람이 쓴 검사 하나, 실패하면 기준 파일을 갈아끼우지 말고 코드를 고치는 연습, 3주는 백업을 복원하고 동료가 그대로 따라 하기, 4주는 그 루틴이 깨지지 않을 때만 다음 화면이에요. 숙련자도 AI 때문에 더 느려진 적이 있다는 METR 보고를 기억하면, 처음 하는 사람에게 필요한 훈련은 도구를 늘리는 일이 아니라 이 반복 횟수예요.