개발 환경·IDE·컴파일러·빌드·형상·설정 관리 | 정보처리기사 필기

개발 환경은 하드웨어·운영체제·런타임·개발 도구를 포함한다. IDE, 번역 도구, 빌드 도구의 역할을 구분하고 웹 서버·WAS·DB 서버·패키지의 관계와 환경 설정의 기본 원칙을 이해한다.

그림으로 확인하기

전처리→컴파일→어셈블→링크. 구문 오류와 외부 심벌 오류는 다른 단계다.

개발 환경과 개발 도구

개발 환경은 소스 코드를 작성하는 편집기만 뜻하지 않는다. 하드웨어, 운영체제, 언어 런타임, 라이브러리·프레임워크, 컴파일러나 인터프리터, 빌드·테스트 도구 등이 함께 프로그램을 개발하고 실행할 수 있는 조건을 이룬다. 같은 소스라도 런타임이나 라이브러리 버전, 운영체제 설정이 다르면 결과가 달라질 수 있으므로 필요한 버전과 의존 관계를 명확히 관리해야 한다.

개발 환경의 구성은 다음과 같이 묶어 볼 수 있다.

하드웨어 환경: 개발자 PC, 서버, 저장장치, 네트워크 장비
소프트웨어 플랫폼: 운영체제, DBMS, 미들웨어, 언어 런타임
개발 지원 도구: IDE, 컴파일러·인터프리터, 빌드·테스트 도구, 버전 관리 도구

Eclipse, IntelliJ IDEA, Visual Studio 등은 대표적인 IDE이고, GCC·Clang·javac 등은 소스 번역에 사용되는 대표 도구이다. 제품명만 외우기보다 각 도구가 맡는 역할을 기준으로 분류해야 한다.

구분	주된 역할	시험에서의 판별 기준
통합 개발 환경(IDE)	코드 편집, 탐색, 실행, 디버깅 등 여러 기능을 통합	컴파일러나 빌드 도구를 포함하거나 호출할 수 있지만 그 자체와 같은 개념은 아님
컴파일러(Compiler)	소스 프로그램을 분석하여 더 낮은 수준의 목적 프로그램으로 번역	구문·의미 분석과 코드 생성이 중심
어셈블러(Assembler)	어셈블리 코드를 기계어 명령이 담긴 목적 파일로 변환	목적 파일은 아직 실행 파일이 아닐 수 있음
링커(Linker)	여러 목적 파일과 라이브러리를 결합하고 외부 참조를 해결	링크가 끝나야 실행 파일이나 라이브러리가 완성됨
빌드 도구(Build Tool)	의존 관계에 따라 컴파일·링크·테스트·패키징 작업을 자동화	번역 도구를 직접 대체하기보다 여러 작업을 순서대로 실행·관리

인터프리터는 실행 시점에 프로그램을 해석하며 실행하는 방식으로 설명되는 경우가 많다. 다만 실제 언어 구현은 바이트코드나 JIT 컴파일을 함께 사용할 수 있으므로, 언어 이름만 보고 번역 방식이 하나뿐이라고 단정하지 않는다.

전처리부터 링크까지

C 계열 도구 체인의 대표 흐름은 다음과 같다.

소스 파일 → 전처리 결과 → 어셈블리 코드 → 목적 파일 → 실행 파일

단계	핵심 처리	대표 산출물
전처리	`#include`, `#define`과 같은 전처리 지시문 처리	전처리된 소스
컴파일	구문·의미 검사, 최적화, 어셈블리 코드 생성	어셈블리 코드
어셈블	어셈블리 명령을 기계어로 변환	목적 파일(Object File)
링크	목적 파일·라이브러리 결합, 외부 심벌 주소 해결	실행 파일 또는 라이브러리

교재에서는 위 번역 과정을 넓은 의미의 ‘컴파일’로 묶어 설명하기도 한다. 그러나 단계와 오류 발생 지점을 묻는 문제에서는 각 도구의 입력·출력을 분리해야 한다.

예를 들어 함수 선언은 확인되지만 실제 함수 구현이 링크 대상에 없으면 소스의 구문 검사는 통과할 수 있어도 링크 단계에서 미정의 심벌 오류가 발생할 수 있다. 따라서 컴파일 성공이 링크 성공이나 실행 성공을 보장하지는 않는다.

빌드·배포·형상 관리의 구분

빌드는 소스와 자원을 실행 파일·라이브러리·배포 패키지로 만드는 과정이다. 컴파일은 그 일부이며, 필요하면 링크·테스트·패키징도 포함한다. 배포는 만들어진 산출물을 실행 환경에 설치·반영하는 과정이다.

도구	구분할 특징
Make	Makefile의 대상과 의존 관계에 따라 필요한 작업 실행
Ant	XML 기반의 타깃·태스크로 작업 구성
Maven	POM과 정해진 빌드 생명주기, 의존성 관리
Gradle	Groovy 또는 Kotlin DSL을 이용한 빌드 작업·의존성 관리

형상 관리는 소스·문서·설정 등 산출물의 구성과 변경을 통제하는 활동이고, 버전 관리는 변경 이력과 버전을 관리하는 그 일부이다. 기본 흐름은 형상 식별, 변경 통제, 상태 기록, 형상 감사로 이해한다. 기준선은 공식적으로 합의된 상태이며 이후에도 승인된 절차를 거쳐 변경할 수 있다.

중앙 집중형 SVN은 중앙 저장소를 중심으로 이력을 관리하고, 분산형 Git은 로컬 저장소에서도 이력 관리와 커밋이 가능하다. 분산형도 협업용 원격 저장소를 사용할 수 있다. 커밋은 변경 상태를 기록하고, 브랜치는 작업 흐름을 나누며, 병합은 분리된 변경을 합친다.

웹 서버·WAS·DB 서버

구성 요소	주요 역할	예
웹 서버	HTTP 요청 수신, 정적 파일 응답, 다른 서버로 요청 전달	Apache HTTP Server, Nginx
WAS	서버 측 프로그램 실행과 동적 결과 생성	Tomcat 등 웹 애플리케이션 실행 환경
DB 서버	데이터를 저장·조회·변경하고 동시 접근과 무결성 관리	MySQL, PostgreSQL, Oracle Database

전형적인 처리 흐름은 클라이언트 → 웹 서버 → WAS → DB 서버이며, DB 조회 결과를 이용해 WAS가 응답을 만든다. 요청에 따라 DB 접근이 없을 수도 있다. 이것은 역할 구분이지 반드시 물리적 컴퓨터 세 대가 필요하다는 뜻은 아니다. 한 제품이 여러 역할을 수행할 수도 있다.

개발환경 구축에서는 운영체제·런타임·서버의 호환성, 서비스 포트, DB 접속 대상, 계정 권한, 필요한 라이브러리를 확인한다. 웹 서버가 정상 실행되더라도 DB 주소나 권한이 잘못되면 DB를 이용하는 요청은 실패할 수 있다.

패키지와 라이브러리

라이브러리는 프로그램이 재사용하는 함수·클래스 등의 모음이다. 패키지는 문맥에 따라 관련 코드의 묶음이나 설치·배포 가능한 소프트웨어 단위를 뜻한다. 예를 들어 Java 패키지는 클래스의 이름 공간을 조직하며, 운영체제 패키지는 실행 파일·설정·의존성 정보를 묶어 배포한다.

패키지 관리 도구는 설치·업데이트·제거와 의존성 관리를 돕는다. A 패키지를 실행하는 데 B 라이브러리가 필요하면 B는 A의 의존성이다. 패키지 관리와 운영체제 프로세스 스케줄링은 서로 다른 기능이다.

실행 환경 설정

DB 주소·포트·로그 수준처럼 환경에 따라 다른 값은 설정 파일, 환경 변수, 실행 인자 등으로 전달할 수 있다. 소스에 값이 고정되어 있으면 환경을 바꿀 때 코드를 수정하고 다시 빌드해야 할 수 있다.

환경 변수 PATH는 실행 파일을 찾는 경로에 영향을 준다. 환경 변수에 비밀번호를 넣었다고 자동 암호화되는 것은 아니다. 소스 저장소와 로그에 비밀값을 노출하지 않는다. 설정 적용 우선순위는 프로그램마다 다르므로 모든 시스템에 공통된 순서로 암기하지 않는다.

디버거로 실행 상태 확인

디버거는 프로그램의 실행을 제어하면서 현재 변수값과 호출 위치를 관찰하는 도구이다. 컴파일러가 소스의 문법·형 규칙을 검사하는 역할, 링커가 외부 심벌을 연결하는 역할과 구분한다.

중단점은 지정한 위치나 조건에서 실행을 멈추게 한다. 단계 실행은 문장이나 함수 호출 단위로 실행을 진행하며, 변수 검사와 호출 스택 검사는 그 시점의 값과 호출 경로를 확인한다. 함수 안으로 들어가는 실행과 함수 호출을 한 단계로 넘기는 실행은 관찰하는 범위가 다르다. 중단점을 만들었다고 오류를 자동 수정하거나 실행 결과가 올바름을 증명하는 것은 아니다.

로그는 실행 중 남긴 사건 기록을 나중에 볼 수 있게 하고, 디버거는 실행을 멈춘 상태에서 조사할 수 있게 한다. 여러 스레드가 실행되는 프로그램을 정지시키면 실행 시점이 바뀔 수 있으므로, 관찰 결과를 모든 실행의 고정 순서로 일반화하지 않는다.