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

핵심 역량 목표

목표 1. 외부 자료 없이 이진 검색 트리, DFS/BFS, 위상정렬 구현하기

계획

월요일까지 중 난이도 문제까지 완료하고, 이후 제한 시간을 두고 문제 풀이 또는 핵심 기능을 재구현하기.

과정

계획했던 재구현 과정은 따로 진행하지 못했지만, 기본 문제를 풀면서 일부 문제를 AI나 힌트 없이 직접 구현하는 과정에서 자연스럽게 목표를 달성했다고 판단했다.

결과 및 피드백

계획과 과정은 달랐지만 목표 자체는 달성.

외부 자료 없이 이진 검색 트리, DFS/BFS, 위상정렬을 활용한 문제 풀이가 가능했다.

목표 2. 기본 제공 강의 외의 알고리즘 문제를 풀기

관련 역량: 문제해결, 학습 민첩성, AI 활용

Week 4 문제 풀이 외의 문제도 중(실버 상급 ~ 골드) 난이도 정도로 4문제 이상 풀이 시도하기.

계획

문제 배경: 3주차에는 시간 제한을 두고 문제를 풀며 풀이 속도는 향상되었지만, 개인 활동에 시간을 분산하면서 2주차와 풀이량이 거의 동일하게 유지되었다.

개선 계획: 정규 시간에는 커리큘럼 활동에 집중하고, 개인 활동은 정규 수업 외 시간과 식사 시간에만 진행한다. 또한, 문제별 소요 시간을 타이머로 기록하고, 템플릿을 활용해 AI 사용 방법, 풀이 전/중/후의 계획과 판단 근거를 정리한다.

과정

난이도는 실버 1~골드 5로, 목표 범위(실버 상급 ~ 골드) 내의 추가 문제 6개를 선정했고 그중 3문제를 풀었다.

3/21(금)

3/23(일) 난이도 중 문제 집중 풀이:

이진검색트리, 작업, DFS와BFS, 미로탐색, 이분그래프, 동전2

3/24(화) 추가 문제 진행:

AtoB, 쉬운최단거리, 적록색약

결과 및 피드백

난이도 중 이하 문제를 다 푼 후, 목표의 4문제 대비 3문제 완료.

목표 3. 자료 공유

계획

이번 주차의 알고리즘을 잘 설명해주는 자료를 찾으면 공유하기.

팀원들의 진행 상태를 확인하고 알고리즘의 개념에 대해서 이야기하기. (같이 배우기)

수요코딩회의 미니 React 구현에 필요한 HTML/CSS/JS, DOM 조작, 브라우저 구성 요소, 렌더링 등의 개념 관련 자료를 정리해서 제공하기.

과정

수요코딩회의에서 미니 React 구현을 위한 자료를 정리해서 공유.

기존 알고리즘 템플릿/예시 공유용 Gist가 관리하기 어려워, 새로운 학습/공유용 Gist로 새로 작성.

결과 및 피드백

팀원들과 알고리즘을 공유하는 것에 대해서는 잘 지켜지지 못한 듯함. 팀원 전체적으로 공감하는 부분이었음.

수요코딩회에서는 Codex Skill을 추가하자고 의견을 제시하거나, 이론 설명 등에서 적절하게 참여했다고 생각함.

단, 3/24의 이동석 코치님과의 커피챗에서 자료를 미리 만들어 공유하는 것에 대해서는 좋지 않다는 피드백을 받았음. 자료 공유 관련해서는 회고 파트에서 설명.

WIL (What I Learned)

03/24 이동석 코치님 커피챗

인상 깊은 질문과 답변 위주로 정리하였다.

수요코딩회의의 우선순위(이론/AI/협업/제품 이해)
- 우선순위를 나누는 접근 자체가 잘못되었다. 기술 이해, AI 활용, 협업은 분리되지 않고 동시에 작동하는 구조이며, "무엇을 구현할지 이해하면서 구현하는 과정"이 중심이다.
수요코딩회의 바이브 코딩 걱정 (코드를 봐야 하는가? 사고까지 AI에게 맡기는 문제)
- 바이브 코딩 자체는 문제가 아니다. 구현 디테일보다 명세와 방향 관리 능력이 중요.
- 다만 what까지 AI가 결정하면 문제. 사람은 명세와 방향을 정의하고, AI는 how를 담당하는 구조가 맞다.
- 수요코딩회의의 본질도 기능 구현이 아니라, AI를 활용하면서 결과를 의도한 방향으로 통제하는 능력을 기르는 것.
잘 아는 사람이 협업에서 자료 공유나 적극적으로 나서는 것이 좋을까?
- 협업에서 잘하는 사람이 먼저 나서서 리딩하는 방식은 비추천. 잘하는 사람이 말하면 모두 따라가고, 의견 다양성과 학습 기회가 사라진다.
- 과도한 자료 공유도 부담/숙제처럼 느껴질 수 있음.
- 먼저 결론을 제시하지 말고 질문을 던지고, 막힐 때만 개입하는 흐름 조정자 역할이 맞다.
개인의 실력 향상이 안 되는 것 같다는 고민 / 팀원 간 차이에 대해서
- 여러 요인이 있겠지만, 여러 학생들을 본 경험상 본인의 멘탈이나 건강에 대한 부분을 체크해 보는 것도 필요할 수 있음.
- 성장 체감이 안 되는 문제에 대해서는, 비교 기준 자체를 재점검해야 한다. 성장의 범위는 기술 능력뿐 아니라 협업 능력, 사람을 성장시키는 능력까지 포함.
  - 오히려 제일 쉬운 게 기술 공부이고 혼자서도 가능함. 반면에 함께 일하는 걸 배우는 건 쉽지 않고 기회도 적음. 오히려 협업 능력을 키울 수 있는 기회로 보아야 함.
    - 팀 내 실력 편차가 클 때, 개인 성장보다 팀을 어떻게 움직이느냐가 중요. "내가 얼마나 잘하냐"가 아니라 "팀을 어떻게 끌어올리냐"가 올바른 기준.
    - 도와주는 방식은 요청 기반, 상황 기반 개입이 원칙. "얼마나 알려주느냐"가 아니라 "언제 어떻게 개입하느냐"가 핵심.
C나 PintOS같은 어려운 커리큘럼의 선행학습이 필요한가?
- C 선행학습은 불필요. 특정 언어보다 코딩 능력이 중요하며, 빈 종이에 코드를 직접 작성할 수 있는지가 기준. Python으로 코딩 반복이 최우선.
- 선행학습은 추천하지 않음. 오히려 지금 커리큘럼에 더 집중하는 걸 추천함.
알고리즘의 경우, 하루 30분에서 1시간 정도의 시간을 투자해서 감각을 유지하는 건 도움이 될까?
- 알고리즘을 짧은 시간(30분 내외) 가볍게 반복해서 푸는 정도는 추천.
- 다만 커리큘럼 방해나 수면 감소를 초래할 정도의 과도한 투자는 피해야 한다. 오히려 이게 부채처럼 느껴져서 스트레스가 된다면 피해야 함.

03/26 김현수 코치님 점심식사

팀원이 3명이라 자리가 하나 비어서 그런지, 김현수 코치님이 합석해 주셔서 여러 이야기를 나눌 수 있었다.

수요코딩회의의 의도와 목적
- 지금 코스에서 배우는 자료구조와 연결되는 경험을 하게 하는 것이 목적.
- "자료구조 열심히 했습니다"로 끝나는 것과, "미니 React를 만들면서 DFS와 트리 기반 설계를 실제로 해봤다"라고 말할 수 있는 것은 다르다.
- 특정 기술(예: 레디스, 리액트) 자체가 중요한 게 아니라, 배우고 있는 자료구조(트리, DFS/BFS)를 실제 존재하는 문제에 적용해보는 것이 핵심.
- 이런 경험은 면접이나 대화에서 했던 일을 구체적으로, 오래 이야기할 수 있는 활동의 증명이 된다. 책이나 이론을 외운 것과 달리 자세하게 답하기 쉽고, 듣는 사람도 "열심히 했구나"라고 느끼기 쉽다.
실제로 면접관이 GitHub을 보는지 질문 / README 관리의 필요성
- 공고를 열면 아주 많은 지원서를 본다. 1차 필터링에서 이력서만으로 애매한 경우에 추가 자료(README, GitHub, 블로그, 유튜브 등)가 관리되어 있는지에 따라 탈락 여부나 추가 검토 대상이 결정될 수 있다.
- README는 모르는 사람도 보기 좋게 키워드 중심으로 정리해야 한다. 지금 당장 완성할 필요는 없지만, 나중에 다시 쓸 때 기억할 수 있도록 어필 포인트나 키워드 정도는 매 주차마다 기록해 두는 게 좋다.
- AI 활용 같은 스킬도 좋은 포인트가 될 수 있고, 추가한 기능들에 대한 정보도 레포 안에 남겨둬서 실제로 그렇게 했다는 걸 확인할 수 있게 해야 한다.

알고리즘/자료구조 정리

코딩 테스트를 위한 파이썬 문법과 알고리즘 정리

회고

수요코딩회 후기

잘 된 점 / 유지할 점:

첫 회의에서 목표를 확실하게 설정했음. 우리가 뭘 모르는지, 어떤 걸 만들어야 하는지를 먼저 정리하고 시작하니 방향이 흔들리지 않았음.
1시간 간격으로 공부/작업 현황을 공유하거나 모르는 내용을 이야기하는 등 팀원 간의 싱크를 맞추는 시간을 가졌음.
AI 활용을 적극적으로 시도했음. 이번에는 Skill.md를 만들어서 반복 작업을 개선했고, 앞으로는 에이전트나 프롬프트 규칙 등을 지속적으로 피드백하면서 개선해보는 것도 좋을 듯.

고민: 꼭 코드를 나눠서 작성해야 할까?

수요코딩회 팀 회의에서도 나온 이야기이고, 계속 고민하는 부분임. 기회가 된다면 시도해보고 싶다.
어차피 AI에 맡기고 결과를 분석할 거면, 요구사항 분석/학습/프롬프트 설계에 집중하고 하나의 에이전트로 개발하는 것도 협업이 아닌가 싶음.
역할 분배나 개발에서의 컨플릭 해결도 결국 AI를 많이 활용하게 될 텐데, 이렇다면 굳이 코드를 나눠야 하는 이유가 있을까?
이동석 코치님도 Week 5 발제 때 비슷한 이야기를 하셨음.

코어타임은 자주 하자

이번 주는 코어타임을 어쩌다 보니 월,화에 몰아서 하게 되었음.

수요코딩회에서는 1시간 간격으로 싱크를 맞추면서 자연스럽게 동료학습이 이루어졌는데, 회고하면서 생각해보니 코어타임도 비슷한 역할을 한다고 생각함.

이번에 알고리즘 시간에 동료학습이 잘 안 된 원인 중 하나가 코어타임을 몰아서 한 것이 아닐까 싶음.

팀 프로젝트에서의 참여 방식 전환

이동석 코치님 커피챗을 통해 Week 2~3처럼 자료를 정리해서 미리 제공하는 방식이 좋지 않다는 피드백을 받았고, 동의하게 되었음.

또한 이번 주차에서 대부분의 팀이 리액트를 안 써봤는데도 과제를 잘 구현한 걸 보면, 꼭 잘 아는 사람이 개입해야만 잘되는 것도 아니었다. 너무 걱정해서 자료를 미리 준비하거나 알려줄 필요는 없다고 느꼈다.

이 부분은 더 고민해 보고 다음 커피챗에서도 논의해 볼 예정.

핵심 역량 목표 회고

잘 된 점: 몇 주간의 시행착오를 거치면서 문제 푸는 방법이나 양에서 적절한 지점을 찾았다고 생각함.

고민: 목표 달성률은 높은데, 대부분 개인 학습 중심이고 팀원들과 함께 성장하는 내용이 부족함.

다음 주차에 시도할 것: 핵심 역량 목표에 팀 차원의 목표를 하나 이상 포함하되, 단순 자료 제공과 같은 방식은 지양하기.