개발자인 친구(FrontEnd개발자)와 그 친구의 친구(BackEnd 개발자)와 함께 내 생에 첫 외주 프로젝트를 진행했다.
이번 글에서는 첫 외주를 진행하며 내가 느낀 경험을 정리하듯이 작성할 예정입니당
프로젝트를 진행하며
프로젝트는 온라인 쇼핑몰의 백오피스 웹이며, 사용자가 N 플랫폼의 쇼핑 및 플레이스 서비스에 등록한 목록들의 관리가 주된 목적이였다.
처음 기획안을 봤을때는 "아이 뭐, 어려울줄 알았는데 괜찬네?ㅋ" 라는 반응이였지만, 이러한 생각은 그리 오래가지 못했다.
첫 번째 시련. feat_데이터_차트
나는 데이터를 2차원 배열 형식 차트 테이블 컴포넌트를 개발을 담당했다. 단순한 차트 테이블이 아닌 입력할 수 있는 필드가 있는 컴포넌트이며, 입력시 입력한 문자열의 길이만큼 필드의 너비가 넓어져야 한다.
추가적으로 조그마한 기능들이 추가되며, 어찌어찌 컴포넌트의 완성이 되었지만 결과는 그리 좋지 않았다.....
공용으로 사용되야하는 테이블 컴포넌트에 너무 많은 기능들이 주입되며 컴포넌트의 무게가 증가하고 범용성 또한 낮아졌다. (이런걸 기능의 응집도가 높아졌다고 한다더라......)
데이터를 로드 및 가공한다면 데이터의 양식을 통일하는 과정이 추가적으로 필요하다. 즉, 내가 처음 구현했던 페이지에서만 사용 가능한 컴포넌트가 된것이다.....
절대 공용 컴포넌트라 말 할 수 없는 컴포넌트가 완성되었다.
이를 해결하기 위해 가장 먼저한 작업은 기능 분리이다. 동료 개발자로 부터 피드백을 받았다. 해당 컴포넌트의 목적은 공용 UI 컴포넌트이며, 받은 데이터를 2차원 차트로 보여주는 컴포넌트이다. 하지만, 나는 데이터의 로드, 가공, 렌더링 기능을 갖고 있는 컴포넌트였다. 이러한 기능들 중 데이터 로드와 가공 기능을 추출해서 페이지단에서 추출한 기능들이 동작할 수 있도록 작업을 진행했다. → 데이터 로드와 가공은 부모 컴포넌트에서 JSX.Element타입의 값으로 가공하여 공용 컴포넌트의 props로 전달하여 렌더링을 진행한다.
이러한 설계 방법을 통해 새로 개발한 공용 컴포넌트는 오직 렌더링 기능만 담당하는 공용 컴포넌트로 만들 수 있었다.
현업 개발 경험
흠... 이 부분이 참 낮설고 적응하기 힘들었다....
외주 개발을 처음 경험했고, 실제 현업에서 사용하는 개발 프로세스를 처음 경험하며 어떻게 해야할지 참 어려웠다.
그 중 가장 힘들었던 경험은 바로 피드백 반영이다.
개발의 경우 프로젝트를 진행하며 개발 능력을 기르며 적응하는데에 큰 어려움이 없었다.하지만 기획자와 디자이너 그리고 클라이언트로 부터 받은 피드백을 적용하는 과정이 힘들었다.전달받은 피드백의 의도를 파악하고, 내가 이해한 내용이 맞는지 확인, 새로운 기능 설계 등의 작업이 많았다.
사실 이러한 프로세스가 낮설었던 이유는 내가 지금까지 경험하지 못한 과정이 많았기 때문이다.....
클라이언트의 의견 반영의 경우 매 미팅마다 수정사항이 있을 수 있었고 요청사항에 대응하는 시간이 추가되어 마감 기한을 맞추는데 어려움이 있었다.또한 마감 기한이라는 한정된 개발 기간이 존재한다는 것도 압박감으로 많이 느껴졌다.외주를 진행하며 계약이란 것을 하고, 계약 기간내에 프로젝트를 완성하여 납품을 해야한다.기존의 프로젝트는 개인 혹은 팀원의 개인 사정을 반영하여 개발 기간을 연장시킬 수 있었던 반면에 계약 기간이 한정되어 있다는 점이 나에게는 많이 부담이 되었던것 같다.....
그럼 좋은 점은 없었나요?
물론 있다.
새로운 기술 학습
Tailwind 사용
이번 프로젝트에서는 CSS-in-JS나 SASS 와 같은 스타일링이 아닌 Tailwind를 이용한 스타일링을 진행했다.
물론 처음에는 Tailwind의 문법을 학습하는데 어려움이 있었고, 동료 개발자와 컨벤션을 통일하는데에 어려움이 있었지만, 사용하다 보니 참 매력적인 기술이라 생각되었다.
빠르게 개발을 진행해야 하는 환경 뿐만 아니라 일반 개발환경에서도 클래스를 작성하지 않아도 된다는 점과 이를 통해 빠르게 개발할 수 있다는 점, 또한 아주 자세하게 설명해주는 공식문서까지 좋은 기술인것같다.
물론 단점도 존재했다.
처음 학습할 때는 러닝커브가 있다는 점이다. 아무래도 class(Name)(으)로 스타일을 지정하다 보니 각 클래스마다 어떻게 스타일이 적용되는지 학습해야 한다.
또한 구현하고자 하는 스타일이 복잡해지면 클래스 코드가 길어짐에 따라 코드의 가독성이 떯어진다는 문제가 있기는하다.
나는 코드의 가독성 문제의 경우 요소들의 분리를 통해 스타일을 분리 구현하거나 동적 스타일링의경우 인라인 스타일을 추가해 개발을 진행했다....
공용 컴포넌트 개발
위에서도 이야기 했지만 공용 컴포넌트 개발을 담당하게 되었다.
이전에 진행했던 프로젝트에서도 공용 컴포넌트를 개발했었지만, 내가 지금 코드를 보니 참 공용으로 사용하기 힘든 코드를 만들었다 생각된다.
하지만 이번 프로젝트를 진행하며 공용 컴포넌트에 필요한 데이터를 가공 및 로등하는 동작은 다른 곳에서 진행하고 실제 공용 컴포넌트에는 필요한 데이터만 전달하는 방식의 개발을 진행했다.
이게 이전에 학습했던 SOLID 원칙에 준하는 컴포넌트 설계 방법인것같다. 그동안 잘 적용하지 못했던것 같다.....
몸으로 경험해야 아는 나.....
프로젝트를 마무리하며
한달 정도의 기간동안 빠르게 개발을 진해하려 노력했던 프로젝트이다. 실제 현업을 경험하고 현직 개발자와 함께 개발한다는 기회가 취업전에는 쉽게 찾아오지 못하는 경험이라 더욱더 귀한 경험이었던 같다.
물론 내가 부족한 점도 잘 알게되었다. 우선 구현 능력을 더 늘렸으면 하는 개인적 바램이 생겼다. 꾸준히 코테문제를 풀고는 있지만 아직 내가 부족한것을 깨닫게 되엇다. (배움에는 끝이 없다....)
또한 현직에서는 이슈 대응을 어떻게 해는지와 얼마나 중요한지 알게되었다. 지금은 라이브 서비스를 제공하는 프로젝트가 아니지만 그럼에도 불구하고 이슈가 계속해서 발생할 수 있기에 서비스 제공에 문제가 될 수 있는 이슈를 대응하는 것이 정말 중요하다고 배웠다.
개발자 커리어를 시작하기 전에 본격적으로 현업 개발을 경험할 수 있는 기회를 제공한 동료분들에게 감사하고 끝까지 도움을 준 동료들과 구글에게 감사를 표한다.
현재 개발업의 상황이 신입 개발자들 뿐만 아니라 경력 개발자들에게도 힘든 상황이지만 꾸준하게 발전하도록 노력하고 행동하는 사람들에게는 더 좋은 기회가 올것임을 믿고 갈 길을 묵묵히 걸어가자.
'회고록' 카테고리의 다른 글
| 오랜만에 쓰는 주저리주저리 (0) | 2024.10.08 |
|---|
