우아한테크코스 7기 프리코스 최종 회고 (웹 프론트엔드)

0. 언젠가 한 번 지원해야겠다 생각했던

우아한테크코스에 대해서는 옛날부터 들어서 알고 있었다. 내가 아는 지인이 우테코에 다니기도 했었고. 대학에서 컴퓨터공학부 수업을 듣고 있기는 했지만, 웹 프론트엔드에 대한 수업은 많지 않았기에 우테코에 들어가서 1년간 제대로 배우면 좋겠다하는 생각을 가지고 있었다. (물론 학교에서의 수업이 중요하지 않다는 의미는 아니다). 또 합격하지는 못하더라도 4주 동안 진행되는 프리코스를 통해 얻어가는 것이 많다고 하기에 더욱 기대가 되었었다.

 

그리고 시간은 흘러 우아한테크코스 7기 입학설명회 영상이 업로드가 되었다. 이번 7기의 주제는 ‘메타인지’였다. 메타인지? 어디선가 들어봤지만 정확히 무슨 뜻인지는 잘 몰랐다. 메타인지는 아는 것과 알지 못하는 것을 구분할 수 있는 능력으로, 자신의 인지 과정을 객관적으로 인지하는 능력으로 메타인지가 높으면 본인이 어느 위치에 있는지 잘 파악할 수 있기 때문에 목표를 세우고 이루는데 큰 도움이 된다. 내가 메타인지가 높았나 생각을 해보았다. 작업을 하다 때때로 길을 잃고 헤매는 경험이 많았기에 메타인지를 길러야한다는 사실을 알게 되었다. 그래서 자기소개서에서 목표를 작성하는 란에 ‘메타인지에 대한 의식’을 지속적으로 실천하겠다고 작성했다. 구체적인 로드맵을 설정하지 않고, 내가 지금 어떤 문제를 해결하고 있는지 의식하지 않은 채 개발을 진행했었기에, 이번 프리코스를 진행할 때에는 내가 지금 어떤 상태인지, 무엇을 하고 있는지 파악하는데 집중하겠다는 다짐을 했었다.

 

그리고 ‘프리코스를 해치우지 않는다’라는 목표도 세웠다. 사실 학업을 병행하면서 프리코스를 진행하기에 여유롭게 프리코스를 진행할 수 있는 상황이 아니리라 예상이 되었다(프리코스 1주차가 중간고사와 겹치기도 했고). 하지만 프리코스 미션을 끝내는데에만 집중한다면 몰입을 하지 못하고 대충대충할 것이 뻔했기 때문에 마음이 조급해지더라도 차근차근 미션을 진행해야 겠다고 다짐했었다. 자기소개서를 작성하며 생각이 정리가 되었다. 프리코스가 시작하기 하루 전에 프리코스 커뮤니티(디스코드)가 열렸고, 디스코드에 자기소개서를 작성하며 느낀 바를 짧게 작성해서 올렸다. 과연 어떤 미션이 나올까 기대가 되었다. 그리고 하루가 지나, 프리코스 1주차가 시작되었다.

 

프리코스 커뮤니티(디스코드)에 작성했던 짧은 글의 일부

---

1. 프리코스를 진행하며 배운 점

나의 예상과는 다르게, html, css를 활용한 뷰 구현은 아예 없었다. React를 사용하지도 않았다. 오직 Javascript를 활용해서 특정한 내용을 입력하면 요구사항을 반영한 출력값이 도출되어야하는 프로그램을 만들어야했다. 대학교 과제같다는 느낌도 들었다. 특징이라면 어떤 내용을 예외처리를 해야하는지가 두루뭉술하게 서술되어 있어서 생각을 많이 해야했다는 점? 1주차, 2주차… 한 주차 미션이 끝날 때마다 공통 피드백이 업로드되었고, 그 다음 주 미션을 진행할 때에는 피드백을 바탕으로 더 발전된 코드를 작성하려고 노력했다(요구사항이 발전된 코드를 요구하기도 했고). 배운 점들을 짧게 정리해보자면,

a. 커밋 메시지 컨벤션(AngularJS commit convention)

프리코스를 진행하기 전까지는 개발을 할 때 일관성 없는 커밋을 진행했었다. 이와 달리 프리코스 미션을 진행할 때에는 AngularJS Commit convention을 배우고 해당 컨벤션을 활용하여 커밋을 작성하였다. 이 컨벤션을 활용한 후, 깃 로그를 통하여 지금까지 커밋별로 어떤 작업을 어디서 진행했었는지 쉽게 파악할 수 있었다. 또한 기능별로 커밋을 작성했는데, 언제 커밋을 해야되는지에 대한 기준이 있으니 더욱 일관적인 개발을 진행할 수 있었다. 이 컨벤션은 다른 프로젝트를 진행하면서도 활용하고 있고, 앞으로도 계속 활용할 것이다.

b. 단일 책임 원칙(SRP)

한 메서드가 하나의 역할을 해야한다는 ‘단일 책임 원칙’은 객체지향적이고 깔끔한 코드에 필수적인 요소이다. 단일 책임 원칙을 적용한 후 특정 상황에서 어떤 메서드를 활용해야 되는지가 더욱 명확해졌으며, 문제가 생겼을 때 어디를 수정해야되는지를 찾는 일이 더욱 쉬워졌다. 프리코스가 끝날 때까지 이 원칙을 계속 지키려고 노력했다. 그리고 앞으로 다른 프로젝트에서 코딩을 할 때에도 이 원칙은 철저히 지키려고 노력할 것이다.

c. MVC 패턴(Model-View-Controller)

사실 웹 프론트엔드 개발을 진행하면서 MVC 패턴을 활용할 일이 많지 않았다. 웹 프론트엔드는 실시간 UI 업데이트에 대한 고려를 많이 해야되고, MVC 패턴이 이에 적합하지는 않았기 때문이다. 하지만 프리코스에서는 실시간 UI 업데이트가 많이 필요하지 않고, 객체지향적인 코드를 작성해야되기 때문에 도입했고 이는 많은 도움이 되었다. 사실 프리코스 이전에는 디자인 패턴에 대한 고려를 많이 하지 않았었는데, 이번 프리코스를 통하여 프로젝트를 효율적으로 설계하는 방법을 배울 수 있었다.

d. getter의 사용을 지양하고 객체에 메시지를 전달하기

객체지향은 객체가 스스로 일을 하도록 하는 프로그래밍이다. 모든 멤버변수에 getter를 생성해 놓고 상태값을 꺼내 그 값으로 객체 외부에서 로직을 수행한다면, 객체가 로직(행동)을 갖고 있는 형태가 아니고 메시지를 주고 받는 형태도 아니게 된다.

출처: https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/

(피드백에 있었던 링크였던걸로 기억한다.)

2주차 미션은 필드를 private로 선언하지 않았었고, 3주차 미션은 필드를 private으로 선언했지만 getter를 많이 활용했었는데, getter의 사용을 지양하고 객체에 메시지를 전달해야한다는 피드백을 확인하게 되었었다. 그리고 4주차 미션에는 getter의 사용을 줄이고 객체 스스로 로직을 수행하게 구현하려 노력했다. 이 점들을 지키려고 노력하다보니 코드가 조금 길어졌지만 위 법칙을 통하여 객체의 활용을 더 적극적으로 유도해낼 수 있었다.

e. 객체지향적인 개발

웹 프론트엔드가 사용하는 Javascript는 Java나 Kotlin에 비해서는 객체지향에 친화적인 언어가 아니라고 생각한다. class가 도입된 것도 비교적 최근으로 알고 있다. 그렇다면 객체지향에 대해서는 신경을 안써도 되는 것일까. 아니라고 생각한다. 객체지향은 개발에 필수와 같은 존재이며, Javascript를 통한 웹 프론트엔드 개발이라하더라도 예외는 아니라고 생각한다. 백엔드 개발에 비해서 중요도가 낮기는 하지만, 객체지향은 분명히 사용될 것이라고 생각한다. 이번 프리코스를 통해서 객체지향적인 개발이 무엇인지 배울 수 있게 된 것은 큰 수확이다.

f. 상수 분리

파일에 값을 하드코딩하지 않고, 상수들을 따로 분리해서 활용하면 휴먼 에러를 방지할 수 있고 가독성 또한 증가한다. constants 폴더를 만들고 역할에 따른 파일들을 생성한 다음, 그 파일들에 상수들을 작성하고, 상수를 활용해야하는 곳에 상수들을 import해서 적용했다. 상수 분리를 하면서 이 작업이 프로젝트 개발에 매우 유용한 방법이라고 생각을 하였고, 주차가 지날수록 상수 분리에 더 신경을 썼던 것 같다.

g. Jest 활용법(테스팅 라이브러리)

내가 지금까지 짠 코드에 대한 테스트를 진행하게 되면 미처 발견하지 못했던 에러를 발견할 수 있게 된다. 테스트 라이브러리 Jest에 대하여 알고는 있었지만 실제로 활용해보는 것은 이번이 처음이었으며, 또한 ‘단위 테스트’라는 개념에 대하여 미숙했었는데 프리코스를 통해 배우고 또 적용할 수 있었다. 확실한 것은 아니지만 에러에 민감한 실무에서는 코딩을 하고난 후, 바뀐 코드에 대한 테스트를 진행하지 않을까. 어떤 테스트를 진행할까 고민하면서, 또 Jest를 어떻게 활용해야되는지 시행착오를 거치며 테스팅에 대한 실력을 향상시킬 수 있었던 것 같다.

---

2. 4주차 미션에 대한 아쉬움

1,2,3주차 미션과는 다르게 편의점 프로그램을 구현해야하는 4주차 미션은 내게는 꽤 어렵게 다가왔다. 일단 문제 조건들이 많아서 이해하는데 애를 조금 먹었었다. 4주차 도중에 1박 2일로 MT를 다녀왔기에 시간이 부족한 탓도 있었겠지만, 프로모션 재고를 전부 구매한 다음 일반 재고를 구매하는 기능을 구현하는 부분에서 많은 시간 지체가 있었다(결국 끝까지 구현하는데에는 실패했다). 각 재고들에 대해 독립적으로 객체를 생성했지만 그러면 위와 같은 상황을 대처하는데 힘들다는 사실을 깨닫고 뒤늦게 Map을 활용한 ProductGroup 클래스를 도입했다.

 

10줄 이내로 메서드를 구현해야하다보니 메서드를 잘개 쪼갤 수 밖에 없었고, 이 때문에 한 파일에 코드 줄 길이가 너무 길어졌었다. 따라서 모델들을 다시 여러 모델로 쪼개는 리팩토링을 미션 도중에 진행했었다. 하지만 그럼에도 불구하고, 기능 하나를 구현하거나 수정해야 할 때마다 건드려야 하는 부분이 너무 많고 또 흩어져있었기에 개발 속도가 계속 느려졌다. 결국, 내가 지금 어떤 상태이고 무엇을구현해야되는지에 대한 자각을 잘 하지 못했었던 것이다. 다시 말해 메타인지가 잘 안되었다는 뜻이다.

 

시간은 계속 흘러 어느덧 제출 마감 데드라인이 다가오고 있었다. 구현이 마무리가 되지 않았기에, 검증도, 테스팅도 구현하지 못하였고, 12시에 다다르기 얼마 전에 부랴부랴 마무리하고 회고를 작성했었다. 예제 테스트 결과는 2/4. 너무나도 아쉬웠다. 설계가 미흡했었나하는 생각, 잠을 줄여서라도 시간 투자를 좀 더 했어야했나 하는 생각 등 온갖 생각이 뒤섞였다. 하지만 이미 4주차 미션은 마무리가 되었고, 이것은 프리코스가 끝났다는 뜻이기도 했다.

4주차 프리코스 결과

---

3. 그럼에도 얻어가는 것이 많았던 프리코스

돌이켜보면 프리코스에 꽤 많은 시간을 쏟았다. 나름대로 기능을 구현하는 것에 재미를 느끼고 시간 가는 줄도 모르고 코딩을 하기도 했다. 이번 프리코스를 통해 얻은 큰 수확은 바로 ‘일관성있고 깔끔한, 가독성 있는 코드를 작성하는 법’을 배운 것이다. 지금까지 내가 아무런 기준도 없이 막 코딩을 했었는지 깨달을 수 있었던 시간이었다.

 

아무래도 내 예상으로는, 최종 코딩테스트에 진출하지 못할 것 같다. 아쉽기는 하지만, 최선을 다했기에 후회가 들지는 않는다. 단지 합격을 하기에는 실력이 부족하였음을 깨닫고 더 노력해야겠다는 사실을 받아들였다. 한 달 동안 많은 내용들을 배웠고, 한 층 더 성장한 것 같다. 진행했던 프로젝트, 지금 진행 중인 프로젝트, 그리고 진행 예정일 프로젝트들에 프리코스 때 배웠던 내용을 활용할 것이다(아마 대대적인 리팩토링을 진행해야 되지 않을까 고민중이다).

 

프리코스가 끝났다고 널널해지지는 않았다. 목표가 있기에 할 일은 끊임없이 생겨났다. 그래서 잠시 프리코스 최종 회고를 작성하는 것이 조금 늦어졌지만(5일 정도), 회고를 작성하기 전까지는 매듭이 지어진 것이 아니었기에 뒤늦게나마 회고를 작성한다. 좋은 기회를 준 우아한테크코스에 감사하며, 앞으로 계속 발걸음을 내딛으려 한다.