크래프톤 정글 — Week 5 WIL

 

이번 주에 뭔가를 완전히 알게 됐다고 쓰기는 어렵다.
다만 얼버무리던 부분이 어디였는지는 전보다 분명해졌다.
상태 정의를 흐리게 잡던 습관, 이유 없이 그리디라고 넘기던 태도, 돌아가기만 하면 됐다고 생각하던 구현이 이번 주에는 계속 걸렸다.

이번 주를 한 줄로 정리하면

107번부터 155번까지의 글을 다시 묶어 보니, 이번 주는 크게 세 흐름으로 정리됐다. 첫째는 알고리즘에서 문제를 상태와 전이로 읽는 연습이었다. 둘째는 컴퓨터시스템 파트에서 코드가 실제로 어떤 구조 위에서 실행되는지 내려가 본 시간이었다. 셋째는 React 구현 회고를 통해 기능보다 제약과 설계 이유를 다시 확인한 흐름이었다. 각각 따로 배운 것 같았지만, 결국은 “겉으로 보이는 답”보다 “안에서 움직이는 구조”를 더 자주 보게 됐다는 점으로 연결됐다. [Source] [Source] [Source]

이번 글에서는 그 흐름이 다른 사람에게도 읽히도록, 내 머릿속에서만 통하는 표현은 최대한 줄이고 이번 주에 실제로 무엇을 공부했고 무엇이 남았는지를 중심으로 정리해보려고 한다.

문제해결

이번 주 알고리즘 파트에서 가장 크게 남은 건, 문제를 보자마자 알고리즘 이름부터 떠올리는 습관에서 조금씩 벗어나기 시작했다는 점이다. 피보나치, 계단 오르기, 01타일처럼 익숙한 DP 문제도 다시 보니 핵심은 공식을 외우는 일이 아니라 무엇을 상태로 둘지 정하는 일이었다. LCS와 배낭 문제에서는 두 축을 함께 상태로 잡아야 한다는 점이 선명했고, 점프나 동전, Word Break, 외판원 순회처럼 조건이 복잡해질수록 상태 정의가 더 중요해졌다. 풀이는 결국 코드보다 먼저 문제를 어떤 단위로 나눠 저장할 것인지에서 시작했다. [Source] [Source] [Source] [Source] [Source] [Source]

그리디 문제를 볼 때도 비슷했다. 예전에는 정답 패턴을 빨리 맞히는 쪽에 더 가까웠다면, 이번에는 왜 이 선택 기준이 유지되는지를 설명하려는 쪽으로 시선이 옮겨갔다. 거스름돈, 회의실 배정, 신입 사원, 멀티탭 스케줄링처럼 각각 문제는 달랐지만, 결국은 지금 당장의 선택이 전체 손해를 최소화하는 기준인지 확인하는 과정이었다. 이번 주에 남은 건 “이건 그리디다”라는 분류보다, “왜 이 기준이면 되는가”를 설명하는 문장 쪽이었다. [Source] [Source] [Source] [Source]

설계

이번 주에는 설계를 별도의 멋있는 단계처럼 보기보다, 문제를 풀기 전에 계산 단위와 책임을 먼저 정하는 일로 더 자주 보게 됐다. DP에서는 상태와 전이 방향을 먼저 정하지 않으면 구현이 흔들렸고, 그리디에서는 선택 기준이 분명하지 않으면 풀이 전체가 무너졌다. React 구현 회고를 다시 보면서도 비슷한 감각이 남았다. Hook 호출 순서, setState의 동작 방식, effect cleanup은 단순한 규칙이 아니라 상태를 예측 가능하게 유지하기 위한 설계 장치였다. 결국 설계는 코드에 들어가기 전의 형식적인 단계가 아니라, 구현이 성립하기 위해 먼저 세워야 하는 기준이었다. [Source] [Source] [Source] [Source]

구현

구현 쪽에서는 손으로 코드를 많이 쳤다는 사실보다, 코드를 문법이 아니라 실행 구조로 보기 시작한 변화가 더 크게 남았다. 프로그램이 실행되는 과정, C 언어의 기본 구조, 포인터와 메모리, 디버깅, 비트와 엔디안, 부동소수점 표현을 거치면서 값 하나도 그냥 숫자가 아니라 저장 규칙과 해석 규칙 안에서 봐야 한다는 걸 다시 느꼈다. 그다음에는 게이트에서 CPU로 이어지는 흐름, fetch-decode-execute, 어셈블리, 함수 호출, 스택 프레임, offset, ISA, cache까지 보면서 코드 아래에 실제로 어떤 장면이 있는지 더 자주 떠올리게 됐다. 이번 주 구현의 핵심은 “코드가 돌아간다”보다 “왜 이렇게 돌아가는가”를 조금 더 구체적으로 보게 됐다는 점이었다. [Source] [Source] [Source] [Source] [Source] [Source] [Source] [Source] [Source] [Source] [Source] [Source] [Source] [Source]

특히 디버깅 파트에서는 정답 여부만 보는 게 아니라, 어디서 상태가 어긋났는지 추적하는 습관이 중요하다는 점을 다시 느꼈다. 포인터를 따라가며 값을 확인하고, 메모리와 주소를 구분하고, 경계 조건과 비교 연산을 다시 보는 과정이 결국 품질과도 이어졌다. 구현은 빠르게 치는 일보다, 실행 흐름을 놓치지 않는 일에 더 가까웠다. [Source] [Source] [Source]

협업

이번 주 협업에서 남은 건 속도보다 기준 정리가 먼저라는 점이었다. React 구현 회고를 다시 보면 상태를 어디에 두는지, Hook 규칙을 어떤 기준으로 지키는지, effect를 어떤 생명주기로 관리하는지 같은 문제는 결국 팀 안에서 먼저 언어를 맞춰야 하는 영역이었다. AI 도구가 들어오면 구현 속도는 빨라질 수 있지만, 기준이 맞지 않으면 더 빠르게 어긋난다. 그래서 이번 주 협업에서 배운 건 역할 분담보다 먼저 구조와 표현을 맞추는 일이었다. 다른 사람이 읽는 글도 마찬가지라서, 내 머릿속에서는 통하는 표현이라도 밖으로 나왔을 때 설명이 되지 않으면 다시 고쳐야 한다는 점을 이번 정리 과정에서 다시 느꼈다. [Source] [Source]

📊 핵심 역량별 WIL

1️⃣ 문제해결 (Problem Solving)

정의: 주어진 문제를 정의하고 논리적으로 해결하는 능력

목표: 문제를 보자마자 알고리즘 이름부터 떠올리기보다, 이 문제에서 무엇을 저장해야 하는지 먼저 정리한다.

이번 주에는 피보나치, 계단 오르기, 01타일 같은 기본 DP부터 LCS, 배낭, 점프, 동전, Word Break, 외판원 순회까지 이어지면서 상태 정의의 중요성을 계속 봤다. 예전에는 "이게 DP인가?"를 먼저 물었다면, 이번 주에는 "이 문제에서 상태는 뭐지?"를 먼저 묻게 됐다. 특히 점프는 현재 돌 번호와 마지막 점프 길이가 같이 상태가 되어야 했고, 외판원 순회는 현재 도시와 방문 집합을 함께 들고 가야 했다. [Source] [Source] [Source]

이번 주 평가: 문제를 많이 풀었다는 것보다, 왜 이 문제를 이런 상태로 읽어야 하는지를 예전보다 설명할 수 있게 된 점이 더 컸다.

💡 이번 주에 가져가는 것
→ 막히면 알고리즘 이름보다 상태 정의부터 다시 적는다.
→ 상태를 정한 뒤 시간복잡도와 공간복잡도도 같이 본다.

2️⃣ 설계 (Design)

정의: 효율적이고 확장 가능한 시스템 구조를 기획

목표: 구현 전에 계산 단위와 선택 기준을 먼저 세운다.

이번 주에는 설계를 예쁘게 짜는 문제로 보기보다, 문제를 계산 가능한 단위로 나누는 일로 보기 시작했다. DP에서는 무엇을 상태로 둘지, 어떤 방향으로 전이할지, 중복 계산을 어디서 제거할지가 먼저였다. 그리디에서는 어떤 선택 기준을 세울지가 먼저였다. React 구현 과제를 다시 돌아볼 때도 같았다. Hook 호출 순서를 왜 지켜야 하는지, setState가 왜 바로 값을 바꾸는 게 아니라 렌더링을 예약하는 구조인지, effect cleanup이 왜 필요한지 생각하다 보니 설계는 편한 구조를 만드는 일이 아니라 무너지지 않는 구조를 만드는 일에 더 가까웠다. [Source] [Source] [Source]

이번 주 평가: 설계는 구현 전에 적어두는 형식적인 단계가 아니라, 사실상 문제를 푸는 핵심 자체라는 걸 더 선명하게 느꼈다.

💡 이번 주에 가져가는 것
→ 코드보다 먼저 흐름과 상태 책임을 적는다.
→ 빠르게 가고 싶으면 시작 전에 더 오래 생각한다.

3️⃣ 구현 (Implementation)

정의: 설계된 내용을 실제로 동작하는 코드로 작성

목표: 이해한 구조를 코드와 실행 흐름으로 끝까지 연결한다.

이번 주 구현 감각은 손보다 구조 쪽에 더 가까웠다. 알고리즘 구현을 계속했지만, 더 크게 남은 건 코드를 문법보다 실행 장면으로 보기 시작했다는 점이었다. 프로그램 실행, C, 포인터, 디버깅, 비트, 엔디안, 부동소수점, CPU, 어셈블리, 함수 호출, 스택 프레임, 캐시까지 내려가면서 코드 한 줄도 아래에서 어떤 흐름으로 도는지를 더 자주 떠올리게 됐다. [Source] [Source] [Source] [Source]

주제	이번 주에 남은 것
포인터와 디버깅	값이 아니라 주소를 따라가며 상태를 읽는 감각
비트 / 엔디안 / 부동소수점	컴퓨터가 숫자를 저장하고 해석하는 규칙을 의식하게 됨
CPU / 어셈블리 / 함수 호출	코드 아래에서 실제로 어떤 흐름이 벌어지는지 조금 더 상상하게 됨
캐시와 메모리 계층	연산 횟수만이 아니라 접근 패턴도 성능이라는 점

이번 주 평가: 구현은 그냥 코드를 치는 문제가 아니라, 그 코드가 어떤 층위에서 어떻게 도는지 이해하는 문제라는 쪽으로 더 가까워졌다.

💡 이번 주에 가져가는 것
→ 코드 한 줄도 아래에서 어떻게 실행되는지 떠올려본다.
→ 결과만이 아니라 실행 구조까지 납득하고 넘어간다.

4️⃣ 품질 (Quality)

정의: 버그 없는 안정적인 코드 및 테스트 작성

목표: 정답 여부보다 실패 조건을 먼저 떠올리는 습관을 만든다.

이번 주에는 품질에 대한 기준도 조금 달라졌다. 포인터, 디버깅, 부동소수점, 캐시를 보면서 겉으로는 돌아가 보이는 코드도 어디서 깨질 수 있는지를 같이 보는 쪽으로 시선이 옮겨갔다. 특히 "왜 틀렸지?"를 문법 실수 하나로 끝내는 게 아니라, 지금 메모리와 상태에서 무슨 일이 벌어지고 있는지를 같이 보게 된 점이 남았다. [Source] [Source] [Source]

이번 주 품질 체크 포인트
1) 상태 정의가 정확한가
2) 경계 조건이 빠지지 않았는가
3) 메모리 / 값 / 주소를 혼동하지 않았는가
4) 비교가 정말 안전한가
5) 통과한 뒤에도 손으로 설명 가능한가

이번 주 평가: 품질은 통과 여부가 아니라, 실패할 수 있는 조건을 미리 보는 감각에 더 가까웠다.

💡 이번 주에 가져가는 것
→ 구현 후에는 경계 조건과 실패 입력부터 다시 본다.
→ 통과했어도 손으로 설명이 안 되면 아직 끝난 게 아니다.

5️⃣ 유지보수 (Maintenance)

정의: 가독성이 좋고 수정이 용이한 코드 작성

목표: 나중에 다시 봐도 바로 복구할 수 있는 구조로 정리한다.

이번 주에는 글과 코드를 정리하는 흐름도 계속 의식했다. 정의 → 상태 → 예시 → 주의점 순서로 정리해두면 나중에 다시 볼 때 훨씬 덜 힘들었다. 시스템 파트도 프로그램 실행 → 메모리 → CPU → 어셈블리 → 함수 호출 → 캐시처럼 하나의 흐름으로 묶어두는 쪽이 훨씬 오래 남았다. 유지보수는 결국 내가 나중에 다시 봤을 때도 바로 복구할 수 있게 남기는 일이라는 생각이 강해졌다. [Source] [Source] [Source]

💡 이번 주에 가져가는 것
→ 정리 순서를 고정해두면 복습 비용이 줄어든다.
→ 코드도 글도 연결 구조가 있어야 나중에 다시 읽힌다.

6️⃣ 협업 (Collaboration)

정의: 팀원과 소통하며 시너지를 내는 과정

목표: 속도보다 먼저 구조와 기준을 맞춘다.

이번 주 협업 쪽에서 크게 남은 건 구조 합의의 중요성이었다. React 구현 과제를 다시 돌아보면서 상태를 어디에 둘지, Hook 규칙을 어디까지 지켜야 할지, effect cleanup을 어떤 생명주기로 볼지를 먼저 맞추지 않으면 구현 속도가 빨라도 오히려 더 많이 돌아간다는 걸 느꼈다. AI를 같이 쓰는 환경에서는 특히 더 그랬다. 빨리 만들 수는 있어도, 기준이 없으면 더 빨리 어긋난다. [Source]

이번 주 평가: 협업은 역할 분담보다 먼저 구조와 언어를 맞추는 일이라는 점이 다시 선명해졌다.

💡 이번 주에 가져가는 것
→ 빠르게 달리고 싶으면 시작 전에 기준을 더 많이 맞춘다.
→ 설명하지 못하면 아직 충분히 이해한 게 아니다.

7️⃣ 태도 (Attitude)

정의: 자기주도적인 학습과 과제에 대한 몰입

이번 주에는 통과했는지보다, 내가 이걸 정말 설명할 수 있는지가 더 중요했다.

알고리즘은 상태를 손으로 다시 적어봤고, 시스템은 실행 장면을 말로 다시 복원해보려고 했다. 막히는 부분이 나오면 거기가 내가 잘 모르는 부분이었다. 이번 주 태도는 빨리 넘기는 게 아니라, 설명이 될 때까지 다시 붙잡는 쪽에 가까웠다. [Source] [Source] [Source]

💡 이번 주에 가져가는 것
→ 막히는 부분을 그냥 넘기지 않는다.
→ 설명이 될 때까지 더 작게 쪼개서 다시 본다.

8️⃣ 비즈니스 이해 (Business Understanding)

정의: 서비스의 가치와 사용자 입장을 고려하는 시각

목표: 기술적으로 가능한 것과 실제로 유지 가능한 것을 구분해서 본다.

이번 주에는 React 구현 과제를 보면서 왜 이런 제약이 필요한지 계속 생각하게 됐다. Hook 규칙이나 cleanup은 귀찮은 규칙이 아니라, 결국 서비스가 커져도 상태를 예측 가능하게 유지하기 위한 장치였다. 만들 수 있는 것과 실제로 운영 가능한 것은 다르다는 점이 전보다 더 선명해졌다. [Source]

이번 주 평가: 기능이 돌아가는지보다, 이 구조가 사용자와 운영 관점에서 오래 버틸 수 있는지 같이 보게 됐다.

💡 이번 주에 가져가는 것
→ 기능을 설명할 때 왜 필요한 구조인지도 같이 설명한다.
→ 기술적 가능성과 운영 가능성을 분리해서 본다.

9️⃣ AI 활용 (AI Utilization)

정의: AI 도구를 활용하여 생산성을 극대화하는 능력

목표: 답을 대신 받는 도구보다, 구조를 정리하고 생산성을 높이는 도구로 쓴다.

이번 주에 더 분명하게 느낀 건 방향은 내가 잡아야 한다는 점이었다. 상태 정의나 설계 기준 없이 AI를 쓰면 빨리 가도 빨리 어긋난다. 반대로 내가 질문과 구조를 먼저 세우면 AI는 정리와 생산성 면에서 확실히 도움이 됐다. 결국 AI를 잘 쓰는 건 많이 쓰는 게 아니라, 내가 먼저 기준을 갖고 쓰는 거였다. [Source]

이번 주 평가: AI는 내 손발이 될 수는 있지만, 방향을 대신 정해주지는 못한다는 걸 다시 느꼈다.

💡 이번 주에 가져가는 것
→ AI를 쓰기 전에 질문과 뼈대를 내가 먼저 정한다.
→ AI가 만든 결과도 내가 납득하고 넘어간다.

🔟 학습 민첩성 (Learning Agility)

정의: 새로운 기술이나 개념을 빠르게 습득하는 능력

목표: 넓게 배우되 하나의 중심 질문으로 묶어간다.

이번 주는 알고리즘, 시스템, 프론트엔드 구현 회고까지 범위가 넓었다. 그런데 오히려 덜 흩어졌다고 느꼈다. 알고리즘은 상태 정의, 시스템은 실행 구조, 프론트엔드는 제약과 상태 책임이라는 질문으로 묶어 보니 각각이 따로 노는 느낌이 줄었다. 처음 보는 개념도 "왜 이렇게 설계됐지?"라는 질문으로 접근했을 때 훨씬 빨리 흡수됐다. [Source] [Source] [Source] [Source]

이번 주 평가: 배운 범위는 넓었는데, 중심 질문이 생기니까 오히려 더 한 줄로 묶이는 느낌이 있었다.

💡 이번 주에 가져가는 것
→ 새로운 개념을 만나면 먼저 왜 이렇게 설계됐는지 묻는다.
→ 넓게 배워도 중심 질문이 있으면 덜 흩어진다.

체크리스트

체크리스트는 10대 핵심 역량과 분리해서, 이번 주에 실제로 공부한 흐름만 더 또렷하게 보이도록 확장했다. 106번의 형식처럼 한 번에 범위를 파악할 수 있게 두되, 이번에는 “무엇을 봤는지”에서 끝나지 않고 “어떤 문장으로 이해했는지”까지 남기려 했다. 문제를 하나씩 따로 보기보다 시리즈로 묶어보면 이번 주 학습 흐름이 더 선명하게 읽힌다. [Reference]

🧭 이번 주 학습 지형도

알고리즘 문제 시리즈 기본 DP → 상태 확장 DP → 그리디 선택 기준 문제를 분류하기보다 상태와 기준을 설명하는 쪽으로 이동

시스템 이해 시리즈 프로그램 실행 → 메모리/포인터 → CPU/캐시 코드를 문법이 아니라 실행 구조로 내려가서 보기

바이코딩  Hook 순서 → setState 예약 → effect cleanup React는 기능보다 내부 제약을 이해하는 쪽이 핵심

문제 시리즈로 묶어 보면

시리즈	대표 문제	이번 주 핵심 질문	관련 글
기본 DP 시리즈	피보나치, 계단 오르기	이 문제를 한 줄 상태로 표현할 수 있는가?	107, 108
상태 확장 DP 시리즈	점프, 동전, House Robber, Word Break	현재 값만으로 부족하다면 무엇을 상태에 더 들고 가야 하는가?	117, 118, 121, 122
압축 상태 DP 시리즈	외판원 순회	방문 집합처럼 여러 정보를 하나의 상태로 압축할 수 있는가?	125
그리디 기준 시리즈	거스름돈, 회의실 배정, 신입 사원, 멀티탭 스케줄링	지금 이 선택이 왜 전체 손해를 줄이는 기준이 되는가?	109, 119, 120, 123

이번 주 상세 체크리스트

상태	분야	구체 체크포인트	관련 글
✅	DP 기초	피보나치 메모이제이션 한 번 계산한 값을 memo에 저장해 중복 계산을 줄인다. → 재귀를 쓰더라도 상태 저장이 없으면 DP가 아니라는 점을 다시 확인했다.	107
✅	DP 기초	계단 오르기 전이식 계단에 도착하는 방법은 바로 이전 두 계단의 합으로 누적된다. → 전이식이 보이면 구현은 자연스럽게 따라온다는 감각을 정리했다.	108
✅	상태 확장 DP	점프 문제 상태 정의 현재 돌 번호와 직전 점프 길이를 함께 상태로 둬야 다음 이동을 결정할 수 있다. → 상태를 하나 더 붙이는 순간 문제가 풀리기 시작하는 사례로 남았다.	117
✅	조합 DP	동전 문제 누적 방식 dp[x]를 금액 x를 만드는 방법 수로 두고, dp[money] += dp[money-coin]으로 조합 수를 쌓는다. → 최솟값 문제가 아니라 경우의 수 문제일 때 DP 해석이 달라진다는 점을 정리했다.	118
✅	선택 비교 DP	House Robber dp[i] = max(dp[i-1], dp[i-2] + nums[i])로 현재 선택과 이전 최적값을 비교한다. → DP는 누적 합만이 아니라 선택 비교 구조라는 점을 다시 봤다.	121
✅	문자열 DP	Word Break 앞부분이 만들 수 있으면 사전 단어를 이어 붙여 다음 구간으로 넘어간다. → 문자열 문제도 결국 구간 상태를 세우는 DP라는 점을 확인했다.	122
✅	비트마스크 DP	외판원 순회 현재 도시와 방문 집합을 하나의 상태로 묶어 순회를 관리한다. → 여러 조건을 방문 집합으로 압축하는 발상이 이번 주 DP 확장의 끝이었다.	125
✅	그리디	거스름돈 가장 큰 동전부터 최대한 많이 사용한다. 회의실 배정 끝나는 시간이 빠른 회의를 먼저 선택한다. → 이번 주에는 “빨리 고르는 법”보다 “왜 이 순서면 손해가 없는가”를 설명하는 쪽으로 정리했다.	109, 119
✅	그리디	신입 사원 서류 순으로 정렬한 뒤, 면접 등수가 현재 최솟값보다 좋을 때만 선발한다. 멀티탭 스케줄링 미래 사용 시점이 가장 늦거나 다시 쓰지 않을 플러그를 제거한다. → 그리디는 현재 선택이 아니라 미래 손해를 얼마나 줄이는지가 기준이라는 점을 남겼다.	120, 123
✅	시스템 기초	프로그램 실행 흐름 CPU, OS, RAM, 저장장치 등 여러 층위에서 프로그램 실행을 바라보는 관점을 세운다. → 컴포넌트 암기보다 실행 흐름을 먼저 붙잡는 쪽이 더 중요하다고 느꼈다.	126
✅	디버깅 / 메모리	포인터와 디버깅 값이 아니라 주소를 따라가며 상태를 읽고, 어디서 어긋났는지 추적한다. 비트 · 엔디안 · 부동소수점 숫자도 저장 규칙과 해석 규칙 안에서 봐야 한다는 점을 다시 확인한다.	128, 129, 132
✅	CPU / 성능	CPU · 어셈블리 · 함수 호출 코드 아래에서 fetch-decode-execute와 스택 프레임이 어떻게 이어지는지 본다. 캐시와 메모리 계층 속도는 연산량뿐 아니라 데이터 접근 패턴에도 크게 좌우된다.	133, 134, 135, 136, 137, 138, 139
✅	React 구현 회고	Hook · setState · cleanup React의 핵심은 API 표면보다 상태 소유권, 호출 순서, 렌더 예약, effect 정리 같은 내부 규칙에 있다. → 구현 회고를 통해 “왜 이런 제약이 필요한가”를 다시 설명해보는 시간을 가졌다.	155

✍️ 이번 주 체크리스트를 이렇게 확장한 이유
이번 주는 단순히 “무슨 문제를 풀었다”보다, 같은 유형 안에서 질문이 어떻게 확장되는지 보이는 주였다. 그래서 체크리스트도 단일 문제 목록보다, 기본 문제 → 상태 확장 문제 → 선택 기준 문제 → 실행 구조 문제로 이어지는 흐름이 드러나도록 다시 묶었다.

마무리

이번 주는 많이 풀었다는 감각으로 남기보다, 무엇을 기준으로 봐야 하는지가 조금 더 선명해졌다는 쪽에 가깝다. 알고리즘에서는 상태와 선택 기준, 시스템에서는 실행 구조, 구현 회고에서는 제약의 이유가 남았다. 이 세 가지는 서로 다른 주제가 아니라, 결국 보이지 않던 구조를 더 자주 보게 됐다는 하나의 변화로 이어졌다. [Source] [Source] [Source]

다음주는 드디어 C언어 주간이다... 포인터의 신이시어 자비를🌱