핵심노트 · 주제 01

소프트웨어 개발

이게 뭔가요?

사람이 하려는 일을 컴퓨터가 실제로 처리하도록 만드는 방법을 배웁니다. 필요한 기능을 파악하고, 구조를 설계하고, 코드로 구현하고, 제대로 작동하는지 확인하고 고치는 과정입니다. 식당 예약 앱이라면 고객이 시간을 고르고 예약한 뒤 취소할 수 있도록 동작을 만드는 일입니다.

왜 배우나요?

코드가 실행돼도 사용자가 필요한 일을 끝내지 못하면 문제는 남습니다. 예약 버튼을 두 번 눌렀을 때 중복 예약이 생기거나, 기능 하나를 고쳤는데 다른 기능이 멈출 수도 있습니다. 필요한 동작을 정확히 만들고, 바뀐 요구에 맞춰 안전하게 수정하는 방법을 배우기 위해 공부합니다.

코드를 작성하는 속도보다, 필요한 동작을 정확히 만들고 안전하게 바꿀 수 있는지가 중요합니다.

교재 개념의 뜻을 설명하고, 가상 업무에서 언제 왜 쓰는지 풀어 쓴 자체 해설입니다. 먼저 설명과 예시를 읽고, 확인 질문에 자신의 말로 답해 보세요. 각 항목의 관련 교재 내용에서 단원과 교재 페이지를 확인할 수 있습니다. 20개 노트는 교재 전체 요약이나 시험 중요도 순위가 아니며, 주제 끝의 추가 학습 내용도 함께 확인하세요.

1. 요구사항 추출 — 만들기 전에 불편을 확인한다

요구사항은 프로그램이 해야 할 일과 지켜야 할 조건입니다. 요구사항 공학은 필요한 내용을 찾아 분석하고 문서로 정한 뒤, 서로 같은 뜻으로 이해했는지 확인하고 변경을 관리하는 활동입니다.

사용자가 요청한 기능만 듣지 말고 그 기능으로 해결하려는 불편도 확인해야 합니다. 엑셀 내려받기 버튼을 원하는 이유가 매일 두 목록을 비교해 누락 주문을 찾기 위해서라면, 파일 제공 외에 누락을 바로 보여 주는 방법도 검토할 수 있습니다. 해결할 문제를 잘못 짚으면 기능을 빨리 만들어도 업무는 나아지지 않습니다.

가상 업무 예시

직원이 엑셀 내려받기 버튼을 요청했다고 합시다. 이유를 물어보니 주문 누락을 찾으려고 매일 두 목록을 비교하고 있었습니다. 파일 제공뿐 아니라 누락 주문을 바로 보여 주는 방법도 함께 검토할 수 있습니다.

생각해 볼 질문
사용자는 지금 어떤 작업에서 막히나요? 요청한 기능을 추가하면 그 작업이 어떻게 쉬워지나요?

2. 테스트 케이스와 완료 기준 — 같은 결과를 확인한다

테스트 케이스는 어떤 준비 상태에서 무엇을 입력하고 실행했을 때 어떤 결과가 나와야 하는지 적은 시험 사례입니다. 개발자와 사용자가 같은 기준으로 완료 여부를 확인하는 데 도움이 됩니다.

고객 검색이라면 찾는 이름이 있을 때만 시험하지 않습니다. 같은 이름이 두 명일 때 구분할 정보, 결과가 없을 때 안내, 권한 없는 정보가 보이지 않는 조건도 정합니다. 이렇게 기대 결과를 구체적으로 합의하면 ‘검색이 된다’의 의미가 서로 달라지는 일을 줄일 수 있습니다.

가상 업무 예시

고객센터에서 ‘김민수’를 검색했더니 동명이인 두 명이 나왔는데 첫 번째 고객만 표시돼 다른 사람의 주문을 안내했습니다. 팀은 ‘동명이인 두 명을 등록한 상태에서 이름을 검색하면 두 행을 표시하고, 상담 권한 안에서 고객 번호로 구별한다’를 합격 기준으로 적었습니다. 없는 이름은 ‘검색 결과 없음’을 표시하는지도 함께 확인합니다.

생각해 볼 질문
어떤 입력을 넣었을 때 어떤 결과가 나와야 하나요? 사용자와 개발자가 같은 결과를 합격으로 판단하나요?

3. 업무 규칙 — 프로그램이 지켜야 할 약속을 찾는다

업무 규칙은 할인 조건이나 취소 기한처럼 프로그램이 지켜야 할 기준입니다. 같은 규칙을 여러 화면에 따로 구현하면 하나만 고쳤을 때 결과가 달라질 수 있습니다.

모듈은 맡은 역할에 따라 나눈 프로그램 부분입니다. 할인 계산을 담당할 공통 모듈을 두고 각 화면이 그 결과를 사용하게 하면 규칙을 한곳에서 관리할 수 있습니다. 사용자가 화면을 거치지 않고 요청할 수도 있으므로 중요한 규칙은 실제 처리를 맡은 서버에서도 확인해야 합니다.

가상 업무 예시

주문 취소 기한을 웹 화면에만 넣으면 다른 경로로 들어온 요청에서는 기한을 넘긴 취소가 처리될 수 있습니다. 서버에서도 취소 가능 여부를 판단하고, 출고가 시작된 주문은 별도 절차로 안내하도록 만듭니다.

생각해 볼 질문
웹 화면 외의 경로로 주문 취소를 요청해도 같은 기한 규칙이 적용되나요? 예외를 승인할 사람도 정했나요?

4. 점증적 개발 — 작은 변경으로 일찍 확인한다

점증적 개발은 핵심 기능부터 동작하게 만든 뒤 기능을 더해 가는 방식입니다. 진화적 개발은 사용하면서 발견한 변경 사항을 다음 버전에 반영하는 방식입니다. 실제 개발에서는 두 방식을 함께 사용할 수 있습니다.

배송지 입력부터 개선해 사용자가 제대로 입력하는지 확인한 뒤 다른 기능을 넓히면 잘못된 가정을 일찍 찾을 수 있습니다. 다만 입력 화면만 바꾸고 기존 주문 저장과 연결되지 않으면 쓸 수 없으므로, 작은 단위도 실제 사용 흐름이 이어지게 구성해야 합니다.

가상 업무 예시

배송지 화면 전체를 개편하기 전에 우편번호 검색과 주소 저장까지만 한 흐름으로 만들어 일부 고객에게 제공합니다. 시험에서 도로명 주소를 모르는 고객이 입력을 끝내지 못하자 직접 입력 경로를 보완합니다. 그다음 배송 요청사항 기능을 추가합니다. 작은 버전에서도 주문을 끝낼 수 있어야 실제 불편을 일찍 발견할 수 있습니다.

생각해 볼 질문
사용자가 확인할 수 있는 작은 기능부터 공개할 수 있나요? 문제가 생겼을 때 이전 코드와 데이터로 돌아갈 수 있나요?

5. 응집도와 결합도 — 모듈의 역할을 모으고 서로의 의존을 줄인다

모듈은 할인 계산이나 주문 저장처럼 역할에 따라 나눈 프로그램 부분입니다. 응집도는 한 모듈 안의 내용이 같은 목적에 얼마나 관련돼 있는지, 결합도는 다른 모듈에 얼마나 의존하는지를 나타냅니다.

할인 계산과 화면 색상 처리가 뒤섞이면 요금 규칙을 바꾸다가 화면 코드까지 건드리기 쉽습니다. 계산은 공통 모듈에 모으고 화면은 결과를 보여 주게 나누면 변경 범위를 이해하기 쉬워집니다. 파일 수를 늘리는 것보다 관련 역할을 모으고 불필요한 연결을 줄이는 것이 목적입니다.

가상 업무 예시

할인율이 바뀔 때 고객용 화면과 관리자 화면을 따로 수정하면 한쪽을 빠뜨릴 수 있습니다. 할인 금액은 공통 계산 함수에서 구하고, 두 화면은 그 결과를 보여 주도록 나누면 같은 규칙을 여러 번 고치는 일을 줄일 수 있습니다.

생각해 볼 질문
정책 하나를 바꿀 때 어디를 고쳐야 하는지 설명할 수 있습니까?

6. 검증 — 중요한 실패를 먼저 잡는다

명세 기반 테스트는 프로그램이 해야 한다고 정한 동작에서 시험할 조건을 찾는 방법입니다. 경계값 분석은 허용 범위의 끝과 그 주변을, 상태전이 시험은 현재 상태에서 어떤 사건이 생겼을 때의 변화를 확인합니다.

주문 수량이 1부터 10까지라면 1·10뿐 아니라 0·11도 확인할 수 있습니다. 결제 실패 뒤 재고가 돌아오는지, 버튼을 두 번 눌러도 중복 주문이 생기지 않는지도 중요한 시험입니다. 시험 수를 늘리는 데서 끝내지 말고 어떤 잘못된 결과와 피해를 막는지 확인합니다.

가상 업무 예시

한정 상품은 한 사람당 최대 10개만 살 수 있습니다. 정상 주문 2개만 시험하면 11개 구매도 허용하는 오류를 놓칩니다. 담당자는 0·1·10·11개를 주문해 경계를 확인하고, 결제 거절 시 확보했던 재고가 반환되는지도 검사합니다. 판매 제한 위반과 팔리지 않은 재고의 장기 점유를 각각 막는 시험입니다.

생각해 볼 질문
이 기능이 잘못되면 사용자에게 어떤 피해가 생기나요? 그 피해를 일으키는 입력이나 상황을 시험했나요?

7. 트랜잭션과 실패 처리 — 응답이 끊겨도 실제 처리 결과를 확인한다

트랜잭션은 함께 성공하거나 모두 취소돼야 하는 데이터 작업의 단위입니다. 하지만 내 프로그램의 트랜잭션이 외부 결제 업체의 처리까지 자동으로 되돌리는 것은 아닙니다.

결제를 요청한 뒤 응답을 받지 못해도 업체에서는 이미 결제가 끝났을 수 있습니다. 바로 새 결제를 요청하면 두 번 청구될 수 있으므로 같은 요청을 구분할 번호와 실제 상태 확인이 필요합니다. 이미 처리된 요청에는 기존 결과를 돌려주는 등의 방식으로 중복 처리를 막아야 합니다.

가상 업무 예시

결제 요청 뒤 통신이 끊겼다고 다시 결제하면 두 번 청구될 수 있습니다. 요청을 식별할 번호를 사용하고 결제 상태를 먼저 조회해, 이미 처리된 요청은 그 결과를 돌려주도록 합니다.

생각해 볼 질문
요청이 중간에 끊기면 사용자는 상태를 알 수 있고, 안전하게 다시 시도할 수 있습니까?

8. 리팩토링 — 기존 동작을 보존하며 개선한다

리팩토링은 사용자가 보는 동작을 유지하면서 프로그램 내부 구조를 개선하는 작업입니다. 기능 추가나 동작 변경과 목적이 다르므로 기존에 지켜야 할 동작부터 확인해야 합니다.

오래된 날짜 보정 코드가 지저분해 보여도 해외 지점의 마감 시간을 처리할 수 있습니다. 그 조건을 재현하는 시험을 먼저 마련하고 구조를 정리합니다. 수정 후 기존 동작이 망가지지 않았는지 확인하는 회귀 시험으로 필요한 예외가 사라지지 않게 합니다.

가상 업무 예시

정산 프로그램 세 곳에 해외 지점의 마감 시각을 보정하는 코드가 복사돼 있습니다. 한 곳만 고치면 보고서마다 날짜가 달라질 수 있습니다. 개발자는 지점별 마감 전후의 정산 결과를 시험으로 남기고 계산을 공통 함수로 모읍니다. 같은 입력의 정산 금액과 날짜는 그대로이고, 다음 시간대 수정은 한곳에서 하게 됩니다.

생각해 볼 질문
없애려는 코드가 막고 있는 문제를 확인했습니까? 대체 구현에서도 그 동작이 유지됩니까?

9. 배포와 복구 — 실제 환경에서 확인하고 실패 시 되돌린다

배포는 새 프로그램이나 설정을 실제 서비스에 적용하는 일입니다. 유지보수에는 오류 수정뿐 아니라 환경 변화에 맞춘 수정과 데이터 변환도 포함되므로 프로그램 파일만 교체하는 것으로 끝나지 않을 수 있습니다.

주소를 저장하는 형식을 바꾸면 기존 자료와 새 프로그램이 서로 맞는지 확인해야 합니다. 옛 프로그램도 잠시 함께 실행된다면 읽을 수 있는 형식을 유지할 전환 기간이 필요합니다. 문제가 생겼을 때 돌아갈 프로그램과 데이터 처리 방법을 함께 준비합니다.

가상 업무 예시

주소를 한 칸에 저장하던 쇼핑몰이 기본주소와 상세주소로 나누려 합니다. 새 프로그램을 순차 배포하는 동안 옛 프로그램도 주문을 읽으므로 기존 칸을 바로 지우면 일부 주문 조회가 실패합니다. 개발자는 전환 중 두 형식을 지원하고 옛 프로그램을 모두 교체한 뒤 기존 칸을 정리합니다. 되돌릴 때도 옛 코드가 주소를 읽는지 먼저 시험합니다.

생각해 볼 질문
배포가 실패했을 때 코드와 데이터를 각각 어떻게 복구합니까?

10. 관찰과 피드백 — 공개 후 실제 사용을 확인한다

UI는 화면과 버튼처럼 사용자가 직접 접하는 조작 수단입니다. UX는 사용자가 서비스를 통해 목적을 이루는 전체 경험입니다. 보기 좋은 화면을 만들었어도 신청을 끝내지 못하면 경험이 좋다고 하기 어렵습니다.

공개 후에는 접속 수만 보지 말고 어디에서 포기하거나 오류가 나는지와 어떤 문의가 반복되는지 확인합니다. 파일 첨부 제한을 이해하지 못해 제출이 줄었다면 안내와 입력 검사를 개선할 수 있습니다. 관찰을 위해 꼭 필요하지 않은 민감한 자료까지 기록하지는 않습니다.

가상 업무 예시

새 신청 화면의 접속 수는 많지만 제출 완료가 적다면 성공이라고 보기 어렵습니다. 단계별 실패와 문의를 확인하고, 파일 첨부 제한을 이해하지 못하는 사용자가 많다면 안내와 입력 검사를 개선합니다.

생각해 볼 질문
이 기능이 도움이 됐는지 어떤 결과를 보고 판단하고, 누가 다음 개선을 결정합니까?

11. 형상관리와 버전 기록 — 변경의 이유를 남긴다

형상관리는 코드·설정·문서 등 관리할 대상을 정하고 승인된 상태에서 무엇이 바뀌었는지 통제하고 기록하는 활동입니다. 비교의 기준이 되는 승인 상태를 기준선이라고 합니다.

버전 기록이 있으면 어떤 수정이 어느 배포에 포함됐는지 찾을 수 있습니다. 요금 계산 수정과 버튼 색 변경처럼 목적이 다른 작업은 나눠 기록하면 오류가 생겼을 때 원인을 찾고 필요한 부분만 되돌리기 쉽습니다. 단순히 파일을 저장하는 것에 더해 이유와 검증 결과도 남깁니다.

가상 업무 예시

요금 계산과 버튼 색 변경을 한 번에 반영하면 금액 오류가 났을 때 필요한 부분만 되돌리기 어렵습니다. 작업 목적별로 변경을 나눠 기록합니다.

생각해 볼 질문
변경 기록에 무엇을 왜 고쳤는지 적었나요? 문제가 생겼을 때 어느 배포에 포함된 변경인지 찾을 수 있나요?

12. 코드 검토 — 다른 사람이 이해할 수 있는지 확인한다

코드 검토는 다른 사람이 코드를 읽으며 의도와 오류 가능성을 확인하는 활동입니다. 실행 결과만 보지 않고 코드와 문서를 살펴 결함을 찾는 정적 검증의 한 방법입니다.

쿠폰 만료 계산이 맞아 보여도 기준 시간이 한국 시간인지 UTC인지 정해지지 않았다면 실제 사용에서 결과가 달라질 수 있습니다. 작성자는 변경 목적과 가정을 설명하고 검토자는 그런 조건이 빠지지 않았는지 봅니다. 확인한 규칙은 만료 직전·직후 시험으로도 검증합니다.

가상 업무 예시

쿠폰 코드를 검토하던 동료가 만료 시각이 한국 시간인지 UTC인지 정해져 있지 않음을 발견했다고 합시다. 팀은 기준 시간대를 정하고, 만료 직전과 직후에 쿠폰이 각각 허용·거절되는지 시험합니다.

생각해 볼 질문
동료가 코드의 목적과 오류 가능성을 확인할 수 있도록 요구사항과 시험 결과를 함께 제공했나요?

13. 동시성 — 여러 사용자가 함께 행동하는 상황을 다룬다

동시성 제어는 여러 사람의 처리가 겹쳐 진행돼도 정해진 데이터 규칙을 지키게 하는 방법입니다. 한 사람이 쓰는 시험에서는 보이지 않던 문제가 동시에 사용할 때 생길 수 있습니다.

마지막 좌석을 두 사람이 각각 조회하면 두 화면 모두 한 자리가 남았다고 볼 수 있습니다. 최종 예약에서는 확인과 확정 사이에 다른 요청이 끼어들어 둘 다 성공하지 않도록 처리해야 합니다. 이처럼 관련 처리를 쪼개지지 않는 한 단위로 다루는 것을 원자적으로 처리한다고 합니다.

가상 업무 예시

마지막 좌석을 두 사람이 동시에 선택하면 두 화면 모두 예약 가능으로 보일 수 있습니다. 최종 확정 단계에서 좌석 확보를 원자적으로 처리해 한 요청만 성공하게 합니다.

생각해 볼 질문
두 사용자가 마지막 좌석을 동시에 예약하면 둘 다 성공할 수 있나요? 한 요청만 확정되도록 처리했나요?

14. FSM과 상태 전이 — 현재 상태에서 가능한 다음 동작을 정한다

FSM은 유한 상태 기계로, 가능한 상태와 어떤 사건에서 다음 상태로 바뀌는지를 정해 표현하는 방법입니다. 주문이라면 접수·결제 완료·배송 중·취소처럼 상태를 나누고 허용할 이동을 정할 수 있습니다.

결제 실패가 확정된 주문에 늦게 도착한 대기 알림이 들어왔다면 무조건 대기 상태로 되돌리면 안 됩니다. 현재 상태와 요청의 조건을 확인하고 허용되지 않은 이동은 거부하거나 담당자 확인으로 넘깁니다. 상태 이름만 나열하지 말고 바뀌는 조건도 적어야 합니다.

가상 업무 예시

온라인 강의 결제가 ‘승인 대기’일 때는 수강권을 발급하지 않고 ‘결제 완료’로 바뀐 뒤에만 발급하기로 했습니다. 결제 실패 통보 뒤 늦게 도착한 대기 알림 때문에 상태를 다시 대기로 돌리면 고객 화면이 뒤집힙니다. 개발자는 허용되는 상태 이동과 확인할 결제 번호를 정해, 늦은 알림이 확정 상태를 임의로 덮어쓰지 못하게 합니다.

생각해 볼 질문
주문이 이미 취소되거나 환불된 상태라면 어떤 요청을 허용하고 거절할지 정했나요?

15. 인터페이스 계약 — 프로그램 사이의 입력·출력 규칙을 관리한다

인터페이스 계약은 프로그램끼리 어떤 입력을 보내고 어떤 형식의 결과와 오류를 돌려줄지 정한 약속입니다. 받는 쪽은 그 약속을 기준으로 값을 읽고 다음 일을 합니다.

가격을 숫자로 보내다가 예고 없이 ‘10,000원’이라는 문자열로 바꾸면 앱의 계산이 실패할 수 있습니다. 새 형식이 필요하면 새 항목을 추가하고 기존 방식의 지원 기간과 전환 날짜를 알립니다. 이용하는 프로그램이 바뀌었는지 확인한 뒤 옛 형식을 정리합니다.

가상 업무 예시

가격 응답을 숫자에서 통화 포함 문자열로 바로 바꾸면 앱 계산이 실패할 수 있습니다. 새 필드를 추가하고 기존 소비자가 전환했는지 확인한 후 옛 필드를 정리합니다.

생각해 볼 질문
입력이나 응답 형식을 바꿔도 기존 앱이 계속 동작하나요? 연동하는 팀에게 변경 방법과 전환 기한을 알렸나요?

16. 의존성 관리 — 외부 코드를 제품의 일부로 취급한다

의존성은 프로그램이 실행되기 위해 사용하는 외부 코드나 도구와의 관계입니다. 라이브러리는 자주 쓰는 기능을 모아 재사용하게 만든 코드입니다. 가져다 쓰면 개발 시간을 줄일 수 있지만 그 버전과 변경도 제품의 일부로 관리해야 합니다.

날짜 표시 라이브러리를 업데이트했을 때 시간 계산 방식이 달라질 수 있습니다. 사용한 버전을 기록해 같은 조건으로 다시 만들 수 있게 하고, 업데이트 후 중요한 날짜 계산과 프로그램 크기 등을 확인합니다. 필요하지 않은 기능까지 가져오는 것은 아닌지도 검토합니다.

가상 업무 예시

예약 날짜를 계산하는 외부 라이브러리의 버전을 고정하지 않아, 같은 소스로 다시 배포했는데 다음 달 예약일 계산이 달라졌습니다. 팀은 사용 버전을 기록하고 업데이트를 별도 변경으로 관리합니다. 월말·윤년 날짜를 확인한 뒤 새 버전을 적용하고, 실패하면 확인된 이전 버전으로 다시 빌드합니다.

생각해 볼 질문
외부 라이브러리를 추가하면 어떤 개발 작업을 줄일 수 있나요? 업데이트·보안 점검·용량 증가까지 고려했나요?

17. 설정 분리 — 시험 서버와 실제 서비스의 설정을 구분한다

설정은 접속할 서버 주소나 실행 모드처럼 프로그램의 동작 조건을 정하는 값입니다. 시험 환경과 실제 서비스가 같은 코드를 써도 설정은 달라야 할 수 있습니다.

시험 서버의 기본 결제 주소가 실제 결제 업체를 향하면 시험 주문이 실제 청구로 이어질 수 있습니다. 환경별 설정을 구분하고 필수 값이 없으면 조용히 실제 주소를 쓰지 않도록 합니다. 소스 변경을 빌드·시험으로 이어 주는 지속적 통합(CI) 과정에서도 적용할 설정과 대상을 확인합니다.

가상 업무 예시

시험 서버가 실결제 주소를 기본값으로 쓰면 테스트 주문이 실제 청구가 될 수 있습니다. 환경별 설정을 분리하고 배포 전에 대상 주소를 확인합니다.

생각해 볼 질문
결제 주소 같은 필수 설정이 빠지면 실행을 멈추나요? 시험 환경이 실결제 서버에 연결될 가능성은 없나요?

18. 사용자 경험 — 오류가 나도 작업을 이어 갈 수 있게 돕는다

사용자 경험에는 정상 처리뿐 아니라 오류가 났을 때 작업을 회복하는 과정도 포함됩니다. 무엇을 고쳐야 하는지 모르면 사용자는 같은 실패를 반복하거나 처음부터 다시 작성해야 합니다.

긴 신청서를 보냈는데 첨부 파일 형식이 틀렸다면 이미 입력한 내용을 유지하고 수정할 파일과 허용 형식을 알려 줍니다. 내부 오류 코드를 그대로 표시하는 것보다 사용자가 다음 행동을 결정할 수 있는 정보를 제공해야 합니다.

가상 업무 예시

긴 신청서를 제출할 때 첨부 오류가 났다면 이미 입력한 내용을 보존합니다. 허용 형식과 수정할 파일을 알려 사용자가 처음부터 다시 쓰지 않게 합니다.

생각해 볼 질문
실패한 사용자가 입력을 잃지 않고 다음 행동을 알 수 있습니까?

19. 기술 부채 — 개선을 미룰 때 늘어날 유지보수 비용을 기록한다

기술 부채는 중복 코드나 임시 처리 때문에 나중의 변경과 오류 수정에 더 많은 비용이 드는 상황을 설명하는 말입니다. 오래된 코드라는 이유만으로 모두 기술 부채라고 판단하지는 않습니다.

임시로 여러 곳에 복사한 할인 코드를 매번 함께 고쳐야 한다면 반복 수정 시간과 누락 오류를 기록합니다. 개선에 드는 비용과 앞으로 줄일 부담을 비교하고, 당장 미룬다면 위험과 다시 검토할 시점을 남깁니다.

가상 업무 예시

급한 행사 때문에 할인 조건을 웹·앱·관리자 코드에 복사했습니다. 이후 할인율을 바꿀 때마다 세 곳을 수정해야 했고, 한 곳을 빠뜨려 고객마다 다른 금액이 나왔습니다. 팀은 공통 계산으로 정리하는 데 이틀이 필요하다고 기록하고 다음 할인 행사 전에 개선하기로 했습니다. 임시로 아낀 시간이 이후의 반복 수정과 오류 비용으로 돌아온 상황입니다.

생각해 볼 질문
지금 미룬 개선 때문에 앞으로 어떤 수작업이나 오류 수정이 늘어나나요? 언제 다시 개선할지 기준을 정했나요?

20. 문제 재현 — 추측보다 증거로 원인을 좁힌다

문제 재현은 오류가 난 입력과 환경, 순서를 맞춰 같은 실패를 다시 확인하는 것입니다. 기대 결과와 실제 결과의 차이를 기록하면 무엇을 고쳐야 하는지와 수정이 효과가 있는지 비교할 수 있습니다.

특정 고객의 총액만 다르다면 할인 중복·반올림·통화 설정을 비교합니다. 실패를 만드는 최소 조건을 찾고 수정한 뒤 같은 입력으로 다시 시험합니다. 오류 메시지가 안 보인다는 이유만으로 정상 결과가 나왔다고 판단하지 말고 계산과 저장 결과도 확인합니다.

가상 업무 예시

1만 원 상품에 10% 쿠폰을 적용하면 9천 원이어야 하는데, 같은 쿠폰을 다시 선택하면 8,100원이 됐습니다. 개발자는 ‘상품 선택 → 쿠폰 적용 → 같은 쿠폰 재선택’ 순서로 오류를 재현했습니다. 수정 후 같은 순서에서도 9천 원인지, 쿠폰을 해제하면 1만 원으로 돌아오는지 확인합니다.

생각해 볼 질문
수정 전 실패와 수정 후 성공을 같은 조건에서 확인했습니까?

교재에서 함께 확인할 내용

위 20개 노트는 교재 개념을 업무에 적용하는 길잡이입니다. 다음 이론과 기법은 별도로 읽고 직접 설명하거나 계산해 보세요. 이 목록도 교재 전체를 대신하지는 않습니다.

1. 스택과 큐

스택은 마지막에 넣은 것을 먼저 꺼내는 구조입니다. 접시를 쌓고 위에서 꺼내는 순서를 생각하면 됩니다. 큐는 먼저 넣은 것을 먼저 꺼내는 구조로, 도착 순서대로 처리하는 대기 줄과 같습니다. 교재의 LIFO와 FIFO는 각각 이 두 순서를 뜻합니다.

확인해 보기: A, B, C 순서로 넣었다면 스택과 큐에서 꺼내는 순서는 각각 무엇인가요?

소프트웨어 개발 · 39쪽 →

2. 이진 탐색과 깊이 우선 탐색

이진 탐색은 크기순으로 정렬된 자료에서 중간값을 보고 찾을 범위를 절반씩 줄이는 방법입니다. 1부터 100 중 수를 찾을 때 50보다 큰지 확인하는 식입니다. 깊이 우선 탐색은 연결된 자료의 한 경로를 끝까지 따라간 뒤 돌아와 다른 경로를 살핍니다. 둘은 사용하는 자료의 구조와 탐색 방법이 다릅니다.

확인해 보기: 정렬하지 않은 목록에 이진 탐색을 바로 적용할 수 없는 이유는 무엇인가요?

소프트웨어 개발 · 49쪽 →

3. UML과 디자인 패턴

UML은 프로그램의 구조와 동작을 약속된 기호로 그리는 표현 방법입니다. 어떤 대상들이 연결되는지는 클래스 다이어그램으로, 로그인할 때 메시지가 오가는 순서는 시퀀스 다이어그램으로 표현할 수 있습니다. 디자인 패턴은 반복되는 설계 문제의 해결 구조를 정리한 것으로, 그대로 붙여 넣는 완성 코드라는 뜻은 아닙니다.

확인해 보기: 클래스 간 관계와 객체 간 시간순 메시지를 각각 어떤 다이어그램으로 나타낼까요?

소프트웨어 개발 · 73쪽 →

4. 컴파일러와 인터프리터

컴파일러는 사람이 쓴 소스 코드를 기계어나 중간 코드 같은 다른 코드로 번역합니다. 인터프리터는 프로그램을 해석하면서 실행합니다. 실제 실행 환경은 번역과 해석을 함께 사용하기도 하므로, 특정 언어는 언제나 한 방식만 쓴다고 외우기보다 번역 결과와 실행 과정을 나눠 살펴보세요.

확인해 보기: 소스 코드, 번역 결과, 실행 단계를 나누어 두 방식의 차이를 설명해 보세요.

소프트웨어 개발 · 90쪽 →