[네이버 부스트캠프 웹・모바일] 10기 멤버십 3주차 회고

 

 

 

멤버십에 입과한 이후로 회고를 적어보는게 처음인 것 같습니다! 

벌써 2주차가 지나고 3주차에 접어든다는 사실이 믿기지가 않네요. ㅎㅎ 

 

사실 제가 멤버십 과정을 처음 시작하기 전에는 챌린지에서 얻은 나만의 노하우를 바탕으로 

저에게 가장 잘 맞는 나만의 학습 → 설계 → 분석 → 구현 -> 피드백 루틴을 구축하고자 하는 욕심이 있었어요.

 

그래서 멤버십 시작 과정 전에 목표, 학습, 회고 등 멤버십 과정에서의 모든 것들을 기록하고

그 과정에서 여러가지 시행착오들을 바탕으로 저와 가장 잘맞는 체계적인 시스템' 을 만들고 싶어서 멤버십 노션 기록장을 만들고 

저만의 루틴을 만들어보려는 시도를 했어요.

 

 

https://ember-braid-3dd.notion.site/25a609b0808780f196aeca0536f27289?source=copy_link

 

 

저는 P 임에도 불구하고, 뭐라도 일단 일주일치 계획을 탄탄하게 세워두고 나면 예측 가능함에서 오는 안정성 같은게 느껴지더라구요.

 

회고의 필요성

그런데 2주차가 지나고 있는 지금, 정작 제가 세워놓은 목표와 계획을 제대로 지키지 못하고 있는 스스로를 발견하게 되었어요. 

 

목표를 세우는 이유는 '지키기 위해서' 인데 정작 목표만 세우고 이 목표를 이루기 위해서 필요한 Task 들을 제대로 정의하지 않으니 그냥 껍데기만 있는 목표가 되어버리는 것 같았어요. 

 

또한, 멤버십 과정에서 다른사람들을 보면서도 하루하루마다 배우는 점이 많았고 따라서 저의 부족한 점과 꼭 개선하고 싶은 점들이 너무도 눈에 많이 보였는데,

정작 바쁘게 나아가기만하고 따로 돌아보며 정리할 시간을 가지지 않으니까 머릿속이 너무 많은 생각들로만 가득차서

엄청 혼란스럽더라구요. 

 

그래서 매주 주말 저녁에 회고를 작성하는 시간을 마련해서 여태까지의 행적들을 점검해보기로 결정했어요! : ) 

 

 

좋은 회고 작성이란?

우선 회고를 작성하기에 앞서서 회고를 작성하는 목적을 분명하게 할 필요가 있겠다고 느꼈어요.

 

회고를 쓰다보면, 오늘 하루 있었던 일, 했던 일들을 나열식으로 적는게 자연스러워지는데,

그럼 그냥 일기장과 다름 없어지고 본질적으로 '내가 왜 회고를 쓰는지' 에 대해서는 깜빡 잊어버리게 되더라구요. 

 

그래서 회고의 의미, 목적, 방식, 팁 등  어떻게 작성하면 좋을지에 대해 아래의 포스트 글을 참고했어요.

 

https://zzsza.github.io/diary/2023/06/05/how-to-retrospect/#%ED%9A%8C%EA%B3%A0%EC%9D%98-%EB%AA%A9%EC%A0%81

 

 

 

위 글에서 가장 크게 느낀 점이 있다면 아래 두가지에요! 

 

• 회고는 결국 '과거를 돌아봄으로서 피드백하고 Action Item을 생각해서  점점 더 나은 방향으로 나아가는 것' 이 핵심
• 수 많은 시행착오와 피드백을 통해서 경험적으로 나와 잘 맞는 방식을 찾아 자신만의 원칙과 기준, 방식을 확립하는 것 

 

어쩌면 저는 매번 회고를 작성할 때마다 Lv2. 관찰자 단계에 머물고 있었는지 모르겠다는 생각이 들었어요.

 

따라서 제가 회고를 작성하는 시간이 헛되지 않도록 단순히 했던 일을 Fact 위주로 나열하기보다는 제가 그 상황에서 느낀 감정과 생각들을 바탕으로 문제의 원인과 맥락을 파악하고 이를 고칠 수 있는 구체적인 Action Item 으로까지 나아가는 것이 중요하다고 느꼈어요.

 

아무리 회고를 많이 한들 피드백이 제대로 되지 않는다면 그냥 같은 곳을 뱅뱅 돌고 있는 것이나 마찬가지니까요! 

 

 

그리고 회고를 어떤 템플릿 양식을 갖추어 작성해야할지 고민이 많았는데,

저는 다른 부스트캠프 동료분들이 올려주신 회고 양식을 보면서 참고하게 되었습니다.

 

특히 개인적으로 동훈님께서 문제 분석(사실을 나열하고 문제의 원인을 파악) -> 다짐(문제를 해결하기 위한 실질적인 Action Plan) 의

전개로 깔끔하게 회고를 작성하시는 모습이 인상 깊었습니다. 

 

저도 이를 참고해서 다음과 같은 저만의 회고 템플릿을 만들어보았습니다.

 

1. 지난주 목표 & Action Plan 점검 : 지난주에 세운 목표가 잘 지켜졌는지 확인

2. 문제 분석 : 지난주간 있었던 일들을 돌아보며 문제의 원인을 파악

3. 다음주 목표 & Action Plan : 더 나은 방향으로 나아가기 위한 목표와 구체적인 실천 계획 세우기 

 

---

🔍 문제 분석 

 

1. 지나친 AI 에 대한 의존도

 

지난 이슈 트래커 프로젝트를 진행하면서, 빠르게 기능 구현을 완료해야한다는 핑계로, AI 를 남용하던 스스로의 모습을 반성하게 되었습니다. 결론적으로 저는 어떤 원리로 작동하는지도 모르는 코드를 결과만 잘 작동하면 됐지 하고 생산성이라는 핑계로 냅다 가져다쓰는 큰 실수를 저질렀습니다. 정말 부끄럽지만 매 순간 프롬프트 몇번이면 동작하는 기능을 만들 수 있는데, 그 유혹을 물리치고 제가 스스로 직접 코드를 작성해보는 경험을 쌓는 것은 굉장히 어려운 일이었습니다. 😂

 

누군가는 "AI가 발전하는 시대에 AI에게 의존해서 프로그램 코드를 작성해도 큰 문제가 없다. 오히려 AI를 잘 활용하는 것이 능력이다." 라고 말할 수 있겠지만,  이에 대해서는 장점과 단점이 모두 잇따르는 것 같아요.

 

1) 장점

• 생산성 극대화 : 반복적이고 보일러플레이트 성격의 코드를 빠르게 작성할 수 있어, 개발자는 더 고차원적인 문제 해결과 설계에 집중할 수 있음.
• 학습 및 탐색 가속화 : AI의 코드 제안을 통해 다양한 접근 방식을 빠르게 접하고, 모범 사례를 학습하는 계기가 됨.
• 반복적/표준화된 작업 : CRUD API, 기본 테스트 케이스, 설정 파일 등 정형화된 작업은 AI 활용의 이점이 뚜렷

2) 단점

• 의존성 심화 : 기초적인 사고력과 구현 능력이 약해져, AI 없이는 문제를 풀기 어려운 상황에 빠질 수 있음.
• 품질 불균일 : AI가 제안한 코드는 항상 최적·안전하지 않으며, 보안 취약점이나 성능 문제가 숨어 있을 수 있습니다. “검증 없는 의존”은 치명적인 리스크
• 이해 부족 : 단순히 AI가 준 코드를 붙여넣으면, 코드의 맥락·구조·성능상의 의미를 충분히 이해하지 못할 수 있습니다. 이는 유지보수 단계에서 문제가 됨.
• 차별화 어려움 : 누구나 AI로 빠르게 비슷한 코드를 얻을 수 있다면, 진짜 경쟁력은 “AI가 못해주는 깊은 이해·설계·추상화 능력”인데 이를 놓칠 수 있음.

 

2. 학습의 함정: 소비만 하고 소화하지 못한 지식

 

Slack 채널에서 JK 마스터님께서 효과적인 학습을 위한 프레임워크를 연구한 영상을 소개해주셨습니다.

 

https://youtu.be/dBubRcgQOM8?si=Hd5FdVzcm4ox1SGe

 

 

 

본 영상에서는 읽고 배우는 과정을 소비 -> 소화 의 두단계로 나눕니다.

 

1. 소비 : 새로운 정보를 수동적으로 받아들이는 것. ex) 유튜브, 읽기 

2. 소화 : 읽고 배운 것을 내것으로 흡수하는 과정 

 

 

사람들이 학습 후에 내용을 잊어버리는 비율은 90% 가까이 된다고 합니다. 따라서 단순히 뇌에 들어오는 절대적인 정보의 양이 중요한 것이 아니고, 내가 새로 받아들인 정보를 소화하는 과정이 굉장히 중요하다고 말합니다. 

 

만약 내가 10000 시간을 학습에 할애했는데 그 중에 9000 시간 분량의 지식을 잃어버린다는 것은 굉장히 억울한 일일 거에요..

 

저는 종종 '열심히 학습했는데 정작 오랫동안 기억할 수 있도록 머릿 속에 남은 지식은 얼마 없는 느낌' 을 받곤 했습니다.

 

이 영상을 보고 나서 저는 제가 여태껏 스스로 새롭게 배운 지식을 제대로 '소화' 하려고 하기 보다 

매번 새로운 정보를 받아들이는데 급급했구나 생각하게 되었습니다. 

 

제가 새로운 정보를 '소비' 하는 것에만 집착하고 있었기 때문에 매번 같은 개념이 나오더라도 제대로 기억이 안나서

다시 검색을 해보거나 다시 학습하는 불필요한 일련의 과정들을 거쳐왔던 것 같습니다. 

 

그리고 저의 머릿속 지식들은 제대로 구조화가 되어 있지 않고 군데군데 파편화되어 있는 느낌이었습니다.

이를 유기적으로 연결시키는 과정이 필요하다고 느꼈습니다.

 

 

보여주기식 학습 정리 

 

또한 저는 종종 '보여주기식 학습정리' 를 만들어내는 것에 급급했던 것 같습니다.

 

마치 AI 가 해준 답변을 이해했다는 생각이 들면,

분명 이미 안다고 느껴지는데 한번 더 스스로 정리해보는 것은 시간 낭비라고 느껴져서 

AI 가 작성해준 답변을 복사 붙여넣기 하면서 노트를 만들기 바빴던 적도 있습니다. 

노트에 옮겨적기라도 하면 마치 지식이 내것이 된 것 처럼 느꼈던 것 같아요. 

 

다른 사람들에게 저의 문제상황을 설명 하려면 배경 지식에 관한 자료가 필요하니까,

Context 를 제공하는데 AI 가 작성해준 답변의 도움을 받곤 했습니다.

 

그러나 이것이 제 스스로의 성장에 도움이 되지 않고, 일부 정보들은 '이해한 척' 을 하고 있었다는 사실을

깨닫기까지는 얼마 걸리지 않았습니다.

 

이렇게 단발성으로 AI 를 활용해서 '그저 옮긴' 요약 정리 노트는 제가 나중에 다시 한번 거들떠 보는 일도 잘 없었고,

무엇보다 지식이 쉽게 휘발되어버리는 문제가 있었습니다.  또한 글 작성을 AI 에 의존하다보니 스스로 글을 쓰는 능력도 퇴화했습니다.

 

정보를 소비하는 과정에서는 분명 이해를 했을 수는 있겠지만,

결국 제가 스스로 충분히 소화하며 장기 기억으로 전환하는 시간을 걷어차버리는 행위인 것 같다고 느끼게 되었습니다.

 

반면, 제가 AI 보다는 필력이 조금 서툴더라도 스스로 문제 해결 과정에서 고민하면서 직접 PR에 작성했던 글들은 

다음 날 피어 피드백에서 문제 상황의 원인과 해결 과정을 자신감 있고 매끄럽게 설명할 수 있었습니다. 

 

제 스스로가 논리적으로 사고하고 내것으로 만드는 과정이 있었기 때문에 가능한 것이었다는 점을 실감했습니다. 

 

또한, 내가 확실히 아는 것이 맞는지 검증하는데에는 스스로 지식을 인출해보는 것만큼 좋은 방법이 없다고 느꼈습니다.

 

그리고 내 스스로가 알고 있는 지식이 정말 겉핥기 수준이 아니라 왜? 라는 질문을 던지면서 제대로 알고 있는지 확인해보는 과정이 중요하다고 느꼈습니다.

 

 

비슷하게 세상에 정말 좋은 책이 넘쳐나지만, 단순히 책을 읽는 것만으로는 

그 이면에 담긴 의미를 온전히 이해하기에는 한계가 있다고 생각합니다.

 

결과적으로 그 깨달음을 얻기까지 본인이 직접 삶에서 경험하고 느낀 과정들이 핵심이기 때문입니다. 

 

예를 들어 데미안에서 “새는 알을 깨고 나온다. 알은 세계다. 태어나려는 자는 하나의 세계를 파괴해야 한다.” 라는 문장이 있다고 칩시다. 

AI 혹은 다른 사람들에게 물어보면 자신이 생각한 저 문장의 의미를 해석해줄 것입니다. 그러나 이를 제대로 받아들이기 위해서는

의미를 충분히 사색하는  과정이 필요합니다.

3. 효율적이지 못한 시간 관리

특히나 마스터 클래스가 있는 날이면, 거기서 배운 내용에 대한 개념을 제대로 소화하고 저만의 언어로 정리하는데만 해도 

오랜 시간이 걸려서 학습에 시간을 쏟으면 상대적으로 구현에 많은 시간을 할애하지 못했던 기억이 있습니다. 학습 해야할 내용이 굉장히 방대한데, 차라리 마스터 클래스에서 가르쳐주시는 내용에 집중해서 이를 제대로 소화하는 시간을 가지는 편이 좋겠다고 생각했습니다.

 

=> 마스터 클래스 직후 수업에서 들은 내용을  나만의 언어로 정리하는 시간을 마련. -> 가능하면 블로그 글까지 작성 

 

4. 일관적이지 않은 PR 템플릿

 

1~2주차에 PR 템플릿을 정해두고 있지 않으니까 일관적이지 않은 내용을 작성하게 되는 것 같아

PR 양식을 정해야 겠다고 생각하게 되었습니다. 

 

 

다른 분들의 PR 템플릿을 살펴보다가

J113 영준님의 PR 템플릿이 자신만의 언어로 문제상황을 요약 정리해두셔서  깔끔하고 인상적이었습니다. 

 

https://github.com/boostcampwm2025/web-p2-issue-tracker/pull/352

 

 

저도 문제 해결 부분을 참고해서 다음과 같은 PR 템플릿을 만들어 보았습니다! 

 

• 완료 작업 목록 
  • 학습 ( 선택 ) 
  • 분석 ( 선택 ) 
  • 설계 ( 선택 ) 
  • 구현 ( 선택 ) 
  • AI 의 도움을 받은 부분
• 주요 고민과 해결 과정
  • 문제 : 맞닥뜨린 상황을 설명 
  • 사고 과정 : 문제를 해결하기까지의 과정, 혹은 여러 선택지의 장단점
  • 해결 방법 : 최종적으로 내가 선택 및 적용한  해결책 (구체적으로)
  • AI 의 답변(참고용) : 문제 상황을 해결하기 위해서 AI 와 토론한 의견 & 내용 첨부 ( 토글 형태 ) 

5. 루틴과 자유 사이에서 늘 찾아오는 불안

 

 

제가 보기에 누군가가 유익하고 좋은 시도를 하더라도, 이거를 바로 따라하는 듯이 즉각적으로 적용하는건 꽤 어려웠습니다.

 

항상 모든 것을 잘해내고 싶은 욕심이 많은 사람이라서 그런 것 같은데,

 

한가지 체계와 시스템을 그대로 유지하게 되면,

시스템 대로만 행동하고 움직이면 되서 안정감이 느껴지긴 하지만,

 

제가 그 시스템에 영입하지 않은, 선택하지 않은 것들에 대해서는 시도를 못해보게 되니까, 

항상 아쉬움과 불안감이 있었어요. 왠지 그 순간 만큼은 제가 시스템에 들이기로 한 루틴들은 더 작아보이고,

다른 사람들이 시도하고 있는 것들이 더 값지고 커보일때가 있었습니다.

 

 

예를 들어, 모두에게 주말 아침 같은 2시간이 주어진다면 어떤 사람은 이 시간을 지식을 더 축적하며 학습 정리를 쓰는데 활용할 수 있고,

어떤 사람은 내 지난날의 루틴을 돌아보며 회고하는데 사용할 수도 있을 것 같습니다.

 

같은 시간이더라도 더욱 값지고 생산적으로 보내고자하는 욕구가 있어서

'과연 이 시간을 어떻게 쓰는 것이 나의 성장에 더 도움이 되는가' 에 대해서 질문을 던지곤 했는데 항상 만족스러운 답을 내리지 못했습니다.

 

어떤 행동을 하며 보낸 시간이 나의 미래에 얼마만큼의 가치를 지닐지, 어떤 영향을 끼칠지 일일히 예측하면서 선택의 이유를 결정하는 것은 굉장히 피로한 일이었어요.  그래서 인간은 불완전한 상태에서 머무는게 필요한건가 싶기도 하구요.

 

그런데 그렇다고 체계가 없이 움직이는 건 반대로 뭔가 마음이 불안했어요.

 

뭔가 체계나 규칙, 일정에 얽매이지 않고 그 때 그 때 마다 마음에 드는 선택을 할 수 있다는 점은 좋은데, 

그 때 그 때 마다 내가 지금 무엇을 해야하는지 결정하는게 부담이고 스트레스였어요. 

 

 

그래서 오히려 '더 잘 맞는 방식을 시스템에 영입해보자' 라는 사고 보다는, '일단 시도해보고 안맞는 방식은 제끼자' 라는 마인드셋이

실질적으로 빠른 의사결정에 도움이 되겠다는 생각을 하게 되었어요.

 

 

아직은 제가 구축한 시스템과 체계가 저와 가장 잘 맞는다는 확신은 잘 들지 않지만 

앞으로 몇번의 프로젝트 사이클을 반복하면서 여러가지 방식들을 시도해보고 피드백해보면서  저만의 개발 루틴을 수립하는 것이 최종 목표에요. 

 

 

그러기 위해서는 매주 회고를 통해서 점검하고 피드백하면서 조금씩 고쳐나가는게 중요하구나 생각하게 되었어요. 

---

 

🎯 다음주 목표 & Action Plan

 

1. AI 제대로 활용하기

 

따라서 AI 시대의 개발자로서 AI 라는 도구를 효과적으로 잘 활용하기 위해서는

AI 의 양면성(장점, 단점) 을 모두 인지하고 장점은 극대화하지만 단점은 최대한 줄이는 방향으로 활용하는 것이 중요하겠다고 느꼈습니다.

 

또한, 저는 아직 주니어 개발자로서 웹 개발을 학습하고 기초 역량을 강화하는 시기인데

사고·설계 과정을 건너뛰고 결과만 얻으면, 근본적 이해 없이 껍데기만 배운 상태에 머무를 위험이 크다고 판단했습니다. 

 

그래서 장단점을 고려하여 저만의  AI 활용 관련한 수칙을 정해보았습니다.

 

1. CRUD API, 기본 테스트 케이스, API 문서 작성 등 AI 가 잘하는 반복적/표준화된 작업 AI 사용하는 것 ok

2. 특정 기능을 구현함에 있어 바로 프롬프트로 구현을 맡기는 것 금지. 적어도 내가 이 기능을 구현하기 위해서 무엇을 해야하는지 Flow 를 먼저 떠올려보고, 구현을 하는 것이 단순히 관련 문서를 찾아보면서 의도에 맞는 동작을 실행시키기만 하면 되는 반복 노동 상황일 때 시간을 효율적으로 사용하기 위해서 내가 생각한 설계(Flow)를 바탕으로 AI 에게 구현을 맡기기 

3. 배경 지식이 부족해서 무엇을 시작해야하는지 조차 감이 잡히지 않는 상황이라면, 그 때는 AI의 코드 제안을 통해 모범 사례를 학습해보기. 다만 이때, 무조건적으로 AI가 작성해준 코드를 수용하기보다 반드시 비판적으로 검토하기.

4. 단순히 AI가 작성해준 코드의 의미를 제대로 이해하지 않고 단순히 복사 붙여넣기하는 행위는 절대 금지 

5. AI가 못해주는 깊은 이해·설계·추상화 능력을 쌓기 위해 노력하기. AI는 표면적인 코드 생성을 잘할 수 있어도 성능 튜닝·복잡한 동시성 제어·아키텍처적 의사결정은 개발자의 몫이다.

 

 

 

=> 처음에는 물론 괴롭겠지만, AI 를 정보를 소비하는 도구로서는 활용하돼, 학습 정리는 반드시 스스로 글을 작성하며 '소화' 시키는 과정을 가져야겠다고 생각했습니다.

 

스스로 너무 완벽한 글을 작성해야지 하고 부담가질 필요가 없습니다. 그리고 매일 매일 정리하려는 부담도 가지지 않아도 됩니다.

그냥, 뭔가 즉흥적으로 구현하다가 꽂히고 깊게 학습하고 싶은 흥미로운 주제, 공유하고 싶은 주제가 생기면 학습 정리를 작성해볼 예정입니다.

 

2. 새로운 지식을 충분히 소화할 수 있는 시간 마련하기.

새로운 지식을 소비하는데 급급하기 보다, 기존에 알고 있던 지식을 충분히 소화할 수 있는 시간을 마련하려고 합니다. 

 

또한, 내가 확실히 아는 것이 맞는지 검증하는데에는 스스로 지식을 인출해보는 것만큼 좋은 방법이 없다고 느꼈습니다. 

그래서 적극적으로 저만의 언어를 통해 학습 정리, 글쓰기를 시도해볼 예정입니다. 

 

그 과정에서  내 스스로가 알고 있는 지식이 정말 겉핥기 수준이 아니라 아무런 자료 없이도 다른 사람에게 자신감 있게 설명할 수 있을 정도로,  왜? 라는 질문을 던지면서 제대로 알고 있는지 스스로 검토하면서 이해의 깊이를 넓히고 기억이 오래 유지되도록 하고자 합니다.

 

 

3. 우선순위 세우기 & 선택과 집중 

매 선택의 순간마다 “이게 더 나은가?” 고민하다가 피로해지는 상황을 줄이려면, 최상위 기준(나의 성장 방향) 을 먼저 잡는 것이 중요하겠구나 느꼈습니다. 그래서 이번 멤버십 과정에서 얻어가고 싶은 목표 키워드 2~3개만 정하고, 앞으로의 선택 기준은 무조건 이 2~3개의 키워드와 연결되는가? 로만 판단하기로 했습니다.

 

또한, 선택 순간마다 새로운 기준을 세우지 말고, 기준을 하나의 프레임으로 고정할 필요성을 느꼈습니다. 

 

여기에는 부스트캠프 측에서 강조하시는 커뮤니티 가이드를 적극적으로 활용하기로 결정했습니다.

 

1. GROWTH : 나를 알고 성장하기

2. INITIATIVE : 자기 주도적으로 행동하기

3. PROFESSIONAL : 기술적 전문성 기르기

4. TOGETHER : 함께 자라기

 

 

4. 기술적 전문성 기르기

 

특정 지식이나 기술에 대해서는 그 누구보다도 깊게 파고드는 딥다이브를 경험하고 싶습니다. 

 

 피어 피드백 시간에 나의 문제 해결 과정을 제대로 이해하지 못하고 두루뭉실하게 말하는 습관이 있었는데 

남들이 제대로 이해할 수 있도록 상황적 배경과 맥락, 시도 과정과 해결방안을 최대한 구체적으로 설명하고

그 과정에서 좋은 인사이트를 얻어가실 수 있도록 잘 정돈해서 말하기 위해 노력할 것입니다.

항상 근거있는 코드를 작성하고, 더 나은 해결 방법을 찾기 위한 책임감을 가지려고 합니다. 

 

 

 

이것 외에도 당장 눈에 보이는 부족한 점들이 너무 많지만, 조급해하지 않고 천천히 앞으로 움직이면서

 다음주 회고로 또 찾아오겠습니다!