라이브러리와 프레임워크와 Spring

발단

2017년 말, 한 주에 하나의 포스팅은 올려보자 라고 생각했던 때가 있었고, 그 직후 나는 놀랍게도 쓰레기가 되었다. 책은 계속 사고 있는데 그다지 열성적으로 읽지는 않고, 정리도 안 하고, 공부는 대충 하는데 대충 하니까 대충 기억이 안 나더라. 그러다 일도 많아지고 하면서…(중략) 그렇게 블로그 포스팅은 정지 상태.

그렇게 언젠간 쓰레기 상태를 탈출할 것이다 생각만 하던 차에, 친구가 물었다.

라이브러리랑 프레임워크는 뭔 차이냐

거 Spring 공부하는데 코드 이전에 나오는 개념이 왜 이렇게 많어

그러게요, 저도 잘 모르겠습니다 설명이 안 되네요. (이 사람은 Java + Spring을 사용해서 먹고 산다) 하지만 모르는 것을 그대로 모르게 두는 것도 성미에 안 맞고, 쓰레기를 탈출할 꽤 괜찮은 소재라 생각해 대충 정리해보기로 했다.

라이브러리와 프레임워크

라이브러리

라이브러리는 연관된 기능들을 가지고 있다. 우리는 그 기능들을 모아서 대충 더 괜찮은 코드를 만들 수 있다. 좀 수동적이고, 우리가 만든 main() 에서 돌아가는 친구들이다.

// 늘 큰 도움을 주는 StringUtils 선생님
// 아파치는 사랑입니다.
import org.apache.commons.lang3.StringUtils
StringUtils.isEmpty(null);
# requests 라이브러리가 없었다면 많은 이들이 고통받았을 것이다.
import requests
r = requests.get('https://api.github.com/user', auth=('user', 'pass'))

프레임워크

프레임워크는 일종의, 규격에 가깝다. 우리는 여러 규격 중 마음에 드는 것을 하나 선택해서, 규격에 맞춰 코드를 짜넣는다.

프레임워크를 선택하면 우리가 할 일이 많이 줄어든다. 이 친구들은 개발자에게 다양한 유틸과 기능을 제공한다. 한편으론 뒷단에서 입/출력을 가공 해주기도 하고, 코드 생성/수행 에 관여할 수도 있고, 애플리케이션의 실행 흐름 도 바꿔준다. 어, 이러면 개발자는 무엇을 하지요?

우리는 Spring Bean 만들어서 Spring 님께 바치는 노예 아니냐. - 어떤 Spring 개발자.

라고 합니다. 그렇다면 이쯤에서 떠오르는 고사 하나.

고제가 장자방을 쓴 것이 아니라 장자방이 고제를 쓴 것이다. - 정도전

프레임워크의 철학

헌법과 프레임워크

뜬금없이 헌법이 나왔다. 나는 법알못이고, 딱히 헌법에 대해서도 잘 아는 것은 아니다. 얼마 전에 표지가 괜찮아서 산 헌법 해설 책이 하나 있긴 한데, 우선순위가 밀려서 아직도 한 번 펴보질 않은 상태이다. 생각해보니 내용은 한 번도 안 읽고 샀네.

여하간, 헌법 1조는 이런 나라도 알 정도로 꽤 유명하다, 여기서 따온 영화나 민중가요도 있지 않은가. 글도 간결하고 임팩트가 있어, 빛이 있으라 수준으로 머리에 쏙쏙 들어온다.

헌법은 국가와 법의 뼈대와 방향을 설정하는 큰 틀의 역할을 한다. 대한민국의 헌법 1조는 국가의 형태, 동작 방향을 명시했고, 이후로도 국민의 범위, 국가의 의무등이 이어진다. 프레임워크에도 헌법과 같은 역할을 하는 것이 있다, 프레임워크의 철학이다. 프레임워크의 제작자/조직은 프레임워크에 특정한 철학을 불어넣는다. 다양한 철학이 프레임워크를 이루는 코드를 규정하고, 사용자에게는 ‘이 프레임워크는 이런 원리로 동작하고, 이렇게 사용하는 것입니다.’ 라고 말해준다.

Spring을 시작하는 히치하이커를 위한(후략)

이거 왜 시작부터 용어가 많이 나오냐…?

Spring을 처음 공부한 친구들이 다양한 Spring 입문서를 보고 하는 말이 이랬고, 나도 처음엔 대충 이런 생각을 했다. 코드를 보고 빨리 써먹고 싶은데! DI는 뭐고! IoC는 뭐고! AOP는 무어란 말인가!

풋내기들의 외침에는 아랑곳없이, Spring은 다음과 같이 전한다.

유구한 역사와 전통에 빛나는 우리 Spring Framework는 JVM 플랫폼으로 건립된 Java 엔터프라이즈 규격과 Java EE의 복잡성에 항거한 이념을 계승하고…(후략)

(중략)

①Spring의 Bean이 되는 요건은 Configuration으로 정한다.

②Spring은 Spring Bean의 명세가 정하는 바에 의하여 의존성을 주입할 의무를 진다.

(후략)

책을 좀 읽고, Spring 프로젝트들을 몇 번 진행해보면 위 암호문이 대충 아래 의미라는 것을 깨달을 수 있다.

헌법 조문을 명심하고 Spring을 사용하면, Spring이 꽤나 일관적인 기준으로 애플리케이션을 운영함을 다시 한 번 깨달을 수 있다. 어쩌면 구글링으로 발굴한 코드를 복붙하며 생긴 의문들 중 몇개의 답을 찾을 수도 있을 것이다. @Service 애노테이션이나 <bean> 설정을 왜 작성하는가? @Value@Autowired 는 어디로부터 오는가? @Async 는 왜 되었다 안 되었다 하지? 왜 인터페이스를 작성하는 것을 권장하는가? Spring은 딱히 하는게 없어 보이는데 설정은 왜 이렇게 많이 필요하지? 그 외 등등. 이 다음에 다시 책을 읽으면 이해가 잘 된다.

그래서 프레임워크를 공부할 때에는

새로운 언어도 마찬가지이지만, 새로운 프레임워크를 공부하고자 책을 읽을 때에는 책의 서문부터 주의깊게 읽으면 도움이 될 지도 모른다. 서문의 XX한 프레임워크인 AA는~ 이라거나, 내가 BB를 선택한 것은 YY 때문이다, CC는 특히 ZZ 패턴을 중시하는데 같은 문장은 희미한 예감이 될 것이다.

…최소한 나는 그렇게 생각하고 있다. 그렇다고 책을 사서 서문만 읽고 책장에 봉인하는건 고쳐야 할 점이긴 한데…

<문서의 끝="">