프로젝트
Markup
React 퍼블리싱 100%
2024.04.28 ~ 2024.08.14
우리은행 e-스포츠관 구축
담당업무
React 3번째 프로젝트 참가. 이번 프로젝트는 기다리고 기다리던 신규 구축건. 퍼블리싱 PL로 참가하여 사용자 화면을 전담하여 진행.
도전해 본 것들
React를 사용해서 페이지 구축을 시작해 볼 수 있었던 것이 가장 크겠다. 그리고 Next.js를 사용해 볼 수 있었다.
원해 마지않던 React 구축을 진행하게 되어서 기대 반 걱정 반으로 프로젝트에 임했다. 특히 프레임워크로 Next.js를 사용하게 되면서 제반지식이 부족했기에 추가 공부를 하며 프로젝트를 진행하게 되었다.
초반 담당 개발자와 함께 시행착오를 통해 가닥을 잡으면서(개발 측에서 방향을 잡아줘서) 퍼블작업 시 관리해야 할 폴더와 건드리지 말아야 할 폴더 등이 정의되면서 작업에 속도가 붙기 시작했다. 일단 일정이 살인적인 일정이어서 조급한 마음도 있었던 것 같다.
대체로 퍼블이 나와야만 개발이 진행 가능했기 때문에 촉박한 일정을 메꾸기 위해 페이지를 뽑는데 집중을 했다. 페이지 본수는 적은 편이었지만, 약간의 테마성 구분도 필요했기에 규모는 작지만 퍼블작업에 필요한 큰 범위의 작업은 나름 알차게 경험한 느낌이다.
컴포넌트에 대한 고찰이 필요했는데 초반 너무 정신없던 살인적인 일정이라 재활용성을 고려한 코드의 품질보다 페이지를 만들어내는 과정이 우선시되어야 했던 부분은 계속 아쉽게 생각된다. 첫날 일정을 받아보고 바로 즉답을 했던 게 기억난다. ‘정말 살인적인 일정이군요..’ 퍼블이 나와야 개발이 진행되니 압박감이 더 크게 작용했었다.
차세대 계열 마크업을 시작하면서 데이터가 실제로 화면에 렌더링 되는 여러 조건들을 퍼블에서 제어가 수월해지면서 좀 더 개발의 부담을 줄이는 방향으로, 반대로 말하자면 퍼블의 업무가 늘어나는 것을 알 수 있었고 조건에 대한 각각의 구분을 잘 잡아 놓으면 개발이 실제 데이터를 사용하여 개발할 경우 작업 부담이 줄 수 있다는 것을 실감했다. 퍼블에서 각각의 경우의 수를 사전에 마크업 하고 json을 사용한 더미데이터를 활용하여 확인하는 과정이 이제는 필수가 되었다는 생각이 든다. 저수준의 스크립트와 React의 useState, props, 조건식(if, switch, 삼항식), map, filter 등을 이해하고 있다면 로컬환경에서 더미데이터를 사용하여 페이지를 생성하고 경우의 수를 확인하며 마크업 작업을 진행할 수 있을 것이라는 판단이 들었다.
개인적으로 부족한 부분이라면 당연하게도 state의 관리. 인강을 통해 혼자 공부하며 익히던 것과는 사뭇 다른 방식의 현장의 코드를 보며 한숨만 나왔다. 그래도 마크업 소스가 필요한 조건에 맞춰서 잘 만들어져 있다면 개발에서도 소스를 변경하는 일이 변수명 변경 정도로 줄어들고 추후 개발이 붙는다 해도 마크업 수정이 수월하다는 것을 체감했다.
새로 배운 것들
Next.js + Typescript를 조금 접해 볼 수 있었지만 개발 측에서 개발단과 퍼블단의 구분차원에서 퍼블작업은 jsx만을 사용하길 원해서 제대로 된 사용은 해볼 수 없었지만, 활용법에 대해서는 조금 이해할 수 있었던 기회였다.
이번 프로젝트에서는 Tailwind를 사용해 봤다. 개인적으로 잠깐 들여다본 정도였지만 여기저기 사용하는 곳이 심심치 않은 것 같아 도입을 해 볼 수 있었다. 부트스트랩과 별반 차이 없는 방법이기 때문에 사용 자체에는 큰 문제가 없었다. 라이브러리 나름의 사용법은 있지만 개념을 이해하면 도입이 어려운 것은 아니라는 것을 알 수 있었다.
React처럼 컴포넌트 단위로 진행되는 코딩에서는 특히 사용이 수월한 느낌이 있었다. 초반 디자인에서 만들어지는 컴포넌트 디자인이 단위별로 잘 만들어져 있다면 작업은 훨씬 작업량이 줄어들 것 같았다. 단지, 작업자에 따라서 호불호가 갈릴 것으로 보이며 마크업을 담당하는 사람이 개발소스까지 건드리면서 오류가 발생하지 않을 정도의 숙련도가 요구되는 것 같다.
Next.js도 처음으로 접하게 되었다. 초반 폴더관리에 대해 약간 헤매긴 했지만 전체적으로 마크업 관점에서 보자면 사용 자체는 어렵지 않다는 생각이 들었다. 세세한 설정등을 개발에서 잡아주었기에 가능한 것이었지만 정말 많은 설정이 필요하다는 것을 알게 되었는데 항상 가지고 있던 희망사항, 프런트앤드로의 전직에 의구심을 가지게 되었다. 난 프런트앤드로 넘어갈 수 있을까?
프로젝트 후반, CSS 관리에 대해 개선해야 할 부분이 보였다. 초기 마크업 단계에서는 jsx가 있는 폴더에 동일한 명칭으로 파일을 두고 진행해도 상관없었지만, 개발이 진행될 때 개발자들이 파일을 그대로 복사해서 사용하는 경우가 있었고 결국 중복된 파일이 생성되며, 약간 관리가 귀찮아지는 문제가 있었는데 CSS의 패스, 우선순위가 뒤틀리는 경우가 있었다. 결국 초기부터 기존 레거시 프로젝트와 마찬가지로 스타일 폴더를 구분해서 작업하는 게 수월할 수도 있을 것 같다. styled-components는 개발요청으로 선택지에서 배제하였는데 이전 프로젝트에서 사용했었는데 관리상 추천하는 방식이 아니었다고 한 것으로 기억된다.
아쉬운 점
초반의 시행착오는 피할 수 없는 부분이었다. 특히 폴더구조를 정하는 방법이 익숙하지 않았던 것 같다. 개인적으로는 타입스크립트를 활용한 마크업 작업에 대한 경험치를 올리고 싶었지만 그러지 못했다. 준비가 부족했던 면도 있지만, 무엇보다 개발에서 원하는 수준의 타입스크립트를 활용하지 못했기 때문에 더 크게 아쉬움을 느끼게 된 것인지 모르겠다.
이른바 차세대 프로젝트로 불리는 Vue, React의 경우 개발과 퍼블의 경계를 구분하는 것이 상당히 애매해진 것을 느꼈다. 개발의 고충(?)을 이해하기 쉬웠다. 아쉬운 건 개인의 능력과 초반 빡빡했던 일정. 항상 느끼게 되고 항상 후회하게 되는 부분은 마크업을 좀 더 잘 짤 수 있지 않았을까 하는 부분이다. 시간에 쫓겨서 작업을 하다 보니 그 순간에 최선을 다했다고는 하지만, 작업 후반 뒤에서 수정하고 싶은 욕구가 나올 수밖에 없다. 그나마 React로 넘어오면서 이런 과정이 조금은 수월해졌지만 그래도 개발 리소스와의 충돌을 피하기 위해선 조심스럽기에 범위가 한정된다.
마크업 관점에서 React는 확실히 할 수 있는 범위가 넓어진 것을 재차 확인할 수 있었다. 문제는 스크립트에 좀 더 많은 지식이 필요하다는 것이라 생각된다. 간단한 스크립트는 제어가 가능하지만, 아직 난도가 있는 스크립트는 어렵다는 것을 알았다.
또한, 슬프지만 아직 내가 타입스크립트를 건들건 아니구나를 알았다.. 초반 tsx 타입으로 마크업을 진행하였지만, 개발자와의 의견 조율로 퍼블(사용자 화면)은 jsx로 작업을 진행하고 개발은 자동화를 수월하게 하기 위해 tsx를 사용하는 방향으로 가닥이 잡혔다.
당연한 결과라 생각된다. 실제로 다루어지는 데이터가 어떤 타입인지를 퍼블 단계에서 정의를 내리고 작업을 진행하기엔 난관이 있기 때문에 결국 모든 타입을 any로 진행을 할 수밖에 없었던 것이 문제라 여겨진다.
최근의 구인공고에서 프론트가 아닌 퍼블에게 타입스크립트를 요구하는 것을 심심치 않게 보는데 적절한 구인 내용은 아니라는 생각이 들었는데 퍼블에서 제대로 정의가 가능한 범위는 애매하다는 생각이 들었기 때문. 이유라면 DB에서 어떤 식으로 관리하는지에 따라 또 달라지는 부분이라 생각되기 때문이다. 결국 가장 포괄적인 any를 남발할 수밖에 없고 개발은 결국 매번 고쳐야 하니 귀찮아하지 않을 수 없겠다.(당연히 타입스크립트를 잘 알고 있다면 다르겠지만..)
마무리
3개월이라는 짧은 기간이었지만 개발일정을 위해 초반 보름 정도를 혼자서 정말 미친 듯이 달렸던 것 같다. 다행히 접근성 프로젝트가 아니어서 난이도가 줄어든 경향이 있다. 만약 접근성까지 대비해야 했다면 이번 프로젝트는 기간 내에 마무리하지 못했을 것이다.
처음으로 구축으로 React 프로젝트를 수행해 본 결과 마크업 단계까지의 업무라면 무난히 수행할 수 있을 것이라 생각되었다. 상태관리는 부모에서 자식으로 넘기는 부분은 대체로 문제가 없지만, 자식 컴포넌트에서 부모로 데이터를 전달해야 하는 경우는 아직도 어렵다. 결국 Redux류의 상태관리에 대한 지식이 절대적으로 필요하다는 것을 알았다.(공부할 때와 달리 실전에서는 뭔가 떠오르질 않는다..)