- 어떻게 문제를 해결했나요?
- 어떻게 문제를 접근했나요?
- 어떤 생각과 고민이 있었나요?
- 코드를 만들어가는 과정에서 어떤 경험을 했나요?
- 어떤 생각의 사고 흐름이 있었나요?
- 어떤 시행착오와 고민이 있었나요?
- 지원서에 적은 목표에 가까워지고 있는 것 같나요?
- 나에게 의미있는 회고를 써야한다.
🚀 지원서나 중간 회고에서 현실적인 목표를 설정하고 이를 달성했다고 생각하나요? 그 이유는 무엇인가요?
👽 현실적인 목표를 작성했나요?
저는 "한 미션 안에서 최소 3개 이상의 오류를 마인드셋 과정을 통해 해결하는 것"을 목표로 설정했습니다. 이 목표를 통해 두 가지 목적을 달성하고자 했습니다.
- 발생한 문제에 대한 이해도를 높인다.
- 다음에 같은 문제가 발생하더라도 기록을 통해 해결할 수 있다.
시간 부족 상황을 고려하여 최소 3개의 오류 해결을 목표로 설정했으며, 실제로도 3~4개의 오류가 발생해 이 목표가 적절했다고 생각합니다.
👽 이를 달성했나요? 그 이유는 무엇인가요?
목표는 75% 달성했습니다.
1주차: 3개 해결
2주차: 2개 해결
3주차: 3개 해결
4주차: 4개 해결
그리고 이 과정을 통해 얻고자 했던 목적은 모두 경험할 수 있었습니다. 예를 들어, 1주차에는 ESLint 설치 후 Airbnb 포맷이 적용되지 않는 문제를 겪었고, 이는 마인드셋 과정을 통해 설정이 아닌 버전 문제임을 파악해 해결할 수 있었습니다. 3주차에는 비동기 함수 관련 오류가 발생했는데, 2주차에 유사한 문제를 다뤘던 덕분에 빠르게 원인을 파악하고 해결했습니다.
🚀 중간 회고에서 조정한 목표가 실제 목표 달성에 도움이 되었나요? 목표를 달성하는 데 어떤 점이 효과적이었다고 생각하나요?
목표를 달성하는 과정에서 다양한 문제에 직면하게 되었고, 특히 처음 보는 문제를 만났을 때 목표가 큰 도움이 되었습니다.
저는 문제 해결 과정에서 아래 4가지 질문에 답하며 접근했으며, 이 질문들은 마치 TDD처럼 문제 해결을 위한 명확한 단계를 제공해 주었습니다.
제가 얻은 효과는 다음과 같습니다.
- 질문에 답하면서 문제에 몰입할 수 있었습니다. 문제를 깊이 이해하며 해결하는 데 중요한 동기부여가 되었습니다.
- 처음 접하는 문제라도 단계적으로 접근하면서 해결 방안에 한 걸음씩 다가갈 수 있었습니다. 막연한 불확실성을 줄이고, 문제를 해결할 실마리를 얻는 경험이었습니다.
- 답변 기록을 남겨두어 비슷한 문제가 다시 발생했을 때 이를 참고해 빠르게 해결할 수 있었습니다. 문제 해결 과정이 기록되므로, 반복되는 오류는 효율적으로 대응할 수 있었습니다.
- 간단한 문제에서는 답변을 작성하지 않아도 자연스럽게 사고 과정이 진행되었습니다.
문제를 해결하며 답변했던 4가지 질문은 다음과 같습니다. ⬇️
- 내가 어떤 문제를 풀려고 하는지 한 문장으로 적는다.
- 올바르게 동작한다면 어떤 일이, 어떤 순서로 벌어져야 하는지 적는다.
- 원인이 될 만한 옵션들을 적어본다.
- 옵션 중 하나를 골라서 가설을 세우고 검증한다.
🚀 각 미션의 목표를 달성하기 위해 세운 계획을 잘 이행했나요? 그 과정에서 어떤 전략이 효과가 있었나요?
매주 학습 목표를 달성하기 위해 "80% 이상 달성 가능할 것 같은 계획"을 두 가지씩 세우고 이를 이행했습니다.
- 1주차
- 구현에 앞서 핵심 기능을 도출하고 이를 목록으로 정리한다.
- 기능 단위로 커밋을 진행한다.
- 2주차
- 기능 목록에 작성된 항목들이 하나의 역할을 수행하도록 설계하고, 각 함수도 단일 책임을 갖도록 작성한다.
- 최소 3개의 함수는 TDD 방식으로 작성하고, 피드백을 통해 개선한다.
- 3주차
- 클래스를 설계하고, 역할이 관련된 함수들을 해당 클래스에 배치한다.
- 각 클래스에 대해 테스트 코드를 작성하여 정상 동작을 확인하고, 피드백을 받는다.
- 4주차
- MVC 패턴을 적용하여 파일 구조를 분리한다.
- 각 클래스가 명확한 역할을 갖도록 설계한다.
이 전략을 통해 완벽하게 해야 한다는 조급함보다는 제 속도에 맞춰 매주 목표를 실행할 수 있었습니다. 또한 제게 필요한 부분을 단계적으로 보완해 나가는 방식으로 부담을 줄이며 설계와 구현에 집중할 수 있었습니다.
👽 어떤 전략이 효과가 있었나요?
'각 미션마다 낯선 것은 최대 2개만 가져간다'는 전략이 매우 효과적이었습니다.
매주 일요일에 회고를 통해 부족한 부분을 점검하고, 그중에서 가장 보완이 필요한 한두 가지를 선정했습니다. 그리고 이 부족함을 해결하기 위해 적당히 도전적인 목표를 다음 주 과제로 삼았습니다.
이 전략이 효과적이었던 이유는, 한 번에 너무 많은 새로운 것을 시도하지 않아서 인지 부하를 피할 수 있었기 때문입니다. 부족한 점을 모두 개선하고 싶은 마음은 있었지만, 이를 한꺼번에 시도했다면 오히려 설계 단계에서 지쳐버리고, 코드 작성이 지연되면서 기본 목표인 구현 자체가 어려워졌을 것입니다.
프리코스 디스코드에서는 많은 분들이 목표를 향해 다양한 도전을 시도합니다. TDD, DDD, OOP, MVC 같은 개념들이 활발히 논의되고 있지만, 일부 분들의 회고를 보면 다른 사람들이 시도하는 방식을 무리하게 따라하려다 실패한 경험도 읽을 수 있었습니다. 도입의 이유가 분명하지 않았거나, 학습량에 비해 부담이 컸기 때문이라고 생각합니다.
저는 이 전략 덕분에 조급함을 느끼지 않고, 제 속도에 맞춰 계획을 실행하면서 점진적으로 발전할 수 있었습니다.
🚀 몰입하고 함께 성장하는 과정을 통해 인상 깊었던 경험이나 변화가 있었나요?
👽 테스크를 관리하며 작업하는 습관
가장 인상 깊었던 경험은 기능 목록을 작성하고, 우선순위를 정해가며 차근차근 작업을 진행했던 순간이었습니다. 이 과정을 통해 테스크 관리의 중요성을 확실히 깨달을 수 있었습니다.
특히 재미있었던 순간은 A 테스크를 진행하는 도중 B 테스크에서 오류가 발생했을 때였습니다. 예전 같았으면 "아, 오류 발견!"하고 바로 수정에 들어갔겠지만, 이번에는 우선순위에 따라 계획적으로 진행해 보자는 생각이 들었습니다. 오류 수정도 하나의 독립된 테스크로 인식하고, 현재 작업을 끝마친 후 수정하기로 마음먹었죠. 그래서 오류 수정을 새로운 테스크로 만들어 우선순위를 다시 매기고, 중요한 기능을 마친 후에 손보자는 계획을 세웠습니다.
이 과정에서 정말 중요한 일에만 집중하며, 우선순위에 따라 처리하는 방법을 배울 수 있었습니다. 이제는 문제가 생겨도 즉시 해결하려 하지 않고, 계획적으로 테스크를 관리하며 차근차근 진행하는 습관이 생겼습니다. 덕분에 예전보다 훨씬 효율적으로 작업할 수 있게 되었습니다.
👽 적절한 피드백을 받으며 작업하는 경험
프리코스 기간 동안 가장 큰 경험은 ‘적절한 피드백을 받으며 작업하는 경험’이었습니다. 다양한 피드백 방식을 통해 작업 과정에서 방향성을 잃지 않고, 궁극적으로 내가 무엇을 하려는지를 끊임없이 고민할 수 있었습니다.
프리코스에서 경험한 주요 피드백 방식은 다음과 같습니다.
- TDD를 통한 피드백
- 테스트를 통해 구현 과정에서 바로 피드백을 받으며 기능이 올바르게 동작하는지 확인할 수 있었습니다.
- 구현 목록을 보며 피드백
- 미리 작성한 구현 목록을 통해 누락되거나 수정이 필요한 부분을 손쉽게 확인할 수 있었습니다.
- 회고를 통한 자기 피드백
- 작업이 끝난 후 회고를 통해 스스로 진행 방식이나 결과를 돌아보며 부족한 점을 찾아 개선할 수 있었습니다.
- 프리코스 동료의 코드 리뷰를 통한 피드백
- 동료들로부터 코드 리뷰를 받으며 새로운 관점과 아이디어를 얻고, 코드 개선점을 확인할 수 있었습니다.
- 디버깅 사고 과정을 정리한 목록을 통한 피드백
- 디버깅 과정에서 문제 해결의 사고 흐름을 정리하면서 문제 해결의 정확도를 높일 수 있었습니다.
이 과정에서 거창한 피드백이 필요한 것이 아니라, 작업 중 간단한 회고를 통해서도 충분히 피드백을 얻을 수 있다는 점을 배웠습니다. 예를 들어, "이 부분이 부족하니 이제 이 부분을 보완해야겠다"와 같은 작은 피드백도 방향을 잡아주고, 목표에 더욱 집중할 수 있도록 도와주었습니다.
적절한 시점에 풍부한 피드백을 받는 것은 작업의 질을 높이고 차근차근 성장해 나갈 수 있는 좋은 경험이라는 것을 느꼈습니다.
