보안을 약하게 하지 않고 Go 서버에 모듈 추가하기

## 안전한 기본 설정을 지키고 새 기능을 둘 위치 정하기 인터넷에 노출되는 서버 플랫폼에서는 안전한 기본값을 가장 중요한 제품 요구 사항으로 취급하십시오. 기능을 코어에 강하게 결합하지 말고 조합 가능한 모듈로 설계하십시오. 단일 배포만을 위한 패치보다 한 부류의 사용 사례에 적용되는 범용 확장을 우선하십시오. 변경 사항이 최상위 애플리케이션, 재사용 가능한 모듈, 구성 적응 처리 또는 명령줄 진입점 중 어디에 속하는지 식별하십시오. 독립적으로 개발된 구성 요소가 충돌하지 않도록 모듈 식별자에 네임스페이스를 유지하십시오. 사람이 사용하기 편한 어댑터를 제공하더라도 기본 구조화 구성 모델을 유지하십시오. 요청 처리, 전송 보안, 신원, 인증서 관리, 신뢰 경계를 특히 엄격하게 검토하십시오. 소유권이 분산되어 있다면 관련 저장소나 패키지 전체에서 보안에 민감한 동작을 추적하십시오. 영향받는 신뢰 경계와 실패 모드를 이해하기 전에는 보안에 중요한 변경을 병합 준비 완료로 취급하지 마십시오. 배포되는 구성 요소를 검색하고 감사할 수 있도록 표준 모듈 레지스트리를 명시적으로 유지하십시오. 명령 바이너리가 우연한 등록에 의존하지 않고 의도한 모듈 집합을 가져오는지 확인하십시오. 새 기능을 합리적으로 둘 수 있는 계층이 둘 이상이라면 아키텍처상 위치를 문서화하십시오. 구현 노력을 줄이기 위해서만 안전한 기본값을 약화하는 설계는 거부하십시오. 첫 설계 결정부터 지원되는 모든 운영 체제와의 호환성을 고려하십시오. ## 오류·이름·주석을 Go의 일반적인 방식으로 쓰기 오류에는 조기 반환을 사용하고 성공 경로를 가장 낮은 들여쓰기 수준으로 유지하십시오. 이미 반환하는 분기 뒤에는 else 분기를 사용하지 마십시오. URL, HTTP, ID를 비롯한 일반적인 두문자어는 관례적인 대문자 형식으로 작성하십시오. 리시버 유형을 일관되게 반영하는 짧은 리시버 이름을 선택하십시오. 오류 문자열은 소문자로 시작하고 끝에 문장 부호를 붙이지 마십시오. 내보내는 문서는 선언된 이름으로 시작하는 완전한 문장으로 작성하십시오. 할당된 빈 슬라이스에 의미상 가치가 없다면 nil 슬라이스를 사용하십시오. 예상되는 실패에는 panic을 일으키지 말고 오류를 반환하십시오. 실패할 수 있는 작업 가까이에서 오류를 처리하십시오. 추가 컨텍스트가 실패한 작업의 위치를 찾는 데 도움이 될 때만 오류를 래핑하십시오. 프로그래밍 방식으로 처리해야 한다면 호출자가 검사할 수 있는 형태로 오류를 보존하십시오. 리소스 소유권이나 정리를 불분명하게 하는 영리한 제어 흐름은 피하십시오. 검토 전에 서식 지정과 정적 분석을 실행하십시오. 유효한 다른 Go 스타일이 있더라도 저장소에서 확립된 규칙을 적용하십시오. 프레임워크 인터페이스를 충족해야 하는 유형에는 컴파일 타임 인터페이스 단언을 사용하십시오. 의도적인 호환성 변경이 승인되지 않는 한 리시버, 패키지, 내보낸 이름을 안정적으로 유지하십시오. ## 각 모듈을 만들기부터 정리까지 순서대로 구현하기 프레임워크의 표준 등록 메커니즘을 통해 각 모듈을 등록하십시오. 네임스페이스가 있는 모듈 ID와 새 인스턴스용 생성자를 포함한 메타데이터를 반환하십시오. 생성자에 환경별 부작용이 없게 하십시오. 수명 주기를 다음과 같은 순서 있는 단계로 취급하십시오. 1. 새 값을 생성합니다. 2. 해당 값에 구성을 디코딩합니다. 3. 런타임 종속성을 프로비저닝합니다. 4. 완성된 구성을 검증합니다. 5. 모듈 기능을 제공하거나 실행합니다. 6. 소유한 리소스를 정리합니다. 구성과 프로비저닝 데이터를 사용할 수 있기 전에 최종 검증을 수행하지 마십시오. 프레임워크가 그런 방식으로 호출할 수 있다면 부분 프로비저닝 후와 반복된 종료 신호 후에도 안전하게 정리되도록 하십시오. 프로비저닝, 검증, 구성 파싱, 기타 선택적 인터페이스에 컴파일 타임 가드를 사용하십시오. 구성 오류와 런타임 실패를 구분할 수 있도록 수명 주기의 책임을 분리하십시오. 프로비저닝과 검증에서 조치 가능한 오류를 반환하십시오. 실패한 초기화를 일부만 사용할 수 있는 모듈 뒤에 숨기지 마십시오. 시작 및 중지 동작을 실제로 소유하는 구성 요소에만 최상위 애플리케이션 인터페이스를 사용하십시오. 구성, 어댑터, 외부 통합이 모듈 ID에 의존할 수 있으므로 이를 안정적으로 유지하십시오. ## 구성 파일을 엄격하게 읽고 관리 엔드포인트 보호하기 사람이 작성하는 구성은 프레임워크의 토큰 디스펜서 또는 동등한 구조화 반복자를 통해 파싱하십시오. 같은 줄의 인수를 읽기 전에 지시문 이름을 소비하십시오. 같은 줄의 인수와 중첩 블록을 별도로 처리하십시오. 현재 중첩 수준을 기록하고 파서가 해당 블록을 벗어나면 중지하십시오. 지원되는 하위 지시문을 명시적으로 인식하십시오. 필수 인수를 즉시 검증하고 파서의 표준 인수 오류를 반환하십시오. 예상하지 못한 값을 포함하는 오류로 알 수 없는 하위 지시문을 거부하십시오. 허용되는 구문을 유지 관리되는 계약으로 파서 옆에 문서화하십시오. 어댑터 출력을 기본 구조화 구성 모델과 일치시키십시오. 프로비저닝 중에 프레임워크 컨텍스트를 통해 로거와 다른 모듈을 가져오십시오. 모듈 범위의 구조화 로거를 사용하고 비구조화 메시지를 만드는 대신 필드를 첨부하십시오. 요청 또는 프로비저닝 컨텍스트를 수명이 긴 구조체에 저장하지 마십시오. 관리 엔드포인트를 추가할 때 프레임워크의 라우팅 인터페이스를 구현하십시오. 관리 화면에서 요구하는 인증, 인가, 노출 규칙을 적용하십시오. 모듈이 트래픽 처리를 시작하기 전에 구성을 검증하십시오. ## 새 종속성을 줄이고 패키지 경계를 분명히 유지하기 새 종속성의 가치가 유지 관리, 보안, 공급망 비용을 명백히 넘지 않는 한 추가하지 마십시오. 아주 작은 종속성이 불균형한 위험을 더한다면 작고 안정적인 기능을 인라인으로 구현하십시오. 외부 패키지의 유형을 프로젝트의 공개 API를 통해 노출하지 마십시오. 서드파티 동작을 프로젝트 소유 인터페이스와 유형 뒤에 래핑하십시오. 언어의 모듈 도구를 사용하여 종속성 선언과 체크섬의 일관성을 유지하십시오. 관련 없는 변경을 수용하지 말고 종속성 정리 명령을 실행한 뒤 해당 diff를 검토하십시오. 구성 어댑터를 런타임 모듈과 분리하십시오. 테스트 유틸리티를 프로덕션 진입점과 분리하십시오. 배포되는 명령이 사용하는 레지스트리에 표준 모듈을 배치하십시오. 명시적인 제품 결정 없이 선택적 모듈을 기본 바이너리에 가져오지 마십시오. 프로토콜 처리, 전송 보안, 인증서 작업을 둘러싼 패키지 경계를 유지하십시오. 대상으로 삼는 반복 동작을 식별한 후에만 일반화된 추상화를 선택하십시오. 단순한 구현을 불분명하게 만드는 추측성 추상화는 거부하십시오. 리팩터링할 때 관찰 가능한 동작을 보존하거나 의도한 모든 변경을 문서화하고 테스트하십시오. 보안에 중요한 패키지와 종속성 변경은 일상적인 내부 코드보다 더 깊이 검토하십시오. ## 병합 전에 모든 테스트·린트·빌드 통과하기 필수 품질 게이트를 모두 권고 사항이 아닌 차단 조건으로 취급하십시오. 데이터 경쟁 감지를 활성화하여 short 모드의 전체 테스트 스위트를 실행하십시오. 전체 저장소를 완료할 충분한 시간을 두고 구성된 린터를 실행하십시오. 모든 패키지를 빌드하여 누락된 인터페이스, 플랫폼 제약, 등록 오류를 찾아내십시오. 성능 변경에는 메모리 측정을 포함한 벤치마크를 실행하십시오. 벤치마크 결과를 적절한 기준선과 비교하고 변동성을 고려하십시오. 영향받는 서버 동작에 대해 집중된 통합 테스트를 실행하십시오. CI가 해당 플랫폼을 지원한다면 Linux, macOS, Windows에서 테스트가 통과하는지 확인하십시오. 다른 곳에 관련 없는 경고가 있더라도 변경된 파일의 경고를 조사하십시오. 필수 테스트, 린트, 빌드 또는 벤치마크 게이트가 하나라도 없다면 풀 리퀘스트를 병합 준비 완료로 표시하지 마십시오. 검토자가 증거를 재현할 수 있도록 명령과 관련 결과를 기록하십시오. 프로덕션 코드를 변경하기 전에 테스트 실패와 환경 실패를 구분하십시오. 직접 영향받는 모든 게이트를 계속 포괄하면서 변경에 비례하도록 검증 범위를 유지하십시오. 검토에 대응하여 코드를 변경한 뒤에는 영향받는 게이트를 다시 실행하십시오. 데이터 경쟁 보고서와 불안정한 동시성 실패를 조사가 필요한 결함으로 취급하십시오. ## 테이블 주도 단위 테스트와 포트를 분리한 서버 테스트 작성하기 여러 입력이 같은 동작을 공유할 때는 테이블 주도 테스트를 우선하십시오. 각 사례에 명시적인 입력, 예상 출력, 예상 오류 상태를 지정하십시오. 예상 오류가 누락된 경우와 예상하지 못한 오류가 반환된 경우를 모두 확인하십시오. 오류 조건을 적절히 처리한 후에만 반환값을 비교하십시오. 유효, 무효, 경계, 회귀 사례를 포함하십시오. 인덱스만으로 실패를 진단하기 어렵다면 사례에 이름을 붙이십시오. 픽스처는 최소한으로 유지하고 결정성을 보장하십시오. 엔드투엔드 구성 동작에는 프로젝트의 서버 테스트 하네스를 사용하십시오. 격리된 구성과 명시적인 형식으로 테스트 서버를 초기화하십시오. 로컬에서 실행 중인 서비스와 충돌하지 않도록 비표준 포트를 사용하십시오. 필요하면 관리, 평문 트래픽, 암호화 트래픽에 별도 포트를 예약하십시오. 상태, 본문, 기타 외부에서 관찰할 수 있는 동작을 단언하십시오. 테스트에서 만든 서버, 리스너, 파일, 고루틴을 정리하십시오. 테스트 순서나 공유된 가변 전역 상태에 의존하지 마십시오. 서버가 성공적으로 시작되는 경우뿐 아니라 구성 파싱 오류도 테스트하십시오. 경로, 소켓, 신호 또는 프로세스 동작이 다르면 플랫폼별 사례를 추가하십시오. 실패를 통해 깨진 계약을 식별할 수 있을 만큼 통합 테스트의 범위를 좁히십시오. ## 풀 리퀘스트·보안 보고서·계약 동의는 사람에게 맡기기 이슈 토론, 풀 리퀘스트, 라이선스 계약, 보안 보고서를 사람이 관리하는 외부 작업으로 취급하십시오. AI 어시스턴트는 사람인 기여자를 사칭하거나 당사자를 대신해 법적 계약에 동의해서는 안 됩니다. 관리 정책에서 해당 에이전트 작업을 명시적으로 승인하지 않는 한 외부 이슈, 풀 리퀘스트 또는 보안 보고서를 생성하거나 제출하지 마십시오. 검토 지원을 허용된 역할 안으로 제한하고 필요한 경우 AI의 참여를 밝히십시오. 기여 정책에서 공개를 요구한다면 AI의 관여를 숨기지 마십시오. 사람인 운영자가 제출된 모든 줄을 이해하고 설명할 수 있게 하십시오. 가능하면 자동 검사로 AI 지원 코드를 테스트하고, 그렇지 않으면 철저한 수동 검사로 테스트하십시오. 생성된 코드에 복사된 자료, 호환되지 않는 라이선스, 검증되지 않은 주장이 있는지 검토하십시오. 취약점 세부 정보를 지어내거나 검증되지 않은 보안 보고서를 제출하지 마십시오. 번역 또는 편집 지원은 사람인 작성자가 검증한 보안 사실을 보존해야 합니다. 사람만 할 수 있는 서명, 증명, 기여자 계약은 책임자에게 맡기십시오. 요청된 작업이 기여 정책과 충돌하면 해당 작업을 중지하고 적용되는 경계를 설명하십시오. 금지된 외부 작업을 대신하기 위해 기만적인 파일, 주석 또는 커밋을 추가하지 마십시오. 커뮤니티 절차를 우회하지 않으면서 패치의 기술적 유용성을 유지하십시오. 승인 전에 공개, 이해, 테스트, 라이선스를 별도 게이트로 검증하십시오. 에이전트가 구현 대부분을 생성했더라도 사람의 책임은 계속 필요합니다.