고객 FAQ와 내부 FAQ

고객 FAQ

1 지금 사용할 수 있는 기능은 어디까지인가요?

2026-10-30에 확인한 공개 배포본은 v0.11.0 프리릴리스입니다. 현재 프로젝트는 파일럿 단계이며 실제 기관 시험 운영이나 운영 승인이 완료된 상태는 아닙니다.

최신 공개 여부는 프로젝트 릴리스에서 확인할 수 있습니다. 가이드의 실행 명령은 고정된 공개 버전을 기준으로 합니다.

2 민원 처리용인가요? 누가 무엇을 만들 수 있나요?

목표는 다양한 공공 프로젝트에서 비개발자가 안전하게 바이브 코딩을 하도록 돕는 것입니다. 핵심 사용자는 업무를 이해하고 직접 도구를 만들려는 공공 업무 담당자입니다. 내부 업무 자동화, 자료 정리·보고, 현황 조회, 신청·접수 도구 등을 탐색할 수 있습니다. 이는 목표 사용 사례이며 현재 모두 지원한다는 뜻은 아닙니다. 민원 로깅은 첫 검증 사례입니다. 개발·보안 담당자는 환경과 기준을 준비하고 전문 검토와 운영 승인을 지원합니다.

3 하네스는 무슨 뜻인가요?

여러 개발 도구와 정책·점검·승인 절차를 연결해 함께 작동하게 하는 기반입니다. 비개발자가 AI와 도구를 만드는 과정에서 필요한 기준, 실행 범위, 검사와 수정·담당자 검토·기록이 함께 작동하도록 연결하는 것이 목표입니다. 현재 공개본이 자연어 제작 경험 전체를 제공하는 것은 아닙니다.

4 기존 보안 검사 도구나 업무 관리 도구와 어떤 관계인가요?

보안 검사 도구는 특정 문제를 탐지하고, 업무 관리 도구는 담당자와 진행 상태를 기록합니다. GovCode Harness가 지향하는 가치는 해당 검사가 왜 필요한지, 어느 변경을 검사했는지, 누가 검토했는지, 어떤 자료가 완료 근거인지를 연결하는 것입니다. 기존 도구와의 연결은 도구별 구현과 검증이 필요하며, 모든 제품과 바로 연결된다고 가정하지 않습니다.

5 우리 기관에 적용되는 규정을 자동으로 결정해 주나요?

기관에 적용할 기준은 담당자가 출처·버전·적용 조건을 확인해야 합니다. 프리뷰의 적용성 기능은 입력한 프로젝트 정보와 기준의 조건을 바탕으로 적용·제외·검토 필요를 구분합니다. 미확정 정보와 담당자 검토가 필요한 항목을 남기며, 법적 판단을 대신하지 않습니다. 적용 대상이 정해졌다는 것과 그 요구를 충족했다는 것도 다릅니다.

6 AI가 코드를 고치고 승인까지 하나요?

AI는 설명과 수정안을 제안하는 역할입니다. 담당자의 승인과 별도 검사가 필요합니다. 현재 공개 참조 흐름은 미리 준비한 AI 응답을 사용하며 실제 AI 추론 품질은 검증하지 않았습니다. 승인된 제안 수정의 격리 검사와 별도로 알려진 수정 코드의 통과를 확인합니다. 이를 실제 AI의 자동 수정·운영 배포 실적으로 해석해서는 안 됩니다.

7 검사에 통과하면 안전하다고 믿어도 되나요?

통과는 지정된 코드 변경과 검사 범위에서 확인한 결과입니다. 검사하지 못한 영역, 다른 변경, 전체 기관의 보안이나 법적 준수에 대한 보장이 아닙니다. 분석 오류·미지원·필수 검사 누락을 통과로 바꾸지 않고, 코드가 바뀌면 다시 검사하는 것이 기본 원칙입니다.

8 업무 중인 민원 서비스가 중단되나요?

검사 대상은 프로그램 코드와 관련 자료입니다. 기본 차단 대상은 검사에 실패한 변경의 병합·배포이며, 실제 CI 연결과 필수 검사 설정이 있어야 작동합니다. 접수 중인 민원 요청을 직접 차단하는 기능은 아닙니다. 현재 안내 사이트는 문서와 공개 자료를 제공하고 검사 서버를 운영하지 않습니다.

9 실제 민원 자료나 소스 코드를 외부에 보내야 하나요?

공개 체험은 개발 담당자의 컴퓨터에서 가상 자료로 진행할 수 있습니다. 현재 데모에 실제 민원 원문은 필요하지 않습니다. 실제 도입에서 외부 모델이나 서비스를 쓴다면 입력 자료, 반출 범위, 보관 정책을 기관이 별도로 정해야 합니다. 공개 이슈에는 개인정보·기관 내부 자료·원본 로그·토큰·개인 키를 올리지 않습니다.

10 비용과 이용 조건은 무엇인가요?

본 프로젝트 코드는 Apache-2.0 조건에 따라 라이선스 비용이나 로열티 없이 사용·수정·재배포할 수 있으며 상업적 이용도 가능합니다. 재배포 시 라이선스 사본, 관련 저작권·NOTICE, 수정 사실 표시 등 조건을 따라야 합니다. 설치·인프라·운영 비용은 별도이며 무보증 조건이 적용됩니다. 가이드·브로슈어는 CC BY 4.0, 선택적 오철칙 연동은 기존 MIT 표시를 유지합니다. 라이선스 안내에서 범위를 확인할 수 있습니다.

11 비개발자도 직접 프로그램을 만드는 것이 목표인가요?

그렇습니다. 사용자가 자연어로 요구를 설명하고 AI의 결과를 확인·수정하면서 직접 도구를 만드는 경험이 핵심 목표입니다. 가이드 열람이나 의견 제출은 지금 참여할 수 있는 경로입니다. 현재 공개 파일럿에는 이 전체 제작 경험이 없으며, 자연어 제작 화면·코딩 에이전트 연결·실행 권한과 쉬운 점검 설명은 후속 설계·구현이 필요합니다. 지금은 만들고 싶은 도구와 업무의 어려움을 제안하고 개발 담당자와 함께 첫 사례를 시험할 수 있습니다.

12 도입 기간이나 지원 수준은 어떻게 되나요?

정해진 도입 기간, 기관 운영 지원 약정, 응답 시간은 아직 없습니다. 실제 파일럿을 시작하려면 대상 업무, 지원 환경, 참여 담당자, 성공 기준, 중단 조건과 운영 책임을 먼저 정해야 합니다. 기능 요청과 코드·문서 기여는 기여 안내에 따라 제안할 수 있습니다.

내부 FAQ

1 우리가 해결하려는 가장 중요한 고객 문제는 무엇인가요?

업무를 아는 비개발자가 AI로 도구를 만들고 싶어도, 생성된 코드와 실행 결과의 위험을 판단하기 어렵다는 문제입니다. 핵심 가설은 프로젝트별 안전장치와 이해할 수 있는 안내가 제작 과정에 연결되면 비개발자가 직접 도구를 만들고 필요한 전문 검토를 요청할 수 있다는 것입니다. 개발팀의 검사·승인 효율은 이를 뒷받침하는 가치입니다. 고객 인터뷰와 실제 제작 관찰로 이 가설을 확인해야 합니다.

2 고객이 다른 일보다 이 문제를 먼저 해결할 이유가 있나요?

반복 업무를 직접 개선하려는 수요와, AI로 만든 도구를 신뢰하기 어려워 멈추는 상황이 함께 있어야 합니다. 인터뷰에서는 ‘어떤 기능이 필요한가’뿐 아니라 최근 직접 만들려다 중단한 도구, 판단하지 못했던 위험, 전문가에게 맡겨야 했던 단계를 확인합니다. 제작 수요가 없거나 기존 도구로 충분하다면 해당 업무를 첫 적용 대상으로 선택하지 않습니다.

3 무엇이 고객을 실망시킬 수 있나요?

비개발자용이라고 소개했지만 설치 명령·코드·정책 파일을 스스로 다뤄야 하는 경우, 이해할 수 없는 차단 메시지만 받는 경우, 단순 검사 통과를 운영 승인으로 오해하는 경우입니다. 비개발자가 다음 행동을 이해하고 제작을 계속할 수 있는지, 시험과 실제 운영의 차이를 구분하는지 검증해야 합니다. 설명을 쉽게 쓰는 것만으로 제작 과정의 사용성 문제가 해결되지는 않습니다.

4 첫 파일럿의 범위를 어디까지 잡을 예정인가요?

제품 파일럿의 단위는 ‘비개발자 한 명이 구체적인 공공 업무 도구를 설명→생성→시험→수정→검토 요청까지 만들어 보는 흐름’으로 제안합니다. 첫 업무와 사용할 자료는 아직 미정입니다. 민원 로깅은 하네스 기반의 기술 검증 사례로 활용하고, 제품의 대상 업무를 그 사례에 고정하지 않습니다. 프로필·규정 팩과 산출물·요구사항 추적은 이 제작 흐름을 지원하는 기반으로 연결합니다.

5 초기 출시에서 약속할 수 없는 것은 무엇인가요?

모든 법령과 개발 언어 지원, 법적 준수 인증, 기관 운영 승인, 실제 AI의 완전 자동 수정·배포, 모든 CI·신원 시스템과의 즉시 연결을 약속하지 않습니다. 초기 약속은 명시된 업무·코드·검사 범위 안에서 처리 과정과 완료 근거를 연결하는 것입니다. 지원 범위를 넓힐 때마다 독립된 정답 자료와 인수 기준이 필요합니다.

6 규정과 정책의 품질은 누가 책임지나요?

기준 묶음의 작성자, 독립 검토자, 기관 적용 판단자와 운영 책임자가 필요합니다. 출처·버전·시행 조건·변경 내역을 확인하고 예시 정책과 실제 적용 기준을 구분해야 합니다. 프로젝트 유지관리자가 모든 기관의 법적 적용성을 일괄 보증할 수는 없습니다. 출시 전에는 업데이트·검토·철회 책임과 오래된 기준의 처리 절차를 정해야 합니다.

7 어떤 근거가 있어야 고객 가치가 입증됐다고 말할 수 있나요?

아래는 파일럿 측정 계획안이며 달성 실적이나 확정 목표치가 아닙니다. 같은 작업 범위의 기존 방식과 파일럿 방식을 비교하고, 표본·업무 난이도·교육 시간을 함께 기록합니다. 수치 목표와 허용 오차는 파일럿 시작 전에 담당자와 합의합니다.

8 기존 시험 통과 수치는 무엇을 증명하나요?

공개 v0.11.0 배포 검증은 전체 739개 시험과 설치 패키지의 통합 확인 34개 통과를 보고합니다. 이전 v0.10.0의 439개 시험은 해당 버전의 과거 기록입니다. 시험 개수만으로 기관 도입 효과, 실제 코드 정확도, 전체 규정 충족이나 AI 품질을 입증할 수 없습니다. 정식 출시 판단에는 고객 업무에서의 사용성·검토 부담·안전성 근거가 추가로 필요합니다.

9 출시를 막는 실패 조건은 무엇인가요?

비개발자가 허용 범위를 이해하지 못한 채 민감한 자료나 실제 업무를 변경하게 되거나, 검사하지 못한 항목이 완료처럼 보이거나, 다른 코드 변경의 결과를 재사용하거나, 미확정 정보가 적용 제외로 처리되는 문제가 있으면 해당 범위의 출시를 중단해야 합니다. 민감 정보가 기록·공유 경로에 남는 경우도 원인을 해결하기 전 적용을 확대하지 않습니다. 고객이 결과를 설명받고도 다음 행동을 이해하지 못하거나 검토 부담이 기준선보다 늘어난다면 기능 확대보다 흐름을 다시 설계합니다. 이는 출시 판단 기준안이며 파일럿 인수 조건으로 구체화해야 합니다.

10 운영과 유지보수 비용은 어떻게 감당할 예정인가요?

사용자 라이선스 비용은 없습니다. 그러나 프로젝트 유지관리, 규정 팩 검토, 보안 패치, 문서와 지원, 기관별 연동에는 비용이 듭니다. 라이선스 정책과 유지보수 재원은 별도의 결정입니다. 기여 기반 운영, 자체 투자, 별도 지원 서비스 등의 선택지는 있으나 현재 확정된 수익 모델이나 지원 상품으로 공표하지 않습니다. 확대 전에 담당자와 운영 예산을 정해야 합니다.

11 가장 큰 기술적·사업적 위험은 무엇인가요?

기준의 적용 조건을 잘못 해석하는 것, 오래된 승인과 검증 결과를 신뢰하는 것, 규정 팩을 유지할 책임이 불명확한 것, 도입·검토 부담이 고객 가치보다 커지는 것이 핵심 위험입니다. 기술적으로는 버전 결합·독립 승인·미확정 상태 유지·재검사로 통제하고, 사업적으로는 좁은 업무 범위와 명확한 책임자로 시작해 실제 부담을 측정해야 합니다. 자동화 범위를 늘리는 속도보다 신뢰할 수 있는 범위를 설명하는 능력이 중요합니다.

12 다음 단계에 투자하기 전에 무엇을 결정해야 하나요?

아래 항목은 미확정 의사결정 목록입니다. 실제 기관, 담당자, 예산, 일정은 아직 정하지 않았습니다.

이 결정이 정리되면 PR의 각 고객 약속을 인수 조건으로 바꾸고, 그 약속을 충족하는 최소 범위부터 구현·검증합니다.

근거와 연결 문서

PR/FAQ 형식은 AWS의 미래 보도자료와 FAQ 작성 안내를 참고했습니다. 고객의 문제·경험을 먼저 쓰고, 세부 조건과 내부 의사결정은 FAQ에서 다룹니다.

현재 기능·라이선스·참여 경로는 본 프로젝트 README, 공개 릴리스, 기여 안내, 가이드의 업데이트 기록을 기준으로 정리했습니다. 공개 기능은 v0.11.0 태그의 실행 안내·문서 생성 안내·검증 기록을 대조한 2026-10-30 기준입니다.

이 문서의 제품 가설·파일럿 측정 계획·출시 판단 기준·책임 역할은 검토를 위한 제안입니다. 실제 고객 인터뷰, 도입 성과, 비용 절감 수치나 기관의 구매 의사로 인용하지 않습니다.