30장: 프로그래밍 도구

30장: 프로그래밍 도구

  • 프로그래밍 도구는 반복 작업, 실수, 피드백 지연을 줄여 개발자가 설계와 문제 해결에 집중하도록 돕는 수단임.
  • 도구의 가치는 기능 수가 아니라 개발 과정의 어떤 비용과 위험을 줄이는지로 판단함.
  • 저자는 좋은 도구 모음과 도구 숙련도가 구현 시간을 줄이고 생산성을 높일 수 있다고 봄.
  • 모든 도구를 쓰라는 뜻은 아님. 실제 사용의 대부분은 일부 핵심 도구에 집중되므로, 놓치고 있는 유용한 도구가 있는지 의식적으로 점검하고 프로젝트에 맞게 선택해야 함.
  • 이 장은 요구사항·관리 도구가 아닌 구현 도구만 다루며, 제품명보다 도구의 종류와 쓰임을 설명함.

30.1 설계 도구

그래픽 기반 설계 도구

  • UML, 아키텍처 블록 다이어그램, 계층도, ERD, 클래스 다이어그램 등을 표현하는 도구가 있음.
  • 일부 도구는 더 넓은 기능을 가진 CASE(Computer-Aided Software Engineering, 컴퓨터 지원 소프트웨어 공학) 도구에 포함되거나, 독립적인 설계 도구로 제공됨.
    • CASE 도구는 설계 다이어그램 작성 외에도 소프트웨어 개발 활동을 폭넓게 지원하는 도구 묶음을 뜻함.

단순 그림 도구와의 차이

  • 펜이나 일반 그래픽 도구로도 같은 다이어그램을 그릴 수 있음.
  • 설계 도구는 요소를 추가·삭제할 때 연결선과 하위 요소를 자동으로 정리하고, 높은 추상화 수준과 낮은 추상화 수준 사이를 이동하게 도움.
  • 설계의 일관성을 검사하며, 일부 도구는 설계에서 코드를 생성할 수 있음.

30.2 소스 코드 도구

코드 작성과 탐색

IDE와 편집기
  • 코드를 작성하고 탐색하며, 언어 문법에 맞는 색상 표시·자동 완성·컴파일·디버깅을 지원하는 기본 도구임.
다중 파일 문자열 검색과 바꾸기
  • 여러 파일에서 클래스·루틴 이름이나 유사 결함을 찾고 바꿈. 정규 표현식으로 복잡한 패턴도 검색할 수 있음.
차이 비교 도구(Diff)
  • 두 버전의 차이를 보여 주어 변경 내용과 결함의 원인을 확인하게 함.
병합 도구(Merge)
  • 여러 사람이 동시에 수정한 변경을 자동으로 합치고, 충돌한 부분의 해결을 지원함.
소스 코드 정돈 도구
  • 들여쓰기, 주석, 이름의 표시 형식 등을 일관되게 맞춤. 출력만 정돈하는 도구와 실제 소스 파일을 바꾸는 도구가 있음.
인터페이스 문서화 도구
  • 소스 코드의 태그가 붙은 주석에서 프로그래머용 인터페이스 문서를 추출해 형식화함. Javadoc이 대표적인 예임.
템플릿
  • 루틴 주석, 클래스, 파일, 반복문처럼 자주 쓰는 코드 골격을 빠르고 일관되게 삽입함.
참조 도구(Cross-reference)
  • 변수와 루틴의 사용 위치를 목록으로 만들어 변경 영향과 코드의 사용처를 파악하게 함.
클래스 계층 구조 생성기
  • 상속 트리를 생성해 코드 구조를 분석하고 패키지나 하위 시스템을 나누는 데 도움.

코드 품질 분석

엄격한 문법·의미 검사기
  • 컴파일러가 허용하지만 의도와 다를 가능성이 있는 초기화 누락, 사용하지 않는 변수, 의심스러운 비교 등을 찾음.
메트릭 보고 도구
  • 복잡도, 결함, 변경 빈도 등을 보고해 추가 리뷰·테스트·재설계가 필요한 이상치를 찾게 함.

소스 코드 리팩터링

리팩터링 도구
  • 이름 바꾸기, 메서드 추출처럼 동작을 유지하며 구조를 바꾸는 작업의 위험과 비용을 낮춤.
구조 개선 도구 (재구성 도구)
  • goto가 많은 비구조적 코드를 더 구조화된 코드로 변환함. 변환 결과도 원래의 나쁜 논리까지 고치지는 못함.
코드 변환기
  • 대규모 코드베이스를 다른 언어로 옮기는 데 도움. 나쁜 코드는 낯선 언어의 나쁜 코드가 될 뿐임.

버전 관리

  • 소스 코드, 의존성, 프로젝트 문서의 여러 버전을 관리하고, 요구사항 변경이 영향을 주는 코드와 테스트를 추적하게 함.

데이터 사전

  • 프로젝트의 중요한 데이터 정의를 모아 둔 데이터베이스임. 대규모 프로젝트에서는 데이터베이스 스키마·클래스 정의·이름의 충돌과 의미 차이를 관리하는 데 유용함.

30.3 실행 코드 도구

코드 생성

컴파일러와 링커
  • 컴파일러는 소스 코드를 실행 코드로 바꾸고, 링커는 객체 파일과 필요한 라이브러리를 연결해 실행 파일을 만듦.
  • 여러 언어의 객체 파일을 연결해 각 부분에 적합한 언어를 선택할 수도 있음.
    • 예: C로 만든 프로그램에 C++ 모듈이나 Fortran 수치 연산 라이브러리를 함께 연결하는 방식임. 단, 객체 파일 형식과 호출 규약이 호환되어야 함.
    • 오늘날에는 하나의 주 언어와 패키지 관리자를 쓰는 경우가 많고, 언어 간 연결도 API·FFI·네이티브 플러그인 형태로 처리하는 일이 일반적임. 다만 게임 엔진 플러그인이나 시스템·고성능 라이브러리에서는 이 개념이 여전히 쓰임.
      • API(Application Programming Interface): 다른 코드가 기능을 호출할 수 있도록 정한 함수, 데이터 형식, 호출 규칙임. 예: 웹 서버가 제공하는 로그인 요청 API.
      • FFI(Foreign Function Interface): 한 언어에서 다른 언어로 작성·컴파일된 함수나 라이브러리를 호출하게 하는 연결 방식임. 예: C#에서 DllImport로 C/C++ 함수 호출.
      • 네이티브 코드·플러그인: 특정 운영체제·CPU에서 직접 실행되도록 컴파일한 코드이며, 주로 C/C++로 작성된 라이브러리를 앱이나 엔진에서 연결한 것을 뜻함. 예: Unity 프로젝트가 Android·iOS용 C/C++ SDK 플러그인을 사용하는 경우.
빌드 도구
  • 소스 파일의 의존성을 확인해 필요한 대상만 다시 빌드하고, 서로 다른 버전의 소스가 섞여 생기는 문제를 줄임.
  • 의존성 분석보다 전체 빌드가 더 빠른 환경도 있으므로, 실제 빌드 시간을 측정해 방식을 선택함.
    • 원문은 Microsoft Word 팀이 소스 구조를 최적화한 뒤 수백만 줄 전체를 약 13분에 다시 빌드해, 의존성 검사보다 빠르게 처리한 사례도 듦.
코드 라이브러리
  • 모든 코드를 직접 쓰기보다 검증된 라이브러리를 재사용해 개발 시간과 품질을 개선함.
    코드 생성 마법사
  • 데이터베이스, UI, 컴파일러 등의 반복적인 코드를 생성하며, 빠른 프로토타입과 설계 실험에 특히 유용함.
  • 생성 코드는 읽기 어려울 수 있으므로 장기 유지보수가 필요한 경우에는 비용을 검토함.
설정과 설치
  • 외부 벤더가 설치 프로그램을 만드는 도구를 제공하며, 개발팀은 이 도구로 배포용 설치 프로그램을 구성함.
  • 이 도구는 대상 기기에 공용 라이브러리가 이미 있는지와 버전이 맞는지 확인하고, 설치 매체나 웹 설치 절차를 지원함.
    • 예: 데스크톱 프로그램 설치기가 실행에 필요한 공용 런타임 라이브러리의 설치 여부와 버전을 확인한 뒤, 없거나 오래된 경우 함께 설치하거나 업데이트함.
전처리기
  • 개발용 디버깅 코드를 제품 코드에서 쉽게 켜고 끄거나, 여러 환경을 대상으로 빌드하는 데 사용함.
  • 언어에 전처리기가 없어도 빌드 과정에 독립 전처리기를 넣을 수 있음.

디버깅

  • 테스트 비계(test scaffolding): 아직 연결되지 않은 부분을 대신하는 stub, 특정 코드를 호출하는 driver처럼 테스트·디버깅을 위해 임시로 만드는 보조 코드임.

컴파일러 경고, diff, 실행 프로파일러, 추적 모니터, 대화형 디버거 등 나머지 디버깅 도구 목록은 책을 참고.

테스트

  • 심볼릭 디버거(symbolic debugger): 기계어 주소 대신 소스 코드의 파일·줄·변수·함수 이름을 기준으로 실행을 멈추고 값을 살펴보게 하는 디버거임.
  • 테스트 비계(test scaffolding): 실제 시스템의 일부를 대신하거나 테스트 대상을 호출·관찰하기 위해 만드는 stub, driver 등의 보조 코드임.
  • 결함 주입 도구(defect-injection tool): 메모리 부족, 통신 실패 같은 오류를 의도적으로 만들어, 시스템이 비정상 상황을 안전하게 처리하는지 시험함.
  • 결함 추적 소프트웨어(defect-tracking software): 발견한 결함의 내용, 상태, 담당자, 수정 이력 등을 기록해 해결 과정을 관리함.

자동화 테스트 프레임워크·생성기, 테스트 기록·재생, 커버리지 측정 등 나머지 테스트 지원 도구 목록은 책을 참고.

코드 튜닝

실행 프로파일러
  • 실행 중 문장·경로별 실행 횟수와 시간을 보여 주어, 튜닝 우선순위를 찾게 함.
어셈블리 목록과 디스어셈블러
  • 컴파일러가 만든 기계어·어셈블리 코드를 확인해, 고수준 코드가 예상과 다르게 실행되는 이유와 컴파일 결과의 효율을 분석함.

30.4 도구 지향적인(중심) 환경

작고 조합 가능한 도구

아래와 같은 개발 환경은 도구 중심 프로그래밍에 더 적합함.

  • UNIX 환경은 grep, diff, sort, make, lint, sed, awk, vi처럼 작고 역할이 분명한 도구를 조합하는 방식으로 유명함.
  • C와 C++의 표준 라이브러리도 작은 함수를 조합해 더 큰 기능을 만든다는 점에서 같은 철학을 가짐.

다른 환경에서의 활용

  • 일부 개발자는 Windows 같은 다른 환경에서도 UNIX와 비슷한 도구를 사용함.

저자는 작은 도구를 연결해 작업 흐름을 만드는 방식을 강조함.

30.5 직접 프로그래밍 도구 만들기

직접 만드는 도구의 가치

  • 반복 작업이라면 작업 자체를 매번 처리하기보다, 도구를 만들어 이후 작업 시간을 줄이는 편이 더 나을 수 있음.
  • 대규모 조직은 내부 도구·지원 조직을 두며, 시중 도구보다 자사 업무에 더 잘 맞는 요구사항·설계 도구를 만들기도 함.
  • 다만 직접 만드는 일이 항상 비용 효과적인 것은 아니므로, 반복 횟수와 도구 제작 비용을 비교함.

프로젝트 전용 도구

  • 중대형 프로젝트는 특별한 테스트 데이터 생성, 데이터 파일 품질 검증, 아직 없는 하드웨어 모사처럼 프로젝트에만 필요한 도구가 필요할 수 있음.
  • 원문 사례처럼 비행 중 수집한 데이터를 분석하거나, 글꼴 데이터 오류와 표시 소프트웨어 오류를 구분하고, 보험료 계산 결과를 별도 계산기로 검증하는 데 활용함.
  • 프로젝트 계획 단계에서 필요한 전용 도구를 미리 생각하고 제작 시간을 배정함.

스크립트

  • 스크립트는 반복 명령을 자동화하는 작은 도구이며, 환경에 따라 레이아웃 파일이나 매크로라고도 함.
  • 컴파일·링크 순서, 백업 명령, 긴 매개변수가 필요한 명령처럼 자주 반복하는 작업이 대상임.
  • 하루에 여러 번 입력하는 긴 명령은 스크립트 후보임. 입력 실수를 줄이고 정해진 순서의 작업을 빠뜨리지 않게 함.

30.6 도구에 대한 환상

프로그래밍을 없앤다는 약속

  • 도구 공급자와 업계 평론가는 오랫동안 새 도구가 프로그래밍 자체를 없앨 것이라고 약속해 왔음.
  • FORTRAN, 4세대 언어, 자동 프로그래밍, CASE, 시각 프로그래밍은 모두 생산성을 높였지만 프로그래머를 없애지는 못했음.

도구가 실제로 하는 일

  • 도구는 코드 정렬, 편집·컴파일·링크·실행, 중괄호 불일치 탐색, 표준 UI 생성처럼 반복적이고 우연한 어려움을 줄임.
  • 이런 개선을 곧바로 프로그래밍의 소멸로 확대 해석하지 말아야 함. 도구는 점진적인 생산성 향상을 제공함.

프로그래밍이 남는 이유

  • 현실 문제를 컴퓨터가 풀 수 있는 형태로 바꾸고, 순서·의존성·예외를 엄밀하게 생각하며, 불명확한 요구사항·외부 인터페이스·규정·업무 규칙을 다루는 일은 남음.
  • 따라서 좋은 도구가 있어도 현실 문제와 컴퓨터 사이를 연결하는 사람, 즉 프로그래머는 계속 필요함.

체크리스트: 프로그래밍 도구

  • 소스 제어·빌드·테스트·디버깅과 연결되는 효과적인 IDE를 갖추었는가?
  • 반복적인 리팩터링을 자동화하고, 소스·요구사항·설계·계획 산출물을 버전 관리하는가?
  • 대규모 프로젝트에서 클래스의 권위 있는 정의를 관리할 데이터 사전 또는 중앙 저장소가 있는가?
  • 직접 작성하는 대신 사용할 수 있는 코드 라이브러리를 검토했는가?
  • 대화형 디버거와 의존성 제어 빌드 도구를 사용해 빠르고 신뢰성 있게 개발하는가?
  • 테스트 환경에 자동화 프레임워크·생성기·커버리지 도구·시스템 교란 도구·diff·결함 추적 도구가 있는가?
  • 프로젝트 특유의 반복 작업을 줄일 전용 도구나 스크립트를 만들었는가?

참고 자료

  • 앤드루 헌트·데이비드 토머스, The Pragmatic Programmer (Addison-Wesley, 2000): 편집기, 코드 생성, 디버거, 소스 제어를 포함한 프로그래밍 도구를 다룸.
  • 스티븐 본니컬스, “Building Better Software with Better Tools,” IEEE Computer (2003년 9월): IBM·Microsoft Research·Sun Research의 도구 연구를 살핌.
  • 로버트 L. 글래스, Software Conflict (Yourdon Press, 1991): 개발자에게 필요한 최소 도구 집합을 제안함.
  • 케이퍼스 존스, Estimating Software Costs (McGraw-Hill, 1998); 배리 보임 외, Software Cost Estimation with COCOMO II (Addison-Wesley, 2000): 도구 사용이 생산성에 미치는 영향을 다룸.

요점 정리

  • 유용한 도구는 수년간 발견하지 못할 수 있으므로, 개발 환경에 빠진 핵심 도구가 없는지 의식적으로 살펴야 한다.
  • 편집, 정적 분석, 리팩터링, 버전 관리, 디버깅, 테스트, 튜닝을 지원하는 도구를 사용할 수 있다.
  • 프로젝트에 특화된 반복 작업은 전용 도구와 스크립트로 자동화할 수 있다.
  • 좋은 도구는 개발의 지루한 부분을 줄이고 프로그래밍의 모습은 바꾸지만, 현실 문제를 엄밀한 컴퓨터 작업으로 바꾸는 프로그래밍 자체를 없애지는 못한다.

results matching ""

    No results matching ""