이 글에서는 우아한테크코스 1주차 미션을 수행하며 얻은 생각들을 기록하려 한다. 나중에 성장한 후, 지금의 나를 되돌아보는 데 도움이 될 수 있도록, 현재의 생각을 솔직하게 적어볼 예정이다.
1. 미션
먼저 미션은 문자열 덧셈 계산기였다. 구현한 코드는 아래에서 확인할 수 있다.
기능 요구 사항은 굉장히 간단했다. 미션에 대한 설명은 다른 게시글에서도 참고할 수 있으니 생략하고, 회고를 작성하는 데 집중하겠다.
2. 회고
2-1. 프로그램 구현 후
처음 과제를 접했을 때 대부분의 요구 사항은 이해했지만, '기능 단위의 커밋'이라는 개념이 명확하지 않아 이틀 정도 고민했다. 평소에는 구현과 기획을 동시에 진행하는 편이었는데, 이번 과제는 미리 기능을 세부적으로 정의하고 그에 맞춰 작업을 진행해야 했다. 이렇게 구현할 기능을 목록화하고, 우선순위에 따라 체계적으로 접근하는 방식이 나에게는 새로운 도전이었다. 과제의 지침에 맞춰 기획 단계에서 충분한 시간을 들여 정리한 덕분에, 후속 작업이 훨씬 수월해졌다. 이 과정에서 실무적인 사고방식과 접근 방식을 배울 수 있었고, 앞으로 이러한 기획 능력을 더욱 키워야겠다고 다짐하게 됐다.
아래는 프로그램을 설계하며 그린 구조도이다.
구조도에서 볼 수 있듯이, 이번 과제에서는 유연하고 확장 가능한 구조를 설계하는 데 중점을 뒀다. 단순히 숫자를 더하는 계산기처럼 단일 기능만을 고려하는 것이 아니라, 예를 들어 '가 + 나 = 가나'와 같이 문자와 숫자를 혼합하는 다양한 방식의 입력도 처리할 수 있도록 고민했다.
나는 경험이 부족하다고 느껴질 때마다 현실에서 이미 존재하는 시스템들을 참고하며 설계 방향을 잡으려고 한다. 실제 계산기를 떠올리면서 외부와 내부를 명확히 분리했고, 외부 기계는 언제든 변할 가능성을 염두에 두어 view로 구성했다. 이 view는 큰 책임을 지지 않고, 단지 사용자와의 인터페이스 역할을 담당하게 했다. 반면, 내부는 CPU와 같은 역할을 하도록 model로 구성해 변화가 어려운 핵심 로직에 집중했고, 데이터베이스의 아키텍처 구조를 생각하면서 책임을 분산시켜 유지보수가 용이하도록 설계했다. 외부와 내부 기능을 연결하고 조립하는 역할은 controller가 맡도록 했는데, 세부적인 기능을 몰라도 조립만 할 수 있도록 인터페이스에 의존하도록 구성하였다. 구체적인 기능들은 외부에서 주입하는 사장과 같은 존재인 내가 main 메서드에서 기능들을 선택해 주입하도록 구성했다. 현실에서 사장이 시켜서 비즈니스적인 변화가 일어나 기계를 분해하고, 조립한 후 다시 가동시키는 것처럼, 기능의 변경도 이와 같은 방식으로 생각했다.
솔직히, 이번 과제에서 필요 이상으로 유연하게 설계하려고 했던 것 같다. 과제 요구 사항을 넘어서 잠재적인 상황들까지 대비하다 보니, 때로는 지나치게 많은 것을 고려하게 됐다. 이러한 설계는 코드 리뷰를 통해 다양한 피드백을 받고 싶다는 간절한 기대에서 비롯된 것 같다. 평소에는 객체지향적 코드 리뷰를 받을 기회가 많지 않아서, 내 접근 방식이 어떻게 평가될지 너무 궁금했고 더 많은 피드백을 받고 싶었다. 이번 기회에 배우고자 하는 열망이 강했기 때문에, 기대감 속에서 힘 조절이 조금 부족했다고 생각한다.
2-2. 다른 사람의 코드를 본 후
아니나 다를까, 필요 이상으로 유연하게 설계하려 해서 읽기 힘든 코드를 작성한 것 같다. 총 5분에게 리뷰를 요청했으나, 2분만 리뷰를 작성해 주었다. 솔직히 코드를 리뷰하고 싶지 않게 생긴 코드였음을 인정해야겠다. 내 코드가 나만을 위해 작성된 코드였다는 걸 깨달았다. 다른 사람이 쉽게 이해할 수 있도록 배려하는 코드보다는 내 능력을 과시하려는 데 중점을 둔, 이기적인 코드였다고 생각한다.
다른 사람의 코드를 읽으면서 그 점을 더욱 절실히 깨닫게 되었다. 솔직히 말해서, 다른 사람들이 작성한 코드 중에는 main 메서드에서 모든 기능을 구현하는 방식으로 작성된 코드가 있었는데, 가장 간단하고 직관적이어서 이해하기 쉬웠다. 그만큼 나는 복잡한 구조를 만들고, 그것이 더 나은 것이라고 착각했었던 것 같다. 결국 코드의 유연성도 중요하지만, 그보다 중요한 것은 본질에 충실하고 명확하게 의도를 전달할 수 있는 코드라는 점을 느끼게 되었다.
즉, 단순히 기능을 충족시키는 코드보다는, 명확하고 직관적인 흐름을 가진 코드가 얼마나 중요한지를 알게 되었다. 결국 다른 개발자와 협업할 때나 나중에 내가 다시 그 코드를 봐야 할 때, '이 코드가 무엇을 하고 있는지'를 빠르게 파악할 수 있는 것이 중요하다. 그래서 앞으로는 더 간결하고 명확한 코드를 작성하려고 노력할 것이다.
또 다른 중요한 점은 커밋 메시지의 중요성이었다. 솔직히 '커밋 메시지를 누가 보겠어?'라는 생각으로 대충 제목만 작성했는데, 다른 사람의 커밋 메시지를 보니 친절한 설명이 코드 이해에 얼마나 큰 도움이 되는지 알 수 있었다. 커밋 메시지는 코드의 변화와 의도를 설명하는 중요한 커뮤니케이션 도구라는 것을 깨달았고, 앞으로는 더 신경 써야겠다고 다짐하게 됐다. 특히나 기능 단위의 커밋과 메시지 작성이 코드의 유지보수에 얼마나 큰 역할을 하는지, 이번 경험을 통해 확실히 배웠다.
결국 코드의 본질에 충실하면서도 타인이 이해할 수 있는 코드를 작성하는 것이 가장 중요하다. 객체지향적 사고나 복잡한 설계도 물론 중요한 부분이지만, 결국 프로그램의 목적은 문제를 해결하는 데 있다. 나 혼자 만족하는 코드가 아니라, 다른 사람과 함께 발전할 수 있는 코드를 작성하는 것, 그것이 진정한 의미의 좋은 코드라는 것을 배웠다.
최근 객체지향 관련 여러 권의 책을 읽다 보니, 객체지향적 설계에 과도하게 빠져 있었던 것 같다. 모든 것을 너무 유연하게 설계하려고 하다 보니 오히려 본질을 놓치게 되었고, 그 결과 코드가 복잡하고 이해하기 어려운 형태가 되어버렸다. 이제는 이 안 좋은 기운을 조금 덜어내고, 본질에 더 집중해야겠다고 다짐했다.
