안녕하세요. 부스트캠프 9기 챌린지를 진행중인 김정욱입니다.
저번주엔 결국 회고를 못쓰게 되어서 이번에 본격적으로 부스트캠프를 진행한 2주차&3주차의 회고를 쓰게 되었습니다.
바쁘고 정신없게 달려왔기에 뜻깊었던 10일을 되짚어보겠습니다.
딜레마에 빠지다
아마 개발을 해보신 분이라면, 그 중 제한된 시간에 개발을 해보신 분들이라면 더욱 더 한번쯤은 생각해보신 부분일 것이라 생각됩니다.
설계가 부족한걸까? 아니면 구현이 부족한걸까?
내가 만들어내야 하는 프로덕트의 개발 제한시간 때문에 매순간 이런 고민에 빠지게 되었습니다. 저는 늘 구현을 더 중시해오던 사람이었습니다. 저에게 설계는 일단 구현을 하다가 막히는 부분이 올 때 한번 만들어놨던 것을 되짚어보고 어떻게 이어서 만들어나갈지 생각해나가는 단계였었습니다.
시행착오
그러다 부스트캠프 1주차를 하게 되고 저는 초기의 탄탄한 설계를 통해 구현을 빠르게 할 수 있을 것 같다는 생각을 하게 되었습니다. 그리고 설계를 잘 해봐야겠다 다짐하고 찾아온 2주차의 저는 역시 설계를 버거워했습니다. 내 속에서 계속 아래와 같은 생각이 들었습니다.
대충 요구사항 다 이해하지 않았어? 일단 만들어보고 생각해봐
거기에 더해서 뭘 어떻게 설계해야 할지도 막막했습니다. 결국 한번 더 일단 만들어보고 부딫히자는 결론을 내리고 미션을 진행했습니다.
저는 제가 잘하는것을 보여주고자 부스트캠프를 신청한 것이 아니고 못하는것을 시도해보고 배우고자 참여한것이었는데, 결국은 또 제가 잘 하는 것만 하려하고 새로운 것은 시도해보려 하지 않았다는 점에 아쉬워했습니다.
동료에게 배우다
부스트캠프에는 피어세션이라는 시간이 있습니다. 이 시간에는 피드백을 주고 받을 수 있는 시간이 있는데, 꼭 피드백을 받지 않는다 하더라도 동료들의 코드나 설계 과정을 보면서 스스로 배울점들을 찾을 수 있습니다.
저는 이 시간에 동료들은 설계를 어떻게 했나 지켜봤습니다. 그 중 Class Diagram을 작성하신 분들이 자주 보였습니다. 확실히 Class Diagram을 작성한 분들의 코드를 읽을 때랑 없는 분들의 코드를 읽을 때 차이가 있었습니다. 각 클래스가 어떻게 서로 관계되어있고, 각 클래스가 어떤 역할을 하는지가 Class Diagram을 작성한 분들의 코드에서 더 잘 다가왔습니다.
그래서 2주차의 저는 Class Diagram을 그려보자는 새로운 시도를 하게 됩니다. 그리고 어떤 툴을 사용하여 그릴까 고민하던 중 동료가 mermaid라는 것을 사용하여 markdown 내에서 문구를 통해 Diagram을 그리는 것을 보고 이거다! 생각해서 사용법을 검색하여 배워봤습니다. (mermaid 사용법)
개선하다
위와같은 다짐을 한 날 저는 Class Diagram을 어려웠지만 그려보았고, 확실히 효과는 있었습니다.
전부 그려놓고 보니 내가 만들려고 생각한 Class들 사이에서 불필요한 역할의 중복이 보였고, 불필요한 종속성도 보였습니다.
몇번을 새로 다시 그리면서 만족스러운 Diagram을 그린 후 구현을 진행하니 미리 생각해 놨던 기능들만 구현을 하면 되는 것이라 훨씬 진행이 수월해졌습니다.
mermaid 정말 잘 배웠다 생각하고, 앞으로도 유용하게 잘 사용할 것 같습니다. 그리고 짝 설계나 프로그래밍을 할 때 마다 제 짝에게 항상 먼저 mermaid 영업을 하고있습니다…ㅎㅎ
설계도 만능은 아니었다
미션을 해결하기 위해선 배워야 할 내가 몰랐던 배경지식도 많이 학습해야 합니다. 그래서 특히 어려운 배경지식이 나오는 날 학습하고, 설계하면서 구현의 비중이 너무 작어졌던 것 같습니다.
지금 다시 생각해보면 학습이 너무 오래걸려서일 수도 있지만, 이럴 때면 더 설계와 구현의 비중을 잘 배분했어야 했는데, 이번엔 그 부분에 대해서 부족했습니다. 이제는 저에게 이런 생각이 들었습니다.
명확하지 않은 부분 있는데 이렇게 설계 끝낼거야? 다시 생각해보자
다이어그램을 다시 만들고 수정하고 반복을 하다 보면서 오히려 더 미션이 미궁속으로 빠져가는 날도 있었던 것 같았습니다. 물론 시간만 많다면야 나갔다 와서 머리 리프레시 하고 다시 생각해보고 다음날 구현한다던가 하면 되겠지만, 주어진 시간은 호락호락하지 않았기에 지나서 다시 생각해보면 설계가 어느정도 되면 일단 구현을 좀 해 보면서 빠지거나 부족한 부분을 찾는 시간도 필요했었을 것 같았습니다.
결론
제가 한주동안 이랬다 저랬다 하는 부분에서 저는 왜 많은 다른 캠퍼분들이 설계와 구현의 비중을 항상 궁금해하는지 알게 되었습니다. 그리고 이건 확실히 답은 없고 케바케 사바사라는 것을 느꼈습니다. 숙련된 개발자일수록 유동성있게 주어진 환경에 따라서 비율을 잘 설정할 것이라 느꼈고, 저희는 아직 배우는 단계이다 보니 당연히 이에 대해서 시행착오를 겪고, 오히려 이런 과정을 통해 강해질 수 있을것이라 생각했습니다. (물론 시행착오 하는 순간에는 힘들었지만요…ㅋㅋㅋㅋ)
함께일 때 우린 강해지지만, 무작정 강해지는 것은 아니다
부스트캠프에서는 공동체를 강조하고 서로 도움을 주고받으며 성장을 추구하고 있고, 실제로 지금 그 효과를 누리고 있다고 생각합니다. 하지만 그냥 머리수만 많아졌다고 무조건 강해졌다라고 생각해서는 안된다는 생각을 느꼈습니다. 그렇다고 짝과 불화가 있었다는 것은 절대 아닙니다! 이런 생각을 하게 된 과정에 대해서 얘기해보겠습니다.
부푼 기대
제가 부스트캠프에서 처음 지원할 때부터 늘 한결같이 부스트캠프에서 기대되는 점이 무엇이냐 하면 항상 똑같은 답을 적어냈습니다.
부스트캠프에 지원한 다른 훌륭한 동료들과 같이 프로젝트를 진행하는 것이 기대됩니다.
지금도 같은 생각이고, 위와 같은 생각을 항상 가지고 있기 때문에 멤버십에 참여해면 좋겠다고 쭉 생각했었습니다. 그리고 챌린지에서도이와 같은 경험을 할 수 있게 되었고, 폐가 되지 않을까 걱정이 되면서도 한편으로는 기대되었습니다.
좋은 동료
1주일에 매일 1시간남짓 만나는 시간이지만 피어세션을 진행하면서 만나는 동료들은 항상 좋은 동료들이었습니다. 프로그래밍에 대해 열의도 있고 친절하고 서로에게 도움을 주기 위해 노력했습니다. 부스트캠프에 관심을 가지고 지원한 분들이라면 대부분 이와 같을 것 같았고, 그래서 지원하기 전부터 기대를 했던 것이었습니다. 이런 분들과 같이 프로젝트까지 진행을 하면 정말 많은것을 배울 수 있을 것 같았습니다.
시행착오
아무리 좋은 동료라 할지라도 사실 우린 모두 같은 배우는 단계의 개발자입니다. 저 또한 마찬가지이구요. 그렇기 때문에 많은 경험이나 노하우가 있지 않습니다. 그러다보니 이런 배우는 개발자끼리 협업을 진행하면서 당연히 시행착오들은 생기게 되었습니다.
설계를 어떤식으로 할지부터 시작하여 학습해 온 내용, 구현 순서, 구현 방식 등 다양한 곳에서 서로의 차이점을 보였습니다.
깨달음
제가 만들지 않은 함수는 함수 이름만 보고 이 함수가 뭘 하는 것인지 감도 잘 안오고, 변수 또한 마찬가지였습니다. 그리고 설계는 난잡해지고 짝은 어떤 부분이 구현 필요한 부분이라 주장했지만 저는 안필요해보였고 등등 이런 과정 속에서 혼자 프로젝트를 진행할 때 보다 더 많은 고민을 하게되었습니다.
이 과정 또한 부스트캠프에서 의도한 하나의 학습과정이라는 것을 느꼈습니다. 협업을 할 수록 생각할 머리가 하나 더 생기는 것이니 작업이 더 빨라지는 것은 맞습니다. 하지만 그 전에 팀원끼리 한 몸처럼 일을 해야지만 효과적으로 빨라진다는 것을 알게 되었습니다. 그때문에 세상에 코드 컨벤션이라는것이 존재하고 프로젝트 전 규칙을 만들고 하지 않겠습니까?
하지만 저희는 그 부분까지 서로 맞추기에 너무 시간이 부족해졌었습니다. 그래서 어찌보면 그 부분은 포기하고 한 코드에서 두명의 개성이 많이 들어가버린 물과 기름이 섞여있는 느낌의 프로젝트가 완성되었습니다.
아쉬운 개선
팀으로 진행한 프로젝트를 저 혼자서 개선하게 된 시간에 제가 한 작업을 한줄로 요약하자면 **“기름을 걷어내고 그 자리를 물로 채우는 것”**이었습니다.
제가 기대한 팀 프로젝트와는 거리가 멀었습니다. 서로의 좋은 아이디어들이 섞여서 만들어진 프로젝트가 아닌 그저 2일동안 만들어낸 개인 프로젝트 느낌이 나버렸습니다.
제가 생각했던 안필요해보였던 부분이 구현된 곳은 삭제하고, 파일구조와 함수명 변수명은 제가 편하게 싹 다시 바꾸면서 결국 미션을 완수하긴 했습니다.
배운점
하지만 이 과정에서 배운점이 있다면 그것으로 뜻깊은 경험이 될 수 있다고 생각합니다.
저는 여기서 프로젝트 개발 전 규칙을 정하고 각자 코드 컨벤션을 익히는 부분이 많이 중요한 과정이라는 것을 배웠습니다.
그리고 서로의 입장이 다를 때 무조건 수용하는 것이 아닌 저의 입장을 잘 정리해서 나는 왜 이렇게 생각했는가 완벽히 전달하는 것이 개발 시간을 단축시킬 방법이 될 수도 있구나 생각했습니다.
나중에 팀에 들어가 개발할 것에 대비해 코드 컨벤션들을 여러 종류 찾아보고, 왜 이렇게 정했을지 생각해보는 시간도 가져야겠다고 다짐할 수 있었던 경험이었습니다.
마치며
이제 챌린지는 단 한주밖에 남지 않았습니다. 저에게 앞으로 두번의 미션과 한번의 시험이 다가올텐데 신기하게도 1주차를 끝마쳤을 때 보단 불안감이 더 사라진 것 같습니다. 제 실력이 갑자기 엄청나게 늘어서라기보단 아마 지금 챌린지를 하고있는 현재를 잘 즐기고 있어서라고 생각합니다.
멤버십을 가고싶은 마음은 여전합니다. 그런데 챌린지에서 느낀점이 워낙 많아서 그런지 이걸 곱씹는데에도 시간이 부족하게 느껴집니다. 1주차 때 다짐한 멤버십을 가지 못할까 불안해하는 마음을 비우는 것 하나는 그래도 잘 지켜진 것 같네요…ㅎㅎ
마지막으로 이번주는 겸손하자는 생각을 많이 했습니다. 같이 발전해나가는 부스트캠프, 그리고 다른 모든 개발자 조직들에서 역시나 중요한 것은 겸손인 것 같습니다.
많은 사람들에게 영감을 줄 프로그래머. 그 최종 목표를 잊지 않고 챌린지의 마지막 4주차도 달려보겠습니다.
지금까지 읽어주셔서 감사합니다!