프로젝트 기획: 문제·요구사항·아키텍처·인수 기준

01기술을 고르기 전에 해결할 문제를 쓰기

• 문제와 기대 결과인프라 자동화의 문제 정의 예: DNS·웹·파일 공유·계정·네트워크 장비를 반복 설정할 때 시간이 늘고 설정 누락이 발생한다.

  • 팝업스토어는 이런 반복 구축을 설명하기 위한 적용 사례다.
  • “Python으로 모두 자동화”는 수단이고, 실제 목표는 입력이 달라져도 정해진 서비스와 접근 경계가 일관되게 만들어지는 것이다.
• 기술 선택의 근거문제 문장에는 사용자와 작업 시점이 들어간다.

  • 새 환경을 여는 관리자, 운영 중 장애를 확인하는 담당자, 종료 후 데이터를 보관하는 담당자는 필요한 기능이 다르다.
  • 구축만 자동화하고 종료·회수·백업을 빼면 초기 설치 시연에는 성공해도 반복 운영이라는 기획 목적을 충족하지 못한다.

02요구사항에서 인수 기준까지의 단계

1. 문제 정의누가 어떤 상황에서 겪는 문제인지, 현재 방식과 개선 목표를 적는다.
2. 요구 분류필요 기능, 성능·가용성·보안 등의 품질 기준, 예산·기간·환경 제약을 구분한다.
3. 구조 설계서비스·데이터·관리 경로와 의존성, 실패 시 영향과 복구 경계를 정한다.
4. 작업과 시험 연결각 요구사항에 작업·담당자·설정·시험 ID와 기대 결과를 연결한다.
5. 검증과 인수정상·실패 조건을 시험하고 충족한 기준과 남은 제약을 정리해 인계한다.

03기능 요구사항·품질 기준·제약을 구분하기

• 기능·품질·제약기능 요구사항은 사용자가 할 수 있는 행동이나 시스템이 제공할 동작이다.

  • 새 서비스의 DNS 레코드를 생성하거나 요청을 올바른 가상 호스트에 전달하는 것이 여기에 해당한다.
  • 비기능 요구사항은 그 동작의 보안성·성능·가용성·재현성 같은 품질 조건이다.
  • “접근 가능”과 “관리망에서 승인된 계정으로만 접근 가능”은 서로 다른 요구다.
• 측정 가능한 요구제약은 설계 선택의 경계다.

  • 한 물리 호스트의 자원, 프로젝트 기간, 지원하는 운영체제, 외부 연결 허용 여부가 여기에 들어간다.
  • 역할별 VM 분리는 장애와 권한의 범위를 줄일 수 있지만 물리 호스트 하나의 장애까지 해결하지는 않는다.
  • 논리적 분리와 물리적 가용성을 각각 설명해야 한다.

04설계를 비교하는 평가 기준

• 평가 기준기획안은 구현 가능성 30, 기술 반영성 25, 운용성 15, 경제성 15, 확장성 10, 차별성 5의 배점을 제시한다.

  • 평가 항목의 비중은 사업 목표·제약·이해관계자에 맞게 합의한다.
  • 숫자를 그대로 목표로 삼기보다 어떤 선택이 각 항목을 만족하는지 근거를 작성하는 데 활용한다.
• 의사결정의 근거예를 들어 처음부터 모든 서버 종류를 자동화하면 기술 반영성은 커 보이지만 기간 내 검증 가능성이 낮아질 수 있다.

  • DNS와 웹부터 정상 생성·실패 복구·재실행을 완성하고 파일 공유를 다음 단계로 두면 범위를 조절할 수 있다.
  • 경제성은 “자동화라 빠르다”가 아니라 동일 작업의 수동·자동 소요 시간, 실패 재작업과 유지보수 비용까지 포함해 측정한다.

06아키텍처에 서비스 흐름과 관리 흐름을 함께 그리기

• 서비스 경로서비스 흐름은 클라이언트 요청이 DNS 조회, 진입 지점, 웹 애플리케이션, DB로 이동하는 경로다.

  • 관리 흐름은 운영자가 어디서 인증받고 장비 설정·로그·백업에 접근하는지 보여 준다.
  • 관제 수집 흐름은 서비스 요청과 별도이므로 센서와 수집기의 방향, 관리 인터페이스, 저장 위치도 표시한다.
• 관리·장애 경로서버 명세에는 역할·운영체제·자원·인터페이스·데이터 보관 위치를 넣는다.

  • 통신 정책 표에는 출발 역할, 목적 역할, 프로토콜·포트, 용도와 승인 주체를 넣는다.
  • 주소표만으로는 해당 통신이 왜 허용되는지 설명할 수 없다.
  • NAT, 방화벽, 서비스 계정의 경계를 넘을 때 요청의 어느 식별자가 유지되거나 바뀌는지도 기록한다.

07설정 자료를 자동화 입력으로 설계하기

• 환경별 입력장치별 설정값을 표나 DB에 저장하고 이를 읽어 구성을 생성할 수 있다.

  • 입력 자료에는 장비 식별자, 서비스 역할, 네트워크 구획, 이름, 필요한 자원을 분리해 둔다.
  • 입력을 명령 문자열에 그대로 이어 붙이는 구조보다 값의 형식과 허용 범위를 검사하고 설정 템플릿에 전달하는 구조가 오류를 찾기 쉽다.
• 설정과 비밀의 분리생성한 파일과 장비에 적용된 상태도 구분한다.

  • 계획 생성 → 유효성 검사 → 변경 전 백업 → 적용 → 정상 동작 확인 → 결과 저장 순으로 나누면 실패 지점을 설명할 수 있다.
  • 적용 중 연결이 끊기는 IP 변경 같은 작업은 관리 연결이 사라질 수 있으므로 별도 복구 경로와 작업 순서가 설계의 일부다.
  • 성공 메시지는 설정 파일을 썼다는 의미인지 실제 서비스 검증이 끝났다는 의미인지 명확히 한다.

09요구사항과 시험을 같은 ID로 연결하기

• 요구사항과 시험 ID요구사항마다 설계 요소, 담당 작업, 확인 방법을 연결한다.

  • 기능이 구현되었는데 대응하는 시험이 없다면 완료 근거가 비어 있고, 시험은 있는데 어떤 요구를 만족하는지 모르면 불필요한 시연이 늘어난다.
  • 같은 ID를 기획·구현·시험·보고서에서 사용하면 변경된 요구가 어느 산출물에 영향을 주는지도 찾을 수 있다.
• 인수 기준아래 수치 없는 예시는 팀이 합의한 조건을 채워 넣는 출발점이다.

  • 서비스 가용 시간이나 응답 시간 같은 수치는 사용자 기대, 자원 제약, 측정 위치를 함께 합의해야 의미가 있다.
  • 기준을 측정 후 유리하게 바꾸면 인수 판정이 흔들린다.

REQ-WEB-01: 이름별 웹 서비스 분기
설계: 진입 프록시의 가상 호스트 + 서비스별 backend
선행 작업: DNS 이름, 인증서, backend 정상 응답
정상 시험: 각 이름에서 해당 콘텐츠가 반환됨
거부 시험: 정의되지 않은 관리 경로로 접근할 수 없음
산출물: 설정 버전, 요청/응답, 프록시·backend 로그
완료: 합의한 정상·거부·복구 시험 통과 및 검토

작성 연습용 예시이며 실제 수행 결과나 개인 경력으로 제시한 내용이 아니다.

10종료와 확장을 설계 범위에 넣기

• 운영 인계단기 서비스라면 개통뿐 아니라 기간 종료 후의 상태 전환도 필요하다.

  • 신규 요청 중지, 데이터 내보내기, 보관 여부 확인, 계정·인증서·접근권한 회수, DNS와 자원 정리를 순서대로 정의한다.
  • 백업의 존재와 복원 가능성은 다르므로 복원 대상과 확인 방법이 있어야 보관 설계가 완성된다.
• 범위와 변경 관리운영체제나 제품은 막연한 업계 점유율 주장으로 선택하지 않는다.

  • 지원하는 기능, 업데이트 기간, 팀이 설명할 수 있는 구성, 필요한 패키지와 자동화 방식, 자원 사용량을 비교한다.
  • 선택 이유와 제외한 대안을 남겨야 규모나 요구가 변했을 때 어떤 조건에서 재검토할지 알 수 있다.