딴짓모음/우아한테크코스 7기

[우아한테크코스] 1주차 프리코스 회고

웅디캉 2024. 10. 22. 18:15

 

안녕하세요. mori 입니다.

기대와 설렘 그리고 약간의 두려움을 안고 시작한 우테코 프리코스의 1주차가 마무리 되었네요.

일주일 간 열심히 달려온 길을 돌아보며 내가 가고자 하는 곳으로 잘 가고 있는지 회고를 해보려고 합니다.

그간 느끼고 생각하고 배운것들도 같이 정리해보겠습니다.

약간은 자조적인 글이 될수도 있겠습니다. 원래 조금 그런편이라서요..! 

아마도 스터디원분들이 제 회고를 먼저 읽어주실 것 같은데요.

간단하게 제 소개를 먼저 드리겠습니다!

 

 저는 어떤 사람이냐면요..! 

저는 컴퓨터 공학과를 졸업했고 현재 6년차 F/W개발자로 일하고 있습니다.

이미 직장을 다니고 있는 마당에 다른 분들의 기회를 빼앗는 것 같아서 우테코에 지원하는 마음을 가지는 것 조차 죄스러운 마음이었습니다만, 조금 더 제가 원하는 방향으로 살고 싶은 마음에 염치 불고하고 지원을 하여 프리코스에 참가하게 됐습니다.

 

저는 이제껏 저의 즐거움과 가치관에 맞지 않는 일을 하며 고통을 느끼면서도 ‘일이 힘든건 당연한거야. 퇴근하고 지코바나 시켜먹으면 그게 행복이지’ 라고 생각하며 살았습니다. 그땐 행복하다고 생각했거든요. 그때도 사실 ‘행복은’ 했습니다.

최근 개인적인 사건을 계기로 제 자신에 대해 깊이 고민하게 되었는데, 그러다 보니 저도 제가 좋아하는 일을 한번 해 보고 싶어지더라구요.

'가치'라는 말이 참 낯간지러웠는데, 이제는 회사가 추구하는 가치와 내가 추구하는 가치가 맞지 않다는 생각이 머릿속에 가득했습니다. 같은 가치를 추구하는 회사에 가고싶어졌고 회사에 기대지 않고 혼자 힘으로 서있을 수 있는 사람이 되고 싶었습니다.

 

여러 고민 끝에 프론트엔드라면 내가 원하는 걸 실현할 수 있겠다. 라는 생각이 들었고, 올해 6월부터 출근 전 1시간씩 프론트엔드 공부를 시작했습니다.

그렇게 혼자 조용히 원하는 세상으로의 탈출(?)을 꿈꾸던 중에 '우아한테크코스'를 우연히 알게 되었습니다.

우테코 속에서 같은 가치를 추구하며 함께 일 하는 방법을 다시 배워보고 싶었고, 올바른 학습 방향과 몰입할 수 있는 환경에서 저와 주변을 들여다보며 함께 성장하는 개발 문화를 경험하고 싶다는 마음이 들었습니다.

 

그래서 결과적으로는 세상을 조금 더 이롭게 그리고 사람들이 조금 더 편안하고 행복해질 수 있도록 도움을 주는 개발자로 살아가고 싶다는 목표를 다시 세워 보았습니다. 근데 사실 아직도 '이게 맞나?'를 몇 번이고 제 자신에게 물어보며 하루를 보내고 있습니다 😹 

 

아무튼..! 프리코스 기간 중 가장 이루고 싶었던 것은 '우물 밖으로 나가는 것' 이었고 이번 일주일간 저의 부족함과 무지를 많이 깨달았습니다!! 그런 점에서는 씁쓸하지만 약간의 목표달성을 하게된 것 같기도 하네요.

제 소개는 여기서 급 마무리 합니다 ㅎ 주절주절 늙고 낡은이(?)의 소개글 읽어주셔서 감사합니다...!

아래 부터는 회고 시작합니다!

 

 TDD의 중요성 

과제 초반에 기능 목록을 작성하며 철저하게 예외 상황을 고려했다고 생각했지만, 개발에 들어가니 생각하지 못했던 예외 상황들이 많이 생겼습니다.

평소 가지고 있던 개발 습관대로 직접 콘솔창을 통해 Test를 하며 개발을 진행했는데, 그러다보니 효율도 떨어지고 코드가 변경될 때 마다 동일한 수준의 기능이 유지되지 않았습니다. 심지어 요구 사항의 누락 까지 발견해서 설계와 알고리즘을 대폭 수정해야하기도 했습니다.

 

개발 전에 TC를 먼저 작성했다면 요구사항과 예외 상황 분석이 조금 더 디테일하게 이루어질 수 있었을 것 같았습니다.  ‘기능구현을 빨리 끝내야 한다는 조급함’ 이 TDD를 수행하지 못하도록 막았던 것 같습니다. 예상치 못한 예외와 디버깅에 더 시간이 많이 소요될 것을 알면서도 말이죠.

지금부터는 시작이 조금 늦어지더라도 Testcase를 먼저 만들고 개발하는 노력을 의식적으로 해야겠다고 생각했습니다.

 

JavaScript 

느낀점

C와 C++만 사용해온 저는 '프로그래밍 언어의 본질은 다 같다!!!' 라고 외치며 JavaScript 기본 문법도 모른채로 우테코에 뛰어들었습니다. C Style에만 익숙해져있던 터라 초반에 미션 기능 구현을 위해 문자를 하나씩 쪼개가며 숫자를 분리하는 원시적인(?) 알고리즘을 짜는 다소 웃픈 시도를 하며 골머리를 앓기도 했습니다 ㅎ

그러던 중 정규표현식과 String관련 API들을 접하게 되어, 그제서야 mdn 문서들을 전전하며 조금 JavaScript스러운 코드를 짜게 될 수 있었습니다.

 

프로그래밍 언어의 본질은 같을지 몰라도, 언어의 기본적인 사용 방법은 항상 숙지하고 있어야 한다는 아주 기본적인 사항을 너무 가볍게만 생각했던 것 같습니다. 

앞으로는 JavaScript 사용을 더 늘려서 많은 문법들을 숙지하고 잘 활용할 수 있는 연습을 해야겠다고 생각했습니다.

 

배운점

  • JavaScript의 모듈 시스템
    • Import 와 Require
    • ESM과 CommonJS
    • Node.js와 V8엔진
    • Babel
  • 비동기 처리
    • Promise, async, await
  • String 처리
    • 정규표현식
    • Escape처리
    • startWith, indexOf 등등

 

 좋은 PR Message 작성 방법 

이번 기회에 PR 내용 작성법에 대해 고민해보는 시간을 가지게 되었습니다.

회사를 다니며 Task들을 신속하게 처리해야 하다보니 PR 메세지도 매번 대충 작성하고, 리뷰도 대충 했던 것이 어느새 나도 모르게 나쁜 습관으로 자리 잡혀있었다는 것을 깨달았습니다.

 

PR 메세지 작성 전, 리뷰어들은 무엇이 궁금할까 생각해보았는데요.

내가 리뷰어라면 버그 발생 상황, 해결 방법 선택의 이유, 리뷰어가 집중해서 봐주었으면 하는 부분, 테스트 계획 또는 테스트 완료 사항을 주로 궁금해할 것 같았습니다.

우테코의 리뷰어분들은 부족했던 요구 사항의 구체화 방안, 코드의 구조, 확장성을 위해 노력한 부분 등이 궁금했을 것 같았고 그런 부분들을 중심으로 PR 메세지를 작성해보려 노력했습니다. (링크)

 

앞으로는 시간이 좀 소요되더라도, 리뷰어분들에게 그리고 미래의 제 자신에게 코드를 더 이해하기 쉽도록 PR 메세지를 구체적으로 잘 작성해보아야겠다고 생각했습니다.

 

 Commit Message Convention과 기능 목록, 그리고 Commit의 단위 

참 부끄럽게도, 커밋에도 컨벤션이 있다는 사실을 몰랐습니다.

변명을 조금 보태보자면 현 회사에서는 코드리뷰를 할 때 코드의 최종 형상만 가지고 리뷰를 진행 했기에, PR의 단위에 대해 생각해본 적은 있엇지만 커밋의 단위에 대해서는 큰 고민을 해본적이 한번도 없었습니다.

하여 저는 혼자 개발하는 브랜치에 마구 잡이로 커밋을 해왔습니다. 그런 통일성 없는 커밋점은 개발 중 버그가 발생할 때면 제대로 정리되어 있지 않은 커밋점을 뒤적거리며 발생 시점을 찾는데 많은 시간을 들게 했던 것 같습니다. 

하지만 이번 기회로 커밋 컨벤션과 과제 요구사항을 지키려 노력하면서, 커밋 단위를 기능별로 명확하게 가져가는 것이 좋은 습관으로 자리 한다면 개발 효율성에 많은 영향을 줄 수 있겠다는 생각을 했습니다.

 

그러나 아쉽게도 이번 미션에서 만족할 만큼의 실천은 하지 못했습니다.

기능별로 커밋 단위를 가져가기 위해 노력했지만, 구현을 진행하다보니 계속 욕심이 생겨서 딸려 나오는 다른 기능들도 홀린듯(?) 같이 작업을 하게 되었습니다. 

그 상태로 커밋을 한꺼번에 진행한 뒤 다시 코드 정리를 하며 커밋점을 나누는 작업을 중복으로 진행하며 시간을 허비했는데요.

그런 저를 돌아보며, 기능 요구 사항과 설계의 중요성을 다시 한번 깨닫게 되었습니다. 

2주차 과제 부터는 커밋점을 유의미하고 간결하게 가져가기 위해 의식적으로 노력하려 합니다. 

 

 Exception Case와 Error Message 

저는 사용자 친화적인 프로그램을 만들고 싶어서 프론트엔드로 직종 변경을 꿈꾸고 있습니다.

사용자에게 친절한 프로그램을 만들기 위해선 세분화된 좋은 에러 메세지를 작성하는 것이 중요하다 여기고 있었고 프리코스 커뮤니티에서도 좋은 자료를 발견해서 에러 메세지 세분화를 해봐야겠다는 목표를 가지고 있었습니다.

 

하! 지! 만! 미션 진행 중에 ‘기능 구현’에 집착하며 에러 세분화 작업을 후순위로 미뤄두다가 제출할 때 까지도 만족할 만큼의 에러 메세지를 작성하지 못했습니다 🥹

개발 완료 후 뒤늦게 Exception을 분류하여 상황별로 에러 메세지를 다르게 출력해주려고 했으나, 코드 설계를 일정부분 바꿔야 하는 문제가 생겨서 성능(직업병)과 설계, 에러 메세지에 관해 계속 고민만 하다가 지쳐버려 시간이 다 흘렀습니다.

반성하고 있고, 아쉽게 생각하고 있으며 2주차 부터는 조급함을 내려 놓고, 설계 단계부터 에러 메세지를 고려 해봐야겠습니다!!

 

 공포의 ESLint 

1주차는 ESLint에 제일 많은 시간을 쏟았습니다...

프로그래밍 요구사항 중 하나인 ‘Airbnb Code Convention’ 준수를 위해 도움 받을 수 있는 Util을 검색해 보던 중 ESLint 라는 Linter를 발견했는데요. 워낙 많이 쓰이는 툴이고 블로그에 ESLint 관련 셋업 글도 많아서 쉽게 적용할 수 있을 것이라 생각했지만 큰 오산이었습니다. 사실 아직도 해내지 못했습니다 ㅠ

아래에 설정을 하며 겪은 시행착오들을 정리해보았읍니다... 미래의 환경 설정에 성공한 제가 이 글을 아주 우습게 여기길 바라며 기록해봅니다...

더보기

1) ESLint Version (Flat Config)

ESLint 8.21.0 버전부터 config 를 설정해주는 파일 형식이 변경되었다.

기존에는 .eslintrc 파일로 ESLint 항목을 설정해주었지만 8.21.0 버전부터는 Flat Config를 사용하는 eslint.config.js 형식이 새로 도입되었다.

내가 참고했던 블로그들은 모두 .eslintrc 형식을 사용하고 있었고, 나는 ESLint 최신버전을 가지고 블로그와 동일하게 ESLint Config를 설정하려 한 것이 실패의 첫 번째 요인이었다.

 

2) Airbnb Style Flat Config not fully support

Flat Config를 사용하여 ESLint 셋업 작업을 성공시키고 싶은 오기가 생겼다.

Stack Overflow와 ESLint 공식 홈페이지를 전전하며 Flat Config 파일 설정방법을 학습했다.

rules Option을 통한 Config 설정은 잘 되는 것을 확인했다.

하지만 홈페이지에 나온대로 외부 Config를 참조해오는 방식의 extends를 사용해봤지만 airbnb style이 적용이 되지 않았다.

그러다 해당 링크 를 통해 airbnb style은 아직 flat config에서 완전하게 지원이 되지 않는다는 것을 발견했다.

아직 flat config를 지원하지 않는 외부 config는 ‘FlatCompact’ Util을 통해 migration해오는 방법이 있다고 하여 해당 방법을 시도해보았다.

공식 홈페이지 가이드대로 config 파일을 설정해보았지만 어찌된 영문인지 적용이 되지 않았다.

import globals from "globals";
import pluginJs from "@eslint/js";

import airbnbConfig from "eslint-config-airbnb-base";

export default [
  pluginJs.configs.recommended,
  airbnbConfig,
  {
    languageOptions: { 
      globals: globals.browser 
    }
  }
];

자료를 더 찾아보았지만 발견은 하지 못하여 Flat Config를 사용하는 ESLint에서 airbnb style을 적용하는 것은 잠시 보류해두고 안정화된 버전으로 설정을 다시 진행해야겠다고 생각했다.

 

3) ESLint downgrade

ESLint 버전을 downgrade 하여 airbnb style을 다시 적용해보는 것을 시도해보았다.

npm 공식문서 내용을 바탕으로 airbnb-base 설정에 필요한 peerDependencies를 파악하고 flat config를 사용하지 않는 버전인 7.32.0으로 downgrade를 진행했다.

그 후 $npx eslint —init 명령으로 airbnb config를 extend하는 ESLint Config도 생성하였다.

하지만 또 airbnb 가이드 대로 VSCode상에 빨간줄이 뜨지 않았다.

npx를 통해 커맨드 창으로 eslint 검사를 직접 수행해보아도 가이드는 적용이 안되는 듯 했다.

아직까지도 계속 원인은 찾는 중이며 나의 프리코스가 끝나기 전 Airbnb Style 설정과 Flat Config Migration 을 성공 시키기 위해 계속 문을 두드려 볼 것이다!!!!!!!!!!! 진짜 누가 이기나 보자!!!!!!!!

 

실패요인과 느낀점

1️⃣ 버전과 dependency를 확인하지 않았다

버전과 depenency의 중요성을 뼈저리게 느꼈다. 또한 늘 최신버전이 좋기만한 것은 아니라는 것도 배웠다. 급변하는 프론트엔드의 특성을 직접적으로 느낄 수 있었던 기회였던 것 같다.

 

2️⃣ 문서를 꼼꼼하게 읽지 않았다

조급함 때문에 환경 설정 가이드 문서들 대충 읽은 것이 화근이었다고 생각한다.

이미 읽었던 문서에 Flat Config에 관한 경고 문구가 있었는데도 발견하지 못했다. 그러다 Flat Config의 존재를 알고 난 뒤 해당 문서를 다시 보니, 경고 문구가 이제서야 눈에 보이는 경험을 했다.

무의식적으로 모르는 내용은 흐린눈으로 보고, 아는 내용만 받아들이려했던 것이 원인이라고 생각했다.

앞으로는 조급함을 조금 내려놓고, '느리더라도 완전하게 이해하는 것이 더 중요하다'는 것을 되 새기며 학습을 하는 태도를 가져야겠다.

 

 👾 1주차 최종 소감 

성장은 스스로 하는 것이다

성장은 스스로 하는 것이고 배움은 찾아 먹는 것이라는 걸 정말 많이 깨달았습니다.

지금껏 회사 탓을 하며 성장의 기회를 밖에서만 찾곤 했습니다. 우테코 프리코스를 신청하게 된 것도 그런 이유 때문이었습니다.

 

하지만 들여다보면 지금 제가 속한 회사 안에서도 개선할 점과 배울 점이 넘쳐나는데, 저는 그 동안 들여다 보려고 하지 않았다는 걸 이번 일주일 내내 느꼈습니다. 그간 별 고민 없이, 호기심 없이, 생각 없이 일 하고 있던 지난날의 제 모습이 부끄러워져 괴롭기도 했습니다.

그렇게 몇 년 동안 깨닫지 못했던 사실을 짧은 일주일 간의 몰입 끝에 알아차리게 되었다는 점이 스스로도 놀라웠습니다.

 

또한 '어디에 있든 배울거리를 찾을 수 있고 성장할 수 있다' 는 생각이 들면서, 나의 성장은 외부가 아닌 나 자신에게 달려있다. 라고 생각하니 마음이 편해지면서도 웅장(?)해 졌습니다.

그런 생각을 하고나니 우테코 합격을 바라게 되지 않게 되었습니다. 다른 대단한 분들의 소중한 기회를 뺏는 느낌도 들고요... (누가 나한테 기회 준다고 한 적 없지만...)

원래는 우테코 최종합격이 목표였지만, 이제 합격은 바라지 않고(누가 합격시켜 준다냐? 그래도 되면 좋겠다) 프리코스에서 얻어갈 수 있는 것만 최대한! 많이! 배부르게 찾아먹기로 목표가 변경되었습니다.

 

몰입의 즐거움

대학생 시절, 코딩에 몰입하며 밥먹는 시간도 아까워 했던 때가 있었습니다.

사실 저에게 이제 그런 열정은 없어졌다고 생각했습니다. 그러면서도 내심 다시 확인해보고 싶은 마음에 프리코스를 신청했습니다.

놀랍게도 이번에 제 속에도 그런열정이 남아 있었단 것을 발견했습니다. 미션에 몰입하고 있다보면 하루가 쏜살같이 흘렀고, 하루 종일 과제와 코드 생각을 하고, 밥먹을 때도 유튜브로 코딩 강의를 듣곤 했습니다.

그렇게 열정을 쏟아붓고 산책을 하던 중에 ‘몰입하는 내 모습’ 이 기특하고 마음에 들어서 기분이 너무 좋았습니다.

우테코에서의 몰입을 통해 아무도 알아주지 않더라도, 내가 나에게 만족할 때 찾아오는 즐거움을 느낄 수 있었습니다.

 

우물안의 ‘나’ 알아차리기

세상에는 정말 대단하고 멋지고 똑똑한 사람들이 많다는 것을 깨달았습니다.

제가 있는 곳이 우물안인줄도 모르고 살아왔는데, 이번 기회에 바깥 세상을 조금이나마 구경할 수 있었습니다. 제가 모르고 있던 지식들과 업무 효율을 높이기 위한 수많은 방법들, 그리고 서로의 성장을 도모하기 위한 환경과 노력들이 많다는 걸 알았습니다.

몰랐던, 모르고 있었다는 것 조차 몰랐던 사실들을 차근차근 배우며 우물밖으로 조금씩 나아가고 싶습니다!!!!!

 

 

🫸🏻🫷🏼앞으로 힘 써볼 것들 정리  

  • ESLint 재도전
  • 설계 단계에 Error Handling 고려 
  • 기능 명세 꼼꼼하게 하기 + 기능 별 Commit 지키기 
  • PR 메세지 더 친절하게 작성
  • 코드 구조와 함수명, 변수명 더 명확하게 하기
  • 파일 분리하기
  • jest 테스트 방법, jest란 무엇인가? 학습하기
  • 비동기 처리 재학습하기