범위가 넓은 실기시험은 모든 내용을 똑같이 외우는 방식보다
프로그래밍·SQL·핵심 이론을 연결해 답을 직접 쓰는 연습이 중요합니다
정보처리기사 실기는 정보처리 실무를 평가하는 필답형 시험입니다. 2026년 적용 출제기준이 별도로 마련되어 있으며 시험시간은 2시간 30분, 합격기준은 100점 만점 60점 이상입니다. 공식 출제 방향은 정보시스템 개발 요구사항을 이해하고 소프트웨어 설계·구현·테스트 등에 필요한 실무 능력을 평가하는 데 있습니다. 따라서 용어 암기만 반복하기보다 코드의 실행 결과를 추적하고 SQL을 직접 작성하며 요구사항·설계·테스트·보안·운영 개념을 구분하는 훈련이 필요합니다.
실기시험 구조와 공부 우선순위
정보처리기사 실기를 처음 준비하면 가장 먼저 느끼는 어려움은 범위가 넓다는 점입니다. 프로그래밍 언어부터 데이터베이스, 요구사항 분석, 소프트웨어 설계, 테스트, 보안, 네트워크, 운영 관련 개념까지 서로 다른 분야가 한 시험 안에 들어옵니다.
하지만 시험 준비 관점에서는 모든 내용을 같은 방식으로 공부할 필요가 없습니다. 크게 직접 풀어야 하는 영역과 정확한 용어를 회상해야 하는 영역으로 나누면 학습 방향이 선명해집니다.
| 영역 | 필요한 능력 | 주요 공부 방법 | 시험 직전 점검 |
|---|---|---|---|
| 프로그래밍 | 코드 추적·결과 판단 | 손으로 변수값 추적 | 코드를 보지 않고 흐름 설명 |
| SQL | 조회·조작·정의 이해 | 쿼리를 직접 작성 | 결과 테이블 예측 |
| 데이터베이스 | 개념·관계 이해 | 정규화·키·트랜잭션 비교 | 비슷한 개념 구별 |
| 소프트웨어 공학 | 용어·절차 구분 | 비교표·흐름도 활용 | 정의를 보고 용어 회상 |
| 테스트·보안 | 기법·공격·대응 구분 | 상황과 개념 연결 | 유사 용어 혼동 제거 |
필답형은 아는 것과 쓰는 것이 다릅니다
객관식 시험에서는 보기를 보고 기억을 되살릴 수 있지만 필답형에서는 자신이 직접 답을 만들어야 합니다. 따라서 책을 읽었을 때 익숙하게 느껴지는 것만으로는 충분하지 않습니다.
예를 들어 트랜잭션의 ACID 특성을 여러 번 읽어서 알고 있다고 생각해도 빈 종이에서 Atomicity, Consistency, Isolation, Durability에 해당하는 개념을 정확하게 적지 못한다면 실전 준비가 끝난 것이 아닙니다.
같은 원리로 SQL도 해설을 보고 이해하는 것과 아무것도 없는 상태에서 SELECT문을 직접 작성하는 것은 난도가 다릅니다. 실기 공부에서는 읽기보다 회상, 해설 보기보다 직접 작성의 비중을 점차 높여야 합니다.
60점을 목표로 하더라도 특정 영역을 통째로 버리면 위험합니다
실기는 100점 만점에서 60점 이상이면 합격합니다. 필기처럼 과목별 과락 구조를 적용하는 시험은 아니지만 실제 출제 구성은 회차마다 달라질 수 있습니다. 따라서 특정 영역이 적게 나올 것이라고 예상해 완전히 제외하는 전략은 위험합니다.
특히 프로그래밍과 SQL처럼 문제 해결 연습이 필요한 영역은 시험 직전에 단순 암기만으로 실력을 만들기 어렵습니다. 준비 초반부터 매일 조금씩 연습하고, 암기 영역은 후반으로 갈수록 반복 주기를 짧게 만드는 방식이 효율적입니다.
프로그래밍 기초 확보 → SQL 직접 작성 → 데이터베이스 핵심 개념 → 소프트웨어 공학 전체 흐름 → 테스트·보안·네트워크 압축 → 문제풀이 → 오답 키워드 회상 → 150분 실전 연습 순으로 구성하면 좋습니다.
프로그래밍 언어 핵심 요약
정보처리기사 실기에서 프로그래밍은 단순히 문법 이름을 외우는 영역이 아닙니다. 공식적인 출제 방향에서도 프로그래밍 언어 활용 능력을 평가 범위에 포함하고 있으므로 코드가 어떤 순서로 실행되고 최종적으로 어떤 결과가 만들어지는지 직접 추적할 수 있어야 합니다.
준비할 때는 언어별 문법 전체를 개발자 수준으로 학습하기보다 시험에서 코드를 읽는 데 필요한 공통 개념부터 잡습니다.
변수 — 초기값과 자료형을 확인합니다.
연산자 — 산술·비교·논리 연산의 순서를 봅니다.
조건문 — 실제로 어느 분기가 실행되는지 확인합니다.
반복문 — 반복 횟수와 변수 변화량을 기록합니다.
함수 — 매개변수와 반환값을 추적합니다.
객체·포인터 등 — 참조 대상과 호출 관계를 별도로 표시합니다.
반복문은 머리로 계산하지 말고 표를 만듭니다
반복 횟수가 늘어나면 머릿속으로만 변수값을 추적하다 실수하기 쉽습니다. 종이에 반복 횟수와 주요 변수의 값을 표로 적는 것이 안전합니다.
초기 | 0 | 0
1회 | 1 | 1
2회 | 2 | 3
3회 | 3 | 6
4회 | 4 | 10
실전에서는 모든 변수를 기록할 필요가 없습니다. 조건 판단이나 출력 결과에 영향을 주는 변수만 골라 기록합니다. 중첩 반복문이라면 바깥 반복과 안쪽 반복을 구분해서 표시해야 합니다.
연산자 우선순위와 증감 연산을 주의합니다
C 계열 코드에서는 전위·후위 증감 연산처럼 실행 시점에 따라 결과가 달라지는 표현을 주의해야 합니다. 복잡한 식을 한 번에 계산하지 말고 연산 단계를 분리합니다.
정수끼리의 연산인지 실수형이 포함되는지에 따라서도 결과가 달라질 수 있습니다. 나눗셈과 나머지 연산에서는 자료형과 연산자의 의미를 반드시 확인합니다.
C는 배열과 포인터의 연결을 봅니다
C 문제를 준비할 때는 배열 인덱스, 포인터가 가리키는 대상, 주소 이동에 따른 값 변화를 구분하는 연습이 필요합니다. 포인터 문제를 공식처럼 외우기보다 종이에 메모리 상자를 그리고 어떤 변수가 어느 값을 가리키는지 표시하면 실수를 줄일 수 있습니다.
문자열도 문자 배열이라는 관점에서 접근하면 인덱스와 반복문이 결합된 문제를 이해하기 쉬워집니다.
Java는 객체지향 호출 관계가 중요합니다
Java에서는 클래스와 객체, 상속, 오버라이딩, 접근 제어, 추상화, 인터페이스 등 객체지향 개념을 코드와 연결해야 합니다.
특히 부모 타입 변수와 자식 객체가 함께 등장할 때 어떤 메서드가 실행되는지를 확인하는 문제는 단순히 코드 위에서 눈으로 따라가면 혼동하기 쉽습니다. 변수의 선언 타입, 실제 생성된 객체, 호출하는 메서드를 분리해서 표시하는 습관이 좋습니다.
| 객체지향 개념 | 핵심 의미 | 시험에서 확인할 것 |
|---|---|---|
| 캡슐화 | 데이터와 기능을 묶고 접근을 제어 | 접근 제어와 정보 은닉 |
| 상속 | 기존 클래스의 특성을 이어받아 확장 | 부모·자식 관계 |
| 다형성 | 동일한 인터페이스가 상황에 따라 다르게 동작 | 오버라이딩과 실제 호출 |
| 추상화 | 핵심적인 특성을 중심으로 표현 | 추상 클래스·인터페이스 등 |
Python은 간단해 보여도 자료구조를 주의합니다
Python 코드는 문법이 비교적 간결하기 때문에 쉬워 보이지만 리스트와 딕셔너리, 슬라이싱, 반복 처리, 함수 반환값을 제대로 확인하지 않으면 실수가 발생합니다.
리스트의 인덱스 범위와 슬라이싱 결과, 반복문에서 실제로 순회하는 값이 무엇인지 손으로 적어봅니다. 문자열과 리스트 처리 문제가 결합될 경우 중간 결과를 한 단계씩 기록합니다.
정답을 가린 상태에서 종이에 직접 변수값을 추적하세요. 틀렸다면 단순히 정답만 확인하지 말고 문법을 몰랐는지, 연산 순서를 틀렸는지, 반복 횟수를 잘못 계산했는지, 객체 호출 관계를 혼동했는지 원인을 분류해야 같은 실수를 줄일 수 있습니다.
데이터베이스와 SQL 핵심 요약
데이터베이스 영역은 개념형과 SQL 문제를 함께 준비해야 합니다. 키와 무결성, 정규화, 트랜잭션 같은 이론을 이해하는 동시에 실제 테이블을 보고 SELECT문의 결과를 판단하거나 필요한 명령문을 작성할 수 있어야 합니다.
키는 후보키부터 구조를 잡습니다
슈퍼키 — 튜플을 유일하게 식별할 수 있는 속성 또는 속성의 집합
후보키 — 유일성과 최소성을 만족하는 키
기본키 — 후보키 가운데 대표로 선택한 키
대체키 — 후보키 중 기본키로 선택되지 않은 키
외래키 — 다른 릴레이션의 키를 참조해 관계를 표현하는 속성
키 문제에서는 정의를 따로 암기하기보다 유일성과 최소성이라는 기준을 이용해 후보키를 직접 찾는 연습을 합니다. 속성 조합에서 불필요한 속성을 제거해도 유일성이 유지된다면 최소성을 다시 확인해야 합니다.
정규화는 이상현상과 함수적 종속을 연결합니다
정규화는 데이터 중복으로 발생할 수 있는 삽입·삭제·갱신 이상을 줄이고 데이터 구조를 적절히 분해하는 과정과 연결해서 이해합니다.
| 단계 | 핵심 확인 사항 | 암기 포인트 |
|---|---|---|
| 제1정규형 | 속성값의 원자성 | 반복·다중값 제거 관점 |
| 제2정규형 | 부분 함수적 종속 제거 | 완전 함수적 종속 |
| 제3정규형 | 이행적 함수적 종속 제거 | 비주요 속성 사이 종속 확인 |
| BCNF | 결정자가 후보키가 되도록 정리 | 결정자와 후보키 관계 |
정규형 이름만 순서대로 외우는 것보다 예시 테이블을 보고 어떤 함수적 종속 때문에 분해해야 하는지를 직접 판단하는 연습이 중요합니다.
트랜잭션 ACID는 반드시 구분합니다
Atomicity는 트랜잭션 연산이 모두 수행되거나 모두 수행되지 않아야 한다는 원자성, Consistency는 트랜잭션 수행 전후 데이터가 정해진 규칙을 만족해야 한다는 일관성입니다.
Isolation은 동시에 수행되는 트랜잭션이 서로 부적절하게 간섭하지 않도록 하는 격리성, Durability는 성공적으로 완료된 결과가 지속적으로 반영되어야 한다는 영속성입니다.
SQL은 SELECT 실행 흐름을 익힙니다
SQL 문제는 SELECT와 FROM만 아는 수준에서 끝나지 않습니다. WHERE, GROUP BY, HAVING, ORDER BY, 집계함수, 서브쿼리, JOIN 등을 조합했을 때 결과가 어떻게 달라지는지 판단할 수 있어야 합니다.
FROM employee
WHERE salary >= 3000
GROUP BY department
HAVING COUNT(*) >= 2
ORDER BY department;
이런 문제가 나오면 한 번에 결과를 예상하지 말고 단계별로 처리합니다. 먼저 FROM에서 대상 테이블을 확인하고 WHERE 조건으로 행을 걸러낸 뒤 GROUP BY로 묶고 집계합니다. 이후 HAVING으로 그룹을 다시 필터링하고 ORDER BY를 적용합니다.
WHERE와 HAVING의 차이를 확실히 합니다
WHERE는 일반적으로 그룹화 이전의 행을 조건에 따라 걸러내는 데 사용하고, HAVING은 GROUP BY로 만들어진 그룹에 조건을 적용하는 데 사용합니다. 집계함수가 포함된 조건을 볼 때 어느 단계에서 적용되는지 확인하는 습관이 중요합니다.
DDL·DML·DCL 계열 명령도 묶어서 정리합니다
CREATE, ALTER, DROP과 같은 정의 명령과 SELECT, INSERT, UPDATE, DELETE처럼 데이터를 조회·조작하는 명령, 권한 제어와 관련된 명령을 목적별로 분류해 정리합니다. COMMIT과 ROLLBACK처럼 트랜잭션 제어와 연결되는 명령도 함께 복습합니다.
문제를 읽고 해설 SQL을 이해하는 것과 아무것도 없는 상태에서 직접 작성하는 것은 다릅니다. 조건 조회 → 정렬 → 그룹화 → 집계 → JOIN → 서브쿼리 → INSERT·UPDATE·DELETE 순으로 직접 작성하는 연습을 반복하면 실전 대응력이 높아집니다.
요구사항·설계·인터페이스 핵심 요약
소프트웨어 공학 영역은 용어의 수가 많기 때문에 무작정 단어장을 만드는 것보다 개발 흐름을 먼저 잡는 것이 좋습니다. 사용자의 요구를 파악하고 분석한 뒤 설계하고 구현하며 테스트와 배포로 이어진다는 큰 구조 안에서 개념을 배치합니다.
요구사항은 기능과 비기능을 구분합니다
기능 요구사항은 시스템이 무엇을 수행해야 하는지를 나타냅니다. 반면 비기능 요구사항은 성능, 보안, 신뢰성, 사용성 등 시스템 기능의 품질이나 제약과 관련된 요구사항으로 이해하면 구분하기 쉽습니다.
문제에서 “사용자는 주문을 취소할 수 있어야 한다”와 같은 문장은 기능에 가깝고, “응답시간은 일정 수준 이내여야 한다”처럼 품질 기준이나 제약을 나타내는 문장은 비기능 요구사항 관점에서 판단합니다.
결합도는 낮게, 응집도는 높게
모듈 설계에서 반복적으로 기억해야 할 기본 방향은 모듈 사이의 결합도는 낮추고 모듈 내부의 응집도는 높이는 것입니다.
결합도와 응집도의 세부 종류는 이름만 외우면 쉽게 섞입니다. 각 단계가 무엇을 공유하거나 어떤 이유로 요소들이 묶이는지를 사례와 함께 정리해야 합니다.
결합도 — 서로 다른 모듈이 얼마나 강하게 의존하는지 확인합니다.
응집도 — 하나의 모듈 내부 요소들이 얼마나 밀접하게 관련되는지 확인합니다.
좋은 설계 방향 — 모듈 간 의존성을 줄이고 하나의 모듈이 명확한 책임을 갖도록 구성합니다.
UML은 다이어그램 이름과 목적을 연결합니다
UML을 공부할 때는 다이어그램 이름을 무작정 나열하지 말고 구조적 관점인지 행위적 관점인지부터 분류합니다. 클래스 다이어그램은 시스템의 정적인 구조와 클래스 관계를 표현하는 데 활용하고, 시퀀스 다이어그램은 객체 사이 메시지의 시간적 흐름을 이해하는 데 활용하는 식입니다.
유스케이스 다이어그램에서는 액터와 시스템 기능의 관계를 보고, 시퀀스 다이어그램에서는 메시지의 순서를 확인합니다. 문제에서 설명을 제시하고 해당 다이어그램 이름을 쓰게 할 수 있으므로 정의를 보고 용어를 떠올리는 훈련이 필요합니다.
디자인 패턴은 목적 중심으로 구분합니다
디자인 패턴은 생성·구조·행위 관점으로 큰 틀을 잡은 뒤 대표 패턴의 목적을 정리합니다. 패턴 이름만 암기하면 설명이 조금 바뀌었을 때 답을 찾기 어렵습니다.
예를 들어 객체 생성 방식을 캡슐화하려는 패턴인지, 객체 사이 구조를 구성하는 패턴인지, 객체 사이 책임과 상호작용을 조정하는 패턴인지 먼저 판단합니다.
인터페이스는 시스템 사이의 연결 관점으로 봅니다
서로 다른 시스템이나 모듈 사이에서 데이터를 주고받을 때는 인터페이스 요구사항과 데이터 형식, 통신 방식, 오류 처리, 보안 등을 함께 고려해야 합니다. JSON과 XML 같은 데이터 표현 방식도 기본 구조와 차이를 알아두는 것이 좋습니다.
인터페이스 오류가 발생했을 때 단순히 통신 여부만 보는 것이 아니라 송수신 데이터, 변환 과정, 연결 상태, 로그 등을 이용해 원인을 추적한다는 흐름으로 이해하면 관련 용어를 정리하기 쉽습니다.
교재에서는 보통 용어 → 정의 순서로 공부합니다. 실기 대비에서는 반대로 정의 → 용어를 맞히는 훈련을 해야 합니다. 설명을 읽고 5초 안에 핵심 용어를 말하거나 쓸 수 있는지 확인하세요.
테스트·보안·네트워크 핵심 요약
테스트와 보안, 네트워크 영역은 비슷한 용어가 많고 설명형 문제로 변형하기 쉬운 영역입니다. 단순한 약어 암기보다 “어떤 상황에서 사용하는 개념인가”를 함께 기억해야 합니다.
화이트박스와 블랙박스 테스트부터 구분합니다
화이트박스 테스트는 프로그램 내부 구조와 논리 경로를 고려해 테스트하는 관점이고, 블랙박스 테스트는 내부 구현보다 입력과 출력, 요구사항에 따른 기능을 중심으로 확인하는 관점입니다.
| 구분 | 핵심 관점 | 연결해서 볼 개념 |
|---|---|---|
| 화이트박스 | 내부 논리·경로·구조 | 문장·분기·조건·경로 등의 커버리지 |
| 블랙박스 | 입력·출력과 기능 | 동등분할·경계값 분석 등 |
테스트 단계는 대상 범위를 생각합니다
단위 테스트는 개별 모듈이나 구성요소를 중심으로 보고, 통합 테스트는 결합된 모듈 사이의 인터페이스와 상호작용을 확인합니다. 시스템 테스트는 완성된 시스템 전체가 요구사항을 만족하는지 확인하고, 인수 테스트는 사용자나 고객 관점에서 최종 요구를 충족하는지 확인하는 흐름으로 정리합니다.
회귀 테스트는 변경이나 수정 이후 기존 기능에 예상하지 못한 문제가 발생하지 않았는지 다시 확인하는 목적과 연결해서 기억합니다.
보안은 공격 이름과 특징을 세트로 외웁니다
보안 문제는 공격 기법 이름만 외우면 설명형 문제에서 혼동하기 쉽습니다. 공격 대상과 방식, 대표적인 대응 방향을 한 세트로 정리하는 것이 좋습니다.
SQL Injection — 입력값을 통해 의도하지 않은 SQL 구문이 실행되도록 노리는 공격과 연결
XSS — 웹 페이지에 악성 스크립트를 삽입해 사용자 측에서 실행되도록 하는 공격과 연결
CSRF — 인증된 사용자의 권한을 이용해 사용자가 의도하지 않은 요청을 수행하도록 만드는 공격과 연결
DoS·DDoS — 서비스 자원을 소모시켜 정상적인 서비스 이용을 방해하는 공격 관점에서 구분
SQL Injection 대응을 단순히 “특수문자를 막는다” 정도로 외우기보다 입력 검증과 안전한 쿼리 처리 방식 등 공격 원인을 줄이는 방향으로 이해합니다. XSS와 CSRF는 모두 웹 환경에서 등장하지만 공격 방식과 목표가 다르므로 반드시 비교합니다.
암호화는 대칭키와 공개키를 먼저 나눕니다
대칭키 암호화는 암호화와 복호화에 동일한 비밀키를 사용하는 구조이고, 공개키 방식은 공개키와 개인키의 쌍을 이용합니다. 속도와 키 관리 특성, 활용 목적을 비교해서 정리하면 좋습니다.
해시 함수는 일반적인 암호화·복호화와 같은 개념으로 외우면 안 됩니다. 입력값으로부터 일정한 형태의 해시값을 만들어 무결성 확인이나 비밀번호 처리 등에 활용하는 관점과 연결합니다.
네트워크는 계층별 역할을 중심으로 정리합니다
OSI 7계층을 단순히 순서만 외우기보다 각 계층이 어떤 역할을 담당하는지 함께 기억해야 합니다. 물리적 전송에서 시작해 데이터 링크, 네트워크, 전송, 세션, 표현, 응용 계층으로 올라가는 구조를 그리고 대표적인 기능을 배치합니다.
TCP와 UDP 역시 이름만 구분하지 말고 연결 지향성과 신뢰성, 전송 특성의 차이를 중심으로 비교합니다. IP 주소와 서브넷, 라우팅 등도 단순 용어 암기보다 데이터가 네트워크에서 어떤 방식으로 목적지를 찾아가는지 흐름으로 이해하면 기억하기 쉽습니다.
시험 직전에는 용어 하나마다 정의 한 줄 + 특징 한 줄 + 혼동하는 개념 한 개만 남겨 압축하세요. 예를 들어 XSS를 정리한다면 정의를 적고 바로 아래에 CSRF와 무엇이 다른지 한 줄을 추가하는 방식입니다.
출제 경향을 반영한 공부 우선순위
정보처리기사 실기의 출제 경향을 분석할 때 주의해야 할 점은 특정 영역이 매 회차 정확히 몇 문제 나온다고 단정하지 않는 것입니다. 공식적인 시험 안내는 실기에서 정보처리 실무 능력을 평가하고, 세부 내용은 해당 연도 출제기준을 기준으로 제시합니다. 실제 회차별 문항 구성과 난이도는 달라질 수 있습니다.
따라서 “이번 시험에서는 프로그래밍이 반드시 몇 문제 나온다”는 식의 예상보다 공식 출제범위에서 반복적으로 문제를 만들기 좋은 영역과 실제 문제 해결에 시간이 필요한 영역을 우선하는 것이 현실적입니다.
우선 학습 — C·Java·Python 코드 해석과 실행 결과 추적
우선 학습 — SQL 작성과 결과 판단, 데이터베이스 핵심 이론
반복 학습 — 요구사항·UML·모듈·디자인 패턴·테스트
압축 암기 — 보안 공격·암호·네트워크·운영 관련 핵심 용어
최종 단계 — 답안을 직접 쓰는 회상 훈련과 150분 시간 관리
프로그래밍은 시험 직전에 몰아서 공부하기 어렵습니다
용어는 시험 며칠 전 집중적으로 반복해도 어느 정도 기억을 끌어올릴 수 있지만 코드 해석은 다릅니다. 반복문, 배열, 포인터, 객체지향 호출 관계를 읽는 능력은 실제 문제를 여러 번 손으로 추적해야 안정됩니다.
따라서 준비기간이 짧더라도 프로그래밍은 첫날부터 매일 공부하는 편이 좋습니다. 하루에 많은 문제를 몰아서 푸는 것보다 C·Java·Python 문제를 꾸준히 접하면서 틀린 원인을 기록합니다.
SQL도 읽기보다 쓰기 비중을 높입니다
SQL은 보기만 하면 쉬워 보이기 때문에 학습 착각이 발생하기 쉽습니다. SELECT문을 읽고 결과를 이해할 수 있더라도 조건에 맞는 SQL을 직접 작성하려면 GROUP BY와 HAVING의 위치, JOIN 조건, 서브쿼리 구조 등을 정확히 기억해야 합니다.
문제를 본 뒤 바로 해설을 펼치지 말고 먼저 직접 작성합니다. 틀렸다면 완성된 정답 SQL을 그대로 필사하는 것보다 자신이 어느 절에서 막혔는지를 확인합니다.
암기 영역은 비교형으로 정리합니다
실기 이론에는 서로 비슷한 개념이 많습니다. 따라서 개별 정의를 수백 개 나열하기보다 비교가 필요한 용어를 한 묶음으로 만듭니다.
| 비교 세트 | 반드시 구분할 포인트 |
|---|---|
| 기능 요구사항 ↔ 비기능 요구사항 | 기능 자체인지 품질·제약 조건인지 |
| 결합도 ↔ 응집도 | 모듈 사이 관계인지 모듈 내부 관계인지 |
| 화이트박스 ↔ 블랙박스 | 내부 구조 중심인지 기능·입출력 중심인지 |
| 대칭키 ↔ 공개키 | 키 사용 구조와 관리 특성 |
| TCP ↔ UDP | 연결·신뢰성·전송 특성 |
| WHERE ↔ HAVING | 행 조건과 그룹 조건의 차이 |
실기시험은 출제기준 안에서 문항 구성이 달라질 수 있습니다. 특정 유형이 최근 많이 나왔다는 이유만으로 다른 범위를 완전히 제외하기보다 프로그래밍·SQL처럼 연습이 필요한 영역을 우선 확보하고 나머지 공식 범위를 압축 반복하는 방식이 안정적입니다.
기출·복원문제 회독법과 실수 방지
실기시험 문제를 반복할 때 가장 피해야 할 공부법은 답 자체를 외우는 것입니다. 같은 개념이 다른 코드와 다른 문장으로 출제되면 기억한 정답을 그대로 적용할 수 없기 때문입니다.
첫 회독은 영역별 약점 발견에 사용합니다
문제를 풀고 점수만 기록하지 말고 오답을 프로그래밍·SQL·DB·소프트웨어 공학·테스트·보안·네트워크 등으로 분류합니다.
프로그래밍에서도 다시 문법 오류, 반복문 추적 실패, 객체지향 개념 혼동처럼 원인을 세분화합니다. 그래야 전체 기본서를 다시 보는 대신 필요한 부분만 보완할 수 있습니다.
두 번째 회독은 답을 가리고 직접 씁니다
용어 문제는 문제를 읽고 종이에 답을 직접 씁니다. 철자와 용어를 정확하게 확인한 뒤 틀렸다면 오답노트에 긴 설명 대신 핵심 단서만 남깁니다.
예를 들어 “실제 참인 귀무가설을 기각하는 오류”처럼 정의를 보고 용어를 회상하는 시험과 달리 정보처리기사에서는 보안 공격이나 테스트 기법, 디자인 패턴, 데이터베이스 개념 등 다양한 설명을 보고 해당 용어를 직접 떠올리는 방식의 훈련이 중요합니다.
코드 오답은 결과보다 틀린 지점을 찾습니다
코드의 최종 출력이 틀렸다면 정답 숫자를 외우지 않습니다. 어느 줄까지 자신의 계산이 맞았고 어디서 처음 어긋났는지를 찾아야 합니다.
□ 반복 횟수를 잘못 계산했는가?
□ 배열 인덱스를 하나 잘못 이동했는가?
□ 정수 나눗셈을 실수 나눗셈처럼 계산했는가?
□ 증감 연산의 적용 시점을 혼동했는가?
□ 포인터가 가리키는 값을 잘못 추적했는가?
□ 부모·자식 객체의 호출 관계를 혼동했는가?
□ 함수의 반환값과 변수 변경을 놓쳤는가?
시험시간 150분을 실제로 연습합니다
실기시험은 2시간 30분이므로 공부 후반에는 실제 제한시간을 적용한 문제풀이가 필요합니다. 아는 문제인데 한 문제에 지나치게 오래 머물러 전체 답안을 검토하지 못하는 상황을 피해야 합니다.
처음 한 바퀴에서는 바로 풀 수 있는 문제를 확보하고, 계산이나 코드 추적에 시간이 필요한 문제에는 표시한 뒤 다시 돌아오는 방식을 연습할 수 있습니다. 자신의 풀이 속도에 따라 순서는 조정하되 시험 당일 처음 새로운 전략을 시도하지 않는 것이 좋습니다.
교정 — 변수표를 만들고 직접 추적합니다. 틀린 문제는 최초로 계산이 어긋난 지점을 찾습니다.
교정 — 다음날 같은 문제를 정답 없이 다시 작성합니다. 직접 작성되지 않는다면 아직 완전히 익힌 것이 아닙니다.
교정 — 정의를 가리고 용어를 말하는 방식이 아니라 설명을 보고 용어를 직접 쓰는 방향으로 회상 훈련을 합니다.
교정 — 회차별 문항 구성이 달라질 수 있습니다. 완전 포기보다 기본 문제를 맞힐 수 있는 수준까지 범위를 확보한 뒤 강약을 조절합니다.
시험 직전 압축 암기 체크리스트
시험 직전에는 새로운 교재를 추가하기보다 이미 공부한 내용을 빠르게 꺼낼 수 있는 상태로 만드는 것이 중요합니다. 최종 노트는 두꺼울수록 좋은 것이 아니라 짧은 시간에 전체 취약점을 훑을 수 있어야 합니다.
프로그래밍 최종 점검
□ C의 배열과 인덱스를 추적할 수 있다.
□ 포인터가 가리키는 값의 변화를 계산할 수 있다.
□ 증감·논리·비교·산술 연산을 순서대로 계산할 수 있다.
□ 중첩 반복문의 반복 횟수를 표로 추적할 수 있다.
□ Java의 상속과 오버라이딩을 코드에서 구분할 수 있다.
□ 객체 생성과 실제 메서드 호출 관계를 추적할 수 있다.
□ Python의 리스트·문자열·슬라이싱·반복 결과를 판단할 수 있다.
데이터베이스·SQL 최종 점검
□ 슈퍼키·후보키·기본키·대체키·외래키를 구분한다.
□ 유일성과 최소성으로 후보키를 판단할 수 있다.
□ 정규화 단계와 함수적 종속을 연결할 수 있다.
□ 삽입·삭제·갱신 이상을 구분할 수 있다.
□ ACID 네 가지 특성을 직접 쓸 수 있다.
□ SELECT·WHERE·GROUP BY·HAVING·ORDER BY의 역할을 구분한다.
□ JOIN 결과를 테이블로 직접 추적할 수 있다.
□ 서브쿼리를 포함한 SQL의 결과를 판단할 수 있다.
□ INSERT·UPDATE·DELETE와 트랜잭션 제어 명령을 구분한다.
이론 최종 점검
□ 기능 요구사항과 비기능 요구사항을 구분할 수 있다.
□ UML 주요 다이어그램의 목적을 설명할 수 있다.
□ 결합도와 응집도의 좋은 설계 방향을 알고 있다.
□ 주요 디자인 패턴을 목적과 연결할 수 있다.
□ 화이트박스와 블랙박스 테스트를 구분한다.
□ 단위·통합·시스템·인수 테스트의 범위를 구분한다.
□ SQL Injection·XSS·CSRF의 차이를 설명할 수 있다.
□ 대칭키·공개키·해시를 구분할 수 있다.
□ OSI 계층별 주요 역할을 설명할 수 있다.
□ TCP와 UDP의 차이를 설명할 수 있다.
□ 정의를 보고 핵심 용어를 직접 쓸 수 있다.
□ 150분 제한을 적용해 실전 풀이를 해봤다.
자주 묻는 질문
정보처리기사 실기 핵심 요약
| 영역 | 최종 공부 포인트 |
|---|---|
| 프로그래밍 | C·Java·Python 코드를 손으로 추적하고 최종 출력 결과를 직접 계산합니다. |
| SQL | 쿼리를 읽는 데서 끝내지 않고 조건에 맞는 문장을 직접 작성합니다. |
| 데이터베이스 | 키·정규화·무결성·트랜잭션을 사례와 연결해 구분합니다. |
| 소프트웨어 공학 | 요구사항·UML·모듈·디자인 패턴을 정의와 목적 중심으로 압축합니다. |
| 테스트·보안 | 비슷한 테스트 기법과 공격 유형을 비교형으로 정리합니다. |
| 실전 | 정답을 직접 쓰는 회상 훈련과 150분 제한 문제풀이로 마무리합니다. |
전체 공부 흐름은 프로그래밍 기본기 → SQL 직접 작성 → 데이터베이스 핵심 이론 → 요구사항·설계·테스트 → 보안·네트워크 압축 → 기출·복원문제 → 오답 원인 분석 → 빈 종이 회상 → 150분 실전 연습으로 정리할 수 있습니다. 합격선이 60점이라는 이유로 특정 영역을 통째로 제외하기보다 기본 문제를 확보할 수 있는 범위를 넓힌 뒤 자신의 취약 영역에 시간을 집중하는 편이 안정적입니다.
첫째, 프로그래밍과 SQL은 눈으로 이해하는 공부보다 손으로 직접 추적하고 작성하는 공부가 중요합니다. 둘째, 이론은 용어를 보고 정의를 읽는 방향에서 벗어나 설명을 보고 정확한 용어를 직접 쓰는 방식으로 연습해야 합니다. 셋째, 출제 영역별 문항 수를 고정적으로 예측하기보다 2026년 적용 출제기준 전체를 바탕으로 준비하고 자신의 반복 오답에 시간을 집중하는 것이 좋습니다.
※ 2026년 9월 기준 정보처리기사 시험 안내와 2026년 적용 출제기준을 기준으로 정리했습니다. 실기 과목은 정보처리 실무이며 필답형 2시간 30분, 100점 만점 60점 이상이 합격기준입니다. 공식 안내상 정보시스템 개발 요구사항을 이해하고 소프트웨어 설계·구현·테스트 등에 필요한 능력을 평가하며, 실제 회차별 세부 문항 구성과 난이도는 달라질 수 있습니다. 특정 영역의 예상 문항 수를 합격 공식처럼 사용하기보다 응시 시점의 출제기준과 해당 회차 수험자 안내를 다시 확인하는 것이 좋습니다.