이 글은 2026년 3월 19일, 크래프톤 정글 SW 12기 과정을 기록하며 처음 작성했습니다. 2026년 7월 Velog로 이관했으며, 당시 내용은 유지하고 가독성을 위한 서식만 정리했습니다.
관련 역량: 구현, 품질, 설계
구현 대상은 자료구조(스택, 큐, 덱, 연결 리스트)와 알고리즘(병합 정렬, 퀵 정렬, 이진 탐색, 분할정복)이다.
주차 초반에 기본 구현을 마치고, 이후 제한 시간을 두고 문제 풀이 또는 핵심 기능을 재구현하는 방식으로 진행한다.
기본 구현을 마친 후, 연결 리스트와 힙을 외부 자료 없이 구현할 수 있도록 반복 연습했다. 병합/퀵 정렬도 마찬가지로 반복 구현했다.
연결 리스트, 병합/퀵 정렬은 문제없이 구현 가능해졌다. 퀵/병합 정렬의 개념이 예상보다 어렵지 않아서 체감 난이도가 낮았다.
힙은 연습량이 부족해서 아직 불완전하다. 남에게 설명할 수 있을 정도까지 추가 복습이 필요하다. 현재 코스의 작업을 유지하는 선에서 지금까지 배운 알고리즘을 가볍게 복습해 볼 계획이다.
Week 2에는 한 문제에 너무 많은 시간을 할당했다. 알고리즘 자체의 이해가 아닌 특정 유형의 풀이에 시간을 오래 쓰는 건 비효율적이다.
관련 역량: 문제해결, 학습 민첩성, AI 활용
문제당 30분 제한 시간 타이머를 설정한다. 소요 시간과 사고 흐름(접근 방식, 막힌 지점)을 주석으로 기록하고, 시간 내 해결한 문제 수를 기록하여 Week 02 대비 개선 여부를 확인한다.
매번 타이머를 켜고 작업하는 습관을 들이려 했으나, 외부 요인으로 멈추거나 끄는 걸 잊어서 정확한 측정이 어려웠다.
각 문제 파일별로 기록용 템플릿을 추가해서 문제 풀이 흐름을 메모했다.
# 템플릿 예시
# =============================================
# 문제: 그래프, DFS, BFS - 점프왕 쩰리 (백준 실버4)
# 링크: https://www.acmicpc.net/problem/16173
# AI 사용 횟수:
# AI 사용 방법:
# 목표 시간: 15분
# 실제 시간:
# 1. 초기 접근
#
# 2. 풀이 전략
#
# 3. 막힌 점 / 실수
# 유형: [접근법] [구현] [엣지케이스] [최적화]
#
# 4. 최종 코드
import sys
...
접근법 자체는 맞았지만, 구현 실수를 찾는 데 시간이 많이 소모되는 경우가 있었다(예: 뱀 문제).
이전보다 문제당 소요 시간은 줄었지만, 뱀 문제처럼 반나절이 걸린 경우도 있었다.
다만 디버깅을 통한 원인 파악 경험은 필요하므로, 구현 정확도와 목표 동작을 명확히 정의해 전체 해결 속도를 높이고, 디버깅 자체를 줄이기보다 문제 정의를 명확히 해 디버깅 시간을 줄여야 한다.
템플릿을 쓰니 문제 풀이 이후에 접근 방식이나 사고 과정을 복기하기 좋았다.
하지만 Jungle Bell 개발에 시간을 써서 전 주차에 비해 문제를 푸는 양은 거의 동일했다(이건 아래 회고에서 설명).
AI 기반 분석에서 다음과 같은 피드백이 나왔는데, 정리하여 다음 주 계획에 반영 예정이다.
1. 예제를 대충 보는 경향이 있으므로 여러 예제를 손으로 돌려보며 다양한 케이스를 고려할 것.
2. 분석은 맞는데 구현 시 조건을 놓치므로 지문 조건을 주의 깊게 보면서 코딩할 것.
이진혁 님이 만든 스터디에 참여했다. 이런 책 스터디는 처음 해보는데, 서로 놓친 부분을 짚어주는 과정에서 이해도가 올라가서 좋았다.
CS 스터디 정리도 작성 중. 책 내용을 그대로 정리하는 게 아니라, 따로 찾아본 내용이나 스터디 때 인상 깊었던 주제를 정리하고 있다.
팀원들이 아는 게 많아서 딱히 정리해서 공유할 만한 게 없었다.
지난 주차와 달리 다들 알고리즘을 아는 상태여서, 처음 목표로 잡았던 잦은 자료 공유를 지킬 필요가 없었다.
그래서 협업 목표는 팀 상황에 따라 유동적으로 가져가는 게 좋겠다는 생각을 했다.
첫 스크럼 전에 협업 목표를 미리 정하는 건 큰 의미가 없을 것 같다. 세우더라도 시간 엄수 같은, 어디서나 적용 가능한 목표 정도가 적절해보인다.
3주차 수요코딩회의 목표는 미니 Redis를 구현하는 것이었다.
팀원들이 최대한 이해할 수 있도록 기능 구현을 줄이고 코드를 최소한으로 유지했는데, 이게 효과적이었는지는 잘 모르겠다.
돌이켜 보면, 요구사항과 엣지케이스를 깊게 파고들면서 구현 원리를 이해하는 방향이 더 나았을 것 같다.
이런 고민을 통해 Redis의 실제 구현과 비교하면서, 일부 기능이라도 딥다이브해서 정확하게 구현해보는 게 더 깊은 이해로 이어졌을 것이다.
개발을 배우는 거지 얕게 훑으려는 게 아니니까, 내부 원리를 CS 지식과 연결해서 배우는 시간으로 활용했으면 어땠을까 하는 아쉬움이 있다.
3번째 팀이라 앞 팀의 구현 관련 질문이 많아서 넘어갔지만, 안 그랬으면 구현도 부족하고 깊은 이해도 없다는 평가를 받았을 수 있다.
다음에는 코드 자체에 집중하기보다 구현 원리를 이해하고, AI에게 설명하면서 검증하는 방식이 더 높은 효율을 보여주지 않을까 싶다.
Jungle Bell이라는 서비스를 만들었는데, 반응이 좋았다.
같은 반에서 팀을 하지 않았던 분들도 설치해서 문의해주셔서 감사했다. 유지보수를 꾸준히 해야겠다는 생각이 든다.
다만 만드는 게 재밌어서 시간을 많이 쏟아버렸고, 알고리즘 목표를 달성하지 못했다.
실 사용자가 있는 서비스를 만드는 경험은 좋지만, 정글 코스에 집중하지 못하는 건 문제다.
개선 방안: 다음 주에는 태스크를 작게 쪼개서, 점심 시간이나 필수 학습 시간 외에만 개발하고, 그 외에는 알고리즘에 집중하도록 할 계획.