[네이버 부스트캠프] 웹 풀스택 챌린지 3주차 회고:: 리팩토링 집착, 성능, 패러다임, 동시성 지옥

학습 활동 가이드의 콘텐츠 이용 및 보호 수칙을 준수하고, 콘텐츠 유출에 주의해 주세요.

해당 포스팅은 경고 문구를 인지한 상태로 작성했습니다.

 

따라서 아쉽지만,

구체적인 미션 묘사나 상황 설명은 최대한 피하고 추상적으로 작성하고 있습니다.

---

목차
- TL;DR
- 3주차, 그리고 멘탈 붕괴🤯
- 리팩토링 집착과 시간 관리
- 동시성, 성능... 새로운 벽🧱
- 패러다임보다 문제 해결
- 균형 무너짐과 깨달음
- 마치며
- 다음 주 목표

 

TL;DR

3주차는 시간이 미친듯이 터졌다.

 

얼마나 터졌냐면,

주말에 뻗었기 때문에 4주차에 몰아 회고를 작성할 정도였다.😂

 

구현과 학습을 모두 잡으려다 둘 다 놓쳤고,

특히 리팩토링을 구현과 동시에 진행하는 습관이 시간을 갉아먹었다.

 

미션의 수준이 업그레이드되면서,

동시성을 생각하지 않을 수 없었고 성능 역시 측정해나가야 했다.

 

결국 2주차까지 나름대로 쌓아왔던 균형이 완전히 무너졌다.

 

리팩토링 시간을 줄이고,

패러다임에 얽매이지 않고 문제 해결 중심으로 접근했다면 뭔가 달라졌을까?

---

3주차, 그리고 멘탈 붕괴🤯

 

3~4주차는 이틀에 한 가지 문제를 구현하는 방식으로 진행됐다.

이 일정이 여유롭게 느껴져서 첫 미션은 설계만 진행한 기행을 부려봤다.

 

결론부터 말하면 이렇게 하지 마세요...ㅋㅋㅋㅋ

완벽한 설계란 것은 없습니다.

 

설계에 공을 너무 들이는 게 좋지 않은 선택으로 느껴졌다.

변수는 항상 존재하고, 모든 조건을 예측할 수 없었기 때문이다.

 

결국 설계가 길어지면 길어질수록

남은 하루에 리팩토링/테스트까지 다 진행할 수 밖에 없..었다...

 

특히, 릴레이 프로젝트나 슬랙 자료 준비, 피어세션까지 겹치면서

무조건 진행해야 한다는 압박감이 커져갔다.

컨디션이 터져서 슬랙 발표는 포기하게 됐다😿

이럴꺼면 왜 밤을 샜지...

---

리팩토링 집착과 시간 관리

 

이번에 어떻게 해야 시간 관리를 잘 할 수 있었을까에 대해

정말 많이 자문하며 내 안에서 답을 찾아나갔다.

 

문제의 핵심은 동시에 하려는 습관이었다.

중복 코드를 유틸로 뺴고, 액션과 계산 로직을 분리하고,

단위 테스트까지 붙이는 건 좋은 습관이라 생각한다.

 

하지만 이번 주처럼 처음부터 끝까지 쌓아올려가는 개발 환경에서는

코드가 계속 수정/폐기될 수밖에 없었다.

 

결국 그 습관이 내 발목을 잡아버린 것이다🤦‍♀️

 

첫날은 완성보다 동작 위주로 구현하고,

둘째 날에 개선과 리팩토링을 대대적으로 시행하는 전략이 오히려 더 잘 맞았다.

근데 이 사실은 4주차에 깨달았다. 이때는 그냥 멘탈이 터져서...

 

뭐랄까, 3주차에서 아쉬웠던 점은 유연한 타협에 대한 부분이다.

리팩토링 집착이 구현 속도를 늦추고, 오히려 멘탈을 갉아먹는 원인으로 변했다.

 

좋은 개발자라면 트레이드 오프를 통해

조금 더 유연하게 사고해야 했을 터인데,

조금 늦게 알아차린 것 같아 아쉽다.

 

리팩토링 집착이 구현 속도를 늦추고,

이 신념이 멘탈을 갉아먹는 원인이 됐다.

---

동시성, 성능... 새로운 벽🧱

 

미션이 복잡해질수록 동시성과 비동기 처리에 대한 고려를 안할 수 없었다.

JavaScript를 처음 마주할 때부터,

JS의 꽃은 비동기 처리에 있다는 말을 주구장창 들었는데...

 

사실 Promise, async/await 같은 비동기 개념은 알고 있었지만

동시 접근 제어를 다뤄본 경험은 거의 없었다.

 

미션 난이도가 상승하면서,

이 조건에서는 동시 접근하게 되면 깨지지 않나? 라는 의문이 들 수 밖에 없었다.

 

문제는, 한 데이터에 여러 로직이 접근할 수 있는 상황을 해결해본 경험이 없단 것이다.

어떤 락을 걸어 충돌을 막으면 좋은지,

혹은 안전하게 병행 처리를 해야할지 결정하는 부분이 너무 어려웠다.

 

node.js는 멀티쓰레드를 지원하지만,

JS는 언어 레벨에서 싱글 스레드로 동작하니...

 

사실 조금 더 딥하게 들어가면 Node.js는 내부적으로 libuv 라이브러리를 이용해

백그라운드에서 멀티스레드 스레드 풀을 운용한다.

 

파일 읽기, 네트워크 요청, 압축/암호화 같은 작업이

이 스레드 풀에서 병렬 처리되는데,

이게 겉에서 본 모양새는 JS 코드 자체가 여러 일을 하는 것처럼 보인다.

 

여기에 Node.js 10 이후 도입된 Worker Threads까지 더해지면,

아예 JS 코드 자체를 여러 스레드에서 병렬 실행할 수도 있다.

 

근데 JS는 싱글 스레드인데, 이거 써도 되나?🧐

 

아무튼... 요 애매한 특성 때문에 비동기와 동시성이 머릿속에서 종종 뒤섞였다.

처음엔 같은 개념인 줄 알았단 말이다.

 

여기에 성능 최적화와 동시성 처리 문제까지 얽히면서

프로파일링과 모니터링의 필요성을 절감했다.

 

CLI 환경과 실시간 처리가 고도화될수록

리눅스 환경이 훨씬 유리하지 않을까하는 결론에도 이르렀다.

 

시스템 콜 추적, 리소스 사용량 분석, 스케줄러 동작 관찰 등.

현업과 가까운 조건에서 실험할 수 있기 때문이다.

---

패러다임보다 문제 해결

 

객체지향 패러다임을 고집한 것도 발목을 잡았다.

이제와서 생각해보면, 굳이 그럴 필요가 있었나 싶다.

 

사실 JavaScript의 클래스는 문법적 설탕에 불과하다.

결국 내부적으로는 프로토타입 기반 객체로 변환되는데...

 

패러다임은 필요할 때 꺼내쓰는 도구처럼 사용해야했지 않았나 싶다.

 

하지만 나는 어느샌가 패러다임을 위한 코드를 짜고 있었고,

이게 꽤 불필요한 시간 소모를 일으키지 않았나 싶다.

 

메서드 한 두개는 그냥 바로 require 방식을 잘 이용하면

클래스처럼 보이게 만들 수도 있었을텐데.

module.exports = {
  greet(name) {
    return `Hello, ${name}👋🏼`;
  }
};

const greetBot = require('./greetBot');
console.log(greetBot.greet('mindaaaa');

 

앞으로는 문제를 해결하기 위해 패러다임을 선택하는 방향으로 전환하고싶다.

---

균형 무너짐과 깨달음

 

정말 아쉬웠던 점은,

2주차까지 잡았던 학습과 구현 사이의 균형이

3주차에 완전히 깨졌다는 점이다.

 

지나고보니 이 부분에서 오히려 성장한 것 같지만.

당시엔 이게 너무 슬펐다 진짜.

@pettydus

 

학습량이 많아질수록 압도당하는 느낌을 매일같이 받았고,

중간에 불필요한 설계와 준비에 매몰되면서 야크털을 열심히 깎았다.

 

완벽한 설계는 없다.

오히려 숲의 윤곽만 잡고 구현하며 보완하는 편이 효율적이었는데,

당시엔 그런 인사이트를 얻을 수 없었다.

 

다만 한 가지, 과도한 사전 대비는 답이 아니었다.

---

마치며

 

나의 네부캠 3주차는 힘들었다.

정말 힘들었다.

 

그리고, 그만큼 명확한 교훈을 얻었다.

1. 리팩토링과 구현은 분리할 것
2. 패러다임보다 문제 해결 중심으로 접근할 것
3. 설계는 충분히만 하면 된다. 나머지는 구현하며 보완하자.

 

4주차는 그래서 이게 왜 필요한가?라는 질문을

코드 전반에 던져나가며 진행할 생각이다.

---

다음 주 목표

@pettydus

1. 첫날 동작 구현을 최대한 끝내놓기
   둘째 날은 리팩토링과 테스트에 집중하기
  두 영역을 구분해 진행하자
2. 성능 최적화 기초를 학습하자
3. 구현 목적과 필요성을 명확히 하는 습관을 들이자📌