August 6, 2022 2 min to read

Python Abstract Class로 어디까지 추상화 해야할까?

섣부른 추상화?

Abstract Class로 어디까지 추상화 해야할까?

제 포스팅을 쭉 읽어오신 분은 아마 느끼셨겠지만, 저는 abstract class를 통한 설계 및 구현을 선호합니다.

python을 통한 서버 개발에 있어, 언제 어떻게 바뀔지 모르는 요구사항에 대한 유연한 처리 뿐만 아니라, 동료들과 협업 하기에도 좋다고 생각하기 때문이죠.

하지만 오늘은 조금 다른 이야기를 해볼까 합니다.

모든 클래스가 Abstract Class를 통해 구현되어야만 하는가?

abstract class를 구현함으로써 가지게 되는 장점은 명확합니다. 덕타이핑 사용에 있어 명확성을 취할 수 있고, 추후 로직 교체 및 확장에도 유용합니다.

하지만, 이 모든 장점들의 전제는 해당 클래스 또는 특정 로직에 변화가 생길 때 입니다.

만약, 앞으로 절대로 (또는 몇년 이상의 오랫동안) 바뀌지 않을 것이라고 예상되는 클래스가 있을 때, 해당 클래스에 대한 추상클래스를 꼭 작성해야만 할까요?

또는, 로직 상에서 추상클래스를 상속하는 객체가 단 하나의 객체만 존재하게 될 것 같을 때, 우리는 해당 클래스에 대한 추상클래스를 작성하는 것이 맞을까요?

프로젝트 내 모든 클래스 객체에 대해 추상클래스를 작성하게 된다면, 위와 같은 의문점을 쉽게 마주하게 됩니다.

확장하지 않을 것 같은 추상클래스를 작성하고 있다거나.. 추상클래스를 고민하다가 오히려 프로젝트 진척도가 느려진다거나.. 좋은 방법을 적용하는 것 같은데 오히려 무언가 나사가 빠진 듯 생각하지 못했던 고민거리들이 발생합니다.

모든 기술적 선택에는 trade off가 있다고 생각합니다.

확장이 예상되는 클래스들을 추상화하여 확장성을 높이는 것은 분명 좋은 방안이지만, 쉽게 확장되지 않을 것들을 미리 추상화하며 시간을 쏟고 있다면, 섣부른 추상화가 될지도 모릅니다.

주니어인 제가 생각하는 것 이상으로 더 많은 문제점과 동시에 더 많은 장점이 존재할거에요.

trade off 상황에서 더 올바른 선택을 하려면..?

예전에 개발을 하는 친구와 고기를 먹으면서 한가지 질문을 던진 적이 있었습니다.

주니어 개발자와 시니어 개발자의 가장 큰 차이가 뭘까?

그러고 작은 주니어 두명은 나름대로의 이야기를 이어나갔었죠.

몇일 뒤, 친구는 문득 그 이야기가 떠올라 자신의 사수에게 제 질문을 그대로 물어봤다고 합니다.

그리고 그 사수분은 다음과 같이 답변해주셨습니다.

이 상황에 이게 맞는지 판단하는 능력의 차이가 아닐까?

저는 그 답변을 전달받고, 무언가 굉장히 부러웠습니다.

저런 이야기를 할 수 있다는 것은, 수 많은 개발을 거쳐오며 매번 어떤 것이 더 적합할까 라는 고민과 답변을 해오셨다는 반증처럼 느껴졌습니다.

그래서 Abstract Class로 어디까지 추상화해야하는데?

답은, 저도 모릅니다. 입니다.

제목을 보고 들어오신 분들은 배신감과 실망을 느끼고 계실지도 모르겠습니다..

지금의 제가 이런저런 글들을 통해 남기고 있는 저 나름대로의 좋은 코딩 방법들도 어떤 프로젝트, 어떤 상황이냐에 따라 굉장히 비효율적이고 좋지 못한 방법일수도 있습니다.

그리고 어쩌면, 제가 남긴 것들이 애초에 바닥부터 잘못 쌓아올린 이야기들일수도 있습니다.

그렇기 때문에, 정말 만약에, 여러분이 제 글을 읽고 저와 같은 스타일을 시도해보시고자 한다면, 제가 이야기한 것들에 대해 한번쯤 의문을 가지고 반문을 해보셨으면 좋겠습니다.

물론, 그 내용을 공유해주시면 더더더더욱 좋습니다 :>

아, 한가지 팁이라면 제가 그저 작고 작은 행복한 세상의 주니어라는 점을 항상 잊지 않으셔야 합니다.

모든 의견에는 확증편향이 존재할 수도 있는데, 저처럼 작은 경험을 지닌 주니어들은 누구보다 쉽게 이 확증편향에 갇힐 수 있으니까요.

이제 슬슬 글을 마칠 때가 된 것 같습니다.

오늘은 인사하는 제리 말고, 오늘 글에 어울리는 좀 색다른 인사짤로 마무리하려고 합니다.

다들 행복하세요 :>

스스로 한 선택도 끊임없이 의심하고 반론하라