삼성 S/W 역량테스트 Level B (삼성 B형) 응시 후기 (SSAFY)

 

안녕하세요.

올해부터 싸피 15기를 다니게 되었고, 싸피를 통해서 B형 시험에 응시 할 수 있었습니다. 

저는 지난 26년 3월 14일(토)에 역량테스트를 볼 수 있었고 다행히 합격하게 되어, 제 경험을 공유하고자 후기를 작성합니다.

B형 시험에 관심이 있으신 분들, 추후 B형 시험에 응시하시는 분들께 도움이 되었으면 좋겠습니다.

 

야호~

* B형 있는데 왜 또 보셨나요?

사실, 저는 이미 B형을 취득했었습니다. (관련 포스팅)

이미 있음에도 불구하고 이번 검정에 응시한 이유는, B형 만료기간 때문이었습니다. 

B형은 2년의 유효기간을 가지고 있습니다. 기존 B형은 2024년에 여름에 취득했었고, 올해 여름에 만료될 예정이었습니다.

취준생 신분이라 기회가 될때마다 삼성전자에 지원하고 있는데, 올해 상반기가 B형을 마지막으로 활용할 수 있는 기회였습니다.

혹여 이번 삼성전자 상반기 공채에 떨어질 수도 있기도 하고, 싸피에서 B형 붙으면 마일리지도 챙겨준대서... 겸사겸사 보험 느낌으로 응시했습니다. 

 

 

* 입과 전 알고리즘 경험

대학교 재학시절 알고리즘 공부를 꽤 많이 했었습니다. 솔브드 기준 백준 다이아5입니다. (티어만 높습니다...!)

백준 티어가 전부는 아니지만, 특히 B형에서는 백준 티어보다는 구현을 얼마나 잘하느냐가 더 중요한 것 같습니다.

플로우, SCC 등 대회 알고리즘을 많이 안다고 B형 문제를 풀 수 있는 것은 절대 아니라는 말씀을 드리고 싶습니다.

 

언어는 기존에 Cpp를 해왔어서 Cpp로 진행했습니다. 싸피에서 Java를 배우긴 했지만, 아직은 Cpp가 익숙하더라구요.

 

 

* 가장 중요한 것은 B형 문제를 최대한 많이 풀어보는 것

누가 모르겠냐만은,, 문제 푸는 것 만큼 도움되는 게 없다고 생각합니다. 풀 수 있는 B형 문제가 많다면 양치기로도 충분히 딸 수 있는 시험이라고 생각합니다.  

 

싸피 내에서는 교육생들의 B형 취득을 위해 여러 방면으로 도와주고 있습니다. B형 특강을 진행하기도 하고, 무엇보다 좋았던 것은 SWEA 내에 B형 문제를 모아놓은 클럽에 가입할 수 있다는 것입니다. 

외부인이 B형 문제를 풀려면 아마 매 방학마다 대학생 대상으로 진행하는 삼성전자 DX 알고리즘 특강이 유일한 것으로 알고 있습니다. 이런 면에서 B형 준비를 위해선 싸피가 최적의 환경인 것 같습니다.

저는 자격이 없었어서 싸피 B형 특강은 듣지 못했는데, 기회가 된다면 해볼 것을 추천드립니다. 주변 싸피 동기들 말 들어보면 도움이 많이 된다고 하더라구요. 

 

풀 B형 문제가 없다면... 백준 플레 이상 구현문제들을 주구장창 푸는 것도 충분히 도움이 될 것 같습니다. 

 

 

* 이번 검정 어땠나요? 

이번 시험 문제는 B형 문제 중에서도 쉬운편에 속한다고 생각합니다. 

설계 30분, 구현 1시간, 최적화 1시간씩 써서 총 2시간 반 정도 걸린 것 같습니다. 

운 좋게 쉬운 문제가 나왔고, 운 좋게 발상이 금방 떠올라서 빠르게 구현할 수 있었던 것 같습니다. 

제출 직전에 테스트케이스 돌렸을 때 0.32~0.35초 정도로 나왔던걸로 기억합니다. 

 

 

---

이 아래부터는 제가 B형 문제를 푸는 과정? 방법? 스타일? 팁? 입니다.

사람마다 푸는 방법이 다 다를 것이고, 저보다 더 나은 방법도 있을 수 있습니다! 그냥 참고로만 봐주시면 감사하겠습니다!

 

1. 설계

1-1. 절대 한 시간동안 키보드에 손을 대지 말 것

한 시간이라고 쓰기는 했지만, "모든 설계를 완벽하게 마친 뒤에 코드 작성을 시작해라"라는 의미로 받아들이셨으면 좋겠습니다. 설령 30분 만에 설계가 끝났다면 바로 구현하셔도 되지만, 한시간을 써도 풀이가 떠오르지 않는다면 두시간, 세시간을 써서라도 반드시 설계를 끝내셨으면 좋겠습니다. (어차피 설계 못 끝내고 키보드를 잡아도 구현 못할 확률이 높습니다..)

무턱대고 구현하시면서 생각하시게되면, 물론 운이 좋다면 풀릴 수도 있겠지만, "어? 이렇게 하면 안되네?", "이렇게 하니까 시간초과나네?"며 코드 고치다가 시간 다 갑니다. 경험담입니다.

 

주변에 B형 보는 동기들이 팁 달라고 할때마다 무조건 이 얘기부터 합니다. 정말정말정말 중요하다고 생각합니다...

 

1-2. 이면지 잘 활용하기

문제를 읽고, 요구사항을 상세히 파악하는 건 당연한 것이고, 구현하기 전에 어떻게 설계할 지를 먼저 고민해야 합니다. 가장 기초적이면서 가장 중요한 점이라고 생각합니다. 

그래서 설계 단계에서 이면지를 적극적으로 활용하셨으면 좋겠습니다. 

 

저의 경우에는 문제를 1회독 하고, 구현해야 할 함수들을 쭉 작성하면서, 문제를 "나의 언어"로 번역하는 것부터 시작합니다.

함수명부터. 

매개변수로는 뭐가 들어오며 값의 범위가 어떻게 되는지.

어떤걸 리턴하는 지.

함수가 테스트케이스에서 최대 몇 번 호출되는지.

함수 시간복잡도는 얼마 아래로 잡아야하는지.

N,M,K의 범위는 몇인지.

이걸 먼저 써 놓고, 본격적으로 설계하는 편입니다. 

 

1회독에서 파악하지 못한 디테일들을 손으로 쓰면서 발견할 수도 있고,

종이에 쓴걸 다시 읽으면서 요구사항을 한눈에 파악하는 것도 꽤 도움이 됐습니다. 

 

문제 지문이 꽤 길다보니 한 화면에 다 못담습니다.

특히 함수 호출 횟수는 문제 맨 밑에 있어서 스크롤 오르락내리락하는게 많이 귀찮습니다...

 

이면지 2장 주는데, 종이 아끼지마세요! 

 

 

1-3. 본격 설계

이면지 내용을 바탕으로 본격적인 설계에 들어갑니다. 

문제를 쓰면서 "어? 이거 쓰면 될 것 같은데?"하는 알고리즘이 있다면 옆에 써두고, 그거에 맞춰서 시간복잡도를 계산해봅시다. 

예를 들면, 구간을 업데이트 해야한다면, [1. 구간을 다 도는 방법]이 있을 수도 있고, [2. Lazy Propagation]이나, [3. 차분 배열]을 떠올려 볼 수 있을겁니다. 답이든 아니든, 1초에 연산 1억번 한다 치고 시간복잡도를 계산해봅니다. 

 

바로 되면 땡큐!하고 넘어가고, 만약 "어? 이건 1초에 안돌겠는데?"하는 API가 있다면, 저의 경우 두 갈래로 나뉩니다.

1. 해당 API부터 다시 설계

2. 기존 방식에서 디벨롭

 

1번 방식은 크게 설명할 게 없을 것 같고, 2번 방식의 경우에는,

A함수에서 시간초과가 난다면, "A에서 할 연산을 B함수, C함수에 분배할 수는 없을까?"를 고민하는 편입니다. 

만약 "A함수에서 정렬을 해야하는데 시간초과다!"라면, "B함수, C함수에서 정렬을 미리 해둘수는 없을까?", "TreeSet이나 PriorityQueue로 애초에 정렬해서 보관할 수는 없을까?"로 사고를 뻗어갑니다.

 

 

1-4. 설계 마무리 및 구현 디테일 잡기

이렇게 어떤 방식으로 구현할 지 생각이 끝났다면, 이제 디테일한 부분을 잡아갑니다.

어떤 전역변수를 쓸지, 변수 이름, 자료형, 배열이라면 인덱스 크기까지 종이에 씁니다. 

그리고 해당 전역변수를 어떤 API가 참조해야하는 지, API에서는 전역변수로 어떤 연산을 할지를 대략적으로나마 적어놓습니다. 

만약 한 API 안에서 구현할 게 많다면, API 내 일부 로직을 함수로 빼놓는 것도 디버깅 측면에서 유용합니다. 

 

그리고 구현해야할 API 안에 어떻게 코드를 작성할지 대략적으로 끄적여봅니다. 이 과정이 구현 시간 단축에 도움이 많이 됐습니다. 또, 구현 전에 내 설계가 사실 틀렸다는 것을 찾을 수도 있구요!

 

 

2. 구현

2-1. 구현하기

앞서 이면지로 적었던 내용을 그대로 구현하면 됩니다. 가끔 이 단계에서 1-4에서 설계했던 내용에서 빈틈을 발견할 수도 있는데, 다시 1-4로 돌아가서 틈을 메웁시다.

 

 

2-2. 테스트케이스 분석 잘하기

구현이 완료됐다면 테케를 돌려봅시다. 

여러 B형 문제를 풀다보면, 제공되는 input.txt의 내용이 크게 다르지 않습니다. 보통 첫줄은 항상 같고, 다음 줄부터 쿼리 수, 그리고 쿼리가 주어집니다. 쿼리는 보통 아래처럼 구성되어 있습니다.

[ (호출할 함수 번호) (함수 매개변수 1) (함수 매개변수 2) … (함수 리턴값 1) (함수 리턴값 2) … ]

이게 무슨 의미인지 와닿지 않으신다면, Main.cpp를 한번 읽어보시면 이해가 되실 것 같습니다. 

 

 

2-3. Main.cpp 수정 / 디버깅용 출력

IDE 디버깅 툴을 잘 쓰실 수 있으시다면 상관없지만, 저는 그냥 출력해서 디버깅합니다. 

채점환경의 Main.cpp는 바꿀 수 없지만, 로컬에서 돌릴때는 필요하다면 임의로 수정합니다. 기존 Main에서는 API에서 원하는 리턴값을 못받으면 okay같은 변수를 true에서 false로 바꾸는데, 바뀔때 cout<<"@@@@@@\n";를 걸어둔다거나,아예 프로그램을 종료시킬 수도 있습니다. 

 

User.cpp의 경우에는 디버깅용 출력문을 작성하는 편입니다.

예를들어 sum(int a,int b)를 호출했다고 하면, 

cout<<”\t SUM : “<<a<<’ ‘<<b<<’\n’;

cout<<”\t RESULT : “<<result<<’\n’;

를 각각 함수 맨앞, 맨뒷줄에 적어놓습니다. 

이렇게 쓰고 cmd에서 출력값을 보면서 동작이 제대로 되고있는지 디버깅합니다.

(물론 제출시에는 다 지워야합니다!!)

 

 

2-4. 테스트케이스 맞추기

input.txt의 첫번째 테케는 문제에서 예제로 보여줄거고, 

첫번째 테케만 먼저 돌려봅니다. 잘 된다면 두번째, 세번째 테케까지도 한번 돌려봅니다. 

틀린게 있다면 디버깅하면서 코드를 고칩니다. 두번째 테스트케이스까지는, 조금 무리하면 세번째 테케까지는 손으로 쓰면서 따라갈만 합니다.

 

세번째 테케까지도 맞다면 전체 테케를 돌려봅니다. 코드 실행하고 터미널에 input.txt를 복붙하면, 파일 내용자체가 너무 많아서 출력하는데 좀 걸립니다. 그래서 전체 테케를 돌릴때는 B형 브라우저에 코드 올려서 돌려보는 걸 추천합니다.

 

 

2-5. 코드 정리

예제 테스트케이스가 제한시간 안에 전부 잘 돌아가나요? 축하합니다! 정말 다 왔습니다!

간단하게 코드 정리만 하고, 1차 제출을 진행합니다. 

기존 출력 코드를 전부 지우고, 안쓰는 변수가 있다면 지워줍니다. 

 

코드 제출은 10번까지 가능하니까, 돌아가는거 일단 제출해봅시다. 

제출하면 제출결과가 뜨는데, 이상이 없다면 이제 다음 단계인 최적화를 진행합니다.

 

 

3. 최적화

3-1. 라이브러리 하나씩 지워보기

지금 코드에서 include된 라이브러리 중 안쓰는 라이브러리나, 스스로 구현이 가능하다면 제거해줍니다. 

예를들어 좌표 관리를 위해 pair, tuple같은 라이브러리를 쓰고있다면, 구조체로 새로 구현하는게 조금 더 빠릅니다. (드라마틱한 차이는 없습니다..!) 

 

특히 set, unordered_set, map, unordered_map은 느린 편이라 배열로 바꿀 수 있다면 바꾸는 걸 추천합니다.

map으로 접근하면 O(logN)인데, 배열 인덱스로 접근하면 O(1)이니까 당연히 빨라지겠죠? 

unordered_map도 O(1)이지만 상수가 크기 때문에 이왕이면 배열을 쓰는게 좋습니다. 

 

 

3-2. 반복문 줄이기

for(int i=0;i<n;i++) arr[i] = 0;
for(int i=0;i<n;i++) vis[i] = 0;

이렇게 똑같은 for문을 두 번 돌리는 것보다

 

for(int i=0;i<n;i++) arr[i] = vis[i] = 0;

이렇게 반복문 한번에 쓰는게 더 빠르겠죠? 

 

API의 특정 기능을 함수로 빼면서 반복문이 한번 더 돌아가고 있다면, 함수로 빼둔걸 다시 API 안에 넣어줘서 조금 더 빠르게 해볼 수 있습니다.

 

 

4. 제출

하나씩 최적화하고, 예제도 돌려보면서 실행시간이 줄어드는 것을 확인합니다.

같은 코드여도 돌릴 때마다 시간이 조금씩 달라서 여러번 돌리면서 대충 가늠해봅니다. 

 

이제 완벽하다, 더 이상 할 게 없다면 시원하게 제출하고 끝냅시다! 수고하셨습니다!

 

 

---

마치며

B형을 지금까지 3번 보면서 개인적으로 느낀 것은, 운도 중요하다는 점입니다. 

시험마다 난이도 편차가 꽤 크다보니, 운이 나쁘면 레이지 세그 같은게 나와서 디버깅하다가 시간 다 가고, 운이 좋으면 단순 빡구현 문제가 나와서 구현만 제대로 하면 풀 수 있는 문제가 나옵니다. 

운이 좋아서 지난번에 푼 유형과 비슷한 문제가 출제될 수도 있고, 

운이 좋아서 구현을 한번에 끝낼 수도 있구요. 

 

그러니 혹여 B형에 떨어졌다고 낙담하지 마시고, 자책하시지 않으셨으면 좋겠습니다.

"아 그냥 내가 운이 없었나보다."하며 넘기시고 다음을 도모하셨으면 좋겠습니다. 

꾸준히 하던 대로 준비하시면 다음엔 무조건 좋은 결과 있으실 거예요. 정말 고생 많으셨습니다.

 

 

긴 글 읽어주셔서 감사합니다!