정보처리기사 실기 SQL 결과 추적법, 파이썬·자바·C 나눗셈 차이 손코딩

시험지를 받았는데 코드 몇 줄 아래에 ‘출력 결과를 쓰시오’라는 문장이 보이면 손이 멈추는 순간이 있어요. 문법 하나하나는 아는 것 같은데, 반복문이 두 바퀴째 돌 때 변수 값이 무엇이었는지 헷갈리기 시작하면 답이 금세 흔들리죠. 정보처리기사 실기는 컴퓨터로 돌려 보는 시험이 아니라 답안지에 직접 적는 필답형이라, 실행해서 맞춰 볼 방법이 없다는 점이 막막함을 더 키워요.

이 글은 2026년 3회 실기(10월 24일~11월 13일)를 앞둔 분과, 이번 회차는 놓치고 다음 시험을 준비하는 분 모두를 위해 쓴 손코딩 추적법이에요. 코드 문제에 파이썬, 자바, C를 모두 대비하는 분이 많아서 세 언어에서 값이 갈리는 지점을 한곳에 묶었어요. 합격 비법이나 기출 족보를 약속하는 글은 아니고, 큐넷 일정 안내와 파이썬·자바·PostgreSQL 공식 문서, C 언어 참조 문서에서 다시 열어 확인한 규칙만 근거로 적었어요.

결론부터 말하면 세 가지예요. 머릿속으로 실행하지 말고 여백에 값을 적어 따라가요. 같은 -7과 2라도 파이썬, 자바, C는 몫과 나머지가 달라질 수 있으니 문제의 언어부터 확인해요. 그리고 시험이 끝나면 틀린 이유를 한 줄 규칙으로 남겨 다음 회차에 그대로 써요.

큐넷의 정보처리기사 시험일정에서 2026년 정기 기사 실기 일정을 다시 확인했어요. 2026-10-14 기준으로 정리하면 아래와 같아요.

올해 정기 기사 실기는 3회가 마지막이고, 일반 접수는 9월 28일에 끝났어요. 큐넷 일정에는 빈자리 접수도 따로 표시되어 있는데, 3회는 10월 18일~19일이에요. 원서접수는 첫날 10시에 열고 마지막 날 18시에 닫는다고 안내되어 있어요. 빈자리가 있을지는 알 수 없으니 기대하기보다 큐넷에서 직접 확인해 보는 정도로만 생각하는 게 좋아요. 시험 기간이 10월 24일부터 11월 13일까지 약 3주로 길고 지역별·종목별로 일정이 다를 수 있다고 안내되어 있어서, 접수를 마친 분은 본인에게 배정된 날짜를 꼭 다시 확인해야 해요.

시험 형식은 이전에 큐넷 종목 안내에서 확인한 대로 필답형이고 시험 시간은 2시간 30분, 합격 기준은 60점 이상, 실기 응시 수수료는 22,600원이에요. 다만 이번 재확인에서는 큐넷 종목 안내 페이지가 이 항목을 제대로 보여 주지 않아 값을 다시 대조하지 못했어요. 접수나 응시 전에 큐넷 종목 안내에서 한 번 더 확인해 주세요. 문항 수와 문항별 배점, 언어별 출제 비중은 공식 안내에서 찾지 못해서 ‘몇 문제가 코드로 나온다’ 같은 단정은 하지 않았어요.

2027년 정기 일정은 2026-10-14 기준으로 공식 공고를 찾지 못했어요. 그래서 다음 회차를 노리는 분은 날짜를 짐작하지 말고, 큐넷 연간 시험일정 메뉴에 공고가 올라온 뒤 날짜를 잡는 쪽이 안전해요.

머릿속으로 실행하려 하지 말고 시험지 여백에 작은 변수 표를 그리는 거예요. 열에는 변수 이름을, 행에는 실행한 순서를 적고, 값이 바뀔 때만 새 칸을 채워요. 손코딩에서 막히는 순간은 대개 문법을 몰라서가 아니라 ‘지금 이 변수가 몇이었지?’를 기억하지 못해서 생겨요. 그 기억을 종이에 맡기면 머리는 다음 줄을 읽는 데만 쓰면 되죠.

시간 배분도 같이 생각해야 해요. 시험 시간이 2시간 30분이라고 안내되어 있고 그 안에 다른 유형의 문항도 풀어야 하니, 한 문제의 표가 길어지면 표시를 해 두고 넘어갔다가 돌아오는 편이 나아요. 반복이 수십 번 도는 코드라면 처음 두세 바퀴만 적어 규칙을 찾고, 마지막 한두 바퀴를 다시 적어 규칙이 끝까지 맞는지만 확인하는 식으로 줄일 수 있어요.

변수 표를 그렸는데도 답이 틀렸다면 실수는 보통 흐름(다음에 어느 줄로 가는지), 값(연산 결과), 출력 형식 중 하나에서 나와요. 이 중 값 실수는 언어마다 규칙이 달라 특히 위험해요. 아래는 각 언어의 공식 문서와 C 언어 참조 문서에서 확인한 규칙이에요.

같은 -7과 2인데 파이썬은 몫 -4와 나머지 1을, 자바와 C는 몫 -3과 나머지 -1을 내놓아요. 세 언어 모두 ‘몫 × 나누는 수 + 나머지 = 원래 수’라는 관계는 지키지만, 몫을 어느 방향으로 자르느냐가 달라서 나머지 부호까지 갈리는 거예요. 파이썬 공식 문서는 나머지가 두 번째 피연산자와 같은 부호라고 적고 있고, 자바 언어 명세는 나머지가 음수일 수 있는 경우는 나눠지는 수가 음수일 때뿐이라고 설명해요. C는 위 항등식으로 나머지 부호가 정해진다고 참조 문서에 나와 있어요. 그래서 문제를 보면 코드를 읽기 전에 어느 언어인지부터 표 위에 적어 두는 습관이 도움이 돼요.

정수 나눗셈에서 한 가지 더 알아 둘 점이 있어요. 자바는 정수를 0으로 나누거나 0으로 나눈 나머지를 구하면 ArithmeticException이 발생한다고 명세에 적혀 있고, C는 같은 경우 동작이 정의되지 않는다고 참조 문서에 적혀 있어요. 시험에서 이런 코드가 나오면 숫자 대신 오류나 정의되지 않음 성격의 답을 묻는 것일 수 있으니, 나누는 수가 0이 되는 순간이 있는지 표에서 한 번 눈여겨봐요.

전위·후위 증가는 단계별로 쪼개면 덜 헷갈려요. 자바 명세는 후위 증가식의 값이 증가 전 변수 값이고, 전위 증가식의 값이 증가 후 값이라고 설명해요. 자바에서 i가 3일 때 k = i++ + ++i 를 왼쪽부터 따라가 볼게요. 자바는 피연산자를 왼쪽에서 오른쪽으로 평가한다고 보장해서 순서가 정해져 있어요.

여기서 핵심은 ‘i 값’과 ‘식에 들어간 값’을 열로 따로 적는 거예요. 둘을 한 칸에 적으면 3을 넘겼는지 4를 넘겼는지가 섞여 버려요. 다만 같은 식을 C로 옮기면 이야기가 달라져요. C 참조 문서는 같은 변수를 순서가 정해지지 않은 채 두 번 바꾸는 식, 예를 들어 i = ++i + i++ 같은 식의 동작을 정의되지 않음으로 분류해요. 그래서 C 문제에서 이런 식을 만나면 값을 단정해서 적기 전에 문제에 붙은 조건이나 설명이 있는지부터 확인해야 해요.

C에서는 포인터도 변수 표에 한 줄 더 만들어 주면 실수가 줄어요. 참조 문서에 따르면 포인터 p가 배열의 인덱스 I 원소를 가리킬 때 p + N 은 같은 배열의 인덱스 I+N 원소를 가리켜요. 또 후위 증가는 앞에 붙은 * 보다 먼저 묶여서 *p++ 는 *(p++) 로 해석되고, (*p)++ 와는 달라요. 가령 int a[4] = {10, 20, 30, 40}; int *p = a; 라고 하고 따라가 볼게요.

이렇게 ‘포인터가 가리키는 위치’와 ‘그 위치의 값’을 두 칸으로 나눠 적어야 *p++ 와 (*p)++ 가 섞이지 않아요. 포인터에 더하는 숫자는 바이트 수가 아니라 원소 개수 단위로 움직인다는 점, 배열 범위를 벗어난 이동은 동작이 정의되지 않는다는 점도 참조 문서에 나와요. 구조체 포인터, 이중 포인터, 문자열 처리 같은 C의 나머지 규칙은 이번에 자료로 다시 확인하지 못해서 이 글에서는 다루지 않았어요.

SQL은 SELECT부터 쓰지만 결과를 손으로 만들 때는 쓰는 순서대로 읽으면 오히려 헷갈려요. PostgreSQL 공식 문서는 FROM 목록을 먼저 계산하고, WHERE로 조건에 맞지 않는 행을 없애고, GROUP BY로 묶어 집계를 계산한 뒤, HAVING으로 조건에 맞지 않는 그룹을 없애고, 그다음에 SELECT의 출력 값을 계산하고, 마지막에 ORDER BY로 정렬한다고 설명해요. 이 순서대로 단계마다 작은 중간 표를 그리면 실수가 어디서 생겼는지 보여요. 아래 예시는 설명을 위해 만든 가정 데이터예요. 1반에는 가(점수 90)와 나(점수 NULL), 2반에는 다(점수 70)와 라(점수 70)가 있다고 해 볼게요.

이 데이터에서 COUNT(*)와 COUNT(점수)를 함께 구하면 결과는 4와 3이에요. 공식 문서 설명대로 앞의 것은 입력 행의 수를 세고, 뒤의 것은 값이 NULL이 아닌 행만 세기 때문이에요. 평균을 구하는 AVG(점수)도 NULL이 아닌 값만으로 계산해서 90과 70과 70의 평균인 약 76.67이 나와요. 무심코 4로 나누면 57.5라는 엉뚱한 값이 되니, 집계 함수가 보이면 중간 표에서 NULL 칸에 먼저 동그라미를 쳐 두세요. 또 하나, 조건에 맞는 행이 하나도 없을 때 COUNT는 0을 돌려주지만 SUM이나 AVG는 NULL을 돌려준다고 같은 문서에 적혀 있어요.

조금 더 나아가 ‘반별로 묶고 점수가 있는 학생이 2명 이상인 반만 남기는’ 질의를 생각해 볼게요. GROUP BY 반으로 묶으면 1반 묶음(가, 나)과 2반 묶음(다, 라)이 생겨요. 여기에 HAVING COUNT(점수) >= 2 를 적용하면 1반은 점수가 있는 행이 ‘가’ 하나뿐이라 떨어지고 2반만 남아요. SELECT에서 반과 COUNT(*)를 고르면 결과는 ‘2반, 2’ 한 행이에요. 공식 문서도 WHERE는 묶기 전에 개별 행을 거르고 HAVING은 묶은 뒤의 그룹을 거른다고 구분하니, 둘을 같은 단계로 생각하면 행 수가 틀어지기 쉬워요.

이 규칙은 PostgreSQL 공식 문서로 확인한 내용이에요. 시험에서 쓰는 데이터베이스 제품이나 문제에 붙은 설명이 다르다면 그 조건을 우선으로 따라가는 것이 안전해요. 다른 제품의 세부 동작은 이번에 확인하지 못했어요.

아래 두 사례는 이해를 돕기 위해 지어낸 가정이에요. 실제 인물이나 후기가 아니고, 시간을 나누는 방식을 보여 주기 위한 예시예요.

가정 사례 1: 3회를 접수했고 반복문 결과에서 자꾸 틀리는 경우

3회 실기를 접수해 둔 A씨를 가정해 볼게요. 시험은 10월 24일부터 11월 13일 사이 배정된 날에 봐요. A씨는 코드를 읽으면 뜻은 이해하지만 출력 결과를 적으면 한두 줄씩 어긋나요. 이런 경우에는 새 개념을 늘리기보다 하루에 짧은 코드 세 개를 골라 변수 표로 결과를 먼저 적고, 그다음 컴퓨터로 실행해 맞춰 보는 연습이 잘 맞아요. 공부할 때는 실행기를 쓸 수 있으니, 틀린 행에 표시해 두고 원인을 ‘조건 검사 시점’, ‘후위 증가’, ‘출력 줄바꿈’, ‘음수 나눗셈’처럼 짧게 분류해요. 일주일쯤 모으면 반복해서 틀리는 유형이 두세 개로 좁혀지고, 남은 날은 그 유형만 다시 보면 돼요. 시험 날짜가 가까워질수록 새 자료를 넓히지 말고 이미 푼 문제의 틀린 이유만 다시 훑어봐요.

가정 사례 2: 시험을 마쳤거나 이번 회차를 놓치고 다음을 준비하는 경우

11월 13일 이후, 또는 접수를 놓쳐 다음 일정을 기다리는 B씨를 가정해 볼게요. B씨는 파이썬은 써 봤지만 자바와 C 코드는 거의 읽어 본 적이 없어요. 시간이 있는 만큼 세 언어를 처음부터 새로 배우기보다, 앞에서 본 것처럼 결과가 갈리는 지점(정수 나눗셈, 나머지 부호, 증감 연산자, 포인터)부터 한 장에 정리해 두는 방식이 현실적이에요. 2027년 일정이 공고되기 전까지는 날짜를 짐작하지 말고, 매일 코드 두세 개를 변수 표로 추적하는 습관을 먼저 만들어 두면 돼요. 다만 언어별 출제 비중은 공식 안내에서 확인되지 않았기 때문에 특정 언어를 아예 빼고 가는 판단은 신중하게 하는 편이 좋아요.

두 사례의 공통점은 ‘더 많이’보다 ‘내가 틀리는 지점’을 좁히는 데 시간을 쓴다는 거예요. 시험이 가까울수록, 그리고 시험이 끝난 뒤에는 더더욱 틀린 이유를 다시 보는 쪽이 손 추적에는 더 도움이 돼요.

시점별로 바로 쓸 수 있게 행동 순서로 정리했어요.

최종 합격 발표는 12월 18일로 안내되어 있어요. 이번 회차를 접수하지 못했다면 큐넷 연간 시험일정 메뉴에 2027년 공고가 올라온 뒤 날짜를 잡고, 그전에는 날짜를 짐작해 계획을 세우지 않는 편이 안전해요.

손코딩이 막히는 건 실력이 부족해서라기보다 기억해야 할 값이 한꺼번에 많아서인 경우가 많아요. 값을 종이에 내려놓는 습관 하나가 시험 전에도, 시험이 끝난 뒤에도 쓸모가 있을 거예요.

정보 확인일: 2026-10-14

• 한국산업인력공단 큐넷 – 정보처리기사 시험일정
• Python 공식 문서 – Expressions (Binary arithmetic operations)
• Oracle – Java Language Specification SE 21, Chapter 15 Expressions
• cppreference – C 산술 연산자(나눗셈·나머지·포인터 연산)
• cppreference – C 평가 순서와 정의되지 않은 동작
• cppreference – C 연산자 우선순위
• PostgreSQL 공식 문서 – Aggregate Functions
• PostgreSQL 공식 문서 – SELECT 처리 순서