[ WIL ] 5-2 잔디 구멍, 한달 적응기, 공부

벌써 내가 현 회사에 취업을한지 한달이 지났다. 신기하게도 시간은 빠르게 갔지만, 아직 1개월차밖에(?) 안됬다는 사실이 놀랍다.

 

우리 회사의 오프라인 행사 간 고객님이 작성해주신 방명록. 보고서 마음이 뭉클하면서도 뜨거웠다.

 

지난 한달동안 정말 많은 일들이있었는데, 너무 많아서 크게 정리해보면, 회사 오프라인 행사 참여, 신규 기능개발 참여, FastAPI 공부으로 정리할 수 있을 것 같다. 

• 회사 오프라인 행사 참여: 큐리어스 데이라는 우리 플랫폼의 첫 공식 오프라인 모임이 진행되었다. 입사 2주차에 진행되어, 생각보다 몹시 빠른 시기에 실제 고객을 만나고 고객의 목소리를 들어볼 수 있었다.
• 신규 기능 개발: 1주차부터 기능개발에 투입이 되었다. 역시 스타트업이라 그런지 바로 기능 개발에 투입될 수 있었다. 개인적으로 나는 이게 훨씬 좋고, 지난 한달동안 깊게 몰입할 수 있었던 것 같다.내가 개발한 기능은 출석체크 기능을 개발했고, 기타 버그 수정과 현재는 큰 프로세스 개선 개발 기획과 결제 관련 개발을 진행하고 있다.
• FastAPI 공부: 사실 FastAPI만을 공부한다는 것은 아니고, "FastAPI를 중점적으로 공부하고 있다."는 표현이 좀더 맞는 것 같다. 공부할 시간이 많이 줄어들어 정리할 시간이 많이 부족하지만, 내 개인 공부를 회사에 도움이 되는 공부, 그리고 회사일을 하면서 내 개인 공부에 도움이 되는 개발을 고민하고 있다. 나는 여전히 좋은 코드, 좋은 아키텍처에 대해 관심이 많다.

 

보통 금요일날 주간 회고의 초안을 작성하고, 일요일날 작성을 완성하는데 이번 한달동안에는 개인적인 일들이 이게 너무 힘들었다..(핑계..) 공부할 시간도 모자르다보니, 금요일엔 운동갔다 늦게까지 공부하고.. 토요일날 아침에 공부하고.. 이렇다보니 자꾸만 주간 회고를 못쓴채로 시간을 보냈다. (또 지난주엔 작성 중 날라간건 안 비밀.. 좌절..) 그리고 무엇보다도 무리(?)하다보니 건강이 갉아 먹히는 느낌도 나는것 같다. 

 

약 2년간의 매일 기록하던 잔디에 구멍이 났다. 흑흑..

 

피로가 많이 쌓이면서, 효율적인 공부를 해야겠다 + 컨디션 조절을 잘해야겠다 라는 생각이 정말 많이 들었다. 그래서 내가 정한 전략을 세워 보았다.

• 공부는 지금처럼 꾸준히 또 지속하지만, 강박을 갖지는 않는다.(수면에 영향을 굉장한 영향을 준다.)
• 필요한 공부는 카테고리로 분명하게 정리하고, 분할 정복해나아간다.(점점 키워가는것이 아닌 크기를 정해놓고 정복한다.)
• 회고는 공부보다 더 중요하다. 따라서 반드시 정리한다.(생각을 반드시 정리한다., 공부할 시간보다 아까워하지 않는다.)

특히 이번주의 금토는 내 2년간 단 한번도 허락하지 않은 공부 기록을 남기지 않은 날이다. 잔디를 심어야만 내 노력을 인정받을 수 있다는 생각을 내려놓았다.(일부 맞지만, 잘못되었다는 생각이 더 크게 들었다.) 근데 내 마음에 구멍이 난 것 같다.. (금토 모두 개발 공부, 독서를 한 날인데 외부 일정 때문에 기록을 못한게... 조금 아쉽다...)

 

하지만 가장 중요한 것은 회고다. 이제는 절대 양보할 수 없겠다는 생각을 하며, 주간회고를 작성해본다. 

 

구성

- 미션드리븐: 한달 적응기

- 공부

 

 

---

미션드리븐: 한달 적응기

 

미션드리븐에 입사(24.04.08)가 벌써 한달이 더 되었다. 시간이 흘러가는 느낌은 벌써 한달? 이고, 현재 팀원들과 지낸 시간을 고려해볼 때, 고작 한달? 이라는 생각이 든다.

 

어찌됬든 나는 미션드리븐에서 한달동안 내가 예상했던 것보다 훨씬 더 많은 경험을 할 수 있었는데, 크게 두가지 분류로 구분할 수 있을 것 같다.

• 신규 및 기존 기능 개발과 개선에 기여하였다.(출석체크, 기타 버그 수정)
• 큐리어스(담당 서비스)의 오프라인 행사에 참여하여 고객들을 직접만나 볼 수 있었다.
• 개인 업무 진행 간 필요한 부분, 앞으로 내가 해야할 부분에 대한 파악을 할 수 있었다.

 

신규 기능 개발 및 기존 기능 개발 개선

나는 신규기능 개발에 참여하기에는 한달 이상의 시간이 소요된 뒤 할 수 있을 것이라 예상했었다. 그러나 생각보다 상당히 빠른 시기(입사 1주차)부터 신규기능 개발에 투입될 수 있었다.

 

내가 개발한 참여한 출석체크 이벤트

 

내가 개발하게된 기능은 출석체크 기능이다. 이 기능은 초기 이벤트성으로서 개발을 하고, 이번 5월 동안하는 이벤트성 기능이다.  출석체크 기능의 기능적 요구사항을 간략하게 정리해본다면 다음과 같았다.

• 출석체크는 한번만 가능하다.(중복 출석체크는 불가능하다.)
• 출석체크 시 포인트가 적립되어야 한다.(포인트의 출처가 기존와는 달라야 한다.)
• 공유하기는 하루 3번 가능하며, 공유하기 시에도 포인트가 적립되어야하며, 출석체크와 구분되어야 한다.
• 출석체크 랭킹을 확인할 수 있어야 한다.

 

기능적 요구사항만 보았을 때는 정말 간단했다. 그러나 하나하나 조금더 깊게 생각해보았을 때, 생각보다 고려해야 할 사항들이 있었다.

 

 

1. 동시성 이슈: 횟수 제한(출석체크는 한번만 가능하다. 공유하기는 하루 3번 가능하다.)

1차원적으로 생각(단일 서버 구조)생각해볼 때는, 단순히  출석체크 시, 요청한 유저의 당일 출석체크 기록을 조회한 뒤 해당 결과에 따라 다르게 처리를 하면될 것이라고 생각했다. 그러나 우리 서비스의 아키텍처 구조에서는 분산환경이었기에, 반쪽짜리 방법이었다.(사실상 오답)

 

나는 이 문제를 개발을 다하고 나서 파악했다. 이를 식별한 뒤 바로 대엽님(CTO)님께 해당 사항을 공유했는데, 이 대화를 통해서 또 새롭게 많은 부분을 고민하고 배울 수 있었다.(feat. 트레이드오프)

 

이와 관련하여 스스로 회고를 진행하면서, 새로운 고민에 빠져들게 되었다. "개발에서는 발생할 수 있는 문제에 대해서 어떻게 대응해야 올바른(효울적인) 대응이 될 수 있을까?" 점점 어려운 고민이 늘어 간다.

 

 

2. 비즈니스 요구사항의 변경: 출석체크 랭킹 조회 시 조회 조건의 변경

이번 출석체크 기능은 1달동안만 진행되는 이벤트 기능이었다. 1달만 진행된다는 것이 가장 초점을 두고서 빠르게 만들고 고객에게 제공하는 것이 핵심이 되었다.(물론 정확한 기능을 제공하는 것은 당연하다.) 

 

이번 기능 개발을 진행하면서, "오버엔지니어링을 하지 않는다.", "현재 필요하지 않은 기능은 개발하지 않는다."를 계속해서 스스로 상기하며 개발을 진행했는데 예상보다 좋은 사용자 참여로 인해, 출석체크 기능의 고도화가 요구되기 시작되었다. (요구사항이 초기와는 다른 내용이 변경되거나 추가되기 시작했다.)

 

사실 비즈니스 요구사항의 변경은 Optional 한 부분이다. None일수도 있고, 있을 수도 있다.(글을 작성하는 지금, Optional의 무서움을 또다시 느낀다..) 새로운 비즈니스 요구사항이 추가(혹은 변경)되면서 나는 다양한 생각이 들었다. 그리고 많은 생각 중 가장 고민을 많이하게 된 생각은 "확장성을 고려한 설계"에 대한 고민을 좀 더 하게 되었다. 다른 말로는 "확장성과 오버엔지니어링의 차이 및 비교"에 대해서 많은 생각을 하게 되었다.

 

솔직하게 아직 확장성과 오버엔지니어링의 차이를 모르겠다. 확장성을 고려하다보면 오버엔지니어링이 되는 것 같고, 확장성을 고려하지 않는다면, 격변하는 비즈니스에 적응하지 못하게 되는 듯하고.. 어려운 것 같다.

 

 

 

큐리어스 데이: 담당 서비스 오프라인 행사 참여

큐리어스 데이 당시 시간표

 

지난 24.04.26~ 27 우리 서비스의 첫 오프라인 행사가 열렸다. 당시 나는 입사 3주차였는데, 생각보다 엄청나게 빠른 시기에 실제 고객분들을 만나보고 이야기를들어볼 수 있었다. 

 

솔직한 마음에서는 많이 부담이 됬었다. 해당 행사에서는 신규 유저분들도 많이 참여해주셨지만, 헤비유저분들이 압도적이었다. 그리고 이에 대해 어쩌면 나보다 우리 서비스를 더 알고 계신분들이기에 문의가 왔을 때, 내가 직원으로서 잘 해낼 수 있을까? 하는 불안감이 많이 생겼었다.

 

결론적으로는 내가 우려했던 내용은 전혀 없었고, 오히려 고객들의 진심 가득한 피드백을 받아 볼 수 있었다. 특히 운영과 관련한 피드백이 가장 기억에 남는데, 운영과 관련된 내용에서는 리더(우리 고객의 일종)분들께 인터뷰를 요청해보는 것은 어떻겠냐는 말이 기억에 남는다.

• 우리 고객님들은 남일처럼 하는 것이아닌 자기것처럼 진심으로 고민하고, 챙겨주시는 모습을 보여주셨던 것에 대해서 너무 인상적이었던 것 같다.

이에 더해 네트워킹이 이뤄지는 모습들 자체가 너무나 신기했다. 중장년(4070)분들의 서로 소통하는 모습이 왜인지 모르게 신기하고 멋있었다.  

 

개인적으로 네트워킹에 대해서 갈증(?)이 있었어서 그런지 더 이런 생각이 들었던 것 같다. 조만간에 개최되는 AWS SUMMIT에 참여하게 될 때, 네트워킹을 할 수 있도록 나도 준비를 해봐야겠다.

 

 

 

개인 업무 진행 간 필요한 부분, 앞으로 내가 해야할 부분에 대한 파악

나는 매일 Daily Record 를 작성하며, 하루를 기록하고 정리하고 있다.

 

나는 한달간 업무를 진행하면서, (당연한 이야기이지만) 나의 부족한 부분들을 많이 느낄 수 있었다. 부족한 부분을 채우기위해 시도한 많은 부분들이 있는데 이들을 기록으로 남겨보려한다.

 

 

1. 업무 우선순위 선정하기

 

현재의 미션드리븐의 초기 스타트업이다는 특징을 고려할 때, 업무의 우선순위는 이전 회사들에서보다도 훨씬 중요했다. 당장 우리가 생사가 불분명한것은아니지만, 시간은 생존과도 매우 연관이 깊다는 것을 매일 진행하는 스탠드 미팅를 통해 많이 느낄 수 있었다.

 

하지만 나는 업무의 우선순위를 정하는 것이 어려웠다. 좀더 구체적으로 이야기를해본다면, 나는 1. 해야할 일을 정하고, 2. 정해진 일을 수행하기 위한 나만의 순서를 정했다. 여기서 문제는 2. 정해진 일을 수행하기 위한 나만의 순서가 문제였다.

• 1. 해야할 일: 개발 우선순위로 정해진 개발 건
• 2. 정해진 일을 수행하기 위한 나만의 순서: 정해진 개발 건에 대한 나만의 개발 순서

 

나는 개발을 하기위해 정한 나만의 순서는 다음과 같다.

1. 요구사항 확인하기
2. 비즈니스 요구사항(유스케이스)를 다루는 클래스 생성하기
3. 요구사항에 필요한 DB 쿼리 만들기
4. 엔드포인트를 생성하기
5. 테스트

 

이렇 작성하고 보니 큰 문제는 없어보이지만, (현재 우리 개발 환경을 고려한)내가 느낀 올바른 순서는 다음과 같다.

1. 요구사항 확인하기
2. 엔드포인트를 생성하기(다음 단계가 생성될 때마다 테스트를 진행하기)
3. 비즈니스 요구사항(유스케이스)를 다루는 클래스 생성하기
4. 요구사항에 필요한 DB 쿼리 만들기

 

엔드포인트를 생성하여 단계 중간마다 정상적으로 동작하는지 확인하는 것이 필요했다. 이상적인 케이스는 단위테스트를 작성하여 해당 클래스의 동작이 정상 동작함을 확인하면 되는 문제이지만, 현재 우리 서비스에는 단위테스트틀 작성하고 있지 않다.(스웨거를 통해 테스트하고 있었다.) 

 

즉, 나는 "개발 마지막에서야 테스트를 통해 문제를 바로 잡을수 있었다"는 것이다. 이것이 가장 치명적이었다. 만약 내가 현 시스템과 구조에 익숙하다면(그래도 문제다) 어느정도 개발간 문제 없이 진행을 할 수 있었을 텐데, 나는 현재 아직 기술적으로나, 현 시스템에 대한 적응도 측면에서나 많이 부족했다.

• 마지막 스웨거를 통한 테스트를 할 때, 놓친 부분을 식별하는게 정말 어려웠다.(어느곳에서 문제인지 파악하기 어려움)
• 사용하는 라이브러리에서 에러를 반환할 때, 내가 사용한 구문의 에러인지, 현재 작성된 코드의 구조적인 에러인지 판단이 어려웠다.

 

나는 이런 과정을 몇번 반복하면서, 현재 개발 환경을 고려한 최적의 개발 순서를 고민하게 되었다. 그리고 이것을 고민하면서 이전보다 확장된 "업무의 우선순위"에 대해 스스로 생각해보게 된 것 같다.

 

 

2. 회사에 필요한 기술, 내가 부족한 기술(공부해야 할 기술)

회사에서는 기술적으로 고민을 할 수 있는 시간이 상당히 부족하다. 이와 관련하여 기술적인 고민에 대한 욕구를 해소하기 위해 궁굼한 부분들을 기록하고, 집에서 공부를 진행하곤 했다.  하지만 회사에서 기술 관련된 이슈를 지속적으로 겪게 되면서 공부주제에 대한 스스로의 문제성(?)을 느끼게 되었다.

• 집에서는 회사와 연관된 공부를 하면 좋지만, 다른 주제의 공부를 지속함으로써, 개발 역량의 확장을 계획했다.
• 나는 지속적으로 좋은 아키텍처에 대한 관심, 설계 패턴에 대한 공부를 지속하고 있었다. 

 

나는 회사에서 느낀 문제점(개발과정이 효율적이지 못함)에 대해 해결할 방법을 공부하는 것이 필요하다 느끼게 되었다. 나는 현 미션드리븐 이전까지 Java, Spring을 공부하고 있었기에 Python 과 FastAPI 및 관련 라이브러리에 대한 공부가 필요하다 생각이들게되었다.

• 개발을 진행하면서, 파이썬을 자바처럼 쓰려한다는 말을 간간히 들었다.(파이썬을 파이썬스럽게 사용해야했다.)
• 기본적으로 웹 개발 및 DB 설정, 테스팅 등, 구조는 동일했지만, 사용방법에서 큰 차이점이 존재했다. 

이를 극복하고자, 나는 FastAPI Playground를 만들어 "회사에서 시도해보지 못한 내용들" + "내가 생각하는 이상적인 시도" 를 해보고 있다. 아직은 많이 부족하지만, 꾸준히 공부를 통해 매일 부족한 부분을 채워나가고 있다. 그리고 이렇게 채워진 지식을 조만간 회사업무에 적용해보고자 한다.

 

 

GitHub - KEEMSY/fastapi-playground: fastapi-playground

 

 

---

공부

 

최근 공부는 앞서 이야기한것처럼 FastAPI Playground를 만들어 "회사에서 시도해보지 못한 내용들" + "내가 생각하는 이상적인 시도" 를 해보고 있다. 하지만 이것이 솔직히는 성애 차지 않는다.

• 나는 연습도 좋지만, 실제 사용에 적용하고 싶다.
• 이상과 현실의 괴리(?)에 부딪히는 일이 점점 늘어나고 있다.
• 사용하고 있는 기술에 대한 불만족이 있다.

물론 내가 성애 차는 개발하면 되지만, 문제는 내가 체력이 안된다는 것이다.. 회사에 너무 많은 체력을 소비하는 것인지.. 아니면 내 체력이 부족한 것인지..(이게 맞을 것 같다.) 최근 체력 이슈 때문에 공부도, 건강도 살짝 걱정이다. 컨디션 조절도 다 실력이기에, 역시 나는 주니어이긴 한가보다.

 

무튼 기술을 공부하면서, 다양한 문제에 직면하기도 했는데, 그 중 가장 날 괴롭혔던 것은 테스트 코드를 작성하는 부분이었다. 해당 부분에 대하여, 구글링을 진행했었는데 생각보다 레퍼런스가 너무 적어 문제를 해결하는게 쉽지 않았다. 대부분 문제 해결의 경우, 공식문서 혹은 에러 메시지를 보고서 해결을 했는데 알고 있는 지식과 충돌하는 부분들이 많았어서 아직 좀 많이 찜찜하다.

 

관련 포스팅

[ Pytest ] fixture 'sync_client' not found, 정의한 fixture를 찾지 못하는 문제

 

이외에도 다양한 문제들이 있었고 문제를 해결했지만, 기록으로 남길정도로 시간이 생기진 않았다. 지금처럼 주말에서라도 작성을 해야하는데, 주말에도 일정과 지친 몸에 늘어지다보니..(핑계) 힘들더라도, 미래의 나를 위해서라도 잘 기록하고 정리해야겠다.

 

 

---

 

벌써 미션드리븐이 합류한지 한달이 지나, 첫 급여를 받았다. 정신없는 한달이었지만, 너무 재밌었다. 그리고 앞으로의 미래가 기대가 된다. 설레고 즐겁다. 

 

그러나 마음 한구석에서는 불안한 마음도 조금씩 생긴다. 초기 스타트업으로서 풀어내야 하는 문제에 대한 부분, 개인 개발 역량에 대한 고민, 생존에 대한 문제 등.. 불안한 마음이 없다는 것은 정말 거짓말이다. 그래도 지금 팀원들과 함께라면, 잘 이겨낼 수 있을 것 이라고 확신한다.

 

이제 벌써 5월의 중반을 지나게 되었고, 2분기가 끝이 보이고 있다. 2분기의 끝은 월초 내가 세운 OKR을 중간점검해야 함을 의미하기도 한다. 내 책상에 적혀있는 OKRs... 잊지않기위해 보이는 곳에 두었지만, 너무 무관심했던 것 같다. 첫 OKR인데 예상했던 것보다 훨씬 더 아쉬워지는 것 아닌가 모르겠네^^... 일단 열심히 해보자! 아좌좌!!