3장: 준비는 철저하게: 선행 조건

3장: 준비는 철저하게: 선행 조건

3.1 선행 조건의 중요성

품질은 프로젝트 초반부터 결정됨

• 프로젝트가 성공할 것이냐 아니냐의 상당 부분은 구현을 시작하기 전에 이미 결정된다.
• 고품질 소프트웨어를 만드는 공통점 중 하나는 시작, 중간, 끝 전 과정에서 품질을 신경 쓴다는 점임
  • 끝에서 품질을 강조하면 시스템 테스트 중심이 됨
    • 테스트만으로는 잘못된 제품을 만들었는지, 올바른 제품을 잘못된 방식으로 만들었는지 잡아내지 못함
  • 중간에서 품질을 강조하면 구현 실천법 중심이 됨
  • 시작에서 품질을 강조하면 문제 정의, 요구사항, 설계 자체를 제대로 하는 방향이 됨
• 구현은 프로젝트 한가운데 있음, 구현에 들어갈 때는 이미 앞 단계가 성공과 실패의 토대를 상당 부분 결정한 상태임

최신 소프트웨어 프로젝트에도 선행 조건은 필요함

• 선행 조건의 가장 큰 목적은 위험 감소
• 특히 요구사항 부족과 프로젝트 계획 부족이 가장 흔한 위험
• 선행 조건은 요구사항, 프로젝트 계획을 향상시키는데 중점을 둠.
• 준비 방식은 프로젝트마다 달라지며, 정확한 접근은 3.2에서 다룸

준비가 부족해지는 이유

• 준비가 부족한 이유도 반복됨
  • 선행 작업을 수행할 역량이 부족함
  • 코딩을 빨리 시작하고 싶은 충동이 강함
  • 관리자들이 구현 전 활동의 가치를 이해하지 못함
• 관리자가 코딩만 진짜 작업으로 보면 준비 활동이 압박받기 쉬움

관리자 압박에 대응하는 방법

• 효과적이지 않은 순서로 일하라는 지시를 단호하게 거절할 수 있음
• 실제로는 요구사항과 아키텍처를 다루면서 코딩하는 것처럼 보이는 선택지도 있음
• 개발 프로세스와 선행 조건의 가치를 관리자에게 설명하는 방식이 더 바람직함
• 계속 준비 활동을 인정하지 않는 환경이라면 다른 일을 찾는 것도 선택지임

구현 전 선행 조건을 수행하기 위한 논리적 설득

• 구현 전에 시스템이 무엇을 해야 하고, 어떻게 해야 하는지 이해해야 함
• 큰 프로젝트일수록 더 많은 계획이 필요하고, 작은 프로젝트일수록 계획 수준은 줄어듦
• 관리 관점의 계획은 시간, 인원, 장비를 추정하는 일임
• 기술 관점의 계획은 잘못된 것을 만들지 않도록 무엇을 만들지 이해하는 일임
• 사용자가 처음부터 원하는 것을 정확히 알지 못하더라도, 잘못 만들고 버리는 것보다 요구를 파악하는 비용이 낮음
• 시스템을 어떻게 만들지도 미리 생각해야 불필요한 시행착오와 비용 증가를 줄일 수 있음

구현 전 준비를 설득하는 비유

• 소프트웨어도 집을 짓듯이 도면과 계획을 확인한 뒤 만들어야 함
• 요구사항은 아키텍처에, 아키텍처는 설계에, 설계는 구현에 영향을 줌
• 앞 단계가 오염되면 뒤 단계도 함께 오염됨
• 반복적 프로젝트도 각 반복에서 만들 부분의 핵심 요구사항과 아키텍처 요소는 먼저 확인해야 함
• 주택 단지를 지을 때 모든 집의 세부사항을 몰라도 부지, 하수관, 전기선 같은 기반은 먼저 확인해야 하는 것과 같음

구현 전 준비를 설득하는 데이터

• 결함은 가능한 한 삽입 시점 가까이에서 잡을수록 비용이 낮음
• 요구사항이나 아키텍처 결함은 뒤로 갈수록 비용이 급격히 커짐

표 3-1. 결함 삽입 시점과 발견 시점에 따른 평균 수정 비용

• 요구사항 결함은 시스템에 가장 오래 남을 수 있고, 영향 범위도 넓어 비용이 커지기 쉬움
• 평균적인 프로젝트는 여전히 결함 수정 노력을 후반부에 많이 쓰며, 디버깅과 재작업이 개발 주기의 큰 비중을 차지함
• 결함을 늦게 고치는 대신 일찍 고치도록 집중하면 비용과 일정을 크게 줄일 수 있음

관리자 이해도 점검

• “디버깅할 것이 많으니 바로 코딩해야 한다”는 말은 자기실현적 예언에 가까움
• “테스트에서 결함이 적을 테니 테스트 시간을 줄인다”는 말도 자기실현적 예언에 가까움
• 더 바람직한 목표는 요구사항과 설계를 충분히 검토해서, 코딩과 디버깅 중 큰 문제가 떠오르지 않는 상태임

3.2 작업 중인 소프트웨어의 종류 결정

프로젝트 유형에 맞는 준비 수준

• 프로젝트마다 선행 조건과 구현의 균형이 다름
• 모든 프로젝트가 같은 방식으로 요구사항, 설계, 테스트를 다루면 안 됨
• 대표적으로는 비즈니스 시스템, 미션 크리티컬 시스템, 임베디드 생명-중요 시스템처럼 다른 성격의 프로젝트가 있음

표 3-2. 세 가지 일반적인 소프트웨어 프로젝트 유형에 적합한 대표 실천법

• 비즈니스 시스템은 대체로 반복적 접근과 잘 맞음
• 생명-중요 시스템은 대체로 더 순차적이고 더 형식적인 접근이 필요함

반복적 접근이 선행 조건에 미치는 영향

• 반복적 접근이 선행 조건의 중요성을 없애는 것은 아님
• 반복적 접근은 선행 작업 부족의 비용을 줄일 수는 있어도 없애지는 못함

표 3-3. 선행 조건을 생략했을 때 순차적 프로젝트와 반복적 프로젝트의 영향

• 선행 조건을 무시한 반복적 프로젝트는 비용을 끝에 몰아내지 않을 뿐, 프로젝트 전반에 나눠서 지불하게 됨
• 선행 조건에 집중하면 순차적 접근이든 반복적 접근이든 총비용을 줄일 수 있음

표 3-4. 선행 조건에 집중했을 때 순차적 프로젝트와 반복적 프로젝트의 영향

• 대부분 프로젝트는 완전히 순차적이지도, 완전히 반복적이지도 않음
• 흔한 경험 법칙은 핵심 요구사항 상당수를 먼저 정하고, 나머지는 후속 반복에서 다루는 방식임

순차적 접근과 반복적 접근 선택

• 더 순차적인 접근이 맞는 경우
  • 요구사항이 비교적 안정적임
  • 설계가 단순하고 잘 이해됨
  • 팀이 해당 도메인에 익숙함
  • 프로젝트 위험이 낮음
  • 장기 예측 가능성이 중요함
  • 후반 변경 비용이 큼
• 더 반복적인 접근이 맞는 경우
  • 요구사항이 불안정하거나 잘 모름
  • 설계가 복잡하거나 도전적임
  • 팀이 해당 도메인에 익숙하지 않음
  • 프로젝트 위험이 큼
  • 장기 예측 가능성이 덜 중요함
  • 후반 변경 비용이 낮음
• 핵심은 프로젝트 성격에 맞는 선행 조건 수준을 먼저 결정하는 것임

3.3 문제-정의 선행 조건

• 구현 전에 가장 먼저 완료해야하는 첫번째 선행 조건은 해결할 문제를 분명히 정의하는 일임
• 문제 정의는 해결책이 아니라 문제 자체를 설명해야 함
• 좋은 문제 정의는 보통 1~2페이지 수준의 짧은 문서임

사용자 언어로 작성

• 사용자 언어로 작성되는 편이 좋음
• 기술 용어보다 사용자의 관점에서 문제가 어떻게 보이는지가 중요함
• 예외적으로 컴파일 시간, 개발 도구 결함처럼 컴퓨터 자체가 문제인 경우에는 기술 용어로 표현해도 됨

문제 정의 실패의 대가

• 문제 정의는 요구사항보다 앞에 있음
• 요구사항이 문제를 더 자세히 파고드는 단계라면, 문제 정의는 그 바탕을 만드는 단계임
• 문제를 잘못 정의하면 애초에 잘못된 목표를 향해 구현하게 됨
• 그 대가는 잘못된 문제를 푸는 데 시간과 비용을 쓰고, 정작 올바른 문제는 풀지 못하는 데 있음

3.4 요구사항 선행 조건

공식 요구사항이 필요한 이유

• 요구사항은 소프트웨어가 무엇을 해야 하는지 자세히 기술하는 내용임
  • 기능 결정을 프로그래머가 아니라 사용자 주도로 만들 수 있음
  • 범위와 기대치를 미리 맞출 수 있음
  • 팀 내부 논쟁을 문서로 정리할 수 있음
  • 개발 시작 후의 변경을 줄일 수 있음
• 요구사항 오류는 구현 이후에 발견될수록 매우 비싸짐

안정적 요구사항이라는 환상

• 요구사항이 안정적이기만 하면 이상적이지만, 실제 프로젝트에서는 변동이 흔함
• 요구사항 변경을 없애려 하기보다, 영향을 줄이는 방식이 중요

구현 중 요구사항 변경 다루기

대응 방식 정리

• 요구사항 품질을 먼저 점검
• 변경 비용을 모두가 알게 함
• 변경 절차 마련
• 변화를 수용하는 개발 방식 사용
• 프로젝트 취소
• 프로젝트의 사업성을 주시

체크리스트: 요구사항

구체적인 기능 요구사항

• 모든 입력이 출처, 정확도, 값 범위, 빈도와 함께 명시되어 있는가?
• 모든 출력이 목적지, 정확도, 값 범위, 빈도, 형식과 함께 명시되어 있는가?
• 웹 페이지, 보고서 등 모든 출력 형식이 명시되어 있는가?
• 모든 외부 하드웨어와 소프트웨어 인터페이스가 명시되어 있는가?
• 핸드셰이킹, 오류 검사, 통신 프로토콜을 포함해 모든 외부 통신 인터페이스가 명시되어 있는가?
• 사용자가 수행하려는 모든 작업이 명시되어 있는가?
• 각 작업에 사용되는 데이터와 각 작업의 결과 데이터가 명시되어 있는가?

구체적인 비기능 요구사항

• 필요한 모든 작업에 대해 사용자 관점의 예상 응답 시간이 명시되어 있는가?
• 처리 시간, 데이터 전송률, 시스템 처리량 같은 다른 시간 관련 조건이 명시되어 있는가?
• 보안 수준이 명시되어 있는가?
• 소프트웨어 실패의 결과, 실패로부터 보호해야 할 중요 정보, 오류 감지와 복구 전략을 포함해 신뢰성이 명시되어 있는가?
• 최소 메모리와 여유 디스크 공간이 명시되어 있는가?
• 특정 기능 변경, 운영 환경 변경, 다른 소프트웨어와의 인터페이스 변경에 적응하는 능력을 포함해 유지보수성이 명시되어 » 있는가?
• 성공과 실패의 정의가 포함되어 있는가?

요구사항 품질

• 요구사항이 사용자 언어로 작성되어 있는가? 사용자도 그렇게 생각하는가?
• 각 요구사항이 다른 요구사항과 충돌하지 않는가?
• 견고성과 정확성처럼 경쟁하는 속성 사이의 허용 가능한 절충이 명시되어 있는가?
• 요구사항이 설계를 명시하지 않는가?
• 요구사항의 상세 수준이 비교적 일관적인가? 더 자세히 또는 덜 자세히 써야 할 항목은 없는가?
• 독립된 구현 그룹에 넘겨도 이해할 수 있을 만큼 요구사항이 명확한가? 개발자도 그렇게 생각하는가?
• 각 항목이 문제와 해결책에 관련되어 있는가? 각 항목의 출처를 문제 환경까지 추적할 수 있는가?
• 각 요구사항은 테스트 가능한가? 독립된 테스트로 충족 여부를 판단할 수 있는가?
• 변경 가능성과 각 변경의 가능성을 포함해 요구사항 변경 가능성이 명시되어 있는가?

요구사항 완전성

• 개발 전에 정보를 얻을 수 없는 영역이 있다면, 불완전한 부분이 명시되어 있는가?
• 제품이 모든 요구사항을 만족하면 받아들일 수 있을 만큼 요구사항이 완전한가?
• 모든 요구사항을 편안하게 받아들일 수 있는가? 구현 불가능하지만 고객이나 상사를 달래기 위해 들어간 요구사항을 » 제거했는가?

3.5 아키텍처 선행 조건

아키텍처의 역할

• 소프트웨어 아키텍처는 고수준 설계임
• 세부 설계를 붙들어 주는 큰 틀이고, 시스템의 개념적 일관성을 좌우함
• 좋은 아키텍처는 구현을 쉽게 만들고, 나쁜 아키텍처는 구현을 거의 불가능하게 만들 수 있음
• 아키텍처 결함도 요구사항 결함만큼 후반으로 갈수록 수정 비용이 커짐

일반적인 아키텍처 구성요소

• 프로그램 구조
  • 시스템의 큰 그림, 주요 서브시스템, 책임 배분, 설계 이유가 드러나야 함
• 주요 클래스
• 데이터 설계
  • 주요 데이터 구조, 데이터베이스 조직, 데이터 흐름, 데이터 소유권이 설명되어야 함
• 비즈니스 규칙
• 사용자 인터페이스 설계
• 자원 관리
• 보안
• 성능
  • 속도와 공간 예산이 클래스, 서브시스템, 기능 영역별로 제시되어야 함
• 확장성
  • 시스템이 미래 수요 증가를 어떻게 감당할지 설명해야 함
  • 사용자 수, 데이터 크기, 트랜잭션 규모 증가를 고려해야 함
• 상호운용성
  • 외부 시스템과의 계약, 데이터 형식, 통신 방식이 명확해야 함
• 국제화와 현지화
  • 여러 지역, 언어, 형식 지원이 필요하면 국제화 전략이 포함되어야 함
  • 문자열, 날짜, 숫자, 통화, 정렬 방식 같은 지역별 차이를 고려해야 함
• 입출력
• 오류 처리
  • 오류 처리가 교정 중심인지, 탐지 중심인지 정해야 함
  • 오류 감지가 능동적인지 수동적인지, 오류를 어떻게 전파하고 메시지를 어떻게 처리할지도 정해야 함
  • 예외 처리 사용 방식, 로깅 방식, 예외 포착 위치도 아키텍처에서 다뤄야 함
• 내결함성
  • 시스템이 오류를 감지한 뒤 다시 시도할지, 대체 코드를 사용할지, 투표 알고리즘을 사용할지 같은 전략이 필요할 수 있음
  • 내결함성이 필요한 시스템에서는 이 결정을 구현 후반으로 미루면 위험함
• 기술적 실현 가능성
  • 위험한 기술 요소는 프로토타입이나 실험으로 확인하는 편이 좋음
• 과설계
  • 아키텍처가 필요 이상으로 복잡하지 않은지 확인해야 함
• 구매 대 개발 결정
  • 직접 만들 것과 구매하거나 가져다 쓸 것을 구분해야 함
• 재사용 결정
• 변경 전략
  • 예상 가능한 변경을 아키텍처가 수용할 수 있어야 함
  • 변경 영향이 소수의 클래스나 모듈에 제한되도록 설계해야 함

일반적인 아키텍처 품질

• 좋은 아키텍처는 개념적으로 한 덩어리로 맞물려야 함
• 목표가 분명해야 하고, 중요한 결정의 이유도 설명 가능해야 함
• 구현자 입장에서 이해 가능하고 납득 가능한 구조여야 함
• 아키텍처가 부실하면 올바른 문제를 잘못된 방식으로 풀게 될 수 있음

체크리스트: 아키텍처

구체적인 아키텍처 주제

• 좋은 아키텍처 개요와 정당화를 포함해 프로그램의 전체 조직이 명확한가?
• 주요 빌딩 블록의 책임 영역과 다른 빌딩 블록과의 인터페이스가 잘 정의되어 있는가?
• 요구사항에 나열된 모든 기능이 너무 많지도 적지도 않은 빌딩 블록으로 합리적으로 다뤄지는가?
• 가장 중요한 클래스가 설명되고 정당화되어 있는가?
• 데이터 설계가 설명되고 정당화되어 있는가?
• 데이터베이스 조직과 내용이 명시되어 있는가?
• 핵심 비즈니스 규칙이 모두 식별되고, 시스템에 미치는 영향이 설명되어 있는가?
• 사용자 인터페이스 설계 전략이 설명되어 있는가?
• 사용자 인터페이스가 변경되어도 나머지 프로그램에 영향을 주지 않도록 모듈화되어 있는가?
• I/O 처리 전략이 설명되고 정당화되어 있는가?
• 스레드, 데이터베이스 연결, 핸들, 네트워크 대역폭 같은 부족한 자원에 대한 사용 추정과 관리 전략이 설명되고 정당화되어 » 있는가?
• 아키텍처의 보안 요구사항이 설명되어 있는가?
• 각 클래스, 서브시스템, 기능 영역에 대한 공간과 속도 예산이 정해져 있는가?
• 확장성을 어떻게 달성할지 아키텍처가 설명하는가?
• 상호운용성을 다루는가?
• 국제화/현지화 전략이 설명되어 있는가?
• 일관된 오류 처리 전략이 제공되어 있는가?
• 필요한 경우 내결함성 접근이 정의되어 있는가?
• 시스템의 모든 부분에 대한 기술적 실현 가능성이 확인되어 있는가?
• 과설계에 대한 접근이 명시되어 있는가?
• 필요한 구매 대 개발 결정이 포함되어 있는가?
• 재사용 코드가 다른 아키텍처 목표에 어떻게 맞춰질지 설명되어 있는가?
• 예상 가능한 변경을 수용하도록 설계되어 있는가?

일반적인 아키텍처 품질

• 아키텍처가 모든 요구사항을 반영하는가?
• 과설계되거나 과소설계된 부분은 없는가? 그런 기대치가 명시되어 있는가?
• 전체 아키텍처가 개념적으로 잘 맞물리는가?
• 최상위 설계가 구현에 사용할 기계와 언어에 독립적인가?
• 모든 주요 결정의 동기가 제공되어 있는가?
• 시스템을 구현할 프로그래머로서 이 아키텍처에 납득하고 편안함을 느끼는가?

3.6 선행 조건에 소요되는 시간

선행 조건에 배정할 시간

• 문제 정의, 요구사항, 아키텍처, 초기 계획에는 프로젝트 노력의 대략 10~20%, 일정의 20~30% 정도를 쓰는 것이 일반적임
• 상세 설계는 포함되지 않음, 상세 설계는 구현의 일부

• 요구사항이 불안정한 프로젝트라면, 요구사항 정리 자체를 별도 프로젝트처럼 다루는 편이 합리적일 수 있음
• 무엇을 만들지도 모르는데 전체 일정을 정확히 추정하는 것은 무리임

• 아키텍처에도 비슷한 원칙이 적용됨
• 낯선 도메인이거나 기술 불확실성이 크면, 아키텍처에 더 많은 시간을 배정해야 함
• 선행 조건에 시간을 쓰는 일은 구현 시간을 빼앗는 낭비가 아니라, 구현 재작업을 줄이는 투자에 가까움

체크리스트: 상위 선행 조건

• 작업 중인 소프트웨어 프로젝트의 종류를 식별하고, 그에 맞게 접근 방식을 조정했는가?
• 구현을 시작하기에 요구사항이 충분히 잘 정의되고 안정적인가?
• 구현을 시작하기에 아키텍처가 충분히 잘 정의되어 있는가?
• 프로젝트 고유의 다른 위험을 다뤄서 구현이 불필요하게 큰 위험에 노출되지 않게 했는가?

참고 자료

요구사항

• Karl Wiegers, Software Requirements, 2nd ed.

  요구사항 수집, 분석, 명세, 검증, 관리까지 요구사항 작업 전반을 실무적으로 다루는 책.

• Suzanne Robertson, James Robertson, Mastering the Requirements Process

  더 고급 요구사항 실무자를 위한 대안 자료.

• Tom Gilb, Competitive Engineering

  Planguage 요구사항 언어와 요구사항 공학, 설계 평가, 진화적 프로젝트 관리를 다룸.

• IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications

  소프트웨어 요구사항 명세서에 무엇을 포함할지와 여러 명세서 개요를 제시하는 IEEE-ANSI 가이드.

• Alain Abran et al., Swebok: Guide to the Software Engineering Body of Knowledge

  소프트웨어 요구사항 지식 영역을 자세히 설명하는 자료.

• Soren Lauesen, Software Requirements: Styles and Techniques

  요구사항 작성 스타일과 기법을 다루는 대안 자료.

• Benjamin L. Kovitz, Practical Software Requirements: A Manual of Content and Style

  요구사항 문서의 내용과 표현 방식을 실무적으로 다루는 자료.

• Alistair Cockburn, Writing Effective Use Cases

  유스케이스를 효과적으로 작성하는 방법을 다루는 자료.

소프트웨어 아키텍처

• Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, 2nd ed.

  소프트웨어 아키텍처를 실제 프로젝트 관점에서 다루는 대표 자료.

• Frank Buschmann et al., Pattern-Oriented Software Architecture, Volume 1: A System of Patterns

  패턴 기반으로 소프트웨어 아키텍처를 설명하는 자료.

• Paul Clements, ed., Documenting Software Architectures: Views and Beyond

  여러 관점에서 소프트웨어 아키텍처를 문서화하는 방법을 다룸.

• Paul Clements, Rick Kazman, Mark Klein, Evaluating Software Architectures: Methods and Case Studies

  아키텍처 평가 방법과 사례를 다루는 자료.

• Martin Fowler, Patterns of Enterprise Application Architecture

  엔터프라이즈 애플리케이션 아키텍처 패턴을 다루는 자료.

• Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified Software Development Process

  통합 소프트웨어 개발 프로세스를 깊게 다루는 자료.

• IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems

  소프트웨어 중심 시스템의 아키텍처 명세 작성에 관한 IEEE-ANSI 가이드.

일반적인 소프트웨어 개발 접근

• Steve McConnell, Software Project Survival Guide

  선행 계획, 요구사항 개발, 아키텍처 작업 뒤에 신중한 프로젝트 실행을 이어 가는 접근을 제시.

• Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed.

  아키텍처 중심, 유스케이스 중심의 프로젝트 접근을 설명.

• Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified Software Development Process

  Rational Unified Process 관련 주제를 더 깊게 다루는 자료.

• Kent Beck, Extreme Programming Explained: Embrace Change

  요구사항과 설계를 구현과 함께 반복적으로 발전시키는 고유연성 접근을 설명.

• Tom Gilb, Principles of Software Engineering Management

  핵심 계획, 요구사항, 아키텍처 이슈를 초기에 탐색하고 프로젝트 진행 중 계속 조정하는 접근을 다룸.

• Steve McConnell, Rapid Development

  프로젝트 특성에 맞게 계획 도구를 조합하는 도구 상자식 접근을 제시.

• Barry Boehm, Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed

  애자일 접근과 계획 중심 접근의 균형을 위험 관점에서 비교하는 자료.

• Craig Larman, Agile and Iterative Development: A Manager’s Guide

  Scrum, Extreme Programming, Unified Process, Evo를 포함한 반복적 개발 스타일을 개관하는 자료.

요점 정리

• 구현 준비의 최상위 목표는 위험 감소이다.
• 고품질 소프트웨어를 만들려면 품질은 처음부터 끝까지 전 과정에 포함되어야 하며, 특히 초반 품질 활동의 영향이 크다.
• 프로그래머의 역할에는 구현 전 준비의 중요성을 주변 사람들에게 설명하는 일도 포함된다.
• 프로젝트 종류에 따라 필요한 선행 조건 수준이 달라지며, 어떤 프로젝트는 반복적 접근이, 어떤 프로젝트는 더 순차적인 접근이 맞는다.
• 좋은 문제 정의가 없으면 구현 단계에서 잘못된 문제를 풀 수 있다.
• 좋은 요구사항 작업이 없으면 중요한 세부사항을 놓칠 수 있으며, 요구사항 변경은 구현 이후로 갈수록 비용이 크게 늘어난다.
• 좋은 아키텍처가 없으면 올바른 문제를 잘못된 방식으로 풀 수 있으며, 코드가 쌓일수록 아키텍처 변경 비용도 커진다.
• 자기 프로젝트에서 선행 조건이 어떤 방식으로 다뤄졌는지 이해하고, 그에 맞는 구현 접근을 선택해야 한다.