부스트캠프 챌린지 2주차 회고

학습한 걸 듣는 내 디버깅 고라파덕

느낀점

지난 주 회고에서 3가지 인사이트를 얻었다고 남겼다.
1. 주기적인 메타인지의 필요성
2. 나만의 문제 해결 과정
3. 문제를 작게 나누는 것의 중요성

그리고 DAKI회고를 통해 기록, AI를 이용한 학습 효율 개선, 해결 과정 중의 메타인지를 해결 과정에 추가하고자 했다.

이를 바탕으로 2주차에서는 새로운 인사이트를 얻었다.

안다는 착각

지난 주에 미션이나 학습 과정에서 얻은 인사이트를 곧바로 실천할 수 있다는 착각을 했다.

저축으로 예를 들자면 다음 상황과 같았다.

1. 저축이 중요하다는 걸 깨달음
2. 바로 손쉽게 저축할 수 있을 것이라 생각함
3. 막상 저축을 하려니 어떻게 저축을 해야할지 모름
4. 적금·예금 중 무엇을? 부동산이나 주식같은 투자성 저축은?
5. 저축이 중요하다는 건 알지만, 어떻게 해야 할지는 전혀 모르는 상태란 걸 깨달음

여기서 중요한 점은 두 가지라고 생각한다.

1. 안다고 생각하지만 착각인 경우가 있다.
2. 착각이란 걸 깨달으려면 시도해봐야 한다.

실제로 나는 지난 주에 "문제를 작게 나누는 것이 중요하다."는 인사이트를 얻었다.
그리고 곧바로 문제를 작게 나누어 풀어나갈 수 있다는 착각을 했다.
문제를 작게 나누는 게 중요하다고 말하면서 정작 어떻게 문제를 작게 나눌지에 대해서는 전혀 고민해보지 않았다.

결국 2주차에 들어 문제를 쪼개어 하나의 스프린트에 부여하려니 어디서 어디까지를 해결할 작은 문제로 봐야할지 가늠을 못 했다.
가령 순환 참조를 발생시키는 것이 문제라고 한다면,
아무런 기준없이 "순환 참조를 만드는 객체 만들기, 순환 참조 일으키기" 정도로만 생각했다.
그리곤 순환 참조가 뭔지 알아야 한다는 생각에 구현은 미루고 학습으로 빠진다.

"30분이면 하겠지?" 라는 생각을 했는데 막상 해보니 2시간이 걸릴 때도 있었고,
"하는 김에 이것도 더 할까?" 라는 생각에 기껏 나눈 의미가 흐려지기도 했다.
이런 상황의 원인은 문제를 쪼개는 기준이 하나도 세워지지 않아서였다고 생각한다.

아마 지금이라면 설계–구현–테스트까지를 하나의 단위로 본 뒤 테스트 가능한 동작을 하나의 쪼개는 단위로 기준을 세울 것이다.

• 객체를 만들고 참조 시키기
  • 참조의 시작과 종료 지점을 알 수 있도록 구현하기
• 서로 참조하는 상황을 만들기
  • instrument나 로그 등을 이용해 검증하기
• 검증해본 상황과 다른 순환참조 찾아보기
  • 참조의 방향이나 의존성을 달리해보기
• 해결책을 시도해보고 검증하기
  • 메모리 해제가 성공적인지 확인하기

실제로 문서를 작성한다면 더 구체적이고 세세하게 쪼갤 것이고,
이런 나만의 기준이 필요하다는 생각은 문제 쪼개기를 직접 시도해본 후에야 갖게 되었다.

미션을 진행하면서 문제 쪼개기 같은 전략이든 학습한 지식이든,
"내가 이해했고 안다고 생각한 것들이 모두 착각일 수 있구나"라는 생각을 비로소 하게 됐다.
엉클 밥의 저서 클린코드 서론에 이런 말이 나온다.

"사례 연구를 건너뛴다면 여러분은 좋은 SW를 작성하는 기분 좋은 책 하나를 더 읽었을 뿐이다."

아마 네부캠의 운영진 분들도 동일한 생각을 할 것 같다.

깨달았다고 멈추지 말고 반드시 직접 실천해봐야 한다. 그렇지 않으면 ‘안다는 착각’에 빠지기 쉽다.

말랑한 사고 방식

학습보다 설계에 집중하겠다는 다짐을 지난 주에 했다.
그러나 되돌아보면 결국 미션이 나오고 12시까지 8시간 정도는 학습에 매몰되어있었다.
그리고 새벽 5시까지 3~4시간 정도만 집중하여 구현을 시도했다.

그러다 학습을 하면서 개발 패러다임이 바뀐다는 건 사고 방식 자체를 바꿔버리는 것이란 말을 보고 깨달았다.
내가 구현을 위주로 넘어간다는 게 단순히 구현 해보자는 생각만으로 되는 게 아니라는 걸 말이다.

예를 들어 레이스 컨디션을 만드는 것이 문제로 나온다면 내 생각과 행동은 다음과 같았다.

1. 레이스 컨디션이 뭔지 모르니 학습하자.
2. 레이스 컨디션 구현을 시도해보자.

지금 생각해보기엔 진짜 구현을 위주로 해보고 싶었다면 다음처럼 행동했어야 하지 않을까?

1. 레이스 컨디션 구현을 시도해보자.
2. 구현 중 모르는 점을 학습하자.

그러니까 구현을 위주로 해보겠다면서도 결국은 그 전에 학습을 끝내야 한다는 걸 놓지 못했다.
사고의 흐름 자체가 항상 학습이 우선이었으니 구현이 끼어들 틈이 없었다.

다양한 관점에서의 해결법을 보고, 다양한 시도를 해보겠다고 했지만 내 사고방식은 너무나 견고하고 단단했다.
운영진 분들이 말하신 유연하고 말랑한 사고가 어떤 건지 어렴 풋이 알게 됐다.
물론 이것도 앞서 말했듯 다음 주에 시도해보고 메타인지에 더 노력을 기울여야 착각인지 아는 게 맞는지 알 수 있을 것이다.

AI를 어떻게 쓸까

그동안 AI를 이용한다고 하면 주로 다음 중 한 가지를 위해 사용했다.

• 학습에 필요한 레퍼런스를 인터넷에서 찾아주기
• 원서 파일과 같은 큰 범위의 자료에서 필요한 부분의 위치 찾아주기
• 이해하기 힘든 문장을 문맥에 맞춰 번역 받기
• 헷갈리는 Swift 문법 알려주기

그리고 이번 챌린지 과정에서 좀 더 효율적인 학습 과정을 위해 다음과 같은 도움을 받아봤다.

• 필요한 학습 커리큘럼 설계받기
• 레퍼런스 체크 전 복잡한 이론이나 개념을 먼저 이해하기
• 내 생산물을 학습 시키고 메타인지 도움 받기

학습 위주의 미션 풀이를 해서 그런지 AI 사용도 대부분 학습에 치우쳐있었다.
근데 이번 주 과제를 진행하면서 도저히 구현을 어떻게 해야 할지 감이 안 오는 문제에 대해 구현 자체에 대한 도움을 받아봤다.
이전엔 스스로 고민해보고 구현한 것들만 의미있게 내 것이 될 수 있다고 생각했는데 이 또한 착각이었다.
막혀있던 문제에 대한 풀이 과정을 보니 내 뇌에 새로운 사고 회로가 열린 것 같았다.
한 번 힌트를 얻고 다시 시도해보니 그동안 너무 불필요하게 매달렸나? 싶은 생각이 들었다.
괜히 바퀴를 발명하지 말라는 말이 있는 걸까 싶기도 하고.

그래도 여전히 내 생각을 대신하게 할까 조심스럽지만 그렇다고 또 너무 안 쓰기엔 확실히 아쉬운 코드 결과였다.
아마 다음 주엔 먼저 시도해보고 다른 방향의 접근은 어떤 게 있는지, 개선할 포인트나 코드의 잠재적인 문제는 뭐가 있을지같은 분석 요청을 많이 시도해볼 거 같다.

TimeLine

월요일

목요일까지만 달리면 된다는 생각에 처음부터 매일 5시에 잘 생각을 했다.
몸에는 나쁘겠지만 그래도 겨우 4주 집중하고 주말에 잘 수 있는데 미션에 좀 더 투자하고 싶었다.
미션 해결에 필요할 것이라고 알려준 지식을 공부하는데 12~1시까지 투자했다.
미션에서 제공하는 목표 외에도 내가 미션 해결을 위해 얻고자 하는 목표를 별도로 작성하기 시작했다.
또, 지난 주의 회고를 통해 문제를 작게 쪼개기(제대로 못했지만), 30분 단위의 행동 점검 등을 시도했다.

화요일

학습 과정에서 애자일 방법론이라는 걸 보고 하루 동안의 미션 해결에도 적용해보면 어떨까 싶어서 시도해보기 시작했다.
처음엔 그냥 해결하는 문제를 스프린트라는 이름으로 기록해두기만 할뿐,
풀어낼 목표를 구체적으로 적거나 매 스프린트마다 점검과 회고를 가지지 않았다.

수요일

필요한 지식으로 베이직 때 학습한 내용이 나왔다.
이때 처음으로 "아, 이 지식은 이 정도로만 공부하고 구현을 시작하면 되겠구나."라는 생각이 들었다.
이전에는 학습할 때 어느 선까지 파고 들어야 하는 건지 정하질 못했다.
그저 필요할 거 같으면 더 공부하고, 시간을 썼다.
그러니 매일 12–2시까지 학습만 했다.

아는 지식이 나오니 그제서야 풀이에 필수적인 개념이 뭔지 알 것 같았다.
문제는 이렇게 아는 지식이 나오는 경우가 잘 없다는 것.

어떻게 해야 필수적인 부분을 구별해낼 수 있을지는 좀 더 고민해봐야 할 거 같다.

목요일

스프린트에 처음으로 구체적인 목표-기간-계힉-설계-수행-점검의 단계를 세우고 진행해보기 시작했다.
이때, 문제를 어떻게 쪼개야 하는가에 대한 고민을 가장 많이 한 듯.
그리고 수행 외에 설계나 점검 단계에서 소비되는 시간도 커서 이게 과연 하루라는 기간에 적용하기에 적합한가도 고민되었다.
그래도 다음주에도 쭉 개선해서 적용해볼 생각이다.

금요일

평일은 5일이지만 마치 주4일제처럼 마지막 날은 비교적 미션에 대한 압박이 심하지 않아서 참 다행이다.
새롭게 만난 분들과 한 3시간 정도 얘기를 나누고 다음주에 진행할 릴레이 프로젝트를 설계하고 받았다.

DAKI

Drop

• 이해했다고 착각하고 그냥 넘어가는 것
  • 특히 지식을 자기화 하는 게 아니라 소비하고 넘어가는 행동 버리기
  • ex) FP는 재귀적으로 문제를 푸는 구나 → 시도해보지 않고 넘기는 행동
• 문제 분석을 위해 1시간씩 다시 쓰고는 막상 해결 과정에선 인터넷의 본문 보기
• 피곤하다고 너무 힘없이 있지 말기

Add

• 문제 분석 단계와 설계를 통합하기
  • 문제를 분석하면서 바로 설계하고 이를 체크포인트에 세세하게 기록하기
• 내가 해야 할 Task를 자세히 풀어낸 뒤 각 Task마다 필요한 예상 시간, 실제 소요 시간을 기록해보기
• 2시간마다 반드시 스트레칭 하기

Keep

• 학습을 위한 AI 활용
• 피어 피드백 시간에 공유할 사항 미리 추가하기
• 피드백 시간을 위해 미리 질문 작성해두기
• 개인 목표 세우기

Improve

• 설계 단계에서 결정에 대한 이유 등을 기록했지만 남들이 알아보기 힘든 듯
  • 스프린트 과정과 거기서 도출된 결론과 실제 구현 정보를 따로 분리해서 작성해보기
    • AI의 도움을 받아볼지 고민 됨
• 다양하게 문제 쪼개기 시도해보기
  • 테스트 가능한 하나의 기능 단위
  • 학습이 필요한 부분과 아닌 부분으로 나누고 먼저 풀이해보기
  • 실행 플로우를 짜고 하나의 동작 단위로 쪼개보기
• 스프린트 단위의 문제 해결 과정 개선하기
  • 스프린트를 진행하면서 스프린트 자체에 대한 피드백 남겨서 개선
  • 저번 주엔 점검시간에 시간을 너무 썼다는 생각이 듬
    • 설계와 계획을 나눴는데 합치는 게 좋은 듯
    • 구현 부분과 설계 부분의 분리가 잘 안 됐음

Thanks to

이제는 당연하게 내 침대에서 자고 있는 봄이

이번 주도 나를 잘 돌봐준 여자친구와 귀여운 걸로 제 역할을 다하고 있는 봄이에게 감사하다.
제대로 참여 못하고 있는데도 이해해주는 프로젝트 팀원에게도 미안하고 감사하다.

지난 주에 만난 동료들과 새벽에 얘기를 나누며 잠시 쉬어가던 시간들도 모두 소중하고 감사했다.
새롭게 이번 주를 보냈던 동료들도 지난 주 동료와는 또 다른 관점에서 각자 열심히 미션을 수행해서 많이 배웠다.
동료들은 다들 어떻게 그렇게 다 구현을 해내고 오는지 참 대단하다고 느낀다.

매 미션마다 재미있고 동료들도 다들 신나서 몰두하는 게 보이는데,
미션을 잘 설계해주신 JK님과 운영진 분들에게도 감사하다.