프로젝트 중간 회고

황연욱·2021년 1월 3일
3

회고

목록 보기
1/1

프로젝트 중간 회고

프로젝트를 초기단계에서부터 시작하고, 진행한지 2달이 지난시점에서,
개발자로서 처음으로 회사에 합류하고 프로젝트를 진행하던 과정에서 많은 것들을 느끼고 배웠다고 생각되는데 점차 시간이 지나면서 그 기억들이 희석되는 것 같아서 기록으로 남기기 위해서 작성하는 글입니다.

접점

현재 진행중인 프로젝트에 처음으로 합류 한 시기는 2020년 9월 14일이었다.

2020년 9월 14일 ~ 10월 16일 이 시기는 현 회사에 팀원으로서 근무했던 시기는 아니었고 당시 수강중이었던 wecode에서 기업협업 과정을 통해 인턴으로 출근을 하고 있던 시기었다.
이때쯤에는 프로젝트의 기획과 디자인이 모두 엄청 초기단계였고 실제 개발이 어떻게 진행될지도 정해지지 않은 상황이었다.
그래서 UI부분 위주로 컴포넌트를 분리해서 재활용성 있게 활용하는데에 초점을 두고 개발을 진행하게 되었고 이 과정에서 처음으로 스토리북을 활용해보게 되었다.

이때는, React를 이용해서 작업을 했기에, 추후 ReactNative를 이용해서 하이런 프로젝트를 진행하게 되면서 이 때의 작업물들을 활용하지는 못하게 되었지만. 스토리북을 접하고 재활용성 높은 컴포넌트를 만들어야 한다는 관점으로 생각해 본 시기였다. 스토리북을 사용하며 느꼈던 점을 정리한 글

그리고 2020년 10월16일 인턴과정이 끝나고, 회사로부터 팀원으로 합류하라는 제의를 받게되어 합류 후 계속해서 프로젝트를 진행하게 되었다.

본격적인 프로젝트 시작

본격적으로 프로젝트를 초기단계부터 시작하면서 모든것을 다 조사하고, 토의하고, 결정 한 후 반영하는 과정의 시작이었다.
처음으로 당면한 과제는 고객사측에서는 앱형태의 결과물을 원하는데 그렇다면 이 앱을 만들기 위해서 1.어떤 기술을 2.어떤 형태로 사용할 것이냐였다.

사용할 기술스택은 개발하는 앱에서의 요구사항이 Native한 기능을 엄청난게 요구하는 것은 아니라고 판단되고, 앱개발자가 따로 없는 상황에서 IOS와 Android를 각각 사용되는 기술을 공부해서 개발하는 것 보다는 크로스플랫폼을 지원하고 React를 알고 있는 사람이라면 좀 더 쉽게 접근할 수 있는, 그리고 사이드프로젝트를 통해서 조금이라도 사용해본 경험이 있는 ReactNative를 활용해서 개발하기로 결정되었다.

그 뒤에 또 결정해야 할 사항은 초기의 고객사와 내부적으로 결정되어있던 진행방향은 대부분의 화면과 기능들을 App에서 처리하는 것이 아닌 App은 단순히 WebView만을 보여주고 실질적인 모든 컨텐츠와 기능들은 연결된 WebView에서 진행하도록 하는 방식을 원하고있었다.
처음 이 얘기를 듣고 이 방향으로 진행하기 위해서 WebView와 앱이 어떻게 통신하는지, 그리고 우리가 구현하고자 하는 기능을 모두 이방식으로 구현이 가능한지등을 조사하던 중, 기존에 ReactNative를 이용해서 개발을 하셨던 경험이 있던 Wecode멘토분에게 이렇게 앱이 단순히 WebView만 연결되어있는 형태이면은 AppStore에 등록되기 전 거쳐야 하는 심사과정에서 통과가 안된다는 얘기를 들었다. 그래서 해당하는 내용을 정리해서 CTO님에게 전달하고 그 뒤 회의를 거친뒤에 그렇다면은 WebView방식이 아닌 ReactNative를 이용해서 모든 기능과 화면단들을 구성하는 식으로 진행하자고 결론이 났다.

이런 과정을 통해서 단순히 코드를 짜는 실력뿐만 아니라, 개발을 하기위해 필요한 관련된 자료들을 조사하고, 정리해서 의사결정권자에게 잘 전달한 후 내부적으로 각자의 근거를 가지고 토의를 하는 것 또한 중요한것을 알게되었고 어떻게 하면 좀 더 효과적으로 내 의견을 전달할 수 있는지 고민해보기 시작하는 시기였다.

프로젝트 초기 구조 세팅

최종적으로 ReactNative의 형태로 작업을 진행하기로 결정을 하고 난 후, 초기 프로젝트의 구조 세팅 테스크가 저에게 부여되고나서 어떤식으로 진행해야 하는지에 대해서 고민을 오래 하게 되었습니다.

사실상 이 테스크가 제가 회사에 합류하고 나서 처음으로 맡게 된 테스크였기에 잘 해내고 싶다는 생각으로 여러가지 리서치를 하던 중 Monorepo라는 것을 보고 이 형태로 적용을 하게되면은 앱과 웹간의 공통으로 사용할 수 있는 부분들은 공용 패키지로 만들어서 사용이 가능하겠다고 판단이 되어서 이 형태로 세팅을 하기로 결정하고 진행했었습니다.

처음으로 개발환경세팅에 관련된 부분을 건들여보다보니, 적합한 자료를 찾는 것부터, 그 자료에서 한 방법과 실제 시행한 결과에서 원하는 결과와 일부분 다른 점이 있으면 다시 어떤 부분을 수정해야 하는지 찾아보고 수정하고, 여러 에러사항들을 다시 검색하면서 해결하고 하는 과정을 거치면서 많이 힘들었던 기억이 있습니다.

하지만 이러한 과정을 통해서 원하는 자료를 찾고, 내가 원하는 결과대로 일부분 수정해서 적용해보는 과정이 여전히 어렵기는 하지만, 두려워하지는 않게 된 것 같습니다.

또한 이 과정에서, 기존에, 개인이 작업할 때나, 편한 사람들끼리 사이드프로젝트느낌으로 진행할때에는 안되면 그때 그때 해결하면 되지, 중간에 변경하면 되지라는 마인드로 진행을 했다면

회사의 프로젝트같은 경우에는 중간에 노선을 변경하기에 많은 리소스가 들고, 처음 세팅을 할 때 최대한 잘 된 상태로 세팅을 해서 모든 팀원들과 함께 사용해야 한다는 생각에 좀 더 많은 부분을 찾고 정리했던 것 같습니다.

그래서 실제 그 뒤에 코드를 짤 때도 회사의 프로젝트기에 모든 팀원들에게 공유되고 서로 사용될 수 있는 코드라고 생각하고 좀 더 가독성 좋고 효율적이고, 공감대가 형성될 수 있는 코드를 짜기 위해서 노력하게 되는 관점의 전환이 되는 시기였습니다.

또 이 때 CTO님께서 세팅을 하면서 겪은 이슈들을 모두 문서화해달라고 요구하셨는데 이 말을 들으면서 내가 이 세팅을 하면서 겪었던 이슈, 발생했던 에러사항들이 다른 팀원들에게도 발생할 수 있고. 그것을 모두 개인이 해결하는 것보다 먼저 어려움을 겪으면서 헤쳐나갔던 사람이 트러블슈팅등의 항목으로 잘 정리를 해 두면 팀원 전체적으로 효율성이 높아진다는 관점 또한 가지게 되었습니다.

그리고 같이 작업하시는 팀원분들과 함께 폴더구조를 어떻게 형성할 것인지,다양한 기기에 대한 대응은 어떻게 할 것인지 등 여러 사항에 대해서도 토의하면서 여러가지 자료를 찾고 어떤 거는 적용하면 좋을 것 같고 어떤 것은 굳이 필요없는것 같다라고 서로의 근거와 자료를 통해서 최적의 방향이라 생각 되는 것을 도출해나가는 과정 또한 좋은 경험이었습니다.

그리고 프로젝트 구조를 팀원들에게 공유하고 어떻게 구성이되어있고, 어떤 식으로 사용을 할 수 있고 어떤 점이 이점으로 작용할 수 있는지를 정리해서 설명하는 과정을 겪게되었는데 이때의 경험이 그 뒤에도 어떤 것을 조사하고 정리해서 의견을 드리는데에 많은 도움이 되었던 것 같습니다.

기획안 분석 및 Task정리

이 때 당시의 개발팀원은 프론트 개발자분이 한분 계시고, 백엔드는 CTO님이 담당하고 있었다. 즉 나를 포함한 프론트2명, 백엔드1명의 구성으로 3명이서 프로젝트를 진행하는 과정이었다.

이제 개발을 하기 위해서 기획안을 보고 Task를 정리하고 팀원들끼리 분배하는 작업에 들어갔다.
CTO님께서 처음 기획안을 보고 Task를 나눠보라고 하시면서 관련된 참고자료를 하나 주셨다.
개발을 여러층의 케익으로 나누기

이 글을 읽고 테스크를 정리해보기 시작했다. 처음에는 어떤식으로 나눠야 할지 감이 잘 안왔지만 계속해서 읽어보고, 기획안을 찾아보면서 어떤 동작을 했을 때 어떤 반응이 사용자에게 일어나야 한다라는 것을 위주로 테스크를 정리해보기 시작했었다.
아직도 테스크를 어떤 기준으로 나누는 것이 잘 나누는 것인지, 어디서부터 어떻게 세분화해서 나눠야하는지에 대한 고민은 계속해서 들고 있다.

이때의 경험을 바탕으로 다음에 더 고민해 볼 관점은 1.테스크를 어디서부터 어떻게 세부적으로 나눠야하는지 2.어떻게 하면 숨겨진 테스크들(발견하지 못한 테스크들)을 최대한 줄여서 처음부터 명료하게 정리가 될 수 있게 하는지에 대해서 고민해봐야겠다.
또한 한편으로는 지금 프로젝트를 진행하면서 계속해서 기획과 디자인이 수정되는 상황이 자주 일어났는데 이러한 상황속에서 과연 초기에 테스크를 정확하게 나누기 위해서 얼마만큼의 시간과 노력을 들여야할지에 대한 의문도 든다.
처음에 완벽하게 테스크를 정리하려고 많은 시간과 노력을 들여서 깔끔하게 Task를 정리할 수는 있겠지만, 그렇게 정리했다고 하더라도 중간에 기획과 디자인이 수정되면은 다시 테스크들을 추가하고 삭제하는 과정이 빈번히 일어나는데 이러한 상황에서 과연 처음 테스크를 정리하는데 많은 리소스를 투입하는 것이 옳은 방향일지에 대한 생각도 해보게 된다. 현재로서의 생각은 테스크정리는 일정 수준에 도달하면은 일단 개발을 진행하고 테스크를 계속 추가하면서 가는 것이 맞는 방향이라고 셍각된다.

또한 Task가 어느정도까지 진행되고 있는지, 한 테스크를 완료하기 위한 일정은 언제인지를 팀원들이 모두 공유하고 관리하기 위해서 여러가지 Tool들을 사용해보게 되었다. 처음에는 teamgantt라는 툴을 이용해서 간트차트의 형식으로 관리를 하기 시작했다.
트렐로 처럼 티켓단위로 todo progress done 등의 칸반보드형식으로 기존에는 프로젝트를 했었는데. 이러한 일정관리까지 연동된 툴들을 사용하다 보니 좀 더 한 태스크를 완료하기 위한 일정에 대해서 직관적으로 보이고 이해하게 되었다.
teamgannt는 유용하고 좋았지만, 속도와 UX가 좀 불편한 부분이 있어서 현재에는 Asana를 통해서 테스크관리를 하고 있다.

라이브러리 사용 및 조사

리엑트네이티브를 활용해서 프로젝트를 진행하면서, 라이브러리를 활용할 일이 많이 있었다.

모바일디바이스의 네이티브한 기능을 사용하기 위해서는 직접 그 네이티브한 기능을 건드는 Swift나 Kotlin으로 된 코드를 작성해서 다시 ReactNative코드로 변환하는 과정을 거치거나 하는 식의 과정이 필요한데 그것들을 직접할 수는 없으니까 그런것들을 미리 해놓은 라이브러리 들을 찾아서 활용하는 과정이 계속해서 반복되었다.

거의 필수적으로 사용되는 유명한 라이브러리등은 문서화나 활용성이 좋게 되어있었기에 잘 적용할 수 있었지만.

그 외의 경우에는 아무래도 리액트보다는 커뮤니티와 사용자수가 작다보니 라이브러리의 가짓수가 많지 않았고, 그래서 문서화가 잘 되어있지 않은 라이브러리들도 많고, 특히 이슈가 해결되지 않은 불안정한 라이브러리들도 많이 존재했었다.

그러한 라이브러리들을 사용해야 하는 상황에 처하면서, 내가 원하는 조건을 갖춘 라이브러리들을 찾아보고
또 문서화되어있지 않은 부분들을 직접 소스코드를 보면서 확인해보고 적용하고 하는 과정들에 익숙해졌다는 수확을 얻었다.

한 예로 처음에 DropDownPicker를 구현하는 라이브러리를 찾았어야하는데 굉장히 간단한 기능인데도 해당하는 라이브러리들이 내가 원하는 기능이 아니여서 다시 찾아보고 그렇게 해서 찾은 것들은 또 사용하는데에 문제가 있어서 해결방법을 찾다 도저히 없는 것 같아서 다시 찾아보고 어떤 라이브러리는 버전이 안맞고 등의 여러 이슈로 인해서 간단한 DropDownPicker하나 사용하는데 3일정도가 걸렸던 경험이 있다.
이때에는 굉장히 스트레스받고 힘들었고 "이정도면 그냥 처음부터 만들어서 사용했으면 차라리 더 빨리 됬겠다"라는 생각도 들었었는데, 그래도 이 과정을 통해서 라이브러리를 찾아보고 적용하는 능력이 좀 더 발전했다고 생각되고, 실제로 그 뒤에 다른 라이브러리를 사용할 때나 인턴으로 오신분들이 라이브러리 사용에 어려움을 겪고 있을때 그때의 경험을 바탕으로 좀 더 쉽게 접근할 수 있어서 실제로 느낄 수 있었습니다.

팀원들이 많아지면서 고려해야 할 점 & 많은 팀원들과 협력하는 법

처음에 프로젝트에 합류했을 때에는 백엔드는 CTO님께서 담당하시고, 프론트는 저 포함 2명으로 3명이라는 소수의 팀으로 프로젝트를 진행하고 있었습니다.

제가 합류하기 전에는 프론트1분, 백엔드는 CTO 1분으로 프론트끼리 협력할 일이 없었기에 git관리 전략이나, 코드컨벤션, 상호코드리뷰등의 과정이 없었는데 적용해보면 좋을 것 같아서 건의를 드렸고, 관련해서 유명한 git-flow등을 처음부터 전체를 다 적용시키는 것은 너무 과하다고 결론이 나서 일부분만 차용해서 적용시키고, 약간의 코드컨벤션, 그리고 Issue 템플릿, MR템플릿 등을 적용시키면서 초기세팅을 했던 경험이 있습니다.
팀원이 소수일때는 모두가 같이 회의를 하고 공감대가 형성된 상태에서 거기에 맞춰서 작업을 하다보니 큰 어려움이없었는데, 프로젝트 중간에 인턴 7분이 합류하게 되었고 그분들이 모두 프로젝트에 투입되는 시기가 있었습니다.

초기에는 기존에 구성해놓은 프로젝트의 구조를 문서화해놓았지만 인턴분들이 모두 ReactNative에도 익숙치않고, 프로젝트의 구조를 문서만 보고 파악하시기에 어려움을 많이 겪으시는 것 같아서 직접적으로 설명해드리는 식으로 계속해서 진행을 했습니다.

중간중간 과정에서는 이러한 공감대가 잘 형성되고 있다고 판단되었고, 만약 뭔가 의도와 다른식으로 진행이 되고있으면 중간에 직접 수정을 요청드리는 방식으로 진행했었습니다.
하지만 7분의 한달간의 인턴기간이 끝난 후 최종적으로 결과물을 검토해봤을 때 저희가 의도했던 방식과는 다른 방향으로 인식하고 진행되었던 결과물들이 일부 보였습니다.

이 과정을 통해서 팀원들이 많아질수록 1. 팀원간의 하나의 공감대를 형성하기가 점점 더 난이도가 올라간다는 것을 느꼈고 2.팀원들 모두간에 공유되어야 하는 사항들(컨벤션, 프로젝트 구조, 이슈사항 등)이 있을 경우 말로 전달하는 것은 전달하는 입장에서도 시간과 노력이 많이 투입되고, 전달받는 입장에서도 시간이 지나면 전달받은 사항들이 휘발되고 또 듣는사람의 이해여부에 따라서 여러사람들이 다 각자 다른 방식으로 이해할 수 있다는 단점이 있기에 정말 불가피한 사항이 아니고서는 문서로 정리해서 전달해주는 것이 더 효율적이라는 것을 깨달았습니다.

그래서 첫 인턴기수분들의 과정이 종료되고 그 뒤에 바로 새로운 인턴 5분이 합류하게되셨는데 그때는 노션에 필요한 사항들을 정리해서 전달하는 식으로 진행을 했습니다.

물론, 이 과정에서도 노션에 모든것을 문서화 하는 것의 어려움, 그리고 최대한 오해의 소지가 없이 전달되도록 명확하게 정리를 하는 것이 어려웠지만, 일단 처음부터 완벽하게 적어놓는 것 보다는 프로토타입 수준으로만 정리해두고 그 뒤에 계속 소요에 따라서 추가해나가는 방식으로 팀원들끼리 협의를 해서 해당하는 방향으로 진행하고 있습니다.

함께 작업하는 팀원들이 늘어나고, 팀원분들이 합류하고 빠지고 다시 새로운 분들이 합류하는 과정을 겪으면서 여러명과 함께 프로젝트를 진행해나갈때의 필요한 능력, 더 효율적으로 함께 협업할 수 있는 방식에 대해서 고민해 보게 되는 경험이 되었습니다.

다른사람의 코드를 분석하고 활용하고 수정해야 했던 경험

위에서 말씀드렸다시피 인턴으로 7분이 합류해서 한달동안 같이 프로젝트를 진행했던 시기가 있었습니다.
인턴기간이 끝난 후 7분이 짜놓은 기존 코드를 이제 활용해야 할 시기가 있었는데. 각자의 코드가 각자의 생각과 관점으로 짜여있다보니 분석하고 활용하는데 시간이 소요됬던 경험이 있습니다.
물론 당연히 타인이 짜놓은 코드를 보고 활용하는데 어려움을 느끼는 것은 당연하지만, 어떻게 하면 최대한 이 리소스를 줄일 수 있을까 고민해보는 시기가 되었습니다.
현재까지의 생각으로는 기본적인 컨벤션등을 모두 일치시키고, 그것을 강제시킬 수 있는 장치들을 마련하는 것 또한 좋은 방법이라고 생각됩니다. 컨벤션등이 일단 문서화되어서 전달이 되긴 하지만 실제로 코드를 짜는 입장에서 짜다보면 사소한 부분들을 놓치고 지나갈 수도 있는데 이러한 상태로 코드가 develop브랜치에 merge가 되고 나중에 활용해야 하는 상황이오면 컨벤션이 안지켜진 코드 같은 경우에는 컨벤션이 지켜진 코드보다 보기가 힘들다는 것을 느꼈습니다. 그래서 컨벤션등을 명확하게 지정해두고 lint, prettier세팅들을 모두 맞추고, 추가적으로 pre commit hook, pre push hook등의 도구등을 통해서 기초적인 컨벤션부분을 일부분 강제할 수 있게 된다면 사소한 실수들을 줄이고 또한 상호코드리뷰시에 기초적인 컨벤션에 관한 리뷰사항들이 줄어들기에 많은 리소스를 줄일 수 있겠다는 생각이 들어 다음 프로젝트부터는 도입을 건의해봐도 되겠다는 생각이 들었습니다.

또한 상호코드리뷰시에도 이제 이 코드가 어떠한 결과를 원하고 그를 위해서 어떤 로직이 진행되고 있는지를 이해하려고 노력하고 이해가 안될 시 쓰레드등으로 질문하고 토의하는 과정을 통해 모두가 서로의 코드에 대한 이해도를 높이고, 다른 사람이 작성해놓은 코드를 볼 때 이해가 가능한 수준까지 모든 팀원들이 공감대를 형성하는 것을 목표로 진행하는 것이 좋겟다는 생각이 들었습니다.

마지막으로 스스로가 코드를 짤 때도 좀 더 명확하게 과정과 결과가 다른사람에게도 이해될 수 있도록 생각하고 노력하면서 그에 초점을 두고 짜야겠다는 생각이 들게 되었던 시기였습니다.

리팩토링의 중요성과 어려움

리팩토링을 해야할 필요가 생겨서 리팩토링을 하기 시작했었는데, 이 과정에서 리팩토링이 왜 중요하다고 생각되고 또 왜 어렵다고 느껴지는지에 대한 생각이 들었습니다.

리팩토링의 정의가 "외부동작을 바꾸지 않으면서 내부 구조를 개선하는 방법" 이기에 기존에 잘 돌아가고 있는 것을 좀 더 유지보수하기 용이하고 알아보기 쉽게 바꾼다는 것에 어려움을 느꼈었었습니다.

먼저 어떻게 하면 코드가 좀 더 읽고, 수정하고, 기능을 추가하기 쉬워질지에 대해서 고민을 하게 되었고,
두번째로는 과연 내가 수정한 이 코드가 기존의 기능과 완벽히 똑같이 동작을 할까? 라는 것에 대한 걱정이 되었습니다. 내가 테스트한 특정 상황에서는 잘 동작하지만 만약 기존 프로그램에서 잘 돌아가고 있던 부분이 내가 수정을 하고 나서 제대로 안돌아가면 어떡하지에 대한 고민으로 좀 더 많은 테스트를 해보고나서 MR을 등록하게 되었던 경험이 있습니다.

이러한 과정을 겪으면서 CTO님께 위의 어려움이 있었다고 말씀드리니, 그래서 실제로 테스트 코드등이 구성되어있으면 그러한 걱정을 좀 더 덜면서 다양한 케이스에 대한 동작 테스트를 해볼 수 있다고 말씀을 해주셨습니다.

그래서 지금까지는 말로만 들어봤던 유닛테스트, 테스트코드, 테스트주도개발 등에 대해서 좀 더 알아보고 싶다는 생각을 하게 되었습니다.

일정 내 완수와 코드 품질에 대한 고민

모든 프로젝트의 경우 일정이 정해져있는데 이 일정내에 많은 결과물을 보여주는 것과 그 내부의 코드들의 품질에 대한 고민을 하게 되었습니다.

실제 개발을 하면서 중간중간에 이러한 부분은 좀 더 모듈화시키면은 추후 코드를 파악하고 유지보수등을 실시할 때 더 효율적이겠다라는 생각이 들지만 그것을 적용시키기 위해서는 더 많은 시간이 투입될 것 같은데 그러기에는 일정이 좀 촉박하다는 생각이 들 때 과연 어떻게 해야할지에 대한 고민이 들었었습니다.

모든 프로젝트는 일정이 산출되고 그 안에 결과물을 보여줘야 하기에 이러한 고민은 지금뿐만 아니라 앞으로도 계속하게 될 것 같은데 어떤것이 옳은 방향인지는 시간이 지나면서 점점 생각이 바뀔 수도 있을 것 같습니다.

일단 지금의 생각으로는 일정내의 완수가 더 중요한 사항이기에 일정 내에 완수에 초점을 두고 그 뒤에 다시 리팩토링을 하는 것이 좀 더 옳은 방향이라고 생각이 되는데 그러기 위해서는 리팩토링을 하기 용이한 환경을 잘 설정해두거나, 추후에 이러한 부분은 리팩토링을 할 필요가 있다고 잘 기록해두고 Task로 관리하는 것이 좋을 것 같다는 생각이 들었습니다.

그리고 최종적인 방향성으로는 일정내에 고품질의 프로그램을 만들 수 있는 개발실력을 갖추는 것이 되어야겠다는 생각이 들었습니다.

모듈화 되고 재사용성 높은 코드에 대한 고민

코드의 모듈화, 재사용성 높은 코드 작성 등에 대한 얘기를 많이 들었는데 실제로 이 필요성을 많이 느끼게 된 경험이었습니다. 기존의 첫 프로그래밍을 입문해서 동기들과 함께 프로젝트를 진행할때에는 코드의 품질보다는 목표로 한 기능이 실제 웹과 앱상에서 돌아가는 것을 보는데에 조금 더 비중을 두고 개발을 진행했었습니다.

하지만 이제 실제로 회사의 프로젝트에 투입이 되어서 진행을 하다보니 목표한 기능이 돌아가는 것은 당연한 것이고 그 기능을 돌리기 위한 코드들이 얼마나 품질이 높은지에 대해서 좀 더 비중을 두는 방향이 옳은 것이라고 생각이 되었습니다.

최대한 중복을 줄이고 기능들을 분리화하고 그것을 다시 조합해서 더 큰 기능을 구현하는 방식으로 개발을 진행해야지 프로젝트가 점점 더 방대해지고 관리해야 할 소요가 많아졌을 때 효율적으로 수정하고 추가할 수 있다는 사실을 알게되고 그러기 위해서 좀 더 좋은 코드란 어떤 것인지에 대해서 고민을 하게 되는 것 같습니다.

저는 2020년 6월부터 프로그래밍을 입문했기에 첫 시작을 ES6+이상의 javascript문법으로 시작했고, 그 뒤에는 프론트엔드로 방향을 정하고 React 기반으로 개발을 하고 있기에 함수형프로그래밍이라는 개념을 처음접했을때 그동안 알게모르게 사용했던 것들이 모두 함수형개념에 들어있다는 것을 알게되었고 그래서 조금 더 많은 관심이 가게 되고 이러한 개념을 접목했을 때 좀 더 고품질의 코드를 작성할 수 있게 될 것 같다는 생각이 들어서 틈틈히 함수형프로그래밍에 대해 공부해보려 합니다.

기록, 문서화의 중요성

처음 회사에 합류해서 어떤 것을 조사하거나 접목하고 정리해서 의견을 말씀드리면 항상 CTO님께서 문서화로 잘 남겨서 다른분들에게도 공유해달라는 말씀을 하셨습니다.
기존에도 뭔가 알게 된 것들을 남들에게 공유하는 과정에서 스스로 한번 더 정리를 하게되고 그러면서 해당하는 지식을 다시 한번 깊게 습득할 수 있다는 생각을 가지고 있어서 문서화에 대해서 거부감이 없었기에 최대한 잘 정리해서 기록하려고 노력을 했었습니다.

하지만 조직전체로 봤을때 실제로 문서화라는 것이 어떠한 효용을 가지고 있는지에 대해서는 생각을 해 볼 기회가 없었는데 어떠한 지식을 공유하는데에는 말로 전달하는 것에는 한계가 있고 리소스가 많이 든다는 점을 깨닫게 되었고, 이를 문서를 통해서 전달하게되면 더 명확하게 전달된다는 것을 깨달았었습니다.

또한, 트러블슈팅같은 경우에도 프로젝트 초기 구조 세팅에서 말했다시피 한명이 관련된 과정을 겪고 난 뒤에 잘 정리해서 전달해주면 조직 전체적으로 같은 에러에 대해서 투입되는 시간이 훨씬 절감된다는 점 또한 깨달았었습니다.

그리고, 추가적으로 제가 조사하고 정리한 지식일지라도 나중에 그것을 다시 활용할 일이 있을때 시간이 지나면 기억이 휘발되어서 기억이 안나는 부분들은 다시 조사를 해야하는 것을 겪었었습니다. 그런데 문서화를 해놓고 나니 기억이 안나는 부분이 있으면 해당하는 문서를 다시보고 그대로 시행하면 되니 효율이 높아진 경험이 있었습니다.

즉, 어떠한 사항들을 팀원들에게 명확하게 정리해서 공유하기 위해서, 그리고 미래의 자신또한 보고 참고할 수 있어진다는 점에서 기록, 문서화의 효용성을 느꼈고 앞으로도 기록을 잘 해 나가야겟다는 생각을 하게 되었습니다.

profile
효율적이고 아름다운 코드를 쓰고싶은 호기심 많은 개발자입니다.

3개의 댓글

comment-user-thumbnail
2021년 1월 3일

연욱님 길고 재미있는 글 잘 봤습니다! 앞으로 제 업무에도 많이 도움될 것 같아요 :) 고맙습니다!!

답글 달기
comment-user-thumbnail
2021년 1월 27일

와 대박 연욱님 대박

답글 달기
comment-user-thumbnail
2021년 1월 27일

자극 많이 받고 갑니다 연욱님!

답글 달기