서론
최근 제 코드를 어떻게 하면 더 나은 방향으로 개선할 수 있을지 많은 고민을 하고 있습니다.
매 순간 마주하는 코드의 맥락과 작업 환경, 그리고 제가 처한 상황이 계속 변화하다 보니 명확한 해답을 찾기가 쉽지 않더라고요. 이런 고민들을 정리하면서 함께 나누고 싶어 이 글을 쓰게 되었습니다.
특히 요즘은 객체지향적인 설계와 역할 분리에 대해 깊이 생각해보고 있는데요. 실제 업무에서 작성한 코드로 예시를 들면 좋겠지만, 회사 코드라는 특성상 공개하기 어려운 점이 아쉽네요.
그래서 이번 글은 다소 추상적인 경험 공유가 될 것 같습니다만, 함께 이야기를 나누면서 서로의 생각을 공유할 수 있었으면 좋겠어요.
고민하게 된 계기
역할 분리와 객체지향에 대해 고민하게 된 계기는 반복되는 보일러플레이트 코드였습니다.
개발을 하다 보니 비슷한 작업을 여기저기에 반복하고 있는 제 자신을 발견했고, 이런 제 모습이 꽤나 불편하게 느껴졌습니다.
그럼에도 마음 편히 개선할 수 없었던 이유는 각각의 비대한 ViewController 가 실제로는 꽤 다른 모습을 하고 있었기 때문입니다. 심지어 일부는 Swift, Objective-C로 언어가 다른 경우도 있었고요... :(
이런 상황에서 불편함을 느끼면서도 개선이 쉽지 않았던 근본적인 이유가 바로 "역할 분리"가 제대로 이루어지지 않았기 때문이라는 걸 깨달았습니다. 만약 역할이 잘 분리되어 있었다면, 코드 개선이 훨씬 수월했을 텐데 하는 아쉬움이 들었어요.
그래서 이번 기회에 큰 틀에서라도 역할을 나눠보기로 했습니다. 이를 통해 반복되는 작업도 줄이고, 비대해진 ViewController도 가볍게 만들 수 있겠다고 생각했습니다. 게다가 Objective-C 코드의 자연스러운 Swift 전환이라는 보너스 효과도 얻을 수 있었습니다 😊
주관적인 역할 분리 기준
역할 분리는 참 주관적입니다.
역할을 나누는 기준과 구현, 수행 위치에 대해 명확한 정답이 없기 때문입니다.
(네이버 부스트캠프에서도 했던 고민인데... 몇 년이 지난 지금도 같은 고민을 하게 되니 씁쓸하면서도 재미있네요. 달라진 게 있다면 프로젝트의 크기와 여러 개발자의 손을 거친 코드라는 거...?)
이번 작업의 목표는 명확했습니다. '반복되는 작업 범위 줄이기.' 이를 기준으로 역할을 구분해 보기로 했어요. 똑같은 작업이 발생한다는 건 역할이 동일하거나 포함 관계에 있다는 의미니까요. 일부 다른 부분은 프로토콜로 추상화하거나 상속으로 해결할 수 있어서, 현 상황에서는 꽤 합리적인 기준이라고 판단했습니다.
특히 주의했던 점은 '과도한 추상화'입니다. 이번 목표는 큰 틀에서의 역할 분리였거든요. 지나친 추상화와 세분화된 역할 분리는 오히려 유지보수를 어렵게 만들 수 있어서, 현재 목적에 맞는 적절한 크기로 객체를 분리하고 구현하는 데 집중했습니다.
자연스러운 객체지향
역할 분리를 고민하다 보니 자연스럽게 객체지향적 사고가 따라왔습니다.
(POP와 OOP는 추상적 레벨에서 보면 근본적 목적이 크게 다르지 않죠.)
아무튼 역할을 잘 분리하려다 보니 SOLID 원칙이 자연스럽게 떠올랐는데요.
SOLID 스럽게 짰느냐라고 묻는다면 아주 약간 그런 거 같아요.
멀리서 보아야 이쁜 것처럼 제 코드도 멀리서 보면 제법 SOLID 스러운 코드가 된 것 같습니다.
1. 다른 클래스가 분리한 객체를 찾는 이유가 하나이고(단일 책임 원칙),
2. 여러 역할을 하는 인터페이스가 없고 (인터페이스 분리 원칙),
3. 외부로부터 의존하는 객체를 주입받고(의존 역전 원칙)
등... 다만 역할이 추상적이고, 인터페이스가 몇 개 없고, 주입받는 객체가 SOLID 스럽지 않다는 문제가 있었지만 흐름 자체는 잘 튼 거 같아요 😅
제가 늘 강조하는 건 객체지향의 자연스러움입니다.
개발자라면 누구나 반복과 비효율을 싫어하잖아요.
이런 불편함을 해소하다 보면 자연스레 역할 분리가 이뤄지고, 객체지향적인 코드가 만들어지는 것 같아요.
그럼에도 저는 처음부터 구조를 고민하는 걸 좋아합니다.
구조를 고민하면서 미래를 예측하고... 그럼 기획과 디자인에 궁금한 게 생기고... 기획자와 디자이너에게 많은 질문을 던지면서 구조를 구체화합니다.
때론 귀찮게 해 드리는 것 같아 죄송하지만,
나중에 "구조가 달라서 수정이 어렵다"는 말을 하는 것보다는 낫다고 생각하면서 소통하고 있습니다 ㅎㅎ;
역할 분리 결과
아직 열심히 진행 중이긴 합니다만 역할 분리를 하면서 구조화는 역시 중요하다는 걸 느꼈습니다.
구조화를 잘하면 미래의 작업이 월등히 편합니다. 심리적 부담감도 적습니다. 불쾌함도 적습니다. 일석삼조입니다.
근데 안 할 이유가 없냐고 묻는다면 그건 조심스럽습니다.
당장 내일 배포해야 하는 아이템이 들어오면 구조가 문제입니까. 어떻게든 빠르게 동작하게 만들어야 하죠.
저는 이런 경우가 적지 않았고...
이런 경우가 모이고 모여 레거시가 되는 거겠죠.
이런 자연스러운 레거시를 이해하고 나니 코드 개선에 대한 시각도 달라졌습니다.
과거 개발자도 어쩔 수 없었구나, 지금의 내가 잘 개선하면 되지!라는 마음으로 점진적으로 개선해야겠다고 생각했습니다.
그럼에도 다른 사람이 쉽게 유지보수할 수 있도록 지나친 추상화는 자제하고,
기획자/디자이너와 개념을 맞춰가며 함께 나아가는 개발이 중요하다는 걸 깨달았습니다.
네이버파이낸셜 인턴 시절 멘토님의 조언을 실제로 체감하는 순간이네요. 😊
마무리
역할 분리는 단순히 코드를 나누는 것이 아닌 비즈니스 로직을 더 명확하게 이해하고 표현하는 과정이었습니다.
이 과정에서 자연스럽게 따라온 객체지향적 설계는 우리가 흔히 생각하는 것처럼 어렵거나 복잡한 게 아닌 개발자의 자연스러운 고민의 결과물이었습니다.
잘 설계된 구조가 미래의 작업을 얼마나 편하게 만드는지, 그리고 이를 위해 기획자, 디자이너와의 소통이 얼마나 중요한지 다시 한번 체감했습니다. 특히 SOLID 원칙을 염두에 두면서도 지나친 추상화를 경계하며 실용적인 접근을 하려 노력했어요.
동시에 레거시 코드에 대한 시각도 변화했어요. 각각의 코드는 당시의 상황과 제약 속에서 최선의 선택이었다는 걸 이해하게 되었고, 이는 제가 코드를 개선하는 방식에도 영향을 미쳤습니다.
앞으로도 '큰 그림'을 놓치지 않으면서 점진적인 개선을 이어나가려 합니다.
역할과 책임이 명확한 객체들이 자연스럽게 협력하는 구조를 만들되, 과도한 추상화는 피하고
팀원들과의 원활한 소통을 통해 모두가 이해하고 수정할 수 있는 코드를 구현하는 개발자...
제가 그렇게 될 수 있겠죠...?
파이팅 해야겠습니다.
감사합니다.
아직은 초보 개발자입니다.
더 효율적인 코드 훈수 환영합니다!
공감과 댓글 부탁드립니다.
