사회복지 바이브코딩 스타터팩

코드 템플릿이 아니라, 코드를 짜기 전에 필요한 정보와 판단 근거를 정리한 문서 모음입니다.
템플릿으로 복사하거나 플러그인으로 설치해 AI와 대화하면, 무엇을 어디에 어떻게 만들지 함께 정리할 수 있습니다.

최근 바뀐 것

• 1.2 기존 정보시스템과 기관 기록 맞추기: 에이전트 브라우저로 두 곳을 맞출 때의 판단 문서(starter/assess/screen-agent.md), 기존 정보시스템 자료의 반출 제한, 외부 알림(웹훅) 원칙
• 1.1 보호 기준과 사람의 결정: 민감정보와 아동 동의, AI 국외이전 동의, "결정은 사람이 하고 실행은 AI가 한다", 판단 기록 맨 앞의 기관 실천 원칙
• 1.0 세 가지 사용법: 템플릿, 플러그인, 채팅으로 쓰는 구조와 HWP 양식, AI 기능, 기관 공용 AI 에이전트 문서

이미 판정을 마친 앱은 그때의 기준으로 고정되므로, 판단 기록에 적힌 버전보다 뒤의 변경만 확인하면 됩니다. 버전마다 이미 만든 앱이 할 일은 CHANGELOG.md에 있습니다.

어떻게 시작하나

같은 문서를 쓰는 방법이 세 가지입니다. 쓰는 도구와 상황에 맞게 고르세요. 어느 방법이든 AI가 읽는 판단 기준은 같습니다.

자세한 방법은 아래 사용방법에 있습니다. /init은 실행하지 않습니다. 규칙 파일이 이미 갖춰져 있어서 /init이 만들어 주는 내용은 필요하지 않습니다.

왜 만들었나

저는 사회복지 현장에서 오랫동안 스마트워크와 DX 컨설팅을 해 왔고, 2023년 GPT-4가 나온 뒤부터는 직접 바이브코딩으로 도구를 만들어 왔습니다. 이 저장소에는 그 시간 동안 기관들과 함께 부딪치며 얻은 노하우와 관점을 담았습니다.

지금까지 우리는 내 손에 맞지도 않는 프로그램을 억지로 쓰고, 데이터가 흩어져 스스로 신뢰를 깎아먹으며, 불필요한 반복 행정에 소중한 시간과 에너지를 쏟아왔습니다. 정부가 의무 사용을 요구하는 프로그램은 업데이트도 안 되고, 업체가 만들어 주는 건 비싸다는 핑계 뒤에서 현장의 비효율과 무력감을 감내해 왔습니다.

제 생각에 바이브코딩은 그 자리를 되찾는 일입니다. 우리가 겪는 고통을 해결할 도구를 스스로 고르고, 그 도구를 운영할 규칙과 데이터 보호 장치를 동료들과 함께 정하고, 불편하면 내일 당장 함께 고쳐 쓰는 것. 실무자가 내 손에 맞는 도구를 직접 만드는 현장 자율성과 도구 주권의 회복입니다.

그런데 실제로 해 보면 걸림돌은 코딩 실력이 아닙니다. 오히려 GAS로 갈지 Cloudflare로 갈지, 개인정보는 어디에 저장해야 안전한지, 국외이전 동의는 받아야 하는지, 내가 그만두면 이 앱은 누가 맡는지. 코드는 AI가 짜 주지만 이런 선택은 사람 몫으로 남습니다. 선택지를 모르다 보니 시행착오를 필요 이상으로 반복합니다.

처음 바이브코딩이 알려졌을 때는 모두 신기해하며 이것저것 스스로 만들어 보는 시기가 있었습니다. 하지만 혼자 시험해 보는 앱과 동료와 이용자가 실제로 쓰는 앱은 정말 다릅니다. 실제로 쓰는 앱에는 실제 사람의 정보가 쌓이고, 우리는 건강, 장애, 상담 내용 같은 민감정보를 다룹니다. 그래서 다른 분야보다 더 엄격해야 하는데, 현장에서는 아직 그만큼 민감하게 여기지 않는 것 같습니다.

그럴 만한 이유도 있습니다. 저는 구글 워크스페이스를 직접 쓰는 데 그치지 않고 전국을 다니며 강의했고, 많은 현장이 실제로 도입했습니다. 워크스페이스 안에서는 로그인과 권한 관리, 접속 기록과 감사 로그, 백업을 구글이 알아서 해 주기 때문에 우리는 그런 일이 있는지도 모르고 지냈습니다. 바이브코딩으로 그 업무 도구 밖으로 나가면 이 일을 이제 스스로 챙겨야 합니다. 우리 현장의 실천가들은 이런 일을 해 본 경험이 거의 없습니다. 그래서 좋은 뜻으로 만든 앱이 결과적으로 이용자의 정보를 드러내거나 권리를 침해하는 일이 생기기도 하고, 저는 그 점이 매우 걱정됩니다. 어떤 플랫폼을 고르든 기관이 직접 챙겨야 하는 일은 요건 매트릭스에 정리했습니다.

워크스페이스에서 배운 것이 하나 더 있습니다. 도구는 일하는 방식을 바꿉니다. 2011년 제가 일하던 복지관은 구글앱스를 들였습니다. 전 직원이 회의자료를 동시에 실시간으로 쓰기 시작했습니다. 그러자 다른 팀의 현안이 따로 설명하지 않아도 공유되었습니다. 회의 문화도 그 도구에 맞춰 바뀌었습니다. 조직문화는 바꾸기 어렵다고들 합니다. 그런데 도구 하나가 그 일을 했습니다. 도구에는 그것을 만든 사람들의 일하는 방식이 담겨 있기 때문입니다.

우리가 만드는 앱도 똑같습니다. 누가 몇 번 빠뜨렸는지 세는 앱은 서로를 지켜보는 문화를 만들기 쉽습니다. "대상자 관리"라는 메뉴를 날마다 누르면 사람을 대하는 태도도 그 말을 닮아 갑니다. 이제는 우리가 만드는 앱에 어떤 방식을 담을지 우리가 정합니다. 그래서 앱을 어떤 철학으로 설계하는지가 중요합니다. 판단 기록(DECISION.md) 맨 앞에 기관의 실천 원칙을 적게 한 것도 이 때문입니다.

이 저장소는 이런 판단의 문턱을 낮추려고 만들었습니다. 개발을 몰라도 됩니다. 기관에서 바이브코딩으로 앱을 만들고자 할 때 판단에 필요한 것을 문서로 정리했습니다. 다 이해하지 못해도 됩니다. 그저 AI에게 그대로 전달하면 됩니다.

앱을 만드는 것 자체가 목적이 아닙니다. 반복 행정을 줄여 당사자를 만날 시간을 되찾는 것이 목적입니다. 그래서 앱을 만들거나 자동화하기 전에 스스로에게 질문해야 합니다. 이 절차는 법령이나 지침에서 요구하는 일인가, 아니면 우리 기관의 관행일 뿐이라 없애도 되는 일인가? 없애고, 줄이고, 남는 것만 앱으로 만들면 좋겠습니다.

이를 위해 우리가 하는 일이 무엇인지 철저하게 규명하고 객관적으로 분석해야 합니다. 흔히 SOP를 작성한다고 하는데, 많은 기관은 이 과정 없이 앱을 만들기 시작합니다. 그래서 실제 SOP를 작성하고 그 과정에서 데이터베이스를 설계하는 절차를 넣었습니다.

제가 요즘 가장 크게 느끼는 것은 우리 현장에 최초 기록을 참조하는 구조가 없다는 것입니다. 프로그램 접수는 전화와 종이로 받아 엑셀에 적고, 출석은 인쇄한 출석부에 강사가 표시하고, 담당자가 합계만 엑셀로 옮기고, 팀과 기관이 취합해 시군구에 내고, 그것이 다시 위로 올라갑니다. 단계마다 사람이 옮겨 적고, 중간에 한 번 틀리면 그 이후 작업을 전부 다시 합니다.

모든 결과물이 최초 기록을 바라보고 있는데, 정작 최초 기록을 참조하는 것이 아니라 사본을 다시 사본으로 만드는 구조입니다. 저는 디지털 전환이 종이를 화면으로 바꾸는 일이 아니라, 최초 기록이 생기는 순간 제대로 수집하고 그 뒤의 모든 작업이 그것을 참조하게 만드는 일이라고 생각합니다. 엑셀에 옮겨 적는 것은 디지털이 아니라 옮겨 적기입니다. 이것이 되어야 비로소 디지털 전환이 시작되고, AI 전환도 그 위에서만 가능합니다. 사람이 꼭 할 일을 먼저 정하고, 나머지 가운데 AI에 맡길 일을 고르고, AI가 한 일은 사람이 확인하고 되돌릴 수 있어야 합니다. ssot.md와 ai.md는 그 출발점을 만드는 방법입니다.

기관 밖의 시스템과도 같은 문제가 있습니다. 시설은 인사, 회계, 후원, 보고, 서비스 이력을 정부가 운영하는 정보시스템에 입력하고, 기관 앱과 시트에도 같은 내용을 적습니다. 두 곳을 잇는 통로가 없으니 단일 원본의 원칙을 어길 수밖에 없고, 두 곳을 손으로 맞추다 보면 불편하고 누락이 생깁니다. 그래서 요즘은 Aside 같은 에이전트 브라우저에게 이 동기화를 맡기려는 분들이 늘고 있습니다. 저는 이 흐름을 막기보다 안전하게 쓰는 법을 함께 정하는 것이 맞다고 생각합니다. 기관 기록을 원본으로 두고, 처음에는 대조만 시키고, 로그인과 저장·제출은 사람이 하는 순서를 screen-agent.md에 정리했습니다.

그런데 막상 기관에서 하려고 하면, 생각보다 저항이 심합니다. 당장 일이 많아지는 것 같기도 하고, 기존에 하던 방식이 마치 잘못된 것처럼 느껴지도록 메시지를 잘못 전하기도 하는 것 같습니다. 저는 사회복지 현장이 ‘문제를 문제라고 정의하는 것’ 자체를 터부시하고, 그 일에 익숙하지 않기 때문은 아닐까 생각합니다.

사회복지에서는 강점관점이 굉장히 중요합니다. 그런데 이런 관점에 익숙해지다 보니, 조직의 업무나 시스템을 볼 때도 ‘문제’라는 말을 너무 조심하게 되는 경우가 있는 것 같습니다.

“그래도 잘하고 있는 부분이 있는데”, “현장에서는 다 사정이 있는데”, “문제라고 표현하기는 조금 그렇고…” 하다 보면 정작 무엇을 바꿔야 하는지가 흐려지기도 하고요.

그런데 DX·AX나 업무개선을 하려면 결국 지금 무엇이 불편한지, 어디에서 오류나 누락이 생기는지, 왜 같은 일이 반복되는지를 집요하고, 또 아프도록 명확하게 정의해야 합니다. 문제를 선명하게 정의하지 못하면 AI를 붙이든 시스템을 만들든 결국 어렵습니다.

중요한 건, 사람을 문제로 보는 것과 시스템의 문제를 찾는 것이 전혀 다르다는 점입니다.

예를 들어
“담당자가 자꾸 누락한다”라고 하면 개인의 문제가 되지만,
“현재 업무가 담당자의 기억과 경험에 의존하고 있고 누락을 막아주는 절차가 없다”라고 보면 시스템의 문제가 됩니다.

후자의 방식이 오히려 사람을 탓하지 않으면서도 조직을 바꿀 수 있는 접근이 아닐까 싶습니다.

그래서 사람에게는 강점관점, 시스템에는 문제해결관점으로 구분하면 좋을 것 같아요.
당사자나 직원을 문제로 규정하지는 않되, 당사자와 직원이 불편을 겪게 만드는 절차와 구조의 문제는 오히려 더 정확하게 찾아야 하지 않을까 싶습니다.

그리고 한 걸음 더 나아간다면, 조직 안에서 만들 수 있는지 묻기 전에 만들어도 되는지 물어보면 좋겠습니다. 만들 수 있다고 해서 근태를 정확히, 그리고 편리하게 관리하고자 지문등록 출근앱을 만들어도 된다는 뜻은 아닙니다. 목적이 옳다고 모든 수단이 정당해지는 것은 아니니까요.

앱을 만들기 전에 따져 볼 다섯 가지 질문을 ethics.md에 모았습니다. 어떤 위험과 부담이 있는지 알고 결정하기 위한 것입니다.

모든 문서는 개발 지식이 없는 독자를 기준으로 썼고, 낯선 용어는 glossary.md에 풀어 두었습니다. AI도 이 저장소를 바탕으로 코딩할 때 용어를 설명하며 작업하도록 했습니다. 도움이 되시길 바랍니다.

사용방법

세 방법 모두 처음부터 요구사항을 완벽하게 정리하지 않아도 됩니다. 만들고 싶은 앱의 목적과 지금 업무 방식을 설명하면 AI가 workflow.md의 판단 기준으로 그 업무가 꼭 필요한지 확인하고, 이미 알 수 있는 내용은 추론하며 필요한 정보만 물어본 뒤 적합한 경로를 함께 정리합니다. 판정(업무 점검, 데이터 등급, 동의 판단)은 Opus 같은 상위 모델로, 가능하면 이 저장소를 연 에이전트형 도구에서 하세요. 세 사례로 비교해 보니 차이를 만든 것은 지시를 따르는 정도가 아니라 다른 문서에 있는 사실을 찾아 읽는지, 모르는 것을 지어내지 않는지였습니다. 가벼운 모델은 등급을 잘못 매기거나 법 근거와 기관의 결정을 지어낸 경우가 있었으므로, 가벼운 모델로 판정했다면 P·S등급 앱의 DECISION.md는 상위 모델에게 한 번 더 확인받으세요. 운영하고 있는 앱에 반영하는 일과 DB를 바꾸는 일의 확인 규칙은 어느 모델을 쓰든 끄지 마세요.

"우리 기관 프로그램일지 앱을 만들려고 해. 사진도 회기당 2~3장 올라가."

처음 써 본다면 진짜 앱보다 먼저 개인정보가 없는 작은 앱을 하나 만들어 보세요. 안내 페이지, 계산기, 물품 재고, 익명 만족도 집계 같은 N등급 앱은 판정이 몇 분에 끝나고, 안내 페이지나 계산기처럼 저장하지 않는 앱은 서버도 필요 없습니다. 도구가 어떻게 움직이는지 익힌 뒤 진짜 앱의 판정으로 들어가면 질문이 길어도 흐름을 놓치지 않습니다.

템플릿으로 시작하기: 앱마다 새 저장소를 만든다

1. 이 페이지 위쪽의 Use this template 버튼을 누르고 앱 이름으로 저장소를 만듭니다. 문서만 복사되고 이 저장소의 이력은 따라오지 않습니다.
2. 만든 저장소를 컴퓨터로 클론하고, 그 폴더 안에서 Claude Code나 Codex를 실행합니다. Claude Code는 CLAUDE.md를, Codex는 AGENTS.md를 자동으로 읽고 나머지 문서로 이어집니다.
3. 판정이 끝나면 AI가 판단 결과를 DECISION.md에 남기고, 선택한 개발 규칙을 CLAUDE.md와 AGENTS.md에 연결합니다. 앱은 같은 저장소의 app/ 같은 폴더에서 만듭니다. starter/와 ops/는 판단 근거와 운영 자료이므로 지우지 않습니다. 이 README는 starter/templates/APP-README.md를 바탕으로 앱 소개로 바뀌고, 스타터 안내는 원본 저장소 링크로 남습니다. 운영하고 있는 앱(실제 직원과 이용자가 쓰는 앱)에 반영하거나 운영 DB를 바꿀 때는 AI가 바뀌는 내용과 되돌릴 방법을 먼저 보고하고 실행 허락을 묻습니다. 보고를 읽고 허락하는 것이 사람의 결정입니다.
4. 다음 앱도 템플릿 버튼을 다시 눌러 새 저장소에서 시작합니다. 한 저장소에 앱을 두 개 만들지 않습니다. 앱을 자주 만든다면 아래 플러그인 방식이 편합니다.

플러그인으로 시작하기: 한 번 설치하고 어느 폴더에서나 쓴다

이미 앱 폴더가 있거나 여러 앱을 만들 계획이라면 이 저장소를 플러그인으로 설치합니다. 한 번 설치하면 어느 폴더에서 시작해도 "복지관 앱을 만들고 싶어" 같은 말에 판단 절차가 자동으로 시작됩니다. 저절로 시작되지 않으면 "사회복지 앱 판단 절차로 시작해 줘"라고 요청합니다. 스킬은 두 개입니다. 앱 아이디어에서 시작하는 판정 절차와, HWP 양식 파일에서 시작하는 양식→앱 절차(form-to-app.md)입니다.

Claude Code에서는 두 줄입니다.

/plugin marketplace add YW-Rainbow/welfare-vibecoding-starter
/plugin install welfare-vibecoding-starter@welfare-vibecoding-starter

Codex에서는 터미널에서 마켓플레이스를 추가한 뒤 플러그인 화면에서 설치합니다.

codex plugin marketplace add YW-Rainbow/welfare-vibecoding-starter
codex /plugins

판정이 끝나면 AI가 starter/, ops/, AGENTS.md, CLAUDE.md를 앱 폴더로 복사해 템플릿으로 만든 저장소와 같은 구조로 만들고, DECISION.md를 채운 뒤 선택한 규칙을 연결합니다. 이미 있던 앱 코드는 옮기지 않고 그대로 둡니다. 앱마다 채우는 것은 handover.md와 destruction-log.md입니다. 동의서와 처리방침 파일은 참고 양식이므로 앱마다 고쳐 쓰지 않고, 기관이 실제로 쓰는 동의서와 처리방침은 기관에 하나만 두고 그 위치를 DECISION.md에 적습니다. 판단 근거가 앱 폴더에 남아 후임자가 읽을 수 있습니다. 다음 앱은 새 폴더에서 시작합니다.

채팅만 쓴다면

Claude나 ChatGPT의 일반 채팅은 저장소 주소를 주어도 README 한 페이지만 요약해서 읽고, CLAUDE.md 같은 규칙 파일은 아예 읽지 않습니다. 그래서 링크가 아니라 본문을 붙여야 합니다. chat-prompt.md를 열어 내용 전체를 복사해 첫 메시지로 붙이고, 이어서 만들고 싶은 앱을 설명하세요. 이 파일에는 판단 절차 본문이 그대로 들어 있습니다. 판정 뒤 실제 개발로 넘어갈 때는 위의 템플릿 방식을 권합니다.

양식 전체를 정리하고 싶다면

앱 하나가 아니라 기관의 양식과 업무 전체를 정리하고 싶다면 form-audit.md에서 시작하세요. 양식을 하나씩 보면 모두 필요한 것처럼 보이기 때문에, 기관에서 사용하는 양식을 한곳에 모아 같은 기준으로 살펴봐야 합니다. 양식마다 근거가 무엇인지, 실제로 누가 읽는지, 법정서식인지, 같은 데이터를 반복해 적고 집계하는지를 차례로 확인하면 없앨 양식, 그대로 둘 양식, 앱으로 만들 양식을 구분할 수 있습니다. 불필요한 양식을 없애거나 합치는 것이 첫 번째 성과이고, 앱으로 전환하기로 한 양식만 workflow.md의 판정 절차로 넘어갑니다.

앱을 여러 개 만들 계획이거나 담당자마다 별도의 파일로 이용자 정보를 관리하고 있다면 ssot.md를 먼저 확인하세요. 이용자 명부 하나를 원본으로 정하지 않은 채 앱만 늘리면 같은 어르신이 파일마다 서로 다른 이름으로 기록되고, 나중에는 담당자가 자료를 일일이 대조해야 합니다. 이용자는 명부에서만 등록하고, 각 앱의 기록은 이용자 이름이 아니라 이용자 ID로 연결하는 것이 핵심입니다.

기본 흐름

없애거나 줄일 업무 찾기
        ↓
사람과 조직에 미칠 영향 확인
        ↓
원본 데이터와 기록 기준 정하기
        ↓
사용자·출력·보호·운영 요건 정하기
        ↓
플랫폼과 개발 규칙 선택
        ↓
같은 저장소의 app/ 폴더에서 개발
        ↓
스테이징에서 확인하고 운영하고 있는 앱에 반영(사람이 결정하고 AI가 실행)

저장소 구성

루트에는 AI 도구가 읽는 규칙 파일과 여러분이 만들 파일만 두고, 스타터의 참고 자료는 starter/ 폴더에 모았습니다. 템플릿으로 복사한 뒤에는 starter/는 읽기만 하고, 나머지는 앱에 맞게 채우고 만듭니다.

함께 보면 좋은 자료

현장에서 이미 만들어 쓰고 있는 도구와 앱, 그리고 이 저장소의 바탕이 된 글입니다. 이 저장소는 아래 분들의 작업에 기대어 만들어졌습니다. 감사드립니다. 자료마다 자세한 소개와 이 저장소의 어느 문서와 이어지는지는 resources.md에 적었습니다.

스타터 템플릿

• apps-script-vibe-starter: 신용우. 경로 C(GAS+시트)용. clasp 설정과 에이전트 규칙이 갖춰져 있습니다. 별도 저장소로 클론하지 않고 내용을 앱 저장소의 app/에 복사해 시작합니다.

만들 때 쓰는 도구

• urimal-for-socialworker: 김종원. 계획서와 보고서를 자연스러운 우리말로 다듬는 Claude Code 스킬
• EASYREAD: 최중호. 복잡한 한국어를 쉬운 정보(Easy-Read)로 바꾸는 MCP 서버
• rhwp: Edward Kim(edwardkim). 브라우저에서 HWP를 읽고 누름틀을 채워 저장하는 오픈소스 엔진. MCP로 AI가 HWP 양식을 직접 읽고, 크롬 확장으로 HWP를 브라우저에서 바로 엽니다
• rhwp-studio: 김종원. Google Drive의 HWP를 열어 편집하고 저장하는 웹 편집기

현장에서 만든 앱

• vehicle-drive-log: 김종원. 여러 기관이 함께 쓰는 차량 운행일지 웹앱, 실제 운영 중
• Family-tree: 김종원. 서버 없이 브라우저에서만 동작하는 대화형 가계도(Genogram) 웹앱
• SW_EDMS: 최중호. 기록 무결성을 보강한 전자결재 학습용 샘플

이 저장소의 절차로 만든 앱

• 아직 없습니다. 이 절차로 앱을 만들었다면 기여 안내를 보고 알려 주세요. 판단 기록(DECISION.md)과 함께 여기에 연결합니다.

읽을거리

• 사회복지사가 바이브 코딩까지 해요: 전재일. 온라인 책
• 모두를 위한 스마트워크: 신용우. 데이터 설계 방법론과 온톨로지 연재, levels.md 4단계의 바탕
• 기록에서 데이터로, 데이터에서 삶으로: 김진래. 흩어진 기록을 원장 하나로 모은 뒤 AI를 연계한 2년의 실천 보고. ai.md의 바탕
• AI 시대, 사회복지 현장이 바꿀 것, 버릴 것, 지킬 것: 신용우. 칼럼(한국사회복지사협회 카드뉴스)과 실천지혜 연작. ai.md의 바탕
• 사회복지 현장 AI·바이브코딩 안전사용 가이드: 신용우. 기관용 AI 사용 가이드라인·동의서·처리방침 제작 매뉴얼. ops/의 동의서 양식과 같은 기준
• vibecoding-pub의 사용자 권한 프로토콜: 이경태. 사용자를 목적과 범위를 정하는 결정권자로 보는 관점. agentic.md의 바탕
• AI는 만들고, 리더는 판단한다: 정수홍. 사회복지시설의 DX·AX를 이끄는 리더십. 없앨 업무를 결정하고 책임의 경계를 정하는 기관장의 몫

알아둘 것

이 저장소의 문서는 법률 자문이 아닌 실무 참고 자료입니다. 판정 절차는 2026년 9월에 지금 구조로 정리되었고, 이 절차로 끝까지 만든 앱 사례는 아직 모으는 중입니다. 민감정보를 다루는 시스템은 도입하기 전에 개인정보 전문가의 검토를 받으세요. 플랫폼의 가격, 한도, 리전, AI 사업자 계약 정보는 각 문서 머리말의 기준일(2026년 8~9월)을 따르며 이후 달라질 수 있습니다. 문서에는 CC BY 4.0을, 코드와 코드 예시에는 MIT 라이선스를 적용합니다. 자세한 범위는 LICENSE.md를 확인하세요.