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

핵심 역량 목표

목표 1. DP/Greedy 기본 유형을 답 없이 풀 수 있을 정도로 많이 풀기

관련 역량: 문제해결, 구현, 학습 민첩성

DP/Greedy 기본 유형을 문제 기준으로 반복해서 풀고, 해설 없이 해결 가능한 범위를 넓힌다.

계획

이번 주에는 DP/Greedy 문제를 가능한 한 많이 풀어볼 계획이다.

많은 문제를 보고 유형을 판단하고 풀 수 있도록 빠르게 반복 학습하는 게 더 효율이 좋았고, 이번에도 동일한 전략으로 가려고 한다.

문제 파일마다 추가한 템플릿에 AI 사용 횟수/방법, 목표 시간, 실제 시간, 초기 접근, 풀이 전략, 막힌 점을 기록한다.

과정

3/27에 basic과 난이도 하의 모든 문제를 풀었다. (피보나치 수 2, 01타일, 동전 0, 잃어버린 괄호)

이후 난이도 중 문제에서 난도가 높아져 거의 풀지 못했고, 추가 학습과 정답 풀이를 보면서 학습하였다.

이후 난이도 하와 중 사이의 몇 문제를 추가하여 풀어보았다.

결과 및 피드백

DP와 그리디는 다른 알고리즘에 비해 학습 경험이 적어서, 이전 주차의 알고리즘보다 훨씬 자주 막힌다고 느꼈다.

basic은 빠르게 끝냈지만, 난이도 중 DP에서는 아직 막히는 문제가 많았다. 지금 다시 풀어보라고 하면 절반 이상을 풀지 못할 것 같다.

비슷한 유형을 더 보충하고, 시간을 써서 여러 번 다시 푸는 과정이 더 필요해 보인다.

템플릿에 남긴 내용을 기반으로 AI에게 피드백을 요청했을 때, 다음과 같은 피드백을 받았다.

구현보다 문제 해석 + 상태 정의에서 병목이 있고, DP라면 "구하는 값 / 상태 / 전이 / 순회 순"과 같이 DP의 구성요소에 대한 문제 정의를 명확히 하는 게 중요하다.
그리디 문제는 왜 그리디로 풀 수 있는가를 명확하게 설명할 수 있을 때까지 분석이 필요하다.
AI를 문제의 답이나 힌트가 아니라 사고 검증용(엣지케이스나 반례 등을 요청)으로 사용하는 것도 도움이 된다.

목표 2. AI 활용 방식을 더 적극적으로 실험하고 정리하기

관련 역량: AI 활용, 협업, 학습 민첩성

계획

수요코딩회나 개인 학습 과정에서도 AI를 단순 질문용으로만 쓰지 않고, 프롬프트, 에이전트, Skill을 의식적으로 실험해 볼 계획이다.

괜찮았던 방식은 혼자만 쓰고 끝내지 않고 팀원들과도 공유해 볼 생각이다.

과정

Claude의 Agent Team을 사용해보고, Tmux 등을 사용해보았다.

Opus를 사용했는데 사용량이 너무 커서 일주일 제한에 걸렸다.

수요코딩회에서는 AI 활용 방법을 간단히 설명할 수는 있었지만, 그것이 중심이 되는 활동은 아니었다.

결과 및 피드백

결과적으로 목표를 이루지 못했다. Claude의 사용량 제한으로 여러 기능을 충분히 테스트하지 못했고, 따라서 팀원들에게 공유하는 작업도 하지 못했다.

다만 몇 가지 개선 방법을 알게 되었다.

Claude Pro 요금제에서는 Sonnet을 쓰는 편이 낫다. Opus의 사용량을 감당하기 어렵다.
Agent Team은 토큰을 많이 사용하므로 지양하고, Skill이나 SubAgent를 사용하는 편이 낫다. 모든 팀원이 Claude를 쓰는 것은 아니므로 범용성 면에서도 더 좋다.
특정 작업은 Codex에 위임하여 토큰을 아낄 수 있다. 며칠 전 OpenAI에서 공식적으로 Claude Code에서 Codex를 호출하는 플러그인을 출시했다.

WIL (What I Learned)

03/29 이동석 코치님 이야기

개발자는 가까운 불편함을 해결하는 사람
- 개발자를 거창한 무언가를 만드는 사람으로만 생각하지 말고, 지금 반복해서 겪는 불편함을 개선하려는 태도를 먼저 가져야 한다는 이야기였다.
도구를 잘 다루는 것도 개발 실력의 일부
- IDE, 에디터, 셸을 더 잘 다루는 것만으로도 생산성이 크게 달라진다. "왜 이 불편함을 계속 참고 있지?"를 자주 점검해야겠다고 느꼈다.
크래프트맨십: 내 이름을 걸 수 있는 코드를 작성하는가
- 결국 코드에 내 이름을 붙였을 때 설명하고 책임질 수 있는가의 문제라고 느꼈다. 부족하더라도 숨기지 말고 드러내고 피드백받는 태도가 중요하다.

03/31 김현수 코치님 커피챗

팀원들과의 협업 방식에 대해 방향을 더 분명하게 잡을 수 있었던 대화였다. 후기는 코어타임 / 협업 회고에서 정리하였다.

잘 아는 사람이 팀에서 설명하거나 자료를 공유해도 되는가?
- 설명 자체는 괜찮다. 오히려 설명은 내가 진짜 이해하고 있는지 검증하는 데 도움이 된다.
- 다만 잘 모르는 상태에서 아는 척 설명하면 잘못된 지식을 전달할 수 있으니, 모르면 모른다고 말하고 같이 찾는 태도가 중요하다.
링크나 자료 같은 문서를 공유하는 것도 괜찮은가?
- 공유와 강요는 다르다. 링크나 자료를 주는 것은 상대가 선택할 수 있으므로 괜찮다.
- 하지만 정리된 문서나 PRD와 같은 플랜을 줄 때는 왜 이렇게 정리했는지 설명할 수 있어야 한다.
- 단순히 GPT가 만든 결과물을 전달하는 것은 큰 의미가 없고, 내가 이해한 맥락까지 설명해야 가치가 생긴다.
- 이러한 공유가 목적이라면 공유도 괜찮고, 설명하는 것도 좋다. 단, 내가 하는 게 강요가 아닌지는 주의해야 한다.
체감하기에 성장 속도가 느린 것 같은데, 이런 고민을 다른 사람들은 어떻게 풀어내는가?
- 정글은 무언가를 완성하는 곳이라기보다, 나에게 맞는 학습 방식과 시작 전략을 찾아가는 과정에 가깝다.
- 제한된 시간 안에 모든 내용을 완벽하게 익히기는 어렵다. 학습 방식에는 정답이 없다. 넓게 훑는 사람도 있고 하나를 깊게 파는 사람도 있다.
- 개발자는 계속 학습해야 하는 사람이므로, 정글에서 본인에게 맞는 학습 방식을 찾아내었다면 그것만으로도 큰 가치가 있다.

04/04 단체 티타임

내 질문은 아니고, 다른 사람들의 질문을 정리하였다.

바이브 코딩이 너무 재미있어서 학습 코스의 내용에 집중하지 못했다. 어떻게 하는 게 좋을까?
- 기본적으로는 정글 안에서는 바깥에서 배우기 어려운 CS나 소프트 스킬을 기르는 데 더 집중하는 것이 좋다.
- 바이브 코딩은 정글 밖에서도 혼자 충분히 할 수 있으므로, 현재 코스에 지장이 갈 정도로 비중을 두는 것은 권장하지 않는다.
수요코딩회의 바이브 코딩 결과물이 내부 구현 이해 없이 불완전한 결과물처럼 느껴진다. 이력서에 쓸 만한 가치가 있는가?
- 바이브 코딩으로 만들었다는 사실 자체가 문제라기보다, 그 사실을 전제로 무엇을 의도했고 어떤 식으로 AI를 활용했는지 설명할 수 있는지가 더 중요하다.
- 회사에서도 AI를 쓰고 있는 만큼, 해당 질문은 구체적인 구현 레벨이 아닌 "개념은 이해했는가", "검증과 테스트는 어떻게 했는가", "다른 사람이나 에이전트와 어떻게 협업했는가" 같은 부분을 물어볼 것이라 예상한다.
- 따라서 수요코딩회 결과물은 포트폴리오 프로젝트가 아닌, 이력서에 경험 한 줄과 대화 포인트를 만드는 정도를 목표로 한다.

수요코딩회

미니 React 구현 저장소

이번 주 수요코딩회에서는 미니 React를 구현했다.

React가 어떤 방식으로 동작하는지, 컴포넌트와 훅이 어떤 역할을 하는지 가볍게 구조를 파악할 수 있었다.

협업 측면에서도 소통 빈도 자체는 높지 않았지만, 초반에 목표를 같이 맞춰 두니 비교적 안정적으로 구현이 진행되었다.

발표에서도 전반적으로 좋은 평가를 받았다. 다른 팀들에는 여러 지적이 있었던 것을 보면, 발표와 구현 모두 큰 문제 없이 마무리된 편이라고 생각한다.

회고

수요코딩회 후기

잘된 점 / 유지할 점

싱크 맞추기: 초반에 함께 모여 목표와 구현 방향을 충분히 맞춰둔 덕분에, 중간에 한 차례 어긋난 시점을 제외하면 작업이 비교적 원활하게 진행되었다.
나눠서 개발하지 않기: 구현을 하나의 에이전트에서 한 것도 좋았다. AI를 적극적으로 활용하는 상황에서는 작업을 나누고, 각자 팀원이 별도의 에이전트로 개발한 뒤 AI로 머지 충돌을 해소하는 방식이 오히려 시간만 더 들고 의미없는 활동이라고 생각한다.

아쉬운 점 / 개선할 점

고민: AI를 사용하는 건가? AI에 의존하는 건가?
- AI를 사용하니 다른 팀과 동일한 결과가 나온다. 이름이나 구현 디테일이 조금 달라도 전체 방향은 비슷한 경우가 대부분이다.
  - 심지어 다른 팀이었는데도, 구체적인 로직의 특정 함수를 물어보면 서로 이야기가 가능할 정도였다.
- 우리가 요구사항을 정의하고 개발하고 있다기보다 모델의 학습 내용과 성능에 기대고 있는 것 아닌가 하는 의문이 든다.
- 이 문제를 줄이려면 과제 요구사항을 그대로 넣기보다, 팀이 정리한 해석과 설계 문서를 더 구체적으로 반영하는 방식이 필요할 수도 있겠다고 생각했다.
- 이런 고민이 있고, 답을 찾은 것은 아니지만 계속 고민해 볼 지점인 듯하다. 그럼 중간 설명을 줄이고, 원문 어투 유지해서 이렇게 가면 된다.
개선: 발표를 단순 기록보다 공유 중심으로 바꾸기 & 다양한 도전을 해보기.
- (팀원인 송영진 님의 의견이었는데, 생각할 부분이 많아서 내 생각을 덧붙여 기록해 보았다.)
- 지금 발표는 "무엇을 만들었고 어떻게 구현했다"를 정리하는 데 그치고 있다. 그러다 보니 발표가 전반적으로 비슷해지고, 시행착오나 선택의 이유, 실패한 시도에서 얻은 점처럼 다른 사람에게 실제로 도움이 될 만한 내용은 잘 드러나지 않는다.
- 결국 발표가 동료학습에 도움이 되려면, 어떤 고민을 했고 무엇을 시도했으며 왜 그렇게 판단했는지를 공유해야 한다.
- 모두가 요구사항 구현에만 집중하거나, 새로운 시도가 있더라도 발표에서 잘 드러나지 않으면 결과는 쉽게 비슷해진다.
- 동료학습의 핵심은 서로 다른 시도와 그 과정에서 얻은 경험을 공유하는 데 있으므로, 다음에는 일부러 다른 방식으로 접근해 보거나 작은 실패를 감수하더라도 새로운 시도를 해 보고, 이를 발표 시간에 함께 공유해보는 게 좋을 것 같다.
개선: 데모는 요구사항과 동작 방식을 이해시키기만 하면 된다.
- 과하게 꾸미거나 실제 서비스처럼 보이게 만드는 것보다, 동작 원리가 잘 드러나는 구성이 중요하다.
- 이동석 코치님의 피드백 중에는, 이번 주차처럼 라이브러리를 만드는 과제의 경우 특정 기능만 간단히 보여주는 제한적인 데모와 해당 코드만 제시했어도 충분했을 것이라는 의견도 있었다. (리액트의 튜토리얼 문서처럼)

코어타임 / 협업 회고

이번 주 알고리즘에서는 협업이 아주 잘 이루어졌다고 보기는 어려웠다.

나 역시 문제를 충분히 이해하지 못한 상태가 많아서 설명하거나 공유할 만한 지점을 만들기 어려웠고, 팀원들도 비슷한 상황이었다.

그리고 무언가 설명하면서 학습하는 성향의 팀원이 없었고, 그래서 자연스럽게 이야기나 공유가 많이 일어나지는 않은 듯하다.

핵심 역량 목표 회고

잘 된 점

두 목표 모두 완전히 달성하지는 못했고, 아쉬운 부분이 많다. 그럼에도 활동 기록을 통해 알고리즘 풀이 방식의 단점과 해결 방향을 잡았다는 것에서 의미가 있지 않을까 싶다.

고민: 핵심 역량 목표를 어떻게 설정할까?

협업 목표나 주차 목표는 문제나 팀 상황에 따라 변수가 너무 많아서, 시작 전에 적어 둔 목표를 그대로 평가하는 방식이 항상 적절한지는 잘 모르겠다.

특히 이번 주처럼 난이도를 잘못 가늠했거나, 목표 자체의 방향이 어긋난 경우에는 달성 여부만으로 평가하기 어렵다고 느끼고 있다.

협업 관련 목표는 계속 넣고 싶지만, 팀 성향과 학습 단계에 따라 적절한 목표가 달라져서 설정이 쉽지 않다.

고민: 자료 공유와 설명, 어떤 방식이 적절할까?

이동석 코치님과의 커피챗 이후에는 자료 공유 자체를 조심해야 한다고 생각했는데, 김현수 코치님과의 커피챗을 거치면서 기준이 더 분명해졌다.

두 코치님의 공통된 의견은, 자료 공유나 설명 자체가 문제가 아니라 그것이 강요처럼 느껴지거나 팀의 사고를 대신하는 방식이 되면 안 된다는 것이었다.

다만 이동석 코치님은 잘 아는 사람이 먼저 방향을 정해 주거나 자료를 많이 제공하는 것 자체를 경계하는 편이었고, 김현수 코치님은 강요만 아니라면 자신이 이해한 맥락까지 함께 설명하는 공유는 충분히 의미 있다고 보는 편이었다.

나는 두 의견을 고려하여, 팀원이 취사선택할 수 있고 강요처럼 보이지 않으며 공유의 이유를 납득 가능하게 전달할 수 있다면 의미 있는 행동이라고 정리했다. 지금까지의 경험 상 도움이 되었다는 의견을 많이 받았기 때문이다. ~~해보고 별로면 바꾸면 된다.~~

내 경험을 예시로 들어보면, Week3 Redis 주차에서 핵심 키워드와 질문 목록을 정리해 각자 조사해오게 했는데, 이는 강제는 아니었지만 숙제처럼 느껴질 여지가 있었다.
반면 Week4에서 React 학습 자료를 공유한 방식은 각자 선택적으로 참고하거나 다른 자료를 찾아보는 흐름으로 이어져 부담이 적었다.

앞으로는 답이나 방향을 먼저 제시하기보다, 필요할 때 가볍게 참고할 수 있는 자료를 공유하거나 내가 이해한 내용을 설명하는 방식을 기본으로 하려 한다.

다음 주차에 시도할 것

다음 주부터는 C 언어와 관련된 파트에 들어가므로, 개인적으로 더 기대하던 내용을 학습하게 된다. 그만큼 이번 주보다 더 적극적으로 참여하고, 개인 학습 목표도 조금 더 구체적으로 세워 볼 생각이다.

협업 쪽에서는 자료 공유를 다시 도입하되, 회고에서 말한 것처럼 강요가 아닌 선에서 가볍게 공유하려고 한다.

AI 활용도 보조 목표로 두고, 코스의 학습과 협업을 방해하지 않는 선에서 꾸준히 할 계획이다.

이외의 구체적인 계획은 팀원들의 성향과 코스의 상황에 따라 달라질 수 있으므로, 고정된 방식보다는 상황에 맞게 조정하는 편이 더 적절할 것 같다.