광진사회적경제네트워크의 AX준비과정 사례 07 — 사이트를 만드는 공장을 만들었다

사이트 하나를 만들고 나면 완성된 화면만 남는 것은 아닙니다. 자료를 요청하는 순서, 숫자가 어긋났을 때 확인하는 방법, 문의가 담당자에게 도착했는지 살피는 기준도 함께 남습니다. 그 경험을 다음 조직에서 다시 쓸 수 있다면 작업의 결과는 사이트 한 개보다 넓어집니다.

앞선 여섯 글에서는 광사넷 디지털허브에 바라는 것, 현황 진단, 우선순위, 자료 수집과 기획, 디자인 시스템을 차례로 살펴봤습니다. 이번 글은 그 작업들을 하나로 묶습니다. 현장의 경험을 반복 가능한 절차로 정리하는 시도, 우리가 ‘사이트 팩토리’라고 부르는 방식입니다.

같은 모양을 찍어내기 위한 공장은 아닙니다

공장이라는 말은 정해진 모양을 대량으로 만드는 장면을 떠올리게 합니다. 그러나 여기서 공통으로 만들려는 것은 조직의 얼굴이 아니라 작업의 바탕입니다. 자료를 어디서 받고, 누가 확인하고, 무엇을 승인한 뒤 공개할지를 다음 작업에서도 빠뜨리지 않으려는 것입니다.

원칙은 ‘기반은 공통으로, 화면은 조직에 맞게’입니다. 콘텐츠 구조와 공개 규칙, 문의 접수와 접근성 점검 같은 뼈대는 재사용하되 실제로 적용할 범위는 조직마다 정합니다. 첫 화면의 구성과 색, 글꼴, 문구와 대표 요소는 조직의 이야기에서 다시 출발합니다.

공통 기반이라고 해서 모든 기능을 모든 조직에 넣지는 않습니다. 외부 소식 자동 수집이 필요 없는 조직도 있고, 문의보다 참여 신청이 중요한 조직도 있습니다. 재사용의 기준은 복사하기 쉬운가보다 같은 실수를 줄이고 필요한 차이를 살릴 수 있는가에 있습니다.

절차와 조직의 값은 나누어 둡니다

다른 협동조합 사이트를 만들 때도 도움이 되는 절차라면 공통 영역의 후보입니다. 조직 이름과 색상, 명부와 개별 기록처럼 값이 달라지는 것은 조직별 영역에서 관리합니다. 공개 사이트에는 승인된 공개 정보만 반영하고, 개인정보·비밀번호·내부 기록은 공통 템플릿이나 공개 코드에 섞지 않습니다.

이 구분은 폴더 정리만의 문제가 아닙니다. 한 조직의 정보가 다음 조직의 시안에 남지 않게 하고, 점검 기준을 고쳤을 때 어느 프로젝트에 적용할지 판단하는 바탕입니다.

사전조사부터 운영까지 열 단계로 봅니다

제공된 팩토리 초안은 S0부터 S9까지 열 단계로 흐름을 정리합니다. 아래 표에서 앞선 글과의 관계는 실제 게시 내용을 기준으로 다시 연결했습니다. 연재는 각 단계를 모두 수행했다는 완료 보고가 아니라, 그 단계에서 필요한 판단을 설명한 기록입니다.

크게 보면 발견, 정의, 설계, 제작, 적용, 학습의 흐름입니다. 실제 작업은 앞 단계로 돌아가기도 합니다. 자료를 정리하다 새 문제가 나오면 진단과 범위를 다시 보고, 제작 중 새 요청이 생기면 영향을 확인한 뒤 합의를 갱신합니다. 순서의 목적은 되돌아가지 않는 데 있지 않습니다. 무엇이 확인된 상태에서 다음 일을 하는지 알 수 있게 하는 데 있습니다.

완료 기준과 승인 지점을 따로 둡니다

작업자가 파일을 만들었다고 그 단계가 끝난 것은 아닙니다. 자료의 기준일이 확인됐는지, 문의가 실제로 도착했는지처럼 완료를 판단할 증거가 있어야 합니다. 초안에서는 특히 범위, 공개할 데이터, 메인 시안, 마지막 인수검수의 네 지점에서 조직의 확인을 받도록 설계했습니다.

네 번의 승인만 있으면 모든 문제가 해결된다는 뜻은 아닙니다. 조직의 의사결정 구조에 따라 확인할 사람이 더 필요할 수 있습니다. 중요한 것은 만드는 사람의 판단과 운영 조직의 결정을 구분하고, 승인 뒤 달라진 요청도 기록하는 일입니다.

스킬은 판단을 대신하는 도구가 아닙니다

팩토리의 스킬은 각 단계에서 무엇을 어떤 순서로 하고 무엇을 남겨야 하는지 적어 둔 작업 지침입니다. 전체 흐름을 관리하는 파이프라인은 현재 단계와 산출물, 남은 확인을 살피고 필요한 지침을 연결하는 역할을 맡습니다.

자료 목록이나 문서 초안, 반복 점검은 도구가 도울 수 있습니다. 조직의 목적, 공개 범위, 예외 처리, 결과의 수용 여부는 사람이 판단해야 합니다. AI가 초안을 만들었다면 근거와 표현을 검토하는 담당이 필요하고, 도구가 실제로 실행하는 작업에는 그 범위에 맞는 권한과 확인 절차가 필요합니다.

원문 지침을 이번 게시에서 직접 확인하지 않았으므로 스킬의 정확한 개수나 버전을 이 글의 핵심 근거로 삼지는 않습니다. 지침이 많다는 것보다 현장에서 사용할 수 있고 결과를 확인할 수 있는지가 중요합니다.

막힌 곳을 고친 뒤에는 기준에도 남깁니다

제공된 초안은 광사넷 작업 중 모바일 메뉴와 링크 공유 미리보기, 공개 전 표시, 검색 준비에서 발견한 문제를 공통 절차에 반영하는 과정을 설명합니다. 변경 기록 원문을 이번 글에서 대조하지 않았으므로 개별 수정의 날짜나 완료 여부 대신, 그 경험을 어떻게 다음 기준으로 옮길지 살펴봅니다.

기술적인 해결법 하나를 모든 상황의 정답으로 남기지 않는 것도 중요합니다. 공유 이미지를 새 이름으로 올리는 것은 캐시 문제에 대응하는 한 방법이지만, 메타정보가 틀렸거나 접근이 막혔다면 그 원인부터 확인해야 합니다. 검색 제한 역시 내부 자료의 보안을 대신하지 않습니다. 비공개 자료는 별도의 접근 통제로 보호해야 합니다.

1. 현장에서 발견합니다어떤 조건에서 막혔는지 기록합니다.
2. 원인을 확인하고 고칩니다수정 결과와 적용 범위를 검증합니다.
3. 공통 기준으로 분리합니다조직별 값은 빼고 지침·서식에 반영합니다.
4. 다음 현장에서 다시 봅니다같은 조건에 유효한지 점검합니다.

이 순환이 있다고 같은 문제가 다시는 생기지 않는다고 약속할 수는 없습니다. 다만 누군가의 기억에만 남기지 않고 점검할 항목으로 바꿀 수 있습니다. 공장은 완성된 정답집보다 배운 것을 잃어버리지 않게 하는 체계에 가깝습니다.

짧게 갈 수 있어도 확인까지 생략하지는 않습니다

이미 진단 자료와 시안이 있는 조직이라면 사전조사 전체를 새로 할 필요는 없을 수 있습니다. 자료를 다시 쓰되 현재에도 맞는지 확인하고 비어 있는 부분을 보완합니다. 담당자가 조직 내부를 잘 안다는 이유만으로 이용자의 관점을 생략하지 않도록 실제 사용자의 의견이나 관찰도 남기는 편이 좋습니다.

개선 전의 시간과 건수 같은 기준값도 챙겨야 합니다. 앞선 글들에서는 실제 측정값이 없어 절감 성과를 말하지 않았습니다. 팩토리가 기준값 기록을 요구한다는 원칙과 모든 시범에서 이미 측정했다는 사실은 다릅니다. 빠뜨린 값은 빠뜨렸다고 적고 이후 측정 계획을 세워야 합니다.

승인 역시 어떤 역할로 누가 확인했는지 구분해야 합니다. 같은 사람이 여러 역할을 맡는 작은 조직에서는 이해관계와 검토 범위를 밝히고, 필요한 다른 결정권자나 이용자의 확인을 보완할 수 있습니다. 형식적인 승인 표시보다 실제로 무엇을 검토했는지가 중요합니다.

개통 다음에도 남는 절차를 만들려 합니다

사이트가 열린 뒤에는 담당자 교육과 운영 안내, 콘텐츠 갱신과 오류 대응이 이어집니다. 업무 하나를 골라 AI 활용을 시험하고, 기록을 보고 계속할지 판단하며, 운영 방식에 정착시키는 과정도 붙을 수 있습니다. 이번 글에서는 확정하지 않은 상품이나 가격을 소개하지 않습니다.

다른 조직에서 이 방식을 참고한다면 세 가지만 남겨도 좋겠습니다. 다음 단계로 갈 때 필요한 근거를 정하고, 공통 절차와 조직의 값을 나누고, 만들다 발견한 문제를 점검표로 되돌리는 것입니다. 작업이 끝날 때 화면과 함께 그 화면을 유지할 방법도 남아 있어야 합니다.

일곱 편의 글은 홈페이지의 바람을 묻는 데서 시작해 그 경험을 다른 현장에서도 쓸 수 있게 정리하는 데까지 왔습니다. 반복 가능한 품질은 모든 조직에 같은 화면을 주는 데서 생기지 않습니다. 조직마다 달라야 할 것을 존중하면서, 빠뜨리지 말아야 할 확인을 꾸준히 지키는 데서 만들어집니다.

작성 근거와 범위

제공된 사이트 팩토리 초안을 바탕으로 편집했습니다. 초안이 명시한 저장소 README·파이프라인 스킬·변경 기록·재사용 판단 문서·git 이력 원문은 이번 게시에서 직접 대조하지 않았습니다. 정확한 스킬 수·최초 기록일·개선판 수·시범 완료 여부는 확정 사실로 싣지 않았습니다. 열 단계와 네 승인 지점은 초안이 제시한 방법론을 설명한 것이며, 모든 단계의 실제 수행과 성과를 검증한 보고서는 아닙니다.