부스트캠프 웹·모바일 9기 챌린지과정이 8월 9일로써 마무리 되었습니다👏👏👏
6월 24일 시작된 베이직부터 참여했으니 거의 2개월 정도의 시간이 정신없이 흘러갔네요
챌린지 1주차 회고를 보시면 아시겠지만 저는 부스트캠프 웹·모바일 5기 챌린지 과정을 수료했습니다. 그리고 이름 들으면 대부분 아실만한 중견 서비스 기업에서 2년 조금 안되는 경력도 있어요
그래서인지 주변 사람들에게 말했을 때는 “너 이미 꽤 하잖아? 부트캠프에 다시 갈 필요가 있어?” 라는 반응이 주 였던 것 같고, 1주차 그룹회고에서 수료생임을 밝혔을 때는 “혹시.. 굳이 다시 하신 이유를 물어봐도 괜찮을까요?” 라는 반응이 있었어요.
그래서 이번 회고에서 어떤 부분이 좋았었는지, 왜 부스트캠프를 다시 선택했는지, 다시 참여했어도 성장했는지 등을 함께 남기면, 다음 참여하실 분들에게 큰 도움이 될 것 같아 글을 남깁니다.
부캠를 통해 얻을 수 있었던 것들
부스트캠프를 통해 단기간에 빠른 역량 향상을 할 수 있었어요, 하지만 개발 역량 향상은 부캠에서 얻을 수 있는 것들 중에 가장 사소한 부분입니다.
저 같은 경우는 부스트캠프 웹·모바일 5기 챌린지과정을 수료한 직후 보다, 현업에서 업무를 수행하며 좋은 경험이었다는 것을 실감할 수 있었던 것 같아요!
챌린지 과정에서의 어떤 부분들이 저에게 큰 자산이 되었는지 말씀드려보면 좋을 것 같습니다😀
인식의 부재와 우매함의 봉우리
필립 G.아모어가 집필한 The Laws Of Software Process라는 책에서 무지의 다섯 가지 단계에 대해서 언급하는데
소프트웨어 전문가들이 자신이 알고 있는 것과 알지 못하는 것을 이해하는 지표로 사용할 것을 권하고 있습니다.
- 0 단계: 무지의 부재
- 어떤 것을 알고 있음을 증명할 수 있는 상태
- 1 단계: 지식의 부재
- 어떤 것을 알지 못하는 상태
- 2 단계: 인식의 부재
- 어떤 것을 알지 못한다는 그 자체를 모르는 상태
- 3 단계: 효율적인 프로세스의 결여
- 무언가를 모든다는 사실을 알지 못한다는 것을 밝혀낼 적절하고 효과적인 방법이 없는 상태
- 4 단계: 메타무지
- 무지의 5단계에 관해 알지 못하는 상태
저는 이런 무지의 단계를 보며 더닝 크루거 효과(인지 편향 그래프)가 같이 떠올랐어요
- 자신이 가능 능력에 비해 자신의 능력을 과대평가
- 다른 사람의 능력을 알아보지 못함
- 자신의 능력부족으로 직면하는 어려움에 대한 인식저하
- 깨달음과 지식의 증가를 통해 능력이 증가한 후 자신의 능력부족을 인지, 인정
더닝 크루거 효과는 우매함의 봉우리(mount stupid)로 유명한데요, 기존에 알고 있는 것이 사실과 다르거나 틀리다는 것을 인지하게 되면서 겸손한 자세로 배우려는 태도를 갖게 된다는 것을 설명합니다.
부캠에 입과하는 대부분 캠퍼분들은 학교에서 꽤 잘하는, 동아리 에이스 등 각자 본인 역량에 자부심이 있으셨을거에요
저 같은 경우 이러한 자부심은 5단계 무지 중 2단계인 인식의 부재가 바탕이 되었었는데요
그러한 이유로 각자 한따까리 잘 하시던 분들이 만들어낸 각자 다르게 잘한 결과물들을 통해 문제를 한번에 많이 인식하게되고, 절망의 계곡으로 빠르게 떨어지게됩니다🎢
아는만큼 보인다는 말의 뜻을 알게됩니다😂
이러한 부분은 주니어라면 언젠간 꼭 느끼게 되는 경험인데, 이후 생각해보니 빨리 경험해서 오히려 좋아!라는 생각이 들더라구요
남들보다 빠르게 깨달음의 오르막을 오르게되며, 겸손해지는 것은 물론이고 다른 사람들의 의견을 존중할 수 밖에 없게 되어버립니다.
좋은 결과물에 대한 기준
부스트캠프 챌린지에서의 경험이 없었다면, 아마도… 개발자로 업무를 수행하면서 길을 잃고 해맸을 것 같다는 생각을 많이 했었어요
이러한 생각을 하게 되었던 이유는 개발자가 만들어내는 결과물의 품질은 중요하지 않다고 생각하는 환경이 훨씬 더 많다고 느껴졌기 때문입니다.
이로 인해 조직에서 정의하는 좋은 개발자의 기준도 이상적인 개발자의 기준과는 생각보다 많은 차이가 있었어요
정말 아쉽게도 기술을 중요하게 생각하지 않는(말로만 중요하다고 하는, 기준이 낮은) 회사들이 정말 많습니다.
클린코드와 같은 여러 책 들에서도 언급되는 내용이지만, 이러한 회사들은 대부분 무리한 일정으로 결과물을 만들어내길 원하고 이러한 과정이 반복되며 악순환이 발생합니다.
- 사실 서류상으로 책임을 회피을 하기 위해 그러는 것 같다고 느껴지기도 했어요
이런 환경이 고착화되면 굉장히 많은 문제가 발생하지만, 그 중에서도 품질에 대한 기준이 없어지거나 왜곡되는 현상이 신입 개발자에게 가장 치명적이라고 생각합니다.
경험이 적은 신입 개발자가 이러한 환경에 노출되면, 왜곡된 품질 기준이 옳은 방향이라고 믿게 되어버리는 문제까지 발생할 수 있고, 안타깝게도 실제로 많이 보이는 사례입니다.
“이러한 환경에서 부스트캠프는 저에게 좋은 결과물에 대한 기준을 잡아줬습니다.”
신입 혹은 예비 개발자들은 위에서 언급한 인식의 부재 즉, 좋은 결과물에 대한 기준이 없거나, 많이 낮기 때문에 위과 같은 문제가 발생하게 된다고 생각합니다.
좋은 결과물에 대한 기준을 잡기 위해서는 당연하게도 좋은 결과물을 많이 접해봐야하지만 현실적으로 너무 어려운 일이죠…
하지만! 부스트캠프에서 다양한 강점을 가진 분들이 모여 각기 만들어낸 좋은 결과물들을 많이 접할 수 있었습니다.
그래서 저는 왜곡된 품질 기준이 옳은 방향이라고 믿게 되어버리는 문제에서 비교적 자유로울 수 있었습니다.
효진적 사고
최근 마무리된 올림픽 사격 여자 공기소총 10m 국가대표인 방효진 선수님은 “나도 부족하지만 남도 별거 아니다.“라며 불안을 인정하는 효진적 사고로 그 부담감을 극복하고 금매달을 따 내실 수 있었다는 인터뷰를 봤습니다.
저도 5기 챌린지가 끝나고 멤버쉽에 가지 못했고, 잘 하시는분들을 직접 많이 접하다보니 저의 역량에 대해서 자신감이 많이 떨어져 있었어요
하지만 시간이 흐를수록 제 자신이 성장했다는 것을 확인할 수 있었던 계기들이 있었고, 결과적으로 이러한 효진적 사고를 탑재하게 되었습니다.
응. 맞아 나 지금은 잘 못해.
근데 내가 평생 못 할 것 같아?
나는 계속 노력할 거고 조금씩 성장해왔어
언젠간 잘 하게 될 거야!
운영진 제이님이 공유해주셨던 명언도 다시 생각나네요
억까에도 강해집니다.
글을 쓰고보니 모두 동료 캠퍼들 덕분에 생기는 긍정적인 영항이었군요!
부캠에 다시 지원한 이유
그래서 왜 다시 지원했느냐라고 물어보신다면..! 아래와 같은 이유들이 있습니다.
동기부여
퇴사 후 푹 쉬고 다시 준비를 시작하는데… 너무 재미가 없었어요
퇴사 전 1년간 팀에서 가장 많은 티켓을 끊은 티켓머신이었던 저는 빡빡한 개발 일정으로부터 나오는 도파민에 뇌가 절여저 있었기 때문에, 저의 의지만으로는 동기부여를 하기 턱없이 부족했습니다.
그래서 저를 부추길 강한 프레셔가 필요했어요🤣
부캠의 어려운 미션과 빡센 일정이라면 저를 움직이게 만들 것 이라고 생각했고, 이러한 환경에 저를 던져야했습니다.
내 수준 파악하기
부캠은 경력 2년 이하의 주니어까지 참여 가능한 만큼 왜 오셨을까 생각이 들 만큼 잘 하시는 분들도 많이 계셨습니다.
그리고 경력이 없는데 이렇게까지 잘해질 수 있나 싶을 정도로 잘 하시는 분들도 많이 계셨었죠
그래서 이 분들과 저를 비교하면 저의 수준을 어느정도 파악할 수 있다고 생각했습니다.
도움을 드리고 싶어요
개발자로 얼마 안되는 기간 일 하면서 학교 후배, 동료 개발자 등 여러 주니어 개발자들과 자연스럽게 대화할 기회들이 있었는데, 같이 고민에 대해 이야기하다보면 개인적으로 안타까운 상황들이 있었습니다.
대부분의 경우는 위에서 언급했던 더닝-크루거 효과의 우매함의 봉우리와 절망의 계곡에서 발생하는 문제들이었어요
우매함의 봉우리
개발자 채용 설명회에 참여해본 분들은 신입 개발자는 역량으로 뽑지 않는다. 던가 잠재력이 중요하다. 이런 말씀을 많이 들어보셨을겁니다.
이런 내용을 들으면 듣기 좋으라고 하는 소리다. 스펙이 잠재력 아니냐라고 생각하시는 분들이 많은 것 같아요(아예 틀린 말은 아니라고 생각합니다.)
그래서 결국 실력으로 증명해야한다 라고 결론을 낸 분들을 많이 접할 수 있었던 것 같습니다.
그런데 일해보니까 정말 그렇지 않아요 정말 역량으로만 뽑지 않고, 성과를 중요하게 생각하는 회사들은 스펙은 크게 고려하지 않는 것 같습니다.
- 정확히 말하면 역량을 기준으로 잡으면 뽑을 사람이 없어요. 그럴거면 신입 말고 경력을 뽑는게 더 좋겠죠(저 포함 신입들 다 왠만큼 합니다.)
이렇게 실력으로 증명한다라고 결론을 내리신 분들은 대부분 본인이 뽑힐만한 역량이라고 믿는 분들이 많습니다. 사실 우매함의 봉우리 쯤에 있는 상태로 본인의 부족함을 인지하지 못하는 경우가 많아요
전 직장에 한 기수 먼저 들어온 주니어 개발자의 사례를 말씀드릴 수 있을 것 같아요, 취업 준비 기간을 오래 갖지 않으시고 거의 현역으로 입사했던 개발자였습니다.
이 분은 전환형 인턴 과정에서 적극적인 의사 표현과 태도, 열정을 높게 평가받아 높은 성적으로 전환되었지만, 본인은 개발자로서의 역량을 높게 평가받아 전환되었다고 믿고 있었습니다.
전환 이후에도 열정적으로 업무를 수행하셨죠, 하지만 시간이 지날수록 연차가 낮을 때는 용인할 수 있는 실수나 낮은 품질의 코드가 개선되지않아 평가가 나빠졌어요
그럼에도 불구하고 본인이 역량이 괜찮은 개발자라는 믿음을 버리지 못하셨고, 결국엔 성장을 포기하시게 되었습니다.
이 문제가 앞서 언급했던 절망의 계곡에 빠르게 진입하지 못했고, 좋은 결과물에 대한 기준이 없었기 때문에 발생한 문제로 생각하고 있습니다.
조금 극단적인 예시이지만 이러한 문제를 경험하지 않기 위해서, 극복하기 위해서는 조금이라도 빨리 좋은 결과물들을 많이 보는 것이 중요하다고 생각했어요
그래서 저도 이러한 좋은 결과물에 조금이라도 도움이 될 수 있지 않을까라는 생각했습니다.
절망의 계곡
우매함의 봉우리에서 내려왔다면 다음 문제인 절망의 계곡을 만나게 됩니다.
절망의 계곡에서 큰 타격을 입으시는 분들은 본인에 역량에 자부심이 강하던 분들이시죠
위 사례로 언급했던 주니어 개발자는 절망의 계곡에 들어서는 과정에서 본인이 역량이 떨어지는 개발자라는 것을 인정하기 어려웠고, 결과적으로 최악이라고 생각되는 회피를 선택하셨습니다.
저도 학교나 동아리, 대외 활동에서 주로 버스 기사 역할을 했었고 나름 제 역량에 대한 자부심도 있었기 때문에, 부캠을 끝내고 절망의 계곡에서 벗어나지 못하고 한동안 힘들었던 경험이 있었어요
절망의 계곡에서 느끼는 감정들은 성장을 위해 꼭 필요하다고 생각합니다.
그렇지만 오래 느낄 필요는 없다고 생각해요
자칫 저와 같이 극복하는 데 오랜 시간이 필요한 분들이 있을 수 있고(사실 많을 것 같다고 생각했어요) 그런 분들에게 포기하지 않도록, 금방 회복할 수 있도록 힘을 드리고 싶었습니다.
이전과 달라진 점
부스트캠프 웹・모바일 9기는 이전과 같이 기본기와 문제 해결력에 대한 내용들을 깊게 체험해볼 수 있다는 점은 같았지만, 5기와 비교했을 때 많은 것이 달라져 있었습니다.
이러한 이유로 어떠한 부분이 달랐는지 살펴보고, 제가 어떤 부분에서 신경을 썻는지 살펴보면 좋을 것 같아요
베이직 과정
처음으로 베이직 과정이 신설되었습니다.
베이직 과정은 1차 문제해결력 테스트 결과에 따라 선택적으로 참여하는 과정이었는데, 저 같은 경우 2차 문제해결력 테스트 직행이었지만 참여했어요
제 기억에는 대략 1,000명 이상이 베이직 과정에 참여하셨던 것으로 알고있습니다.
5기 챌린지 과정과 마찬가지로 다른 사람들의 결과물을 확인할 수도 있었고, 팀 활동도 있다는 점이 특별했던 것 같습니다.
결과물에는 자신이 문제를 해결해나간 과정을 README를 통해 꼭 남겨야 했기 때문에 다른 사람의 접근 방식들도 잘 파악할 수 있었습니다.
아마 개발 관련 학습을 오래 하시지 않았다면, 베이직 과정을 성실하게 참여하고 다른 분들의 결과물들은 볼 수 있는 것 만으로도 많은 도움이 되셨을 것 같다는 생각이 들었어요
미션
베이직 과정은 요구 사항은 조금 복잡하지만 구현 자체는 어렵지 않은 미션들을 해결해야했습니다.
5기 챌린지 과정 미션에 비교한다면, 베이직의 미션은 챌린지 미션에서 구현해야 할 전체 기능 중 일부 기능을 구현하는 정도로 느껴졌던 것 같습니다.
다만 깔끔한 설계가 반영되었을 때 완전히 다른 결과물을 만들 수 있어서, 평소 알고리즘 테스트같이 구현만을 위한 코딩을 해오신 분들 이라면, 다른 잘한 결과물을 봤을 때 내 결과물이 뭔가 잘못됐다는 것을 느꼈을 것 같았어요
저 같은 경우 구현 자체에는 시간이 많이 필요하지 않았습니다. 그래서 많은 시간을 좋은 설계를 위해 활용했던 것 같습니다.
거기에 더해서 읽기 쉬운 코드를 만들고, 저의 생각과 코드를 더 쉽게 이해할 수 있도록 분석 부터 구현까지의 모든 과정을 상세히 README에 기록하려고 노력하였습니다.
팀 활동
팀 활동에서 특별했던 점은 구현뿐만이 아니라 설계미션이 주어졌다는 점 인데요
개발을 할수록 느끼는 점은 설계가 참 중요하다는 것 입니다.
저는 설계를 완성하는 과정에서 소프트웨어가 완성된다고 생각해요, 구현은 그 설계를 코드로 조금 더 상세하게 옮겨 적는 것 뿐이라고 생각하죠
그래서 저는 항상 프로그래밍에서 구현 자체는 사소한 부분이라고 말 합니다.
설계의 중요한 역할 중 하나는 머리속에 떠다니는 내용들을 글이나 그림을 통해 현실 세계로 가져와 규격화하는 것이라고 생각합니다.
그렇기 때문에 설계에 대한 개념 자체가 없으셨던 분들, 중요성을 체감하지 못하셨던 분들은 팀 활동을 통해 설계를 하며 다른 사람들의 생각을 더 깊게 이해해보고 정리하는 과정이 성장에 큰 도움이 될 것 같다고 느꼈어요
교육을 설계하실 때 굉장히 많은 고민이 있었다는 것이 느껴졌습니다.
저는 팀 활동에서 다른분들과 함께 의견들을 글과 그림으로 표현해보며 생각을 공유하기 위해 노력했고, 설계가 필요한 이유들을 최대한 느낄 수 있도록 노력했습니다.
챌린지 과정
챌린지 과정에서의 학습 내용들은 5기때와 차이가 없었습니다.
하지만… 3년간 무슨 일들이 있었을까요? 난이도는 꽤 많이 상승되었다고 느껴졌습니다.
Chat-GPT와 같이 개발을 도와줄 도구가 등장했다는 것도 난이도 상승에 영향을 줬을 수도 있을 것 같고, 베이직 과정에서 잘 하시는 분들이 많아 난이도를 올렸을까? 라는 생각도 들었어요
아니면 아는 만큼 보인다는 말 처럼 제가 더 성장해서 문제의 본질을 더 잘 알게되었을까? 라는 생각도 들었던 것 같습니다.
무슨 이유던 이전보다는 많이 어렵게 느껴졌어요. 5기때는 요구사항을 모두 만족하지 못했던 미션이 마지막 2개쯤 뿐이었고, 대부분 오후 12시 이전에 마무리 했었다면…
9기 챌린지 과정에서는 요구사항을 모두 만족시키지 못한 과제가 꽤 있었고, 적어도 오전 2시까지는 문제해결을 위해 시간을 보냈습니다.
사실 문제해결을 통한 역량이 향상되는 것은 큰 기대를 하고 있지 않았었는데, 관련 내용들을 다시 복기하고 결과물을 만들어가는 과정에서 기대보다 더 많은 성장을 할 수 있었습니다.
짝 미션
5기때와 가장 큰 차이점은 짝 미션이었습니다.
짝 미션은 챌린지 과정 4주 중 마자막 2주는 짝 미션을 중심으로 진행될 만큼 큰 비중을 차지했어요
짝과 함께 설계 후 각자 결과물을 만들어보는 짝 설계, 짝과 설계와 구현을 함께하는 짝 구현, 단순히 같이 개발하는 짝 구현을 넘어 페어 프로그래밍을 해야하는 미션도 있었고, 같이 만든 결과물을 각자 개선해보는 각자 개선하기, 각자 만든 결과물을 같이 개선해보는 짝 개선이 있었습니다.
현업에서도 관련 경험이 없었기 때문에 굉장히 흥미로웠는데 이 중 짝 설계와 페이 프로그래밍이 가장 인상적이었습니다.
짝 설계
혼자 미션을 수행할 때는 요구사항 분석 과정에서 애매한 부분에 대해 의사 결정에 시간이 많이 필요했었습니다.
하지만 짝과 함께 설계를 진행하며 짝과 함께 미션 요구사항을 분석하며 서로 중요하다고 생각되는 것들, 불필요하다고 생각하는 것들을 공유하고 토론하며 훨신 더 빠른 의사결정을 했던 경험이 아주 긍정적이었어요😀
서로 다르게 이해한 부분을 줄이기 위해 필요한 기능들을 mermaid를 활용하여 클래스 다이어그램을 이용해 시각화하기도 했습니다.
같은 설계를 통해 구현했음에도 불구하고, 큰 틀을 제외한 세부 사항들이 완전히 달랐다는 것은 정말 흥미로웠네요
페어 프로그래밍
여러번의 페어 프로그래밍이 있었지만 마지막 미션이 가장 기억에 남습니다.
짝이 저와 마찬가지로 TDD를 계속해서 시도하고 계셨던 분이셔서 자연스럽게 TDD를 활용해서 페이 프로그래밍을 수행하였습니다.
기능 단위를 기준으로 같이 테스트 케이스를 만들고 네비게이터와 드라이버 역할은 바꿔가며 진행하였는데, 실시간으로 피드백을 주고받으며 점진적으로 더욱 좋은 결과물을 만들어가는 과정이 굉장히 유익하다고 느껴졌어요
애자일 방법론에서 반복적이고 점진적인 개선과 협업 정신을 위해 TDD와 페어 프로그래밍을 강조하는 지 이유를 조금이나마 느낄 수 있었던 것 같습니다.
내가 시도한 것들
협업에서 풀스택 개발자로서 일하는 과정에서 저에게 부족한 부분이라고 생각되었던 문서화와 TDD를 적극적으로 시도하려했습니다.
문서화
개발자로 일하는 과정에서 문서화를 하지 않았던 것은 아닙니다.
복잡한 업무라던가 새롭게 추가되는 기능 같은 경우에는 꽤나 꼼꼼히 문서를 작성하기도 했었어요
하지만 이 외에는 단순히 업무 기록을 위해(이후 발생할 시시비비를 가리기 위해) 문서를 작성하는 느낌이 강했습니다.
- 물론 전 회사에서도 업무 기록 수준의 문서화를 요구했습니다. (사실 저는 개발 문서라고 생각하지 않았어요)
개발 문서는 정책을 협의하는 과정에서 왜 이렇게 선택할 수 밖에 없었는지, 구조를 왜 이렇게 해야했는지와 같은 히스토리와 앞으로 어떤 식으로 수정되길 바라는지와 같은 내용들을 통해 이후 유지 보수를 더 잘 할수 있도록 만들어주는 것이 목표라고 생각했습니다.
이후 해당 영역을 담당할 개발자들이 관련 내용을 보며 다른 접근 방식을 알고 있어 개선한다던가 하는 긍정적인 효과를 기대했던것이죠
하지만 업무 기록 수준의 문서화를 요구받다보니 시간을 많이 부족했고, 다른 문서들도 업무 기록 수준이었기 때문에 참고할만한 자료도 없었습니다. 그래서 점점 공을 많이 안들이게 되더라구요
미션을 수행하면서 만들어지는 요구사항 분석 내용, 설계 등과 같은 내용들은 유지보수와는 관계가 없겠지만, 다른사람들이 보고 내 결과물을 쉽게 파악할 수 있다는 부분에서는 공통점이 있다고 생각했습니다.
그래서 더 좋은 피드백을 받기 위해서, 다른 분들이 더 쉽게 영감을 받게 만들기 위해 분석 내용과 설계 등을 최대한 상세하면서도 잘 읽히도록 만들기 위해 노력했던 것 같습니다.
TDD
이전 직장은 저품질 레거시 코드로 인해 악순환이 발생하고 있는 상황이었습니다.
주요 원인 중 하나는 테스트 코드를 전혀 작성하지 않고 QA에 의존하는 개발이 원인이라고 생각했어요
- 테스트 코드가 없으니 변경 자체가 굉장히 도전적인 일이 되어버립니다.
- 그러다 보니 최소한의 변경을 위해 작은 코드들이 붙여져 나갔고 코드 품질은 더 나빠지게 되어버렸습니다.
- 코드의 결합이 높고, 중복되는 로직이 많다보니 테스트 코드 자체를 시도하는 것이 어려웠습니다.
- 같은 이유로 이미 구현되어있는 비즈니스 로직 분석이 굉장히 어려웠습니다.
이러한 환경에서 개발을 수행하다보니 테스트 코드의 중요성을 크게 느꼈지만, 어떻게 접근해야할지 감을 잡을 수 없어 적용하지 못했습니다.
퇴사 이후 TDD를 적극적으로 활용하는 회사의 과제 테스트를 수행해볼 기회가 있었습니다.
이를 위해 테스트 코드 관련 자료들을 찾아가며 나름대로 테스트들을 만들었고, 이후 면접에서 어떤 식으로 테스트 코드를 작성하는지 물어본 후 대략적인 방향성을 배울 수 있었어요.
이 때 들었던 내용 중 가장 인상깊었던 내용은
“저희는 요구사항과 정책이 완성되면 그 내용들을 전부 테스트 코드로 작성해요”
였습니다. 나중에 찾아보니 BDD가 요런 맥락으로 진행되더라구요
그래서 저도 이러한 방식들을 적용해보려 시도했고 어느정도 TDD 적응할 수 있었던 것 같습니다.
애자일스러운 개발
TDD와 더불어 변경을 가정하고 전체 기능의 일부만 설계하고 구현해나가는 애자일스러운 개발을 시도했습니다.
처음에는 전체를 설계하고 기능을 나누어 구현하는 방식으로 진행했었는데, 구현 과정에서 요구사항을 잘못 분석했거나, 설계가 잘못된 것을 확인하게 되는 경우가 종종 있었습니다.
이 중 일부는 큰 변경이 따라와서 설계 전체가 흔들리게되는 경우가 종종 발생했었어요
이 때문에 고민하고 있었는데, 부스트캠프 마스터인 JK님이 애자일스러운 개발에 대해 언급해주셨고, 이를 즉시 반영하였습니다.
필요하다고 생각되는 기능들을 대략적으로 분리한 후 그 중 일부만 설계하고 개발했는데 당연하게도 변경은 발생했지만, 영향 범위는 극히 제한적이었어요.
TDD와 결합하니 마치 게임을 하는 것 같은 느낌마저 받을 수 있었습니다 🎮🎮
마무리
13일부터 글을 작성하기 시작했는데 16일에 마무리하게 되었습니다. 간만에 많은 시간을 들여 글을 써본 것 같네요
글을 작성하는 도중에 3차 문제해결력 테스트 결과가 나왔어요. 이번에는 멤버쉽을 경험할 수 있게 되었습니다.👊
멤버쉽에 가지 못하시는 분들도 계실 것 같아요! 하지만 낙담하지 않으셨으면 좋겠습니다.
저도 5기에는 챌린지 과정까지만 참여할 수 있었지만, 챌린지에서의 경험만으로도 큰 성장을 이뤘다고 생각해요
실제로 취업 후 팀 막내였음에도 불구하고 구현에서만큼은 상위권이었습니다. 마찬가지로 어디 가서 꿀리지 않으실거에요🔥
앞으로 시작할 개발자 커리어에서 부스트캠프는 하나의 마일 스톤일 뿐입니다. 중요한 체크 포인트 하나를 달성했으니 다른 체크포인트를 달성해야겠죠?
앞으로 달성해야할 체크포인트를 위해 포기하지말고 함께 끝까지 나아가봐요 🏁
끝까지 읽어주셔서 감사합니다😄