개발자와 라면 조리법
라면 봉지 뒷면에 써있는 조리법을 한번 들여다보자.
(1) 물 550ml와 건더기 스프를 넣고 물을 끓인다.
(2) 분말 스프와 면을 넣은 후 4분 더 끓인다.
3번은 먹는 방법에 대한 권장사항이니 제외하면 두 단계라고 볼 수 있다. 근데 실제로 라면을 끓이는 자신의 모습을 상상해보면 이보다 훨씬 많은 단계들이 숨어있다.
(1) 냄비를 꺼낸다.
(2) 냄비에 물 550ml와 건더기 스프를 넣는다.
(3) 물과 재료가 담긴 냄비를 가열한다.
(4) 물이 끓기를 기다린다.
(5) 물이 끓기 시작하면 면과 분말 스프를 넣는다.
(6) 4분 더 끓인다.
(7) 불을 끈다.
(8) 그릇에 옮겨 담는다.
이보다 더 자세하게 서술할 수도 있다. 들여다보면 ‘냄비를 가열한다’에도 여러 단계가 생략돼있다. 심지어 장비에 따라서도 다르기 때문에 분기가 필요하다.
(1) 인덕션이라면 전원을 켜고 버튼을 눌러 온도를 높인다.
(2) 가스레인지라면 가스밸브를 열고 다이얼을 돌려 점화한다.
(3) 휴대용 버너라면 가스통을 흔들어 넣고, 잠그고, 점화한다.
하지만 그 어떤 라면 조리법에도 위 같은 내용이 포함되진 않는다. 왜냐면 이정도 상세한 내용은 독자가 이미 알고 있다고 간주하거나, 실은 라면 회사가 알 바 아니기 때문이다. 너무 당연한 말이라고 생각할 수도 있겠지만 이런 류의 코드는 꽤 흔하다. 함수 이름에 표현된 것보다 더 많은 일을 하거나 지나치게 세부적인 구현부가 드러나기도 한다. 이런 경우 보통 if문, for문이 많고 코드가 장황하다.
가령 fetchRecentArticles 라는 함수를 마주쳤다고 상상해보자. 이 함수가 수행하는 작업은 아래와 같다고 예상할 수 있다.
(1) 저장된 아티클을 적당히 불러온다.
(2) 최근 X일 내에 생성된 것들을 골라낸 후 반환한다.
그런데 막상 함수를 들여다보니 함수 안에서 로컬 캐시를 확인하고, 없으면 서버 API 호출을 해서 데이터를 가져와서 파싱하고, 저장소에서 데이터를 불러오기 위한 키 값도 정의하고, switch문으로 아티클의 종류에 따라 각기 다른 필터링 로직을 생성하고 있다면 어떨까. 막상 핵심 부분은 장황한 코드 속에 파묻히게 된다. 코드를 수정하려고 해도 어디를 건드려야할지 한참을 찾아야한다. 라면 물을 끓인다는 것만 알면 되는데 불을 어떻게 지펴야 하는지까지 설명하고 있는 셈이다.
‘왜 자석은 서로 밀어내는가?’란 기자의 질문에 리처드 파인만이 대답을 한 영상에서도 비슷한 의미를 찾을 수 있다. 같은 질문이라도 질문자가 누구냐(물리학 전공자, 일반인, 외계인 등)에 따라, 또는 질문자가 무엇을 알고 싶어하느냐에 따라 설명은 천차만별이 된다. ‘그건 그냥 그런거야’와 같이 한마디 답변이 될 수도 있고, 설명이 꼬리에 꼬리를 물고 끝도 없이 자세하게 설명할 수도 있다.
본인이 쓴 코드가 적절한 수준의 로직만 드러내고 있는지 고민해보자. 함수의 역할에 맞는 작업만 하고 있는지, 아니면 온갖 세부 로직을 장황하게 늘어놓고 있는게 아닌지 살펴보고 손봐야 한다. 그런데 ‘적절한 수준’이란 것엔 정답이 없다. 코드가 속해있는 클래스나 모듈에 따라 다르다. 코드를 읽는/쓰는 사람의 역량에 따라서도 달라질 수 있다. 누구에게는 간결한 코드가 누구에게는 더 이해하기 어려운 코드일 수 있다. 코드를 리팩토링 하다보면 또 기준이 바뀔 수도 있다. 모든게 유동적이다. 딱 떨어지는 기준은 없지만 독자의 입장에서 자신의 코드를 한번이라도 더 읽어보고, 함수를 짧게 만드는 연습을 하고, 동료끼리 코드 리뷰를 하면서 적절한 수준으로 맞춰갈 수 있다.
객체는 하나의 책임만 가져야 한다는 단일 책임 원칙을 지키는게 결코 쉽지는 않지만 함수 단위에서부터 시작해보자. 함수를 간결하게 만들수 있게 됐다면 다음으로 클래스 수준에서도 적용해본다. 단일 책임 원칙은 모든 패턴이나 아키텍처의 시작이다. 즉 단일 책임 원칙을 지키지 못하면 어떤 패턴을 쓰던, 어떤 아키텍처를 도입하던 시간이 흐를수록 결국 스파게티 코드가 될 확률이 높다. 언어 문법도 코드를 더 간결하게 표현하기 위한 수단으로써 공부를 하면 길을 잃지 않을 수 있다. 함수를 짧게 만들고 클래스를 작게 만드는 연습을 많이 하자.
같이 읽어볼만한 글
스위프트로 다시보는 객체지향 프로그래밍: 피해야할 코딩 습관