web builder를 만든 주니어 프엔 개발자의 회고

1년 동안 열심히 만든 회사 프로덕트가 드디어 배포를 하였습니다~!!🎉
https://qshop.ai/

 

저희 팀이 만든 프로덕트는 웹사이트를 만들어주는 Web Builder라는 것입니다.
사이트를 드래그&드롭 만으로도 만들 수 있게 해줍니다.

 

다양한 이벤트(키보드, 마우스..)가 사용되는 제품인 만큼 이벤트를 숙련도 있게 다루어야 했습니다. 프론트엔드 개발자로서 할 수 있는 흥미로운 과제라고 생각합니다. 그만큼 에러도.. 많이 발생했고 죽을뻔 했고 QA에 고생하는 요즘입니다😇

 

1. 기억에 남는 배운점들

업무를 분석하고 계획하는 법 (agile~!)

 

기획팀이 들어오면서 업무를 체계적으로 분석하고 계획하는 방법을 알게 되었습니다. 스프린트, 백로그, 칸반, 스토리포인트, 스크럼, 회고! 애자일 프로세스가 어떻게 돌아가는지 익숙해졌습니다. 업무 방식으로 인해 해야할 일과 전체 프로젝트의 진행상황이 잘 보이니까 마음이 편해졌습니다.

 

타 팀원의 칸반을 볼 수 있으니 도움을 주거나 받기 편했습니다. 나의 일이 먼저 끝난다면 다른 분들을 도우러 갈 수도 있구요. 스토리포인트도 너무 좋았습니다. 스토리포인트는 업무에 드는 시간을 포인트로 환산한 것입니다. 저희는 1시간 단위로 포인트를 산정합니다.

 

회고는 특히! 서로의 회고록에 피드백을 달아주면서 응원도 하고 도움이 되는 글도 적어주는 문화가 좋았습니다. 회고하는 시간이 은근 기대되었어요ㅎㅎ

 

회사에는 개발자만 있는 것이 아니구나

원래 프로젝트는 자바스크립트로 시작했습니다. 리액트로 프로젝트의 기술을 바꾸기로 했죠. 제가 대표님에게 그 이유를 설명하려 했었습니다. 저는 “개발자”의 입장에서 어려운 것들을 적어갔습니다. 파일을 찾기 어렵고, 개발이 불편하다는 느낌의 주장을 했었던 것 같습니다.

 

시니어님 제가 하는 말을 듣고는 대표님이 더 알아 듣기 좋은 방식으로 말씀하셨습니다. 리액트를 사용하면 다른 팀과 기술을 맞출 수 있고, 추후에 데스크톱 앱으로의 확장도 편하다고 말이지요.

회사에는 개발자만 있는 것이 아니구나 다시 한 번 깨달았습니다. 각자 분야에서는 서로 필요한 것이 다릅니다. 분야가 다른 팀원을 설득하려면 그 사람의 입장에서 무엇이 필요할까를 먼저 생각하는게 중요하다고 느꼈습니다.

 

2. 기억에 남는 구현이나 기여에 대해서

단축키

 

단축키를 처음부터 끝까지 개발했습니다.🕺🕺🕺

단축키 기능에는 이런 것들이 포함됩니다.

• ctrl + c,v 를 사용해서 요소를 복사 붙여넣을 수 있습니다.
• ctrl + s로 제작중인 페이지의 상태를 저장할 수 있습니다.
• ctrl + z로 이전 작업을 불러올 수 있습니다.
• 그 외에도.. 단축키만 84개가 됩니다. (죽는 줄..)

 

웹상에서 단축키를 매핑하는 것은 처음이어서 여러가지 궁금한 것들이 많았습니다.

• 사용자의 키보드 입력값을 받아들이고 구분하는 함수는 어떻게 구성할까?
• 입력값에 맞게 행동하는 함수들은 어떻게 구현할까?

 

그 과정에서 가독성이 좋은 함수 구조를 고민해보기도 하고, Hash 자료 구조를 어떻게 사용할 지도 고민하는 유익한 시간이었습니다. 현업에서 자료구조를 고민하여 적용하는 일도 해보는구나 싶었습니다.

 

단축키 하나하나가 돌아가려면 정말 많은 함수를 짜야 합니다. 그리고 그 함수들이 한 번만 쓰이는 것이 아니라 다른 함수의 내부에서 쓰이기도 합니다. 혹은 아예 다른 컴포넌트에서 필요하기도 하죠. 어떻게 하면 재사용성하기 편하게 사용할지 고민했습니다. 함수를 기능 단위로 최대한 나누었죠.

 

익숙하지 않아서 만드는 과정은 어려웠지만, 다 만들고 나서 단축키가 작동할 때에는 뿌듯했습니다.

 

페이지

 

좋은 기억인지 나쁜 기억인지는 모르겠지만 어쨌든 기억에 남습니다. 이 기능을 구현하기 위해 여러 사람들과 소통했습니다. 특히 서버와 통신을 정말 많이 하는 기능이었습니다.

• 사용자가 페이지를 드래그 앤 드롭을 한다. 위치에 따라 상위 페이지와 하위 페이지가 바뀐다.
• 드롭을 한 위치에서 상위 페이지가 무엇인지, 위치는 어디인지에 대한 정보를 서버에 보낸다.
• 서버에서 이 정보들을 받아 리스트를 다시 정렬한 후 보내준다. 정렬된 리스트를 프론트 측에서 받아 다시 보여준다.

 

라이브러리와 API가 복잡하게 얽혀 있어 어려운 과제였습니다. 덕분에 시니어님과 기획팀, 서버팀 사이를 부지런히 오갔던 기억이 납니다.

• 백엔드팀 : 서버에서 제한해야 하는 사항으로 인해
• 기획팀 : 라이브러리 구현 상 안 되는 것들을 설명드리고 대안을 찾기 위해
• 시니어님 : 어떻게 해야 에러가 덜 나는 구조를 짤 수 있는지 여쭈어보기 위해

 

이 기능을 구현하면서, 프론트엔드 개발자는 코딩도 중요하지만 여러 사람들 사이에서 중재하는 역할도 중요하다는 생각이 들었습니다.

 

3. 스스로 부족했다고 생각하는 점

빠르고 안전하게 짠 코드가 최고

한 때 가독성이 좋고 구조가 명확한 코드를 짜는 것이 중요하다고 생각했습니다. 중요하긴 하지만, 회사마다 필요한 개발의 방식이 있는 것 같습니다. 출시를 앞둔 회사의 경우, 개발을 빠르게 하고 테스트를 많이 돌려보는게 가장 좋은 개발 방식이라고 생각합니다. (리팩토링은 나중에 언젠가 정말 필요할 때..)

 

예전에 같은 팀원의 회고에서도 느낀 것인데, 프로그램을 코딩하는 것은 돌아가게 만드는 것이 다가 아닙니다. “잘”돌아가게 만들어야 코딩이 마무리되는 것 같아요. 테스트에 대한 새로운 시각을 얻었습니다.

 

익숙한 방법으로만 개발을 하고 있지는 않았나?

회사는 내 기술력을 높이는 곳이 아니고 내가 가진 기술력을 쏟아 붓는 곳입니다. 기술력은 각자가 알아서 채워와야 하는 것이구요. 요즘은 개인적으로 프로젝트도 하면서 기술력을 갈고 닦으려고 노력하고 있습니다🔥 (다만 너무 바빠서 못하고 있는 중)

 

도움을 적극적으로 요청하자

입사 초기 부터 프로젝트의 프로토타입을 혼자 제작했어야 했습니다. 다들 바빠 보여서 그런지, 저는 그 때 정말로 혼자서 해야 한다고 생각했었습니다. 길을 잃어도 깨닫지 못했던 적이 있었습니다. 시니어님이 이를 캐치하여 피드백을 주셨습니다. 주변 개발자와 동료에게 도움을 잘 요청할 수 있어야 한다는 내용이었어요.

 

지금은 주변 동료들에게 도움을 받는 데에 많이 열려 있게 되었습니다. 바빠 보여도 도움을 청하려고 노력한 결과지요. 요즘은 너무 많이 도움을 받는 것 같습니다. 스스로 성장했구나 싶지만서도 죄송한 마음도 있습니다.🙏

 

4. 스스로 잘했다고 생각하는 점

회사 블로그에 글을 나름 열심히 썼다

팀원들을 보면 각자 장점들을 하나씩 가지고 있더라구요. 제 장점이 무엇일까 곰곰이 생각해보니 글을 열심히 쓴다는 것이었습니다. 회사 내 블로그에 8개의 글을 작성해서 올렸습니다. 주로 제가 공부했던 것이나 구현했던 것에 대한 팁들입니다. (이 블로그에도 잘 필터링해서 올릴 예정!)

 

몹시 매력적인 글을 쓰는 것이 아니더라도 이런 행동이 문서를 정리하는 문화에 도움이 되지 않을까 생각하면서 차근차근 했습니다.

 

부족하거나 잘못

한 것을 인정하고 고치려고 노력했다

지금 돌이켜보니 “스스로 부족했다고 생각하는 점” 에서 적은 것들을 해결하려고 노력했었습니다. 배운 것도 많고 성장한 것도 많은 것 같아요. 더 소통하고, 더 빠르고 안전하게 코딩하고, 모르는 것들은 적어두고 알려고 노력 중입니다ㅎㅎ

 

5. 개발적으로 어려웠던 것들

헤더에서의 실패에서 느낀 경험 부족, 예외처리는 무조건 안전하게

에디터를 모두 같이 사용해보는 자리에서 헤더에서 심각한 오류가 발생했었습니다. 페이지가 다운이 되어버리는 큰 오류였습니다. 기존 헤더는 사진과 같이 상세 설정으로만 설정 가능했습니다. 예외처리 코드를 제대로 작성을 안하여 발생한 것이었습니다.

 

사용자가 많다보니 여러 테스트케이스가 나올 수 밖에 없고, 보수적으로 예외처리를 했어야 했습니다. 그 이후 엥간하면 ?? 연산자 를 사용하거나 옵셔널 체이닝 연산자를 사용하고 있습니다.

 

텍스트, 필요한 기능인지 생각은 해봤니?

Quill Editor라는 텍스트 라이브러리를 사용했습니다. 기존 라이브러리에서 새로운 기능을 붙이느라 커스텀을 많이 했습니다. 그러다보니 기능이 제대로 실행되지 않더라구요.. 결국 기획팀과 긴 논의 끝에 커스텀한 기능들을 상당 부분 덜어냈습니다.

• 새로운 기능들을 붙일 때 나중에 문제가 될 수도 있겠다고 생각하는 시야가 생기면 좋겠다고 생각했습니다.
• 기능을 붙일 때 정말 필요한 기능인지 기획팀과 깊은 논의가 필요합니다!

 

6. 아쉬웠고, 앞으로 나아졌으면 하는게 있다면?

서로의 코드를 알자!

사용자가 생기고 나서는 코드 한 줄 한줄도 검증해야할 것만 같은 불안감이 있습니다. 각자 서로의 코드를 검증하고 합치는 과정이 당연하다고 생각하는데, 애석하게도 그렇게 하지 못하고 있습니다.

누군가가 부재하거나 업무를 대신 맡아야 할 때에 효율적으로 일하기 위해서는 서로의 코드를 알아야 합니다. 최근에는 스토리포인트를 따로 내어서 서로 코드에 대해서 리뷰하는 시간을 가지고 있습니다. 서로의 코드를 확인해주는 pull request도 강력하게 건의하여 다시 시작할 예정입니다.

 

테스트는 어떻게 하는 것이 좋을까?

사용자가 있다보니 테스트를 어떻게 하는게 좋을까 고민이 됩니다. 테스트 방법론 같은 것도 공부해보면 좋을 듯합니다. 요즈음에는 Jest나 테스트 시그마에 대해서 관심을 가지고 있습니다. 각각 장단점이 있습니다. [Jest]

 

개발자가 테스트 케이스를 다루기 쉽습니다. 개발단에서 사용하던 함수를 가져다가 사용할 수 있어서 (개발자에게는) 몹시 편합니다. 다만, 비개발자는 테스트를 돌리기 조차 힘듭니다. [Test Sigma]

 

개발자가 아닌 누구라도 테스트 케이스를 작성할 수 있습니다. 그냥 웹사이트를 편하게 사용하기만 하면 알아서 녹화하고 행동을 분석하여 테스트 케이스로 만들어줍니다. 다만, 예외처리가 상당히 힘들 수 있습니다.

 

*일단 일과 외 시간에 테스트 시그마를 사용해보면서 검증해보려고 합니다.*

 

7. TMI

기획팀이 제 옆자리에 왔던 초반에는 소통에 대한 고민이 있었습니다. 기획팀과 자주 소통을 하다보니 제가 구현하던 것을 중간에 까먹는 경우가 종종 있었습니다. 그래서 흐름이 끊기지 않고 구현을 해야할 때에는 이런 친구를 사용하기도 했습니다.

 

 

지금은 제가 더 기획팀에 더 말을 많이 겁니다. 괜찮다고 하시긴 하지만, 타인에게 질문을 할 때에는 시간이 되는지부터 정중하게 물어봐야 할 것 같습니다.