지난 일주일은 우테코에서 강조하던 몰입을 진정으로 체험해본 시간들이었다. 이전에는 구현의 완성을 목표로 했었지만, 이번 미션에서는 더 나은 코드를 목표로 했었다. 하루에 6시간 이상을 핸드폰도 꺼두고 오로지 노트북만 봤다. 그 과정에서 나의 지식 중 많은 것들이 사실 잘못된 정보였음을 깨달았다.

그 잘못된 정보들은 분명 새로운 배움을 꺼려하고 당장의 편안함만을 추구하던 과거의 나에게서 기인했을 것이다. 새삼 현재의 내가 과거의 나와 비교하여 이 분야에 얼마나 관심을 갖고 진심으로 임하고 있는지 느꼈다.

1. 클래스와 객체
2. ESlint, Prettier 적용하기
3. 플로우 차트의 중요성
4. 도메인 로직에 대한 이해
5. 정적 메서드
6. 커밋 스테이징 영역

7. pirvate

8. 리팩토링에 대한 고찰

9. 클래스와 객체 과거에는 클래스와 객체, 인스턴스를 거의 동일한 개념으로 혼동하여 사용했다. 하지만 이번 미션을 통해 각각의 역할과 의미를 분명히 파악하게 되었다.

클래스는 객체를 생성하기 위한 청사진으로, 필요한 상태(속성)와 행동(메서드)을 정의한다. 반면, 객체는 이 클래스에 기반하여 실제 메모리에 할당된 실체로, 클래스의 인스턴스화를 통해 형성된다. ‘인스턴스’는 구체화된 객체를 의미하는데, 이는 특정 클래스의 형태로 메모리에 할당된 상태를 말한다.

이렇게 클래스의 구조를 따라 생성된 객체가 바로 인스턴스이며, 이 과정을 통해 클래스의 추상적인 정의가 실제 사용 가능한 형태로 전환되는 것을 이해했다. 이번 학습을 통해 클래스와 객체에 대한 개념을 보다 명확히 인식하고, 앞서 내가 오해하고 있던 부분들을 바로잡을 수 있었다.

1. ESlint, Prettier 적용하기 이전까지 나는 Visual Studio Code의 확장 기능인 Prettier를 사용해 코드를 정리하는 것만으로도 ‘linter와 Code Formatter를 활용한다’는 1주차 피드백 요구 사항을 충족한다고 생각했다. 그러나 ESLint와 Prettier의 기능이 서로 다르다는 것을 이번에 깨닫게 되었다.

미션을 시작하면서 가장 먼저 했던 일은 ESLint 설정이었다. 그 과정은 단순하지 않았고, ESLint를 효과적으로 사용하기 위해서는 라이브러리와 VScode의 확장팩이 모두 필요하다는 것을 배웠다.

Prettier의 경우, 라이브러리만 사용하는 방법, VSCode 확장 기능만을 사용하는 방법, 그리고 둘을 동시에 사용하는 방법 사이의 차이점을 이해했다. 특히 ESLint와 Prettier를 동시에 사용할 때는 두 도구 사이의 규칙 충돌을 방지하기 위한 세심한 설정이 필요함을 배웠다.

나의 프로젝트 상황에 부합하지 않는 규칙들에 대해서는 ESLint 설정에서 제외해야 했다. 예를 들어, JavaScript 파일을 import할 때 확장자명을 명시하지 않는 것은 ES6 모듈 사양에 맞지만, Node.js 환경에서는 반드시 필요한 경우가 있었다. 이러한 상황에서 ESLint의 기본 설정이 문제를 일으킬 수 있기 때문에, 확장자와 관련된 규칙을 무시하도록 설정해야 했다.

처음에는 설정의 복잡함에 좌절할 뻔 했지만, ESLint와 Prettier 설정에 하루를 할애한 후, 내 코드의 질이 실질적으로 향상되는 것을 체감할 수 있었다. 이는 코드 작성 시 발생할 수 있는 실수를 줄이고, 일관성 있는 코드 스타일을 유지하는 데 크게 도움이 되었다.

또한 프로그래밍 요구사항에 따라 Airbnb의 코드 컨벤션을 따르도록 권장받았는데, ESLint 설정을 통해 이러한 스타일 가이드를 규칙으로 직접 적용할 수 있다는 사실이 놀라웠다. 이전 주차에는 Airbnb 스타일 가이드를 수동으로 적용하려고 노력했었지만, ESLint를 통해 이 과정을 자동화할 수 있게 되어 훨씬 더 효율적인 작업 흐름을 구축할 수 있었다.

1. 플로우 차트의 중요성 기능 목록을 더 자세히 공들여서 작성하자던 지난 주의 다짐을 상기하며, Eslint 설정을 끝내고 다음날은 하루 종일 기능 목록 작성에 매진했다. 특히 플로우 차트 작성에 많은 시간을 할애했고, 그로 인해서 정말 많은 것들을 얻을 수 있었다.

첫 번째, 뒷 부분을 생각 하다 보면 앞 부분을 잊는 등 전체적인 그림을 한번에 구상하는 것에 어려움을 겪었었는데, 플로우 차트를 그리며 떠오르는 프로세스들을 즉각적으로 그림으로 표현함으로써 이러한 어려움을 해결할 수 있었다. 또한, 프로세스들을 구체적으로 나타내기 위해 기능들에 대해 깊게 생각하다 보니 구현을 어떻게 해야 할지 전보다 훨씬 수월하게 감이 잡혔다.

두 번째, 플로우 차트 작성 도구인 draw.io를 발견하는 것이었다. 이 사이트를 통해 플로우 차트 작업 공간을 GitHub 레포지토리와 직접 연동할 수 있었고, 플로우 차트의 변경 사항을 레포지토리에 바로 커밋할 수 있었다. 기존에는 README 파일에 플로우 차트를 첨부하려 하면 번거로운 과정이 생각나 한숨이 나왔지만, 이제는 간단한 몇 번의 클릭만으로 변화가 레포지토리에 반영된다.

세 번째, 플로우 차트가 실제 구현 단계에서 훌륭한 이정표가 됐다. 상세하게 작성된 플로우 차트는 구현 과정에서의 혼란을 줄여주었고, 개발의 흐름을 매끄럽게 이끌어줬다.

이 경험을 통해 기능 목록과 플로우 차트의 완성도가 프로젝트 성공에 큰 영향을 미친다는 사실을 몸소 체험하였다.

1. 도메인 로직에 대한 이해

이번 미션은 “도메인 로직에 대한 단위 테스트를 구현하라”는 새로운 요구사항이 추가되었다. “도메인 로직”이란 용어를 처음 접하면서, 이 요구사항을 충족시키기 위해 그 의미를 찾아봤었고, ‘eddy_song’ 님의 블로그를 통해 도메인 로직에 대한 깊은 이해를 얻을 수 있었다.

도메인이란, 소프트웨어가 해결하려는 실제 세계의 문제들을 말한다. 따라서 로직이 도메인 로직인지를 판별하기 위해선, 그 로직이 실제 문제에 대한 결정을 내리고 있는지를 살펴봐야 한다. 이번 미션을 예로 들면, 로또 당첨 번호를 생성하거나 결과를 판단하는 로직이 바로 도메인 로직에 해당한다.

이처럼 로직을 도메인 로직과 그렇지 않은 로직으로 구분하고, 각각을 결합도가 낮게 유지하는 것이 클린 아키텍처에 다가서는 첫 발걸음이라는 것을 학습했다.

위와 같이 생각지도 못한 곳에서 깊은 통찰을 얻을 수 있었고, 추가로 클린 아키텍처에 대해 조금 더 깊게 공부해봐야겠다는 생각이 들었다.

1. 정적 메서드 Eslint를 설정하고 코드를 구현하는 과정에서 this 키워드를 사용하지 않는 메서드는 정적 메서드로 선언하라는 에러가 출력 됐다.

정적 메서드란 해당 클래스의 특정 인스턴스와는 연결되어 있지 않아서 클래스의 인스턴스를 생성하지 않고 직접 호출할 수 있는 메서드라고 한다. 정적 메서드를 학습한 덕분에 객체를 생성할 필요가 없는 메서드를 구분할 수 있게 되었고, 필요 없는 인스턴스 생성 코드를 줄여서 코드를 조금 더 간결하게 작성할 수 있게 되었다.

처음에는 Eslint의 강제적인 에러들에 반감이 생겼었는데, 이 경험을 통해 에러들이 나에게 새로운 지식들을 배우도록 도와준다는 것을 느꼈다.

1. 커밋 스테이징 영역 그동안 꼼꼼하게 기능 단위로 커밋하는 걸 잊고 여러 기능을 한꺼번에 구현해 버렸던 적이 많았다. 그럴 때면, 구현한 기능 일부를 메모장에 붙여넣고 작업 영역에서 삭제하는 등, 상당히 번거로운 방법으로 커밋을 분리했다.

그래서 변경사항 중 일부분만 커밋하는 방법은 없을까 찾아보게 되었고, 커밋하고 싶은 부분만을 선별적으로 스테이징한 뒤 커밋할 수 있다는 사실을 발견했다.

‘모든 변경사항을 스테이징 영역에 추가하시겠습니까?’ 한 번도 제대로 생각해보지 않았던 그 영어 문구가 떠올랐다.

이를 계기로 커밋의 작동 원리를 더 자세히 알아보았고, 지금까지 모호하게 사용해왔던 커밋의 개념을 확실히 이해할 수 있게 되었다.

1. pirvate

   제공 받은 로또 클래스 코드를 들여다보던 중, 낯선 # 키워드가 눈에 띄었다. 로또 클래스를 활용하기 위해 # 키워드의 의미를 찾아봤고, #이 private 변수를 위한 것임을 알게 되었다.

분명 # 키워드를 prefix 해놓은 의도가 있을거라 생각했다.

#을 붙여서 외부에서는 접근할 수 없도록 한다는 것, 그리고 그것이 결합도를 낮추는 데 기여한다는 것까지, 모든 게 논리적으로 이어졌다. 심장이 뛰었다.

1. 리팩토링에 대한 고찰 처음 두 주차 동안 나는 기능 구현에 급급했다. 비록 코드가 지저분해도, 작동만 하면 그것으로 만족했다. 하지만 이번 주는 달랐다. 단순히 ‘작동하는 코드’를 넘어 ‘잘 짜인 코드’를 목표로 삼았다. 더 나은 아키텍처, 명확한 변수명, 그리고 논리적인 로직에 대한 고민이 깊어졌다.

특히 내가 설계한 객체 구조의 타당성에 대해 많이 고민했다. 당첨 결과를 판단하는 메서드를 가진 클래스를 리팩토링 했던 경험을 예시로 들면, 처음에는 로또 객체를 생성할 때 당첨 번호를 생성자 인자로 넘겼지만, 그 방식이 타당하지 않다고 생각했다. 그래서 로또 번호만 생성자에서 받고, 당첨 번호는 결과 판단 메서드의 인자로 넘기는 방식으로 바꾸었다.

그리고 private 키워드와 클래스 분리를 통해 객체의 데이터를 외부에 노출시키지 않고 해당 객체 내에서 프로세스를 수행하도록 하여 보다 완벽한 객체 지향적 프로그래밍을 하고 싶었는데, 새로 배운 것들에 적응하며 시간에 쫓기는 바람에 실천하지 못한 것이 아쉬움으로 남는다.

하지만 그럼에도 긍정적인 것은 이번주도 분명히 지난주의 나와 비교했을 때 정말 많이 성장했다는 사실과 친해질 수 없을 거라 여겼던, 초등학교 여름방학 숙제처럼 느껴지던 코딩이 지난 몰입해온 일주일 동안 진심으로 즐거웠다는 점이다.

This line appears after every note.