소프트웨어와 개발 산출물

프로그램·데이터·문서·운영 규칙을 구분하고 개발 단계마다 남겨야 할 검증 가능한 산출물을 정합니다.

신청 함수가 잘 실행되어도 진행자가 정원을 어디서 바꾸는지 모르고, 담당자가 취소 정책을 모르면 모임 운영은 실패합니다. 소프트웨어를 실행 코드만으로 생각하면 이 실패를 개발 범위에서 놓칩니다.

이 문서에서는 독서 모임의 코드, 데이터, 설명서, 운영 절차를 구별하고 다음 장에서 무엇을 결정해야 하는지 정합니다.

같은 프로그램을 둘러싼 네 가지 대상

대상	모임 예	확인할 질문
프로그램	신청·취소 함수	규칙대로 상태가 바뀌는가?
데이터	모임 정원·참가자 목록	누가 만들고 언제까지 보존하는가?
사용자 문서	설치·실행·거절 이유 안내	처음 쓰는 사람도 다음 행동을 아는가?
운영 절차	마감·백업·복구·변경 승인	문제가 났을 때 담당자가 무엇을 하는가?

소프트웨어는 눈에 보이지 않는 규칙을 다루고 실행 중 기능이 추가되며 다른 시스템에 의존합니다. 복사본을 만들기 쉽다고 요구 분석과 검증 비용까지 사라지는 것은 아닙니다. 하드웨어처럼 마찰로 닳지는 않지만 실행 환경이나 요구가 바뀌면 기존 코드도 더 이상 적합하지 않을 수 있습니다.

소프트웨어공학은 이런 개발·운영의 일을 체계적으로 수행하고 증거로 개선하는 활동입니다. 모든 상황에 같은 문서 양식을 강제하는 뜻은 아닙니다. 작은 모임 앱과 의료 장비의 승인·검증 절차가 달라지는 이유도 실패의 영향과 변경 비용이 다르기 때문입니다.

단계는 결과물을 연결한다

산출물은 개발 활동에서 남는 결과입니다. 요구 분석은 “취소하면 자리를 다시 사용할 수 있다”는 조건을 만들고, 설계는 명단에서 ID를 제거하는 상태 전이를 정하고, 구현은 그 전이를 실행하며, 테스트는 실제로 자리가 재사용되는지 검사합니다.

요구 → 설계 → 구현 → 테스트 → 운영을 한 번만 순서대로 끝낸다고 가정하지 않습니다. 운영에서 잘못된 거절 이유를 발견하면 요구를 확인하고 설계와 테스트를 함께 고칩니다. 각 단계의 담당이 다르더라도 근거를 연결해야 합니다.

작업 폴더에 policy.md를 만들고 다음 메모를 직접 작성합니다. Markdown은 #로 제목을 표시하는 일반 텍스트이며 전용 편집기가 없어도 읽을 수 있습니다.

# 독서 모임 첫 정책
목적: 명단 중복과 정원 초과를 막는다.
대상: 모임 진행자와 참가자.
아직 결정하지 않은 질문: 마감 뒤 취소를 허용할까?
확인 방법: 진행자에게 취소 사례를 질문하고 결과 코드를 테스트한다.

이 메모는 코드가 어떤 규칙을 따라야 하는지 합의하기 위한 것입니다. 문서를 많이 쓰는 것보다 미결정 사항과 검증 방법이 드러나는지가 중요합니다.

교재 실습 파일을 준비하는 두 경로

저장소 예제 묶음은 dev-note/scripts/software-engineering-lab/에 있습니다. 저장소의 최상위 폴더에서 다음 명령으로 장별 예제를 실행합니다.

node dev-note/scripts/software-engineering-lab/examples/ch1.mjs

직접 파일을 만드는 경로도 가능합니다. 기능 요구와 수락 조건에서 core.mjs 전체를 제공하고, 해당 문서의 코드를 examples/ch2.mjs에 저장합니다. 이후 장별 코드는 같은 폴더 구성을 사용합니다.

reading-lab/
  core.mjs
  core.test.mjs
  examples/
    ch2.mjs
    ch3.mjs ... ch10.mjs

import는 다른 파일의 공개된 함수를 가져옵니다. ../core.mjs에서 ..는 현재 예제 파일보다 한 단계 위 폴더를 뜻합니다. 파일 이름의 대소문자와 확장자를 맞춥니다. node:로 시작하는 모듈은 Node.js에 포함되어 있습니다. 저장소 경로 명령은 저장소에서, 직접 만든 예제는 reading-lab에서 node examples/ch2.mjs로 실행합니다.

실행 위치와 import 기준은 서로 다르다

터미널의 현재 작업 폴더(cwd)는 상대 실행 경로의 출발점입니다. node examples/ch2.mjs는 현재 폴더에서 examples/ch2.mjs를 찾습니다. 다음 명령으로 먼저 위치를 확인합니다.

node -p "process.cwd()"

직접 만든 실습을 C:\study\reading-lab에 저장했다면 PowerShell에서 아래처럼 이동한 뒤 실행합니다. 실제로 자신이 만든 폴더 경로를 사용합니다.

Set-Location -LiteralPath 'C:\study\reading-lab'
Get-ChildItem
Get-ChildItem -LiteralPath '.\examples'
node examples/ch2.mjs

첫 목록에는 core.mjs, 다음 목록에는 ch2.mjs가 보여야 합니다. 편집기가 ch2.mjs.txt로 저장하지 않았는지도 확인합니다. Cannot find module이면 무작정 패키지를 설치하기 전에 현재 위치 → 실행 파일의 실제 이름 → import 대상을 차례로 확인합니다. node 자체가 없다고 나오면 Node 준비로 돌아갑니다.

경로	기준	위 구성에서 가리키는 곳
터미널의 `examples/ch2.mjs`	현재 작업 폴더	`reading-lab/examples/ch2.mjs`
ch2.mjs 내부의 `../core.mjs`	import를 쓴 파일의 위치	`reading-lab/core.mjs`
`node:assert/strict`	Node 내장 모듈 이름	별도 다운로드 없음

다른 폴더에서 node C:\study\reading-lab\examples\ch2.mjs처럼 실행 파일을 절대경로로 지정해도 그 파일의 ../core.mjs는 그대로 형제 구조를 찾습니다. 터미널 위치와 모듈 위치를 같은 것으로 생각하지 않습니다.

장별 파일은 서로 다른 예제입니다. 본문이 추가하라고 명시하지 않은 독립 블록들을 한 파일에 계속 붙이지 않습니다. 같은 const store나 함수 이름을 다시 선언하면 업무 규칙 이전에 문법 오류가 납니다. 저장소 예제는 완성된 장별 파일을 사용하고, 직접 만드는 경로에서는 절의 파일 이름과 필요한 import를 먼저 맞춥니다.

독립 문제: 다음 담당자에게 남기기

제작자가 “잘 돌아가요”라는 말과 실행 파일만 전달했습니다. 진행자는 정원을 바꾸고 마감 뒤 취소를 받아야 합니다. 인수할 때 요청할 산출물 세 가지와 각각 확인할 사례를 제시하세요.

힌트

실행 방법, 업무 규칙, 문제에서 회복하는 방법을 별도로 생각합니다.

해설과 예시 답안

실행 안내와 지원 버전을 받아 새 환경에서 예제를 실행합니다. 정원·마감·취소 정책표를 받아 가득 찬 명단의 중복 신청과 마감 뒤 취소를 확인합니다. 데이터 보존·복구 절차를 받아 종료 후 명단을 복원하는 사례를 확인합니다. 소스와 테스트도 유용하지만 테스트 통과만으로 이 세 업무 질문의 답이 자동으로 생기지는 않습니다.

웹·임베디드·업무·AI 소프트웨어는 서로 겹칠 수 있는 분류입니다. AI를 언제나 연구 단계라고 두거나 웹 앱은 운영 절차가 없다고 생각하지 않습니다. 다음 장은 구현 기술을 고르기 전에 사용자의 문제와 이번 작업 범위를 정합니다.