SW Certi. Expert 시험에 대해

삼성 SW Certificate Expert 시험에 대해#

2017년에 입사한 이후로, 나는 꾸준히 S/W Expert 시험에 도전하고 있다. 2026년 3월 기준으로 37번째 시험을 봤다. 꽤 어마어마한 장수생일 것이다. 이 시험은 두 달에 한 번 열리는데, 코로나 시기에는 아예 시험이 중단되었으니 사실상 열릴 때마다 거의 빠짐없이 응시해온 셈이다.

처음 이 시험을 접했을 때는 불만이 꽤 많았다. 나는 PS(Problem Solving)를 좋아하는 편이고, 문제 해결 능력을 평가하는 시험 자체에 대해서는 거부감이 없었다. 오히려 그런 시험이 존재하는 건 당연하다고 생각하는 쪽이었다. 다만 시험의 형태가 내가 기존에 경험해왔던 것과는 많이 달랐다.

회사 밖에서 흔히 접하는 PS 문제들은 대부분 다항 시간 내에 최적해를 구할 수 있는 문제들이다. 그런데 이 시험에서는 최적해를 보장할 수 없는, 이른바 NP 스타일의 문제가 출제된다. 정확한 정답이 있는 것이 아니라 점수로 평가되는 형태고, 그 점수를 기준으로 1~2명만 합격하게 된다. DS 부문 기준으로는 합격자가 없는 경우도 종종 있다.

이런 구조가 처음에는 낯설게 느껴졌다. 회사 밖에서는 잘 다루지 않는 유형의 문제를 왜 시험으로 보는 걸까 하는 생각도 들었다. 평가 방식 역시 쉽게 납득이 되지 않았다. 전산에서는 보통 몇 초 차이를 따지기보다는, 문제가 어느 정도 규모까지 현실적으로 해결 가능한지를 더 중요하게 본다고 생각해왔다. 그런데 이 시험에서는 미세한 점수 차이로 순위가 갈리고, 그 결과로 합격 여부가 결정된다. 그 당시에는 이런 방식이 다소 과하게 느껴졌던 것도 사실이다.

그런데 시험을 계속 보다 보니, 내가 부족한 부분들이 훨씬 명확하게 보이기 시작했다. 단순히 아이디어를 떠올리는 것만으로는 점수가 나오지 않았고, 그걸 실제로 끝까지 구현해서 결과로 만들어내야 했다. 그 과정에서 생각과 구현을 따로 가져갈 수 없다는 걸 계속 확인하게 됐다.

그리고 그런 과정에서 얻은 것도 많았다. 제한된 시간 안에 수많은 변수를 다루면서, 어떤 상태를 유지해야 하는지, 무엇을 버려야 하는지, 어디까지 계산하고 어디서 멈춰야 하는지를 계속 고민하게 된다. 내가 평소에 놓치고 있던 부분들이 그대로 드러났고, 그걸 하나씩 메우는 과정 자체가 의미가 있었다.

생각해보면 실제로 현업에서 다루는 문제들도 크게 다르지 않다. 최적해가 명확하게 존재하는 문제보다는, 여러 조건을 만족시키면서 최대한 좋은 결과를 만들어야 하는 경우가 훨씬 많다. 다뤄야 하는 변수도 많고, 상태도 복잡해서 항상 헷갈린다. 그런 점에서 이 시험이 다루는 문제의 형태는 오히려 실제 업무와 더 가까운 쪽이라고 생각한다.

구현과 생각은 분리되지 않는다#

개발은 결국 생각과 구현이 같이 간다고 생각한다.

“생각은 했는데 구현을 못했다”는 말은 솔직히 전혀 공감되지 않는다.

시험을 보고 나오면 항상 이런 말이 나온다.

(1등 풀이법을 보며) “아… 생각은 똑같이 했는데 구현을 못했네요.”

그건 구현 문제가 아니다. 끝까지 밀어붙일 수 있는 형태로 생각이 정리되지 않은 것이다. 구현은 단순한 작업이 아니다. 문제 해결 능력 그 자체다.

실수 없이 코드를 작성하는 능력
복잡한 상태를 정확하게 관리하는 능력
예외 상황을 빠짐없이 처리하는 능력
제한 시간 안에 결과를 만들어내는 능력

이건 전부 구현에서 드러난다. 그리고 전부 생각과 연결되어 있다.

“실수했다”는 말도 마찬가지다.

실수는 그저 구현을 조금 잘못한게 아니다. 생각이 잘못된 것이다. 애초에 실수할 수 없는 구조로 생각해서 짜야 한다. 구현력이 부족하다는 건 손이 느린 문제가 아니다. 생각한 것을 끝까지 밀어붙여 완성할 수 있는 힘의 문제다.

나는 개발을 이렇게 생각한다.

개발 = 생각 + 구현

무엇을 만들지 생각하고, 그걸 손에서 뽑아내는 것!

이 둘은 분리되지 않는다.

STL이 없는 환경에서 배운 것들#

이 시험에서는 STL을 사용할 수 없다.

처음에는 불편했다. 왜 이런 환경까지 강제하는지 이해가 가지 않았다. 하지만 계속 문제를 풀다 보니, 오히려 얻는 것이 더 많았다.

cache hit을 고려하게 되고, 메모리 구조를 의식하게 되고, 불필요한 접근을 줄이게 된다. 기본적인 알고리즘을 직접 구현하면서, 단순히 라이브러리를 사용하는 것과는 다른 감각이 생긴다. 평소에는 크게 의식하지 않던 부분들이지만, 제한된 환경에서는 이런 것들이 그대로 성능 차이로 이어진다.

변수 하나에도 체계가 필요하다#

이 시험은 변수 개수가 많다. 조금만 복잡해져도 수십 개가 된다. 이 상태에서 변수명을 대충 지으면 바로 문제가 생긴다.

“이 변수 내가 왜 만들었지?”

이 생각이 드는 순간 흐름이 끊긴다.

그래서 나는 변수 관리를 위해 몇 가지 기준을 두고 있는데, 그 중 하나가 “이 배열에 무엇을 넣으면 무엇이 나오는지”를 이름으로 표현하는 방식이다.

예를 들면, pid_by_cid[cid]는 cid를 넣으면 pid가 나오고, pid_list_by_lid[lid][i]는 특정 물류창고 기준으로 묶인 상품 리스트다. pid_by_cid_by_lid[lid][cid]처럼 여러 조건이 들어가는 경우도, 이름만 보면 어떤 입력에 어떤 값이 나오는지 바로 알 수 있게 만든다.

이렇게 해두면 내가 이 변수를 실제로 만들었는지 기억이 안 나더라도, 그냥 있다고 생각하고 자연스럽게 코드를 작성할 수 있다. 있으면 그대로 쓰면 되고, 없으면 Visual Studio에서 바로 표시해주기 때문에 그때 추가하면 된다. 코드를 읽을 때도 흐름이 자연스럽게 이어진다.

이건 여러 가지 방법 중 하나지만, 이런 식으로 규칙을 만들어두는 것이 복잡한 상태를 다루는 데 도움이 된다.

이 블로그에서 다룰 것들#

회사 정책상 시험 문제나 구체적인 풀이를 외부에 공개할 수는 없다. 그래서 문제 자체를 다루지는 못하지만, 이 시험을 준비하면서 자주 사용하게 된 코드나 방법들을 정리해보려고 한다.

다음과 같은 것들을 정리해보려고 한다.

Merge Sort / Counting Sort (Radix Sort)
Bitmask DP (TSP, Hamiltonian Path)
2차원 좌표 CCW 정렬
사각형 겹침 및 포함 조건
변수명 체계
자주 사용하는 상수
문제 접근 방식
기타 등등 …

아직 합격하지 못했다#

요즘 계속 공부하면서 나름 성장하고 있다고 생각한다. 그런데 그게 아직 결과로 이어지진 못했다. 이제는 그게 그대로 점수로 나왔으면 좋겠다.

올해는 꼭 합격하고 싶다.