우테코 8기 1주차 미션 회고

@Override
public void start() {
	System.out.println("8기 1주차 미션")
}

“두려움 → 도전 → 실패 → 성장”을 체감한 일주일

1주차 미션 - 문자열 덧셈 계산기

처음엔 “이 정도면 금방 끝나겠네?”라고 생각했습니다. 하지만 요구사항을 차분히 읽어보니, 이 미션은 기능 구현도 중요하지만 내가 직접 설계하고 예외를 생각하고 검증해야 하는 과제였습니다.

입력한 문자열에서 숫자를 추출하여 더하는 계산기를 구현한다.

• 쉼표(,) 또는 콜론(:)을 구분자로 가지는 문자열을 전달하는 경우 구분자를 기준으로 분리한 각 숫자의 합을 반환한다.
  • 예: "" => 0, "1,2" => 3, "1,2,3" => 6, "1,2:3" => 6
    
    
• 앞의 기본 구분자(쉼표, 콜론) 외에 커스텀 구분자를 지정할 수 있다. 커스텀 구분자는 문자열 앞부분의 "//"와 "\n" 사이에 위치하는 문자를 커스텀 구분자로 사용한다.
  • 예를 들어 "//;\n1;2;3"과 같이 값을 입력할 경우 커스텀 구분자는 세미콜론(;)이며, 결과 값은 6이 반환되어야 한다.
    
    
• 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException을 발생시킨 후 애플리케이션은 종료되어야 한다.

나는 이 요구를 최소 기능만 정의하고 나머지는 스스로 판단해서 개발하라는 메시지로 받아들였습니다.

TDD와의 첫 만남

프리코스를 시작하기 전, 커뮤니티에서 오가는 TDD(테스트 주도 개발)라는 단어는 들어만 봤었던 단어였습니다. 그냥 단순히 '코딩 전에 테스트를 먼저 작성하는 방법' 정도로만 알고 있었습니다.

자주 이야기가 오가다보니 호기심이 생겨 포비님의 TDD 세미나 영상을 시청했습니다. 왜 TDD가 필요하고 어떻게 사용하는지를 이해했습니다. 단순히 테스트를 넘어 좋은 설계를 위한 길잡이라는 것을 어렴풋이 이해했고, 이번 1주차 미션에 직접 도입해보기로 결심했습니다.

솔직히 많이 두렵기도하고 어떻게 해야할지도 몰랐습니다. 한번도 해보지 않은 방식이었고, 당장 미션을 받고 시작했을 때 무엇을 어떻게 테스트해야 할지조차 막막했습니다.

하지만 8기 입학설명회에서 "두려움보다 일단 도전해보자"라는 말이 계속 생각났습니다. 일단 무엇이라도 테스트를 해보고 기능을 만들어보자라는 생각이 들었습니다.

기능 요구 사항을 처음 딱 보였던 공백을 입력했을 때 0을 반환하는 단순한 로직부터 시작했습니다. 그렇게 단순히 하나씩 성공 케이스를 생각해보며 실패하고, 기능을 만들고, 성공하는 사이클을 하나씩 밟아가며 조금씩 앞으로 나아가기 시작했습니다.

@DisplayName("빈 문자열은 0 반환")
    @Test
    void 빈_문자열은_0을_반환() {
        //given
        String input = "";

        //when
        int result = StringCalculator.calculate(input);

        //then
        assertEquals(0, result);
    }

(ps. 인생 첫 테스트 코드였습니다..ㅎㅎ)

실패라는 이름의 발판

이전까지 개발에서의 실패는 단순한 '오류'로 치부하고 넘어갔습니다. 하지만 TDD 사이클 안에서 마주한 실패는 더 이상 실패가 아니였습니다.

오히려 "내가 어디로 가야 할지 알려주는 나침반"과 같은 역할을 해주었습니다. 이러한 실패가 다음에 구현해야할 최소한의 기능을 알려주었고, 이러한 깅르 따라가다 보니 어느새 기본 기능은 모두 구현되어 있었습니다. 모든 기능이 완료되고 테스트가 모두 초록불이 들어왔을때 기존에 개발했었던 어느때보다 기뻤습니다.

하지만 이제부터 TDD의 진짜 가치인 리팩토링을 시작했습니다. 제 코드는 Calculator 클래스 하나에 뒤엉켜 있었습니다. 구분자 추출, 문자열 파싱, 유효성 검증, 숫자 계산까지 하나의 클래스가 많은 책임을 지고 있었습니다.

새로운 기능을 추가하고 검증 로직을 넣을 때마다 디버깅 시간은 점점 길어졌고, 변화에 취약한 코드라는 것을 체감했습니다. '검증', '추출', '입력', '계산'처럼 역할에 따라 코드를 분리해야 한다는 생각이 들었습니다.

그래서 이전 프로젝트에서 api, config, controllers, middlewares, service처럼 패키지를 나누어 각자의 역할을 부여했을 때, 코드 찾기도 쉬웠고 유지보수하기도 편했던 경험이 생각났습니다.

그래서 그 기억을 바탕으로 MVC 패턴에 대해 조금 더 공부하며, 각 계층에 명확한 역할과 책임을 부여하는 방식으로 코드를 분리를 시작했습니다.

(PS. 후.. 리팩토링한다고 고생했다..)

순서에 대한 고민

개발을 지속적으로 진행하다보니 검증, 출력 등 부가적인 기능부터 구현하기 시작했습니다. "입력값은 뭐 그래도 나중에 해도 괜찮겠지", "그래도 검증이랑 입력값을 받았을 때 추출하는 기능이 더 중요하지"라고 생각하며 구현하기 시작했습니다. 그러나 핵심 기준이 되는 '도메인'에 대한 정의 없이 기능을 추가하자 코드는 계속 예상치 못한 버그들이 계속 발생했습니다.

예를 들어, 입력을 했을 때 커스텀 구분자 / 숫자 파트를 나눠서 정규식으로 추출하고 정규식으로 검증하다보니 이미 앞에서 예외가 발생해서 다른 에러 메시지가 나온다는 등 이러한 버그가 많이 발생했습니다.

결국 화이트보드에 작성하면서 다시 생각했습니다. 계산기의 검증 과정을 어떻게 수정하고 중요한 비즈니스 로직을 어떻게 짜야할지를 고민했습니다. 그렇게 진행하다보니 현재 과제에서 중요하다고 생각한 숫자와, 구분자가 핵심이라고 생각하며 두개를 모두 도메인으로 정의하고 진행하며 다시 생각하기 시작했습니다.

• Number는 스스로 음수이거나 숫자가 아닌 문자열을 검증하는 책임
• Numbers는 Number들의 합계를 계산하는 책임
• Delimiter는 Set 집합으로 동일한 구분자는 포함하지 않고 문자열을 구분자 집합으로 나누는 책임

이렇게 각자의 도메인에게 역할을 부여하여 책임을 주었고 도메인을 중심으로 역할을 나누자 검증 / 추출 로직을 다시 생각해 볼 수 있게 되었습니다. 기존에는 customDelimiterExtractor/Validator과 NumberPartExtractor/Validator으로 개발을 진행하였는데 InputValidator에서 입력 형식만 검증하고, InputParser로 문자열을 추출하는 담당으로 합치고 진행하니 이전 각 로직은 올바른 시점에 정확한 오류를 발생시키고 종료되었습니다.

이전 프로젝트에서 막연히 '편하다'고 느꼈던 MVC 패턴이 왜 좋은 구조인지, 도메인을 중심으로 설계하는 것이 개발 효율성에 얼마나 큰 영향을 미치는지 느꼈습니다.

(PS. 오류가 너무 많이 나왔습니다 ㅠ.ㅠ)

(PS. 화이트 보드 앞에 앉아서 고민 엄청 했습니다..ㅠㅠ)

몰입의 시간

아침 8시 반부터 밤 11시까지, 시간 가는 줄 모르고 TDD에 빠져들었습니다. "이런 입력값에는 어떤 예외를 던져야 할까?", "어떻게 하면 내 코드를 보는 사람이 쉽게 이해하고 기능을 추가할 수 있을까?" 같은 질문을 스스로에게 던지며 더 나은 코드를 고민했습니다.

(PS. 문제 나오고 하루 고민하고 제출날까지 계속 고민하고 고민하여 개발했습니다..)

단순히 과제를 끝내는 것이 아니라, 사용자가 믿고 사용할 수 있고 개발자가 수정하기 쉬운 프로그램을 만들고 싶다는 욕심이 생겼습니다. 머릿속으로 그리던 구조가 코드로 구현되고, 수많은 실패 끝에 마침내 마주한 성공의 순간은 그 어떤 것과도 바꿀 수 없는 행복감을 주었습니다. 두려움이 있던 자리에, 어느새 즐거움과 몰입이 가득 차 있었습니다.

마무리하며

일주일 저는 TDD를 그냥 막연하게 개념만 알고 있었습니다. 지금의 저는 테스트 코드가 좋은 설계의 첫걸음이라고 생각하게 되었습니다.

단순히 개념을 하나 더 알게 되었다고 생각들지 않았습니다. 문제를 정의하고, 핵심을 파악하고, 실패를 성장의 발판으로 나아가는 개발의 즐거움을 다시 느낄 수 있었습니다.

이젠 코드리뷰를 받고 현재 코드의 문제점과 이제는 조금 더 TDD에 대한 방식을 고민하고 MVC패턴과 도메인 중심 설계에 대해서 고민을 해볼 예정입니다.

코드리뷰를 해주실 모든 분들에게 미리 감사드리겠습니다 !!

모두 같이 성장하고 열띤 토론을 하며 좋은 결과를 내는 개발자가 되면 좋겠습니다 !

이번 프리코스는 시작에 불과합니다. 앞으로 더 어려운 과제와 복잡한 문제들이 기다리고 있을 것입니다. 하지만 두려워하지 않겠습니다. 실패를 두려워하기보다는 그 속에서 무엇을 배울 수 있는지에 초점을 맞추겠습니다.

📌 참고 링크

포비님의 TDD 세미나 유튜브
[GitHub Repository](PR 링크)
우테코 클린코드 체크리스트
AngularJS Git Commit Message Conventions