🌿크래프톤 정글 2주차 WIL — 배운 것들의 기록

 

첫 번째 WIL을 쓴다. 2주가 지났고, 블로그엔 28개의 글이 쌓였다.
숫자보다 중요한 건 그 안에서 내가 무엇을 배웠는가이다.

📌 이번 주 목표 3가지

✅ 목표 1. 주어진 알고리즘 문제를 모두 풀고, 블로그에 게시한다.

✅ 목표 2. 파이썬 문법을 의미 있는 코드를 작성할 수 있는 수준까지 익힌다.

✅ 목표 3. 내 코드와 풀이 방식을 팀원에게 설명할 수 있는 능력을 기른다.

세 가지 모두 달성했다. 다만 "달성"의 의미가 각기 달랐다. 목표 1은 양적 완료였고, 목표 2는 언어 전환의 고통이었으며, 목표 3은 설명하려다 내 이해 부족이 드러나는 경험이었다.

📊 핵심 역량별 WIL

1️⃣ 문제해결 (Problem Solving)

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

이번 주 제공된 알고리즘 22문제를 전부 풀었다. 베이직 10개 + 백준 12개.

단순히 통과시키는 것에서 멈추지 않으려고 했다. 틀리면 "왜 틀렸지?" 부터 물었다.

회문 판별 문제에서 s.isalnum() 한 글자 차이로 모든 입력에 True가 나왔다. for c in s라고 쓴 순간 다루는 건 c인데, 조건에서 s 전체를 검사하고 있었던 것. 원인을 찾는 데 시간이 걸렸지만, 그 시간이 루프 변수를 항상 의식하는 습관을 만들어줬다.

💡 이번 주에 가져가는 것
→ 문제가 막히면 더 작은 케이스부터 손으로 따라간다.
→ 루프 변수가 무엇인지 항상 의식한다.

2️⃣ 설계 (Design)

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

백트래킹 문제들(조합, 차이를 최대로, N-Queen, 외판원 순회)에서 코드보다 흐름을 먼저 그리는 것이 훨씬 효과적이었다.

Choose → Explore → Unchoose 이 세 단계가 머릿속에 안 그려지면 코드를 쳐봤자 방향이 없었다.

재귀도 마찬가지였다. base case가 뭔지, recursive case에서 n이 반드시 작아지는지. 이 두 가지가 설계의 전부였다.

팀 프로젝트에서도 같은 교훈을 얻었다. 뼈대 — 모듈 구조와 인터페이스 — 를 먼저 합의하지 않고 달렸더니 각자 같은 모듈을 다르게 설계하고 있었다. 합치는 데 시간이 더 걸렸다.

💡 이번 주에 가져가는 것
→ 코드보다 흐름을 먼저 그린다.
→ 빠르게 달리고 싶으면 시작 전에 더 많은 시간을 써야 한다.

3️⃣ 구현 (Implementation)

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

W3Schools로 파이썬 문법을 Ch.01~25까지 전부 정리했다. C만 써오다 처음 파이썬을 봤을 때는 낯선 것들이 많았다.

문법	배운 것
리스트 컴프리헨션	줄이기가 아니라 의도를 드러내는 문법이다
[::-1]	뒤집기를 한 줄로. C에서는 상상도 못 했다
for-else	flag 변수 없이 탐색 결과를 처리한다
이터레이터 프로토콜	for문이 내부에서 어떻게 돌아가는지 처음 납득했다
*args / **kwargs	가변 인자를 이렇게 우아하게 처리한다

Ch.25까지 마치고 나니 슬라이싱이랑 f-string은 C로 돌아가기 싫게 만든다.

💡 이번 주에 가져가는 것
→ 동작하는 코드와 잘 쓴 코드는 다르다.
→ 파이썬에는 파이썬다운 방식이 있다.

4️⃣ 품질 (Quality)

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

버그를 만날 때마다 "왜 이게 틀렸지?"를 먼저 물었다.

가장 기억에 남는 건 재귀였다. 코드는 바로 맞았다. 테스트도 통과됐다. 근데 뭔가 찜찜했다. 내가 이해하고 쓴 건지, 그냥 베껴 쓴 건지.

코드를 닫고 factorial(5)를 손으로 직접 따라갔다.

factorial(5) → 5 × factorial(4)
factorial(4) → 4 × factorial(3)
factorial(3) → 3 × factorial(2)
factorial(2) → 2 × factorial(1)
factorial(1) → 1  # ← base case, 여기서 멈춤

그때서야 재귀가 납득됐다. 테스트를 통과하는 것과 이해하는 것은 다르다.

백트래킹은 짤 때마다 체크리스트를 쓰게 됐다.

✅ base case가 있는가
✅ recursive case에서 depth가 깊어지는가
✅ Choose 했으면 Unchoose가 반드시 있는가
✅ 스냅샷이 필요하면 current[:]로 복사했는가

💡 이번 주에 가져가는 것
→ 통과했어도 손으로 추적해서 납득이 되면 다음으로 넘어간다.
→ 백트래킹 4-step 체크리스트를 습관화한다.

5️⃣ 유지보수 (Maintenance)

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

블로그에 올린 모든 풀이에서 BEFORE / AFTER 코드를 나란히 놓았다.

❌ BEFORE

"".join([c.lower()
  for c in s
  if s.isalnum()])

✅ AFTER

"".join([c.lower()
  for c in s
  if c.isalnum()])

바뀐 건 딱 한 글자인데, 왜 바뀌었는지를 설명해야 나중에 내가 봐도, 읽는 사람이 봐도 의미가 있다.

이번 주에 체감한 것 하나. 파이썬다운 코드가 단순히 짧은 코드가 아니라는 것. 의도가 잘 보이는 코드 = 나중에 고치기 쉬운 코드였다.

💡 이번 주에 가져가는 것
→ 코드보다 설명이 더 중요할 때가 있다.
→ 의도가 보이는 코드가 유지보수하기 쉬운 코드다.

6️⃣ 협업 (Collaboration)

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

이번 주 크래프톤 정글 × 오픈AI 워크숍이 있었다. 3인 팀으로 하루 만에 Clean Email (Gmail 위험 메일 필터링 서비스)을 만들었다.

바이브코딩 환경에서 각자 AI로 빠르게 달렸는데, 중간에 충돌이 생겼다. 서로 같은 모듈을 다르게 설계하고 있었다. 뼈대 합의 없이 시작했던 탓이었다.

거기서 배운 팀 협업 원칙 세 가지

①
뼈대부터 잡는다 — 인터페이스를 먼저 합의해야 충돌이 안 난다

②
기능을 잘게 쪼갠다 — 누군가 대기하는 순간이 생기면 기획이 덜 된 것이다

③
PR 리뷰의 의미가 바뀐다 — 코딩 방식뿐 아니라 도메인 맥락까지 리뷰한다

팀원에게 코드를 설명하다가 말이 막혔다. 말이 막히는 곳이 내가 모르는 곳이었다.

💡 이번 주에 가져가는 것
→ 빠르게 달리고 싶으면 시작 전 뼈대 합의에 더 시간을 쓴다.
→ 설명하지 못하면 이해한 게 아니다.

7️⃣ 태도 (Attitude)

정의: 자기주도적인 학습과 과제에 대한 몰입 (집요함)

"강의 코드는 따라 치는데, 빈 화면 앞에 혼자 앉으면 손이 안 움직인다."
— 입소 에세이에서

이번 주는 그 화면 앞에서 손이 움직였다. 천천히, 틀려가면서.

코드가 통과했는데도 찜찜하면 코드를 닫고 손으로 추적했다. 공식이 납득이 안 되면 숫자를 직접 넣어봤다. 막히면 더 작은 케이스부터 다시 시작했다.

22문제를 풀면서 이 루틴이 몸에 익었다. 완벽하게 푸는 것보다 막히는 지점을 찾아서 거기서 다시 시작하는 것 — 그게 이번 주 태도였다.

💡 이번 주에 가져가는 것
→ 통과에 만족하지 않는다. 납득이 될 때까지 파고든다.

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

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

1주차 미니 프로젝트에서 들었던 피드백이 이번 주도 머릿속에 남아있었다.

"유저가 굳이 그렇게까지 해가며 써야 할 이유가 있나요?"

Clean Email을 만들면서 다시 그 말이 떠올랐다. 기능을 구현하기 전에 왜 이 기능이 필요한지를 팀 안에서 먼저 정의했다.

기술보다 방향이 먼저다. 기능이 아무리 잘 돌아가도, 쓸 이유가 없으면 의미가 없다.

💡 이번 주에 가져가는 것
→ 기능을 만들기 전에 "왜 이게 필요한가"를 먼저 묻는다.

9️⃣ AI 활용 (AI Utilization)

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

오픈AI 워크숍에서 바이브코딩을 처음 제대로 써봤다. AI가 코드를 빠르게 만들어주는 건 맞다.

근데 한 가지를 확실히 알았다.

방향을 잘못 잡으면, 빠르게 엉뚱한 곳에 도착한다.

AI를 잘 쓰는 건 AI를 많이 쓰는 게 아니었다. 내가 원하는 게 뭔지, 구조가 어떠해야 하는지를 먼저 명확히 하는 것. 그다음에 AI가 손발이 되는 것.

AI는 내 손발이지, 내 머리가 아니다.

💡 이번 주에 가져가는 것
→ AI를 쓰기 전에 방향과 뼈대를 내가 먼저 정한다.
→ AI가 생성한 코드도 내가 납득하고 넘어간다.

🔟 학습 민첩성 (Learning Agility)

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

C 개발자로서 파이썬을 처음 공부하면서, 처음엔 중괄호 없는 것도 타입 선언 없는 것도 어색했다.

Ch.25를 마치고 나니 파이썬의 리듬이 익숙해졌다. 빠르게 흡수할 수 있었던 이유를 돌아보면 한 가지였다. "왜 파이썬은 이렇게 설계됐지?"를 계속 물었던 것.

새로운 개념을 만났을 때도 같은 방식으로 접근했다. 에라토스테네스의 체 — "왜 매번 판별하면 안 되는가"부터. 유클리드 호제법 — "왜 나머지로 줄여가면 되는가"부터. 이유를 이해하면 외울 필요가 없었다.

💡 이번 주에 가져가는 것
→ 외우지 말고 "왜 이렇게 설계됐지?"를 먼저 묻는다.
→ 이유가 납득되면 흡수가 빠르다.

📚 이번 주 학습 정리

🐍 파이썬 문법 — W3Schools Ch.01~25

챕터	핵심 개념	인상 깊었던 점
01~11	들여쓰기, 동적 타이핑, 슬라이싱, f-string, Boolean falsy	C와 달리 오버플로우 걱정 없는 int
12~15	List, Tuple, Set, Dictionary — 시간복잡도와 사용 맥락	자료구조 선택이 곧 성능 설계
16~20	for-else, while-else, 람다, 재귀, 메모이제이션	for-else로 플래그 변수 제거 가능
21~25	이터레이터 프로토콜, import, datetime, math 모듈	배터리 포함(batteries-included) 철학

🧩 이번 주 풀이 목록 — 총 22문제

베이직 10문제  백준 12문제

#	분류	문제 / 주제	핵심 개념
1	베이직	N×N 배열 90도 회전	인덱스 변환 공식 (i,j)→(j,n-1-i)
2	베이직	리스트 컴프리헨션으로 평균 이상 학생 필터	Pythonic 코드, 제너레이터 표현식
3	베이직	팰린드롬 검사 버그 수정	루프 변수 vs. 컨테이너 혼동, [::-1]
4	베이직	Two-Sum 이중 루프 버그 수정	range 경계 조건 range(i+1, n)
5	베이직	팩토리얼 & 피보나치 재귀	기저 조건, 호출 스택, O(2ⁿ) 비효율
6	베이직	조합 생성 백트래킹	선택→재귀→복원, 스냅샷 current[:]
7	베이직	버블 정렬 (최적화 포함)	swap 문법, swapped 플래그, O(n²)/O(n)
8	베이직	Big-O 중복 탐색 비교	브루트포스 O(n²) vs 해시셋 O(n)
9	베이직	삽입 정렬	O(n²) 최악, O(n) 최선, Timsort와의 관계
10	베이직	GCD & LCM — 정수론	유클리드 호제법, 소수 판별 O(√n)
11	백준	2562 — 최댓값	선형 탐색, 1-index 주의
12	백준	1978 — 소수 찾기	소수 판별, 1 처리 예외
13	백준	17478 — 재귀함수가 뭔가요	재귀 깊이, 기저 조건, 들여쓰기 출력
14	백준	4344 — 평균은 넘겠지	평균 계산, 조건부 카운트, 포맷
15	백준	2675 — 문자열 반복	문자 단위 반복, int 변환
16	백준	1157 — 단어 공부	빈도 딕셔너리, 대문자 통일, 동률 처리
17	백준	3107 — IPv6	문자열 split 엣지케이스, zfill(4)
18	백준	9020 — 골드바흐의 추측	에라토스테네스의 체, n//2 대칭 탐색
19	백준	10819 — 차이를 최대로	DFS 백트래킹, 복원 단계 필수
20	백준	9663 — N-Queen	DFS, 대각선 배열 O(1) 체크
21	백준	1914 — 하노이 탑	재귀 분해, T(N)=2ⁿ-1
22	백준	10971 — 외판원 순회 2	DFS + 가지치기, 시작점 고정
✅ 총 22문제 완료 (베이직 10 + 백준 12)

🤝 팀 프로젝트 — Clean Email (바이브코딩)

 

2주차 팀(총 3명, 주차마다 랜덤 매칭)과 함께 하루 만에 이메일 정리 서비스 Clean Email을 구현했다. Flask, Gmail API, MongoDB를 사용했고, AI 코드 생성(바이브코딩)을 팀 전략으로 활용했다.

AI가 빠르게 달려도, 핸들은 사람이 쥐어야 한다.

초반에 각자 AI를 돌리다 충돌이 생겼다. 이후 ① 프레임워크 합의 → ② 역할 분담 → ③ PR 리뷰 순서를 정하니 충돌이 줄었다. PR을 올리고 받는 경험이 단순 코드 공유가 아닌 팀 소통의 단위라는 걸 처음으로 느꼈다.

📊 핵심역량 성장 요약

핵심역량	이번 주 성장 포인트
🔍 문제해결	막히면 더 작은 케이스부터 / 루프 변수 의식하는 습관
🏗️ 설계	코드 전에 흐름 먼저 / 뼈대 합의의 중요성 체험
💻 구현	Python Ch.01~25 완주 / Pythonic 코드 감 잡힘
🧪 품질	손으로 추적하는 습관 / 백트래킹 4-step 체크리스트
🔧 유지보수	BEFORE/AFTER 기록 / 의도를 드러내는 코드 = 유지보수하기 쉬운 코드
🤝 협업	바이브코딩 팀 전략 정립 / 설명 못 하면 이해 못 한 것
💪 태도	통과에 만족하지 않음 / 납득될 때까지 파고드는 루틴
💡 비즈니스 이해	기능 전에 "왜 필요한가" 먼저 묻기
🤖 AI 활용	AI = 방향은 내가, 실행은 AI가 / AI 코드도 납득하고 넘어가기
⚡ 학습 민첩성	외우지 않고 "왜?"로 이해 / C → Python 한 주 만에 전환

🚀 다음 주 목표 & 학습 키워드

🎯 다음 주 목표

• 알고리즘 문제 풀이가 궤도에 올랐으니, 이제 속도와 깊이를 함께 높인다.
• 새로운 자료구조와 탐색 알고리즘을 익혀 더 복잡한 문제를 설계할 수 있는 수준으로 끌어올린다.
• (내부 계획) 아래 키워드만 제대로 다뤄도 한 주가 빽빽하게 찰 것 같다.

🔑 학습 키워드

이분 탐색 분할 정복 퀵정렬 머지정렬 스택 큐 우선순위 큐 연결 리스트 해시 테이블

---

 

 

22문제를 풀었고, 28개의 글을 썼다.
숫자보다 더 기억에 남는 건, 틀렸던 순간들이다.
다음 주도 잘 틀리겠습니다. 🌱