대략적인 프론트엔드의 초기 형태를 구현했다. 디테일한 부분까지 신경 쓰지는 않고, 수정해야 할 부분도 많은데도 불구하고, 자꾸 욕심이 생기다 보니 프론트엔드에 시간을 조금 많이 투자했다. AI를 통해서 대부분 작업을 마쳤지만, 아직까지는 내가 개입하거나 수정해야 할 부분이 많기도 했고, 프론트엔드 개발자가 아니라서 조금 많이 헤매기도 했다. 대략적인 완성 형태는 다음과 같다.
프로토타입 살펴보기
전체적인 화면 구성은 인스타그램을 많이 참조했다. 사실상 베끼기에 가까운 UI를 구성하고 싶었는데, 능력이 부족해서 결국은 독자적인 형태를 가질 수 없었다는 슬픈 사실이 남아있다. USER 마이크로서비스는 기능이 완성되어 있어서 화면 말고도 기능 테스트도 마쳤는데, 우선 단순 기능적인 측면에서 로그인, 프로필 수정은 정상적인 동작을 확인했다. 개발이 필요한 CHALLENGE 마이크로서비스는 프론트엔드 화면을 만들어보면서 어떤 기능들이 필요한지 생각해 볼 수 있었다.
메인화면
사용자가 올린 도전의 피드를 확인할 수 있으며, 화면의 모드 전환, 로그인, 도전 공유 등의 기능을 사용할 수 있는 메인화면이다. 화면 자체는 순조롭게 구성했으나, 로그인을 위한 화면에서 기존의 레이아웃을 제외하는 방법을 잘 몰라서 조금 시간을 썼다. 이 레이아웃의 각기 다른 적용은 이전 포스팅에서 해결 방법을 정리했다.
사용자 프로필 홈
사용자의 프로필 홈으로, 가장 단순한 형태만 구현했다. 해당 사용자가 작성한 글 리스트를 볼 수 있고, 게시글을 누르면 상세 내용을 볼 수 있는 화면이다. 좋아요와 댓글을 남길 수도 있다. 모달 화면에서 보여지는 형태나 동작을 구현하는 데 약간 고생했다.
로그인과 프로필 변경
OAuth를 통한 로그인과 사용자의 프로필 변경 화면이다. 화면적으로는 특이사항은 없다. OAuth 기능은 별다른 문제 없이 바로 제대로 된 동작을 확인했다.(시연 단계에서는 이전의 토큰 정보 때문에 별다른 Google 인증 없이 바로 넘어 갔다) 프로필 이미지 변경의 경우는 백엔드에서의 파일 업로드에서 약간 버벅이긴 했지만, 큰 문제 없이 기능적인 부분도 모두 확인을 완료한 페이지다.
도전 공유
별것 아닌 것 같아 보였고, 결과물도 썩 퀄리티가 좋아 보이진 않지만 정말 많은 시간을 썼던 도전 공유의 글쓰기 화면이었다. 이미지 자르기와 함께, 이미지 보정(필터 적용 등) 기능도 넣고 싶었는데, 아무래도 시간을 너무 잡아먹을 것 같아서 빼버렸다. 원래 프로젝트의 핵심 기능 겸 요소라고 생각했던 도전장 작성하고 커스터마이징하는 기능을 제대로 보여주고 싶었는데 쉽지는 않았다.
따로 프론트엔드 개발자가 있었으면 했던 화면이다. 우선 현재는 이 정도 수준에서 만족하고 있다.
빠른 구현을 위해 사용했던 것
디자인 초안은 V0에게
이전에 이미 언급 했지만, 다시 한번 소개 하자면, 디자인 초안은 V0 를 통해 만들었다.
그냥 원하는 요청사항을 요구하면 알아서 만들어 준다. 한국어로 해도 잘 동작할지는 의문이여서, 프롬프트는 파파고로 번역 후, 사용했다. 프로필 컴포넌트에 대해서 필요한 사항을 하나씩 나열하고 아래와 같이 만들어 달라고 요청 했다.
그리고 그 응답으로 화면을 확인 해 볼 수 있고, 코드도 제공 해 준다. 다만 제공 해 주는 코드는 React코드로 나는 이 코드 자체를 ChatGPT에게 다시 Svelte 코드로 변환 요청해서 만들었다.
ChatGPT에게도 디자인을 따로 부탁 해 보기도 했었는데, V0쪽이 프론트엔드 디자인에 특화되었기에 결과물에 대한 퀄리티가 훨씬 뛰어났다. 동일한 프롬프트를 ChatGPT와 V0에 요청 해 봤는데 V0쪽이 내가 놓치고 있던 부분까지 잘 보완하고 잘 만들어 줬다.
무료 사용으로 쓰면서 하루에 토큰 제한이 걸리곤 했는데, 그냥 다음날 또 요구하면 그만이라 큰 제한 없이 사용했다. 만약 실무로 사용한다면 React 프론트엔드 개발자라면 충분히 유료 사용의 매력이 있을 것 같아 보였다.
이미 있는 기능은 다시 만들지 않기
Svelte를 사용하면서 캘린더, 이미지 자르기 등 기능을 구현은 정말 쉽게 했다. 이미 충분한 라이브러리가 있어서 이 라이브러리를 사용하면 끝이였다. 정확히는 NPM 라이브러리 중 Svelte 용으로 구현된 기능들을 가져와 사용했다. 일반적인 상황에서 필요한 기능들은 이미 구현된 라이브러리가 있으니 잘 찾아서 사용하기만 하면 된다. 라이브러리의 사용은 공식 문서를 보고 구현하는게 가장 좋았다. 버전별로 사용법이나 설정이 미묘하게 다른 경우가 있어서 그런지 몰라도, ChatGPT에게 물어봐서 구현하는 경우에 약간씩 잘못된 정보를 가져다 주었다. ChatGPT에게 정확한 정보를 얻고 싶다면 공식 문서 자체를 자료로 제공하고 알려달라고 하면 됐는데, 그냥 이 정도 수준은 개발자가 직접 공식문서 보고 사용 해 보는게 좋을 것 같다. 각각의 프로젝트에 따른 특수성이나 예외 상황 등에 대처 할 수 있는 장점이 있기 때문!
SVG로 아이콘 구현하기
웹에서 이미지에서는 해상도에 따라서 이미지 품질 저하 문제를 겪기 쉽다. 만약 여러 해상도에 따라서 이미지를 나눠서 제공한다면 그 관리 포인트도 늘어나고, 용량 문제 등 여러 단점이 존재할 것이다. 따라서 아이콘이나 로고와 같은 특정 이미지를 제공하고 싶을 때에 SVG는 아주 좋은 대안이다. 다만 문제가 있다면 이것을 개발자가 직접 구현하기는 매우 힘들다는 것.
나는 처음에는 SVG도 ChatGPT에게 생성을 요청 했었다. 통일된 퀄리티나 디자인을 제공하지 못하는 이유로 기존에 완성이 되어있는 것들을 사용하기로 했다.
몇 가지 무료 SVG 이미지를 제공하는 사이트를 찾아 보았고, 나는 직접적인 선택은 heroicons를 선택했다. 각기 다른 사이트에서 SVG 이미지를 취사 선택해도 좋으나 디자인 통일성과 같은 문제로 한 번 선택한 스타일은 그대로 유지하는 것이 좋다. 아니면 직접 기존의 스타일과 비교 해 보고 이질감이 없다면 사용해 보자. 다음은 내가 고려했던 무료 SVG 이미지를 제공하는 사이트 목록이다. 무료라고 되어있지만 막상 로그인 혹은 일부 유료정책을 거르다보니 2곳 정도만 찾아보게 되었다.
heroicons는 Tailwind CSS 쪽에서 제공하며, Material Symbols & Icons는 Google에서 제공한다.
이미지 생성도 GPT로
기능 구현 중에서, 도전장의 디자인(스킨)을 사용자가 선택하는 기능을 만들어 보고 싶었다.
그래서 나름의 배경 이미지가 필요했는데 기존에 쓰고 있던 Stable Diffusion을 사용 하자니 이런 배경이미지에 맞는 학습 모델을 또 찾아야 봐야하는 수고로움이 싫어서 ChatGPT로 이미지를 생성하기로 했다. 초기에 ChatGPT (정확히는 DALL·E)로 생성하는 이미지는 동일한 화풍이나 인물(캐릭터)를 구현하기가 어려운게 문제였는데, 배경 이미지는 그런 요구 사항이 필요하지 않았다. 또 어느순간인가부터는 생성된 이미지의 특정 부분을 선택하고, 그 부분에 대한 이미지 변경 내용을 요청 할 수 있는 기능이 생겼다. 그래서 발전된 기능을 활용하면 충분히 몇번만에 내가 요구한 사항을 만들 수 있을 것이라 생각해 배경 이미지를 만들어 보았다.
원하는 느낌은 만들었으나, 가운데에는 글씨가 표시되어야 하기 때문에 문양은 삭제 하고 싶었다. 그래서 지워야 할 부분을 선택하고 그 문양을 지워 달라고 요청 해 보았다.
그리고 그 결과이다. 지워진 문양이 솔직히 깔끔하지는 않다. 얼룩이 진 것 같이 자세히 보면 약간 거슬리는 부분이 있고, 색의 경계가 어색한 부분이 있다. 하지만 이 정도 수준에서 약간의 포토샵 정도 처리만 하면 원하는 퀄리티를 만들 수 있을 것이다.(그리고 요새 포토샵은 자체 AI를 통해 이런 작업 & 이미지 생성도 쉽게 해준다고 한다)
결론적으로 디자이너 없이도 충분히 프로토 타입으로 제공하기에는 충분한 수준의 이미지를 ChatGPT로도 만들어서 사용 해 볼 수 있었다.
구현 삽질기
막상 알고 보면 별것 아닌데 시간을 오래 잡아먹었던 내용을 정리해 본다.
같은 화면은 늘 같도록 처리!
브라우저에서 화면을 표시할 때, 화면 내의 글씨나 콘텐츠의 크기 등에 따라서 화면의 크기가 바뀌고, 매번 보여지는 레이아웃이 조금씩 달라지는 것을 방지해야 했다. 실제로 경험한 요소는 콘텐츠의 길이가 길거나, 화면 크기에 따라서 스크롤바가 표시되거나 되지 않는 것 때문에 CSS가 조금씩 틀어지는 현상을 경험했다. 처음에는 스크롤바의 문제 자체를 인지하지 못하고, CSS 적용에서 문제가 있나 여러 가지 방법을 다 찾다가 갑작스러운 눈썰미에 의해 원인을 발견했다. 프론트엔드 개발자라면 이미 다들 알고 있었을지도 모르겠는데, 나의 경우는 처음 이 사실을 깨달았다. 그래서 아주 간단한 해결 방법으로
<style>
html {
overflow-y: scroll; /* 스크롤 바 항상 표시 (CSS 깨짐 방지) */
}
</style>HTML에 스크롤바를 항상 표시하도록 했다. 이렇게 처리하면 콘텐츠 길이와 상관없이 항상 스크롤바가 표시되기 때문에, 이 스크롤바가 표시되는 것을 기준으로 CSS를 수정하면 되고, 동일한 화면의 형태를 항상 보여줄 수 있게 되었다.
또 이런 식으로 적용하면 좋을 만한 것이 하나 더 있는데,
<style>
box-sizing: border-box;
</style>이 요소이다. 너비 등을 수정할 때, padding이나 border의 값도 포함되어 계산되므로, 원래 의도했던 요소의 사이즈를 그대로 유지할 수 있다.
동적 생성 요소의 CSS는 전역 설정을!
도전 공유하기를 작성하는 모달 화면에서 날짜 선택을 하는 달력이 표시될 때, 달력이 원하는 영역에 표시되지 않아서 정말 고생했다. 해당 달력 기능은 flatpickr라는 라이브러리를 사용했는데, 해당 라이브러리의 옵션 값 등을 찾아보고 이리저리 바꿔보면서 적용했는데 도저히 원하는 방식대로 동작하지 않았다. CSS를 강제로 적용시키고 모든 방법을 적용했는데도 실패했다. 웹 브라우저 상에서 직접 CSS를 적용해 보니 정상적으로 동작하는 것을 확인하고는 Svelte에서 사용법에 문제가 있지 않을까란 의심으로 답을 찾았다. 사실 Svelte가 실행될 때, 해당 CSS가 삭제되었다는 식으로 메시지가 나오고 있었음을 나중에 발견했는데, 모든 문제의 이유를 사실 나에게 알려주고 있었던 것을 내가 바로 알지 못했다. Svelte에만 국한되는 동작은 아닐 것으로 생각하며, 모던 프론트엔드 프레임워크에서도 아마 비슷한 동작을 할 것으로 생각하는데, CSS 적용이 되지 않는 문제의 결론은 다음과 같다.
<style>
:global(.flatpickr-calendar) {
position: fixed;
}
</style>global이라는 키워드로 해결을 바로 할 수 있었다. 이 CSS가 무시되는 이유는 사실 간단한데, 웹 프로젝트가 빌드되는 순간에 사용하지 않는 CSS는 삭제된다. 최대한 자원을 아끼고, 최적화하기 위해 필요 없는 요소는 배제하는 동작 때문이었다. 달력 라이브러리로 인해 동적으로 생성되는 요소인 flatpickr-calendar는 빌드 시점에는 존재하지 않는 요소이며, 코드를 사용한 컴포넌트에서 필요 없는 요소로 인식되어 삭제되기 때문이었다.
반응성이 필요할 땐 $ 문법을!
이전의 포스팅에서는 별도로 Svelte의 store 객체 중, writable를 통한 상태의 변경을 공통으로 관리할 수 있는 방법으로, 변경된 값을 화면에 반영할 수 있도록 하는 방법을 정리했었다. 하지만 막상 개발을 해 보니, $을 통한 문법이 따로 존재했고, 일부 반응성이 생각대로 동작하지 않는 경우에 유용하게 사용할 수 있는 문법임을 알았다.
실제로 겪었던 현상은, OAuth를 통한 로그인 후, 로그인 여부에 따라서 헤더에 접근할 수 있는 기능이 다르고 보여지는 화면이 다르도록 동작하기를 의도했다.
하지만 로그인 성공 이후, 메인 페이지 리다이렉트 이후에 바로 로그인이 적용된 UI가 보이지 않고, 다시 페이지를 재요청해야 하는 문제가 있었다. 로그인에 대한 값 자체는 store 객체로 관리하고 있었음에도, 제대로 동작하고 있지 않았고 페이지 로딩 이후 시점에 다시 화면을 갱신하는 로직을 넣어서 해결했나 싶었는데도 간헐적으로 동일한 문제를 겪었다.
결국 해결책은 $:로 시작하는 문법으로, 읽는 방법 자체는 모르겠으나, 반응성 선언(reactive declarations)에 대한 문법이라고 한다. 이 선언 이후에 사용한 값에 대해서는 데이터의 변경이 일어날 때마다 자동으로 UI 코드를 다시 불러온다고 한다.
<script>
let count = 0;
// 반응성 선언: count가 변경되면 이 코드가 실행.
$: doubled = count * 2;
</script>
<button on:click={() => count += 1}>
Increment count
</button>
<p>Count: {count}</p>
<p>Doubled: {doubled}</p>React나 Vue.js 라이브러리에서는 동일한 기능을 구현하기 위해 useEffect나 watch 같은 메서드를 사용하는데, 이것과 비교하면 훨씬 쉽게 작성이 가능하기 때문에 이 문법 또한 Svelte의 강점이라고 한다.
기타 고생했던 요소들
별것 아니지만 시간을 잡아먹었던 요소는 역시 CSS이다. 사소한 것 하나 바꾸려고 했는데도 원하는 대로 동작하지 않았다. 물론 최대한 TailwindCSS의 문법을 활용해서 바꾸려고 했기에 선택지 자체가 제한되어 있기도 하고, 원하는 대로 동작하는 경우는 정말 따로 미세 조정을 할 필요가 없을 정도로 원하는 디자인이 나왔다. 하지만 여러 컴포넌트가 엮이면서 HTML 구조 자체의 복잡도가 높아지니 사소한 것 하나에도 어려움이 생겼다. 나의 소감은 아래와 같았다.
생성형 AI와의 싸움
결과적으로는 아주 많은 도움을 받았지만서도, 디테일한 부분은 아직까지는 부족하다는 게 내 결론이다. 현재의 GPT-4 o 모델은 물론 과거 모델과 비교하면 비약적인 발전을 이룬 것은 맞지만 역시 디테일한 부분은 약하다는 생각이 든다.
적어도 백엔드 쪽 부분은 명백한 에러 로그를 통해서 무엇이 문제인지 논리적으로 잘 찾아가주는 느낌이 있었는데, 프론트엔드 부분은 원래가 에러 디버깅 자체가 힘들고, CSS와 같은 미묘한 사람이 캐치한 문제에 대해서는 설명하기도 힘들었다. 또 설명을 엄청 꼼꼼히 하기도 하고, 단계적으로 전체 코드와 HTML 구조 코드도 전달하고 해봤는데도 일정 부분 이상 복잡도가 올라가거나 다른 요소와 엮이는 부분이 많아질수록 문제 해결 능력이 떨어졌다.
결론적으로는 같은 문제에 대해서 두 번 이상 질문해도, 동일한 에러를 발생하거나 해결을 못 하고 있는 경우는 직접 디버깅용 console을 출력한다던지, 브레이크포인트를 통해 디버깅하는 식으로 사람이 직접 개입하는 게 훨씬 빠르게 해결할 수 있었다. 글을 쓰고 있는 현재 시점에서 ChatGPT는 대답을 하기 전에 추론 작업을 거친 뒤 답변을 하는 다음 모델의 출시를 조만간 하겠다고 예고했는데, 코딩 쪽에는 비약적인 발전이 있을 것이라고 하니 실제 전체 백엔드 기능이 완성된 이후에 다시 프론트엔드 작업할 때의 성능 차이를 느껴보고 싶다.
글의 초안을 다 쓰고 난 시점에서 기습적으로 GPT-4 o1의 프리뷰 버전이 출시됐다. 추론 기능이 추가됐다고는 하나 아직 기존의 o 버전과는 크게 다른 것을 모르겠다. 다만 o1 정식 출시 버전과 프리뷰의 성능 차이가 꽤 있으므로 추후 개선을 기대해 본다.
보완해야 할 요소들
UI/UX나 여러 디테일한 부분은 개선할 사항이 끝이 없다. 그밖에 인식 자체는 하고 있지만 개선을 나중으로 미룬 요소를 몇 가지 뽑으면 다음과 같다.
보안 & 검증 & 에러 처리 문제
보안
로그인 여부 확인이나 실제 로그인한 사용자의 인증 또는 인가 내용이 맞는지 확인하는 부분은 일단 완전 배제했다. 결론적으로는 백엔드에서의 검증을 통해서 해결할 수 있는 문제이므로, 백엔드 보안을 추가하면서 자연스럽게 프론트엔드에서도 추가 방법을 적용할 것 같다.
검증
검증 쪽은 Validation에 관련된 사항으로, 프론트엔드에서는 솔직히 얼마든지 전달 값 자체를 조작할 수 있다. 이것도 역시 백엔드에서 최종적으로 검증을 해야 하나, 사용자 편의와 같은 문제로, 만약 글자 수 제한 150자의 경우는 사용자에게 더 이상 입력할 수 없음을 화면적으로 제대로 제공하거나, 데이터 제출 시 해당 내용을 수정하라는 알림을 전달하는 방식 등을 고려해서 추가해야 할 부분이 되겠다.
에러 처리
우선은 백엔드 API에서의 스펙이 완벽하게 정해지지 않았기 때문이기도 해서, 구체적인 에러 처리는 하지 않았다. 실제로 에러 처리를 하게 된다면 백엔드에서의 에러 코드를 기반으로 어떤 동작을 하게 할 것인지 구분하고 처리를 해야 할 것이다. 우선 현재의 단계에서 직접 테스트해 볼 수 있었던 USER 마이크로서비스와 관련되어서 고려해 봐야 할 점은 백엔드와의 통신에 문제가 생겼을 때 상황은 모든 경우에 공통적으로 처리할 필요가 있을 것 같았다. 비동기로 데이터를 가져오는 경우에 데이터를 얻을 수 없는 경우가 있는데 (백엔드 서버를 기동하지 않았음) 따로 적절한 타임아웃 등을 설정해서 데이터를 얻지 못한 경우 예외 처리를 만들어야 하는 것을 알았다. 현재의 구현 구조에서는 기존 컴포넌트의 기본 값을 사용하고 보여주면서 에러 자체를 인지하지 못하는 문제가 있다.
기타 API와의 통신 외에도 다른 예외 상황 등을 고려하며 이런 에러와 관련된 처리는 계속 추가해야 할 것으로 생각한다.
접근성 문제
접근성 관련 문제는 결코 쉽지 않은 문제라고 생각한다. 고려할 사항이 많아서 단기간에 완벽하게 적용하기는 힘든 내용이다. 접근성과 관련해서는 키워드만 나열하면 다음 사항을 고려해야 한다.
- 대체 텍스트(Alt Text) 제공
- 명확한 헤딩 구조
- 키보드 내비게이션 지원
- 명도 대비
- 폼 입력 요소에 레이블 연결
- 비디오 및 오디오 콘텐츠에 자막 제공
결론적으로는 시각적으로 장애가 있는 사용자도 모두 웹 페이지를 사용할 수 있는 조치가 필요한데, 위에 나열한 목록 말고도 화면 읽기 도구에서 웹페이지를 탐색하는 데 도움이 되는 조치가 필요하다.
나는 우선은 최대한 IDE에서 접근성 문제로 코드를 수정하라는 내용에 맞춰서만 조치를 하고 있다. 프론트엔드 개발자의 전문성이 가장 필요한 부분이라고 생각한다.
반응형 웹
DaisyUi 와 TailWind CSS의 도움으로 사용자의 화면 크기에 따른 화면 전환과 같은 효과는 어느 정도 적용되고 있다. 하지만 세밀하게 모든 화면마다 테스트 하지는 않았고, 큰 화면, 중간 화면, 작은 화면의 기준으로 서로 화면마다 일관성 있는 UI를 제공하도록 수정 한다거나, 어떤 화면에서는 표현 방법을 다르게 해야 하는 필요성이 있다. 반응형 처리는 모든 기능과 화면이 정상을 확인 한 이후에 따로 작업할 예정이다.
컴포넌트 및 패키징 정리 문제
기술적인 부분은 아니지만 고려는 하고 있는 상태이다. 코드 구현을 하면서 어느 정도 완성이 되고 난 뒤에 따로 리팩토링 작업도 병행했다. 이 리팩토링을 진행하면서 몇몇 컴포넌트의 경우 개별적인 컴포넌트로 쪼개서 구성하는 것이 좀 더 유지보수에 좋을 것 같은 구조라고 생각이 들면서도, 따로 재사용성 자체는 떨어지기 때문에 굳이 만들어서 논리적인 가독성을 떨어뜨릴 것 같다는 생각에 일단은 냅둔 상태이다. 다만 이 컴포넌트 분리와 통합의 과정을 거치면서 전체적인 패키징 구조에 대해서는 언제나 의문을 가지고 있다. 프론트엔드에서는 어떤 기준으로 패키징하는 것이 좋을지 전혀 감이 잡히지 않았다. Svelte는 폴더 라우팅 방식을 사용하기 때문에 단순 페이지는 폴더 구조를 따라가고 있는데, 이에 대칭되는 컴포넌트 구조를 따라가고는 있으나, 일부 100% 대칭 구조를 가지는 건 아니라 과연 좋은 구조인가에 대해서는 계속 고민하고 있다.
작업을 마무리하며...
프론트엔드의 초기 화면을 부족하지만 완성은 해 봤다.
주력으로는 백엔드 개발자이면서 프론트엔드를 개발해보니 소감은 정말 쉽지가 않았다.
물론 내가 모르는 것이 많기 때문이긴 했지만서도, 개선할 요소들이 너무 많다. UI/UX적인 측면도 그렇고, 기능적으로도 추가해 보고 싶은 요소도 자꾸 보이고, 개선할 요소들이 화면마다 튀어나오는 느낌을 받았다. 화면에 직접적으로 보여지기 때문에 빠른 개발 피드백을 느낄 수 있어서 나름의 성취감도 있고, 재미도 느끼긴 했다. 하지만 결국 이 길은 내 길이 아닌 것을 다시 한 번 느끼며 프론트엔드 개발자의 고충을 느낀 시간이었다.
다음은 이제 다시 본격적으로 CHALLENGE 마이크로서비스의 개발에 들어가면 된다. 이전의 USER 마이크로서비스에서의 시행착오를 겪었기에 작업에 몰두만 한다면 금방 개발 할 수 있을 것 같은 기대를 하며 이번글을 마무리 한다.
