아홉 번째 수업 이모저모

  • 수업은 2017-05-08 19:01:00 +0900에 시작.
  • 사내 교육장이 완성되어, 이제부터는 소마 미술관에 가지 않아도 된다.
    • 다만 교육장 내부 시설은 아직 정비가 필요한 듯하다. 간이 책상과 의자를 사용했고, 교육장 앞쪽에 컴퓨터를 둘 수 없어, 박재성 교수님이 앞뒤로 이동하며 강의하셔야 했음.
  • 오늘은 MVC 프레임워크 실습 피드백을 하고, Spring 실습을 한다.
  • QnA가 다른 시간보다 활발한 편이었다. 리팩토링에 대한 이야기가 주를 이루었음.

단상: 삶과 프로그래밍

  • 권위: 동의할 수 없는 권위에 굴복하지 말 것.

메모: Spring Annotation

스프링엔 어노테이션이 도입되지 않았던 시절도 있었다. 어노테이션 없이도 훌륭한 스프링 애플리케이션을 만드는 것은 가능할 것이다. 그러나 스프링 어노테이션의 존재를 알면서도 사용하지 않는 사람은 매우 드물 거라고 생각한다.

내 관점에서 현재의 스프링은 거대한 리플렉션 라이브러리다. 스프링은 리플렉션을 사용한 어노테이션 기능을 잔뜩 구현해 놓음으로써, 사용자가 리플렉션의 필요를 느끼지 못하게 만들었다.

나는 리플렉션이 Java답지 않은 기능이라고 생각한다. Java의 중요한 특징인 강한 타입과 IDE 지원을 무시하는 코드가 생산되기 때문이다. 게다가 결과물은 Exception이 잔뜩 붙어 있어 참기 어려운 고약한 냄새가 난다. 하지만 Java의 문법만으로는 몇몇 작업을 수행할 때 한계가 있으니 울며 겨자 먹기로 사용할 수 밖에 없다.

하지만 스프링이 있다면 사용자의 코드에서는 리플렉션이 사라지게 된다. 스프링 어노테이션은 환상적인 기능이다. 클래스와 메서드에 어노테이션 스탬프만 쾅쾅 찍어 놓으면 프레임워크가 알아서 리플렉션으로 처리해준다. 이는 내가 좋아하는 스티브 맥코넬의 '최종 목표'와도 걸맞는 일이다.

최종 목표는 한번에 생각해야 하는 프로그램의 양을 최소화하는 것이다.

스프링은 Java 프레임워크의 정점이라는 생각까지 들고 있다. 그러나 이것이 과연 바람직한 일일까? 로드 존슨이 어노테이션 도입을 반대했다는 이야기를 얼핏 들은 것 같은데, 아마도 스프링 어노테이션으로 인한 커플링을 걱정했던 모양이다.

루비 온 레일즈에 대한 비판을 찾아보는 것도 좋을 것 같다.

메모: Refactoring, FP, OOP

OOP Language에서 Functional Language로 넘어가는 작업을 해 본 적이 있었다. Java에서 Scala로. 전체적인 구조는 OOP 형식으로 잡고 메서드 단위에서는 FP 방식으로 코딩하는 쪽으로 작업을 했는데 썩 만족스러웠다.

그러나 돌이켜 생각해보니 아쉬운 마음이 든다.

전체적인 구조를 OOP로 잡고, 메서드 단위에서 FP의 이념을 구현한 것은… 현실적인 대안이긴 했지만 FP라 부르기에는 많이 부족했다고 생각한다. 패러다임이 바뀌지 않았기 때문이다. 결과물은 여전히 객체들 사이의 상호작용이었다.

Java에서는 함수를 동적으로 생성해 리턴하거나, 일반 동사처럼 작동하는 여러 개의 기본 함수를 합성해 한 번만 사용하거나 하는 일들이 어렵거나 때로는 불가능하다. OOP 하 FP 스타일의 메서드 구현이란 궁여지책은, 함수가 스스로 존재할 수 없으며 클래스에 내재되어야 하는 구조이기 때문에 그렇게 작업할 수 밖에 없는 Java의 문법, Java의 OOP 패러다임에 지나치게 익숙했기 때문에 비롯된 것이었다고 생각한다.

물론 나는 그 경험이 나쁜 경험이었다고는 생각하지 않는다. 좋은 경험에 가깝다. FP 언어로 넘어갔음에도 불구하고 안타깝게도 패러다임이 전환에 실패한 경험일 뿐이다. OOP 코드는 FP 메서드를 뿌려줘도 계속 OOP 코드일 수 밖에 없다는 교훈을 얻었다.

Spring MVC 실습

강의는 Spring 아키텍처에 대한 내용이 주를 이루었다.

내 구현 내용은 GitHub에 올려두었다.

Links