Hello_Ian

[이 글을 쓰게 된 계기]

---

 

나는 개발 비전공자이다.

 

최근 '원티드 - 12월 커리어 킥오프 이력서 부수기'를 들었다.

기존 경력과 개발 경력 사이의 연결성을 포기하지 말라는 말에 기억을 더듬다가

호텔에서 보낸 시간과 경험을 다시 분명히 기억하고 싶어 글을 적게 됐다.

 

[약 3년 3개월 간 호텔에서 해결한 문제들]

---

Lv.0 호텔리어

-> 내 원래 전공은 '관광학과'이고, 운 좋게 교직이수를 하여 관광 정교사 2급 자격증을 가지고 있다.

학교를 졸업하기 한 달 전쯤, 마찬가지로 운이 좋게 호텔리어 생활을 바로 할 수 있었다.

 

오픈한지 몇 달 안 된 호텔이었고, 나는 막내였다.

호텔의 프론트데스크 직원은 OJT기간 체크인을 받지 못한다.

이 기간에 할 수 있는 것은 응대매뉴얼이나 객실 관리 시스템 매뉴얼 등의 문서를 외우는 일이나

프론트 데스크에서 선배들이 체크인 받는 것을 지켜보거나, 복사용지를 채우고 카드 단말기 빌지를 채우고,

볼펜을 정리하고, 데스크를 청소하는 등의 일을 한다.  

 

특급호텔 출신의 일 잘하는 선배님들 사이에서 부족했던 나의 첫 인상은 당연히 별로 좋지 못했다.

OPIC - 'AL'을 가지고 자만했던 내 영어 실력은 현지 유학을 다녀온 선배님들 성에 차기엔 부족했고,

조금은 폐쇄적인 시스템과 분위기는 날 더 주늑들게 했다.

 

초반엔 실수도 많이 했고, 혼나기도 많이 혼났다.

데스크를 닦으며, '내가 이러려고 호텔에 왔나' 생각하기도 하고,

객관적으로 잘못한 사람은 위로를 받고, 사고를 수습한 사람은 납득하기 어려운 이유로 혼이 나는 모습을 보며

마음이 많이 흔들리기도 했다.

 

책임질 사람이 명확하지 않아 책임질 방법을 스스로 생각해야내는 때도 있었다.

 

내 커리어 첫 시작 연봉은 '2000만원'이었고, 나는 그 돈에 기뻐하며 계약서에 싸인했었다.

 

첫 사회 경험 시작은 생각만큼 달콤하지는 않았다.

 

Lv.1 호텔리어

-> 내가 일했던 호텔은 장사가 정~말, 정~~말 잘 되는 호텔이었다.

 

여러 가지 특수성이 결합돼서 여름이면 각 기업에서 휴가를 왔고,

봄 가을엔 커플과 인바운드 고객이 찾았다. 겨울엔 쉬는 날이 많고 날이 추워서 방문객이 많았다.

 

최대 약 700~800명이 수용되는 객실 점유율 평균 60%, 공휴일 만실, 주말? 만실, 성수기? 만실

나는 반드시 성장해야하는 상황이었다.

갑자기 각성하는 소설 속 레벨업은 존재하지 않았다.

 

개인적인 욕심으로는 팀에게 해를 끼치고 싶지 않았고,

팀적으로는 1명의 구멍이 퇴사 의욕을 만들어냈다.

 

열심히 잘 웃고, 최대한 친절하려했던 내 노력의 보상이었는지 4개월째의 어느 날 나는

연봉 20%가 상승한 계약서에 싸인했다.

 

내가 이 시기에 가졌던 마음 가짐은 다음과 같다.

 

1) 내가 할 수 있는 것과 할 수 없는 것 분리하기

->

[1개월 차]

할 수 있는 것: 물품 딜리버리, 객실 내부 문제, 데스크 청소, 체크아웃, 객실 카드 관리, 작은 컴플레인 응대

할 수 없는 것: 결제와 전산 처리, 체크인, 예약 생성, 객실 배정

 

2) 할 수 있는 것은 어떻게 하면 더 잘 또는 더 깊게 할 수 있는지 고민하기

-> 예시

객실 내부 문제: 문제 발생 빈도 높은 케이스 별로 정리하기(공통 비밀번호, 리모콘 매칭 방법)

딜리버리: 인사 멘트와 목소리톤 상황 별 정리(여고객, 남고객, 커플, 가족, 어른), 서있는 위치, 시선 방향, 노크 횟수 등 디테일 고민

 

3) 할 수 없는 것은 왜 할 수 없고, 어떻게 하면 잘 할 수 있는지 배우기

-> 예시 

결제와 전산 처리:

이유) 복잡한 케이스를 완전히 숙지하지 못함

방법) 매뉴얼보고, 생각하고, 그럼에도 모르겠으면 정리해서 질문하기 

 

객실 배정:

이유) 선배들이 믿지않음

방법) 배정할 때 옆에서 지켜보면서 궁금한 점 묻고, 메모하기

 

4) 고객에게 늘 웃고, 무엇이 필요한지 먼저 생각하고, 조금 더 친절하게 응대하기

짐이 많은 고객: 문 밖 이동 - 인사 - 열어드리기 - 입장 도움 필요한지 여쭈고, 필요하다면 3개 이상 = 카트 | 2개 이하 대신 들어드리기

Detail

체크인 전)

문 닫음 - 고객보다 살짝 느리게 걸으면서 데스크 도착 - 동선 방해하지 않게 고객 뒤편으로 짐 이동 - 오른쪽 대기

체크인 후)

뒤도는 순간에 맞춰 짐쪽으로 이동 - 눈 인사 - 거절하는 경우 아니면 엘레베이터까지 살짝 뒤에서 이동 - 엘레베이터 먼저 잡기 -

고객 탑승 이후 가시는 층 여쭙기 - 버튼 누르기 - 고객 잡기 편한 위치로 짐이동 - 마무리 인사

 

5) 선배들 선에서 해결할 수 있는 실수만 하기

a. 선배들 보며 실수하는 케이스 메모

b. 실수를 하면 객관적으로 작은지 큰지 판단

c. 판단이 안 됨 -> 즉각 실수 내용과 해결 법에 대하여 질문 또는 보고

d. 판단이 됨 ->

d1. 작은 건: 실수 내용 정리, 뒷 수습 후 질문 또는 보고

d2. 큰 건: 즉각 정리 보고

 

5-1) 그러나 돈 관련 실수는 절대 하지 않기

그러나 발생 시 대처에 대해서는 고민을 정말 많이 했다.

내 착오로 인한 결제 실수: 케이스 별 해결 법 정리

타인의 착오로 인한 결제 실수: 5번으로 이동

 

Lv.?? 호텔리어와 대재앙

[내가 해결할 수 없는 재앙들]

-> 위의 마음가짐을 더하고 빼다보니 시간은 빠르게 흘렀다.

새 해 첫 날 2명이서 근무하는 체크아웃 피크시간에 기계식 주차가 고장이 나는 경우나

한 겨울 만실 날 갑작스런 난방기 이상으로 객실 반절이상 히터가 고장나는 경우 등을 겪으며 나름 1년차 호텔리어가 되었다.

이쯤의 배정 관련 디테일은

2~3일 내 객실 가동률, 예약 사항 파악하여 우선 순위(연박, 일행, 단체, 기념일, 선호 등)고려까지 변화해있었다.

 

1년 동안 개인적인 성장의 디테일을 깎아나가다보니 이젠 팀으로 눈을 돌아가기 시작했다.

생각했던 것보다 사람들과 정이 많이 쌓여서, 이 사람들이 나로인해 조금이라도 더 편하게 일했으면 좋겠다는 생각을 했다.

 

시야가 점점 넓어지면서 문제는 내가 해결하지 못하는 것과 해결할 수 있는 것으로 나뉘기 시작했다.

대재앙의 시작이었다.

[대재앙 목록]

1) 100객실 이상 온수 사용 시 온수 온도 급감

원인: 보일러 설비적인 문제

대처법: 시설팀에게 이슈 전달

해결법: 주보일러 하나 더 설치

 

2) 주차

원인: 법적효용 댓수에 딱 맞는 주차장 보유

대처법: 이중주차, 인근 무료 주차 공간 안내 등

해결법:

a. 주차장 증설

b. 인근 주차장 섭외 -> 발렛 직원 필요

 

3) 냉난방기 소음

원인: 날씨 추우면 나는것으로 추정, 불특정 객실 또는 복도 발생

대처법: 시설팀 이슈 전달, 객실 교체 또는 층 교체

해결법: 냉난방기 점검 및 교체

...

 

그렇다.

 

대재앙은 호텔이 지어질 때부터 생겼거나 설계적인 문제로 인해 발생해서 개인이 어떻게 할 수 없는 문제들'처럼' 보였다.

 

선배들은 이미 저 문제들에 대해서 생각하고, 고민하기를 포기한 상황이었다.

시설 팀분들은 문제를 궁금해하는 나를 달가워하지 않으셨다. 

 

1)의 경우 제어실에서 보일러 온도가 너무 이상해서 시간 별로 기록하는 것을 부탁하거나 시스템에 대해 질문할때도, 

3)의 경우 소리를 녹음하고, 소리가 나는 지점을 파악해서 정리해서 전달할때도,

'원래 그래요.', '~~때문이라 어쩔 수 없어요' 등의 말을 들으면 내가 이상한 사람이 되는 기분이었다.

시설팀의 일을 궁금해하는 프론트데스크 직원은 지금생각하면 충분히 이상한 사람이 맞긴 하다.

 

그저 나는 팀원들이 스트레스를 받고, 해결하지 못할 문제들로 욕을 먹는 상황을 지켜보는 것이 힘들었다.

 

간곡히 부탁해서 점검받은 보일러는 보일러 이상이 맞았다. 지하에 설치된 펌프 쪽에 문제가 있었다.

주보일러 설치가 아니라 보조 보일러로 설치하면 예상 예산보다 3배는 더 저렴하게 해결할 수 있는 문제였다.

 

냉난방기는 내가 찍어서 정리하여 전달한 지점들의 고압, 저압 펌프가 반대로 연결되어 있었다.

몇 번의 방문으로 냉난방기는 거짓말 같이 조용해졌다.

 

그래서 조용히 다짐했다.

 

아 이거, 재앙을 해결 못하면 팀원들을 조금이라도 더 편하게 해줘야겠다고

[스트레스를 줄이는 시스템 구축]

호텔 일을 하다보면 관리해야할 문서가 정말 많다.

수기로 적어야하는 것도 많고, 여기저기 데이터가 흩뿌려져있기도 하다.

관리해야할 OTA 계정들을 예약실에 물어보고, 전달받아야하는 경우도 있다.

코드를 치고, 프로그램을 짤 수 있었으면 정말 좋았을텐데 불행히도 이때의 나는 그럴 능력이 없었다.

그래서 내 나름대로 문제를 정의하고 분류하고 고민하기 시작했다.

 

1) 로그북, LOST and Found List 등 수기 작성 서류

불편한 점:

a. 오래된 기록을 찾기가 힘듦.

b. 글씨를 못쓰는 사람의 기록을 읽기가 힘듦.

c. 특정 서류는 처리 과정에서 타이핑과 수기를 번갈아가면서 해야함.

d. 손글씨를 써야함.

...

예상 해결법:

1. 관리 시스템 내 메모 사용 -> 스킵하는 직원이 있거나 누가 알림을 꺼버리면 대응할 수 없음.

2. 엑셀 파일로 정리 -> 관리해야할 엑셀 파일이 지속적으로 증가함. 이미 프론트 내부 엑셀파일이 많음.

 

2) OTA 어카운트 관리

불편한 점:

a. 예약실 퇴근 이후 대처 어려움.

b. 계정 관련 엑셀 시트를 매 월 받아야함.

c. 예약실 업데이트 시 즉각 전달이 안되는 경우 일에 지장이 생김.

...

 

열심히 'G'선생님을 찾던 와중에 문득 그런 생각이 떠오른다.

 

"아 그냥 'N'이나 'G' 같은 플랫폼 계정으로 동시에 3개 로그인하면 어떨까"

 

'G'사 계정을 파서 테스트해보니 북마크, 로그인이 유지가 되는 것을 확인한 나는

객실 팀장님과 예약 실장님 컨펌하에 세 컴퓨터에서 예약실 계정 로그인 -> 계정 동기화를 클릭하여 2번 문제를 해결했다.

 

그리고, 이 일을 빌미로 팀장님과 선배들에게 이런 저런 문제점으로 이번엔 수기 문서들을 전자 문서들로 대체하고 싶다고 설득했다.

 

사실  '구글 스프레드 시트'를 사용해서 혼자서 형태는 만들어놓은 상태였다.

첫 페이지에는 내가 분류를 새로이 한 이유, 기존 문서가 가진 문제점들을 적었다. 그리고 새로이 분류된 문서들의 시트 링크를 넣었다.

두 번째 페이지에는 내가 호텔에서 일하며 겪은 문제들의 종류 그리고 해결법이 적힌 시트 링크를 넣었다.

세 번째 페이지에는 호텔에서 자주 연락해야하는 업체들의 연락처가 적힌 시트 링크를 넣었다.

 

후배들은 시트들을 보자마자 찬성했다.

선배들은 우려되는 문제점들에 대해 물어보았고, 질문에 대한 내 대답을 듣고는 찬성했다.

팀장님은 긍정적으로 생각해보신다고, 완성을 장려하셨다.

 

이렇게 문제들을 마주할때마다 어떻게든 해결하다보니 퇴사즈음에 나는 처음과는 다르게

사람들이 꽤 좋아하는, 믿을 만하다는 이야기를 듣는 직원이 될 수 있었다.

 

진짜 대재앙 '코로나'

서비스나 외식산업에서 코로나는 정말 힘든 시간이었다.

호텔에서의 퇴사는 조금은 당연한 수순이었고, 시간을 보내던 중 인연이 닿아 '코로나 임시 격리 시설'로 사용되는 호텔에서 일하게 된다.

 

매일 자정이 되면 방호복을 입고, 프론트데스크로 내려가서 마감을 돌려야하는 상황에는 '구글 원격 데스크톱'으로 본부 컴퓨터와 프론트 컴퓨터를 연결하여 원격에서 마감을 돌릴 수 있게 하였고, 밝힐 수 없지만 동일한 내용을 여러 개의 부처에 문서 형식으로 나뉘어진 문제나 매일매일 수기로 기록하는 현황판을 파이썬을 통해 만들어보다가 결과물 완성도에 좌절하는 경험도 겪었다.

여러개의 인증 어플로 인한 혼란이나 각 종 문제들이 누군가의 코드로 해결되는 것을 바라보면서 생각했다.

 

이거, 코드를 칠 줄 알면 문제를 해결하기 더 좋겠다  

 

[마치며]

---

글에는 미처 적지 못한 여러가지 운과 상황이 겹쳐진 선택과 결과이지만 대학 졸업 이후 약 5년 간 난 이런 삶을 살았다.

"이력서에 호텔에서 이런 문제들을 해결했고, 소통하기 위해 팀을 위해 이런 것을 했어요."를 적기 위해서 시작한 글이 생각보다 많이 길어져서.. 이력서에 이걸 어떻게 써야할지 모르겠지만, 그래도 이 글을 통해 내가 다시 깨닫게 된 것은

 

나는 문제를 해결하는 것을 좋아하는 사람이라는 것과 생각보다 운이 많이 좋았다는 것이다.

 

상황에따라 선택할 수 있는 답지가 제한되는 경우도 있을 것이고, 내 행동이 선을 넘었을 경우도 분명 존재했을 것인데 좋게 받아준 사람들 덕분에 그 와중에도 조금 괜찮은 선택을 할 수 있었다는 것을 늘 잊지 말아야겠다.

 

아, 선배님들은 다 좋은 사람들이다.

여기에는 적을 수 없지만 인간적으로 성장하는데에 도움이 됐고, 퇴사 후에도 간간히 연락하며 지낸다.

내년 이맘은 조금은 더 행복할 수 있기를

[첫 직장, 첫 프로젝트 싸이클에서 고민했던 것]

---

원티드 12월 챌린지 사전 과제를 위한 아주 짧은 요약글은 
이쪽

 

원티드 12월 챌린지 사전 과제 | Built with Notion

비즈니스 로직이 들어간 첫 프로덕트에서 마주한 것들

cheddar-appeal-ee8.notion.site

 

1. 내가 바랬던 것들의 문제점

---

내 첫 직장은 스타트업이었다.
지금은 사업이 어려워져서 퇴사한 상태이지만, 취업 당시에 해당 회사를 선택했던 두 가지 큰 이유는

1) 자체 서비스를 가지고 있고, 이미 각 스토어에서 서비스를 하고 있다.

2) 내가 프론트엔드를 처음부터 끝까지 맡아서 팀과 진행해볼 수 있다.

였다.

 

12월 챌린지에는 짧게 정리했지만 정말 많은 고민과 많은 문제를 마주 했었다.

1)에서 이야기한 서비스는, 입사 당시엔 내가 실물로 본 첫 프로덕트 레벨의 코드였다고 생각했고 수준이 정말 높다고 생각했다.

1개월 쯔음 지났을때 이전 담당자의 코드 구조에 익숙해졌을 즈음엔 그 안에 해결하지 못한 문제들이 조금 많다는 것을 깨달았다.

 

그 당시에 내가 정의했던 문제들은 다음과 같다.

 

1. 개발 당시에 요구했던 사항들이 문서화 되어있지 않고, 피그마에 흩뿌려져 있다.
-> 이로 인해 코드에서 시간에 쫒겼다는 느낌을 받았다.
2. 코드에 주석이 달려있지 않다.
-> 1번과 맞물려서 코드의 전반적인 흐름을 따라가는 것이 조금 힘들었다.
3. 코드 & 디렉토리 구조 컨벤션이 없다.

-> 1, 2번과 맞물려서 내가 코드를 추가, 변경할때 흐름을 일관적으로 유지하기 힘들었다.
4. 여기부터는.. 기능적이거나 구조적인 문제라 생략!

 

A1. 그래서 나는?

---

내가 결정하고, 지키고자 유지했던 것들은 다음과 같다.

 

1. 코드를 작성하기 전에, 전체적인 흐름을 설계하자.

-> 예외처리나, 세부 사항에 대한 구현 전에 큰 틀을 그리자.

 

2. 리액트를 사용하니까, 리액트 답게 코드를 구성해보자.

-> 모임에서 사용했던 구조를 조금 변화시켜서
Screen(Page) -> Viewer(Renderer) | State | API | Function | Custom hook | Interface(type) 로 나누기로 했다.

Page: url endpoint와 매칭되는 상위 컴포넌트
Viewer: data를 받아서, JSX를 리턴하는 컴포넌트
State:

서버 사이드(출처가 backend인 데이터를 위한 상태 ex, user) = react-query(tanstack-query)

클라이언트 사이드(출처가 frontend인 상태 or storage에 write | read 해서 전역으로 써야하는 상태 ex, modal open) = jotai

지역 상태(page에서 사용되고, 소멸되는 상태 ex, userInput, isValid)

API: baseurl - url endpoint를 위한 전역 인스턴스, token을 관리할 인터셉터 = axios 

Function: 데이터를 받아, 데이터를 조작하고, 조작된 데이터를 리턴하는 함수

Custom hook: 외부 라이브러리나  react hook과 function을 이용하여 한번 더 추상화한 컴포넌트, page에서 호출해서 사용

Interface(Type): 서버에서 받은 data object나 컴포넌트 프로퍼티로 전달될 오브젝트를 정의한 것

이유?
1) 가장 근본적으로 UI | Control logic 분리 -> Data 구조를 위한 구조체를 분리하고 싶다(MVC) -> View를 위한 Logic이 필요하다. -> MVVM을 하기엔 프로젝트 규모가 그정도는 아니다.

2) 리액트는 Flux패턴이다.
3) 사람이 유지보수하기 편하게 코드를 구성하자.

고민?

1) 컴포넌트 깊이가 깊어지는 것과, 코드의 line이 늘어나는 것 중 어떤 것이 더 가독성에 좋지 못한가?
2) 내가 정한 구조가 타당한가? 리액트스러운가?
3) 3주의 시간을 들여 완전하게 재설계하는 것과 3시간의 임시 방편 중 어떤 것이 옳은 선택인가?
4) 리팩토링을 위한 시간을 확보할 수 있는가?
5) 객관적으로 가독성이 높다는 것은 어떤 것인가?

 

3. 복잡한 HOC에는 flow, case, return, parameter에 대한 주석을 달자.

[남아있는 것들에 대한 이야기]

---

1. 원티드 12월 챌린지 - 비즈니스 로직 1주차

 

1-1)에서 제공한 것

-> 실제로 초반 부에 리액트를 또는 자바스크립트를 배우면서 할 수 있는 대표적인 실수들
(컴포넌트 크게만들어서 의존성 높이기, 컴포넌트 분리하면서 깊이 늘리기 등)을 사례로 공유하면서,

컴포넌트를 분리할때 최소한의 기준인 [데이터 - 액션 - 계산]으로 분리하는 방법과 이유에 대해서 배운다.
순수함수, 사이드 이펙트, 클로저, 옵저버 패턴, 리덕스 이야기는 덤이다.

(덤인데, 꽤나 근본적이고 직관적이게 설명돼있다.)

1-1)에서 느낀 것

내가 일을 하며 코드를 나눌때 가장 고민했던 포인트 중의 하나의 대한 답이 되었다.

개인적으로 분기문에서 함수를 열면
1) 함수 호출 -> 종료 과정에서 인스턴스 생성
1-1) 1로 인한 깊이 증가(다른 파일을 들여다봐야함) - 인간 문제
1-2) 함수 재실행 시 인스턴스 재생성에 대한 비용(히든 클래스, 인라인 캐싱, 단순히 함수 열고 닫는 비용 등) - 기계 문제

이라는 이유들때문에 별로 선호하지 않았는데,

A1) 재사용성이 증가할 수 있다.(테스트 쉬워짐, 내 기준 3회 이상 중복되면 common으로 승격)

A1-1) 이름을 잘 지으면 오히려 명확하게 읽힐 수도 있고, 줄 수 늘어나는게 해석하기 더 어려워 진다.
A1-2) 요즘 엔진 성능 좋고, 리액트나 넥스트 또는 JS라이브러리에 따라 다르겠지만 단순 계산(크지 않다는 전제) 크게 성능적 영향을 끼칠 것 같지 않다.

[넥스트 '앱라우터'의 경우]

- RCC선언된 쪽에서 호출하여 bundle에 포함되어버림 = 최대한 적게 들어낼 수 있게 경계를 나누자

- RCC가 아니라면 번들 제외당해서 서버에서 직렬화해서 날라올 것 = 이미 분리할 수 있는 만큼 분리 된 것인지 재확인
등 프레임워크와 결합하여 사용할 경우를 깊게 생각 해보게 되는 계기가 됐고,

액션(외부에 부수효과) - 계산(인풋 -> 아웃풋의 순수함수)라는 경계선이 그어진 것 같아 만족스러웠다. 

 

1-2)에서 제공한 것

-> 프론트엔드 야근의 원인과 비즈니스 로직에 대한 정의, 개발자로서 성장을 위해 지녀야할 마음가짐
비즈니스 로직과 UI로직의 구분 기준, 마지막으로 둘을 격리하는 방법에 대해 집중한다.
예시를 통해 실재하게 만들 어떤 개념을 추상화하고, 이게 어렵다면 먼저 캡슐화를 통해 모호한 추상적 형태를 구체적인 형태로

가공해 나가는 과정을 공유한다.

 
단일책임원칙, 컴파운드 컴포넌트 패턴, 추상화.캡슐화|모듈화, 응집도, MVC패턴, 어댑터패턴은 덤이다.

 

1-2)에서 느낀 것

-> 나는 그동안 추출과 추상화를 혼합해서 개념화해놓았다는 반성을 했다.
내가 작성한 것이니 누구보다 잘 이해를 할 수 있다. 시간이 없다 등의 반성으로 그냥 단순 추출 작업을

추상화라고 합리화한 것은 아닌지 돌아보는 시간을 가질 수 있어 좋았다.
42서울에서, 그리고 '널널한 개발자'님의 강의로 CPP를 학습하며 했던 고민들을 다시 한 번 돌아보는 계기가 됐고,
특히 어댑터 패턴 같은 경우는 나도 모르게 그렇게 쓰고 있다는 것이 기뻤다.

아래는 강의 이후의 한 질문 글에 단 내 답변이다.

 

그리 대단한 내용은 아니지만, 조금의 도움이라도 됐으면 좋겠다는 생각에서 최대한 풀어쓰려고 해보았는데

다행히 도움이 되었다는 답변이 달려서 굉장히 기분이 좋았다.

 

2. 원티드 12월 챌린지 - 비즈니스 로직 2주차

 

2-1)에서 제공한 것

->개발자로서 툴벨트(남들은 아마도 툴박스라고 말하는)것을 만드는 것의 중요성과

대체되거나 사장되거나, 간과하는 기술들이 필요해질 수 있는 순간들을 예시로 도구를 선정하는 기준에 대해서 고민한다.

그리고 solid에 대해, 객체지향에 대해 고민하며 이전 강의에서 배운 개념과 solid의 원칙들을 연결한다. 

마지막으로 실제 코드에 적용하는 예시를 통해 그동안 알게 모르게 사용하고 있었던 것들의 존재를 인지하는 시간이다.
그리고 이것은 모두 좋은 구조를 설계하기 위함이다.

 

SOLID.SRP|OCP|LSP|ISP|DIP, IOC, renderprops는 덤이다.

 

2-1)에서 느낀 것

-> 꽤 예전부터, 클래스를 배워왔고 스스로 개념화하려고 노력했지만, 사실 객체 지향에 대해서 완전하게 이해하고 있지

못 한 것 같다. 특히 '솔리드'는 계속 보아도 머릿속으로 잘 들어오지 않는 개념이었다.

강의를 보고도 100%이해했다고 하기는 어렵고, 그동안 내가 학습하면서 알게 모르게 습득했던 것과 연결되는 기분이 들어서 조금 신기했다. 분명 경험을 통해 더 마주해보면, 더 매력적인 개발자가 될 수 있을 것 같았다.

Radix나 shadcn, headless ui는 매력적이었다.

 

2-2)에서 제공한 것

-> 좋은 개발자가 되기 위해서 가져야할 마음가짐, 특히 리액트를 벗어나서 사고하는 방식과 필요성에 대하여 이야기한다.

조금 더 자세하게는, 내가 만들어야할 Product 혹은 Service의 본질(Core)를 분리해내고 React의 본질적인 역할, 그러니까 View로서의 분리해내는 것의 의의에 대해 공부한다.

그리고 이전 세 수업에서 가지고 왔던 개념들과 앞선 개념들을 연결하며 가능성에 대하여 고민한다.

 

2-2)에서 느낀 것

-> 좋은 구조라는 것에 대해 인지하지 못했던 영역의 가능성을 엿본 느낌이다.

'class는 리액트에서 거의 사용하지 않는 방식이기때문에 낡은 기술'이라는 느낌과

'Type이나 Interface를 Typescript로 강제하면서 결국은 객체의 어떤 형태인 class로 돌아가는 것인가'라는 고민의 답안을 재정의할 수 있었다.

결국 중요한 것은 개발자의 의도이고, 이런 저런 도구(Tool)를 적재적소에 활용하는 것이 개발자의 역할이라는 생각을 했다.

내가 이전에 했던 고민들과 경험들이 완전히 잘못되거나 옳지 못한 것이 아니었다는 것에 대해 안도감을 느끼고,

돌아보았을때 굉장히 귀중한 자산이 될 것이라는 느낌을 받았다.

 

[마치며]

---

우선 아직 경력 4개월 언저리의 초짜 개발자가 쓰기에는 조금 무거운 주제일 수 있겠지만, 정말 많은 것을 생각해 볼 수 있는 6개월이었다고 생각한다.

회사가 재정이 어려워지면서 5일전에 갑자기 퇴사를 통보받는다던지, 그동안 이슈를 정리하고 보고했던 노션이 터진다던지 하는 일들이나 12월까지 오면서 있었던 개인적인 일들은 조금 힘들었지만

2년, 3년 뒤의 내가 바라봤을때 분명 의미 있는 시간이었다고 생각할 수 있도록 노력해야한다.
중요한 것은 팬시하고 멋진 기술이 아니라 그 기술을 선택한 이유와 과정이라는 것을 잊지 말아야겠다. 

마지막으로 좋은 강의를 제공해주신 원티드와 캡슐단 수장 오종택님 다시 한 번 감사드립니다.