코딩 테스트, '맨땅에 헤딩'을 멈추기로 했다
들어가며: 왜 나는 같은 벽에 부딪히는가
게임 서버 개발자로 약 4년 안되는 기간을 일했습니다. 트래픽을 처리하고, DB를 튜닝하고, 아키텍처를 고민하는 일에는 꽤 익숙합니다. 그런데 아이러니하게도 '코딩 테스트' 문제 앞에만 서면 다시 1학년 학부생이 된 기분이 듭니다.
변명 아닌 변명을 하자면, 저는 첫 회사를 코딩 테스트 없이 기술 면접과 포트폴리오만으로 입사했습니다. 그렇다 보니 지난 4년간 알고리즘 문제 풀이의 중요성을 깊게 체감할 기회가 없었습니다. "개발자는 실무만 잘하면 되지"라는 안일한 생각도 있었던 것 같습니다.
하지만 최근 이직 준비를 본격화하면서 알고리즘 문제 풀이를 다시 시작했습니다. 시중에 알려진 정석대로 공부했습니다. 문제를 읽고, 고민하고, 안 풀리면 더 고민하고, 몇 시간을 끙끙대다 결국 해설을 보고 좌절하는 반복.
문득 이런 생각이 들었습니다. "이게 정말 효율적인 학습일까? 내가 실무에서 문제를 해결하는 방식과 너무 다르지 않나?"
실무에서 우리는 새로운 기능을 만들 때, 모든 로직을 바닥부터(Zero-base) 창조하지 않습니다. 이미 검증된 '디자인 패턴'을 참고하고, 상황에 맞는 '아키텍처'를 선택합니다. 그런데 왜 코딩 테스트 공부는 무조건 스스로 발명해 내야 한다고 생각했을까요?
그래서 저는 오늘부터 공부 방법을 개선하기로 했습니다. 이 글은 그 실험의 시작을 알리는 기록입니다.
'창의력'이라는 함정
기존의 공부법이 나에게 맞지 않았던 이유는 명확합니다.
- 시간 대비 효율(ROI)이 낮다: 한 문제에 2~3시간을 쏟아도, 막상 남는 건 "나는 왜 이걸 생각 못 했지?"라는 자괴감뿐이었습니다.
- 지식이 휘발된다: 억지로 푼 문제는 며칠 뒤에 다시 보면 또 새롭습니다. 체계적인 '정리'가 없었기 때문입니다.
- 목적의 전치: 코딩 테스트는 '제한 시간 내에 요구사항을 구현하는 능력'을 보는 시험이지, 수학적 난제를 해결하는 창의력 대회(경시대회)가 아닙니다.
알고리즘도 '패턴'이다
저는 앞으로의 학습 방향을 '문제 해결(Problem Solving)'에서 '패턴 인식(Pattern Recognition)'으로 전환하려 합니다.
우리가 MSA(마이크로서비스) 구조가 필요할 때와 Monolithic 구조가 필요할 때를 구분하듯, 알고리즘 문제도 "이 문제는 DFS 패턴이 적합해", "이건 해시(Hash) 패턴이야"라고 판단하고, 미리 준비된 도구(Code Snippet)를 꺼내 쓰는 훈련을 할 것입니다.
이 가설의 핵심은 다음과 같습니다.
코딩 테스트는 문제를 '푸는' 것이 아니라, 문제의 유형을 '읽어내고' 가장 적절한 알고리즘을 '매칭'하는 과정이다.
나의 실험 계획: '콜드 스타트'부터 시작하기
서버를 처음 띄울 때 캐시가 비어있으면(Cold Start) 요청 처리가 느릴 수밖에 없습니다. 지금 제 머릿속 알고리즘 캐시는 텅 비어있는 상태입니다.
따라서 무리하게 바로 '15분 테스트'를 돌리는 대신, 점진적인 온보딩(Onboarding) 과정을 거쳐 트래픽(문제)을 감당할 수 있는 상태로 만들 계획입니다.
1단계. 데이터 주입 - "그냥 베껴 쓰기"
처음 접하는 유형(예: 다익스트라, 플로이드 워셜)은 고민하지 않겠습니다.
- 문제를 읽고 바로 정답 코드를 띄웁니다.
- IDE에 코드를 한 줄씩 필사(Transcription)합니다.
- 각 라인마다 왜 이 코드가 필요한지 주석을 달며 논리 흐름을 입력합니다.
2단계. 오픈 북 테스트 - "참고하며 풀기"
기본적인 문법과 흐름이 익숙해지면, '공식'을 옆에 펴두고 문제를 풉니다.
- 마치 레고 조립 설명서를 보듯, 미리 정리해둔 '패턴 템플릿'을 보며 문제에 맞게 변형하는 연습을 합니다.
- 이 단계의 목표는 암기가 아니라 '적용(Application)'입니다.
3단계. 타임 박싱 - "15분 컷 도전"
어느 정도 패턴이 손에 익으면 비로소 엄격한 룰을 적용합니다.
- 아무런 참고 자료 없이 문제를 마주합니다.
- 15분 내에 접근법(알고리즘 종류, 로직 설계)이 떠오르지 않으면 중단합니다.
- 다시 해설을 보고 부족한 '연결 고리'를 찾아 보완합니다.
저는 이 과정을 통해 '무작정 헤딩'하는 고통을 줄이고, '지식을 체계적으로 쌓아 올리는' 즐거움을 찾아보려 합니다.
시스템 구축: 분석과 자산화의 자동화
문제를 푸는 것만큼 중요한 것은 '어떻게 분석하고, 이를 어떻게 기록하여 내 자산으로 남길 것인가'입니다. 당장 제게 필요한 것은 알고리즘과 패턴에 대한 양질의 학습 데이터입니다. 단순히 문제를 풀고 정답을 맞히는 것에서 멈추면 그 지식은 곧 휘발되어 버립니다.
따라서 저는 특정 문제를 분석하는 방법론을 정립하고, 각 문제 유형에 필요한 알고리즘 패턴을 학습한 뒤, 해당 패턴의 다양한 변형(Variation)까지 체계적으로 기록하려 합니다.
이 과정을 효율적으로 만들기 위해, 저는 AI 에이전트를 파트너로 삼아 다음 세 가지 커스텀 커맨드를 활용할 계획입니다.
1. 문제 분석 (/cote.analysis)
문제를 마주했을 때 무작정 키보드에 손을 올리는 대신, 에이전트와 함께 문제를 해부합니다.
- 문제의 본질 파악: 문제의 제약 조건과 핵심 요구사항을 분석합니다.
- 알고리즘 매칭: "왜 이 문제에 BFS가 적합한가?"에 대한 논리적 근거를 찾고, 시간 복잡도를 고려한 최적의 알고리즘을 선정합니다.
- 전략 수립: 코딩 전, 전체적인 로직의 흐름을 설계합니다.
2. 패턴 자산화 (/code.snippet)
학습한 내용은 언제든 꺼내 쓸 수 있는 '도구'가 되어야 합니다.
- 스니펫 생성: 해당 문제 유형을 관통하는 핵심 로직을 재사용 가능한 코드 조각(Snippet)으로 만듭니다.
- 바리에이션 기록: 같은 알고리즘이라도 문제 상황에 따라 달라지는 구현의 디테일(Edge case 등)을 함께 정리합니다.
이렇게 축적된 스니펫들은 저만의 '알고리즘 라이브러리'가 되어, 향후 비슷한 문제를 만났을 때 고민하는 시간을 획기적으로 줄여줄 것입니다.
3. 풀이 리뷰 (/cote.review)
실전 문제를 풀고나서, 에이전트와 함께 풀이 과정을 리뷰합니다.
- 코드 리뷰: 작성한 코드의 효율성과 가독성을 평가합니다.
- 문제 정리: 풀이 과정을 정리하여, 향후 다시 풀 때 참고할 수 있도록 합니다.
- 비편적 평가: 칭찬보다는 비판적이고 건설적인 피드백으로 인사이트를 얻을 수 있도록 합니다.
마치며
앞으로 이 블로그의 [Algorithm] 카테고리에는, 제가 문제를 풀며 수집한 '유형별 공략 패턴'과 '실패와 성공의 기록'들이 쌓일 것입니다.
이 방식이 무조건 옳다는 확신은 아직 없습니다. 하지만 무작정 시간을 쏟는 '양치기'보다는, 개발자답게 시스템을 분석하고 공략하는 이 방식이 훨씬 더 멀리 갈 수 있으리라 믿습니다.