우아한테크코스 레벨 1 회고

 

어느덧 4월 초가 되어 우테코 레벨 1이 끝났다. (사실 2주 전에 끝났고, 당장 내일이 레벨 2 시작이다. 😅)

회고를 아주 아주 중시하는 우테코 문화에 따라 나도 레벨 1 회고를 해보려 한다.

합격 통보를 받고 기뻐했던 게 엊그제 같은데 시간이 참 빠르다.

항상 느끼는 것이지만, 몰입해서 보낸 시기는 정말 빠르게 지나가지만 돌이켜 봤을 때 많은 기억들이 남아있다.

이번 레벨 1도 그런 시간이었던 것 같다.

짧지만 길고, 길지만 짧았던 레벨 1 무엇을 하며 무엇을 배우고 느꼈는지 되돌아보자.

---

우테코 문화에 따라 회고하는 것까지는 좋지만, 목적 없이 그냥 하고 싶지는 않다.

내가 이번 회고를 통해 얻고자 하는 게 무엇인지 정리해 보자.

회고 목적

• 끝맺음을 통해 다음으로 나아갈 추진력을 얻기 위해: 우리의 삶은 끝없이 바쁘고 혼란스럽다. 이번 바쁨이 끝나면 다음 바쁨이 밀려온다. 바쁨의 파도에 내밀려 살다 보면 금세 번아웃이 찾아오기 마련이다. 이를 방지하기 위해서는 그간 해 온 일들에 마침표를 찍어줘야 한다. 이번 회고를 통해 마침표를 찍으며 새로운 출발을 준비하려 한다.
• 부족했던 점을 인지하고 그것을 개선하기 위한 액션 플랜을 도출하기 위해: 돌아보지 않으면 부족한 점이 무엇이었는지 잘 생각나지 않는다. 또한 막연하게 느꼈던 아쉬움은 불편한 감정으로만 남고 휘발된다. 이번 회고를 통해 아쉬움으로 말미암아 불편한 감정을 느끼는 것을 넘어 나에게 변화를 가져다줄 수 있는 행동과 사고방식이 무엇인지 생각해보려 한다.
• 학습 내용을 기록으로 남겨 미래에 재학습하기 위해: 인간은 망각의 동물이다. 지금 생각이 아무리 또렷해도 1년만 지나면 거의 휘발될 것이다. 이번 회고를 통해 미래의 내가 지금 이 시기에 느끼고 배웠던 바를 다시 학습할 수 있도록, 미래의 나를 위한 하나의 교보재를 만들어 두려 한다.

---

활동 단위 회고

지원 과정 📝

 

지원 과정은 지원서 작성 - 프리코스(4주) - 최종 테스트로 이루어졌다.

지원 과정에서의 과제들은 심하게 어렵거나 무리가 되는 수준은 아니었다.

하지만 결과에 대한 불확실성이 나를 힘들게 했다.

우테코에 들어가고 싶은 마음이 커질수록 불확실성으로 인한 고통도 함께 커졌다.

쓸데없는 걱정이라는 것을 알면서도 이를 통제할 수 없었다.

그런 고통을 충분히 겪어가며 견뎠고, 결국에는 우테코에 합격할 수 있었다.

 

두려움을 용기로 바꿀 수 있다면

우테코 지원 과정 경험으로부터 간직하고 싶은 교훈은 딱 한 가지이다.

"중요한 기회가 찾아왔을 때 쓸데없는 불안을 느끼지 말고, 할 수 있는 일에만 집중하자"

너무 당연한 말이어서 적기도 민망하지만, 지원 과정 경험으로부터 얻은 이 느낌을 잊고 싶지 않아서 적어 보았다.

중요한 기회가 찾아오면 간절해지고, 이 간절한 마음은 종종 과한 집착을 낳는다.

그리고 과한 집착은, 결과를 개선하기 위해 할 수 있는 일들이 많이 남아있음에도 불구하고 걱정과 불안에 에너지를 낭비하게 만든다.

내가 프리코스 과제에 집중할 시간도 부족한데, 이미 제출해서 수정할 수도 없는 지원서를 자꾸 꺼내본 것처럼 말이다.

 

집착이 단순히 우리를 고통받게 만드는 데에서 그치면 큰 문제가 아닐 수 있다. (사실 이것도 큰 문제라고 생각한다.)

그런데 집착으로 인한 스트레스와 불안은 우리가 좋은 결과를 얻기 위해 마땅히 해야 할 일들을 못하게 만들기까지 한다.

결과에 대한 간절함이 도리어 결과를 망치는 원인이 될 수 있다는 뜻이다.

할 수 있는 일에 최선을 다한 후 실패했을 때와, 할 수 있는 일을 미처 하지 못한 채 실패했을 때 중에서 후회가 많이 남는 건은 어느 쪽일까?

 

중요한 기회가 찾아왔을 때, 간절함을 지니되 그 간절함이 좋은 결과를 위해 쓰이도록 해야 한다.

---

온보딩 연극 🕺🏻

 

미션보다 더 걱정이 되었던 온보딩 연극이다.

우테코가 시작되자마자 그다음 주 월요일에 연극을 해야 한다고 공지를 받았으니, 걱정이 클 수밖에 없었다.

우리는 서로에 대한 얘기를 충분히 나눠보기도 전에 연극 주제에 대해 논의했다. 😂

다행히 아이디어 뱅크 조원들 덕분에 어렵지 않게 주제를 결정할 수 있었다.

(주제는 '자바스크립트에 대한 재판'으로 정했다. 😄)

 

주말에 모여 내용을 구체화하는 단계에서는 약간의 어려움을 겪었다.

주제는 참신했지만 연극으로 재밌게 풀어내는 게 어려웠다.

그래도 대여섯 시간의 논의 끝에 스크립트를 모두 완성하고, 나름대로 마음에 드는 연극을 완성할 수 있었다.

처음 걱정에 비해 큰 어려움 없이 즐겁게 연극을 마칠 수 있었다.

 

Relax~

연극 준비 과정에서 스스로의 강박 하나를 발견할 수 있었다.

목적이 있는 커뮤니케이션 상황에서 시간을 효율적으로 사용해야 한다는 강박이다.

나는 창업 팀에서 일한 이래로 시간을 컴팩트하게 사용하는 것을 중시하는 성향을 가지게 되었다.

중요한 목적을 달성하기 위해서는 산더미 같이 쌓인 일들을 주어진 시간 내에 해내야 했기 때문이다.

그래서 창업 팀에 있을 당시 구성원들의 시간을 아끼기 위해 효율적인 회의 문화를 정착시키는 데 앞장서기도 했다.

이러한 성향이 이번 온보딩 연극을 준비하는 동안에도 나타났다.

 

물론 시간을 효율적으로 사용하려는 태도 자체는 큰 장점이라 생각한다.

하지만, 우아한테크코스라는 조직의 특성을 고려할 필요가 있다.

우테코는 즐겁게 교육받으며 학습하기 위한 조직이다.

그런데 이런 조직에서 매사 시간을 효율적으로만 활용하려고 노력하는 게 구성원들과 스스로에게 좋은 영향을 줄 수 있을까?

그렇지만은 않을 것 같다.

때에 따라 의식적으로 마음의 여유를 가져보도록 하자. 🧘🏻

---

미션 1: 자동차 경주 게임 🏎️ [PR 바로가기]

자동차 경주

 

첫 번째 미션은 '자동차 경주'다.

랜덤 숫자에 따라 전진 여부가 결정되는 자동차 경주 콘솔 프로그램을 만드는 미션이다.

 

미션 1의 학습 목표는 다음과 같다.

• Github 기반 온라인 코드 리뷰 경험
• 코딩 컨벤션 준수
• 단위 테스트 작성
• 함수 분리 리팩터링

내가 집중했던 학습 주제는 다음과 같다.

• 좋은 코드란?
• 단위 테스트(Jest)
• JS 기본 (데이터 타입, Object, prototype,...)
• 도메인/UI 분리

 

좋은 코드라는 신기루를 쫓다

미션 1 동안 가장 주안점이 됐던 것은 유지보수에 용이한, '좋은 코드'에 대해 고민하는 일이었다.

함수 단위를 잘게 나누고, 함수 이름을 명확한 형태로 짓고, static, private 키워드를 이용하는 등 클래스 문법을 적극적으로 사용하려 노력했다.

이에 더해 '객체지향의 사실과 오해'에서 배운 내용을 바탕으로 프로그램을 객체 간의 상호작용으로 설계하려 시도했다.

단순히 절차지향적인 코드를 여러 토막으로 나누는 게 아니라 객체스러운 객체를 만들기 위해 고민했다.

이를 위해 코드를 작성하기 이전에 설계에 대해 페어와 충분히 논의하는 시간을 가졌다.

결론적으로 나름 만족스러운 결과물을 얻는 데 성공했다.

 

그런데, 왜인지 그 결과물을 다시 살펴볼수록 부족한 점이 많아 보였다.

잘한 부분보다는 아쉬운 부분이 눈에 더 많이 들어왔다.

그리고 여전하게도 좋은 코드가 무엇인지 감을 잡기가 어려웠다.

 

좋은 코드는 신기루 같이 느껴진다.

풋내기 초보 개발자든, 경력이 오래된 시니어 개발자든 자신의 코드가 꽤 좋은 코드라고 생각할 것이다.

그리고 동시에 부족한 점이 여전히 많은, 안 좋은 코드라고 생각할 것이다.

아는 게 많아진 만큼 부족한 점도 잘 발견할 수 있게 됐기 때문이다.

같은 맥락에서, 내 개발 실력은 과거에 비해 많이 향상됐지만 스스로의 코드에 대해 느끼는 감상은 과거나 지금이나 비슷하다.

 

좋은 코드로 향하는 과정은 이렇지 않을까 싶다.

1. 내 코드가 그럭저럭 만족스럽다.
2. 새로운 내용을 학습한다.
3. 아는 게 많아져 내 코드의 부족한 점이 새롭게 보이지만 개선 방법은 모른다.
4. 개선할 방법을 터득하여 적용한다.
5. 내 코드가 그럭저럭 만족스럽다.
6. 새로운 내용을 학습한다.
7. 아는 게 많아져 내 코드의 부족한 점이 새롭게 보이지만 개선 방법은 모른다.
8. 개선할 방법을 터득하여 적용한다.
9. ... 무한 반복...

그야말로 시지프스의 형벌이다.

앞으로도 끊임없이 이렇게 좋은 코드라는 신기루를 쫓는 일을 반복하게 되지 않을까 싶다.

레벨 2에서도, 레벨 3에서도, 더 나아가 실무자가 되어서도 말이다.

 

이 지난한 과정을 견디기 위해서는 마음가짐을 달리 먹을 필요가 있어 보인다.

좋은 코드라는 신기루에 닿는 것 자체를 목적으로 하면 머지않아 지칠 것이다.

그러니 그 여정 자체를 즐길 줄 알아야 한다.

새로운 개념을 익히고 시야를 넓히는 일 자체를 즐기고, 어제의 나보다 나아졌음에 감사할 줄 알아야 한다. 🚀

---

미션 2: 로또 🎱 [PR 바로가기]

로또

두 번째 미션은 '로또'이다.

로또를 구매하고 당첨 번호에 따른 당첨 결과를 볼 수 있는 프로그램을 만드는 미션이다.

step 1에서는 콘솔 기반으로, step 2에서는 웹 기반으로 만들었다.

 

미션 2의 학습 목표는 다음과 같다.

• 도메인/UI 분리
• 목적에 맞게 객체와 함수를 활용
• 단위 테스트 기반 점진적인 리팩터링

 

내가 집중했던 학습 주제는 다음과 같다.

• TDD
• 객체지향 프로그래밍
• DOM
• Event
• 불변성 유지
• SPA with 바닐라 JS
• 옵저버 패턴

 

서로 다른 두 사람이 하나의 결정을 내리는 일

미션 2에서는 페어와 논의하는 과정에서 어려움을 겪었는데, 이로부터 큰 깨달음을 얻을 수 있었다.

나는 코드의 가독성과 유지보수성을 최우선으로 생각하는 편이었다.

더군다나 당시에는 객체지향 프로그래밍에 관심을 갖기 시작했던 터라 그런 성향이 더 강했다.

반면, 내 페어는 유지보수성보다는 성능을 개선하는 일에 큰 가치를 두었다.

평소에 취미로 알고리즘 풀이를 즐길 정도로 알고리즘 최적화에 관심이 많았다. 🧑🏻‍💻

 

이렇게 '좋은 코드'에 대한 근본적인 기준 자체가 다르니 많은 결정에서 의견이 갈렸다.

예를 들면, 로또를 생성하는 로직을 만들 때 나는 읽기 좋은 방식을 선호한 반면, 페어는 연산 비용을 최소화할 수 있는 방식을 선호하는 식이었다.

이뿐만 아니라 다른 결정을 내리는 데에도 의견이 번번이 갈리다 보니 논의하는 데 서로 에너지를 많이 쏟게 되었다.

 

결국 우리는 서로 완전히 만족할 수 없다는 사실을 인정하고 타협을 했다.

일부의 로직에 대해서는 내가 선호하는 방식을 채택하고, 일부의 로직에 대해서는 페어가 선호하는 방식을 채택했다.

그렇게 서로의 DNA가 반씩 섞여 들어간 결과물을 만들게 되었다.

페어가 워낙 유쾌한 성격을 가졌던 터라 과제를 해나가는 과정은 즐거웠다.

하지만 페어와의 논의가 주로 가장 좋은 하나의 방안보다는, 둘 모두 적당히 수용할 수 있는 타협안을 찾는 방식이 된 것 같아 아쉬움이 남기도 했다.

 

이 경험으로부터 나는 두 가지 깨달음을 얻었다.

1. 결정을 위한 공동의 기준을 먼저 세우는 것이 중요하다: 같은 목적지를 향해 나아가야 한다면 공동의 의사결정 기준을 세우는 게 중요하다. 그렇지 않으면 사소한 결정에서 반복해서 소모적인 대화를 하게 될 가능성이 크기 때문이다. 앞으로의 의사결정의 근간이 되는 주제들에 대해 충분히 대화를 나누며, 이후 의사결정의 근거가 되어줄 공동의 기준을 잘 세워야 한다.
2. 팀원과 의견이 부딪힐 때는 개인적 의견/주장보다는 공동의 기준에 입각해 생각하고 판단하자: 나는 미션 2에서 페어에게 유지보수성을 택하자고 설득하기 위해, 내가 생각했을 때 유지보수성이 성능보다 더 중요한 이유에 대해서 늘어놓았다. 이에 대해 페어는 자신이 생각했을 때 성능이 더 중요한 이유들을 설명하며 반론했다. 지금 생각하면, 내가 페어의 입장이었어도 나의 주장에 설득되지 않고 반론하게 됐을 것 같다는 생각이 든다. 왜냐하면 논의가 개인 의견 대 개인 의견으로 부딪히는 양상이었기 때문이었다. 하나의 정답이 없는 문제이며, 두 주장이 모두 합리적이었기 때문에 서로 상대의 주장에 설득되기 어려운 상황이었다. 그 상황에서 공동의 기준으로 합의된 사항에 기반하여 논의가 이뤄졌다면 진전이 있지 않았을까 생각이 든다. 예를 들어 그 당시에는 둘만의 공동 기준은 없는 상황이었으니, LMS(우테코 학습 시스템)에 나와 있는 학습 목표를 근거로 삼았다면 논의가 더 잘 진전되었을 것 같다. 학습 목표는 우테코 크루라면 이미 어느 정도 수용하기로 한 기준점이기 때문이다. 앞으로는 논의 상황에서 개인 대 개인 간의 논쟁을 하기보다는 합의된 공동의 기준을 기반으로 판단하고 이를 근거로 삼자.

 

---

미션 3: 점심 뭐 먹지 🍔 [PR 바로가기]

점심 뭐 먹지

세 번째 미션은 '점심 뭐 먹지'이다.

음식점 정보를 등록하고, 음식점 정보를 조회할 수 있는 웹 프로그램을 미션이다.

이전에 비해 기능이 많고 구성이 복잡했다.

step 1, step 2 모두 웹 기반 프로그램이었으며, step 2에는 상세 조회, 즐겨찾기 추가, 삭제 등의 기능이 추가되었다.

 

미션 3의 학습 목표는 다음과 같다.

• 애플리케이션을 컴포넌트 단위로 모듈화 하여 개발
• TypeScript의 기본 문법 학습 및 필요성 경험
• 웹 UI 환경에서의 테스트 기초 (E2E 테스트)

 

내가 집중했던 학습 주제는 다음과 같다.

• 컴포넌트
• E2E 테스트 (Cypress)
• TypeScript
• 웹 컴포넌트
• 정적 렌더 vs 동적 렌더
• 이벤트 리스너
• 객체지향 프로그래밍 (도메인/스토리지 관련 역할 분리)

 

은탄환은 없다

미션 3에서는 기술적 의사결정의 본질적인 어려움을 겪으며, 모든 상황에서 정답인 은탄환 같은 결정은 없다는 사실을 배웠다.

미션 3으로 웹 앱을 구현하는 과정에서 자율적으로 결정해야 하는 사항들이 여럿 있었다.

전체 구조를 어떻게 설계할지, 어떤 방식으로 Element를 만들고 화면에 그릴지 등을 결정하는 일이 모두 내 몫이었다.

어떻게 해도 기능 상으로는 동일하게 구현할 수 있지만, 기술적인 측면에서 차이가 있었다.

 

createElement vs innerHTML

예를 들면 createElement() + append()와 innerHTML 중 어떤 것을 사용할지 고민이 되었다.

createElement()를 이용하면 XSS 공격에 대비할 수 있고 성능 상 이점이 있었다.

동시에 코드가 절차적인 형태가 되어 가독성이 떨어진다는 단점이 있었다.

반면 innerHTML을 이용하면 직관적인 코드를 작성할 수 있어 가독성 측면에서 이점이 있었다.

동시에 XSS 공격에 노출될 수 있고, 상대적으로 성능이 떨어진다는 단점이 있었다.

 

나는 고민 끝에 innerHTML을 선택했다.

innerHTML을 사용했을 때 생산성이 높고 가독성이 좋아서, 미션의 학습 목표에 집중하기에 더 유리하다고 판단했기 때문이다.

한편으로 XSS 공격이나 성능 측면에서 아쉬움이 생겼다.

하지만 현재 상황을 고려했을 때 당장 이런 점들이 큰 문제가 된다고 생각하지 않아 내 생각을 밀고 나갔다.

 

다른 크루들의 PR을 살펴보니 innerHTML 사용에 대해 지적을 받은 경우가 종종 있었다.

앞서 이야기한 innerHTML의 단점 때문이었다.

어느 정도 예상하긴 했지만, 현직자 리뷰어분들이 그런 피드백을 남기신 것을 보니 마음이 조금 흔들리기도 했다.

 

깨달음

구현 방법은 수없이 많다.

그중 어떤 것을 택해도 된다.

그런데 동시에 그중에서 완벽한 선택지는 아무것도 없다.

 

모든 건 트레이드오프의 문제이다.

A를 택하면 B에서 아쉬움이 생긴다.

반대로 B를 택하면 A에서 아쉬움이 생긴다.

그러니 A를 택하든, B를 택하든 완벽한 선택이 될 수 없으며, 동시에 둘 모두 완전히 틀린 선택지도 아니다.

 

이러한 특성상, 개발 영역에서의 의사결정은 상당히 어렵게 느껴진다.

사실 개발뿐만 아니라 비즈니스든 기획이든 디자인이든 크게 다르지 않을 것이다.

이런 정답이 없는 상황에서 어떻게 살아남을 수 있을까?

결정을 내린 나만의 확실한 이유가 있으면 된다.

 

동료로서 신뢰받지 못하는 사람은 완벽한 결정을 내리지 못하는 사람이 아니다.

신뢰를 받지 못하는 사람은 아무런 고민 없이, 아무런 주관 없이 안일한 결정을 내린 사람이다.

결과적으로 옳은 결정이었을지라도 충분한 고민이 없었다면 납득되기 어려우며 성장할 수 없기 때문이다.

반면 결과적으로 옳지 않은 결정이었어도, 충분한 고민이 있었다면 납득될 수 있으며 그 고민으로부터 성장할 수 있기 때문이다.

 

또한, 자신이 선택한 선택지 외의 선택지에 대해서도 충분히 공부하여 알고 있어야 한다.

중요한 건 내 선택지가 받아들여지는 게 아니라, 최선의 결정을 내리는 것이기 때문이다.

내 선택의 근거를 보충하기 위해 고민할 게 아니라 정말 최선의 선택지가 무엇인지 충분히 고민해야 한다.

자신이 선택한 선택지 외에는 어떤 선택지들이 있으며 각 선택지의 장단점은 무엇인지 잘 알고 있어야 최선에 가까워질 수 있다.

 

의사결정에 완벽한 정답이란 있을 수 없다.

하지만 내 의사결정에는 충분한 이유와 고민이 있어야 한다.

---

미션 4: 영화 리뷰 🎬 [PR 바로가기]

영화 리뷰

네 번째 미션은 '영화 리뷰'다.

TMDB의 공공 API를 통해 영화 목록을 받아와 영화 정보를 보여주는 웹 기반 프로그램이다.

step 1, step 2 모두 웹 기반이었으며, step 2에는 상세 조회, 별점 입력, 반응형, 무한 스크롤 등의 기능이 추가되었다.

 

미션 4의 학습 목표는 다음과 같다.

• API 연동을 위한 테스트 환경 경험
• 실제 동작하는 API를 통한 비동기 통신
• UX 경험 개선을 위한 더 보기(페이징) 구현
  

 

내가 집중했던 학습 주제는 다음과 같다.

• 비동기 통신
• 스켈레톤 UI
• 반응형 UI
• 객체지향 프로그래밍 (API, 스토리지 역할 분리 및 추상화)
• 사용자 경험 개선
• 실행 컨텍스트
• 이벤트 루프와 태스크큐 (비동기 함수 동작 방식)

 

유지보수하기 좋게 vs 당장 필요한 만큼

미션 4를 진행하면서, 오버엔지니어링하지 않고 필요한 만큼의 개발하는 일에 대한 고민을 할 수 있었다.

우테코에 들어오며 가장 기대하고 원했던 건, 유지보수하기 좋은 코드를 작성하는 방법을 터득하는 일이었다.

그리고 교육 기간 내내 유지보수성에 초점을 두어 학습하고 코드를 작성하려 노력하다 보니, 실제로 '좋은 코드'에 가까워지고 있는 듯한 느낌을 받았다.

그런데 유지보수성을 중시하다 보니 때로는 간단하게 처리할 수 있는 로직에 대해서도 과한 고민을 하게 되기도 했다.

 

유지보수성을 높이기 위해서는 단순히 잘 돌아가는 로직을 작성하는 것을 넘어서 다양한 요소를 고려해야 한다.

유연성, 가독성, 높은 응집도와 낮은 결합도 등을 모두 고려해야 한다.

당장의 요구 사항을 충족할 뿐만 아니라, 미래의 상황에서도 쉽게 수정하고 확장할 수 있어야 한다.

흔히 프로덕트를 유지보수하는 일을 달리는 차의 바퀴를 갈아 끼우는 일에 비유하곤 한다.

그냥 달리기만 하는 차보다는 달리면서 바퀴를 쉽게 갈아 끼울 수 있는 차를 만드는 일이 훨씬 어렵지 않겠는가.

그래서 유지보수성을 1순위로 고민하는 나로서는 요구 조건이 크게 어렵지 않아도 과제를 완성하는 일이 어렵게 느껴졌다.

동일한 기능을 만들더라도 투입해야 하는 시간과 노력의 양이 훨씬 많았다.

 

이는 크게 두 가지 측면에서 우려가 됐다.

첫째, 1순위로 지켜져야 할 데드라인을 지키지 못할 가능성이 높아졌다.

개발자라면 마감기한 내에 주어진 요구사항을 충족시키는 것을 1순위로 두어야 하는데, 이를 지키지도 못하면서 유지보수성을 논하는 것은 잘못이라 생각한다.

둘째, 학습 목표에 대한 집중도가 비교적 낮아지게 되었다.

우테코의 교육 커리큘럼은 코치분들의 각고의 노력으로 탄생했다.

그만큼 교육의 효과를 극대화하기 위한 의도들이 곳곳에 녹아 있다.

그런데 이 학습 목표를 충실히 이행하지 못한다면, 그 훌륭한 커리큘럼에서 충분히 배울 수 없게 된다.

 

이러한 이유로 인해 유지보수성을 얼마나 타협해야 하는지에 대해 내적갈등하는 일이 빈번했다.

유지보수하기 좋은 코드에 대해 많은 시간을 들여 고민하면서도, 이렇게까지 하는 게 맞는 건지 의구심을 품어왔다.

이 고민에 대한 현재의 잠정적 결론은 '데드라인과 학습 목표 충족을 1순위로 둔 채, 유지보수성을 최대한 향상한다'이다.

 

결국엔 요구 조건을 지키는 일도, 학습 목표를 따르는 일도, 유지보수성에 대해 고민하는 일도 모두 챙기겠다는 이상적으로만 보이는 결론이 돼버렸다.

그런데 정말 아무리 생각해봐도 어쩔 수 없다.

그만큼 셋 모두 중요하다고 생각하고, 어느 하나도 빠뜨리지 않고 잘 지키고 싶은 것들이다.

유지보수성은 장기적인 관점에서 개발 생산성에 아주 큰 영향을 끼칠 것이라 생각한다.

그리고 유지보수성을 보는 눈을 기르는 일은 단기간에는, 그리고 의식적인 노력 없이는 절대 이루지 못할 것이라고 생각한다.

그렇기에 어떤 미션을 하든, 무슨 레벨에 있든 유지보수성에 항상 관심을 갖고 이에 대한 고민을 게을리하고 싶지 않다.

다만, 그럼에도 우선순위 상 데드라인과 학습 목표 충족이 1순위라고 생각하기에 이 둘은 꼭 먼저 챙기려 노력할 것이다.

 

이렇게 욕심이 많기 때문에 항상 머리가 아프고 힘든가 보다. 🙃

하지만 내가 이런 사람인 것을 어쩌겠는가.

욕심 내려놓기는 항상 실패해 왔으니, 그 욕심을 한번 잘 채워보자. 💪🏻

---

소감

올해는 상당히 바쁘고 시간이 눈 깜짝할 새 지나갈 것이라 예상했다.

그리고 예상처럼 레벨 1 기간은 언제 지나갔는지 모르게 금세 지나갔다.

우테코가 둘도 없는 훌륭한 교육 기관인 것은 맞지만, 성장에 대한 책임은 나에게 있다는 사실을 잊지 말자.

시간은 앞으로도 눈 깜짝할 새 지나갈 것이니 정신을 잘 차려야 한다.

 

나는 우테코에 들어오기 전 창업 팀에서 일하며, 좋은 코드보다는 의미 있는 결과물(성과)에만 초점을 뒀었다.

창업 과정에서는 아주 아주 잘 짜인 코드여도 성과를 만들지 못하면 아무 의미가 없었기 때문이다.

그래서 좋은 코드에 대한 욕심은 버리고 실질적인 성과를 낼 수 있는 방향에만 집중했다.

그리고 실제로 어느 정도 성과를 만들어 내며 우리 팀의 성장에 기여할 수 있었다.

MAU는 3만 명 정도가 꾸준히 나오고, 월 거래액은 1~2억 원 사이를 왔다 갔다 했다.

내가 만든 프로덕트로 이 정도 규모의 성장을 지탱할 수 있다는 사실에 큰 효능감을 느꼈다.

 

그런데 성장의 규모가 커져 성능/유지보수성이 중요해지는 시점에, 나는 개발 능력의 한계에 직면했다.

시간을 더 들여서라도 안정성을 챙기는 게 중요한 시점임에도 좋은 코드를 작성할 수 없었다.

애초에 내가 좋은 코드를 작성할 수 없었던 건, 시간문제가 아니라 실력이 부족했기 때문이라는 사실이 드러났다.

프로덕트에 여러 기능이 붙고 복잡해지면서 기능 추가/수정 시마다 예상치 못한 오류에 시달렸다.

트래픽이 늘어나는 과정에서 서버가 터지고 결제 관련 오류가 발생하는 일이 잦아졌다.

이런 치명적인 문제들은 팀의 성과나 생산성에도 큰 영향을 주었다.

 

이런 과정을 겪고 스스로의 한계에 직면하며, 크게 두 가지의 아쉬움을 느꼈다.

 

첫째, 내가 개발로써 만들 수 있는 임팩트의 크기가 한정되어 있다는 사실에 큰 아쉬움을 느꼈다.

트래픽과 거래액 규모가 아주 미미할 때는 기술력의 중요도가 높지 않았다.

잘 짜인 코드와 못 짜인 코드가 만들어 내는 차이가 그리 크지 않았기 때문이다.

그런데 규모가 조금씩 커질수록 자연스레 코드 퀄리티로 인한 격차가 표면으로 드러나게 됐다.

개발자로서 내가 지탱할 수 있는 성장의 규모가 내가 가진 기술력에 어느 정도 비례한다는 사실을 점점 깨달았다.

동시에 내가 개발자로서 발휘할 수 있는 임팩트의 크기가 한정되어 있다는 사실을 느꼈다.

 

둘째, 개발 공부에 대한 갈증을 해소하지 못해 아쉬움을 느꼈다.

처음 개발에 관심을 가지게 됐던 건 개발이 지닌 잠재력 때문이었지만, 점점 개발 자체에 대한 호기심과 재미를 많이 느꼈다.

기술 이해에 깊이를 더하고 기술을 더 잘 활용할 수 있게 되는 과정 자체가 즐거웠다.

그런데 창업 과정 동안은 여러모로 개인의 개발 공부에 높은 우선순위를 둘 수 없는 환경이었다.

더 좋은 코드를 짜기 위한 공부를 하고 싶지만 그러지 못하는 상황에 아쉬움을 느꼈다.

 

반면, 우테코는 개발 공부에만 온전히 몰입할 수 있는 환경이다.

성과를 배제한, 코드만을 위한 고민이 어느 곳보다 환영받는 환경이다.

창업 과정과는 반대로 결과물이 아무 데도 쓰이지 않을지라도 좋은 코드만으로 의미가 있다.

 

우테코에서 프로그래밍 공부에 너무 시달려 도망치고 싶은 순간이 찾아온다면 지난 창업 과정을 떠올려 보자.

개발 실력의 한계로 고통을 겪던 그 시기, 스스로의 한계에 직면했던 그 시기를 떠올리자.

개발 공부를 하고 싶어 바쁜 와중에 짬짬이 시간을 내려했던 그때를 떠올리자.

또, 지금의 지난한 과정이 미래에 직면할 어려움 속에서는 든든한 버팀목이 되어줄 것이라는 사실을 떠올리자.

 

개발하느라 힘든가?

과거의 나는, 그리고 미래의 나는 분명 지금의 나를 누구보다 부러워하고 있을 것이다.

이 사실을 떠올리며 그들을 위해 내가 할 수 있는 최선을 다해보자! 🚀