📚 책 선정
6월 초 CS 스터디 진행 방식을 기존처럼 자유 주제 탐색이 아닌 "책 완독하기" 로 변경하면서 뒤도 돌아보지 않고 선택한 책이 바로 헤드퍼스트 디자인 패턴 이다. 비록 당시 취준에 막 발을 담그고 있던 시기였기 때문에, 주변에서 면접을 위한 공부를 하는 것이 좋지 않겠냐 라던가 굳이 이 시점에 신입 개발자에게 요구되지 않는 역량을 깊게 공부할 필요가 있느냐 같은 우려를 한 몸에 샀지만... 한 번쯤은 꼭 공부해보고 싶었던 과목이었고, 원하는 걸 마음껏 공부해볼 수 있는 시기가 바로 지금이라는 생각이 들어서 고집스럽게 디자인 패턴을 주제로 선정했다.
책은 당시 교육을 듣던 컨설턴트님께서 디자인 패턴을 간략하게 설명해주실 때 저 책을 언급하면서 '술술 훑어보기 좋더라' 라고 하셨던 책으로 선정했다. 물론 그 외에도 주 언어가 Java인 만큼 코드가 Java로 쓰여있기를 바랬고, 항상 기초가 부족하다고 느끼고 있었기 때문에 너무 깊은 내용을 다루는 책 보다는 적당히 라이트한 느낌의 책이 필요했다는 이유도 있었다!
🤔 왜? 굳이? 지금?
디자인 패턴을 자세히 공부해보고 싶다고 했을 때, 가장 많이 받았던 질문이다. 디자인 패턴을 왜? 굳이 그걸 그렇게나 자세하게? 지금 해야 할 공부가 산더미인데? 등등... 모든 질문에 구구절절 이유를 대며 해명하진 않았지만, "그냥 전부터 해보고 싶어서" 라고 둘러댔다. 사실 저 짤막한 해명에는 그동안 몰래몰래 해왔던 나름의 고민이 담겨있었다.
🌲 고민 1. 나무가 아닌 숲을 보는 시각
사실 무경력 쌩신입이 대규모의 서비스 개발을 해보기란 거의 불가능하다. 나 또한 몇 번의 프로젝트를 진행하면서 소규모의 서비스를 개발해본 것이 내 경험의 전부이다. 그러나 소규모의 프로젝트라고 할지라도 분명히 그 안의 체계와 질서는 존재한다고 생각한다. 프로젝트 구조를 설계하면서 매번 드는 의문은 '지금 잘 하고 있는건가?' 였다. 디렉토리를 구분하고 서버 구조를 팀원들과 의논하면서 나름 타당성을 갖고 구조를 설계했다고 생각했고, 지금도 그 당시에 할 수 있는 최선의 선택을 했다고 생각하지만, 그렇다고 해서 그것이 올바른 설계였는지는 확신할 수는 없다.
이는 리팩토링을 진행하면서 더욱 뼈져리게 느꼈다. 서비스의 확장성이라던가 비즈니스 요구사항의 변화 등을 고려하지 않은 토이 프로젝트의 부실한 설계는 프로젝트의 규모를 키울 수록 발목을 잡았고, 실제로 팀원들과 완전히 갈아 엎고 처음부터 시작해야 하나 심각하게 고민하기도 했었다.
이러한 경험들을 하면서 뭔가 중요한 단계를 빼먹었다는 생각이 스멀스멀 들기 시작했다. 그게 뭘까 고민할수록 드는 생각은 단순히 눈앞의 구현만 후딱 해치우는 것이 아닌, 더 넓은 시야를 갖고 개발에 임하는 것 이 부족하다는 것이었다. 당장 기간 내에 해내야 하는 기능 구현에만 몰두하고, 내가 맡은 파트에만 집중하다 보니 서비스의 전체 그림을 보지 못했던 것이다.
📖 고민 2. 얼렁뚱땅 아는 것은 사실 모르는 것이다.
사실 학부 수업, 정보처리기사 취득을 위한 공부를 하면서 디자인 패턴의 종류와 이를 구분하는 기준 등을 지겹도록 듣게 된다. 그런데 막상 이를 구현해보라고 하면 말문이 턱 하고 막혔다. 자세히 설명해보라고 해도 깜지를 써가며 외웠던 사전적 정의를 암송하는 것 뿐이었다. 싱글턴 패턴을 왜 사용하는지, 상태 패턴과 전략 패턴의 차이점은 무엇인지, 데코레이터 패턴을 사용한 예시는 무엇이 있는지 등 애초에 제대로 알고 있지도 않았을 뿐더러 이를 활용하는 방법을 알 리가 없었다.
취업 준비를 하면서, 또 개발자가 되기 위해 공부를 하면서 스스로 다짐한 것은 "제대로 알고 활용하자" 였다. 슥 훑어보고 대충 코드를 작성해보다가 '어? 됐네?' 하고는 넘어가는 방식은 나의 나태함의 양분이 될 뿐임을 알고 있기 때문이다. 비록 당장 활용하기 어려운 지식임을 알고 있음에도 디자인 패턴을 공부해야겠다고 마음먹은 이유가 바로 이것이다.
🤷 고민 3. 그래서 어떻게 해야 하는 건데?
MyBatis, Spring data JPA, Querydsl 등 하나의 기술을 사용하는 데에 익숙해지기 시작하면 어김없이 "더 좋은 코드를 작성하고 싶다" 라는 욕심이 피어오른다. 이 좋은 코드를 한 문장이나 단어로 정의하긴 어렵지만, 코드 자체를 더 깔끔하게 작성하고 싶다는 것과 더 효율적이고 생산성 있는 코드를 작성하고 싶다는 의미가 가장 많이 포함되어 있었던 것 같다.
이런 갈증을 해결하기 위해 클린 코드와 같은 유명한 지침서는 물론이고 다양한 서적을 읽어보았다. 다만 이런 류의 책들은 좋은 개발자, 좋은 코드를 위한 포괄적인 조언들을 담고 있는 만큼 내가 필요했던 "그래서 어떻게 해야 하는 건데"를 100% 충족시켜주진 못했다. 아직 햇병아리에 불과한 내가 원하는 건 전반적인 나의 미래에 대한 로드맵이나, 개발에 있어 필요한 대전제가 아닌, 당장 그걸 어떻게 써먹어야 하는지에 대한 실질적인 답변이었기 떄문이다.
🚨 저 책들이 부족하다거나, 도움이 1도 되지 않는다는 그런 이야기는 아닙니다! 다만 그 당시에 제게 필요했던 것과는 포인트가 달랐던 것이었다고 생각해요. 저 때 읽었던 책들은 여전히 제게 훌륭한 지침서입니다..!
⛳️ 고민의 끝
이러한 고민들은 제게 디자인 패턴을 공부해야 할 좋은 명분이 되었다. 더 넓은 시야를 갖출 수 있고, 더 나은 코드를 디자인 하기 위한 기초 지식이라고 생각했기 때문이다. 누군가에겐 귀한 시간을 야무지게 활용하지 못하는 덜렁이로 보일 수도 있겠지만, 내겐 원하는 개발자의 모습에 한 걸음 다가가기 위해선 꼭 필요한 과정이라고도 생각한다.
🧩 디자인 패턴은 완벽한 해답이 아니다.
책에도 적혀있고, 저 또한 공부를 시작하며 매번 되뇌이는 말이다. 디자인 패턴은 말 그대로 코드와 구조를 디자인하기 위한 일종의 도구일 뿐, 이것이 설계와 문제 해결에 있어 완전한 해답은 아니다.
다만 우리가 개발을 하면서 다양한 프레임워크, 라이브러리를 적절하게 사용하듯이 디자인 패턴 또한 시기적절하게 사용하면 크게 도움이 될 것은 분명하다고 생각한다. 그리고 원하는 때에 알맞게 사용하기 위해서는 주요 디자인 패턴에 대해 잘 알고 있어야 한다!
🎲 앞으로의 방향성
책을 읽고 정리&발표하는 방식으로 공부한 만큼 전반적인 내용은 헤드퍼스트 디자인 패턴에 의존하겠지만, 그 외 더 공부했던 부분이나 개인적으로 경험한 것들, 또는 실제 발표에 사용한 자료 등을 약간씩 첨부할 예정이다.
책의 목차와 커리큘럼을 존중하지만, 기존에 디자인 패턴에 대한 선행 학습을 한 상태라는 점과 스터디 발표를 염두에 두고 있기 때문에 분량을 조절하거나 당장 도움이 될만한 부분을 먼저 학습하는 등 다양한 요인으로 인해 뒤죽박죽 순서로 학습했다. 이러한 이유로 앞으로 작성하는 글도 책의 목차가 아닌 내 발표 순서를 따를 것이다.
이미 책을 완독했고 발표 자료가 만들어져 있는 상태이기 때문에 이를 잘 다듬고 정리해서 올리게 될 것 같다. 배운 것을 다시 리마인드하고 나중에 다시 찾아볼 수 있는 자료를 만드는 좋은 기회가 될 것이라고 생각한다. 화이팅!!
