들어가며
코드를 작성하다 보면 “왜 이 코드는 한눈에 이해가 안 될까?” 하는 고민을 종종 하게 됩니다.
그래서 많은 개발 서적과 강의에서 공통적으로 강조하는 것이 가독성, 즉 읽기 좋은 코드입니다.
제가 수강 중인 “Readable Code: 읽기 좋은 코드를 작성하는 사고법” 강의에서는, 읽기 좋은 코드를 만드는 여러 방법 중 하나로 “추상과 구체” 개념을 다룹니다.
이를 제대로 이해하면, 복잡한 로직을 단순화하고 코드의 의도를 더욱 분명하게 드러낼 수 있습니다.
오늘은 이 “추상과 구체” 개념을 제가 이해한 대로 정리하고, 개인적으로 느낀 점 그리고 함께 진행중인
‘인프런 워밍업 클럽 스터디 3기’ 미션까지 공유해 보겠습니다.
추상과 구체
추상과 구체란?
개발 과정에서 종종 “상세한 구현을 전부 써줘야 하나?” 라고 고민하게 됩니다.
- 예를 들어, “버튼을 누르면 서버와 통신해서 데이터를 가져온다.” 라고만 표현해도 되는 경우가 있는가 하면, 어떤 상황에서는 “버튼 클릭 시 비동기 요청을 보내고, JSON으로 응답을 수신한 뒤 파싱해서 화면에 표시한다.” 같은 구체적 프로세스가 필요한 경우도 있습니다.
이를 추상과 구체 관점에서 바라보면,
- 구체는 실제 동작이나 물리적·기술적 세부 사항을 그대로 드러내는 것,
- 추상은 “왜 이 로직이 필요하고, 어떤 의미가 있는지”에 방점을 두면서, 세부 구현을 한 단계 감춰주는 개념이라고 볼 수 있습니다.
코드에서의 적용: 이름 짓기와 메서드 분리
코드를 짤 때 “추상”과 “구체”를 적절히 섞어 쓰려면, 기본적으로 이름 짓기(Naming)와 메서드 분리가 중요하다고 느꼈습니다.
- 이름 짓기(Naming)
- 길고 복잡한 로직을 한 메서드 안에 다 집어넣기보다, “이 로직이 무슨 일을 하는지”를 보여주는 이름을 붙이면, 코드를 읽는 사람이 세부 구현을 다 열어보지 않아도 그 의도를 빠르게 파악할 수 있습니다.
- 메서드 분리(Method Extraction)
- 한 메서드가 여러 가지 일을 하고 있다면, 추상화 레벨을 구분하기 어렵습니다.
- 따라서 주제(목적)가 다른 부분은 잘게 나누어, “이 메서드는 어떤 역할을 한다”를 분명히 해 주면, 협업하거나 유지보수할 때 훨씬 편리해집니다.
미션 과제: “추상과 구체” 예시
제시된 미션은 다음과 같습니다.
"추상과 구체" 강의를 듣고, 생각나는 예시를 적어보세요.아래는 제가 직접 생각해본 두 가지 예시입니다.
예시 1) 회사에 출근하기
- 추상 표현: 매일 아침 지하철을 타고 회사에 출근했다.
- 구체 표현:
- 아침 7시에 집을 나서 10분 정도 걸어가 지하철역에 도착한다.
- 교통카드를 태그해 개찰구를 통과하고, 에스컬레이터를 타고 승강장으로 내려간다.
- 2호선을 타고 10정거장 이동한 뒤 하차하고, 다시 환승통로를 거쳐 5호선으로 갈아탄다.
- 회사가 있는 역에 도착해 출구로 나가, 5분 정도 걸어가 사무실 건물에 들어간다.
비교
- “지하철 타고 출근”이라는 한 문장으로도 전체 과정을 추상화해 표현 가능하지만, 실제로는 역까지 걷기, 개찰구 통과, 노선 환승, 역에서 다시 걷기 등 구체적인 단계를 거칩니다.
예시 2) 배달 음식을 시켜먹었다
- 추상 표현: 출출해서 치킨을 배달시켜 먹었다.
- 구체 표현:
- 배달 앱을 열고, 주소를 확인한 뒤 치킨 프랜차이즈 메뉴를 선택한다.
- 후라이드 치킨 1마리를 장바구니에 담고, 카드 결제를 진행한다.
- 점주는 튀김 기계 온도를 맞춰 치킨을 약 10분간 튀긴 후, 기름을 빼고 포장한다.
- 배달 기사가 오토바이를 이용해 매장→고객 주소까지 이동하고, 문 앞에 놓고 벨을 누른다.
- 내가 문을 열어 음식 픽업 후, 집 안으로 들어와 포장을 열고 바로 먹는다.
비교
- “치킨을 시켜 먹었다”라는 말은 핵심 요점을 아주 간단히 담은 추상이지만, 실제 과정을 살펴보면 배달 앱 주문 → 결제 → 조리 → 배달 등 여러 단계가 있습니다.
느낀 점
이번에 “추상과 구체”를 고민하다 보니, 코드 전체가 일종의 추상화 계층 구조로 되어 있다는 사실을 다시금 깨달았습니다.
- 협업 시
- 상대방이 어느 정도 레벨의 정보를 원하는지 먼저 파악해야, 너무 복잡한 구체 사항을 늘어놓아서 혼동을 주지 않을 수 있습니다. 반대로, 너무 추상적인 얘기만 해서 “정작 필요한 디테일이 빠져있다”는 식의 문제를 일으키지 않도록 주의해야 합니다.
- 설계 시
- 클래스나 메서드를 만들 때, “이 부분은 외부에 보여줄 추상화 레벨, 저 부분은 내부 구현 디테일”로 적당히 나누는 연습이 필요하다는 걸 느꼈습니다.
- 메서드나 변수가 지나치게 구체적인 정보를 노출하면, 읽는 사람 입장에서 오히려 피로감이 커집니다. 반면, 추상화가 너무 높아 실제 내부가 도대체 어떻게 돌아가는지 알 수 없으면 또 답답합니다.
- 결국 적절한 선을 찾기 위해 계속 코드 리팩토링과 리뷰를 반복해야겠다 라는 생각이 들었습니다.
- 개인적으로
- 이 주제를 공부하면서, 코딩뿐 아니라 문서 작성이나 회의할 때도 “어느 수준까지 말할지”를 신경 쓰게 되었습니다.
- 예컨대, 특정 이슈를 공유할 때 팀원에게는 “원인과 해결책의 핵심”만 설명하는 게 좋고, 실제 세부 로그나 에러 스택 트레이스 등은 궁금해하는 사람에게만 추가로 보여주는 식으로 나누는 편이 효율적이라는 걸 깨달았습니다.
추상과 구체는 단순히 용어가 아니라, 코드를 설계하고 읽는 방식 전반에 걸쳐 중요한 개념이었습니다.
- 너무 구체적이면 처음부터 모든 정보를 다 알 필요가 없는 독자에게는 오히려 혼란을 줄 수 있고,
- 너무 추상적이면 구체적으로 무슨 일을 하는지 감이 안 잡혀 결국 로직 이해에 어려움을 겪을 수 있습니다.
어떻게 보면, 이 적정선을 찾는 것이 개발자로서 계속 고민하고, 연습해야 할 과제인 것 같습니다.
앞으로도 코드를 짤 때마다 “이 부분은 추상화해야 하나, 아니면 더 구체적으로 드러내야 하나”를 의식해 보며, 가독성이 좋으면서도 유지보수하기 편한 코드를 작성해나가고 싶습니다.
마치며
이번에 “추상과 구체” 개념을 다시금 고민해 보며, 아래와 같은 점들을 앞으로 코드에 적용해 보려고 합니다.
- 메서드/클래스가 한 가지 책임만 수행하는지 늘 점검하기
- 여러 기능이 섞여 있으면, “추상”과 “구체”가 뒤죽박죽 얽히기 쉽기 때문입니다.
- 이름 짓기에 더 신중하기
- 변수가 무엇을 의미하는지, 메서드가 어떤 의도를 갖는지 명확하게 드러나는 이름 사용하기
- 필요하다면 도메인 용어를 사전에 정리하여 팀원들과 공유하기
강의가 진행될수록 코드를 읽는다는 것이 얼마나 중요한 습관인지를 새삼 깨닫습니다.
“추상과 구체” 개념은 사실 일상생활이나 커뮤니케이션 전반에도 적용되는 아이디어이니, 앞으로도 계속 연습하고 팀원들과 공유하려 합니다.
이상으로 Readable Code: 읽기 좋은 코드를 작성하는 사고법 “추상과 구체” 강의 수강 후 정리한 블로그 포스팅을 마치겠습니다. 감사합니다.
