4월과 5월은 굉장히 바쁜 시기였다.
개인적인 이유로 2, 3월을 힘들게 보냈었고 이게 어느정도 해결이 되고 나니 얼씨구 이제 회사가 바빠지기 시작했다.
많은 일들이 있었고 노력들을 했던 오랜만에 제대로 살았다는 느낌을 느낄 수 있었던 기간이었다.
1. 이거 끝낼 수 있을까..?
내가 입사하기 전부터 가지고 있었고 아직까지 Holding 상태인 프로젝트가 하나 있었다. 이미 서비스가 되고 있던 프로젝트였고 새롭게 리뉴얼하는 프로젝트를 이어 받게 됐다.
업무를 받고 처음 사용해보는 기술이 있었지만 이것을 학습할 시간이 따로 없었고 정해진 마감 기한 안에 개발을 끝내야 하는 상황이었다.
그렇게 기존에 작성된 코드를 천천히 살펴보기 시작했는데 이건 정말이지 복잡해도 너무 복잡한 것이었다.
추상화가 깊게 이루어져 있어서 평균적으로 2~3개 많게는 4~5개의 함수들을 파고 들어 들어 들어가서 하나의 기능을 표현하고 있었다.
간단한 기능임에도 왜 이렇게 복잡한게 만들었을까를 생각하고 있던 중 어떤 이야기를 듣게 됐다.
???: 예전에 개발을 할 때 백엔드 인력이 부족해서(?) 프론트엔드에서 백엔드에서 다룰만한 비즈니스 로직을 처리하는 안타까운 사연이 있었단다..
위 얘기는 차치하고 어찌됐든 나는 기한 내에 이걸 끝내야만 했고 이런 저런 생각을 할 시간이 없었다. 그래서 산재되어 있던 이슈들을 하나하나 쳐내기 시작했다.
처음에는 간단한, 예를 들어 메뉴 탭을 하나 제거하는 작업을 처리하는 것도 꽤나 오래 걸렸다. 코드를 어느 정도 이해하고 작업을 했다면 조금 달라졌을지 모르지만 그렇지 못했기에 처음에는 정말 힘들었다.
하지만 시간이 지나면서 어느 정도 구조를 파악할 수 있게 됐고 어디를 수정해야 될 지를 알게 되면서 간단한 이슈의 경우 쉽게 처리할 수 있게 됐다.
그럼에도 정말 어려웠던 부분이 있었는데 엑셀 Raw Data를 형식에 맞게 Validation 하는 부분이었다.
여러 형식의 엑셀 데이터가 주어지고 검증 요건에 맞게 검증을 한 다음 올바른 데이터를 보내줘야만 하는 상황이었다. 들어오는 데이터의 형식이 조건마다 달랐기에 같은 검증을 사용할 수 없었고 Flow를 나누어서 검증을 진행했다.
이때 정말 머리 뜯고 갈아끼우고 싶을 정도로 머리가 안돌아가서 죽을뻔 했다^^;
물론 이외에도 키보드에서 손 떼고 싶었던 순간들이 많았지만 개발을 무사히 끝내긴 했다. 물론 일정이 사알짝 밀린건 비밀이지만ㅎㅎ..
이번 프로젝트를 끝내고 느낀점이 크게 두 가지가 있다.
정말 다른 사람의 코드를 보는 것이 어려운 일이구나.. 개발을 잘하는 사람은 다른 사람이 이해하기 쉬운 코드를 짜는 사람이 아닐까?
그때의 그 분께서는 그 상황의 Best Practice를 찾아서 한 것일 수 있다. 그러니 나도 항상 Best Practice를 찾아가면서 코드를 치는 것을 습관화해야겠다.
결국 내가 내린 결론은 다음과 같다.
항상 Best Practice를 찾아가면서 코드를 치되 다른 사람이 이해하기 쉬운 코드를 작성하는 사람이 되자
이렇게 나의 4월이 지나갔다.
2. 떨어지는 독수리 성장법
독수리의 새끼들이 처음부터 고공을 솟아오를 수 있는 것은 아니다. 그들의 보금자리는 아슬아슬한 절벽 위 바위 턱에 있다.
이 보금자리를 어미 독수리는 때가 되면 뒤흔들어 어린 새끼들을 쪼아 낭떠러지 밑으로 떨어뜨린다. 그러면 새끼들은 비명을 지르며 어설픈 날갯짓을 하며 떨어진다.
새끼 독수리가 바닥에 떨어지는 찰나에 어미 독수리는 새끼들 근처로 날아와 새끼들을 자기 날개로 걷어 올린다. 이러한 과정을 수없이 반복함으로써 새끼들은 나는 법을 배우고 강한 독수리가 된다.
출처 : 에듀인뉴스(EduinNews)(http://www.eduinnews.co.kr)
입사 때부터 많은 걸 가르쳐줬던 선배 개발자가 5월에 다른 회사로 이직을 하게 됐다. 처음 이직을 한다고 들었을 때는 솔직히 겁이 조금 났다.
이제 7개월 된 아기 독수리 두 명이서 과연 잘 할 수 있을까? 라는 생각이 먼저 들었다. 아마 한 2~3일은 계속 이런 생각이었던 것 같다.
부담도 많이 되고 걱정도 많이 됐지만 이런 생각을 계속 한다고 해서 달라질 것도 없고 나에게 도움이 되지도 않을거라 생각해서 당장 내가 할 수 있는 것부터 하려고 했다. 일단 거의 만져보지 못한 프로젝트의 코드와 서비스 흐름을 이해하려 했다.
인수인계 기간동안 집중했던 부분은 크게 세 가지였다.
1) 서비스가 어떻게 이루어져 있는지 파악
먼저 코드를 분석하는 것보다 서비스를 직접 사용해보는 것에 집중했다.
환자 앱과 의사 웹이 연동이 되기 때문에 직접 환자가 되기도 하고 의사가 되기도 하며 서비스를 양 쪽 입장에서 사용해보면서 어떻게 서비스가 이루어지는지를 파악할 수 있었다.
2) 데이터 흐름 추적하기
다음으로 기능에 따라 코드를 분석했다.
복잡한 클라이언트 데이터와 서버 데이터가 있었고 이를 이용해서 여러 작업들을 하고 있었기에 데이터를 기준으로 코드가 어떻게 흘러가는지 파악하려고 노력했다.
데이터를 기준으로 코드를 따라가니 코드를 파악하는게 더 쉽게 느껴졌다.
그렇지만 이 과정에서 약어로 이루어진 많은 변수나 데이터가 있었는데 이걸 정리한 문서와 코드를 번갈아가면서 눈 빠지는 줄 알았다.
어느정도 기능과 코드에 대한 정리가 끝난 후 문서로 정리하면서 다시 한 번 살펴볼 수 있었다.
3) 어떤 의도록 이루어져 있는지 파악
코드를 살펴볼 때 의도는 알겠으나 의아했던 부분이나 이해하기 힘든 부분들을 따로 정리해서 인수인계 기간동안 질문을 했다.
주석이나 문서가 없었기 때문에 코드만 딱 바라봤을 때 이게 무슨 의도를 가지고 작성한 코드인지 아는 게 힘들었기에 이 부분을 질문을 통해 해소하고 따로 문서로 정리했다.
지금 내 상황이 어떻게 보면 부담스러울 수 있지만 오히려 기회라고 생각하려 했다. 아직 신입이라는 방패 아래에서 보호를 받고 있는 입장이라 위에서도 기존과 같은 퍼포먼스를 기대하지는 않을 것이라고 생각한다.
그렇지만 여기서 만약 내가 신입답지 않은 퍼포먼스를 보여준다면 나를 어필할 수 있는 좋은 기회가 되지 않을까싶다.
물론 꼭 그 이유뿐만은 아니더라도 기획이나 마케팅 쪽과 직접적으로 소통을 하고 의견을 좀 더 적극적으로 개진할 수 있다는 점도 좋은 기회라고 생각한다.
또한 내가 적용해보고 싶었던 것을 더 적극적으로 적용해보려고 할 수도 있을 것 같다. 긍정적으로 생각하면 사수가 없다는 게 마냥 안 좋은 부분만 있는건 아닌 것 같다.
그 안에서 내가 어떻게 하느냐에 따라 결과는 천차만별이 되지 않을까싶다.
3. Back To The Basic
React를 주로 사용하고 있지만 아직도 많이 부족하다고 느낄때가 너무나 많다.
매일 Daily Log를 작성하면서 React와 그 외의 개발과 관련된 많은 양질의 자료를 보면서 공부하고 코드를 작성하지만 그럼에도 불구하고 항상 무언가 부족하다는 느낌이 들어 React를 처음부터 다시 공부해보고자 하는 생각이 강하게 들었다.
어디서부터 시작해야할 지 고민을 하던 찰나에 리액트 기초부터 심화까지 여러가지 질문을 제시하고 설명하는 좋은 Repository를 발견했다.
이 Repository에 나온 질문을 기반으로 현재 내가 알고 있는 대답을 하고 관련 자료를 찾아가면서 지식의 오류를 정정하고 깊이를 늘리고 있다.
이 공부를 하면서 오? 내가 꽤 깊게 알고 있구나 라는 생각이 들기도 하면서도 마치 그냥 오직 면접만을 위한 원론적이면서 이상적인 대답을 하는 질문들도 있었다.
예를 들면 아래와 같다.
A: ci/cd에 대해서 설명해주세요.
B: ci는 Continuous Integration의 약자로 코드의 변경 사항을 지속적으로 통합하여 여러 개발자가 협업을 하는 경우 .....
A: 그럼 CI/CD를 구축해본 경험이 있나요?
B: 예?
A: 면접은 여기까지 진행하겠습니다.
이제는 취준생이 아닌 만큼 CI/CD를 알기만 한 개발자가 아닌 알고 적용해본 개발자가 되는 것이 정말 중요하다.
마찬가지로 지금 하는 리액트 공부를 그냥 하는 것이 아니라 배우고 코드에 써먹고 익숙해지면서 성장하는 과정이 꼭 필요하다.
4. 나부터 시작하는 팀의 성장
개인의 성장을 통해 팀이 성장할 수 있게 만들겠습니다.
내가 취준을 하면서 이력서에 정말 수없이 적었던 문구다.
이력서에 보기 좋은 소리를 채워 넣기 위해 하는 말이 아니라 정말 내가 가지고 있는 생각이며 하고 싶고 바라는 점이다.
어떻게 해야 팀의 기여할 수 있을까를 곰곰히 생각해본 결과 당장 혹은 빠른 시일 내에 기여할 수 있는 방법이 몇개 생각이 났다.
1. 공부한 내용을 정리해서 Confluence에 공유하기
위에서 말한 리액트 톹아보기부터 업무를 진행하면서 필요한 부분들에 대한 공부가 있으면 개인적으로 공부한 내용을 Confluence에 공유하고 있다.
이렇게 공유를 하게 되면 (남들이 보기 때문에) 의식적으로 더 깊고 정확하게 공부하게 되는 장점이 있는 것 같다.
공부한 부분뿐만 아니라 프로젝트에 대한 Context를 파악해서 Flow를 정리해 공유하고 있다. 처음 들어가는 프로젝트나 소스 코드를 보고 파악하는게 여간 어려운 일이 아니라는 것을 몸소 겪고 있었기 때문에 최소한 흐름이라도 이해하고 코드를 볼 수 있으면 좋겠다는 마음에 시작했다.
아직 전부 다 한 것은 아니지만 앞으로도 내가 봤을 때 어? 이거 좀 이상한데 라고 느끼는 부분은 따로 정리해서 물어보고 이해해서 정리를 계속해서 해나갈 예정이다.
2. MSW 적용하기
그동안 백엔드와 협업을 하면 DTO를 미리 받고 JSON으로 관리를 하던 그냥 상수로 관리를 하던 별도의 API 요청 없이 개발을 했었다.
이렇게 하면 발생할 수 있는 (내가 겪었던) 문제점은
- 데이터를 가지고 화면은 제대로 만들 수 있지만 에러 처리가 제대로 이루어지지 않는다. 따라서 API 명세를 받고 난 후 또 다시 에러 처리를 일일이 해줘야 한다.
- 실제 네트워크 요청을 하는 것이 아니기 때문에 네트워크 상태에 따라 디버깅이 불가능하다.
- 프론트엔드는 일반적으로 개발 파이프라인의 마지막에 위치하기 때문에 API 명세가 나온 후 일정이 촉박할 수 있다. 이때 만약 샘플 데이터로 작업하고 있었다면 이를 실제 API로 수정하는 작업에 소요되는 시간으로 인해 디테일이 부족해질 수 있다.
내가 만약 MSW 따위는 없어도 되고, 마감 당일에 API가 완성이 되도 문제 없이 개발을 끝낼 수 있다면 상관없겠지만 아직 그러지 못하기 때문에(^^;) MSW 도입을 결정했다.
MSW 도입을 결정한 또 다른 이유는 많은 레퍼런스와 쉽게 적용할 수 있다는 점이다. 공식 문서와 이런 저런 글을 보고 쉽게 초기 세팅을 완료했고 상대적으로 부담이 적은 관리자 페이지에 먼저 적용을 해봤다.
실제로 MSW를 사용하니 API를 사용해서 개발을 하던 때와 크게 달라지지 않는 흐름으로 개발을 할 수 있었고 API 명세가 나온 후 해당 API로 교체만 해주니 정상적으로 동작하는 것을 확인할 수 있었다.
결과적으로 MSW를 도입해서 백엔드와 병렬적으로 개발이 가능해졌고 생산성이 많이 제고됐다.
3. Unit Test 적용하기
이건 아직 프로덕트 코드에 적용하지 못한 부분이다. 적용하면 어떨까? 라는 생각에 개인적으로 공부를 하고 있고 추후에 점진적으로 적용을 해보려고 생각 하고 있다.
이전에 개발을 할 때 테스트를 따로 진행하지 않다보니 QA 단계에서 빠꾸(?)를 먹은 적이 꽤나 많이 있어서 그때부터 테스트를 도입하는게 좋을 것 같다는 이야기를 했었다.
E2E 테스트까지는 오버 엔지니어링이 될 것 같아 굳이 할 필요는 없을 것 같다고 생각해서 작은 단위의 Unit 테스트부터 도입하려 한다.
테스트 공부를 하면서 느낀 점은 모든 부분을 테스트 할 필요는 없다고 느꼈다.
소위 말하는 테스트 커버리지를 100%로 만들기 위해 작성하는 테스트 코드는 큰 의미가 없다고 생각해서 정말 테스트가 필요한 부분에 적용하는 방식으로 진행할까 생각 중이다.
어떤 부분이 테스트가 필요할까에 대한 명확한 정의나 개념이 아직은 분명하지 않기 때문에 팀원과 이야기를 해서 테스트가 꼭 필요한 부분을 정의하는 과정이 필요하고 오픈소스 등을 참고하고 적용해보며 진행해야 할 것 같다.
Test Code를 작성하게 되면 개발 단계에서의 공수는 늘어나지만 전체적인 개발 생산성은 향상되지 않을까 하는 기대를 갖고 있다.
