Week 03: 컴퓨팅 사고로의 전환

분할정복/정렬과 선형 자료구조

핵심 역량 목표

목표 1. 외부 자료 없이 선형 자료구조, 정렬/분할정복 알고리즘 구현하기

관련 역량: 구현, 품질, 설계

계획

구현 대상은 자료구조(스택, 큐, 덱, 연결 리스트)와 알고리즘(병합 정렬, 퀵 정렬, 이진 탐색, 분할정복)이다.

주차 초반에 기본 구현을 마치고, 이후 제한 시간을 두고 문제 풀이 또는 핵심 기능을 재구현하는 방식으로 진행한다.

과정

기본 구현을 마친 후, 연결 리스트와 힙을 외부 자료 없이 구현할 수 있도록 반복 연습했다. 병합/퀵 정렬도 마찬가지로 반복 구현했다.

결과 및 피드백

연결 리스트, 병합/퀵 정렬은 문제없이 구현 가능해졌다. 퀵/병합 정렬의 개념이 예상보다 어렵지 않아서 체감 난이도가 낮았다.

힙은 연습량이 부족해서 아직 불완전하다. 남에게 설명할 수 있을 정도까지 추가 복습이 필요하다. 현재 코스의 작업을 유지하는 선에서 지금까지 배운 알고리즘을 가볍게 복습해 볼 계획이다.

목표 2. 많은 알고리즘 문제를 접하고 풀기

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. 분석은 맞는데 구현 시 조건을 놓치므로 지문 조건을 주의 깊게 보면서 코딩할 것.

WIL (What I Learned)

CSAPP / OSTEP 스터디

이진혁 님이 만든 스터디에 참여했다. 이런 책 스터디는 처음 해보는데, 서로 놓친 부분을 짚어주는 과정에서 이해도가 올라가서 좋았다.

CS 스터디 정리도 작성 중. 책 내용을 그대로 정리하는 게 아니라, 따로 찾아본 내용이나 스터디 때 인상 깊었던 주제를 정리하고 있다.

공유/정리용 노트 작성

팀원들이 아는 게 많아서 딱히 정리해서 공유할 만한 게 없었다.

회고

협업

지난 주차와 달리 다들 알고리즘을 아는 상태여서, 처음 목표로 잡았던 잦은 자료 공유를 지킬 필요가 없었다.
그래서 협업 목표는 팀 상황에 따라 유동적으로 가져가는 게 좋겠다는 생각을 했다.

첫 스크럼 전에 협업 목표를 미리 정하는 건 큰 의미가 없을 것 같다. 세우더라도 시간 엄수 같은, 어디서나 적용 가능한 목표 정도가 적절해보인다.

수요코딩회

3주차 수요코딩회의 목표는 미니 Redis를 구현하는 것이었다.

팀원들이 최대한 이해할 수 있도록 기능 구현을 줄이고 코드를 최소한으로 유지했는데, 이게 효과적이었는지는 잘 모르겠다.

돌이켜 보면, 요구사항과 엣지케이스를 깊게 파고들면서 구현 원리를 이해하는 방향이 더 나았을 것 같다.

  • 추가/삭제 요청이 네트워크 문제로 꼬이는 경우
  • 악의적 사용자의 트래픽 부하
  • 잘못된 포맷 검증
  • 영속성을 제공하더라도 디스크 장애가 발생할 때의 처리
  • Redis가 왜 빠른지, RDB나 MongoDB도 내부적으로 메모리를 쓰는데 왜 더 느린지

이런 고민을 통해 Redis의 실제 구현과 비교하면서, 일부 기능이라도 딥다이브해서 정확하게 구현해보는 게 더 깊은 이해로 이어졌을 것이다.
개발을 배우는 거지 얕게 훑으려는 게 아니니까, 내부 원리를 CS 지식과 연결해서 배우는 시간으로 활용했으면 어땠을까 하는 아쉬움이 있다.

3번째 팀이라 앞 팀의 구현 관련 질문이 많아서 넘어갔지만, 안 그랬으면 구현도 부족하고 깊은 이해도 없다는 평가를 받았을 수 있다.

다음에는 코드 자체에 집중하기보다 구현 원리를 이해하고, AI에게 설명하면서 검증하는 방식이 더 높은 효율을 보여주지 않을까 싶다.

이동석 코치님 반 전체 피드백 메모

  • 발표는 여러 사람이 번갈아가면서 할 것
  • 기술뿐 아니라 협업이나 회고 관련 경험도 함께 이야기하기
  • 듣는 사람을 위한 발표 연습 (폰트 크기, 배경 설명, 텍스트보다 시각적 자료 위주)
  • 12 Factor 같은 현대 서버 원칙이 반영되었는지 확인 (특히 로그, 보안)
  • 프로젝트를 하면서/끝난 후 본인의 강점과 선택의 이유를 정리하기
  • AI는 소화할 수 있는 만큼만 활용할 것. 안 그러면 남는 게 없다.
    수요코딩회는 AI를 활용한 학습과 경험을 위한 자리이지, AI에 의존하는 것이 목적이 아니다.

Jungle Bell 출시와 시간 관리

Jungle Bell이라는 서비스를 만들었는데, 반응이 좋았다.
같은 반에서 팀을 하지 않았던 분들도 설치해서 문의해주셔서 감사했다. 유지보수를 꾸준히 해야겠다는 생각이 든다.

다만 만드는 게 재밌어서 시간을 많이 쏟아버렸고, 알고리즘 목표를 달성하지 못했다.
실 사용자가 있는 서비스를 만드는 경험은 좋지만, 정글 코스에 집중하지 못하는 건 문제다.

개선 방안: 다음 주에는 태스크를 작게 쪼개서, 점심 시간이나 필수 학습 시간 외에만 개발하고, 그 외에는 알고리즘에 집중하도록 할 계획.