일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 애그리거트
- Pay
- MongoDB
- IDDD
- spring-web
- Redis
- armeria
- spring caching
- 신입
- MSA
- 반버논
- 값객체
- Spring
- zuul
- docker
- spring6
- mongo
- webframework
- springcloud
- springboot
- ddd
- Conference
- ifkakao
- springboot3
- 개발자
- java17
- 바운디드컨텍스트
- kakao
- Kotlin
- spring scheduler
- Today
- Total
Easy Understanding
찐 개발자로의 성장을 위한 코드 분석 시작해보기(feat. Spring Framework) 본문
계기와 결심
라이브러리나 프레임워크를 사용하는 것은 개발자에겐 일상이다.
시간이 지날수록 프레임워크들은 편리하게 발전하고 있으며,
그 때문에 우리는 비즈니스 로직을 처리하는 것에만 집중하면 된다.
책 하나 정도만 파보면 사용법을 익히는 건 어려운 일은 아니다.
그런데 그러다가 가끔 코딩하다 문제가 생겼을 때 혹시나 라이브러리를 한 번 까보면 신세계가 펼쳐진다.
도대체 내가 보고 있는 코드는 다른 차원의 코드인가 하는 생각이 든다.
그러다보니 코드에 대해서 두려움이 해소가 되지 않는다.
나는 예전부터 자기가 필요한 프로그램을 만드는 사람이 신기했다.
도대체 이 사람은 이런 프로그램을 어떻게 만들었을까라는 궁금증이었다.
- VSCode에 있는 플러그인도 직접 개발한다고 하는데 도대체 어떻게 개발했을까?
- 도대체 Spring은 어떤 괴물들이 만든걸까?
- 프레임워크도 잘 모르겠는데 이와중에 언어를 만드는 사람은 얼마나 대단할까?
도대체 얼마나 천재들이길래 나는 못하는 것들,
나는 상상조차 못하는 것들을 그들은 하는걸까라는 생각이 항상 들고는 했다.
나는 이런 상황에 대해서 너무 화가 나고, 오기가 생겼다.
물론 아는 건 쥐뿔도 없고, 머잖아 좌절했지만 그럼에도 나도 그런 커뮤니티에 참여하고 싶었다.
나도 '찐' 개발자가 되어서 바퀴를 만드는 사람이 되고 싶었다.
그래서 나도 못하란 법이 없잖아 라는 생각으로 도전을 해보기로 마음을 먹었다.
가장 처음 알아본 것은 오픈소스와 관련된 것이었다.
오픈소스 입문과 관련해서 많은 글들이 있길래 좀 읽어봤다.
(예를 들면 https://opensource.guide/ko/ 이런 곳)
누구나 할 수 있다
지금 당장 해 봐라
같은 희망적인 문구와 각종 방법론들이 있길래 일단 글은 재밌게 읽었다.
물론 딱 몇 개의 오픈 소스를 훑어 보자마자 나의 한계를 깨달아버렸다.
도대체 이게 어떻게 되어먹은 건지, 코드는 내가 아는 그 자바가 맞는지 싶을 정도였다.
이러한 절망적인 마음을 안고 가장 먼저 내가 사용하고 있는 스프링 프레임워크를 정복하겠다는 일차적인 목표를 세웠다.
문서 읽기
가장 먼저 하기로 결심한 것은 그 프로젝트의 공식 문서를 읽는 것이었다.
스프링의 공식 문서는 굉장히 긴 데다가, 실제로 사용하지 않는 내용도 많아서 잘 안 읽히는 편이다.
예전에 이 문서를 읽으려다가 쓸모가 없을 것 같다고 판단하여 조금 보다가 포기한 적이 있다.
차라리 그 시간에 유튜브에서 튜토리얼 영상을 하나 더 봐야겠다는 생각이었다.
이번에는 새로운 마음가짐으로 문서를 처음부터 꼼꼼하게 읽어보았다.
그런데,
사람이 마음 먹은 게 달라져서 그런지 보이는 게 달랐다.
분명히 이전에는 어떻게 '사용'을 할지에 초점을 두고 봐서 그런지, 쓸데 없어 보이는 내용이 많다고 느꼈었다.
하지만 이번에는 어떻게 '만들었는지'로 초점을 바꿔서 문서를 읽으니 많은 것들이 보이기 시작했다.
어떤 구조로 되어있는지, 어떤 식으로 사용하도록 의도했는지 등 새로운 것들이 보이기 시작했다.
또한 확장성, 재사용성 같은 개발 원칙 중에 중요한 것들이 다 녹아져 있음을 확인할 수 있었다.
나중에 나도 이렇게 따라서 해봐야지 했던 것들이 많았다.
그러나 글로만 표현한 문서로는 분명히 한계가 있음을 깨달았다.
도대체 이 정도로만 읽어서는 완벽한 파악은 힘들었다.
그래서 개발자로서 처음과 끝인 '코드'를 드디어 분석하게 되었다.
코드 분석
문서를 읽은 것을 토대로 어떤 코드를 분석해야 하는지를 결정했다.
프레임워크의 코드는 방대하고 정말 많은 클래스가 있기 때문에 무작정 달려들 기엔 너무 미로처럼 복잡하다.
게다가 대부분 인터페이스와 상속을 통한 객체지향적인 설계가 굉장히 잘 되어있기 때문에,
어디서 본 듯한 반가운 클래스 이름이 보여서 들어가도 인터페이스라서 비어있기 일쑤다.
그래서 문서를 읽기는 해야 한다.
어디서 본 듯한 용어라도 보여야 코드를 볼 수가 있기 때문이다.
Step 1) 구조 파악하기
가장 처음 한 것은 각 모듈/패키지 별로 어떤 기능을 하는지 파악하는 일이다.
java는 javadoc 문서화를 위해서 각 패키지에 package-info.java 파일을 두기 때문에,
이를 확인하면 설명이 써 있어서 편리하다.
이런 것들을 읽고 정리하면서, 각 파트에 대한 것들을 파악했다.
Step 2) 초기화(Bootstrap) 코드를 중심으로 보기
코드를 볼 때 클래스 하나하나를 뜯어서 보는 것은 효율적이지 않을 가능성이 크다.
라이브러리는 그럴 수도 있지만, 프레임워크는 흐름이 중요하다고 생각을 했다.
그래서 그 중에 제일 중요하다고 여겼던 초기화 코드를 중심으로 코드를 보기 시작했다.
프레임워크라면 분명히 초기화(startup, initialize 등의 용어가 포함된) 과정이 존재하기 때문에,
그 과정을 따라가다보면 이 프레임워크가 어떻게 구성되는지 거의 반 이상을 알 수 있다고 생각한다.
Spring의 경우에는 초기화 방식이 Tomcat과 엮여 있어서 다소 복잡하기 때문에 시작점을 찾는 것에 애를 먹었다.
그럴 땐 IntelliJ의 'Find Usages' 기능을 사용해서 이 클래스나 메서드가 사용된 지점을 찾기도 했다.
여러 가지로 헤맸지만, 이렇게 잃었던 길을 찾아가는 그런 과정을 통해서 코드 분석 능력이 더 늘어난 것 같다.
결국 코드 한줄 한줄을 따라가면서 나는 Spring이 ApplicationContext를 구성하는 과정을 파악했다.
정말 여기저기 왔다갔다 하기는 하지만, 그런 복잡한 과정도 최대한 중간중간 정리하면서 진행했다.
코드 분석에 제일 좋은 방법 중 하나는 Debugger를 사용하는 방법이다.
테스트 용으로 어플리케이션 시작 코드를 하나 작성해 놓은 다음,
디버거에서 'Step Into/Over' 버튼을 눌러서 한 줄 씩 따라가보니 정말로 알 수 있는 정보들이 많았다.
Method의 호출 스택도 확인할 수 있고, 필드에 대해서도 하나하나 다 알 수 있기 때문에 굉장히 유용했다.
성과
나는 이제 코드를 보기 시작한 막 발을 뗀 개발자일 뿐이다.
그렇지만 코드를 보고 나서 나의 코드에 대한 시야가 정말 넓어진 것을 느낀다.
이번 코드 분석 배운 것은 다음과 같은 것들이 있는 것 같다.
1) 객체 지향적 사고 / 능력
코드를 읽으니 객체지향이 뭔지에 대해서 제대로 알게 되는 것 같다.
읽다보니 여러 개의 인터페이스들과 추상 클래스들이 거미줄처럼 얽혀있는 구조에 대해서 조금씩 익숙해졌다.
게다가 왜 이런 구조가 필요한지에 대해서도 문서와 함께 읽다보니 이해할 수 있게 되었다는 점이 크다.
객체지향의 이점이라면 대부분은 '책임'과 '확장성' 이라는 키워드로 정리할 수가 있을 것 같다.
내가 분석한 코드들을 통해
객체지향적인 설계 덕분에 각 클래스들이 '책임'을 명확하게 가질 수 있게 되었고,
사용자 커스텀 구현체 등 여러 가지로 확장될 수 있는 '확장성'을 가지고 있음을 알 수 있었다.
2) 패턴에 대한 이해
실제 예시를 통해 각종 디자인패턴, 코딩 패턴들의 사용을 구경할 수 있었다.
특히나 Adapter, Builder, Delegation, Composition, Factory와 책에서 봤을 땐 이해가 되지 않던 것들이,
코드를 읽다보니 익숙해지게 되었다.
3) 다양한 코딩 스킬들
Naming Convention이나 변수 선언 등 각종 코딩 관련 스킬들을 보고 배울 수 있었다.
코드분석의 제일 큰 장점은 좋은 코드라는 참고서를 얻을 수 있다는 점이다.
내가 나중에 나의 코드를 작성할 때, 잘 모르겠으면 분석한 코드를 다시 꺼내 읽으면서 참고하면 된다.
코드를 분석할 수록 나의 코딩 실력이 늘어나는 것은 당연한 것 같다.
또한 코드를 한 번 읽어보니 익숙하지 않은 코드를 보는 것에도 자신감이 붙었다.
이왕 읽은 김에 다른 소스들도 살짝 건드려 보았는데 이전과 보는 안목이 달라진 것을 확실히 느꼈다.
Nest.js라는 Node.js의 프레임워크를 쭉 분석해 보았는데 생각보다 어렵지 않게 읽을 수 있었다.
언어가 다르기는 했지만, 언어는 역시나 크게 중요하지 않다는 것을 알 수 있었던 경험이었다.
Controller의 Scanning부터 IoC 컨테이너의 설정까지 어렵지 않게 파악할 수 있었다.
나의 다음 목표는 다양한 코드들을 열심히 분석하고 레벨업을 하는 것이다.
결국 오픈 소스에 참여할 수 있을 정도의 개발 수준이 되고,
실제로 좋은 코드를 개발하는 팀에 참여해보는 것이다.
이번 기회를 통해서 많은 것을 얻은 것 같아서 뿌듯하다.