한국 스프링 사용자 모임(KSUG)의 페이스북 그룹에서 스프링으로 웹 애플리케이션을 개발하면서 서비스에 인터페이스를 사용해야 하느냐는 토론이 있었습니다.
원래 그 글의 댓글로 작성한 글인데 무슨 일인지 댓글이 등록되지 않아서 이렇게 블로그에 올립니다.
모든 프로그래밍 원칙과 장치는 ‘적절히 써야 한다’는 대전제 아래에서 논의돼야 한다는 점을 먼저 밝히고 제 생각을 말하고 싶습니다. 프로그래밍 원칙을 위반한다고 지구가 무너지거나 감옥에 갇히지는 않죠. 누가 죽지도 않고요. 그렇다고 해도 어떤 원칙을 위반했을 때에는 원칙의 중요도 만큼 원칙을 무시한 결정이 적절했음을 설득하거나 그로 인해 생기는 문제를 해결할 책임을 위반하기로 결정한 사람(또는 조직)이 수용하고 감당하면 됩니다.
KSUG에서 논의된 내용을 요약하면
- 인터페이스 없어도 AOP 잘 됨
- 인터페이스 하나에 서비스 하나 뿐임
- 인터페이스 때문에 가독성이 떨어짐
- 테스트를 하면 인터페이스 구현체를 하나 더 만들게 됨
- 테스트도 요즘 목 프레임워크 기술이 좋아서 인터페이스가 꼭 필요하지 않음
- 프로젝트 규모와 중요도에 따라 다를 듯
- 인터페이스를 나중에 추출하는 방법도 있음
저도 인터페이스가 비용인 건 인정합니다. 모든 코드는 비용이죠. 다만, 그 비용을 들인 만큼 얻는 가치가 있다면 투자하면 되고 없다면 투자해서는 안 될 것입니다. 프로그래밍에서 간접화와 추상화와 관련된 코드를 비용으로 따진다면 간접비(overheads)에 해당할 것입니다. 따라서 과도한 간접화나 추상화는 피하도록 노력해야 합니다. 그렇지만 단순히 간접화나 추상화와 관련된 투자가 비용이라서 쓰면 안 된다는 식의 논리는 빈약입니다. 투자회수율(RoI)을 생각해야지 총비용만 무조건 줄이겠다는 생각은 현명하지 않습니다.
같은 맥락에서 @김지헌님이 링크 거신 동영상 강좌(?)에서 문제 삼은 “모든 클래스에는 인터페이스를 만든다”는 과격하고 경직된 정책은 저도 반대입니다. 그러나 저 화자께서 한 쪽의 극단적인 상황을 예로 들면서 그 반발로 또 다른 극단으로 치우치시는 것 같아서 저 강좌의 주장을 그대로 인정하지 못하겠습니다. 저 강좌를 얼마 전에 보고 따로 글을 쓰고 싶었는데 시간이 될지는 모르겠습니다.
OOP의 핵심, 메시징
살짝 한 발 물러서서 객체 지향 프로그래밍(OOP)이 뭔지 생각해 보는 게 좋을 것 같습니다. 최초의 OOP 언어라고 불리우는 두 언어가 있(었)습니다. 하나는 67년도에 나온 시뮬라 67이고 또 하나는 80년도에 나온 스몰토크-80입니다. 우리나라의 많은 사람들이 (아마도 마이크로소프트 덕에) C++를 통해서 OOP를 접했는데, C++는 시뮬라 67에서 OOP의 특성을 물려 받은 언어입니다. 우리가 OOP를 생각하면 흔히 떠오르는 객체, 클래스, 상속 같은 언어적 장치는 모두 시뮬라 67에서 소개되었습니다. 시뮬라 67에서는 프로그램을 작은 여러 독립 프로그램(객체)으로 나누고 이 작은 독립 프로그램들이 병렬적으로 서로 협력하며 동작하도록 하는 프로그래밍 모델을 도입했습니다.