블로그 사이트 재구성하기 1 - 기획과 디자인

안녕하세요, 빅픽처 인터랙티브 개발본부 프론트엔드(FrontEnd)챕터 소속 개발자 박성렬입니다. 이번에 우연하게 자가격리로 업무를 잠시 쉬게 되어, 이 시간동안 블로그 사이트를 기획부터 디자인, 개발까지 재구성하며 느꼈던 점들을 공유해 보고자 합니다.

시작하며

세상엔 가치있는 것들이 너무나 많습니다. 리셀샵에서 구매한 나이키 조던👟도 중요하고, 어렸을 때 쓰던 박찬호 썬칩 열쇠고리가 달린 다이어리도 중요합니다. 제 어머니는 “별 쓸데없는 걸 다 중요하게 생각한다”고 투정을 부리기도 했습니다. 그렇게 사소한 것에 애착을 쉽게 가지는 제게도 블로그는 생각보다 그렇게 중요한 것이 아니었던 것 같습니다.

 

호스팅 비용이 밀려서 청구서 메일💸이 쌓일 때에도 귀찮다는 생각밖에 들지 않았습니다. 각종 오류들이 쌓여가고 있을 때에도 적당히 방치하며 있는 듯 없는 듯 내버려 뒀습니다. 오류 페이지만 떴던 기간도 꽤 길었습니다. 그렇게 1년 정도를 어영부영 보냈습니다. 살아있는 반려동물도 아닌데 미안해질 정도였습니다. 가끔씩 어떻게 살려낼까 궁리만 하다가 마침 우연한 기회로 10일동안 자가격리를 하게 되었습니다.

 

지난 2주 동안 블로그 사이트를 처음부터 끝까지 혼자 다시 작업해 보았습니다. 막상 진지하게 작업을 시작하려고 하니, 배울것도 너무 많고 적용해 볼 것도 너무 많았습니다. 별 것 아니라고 생각했는데 기술적으로나 내 자신에게나 모두 꽤 가치있는 일인 것 같습니다. 인터넷에 나만의 다이어리를 적을만한 32절 크기의 공간을 갖고 있는 것 말이예요.

기획하기: 목표

이번에는 기획과 디자인에 조금 더 힘을 실어보기로 했습니다. 지난 블로그 개발이 워낙 기술에만 치중하다보니 사용성에서는 부족한 점이 너무 많았습니다.

 

기획은 크게 기술적인 측면과 사이트 이용성 측면의 두 가지로 나누었습니다. 사실 어떻게 보더라도 블로그-포트폴리오 수준의 사이트에 기술적인 측면이 꼭 필요한 것은 아닙니다. 하지만 팀 소속의 개발자로서, 단순한 개인 작업물로 마무리하기 보다는 팀에게 새로운 소개해줄 수 계기로 작용하면 더 좋겠다는 생각이 들었습니다. 그래서 기술도 가져가되, 전보다는 작은 볼륨으로 작업했습니다.

 

목표: 사이트 이용성

• 와이어프레임을 직접 그려볼 것
  토이프로젝트간 1인 개발을 주로 하다보니 대부분 와이어프레임과 디자인을 함께 진행하는 경우가 많았습니다. 이번에는 정석적인 기획을 해보기 위해 와이어프레임 작성과 디자인을 명확하게 분리하여 진행해 보기로 했습니다.
• 뚜렷한 무드를 가진 디자인을 할 것
  기존에 작업한 블로그 겸 포트폴리오는 기술자적인 측면은 제대로 부각하고 있었지만, 사이트 자체의 아이덴티티가 부족했습니다. 지금 재직하고 있는 곳의 경험과 기분을 디자인에 녹여보기로 했습니다.
• 불필요한 장식적인 측면을 제외하고, 최대한 심플하게 제작할 것
• 블로그 포스팅 형식의 저작물을 올리고 필요에 따라 빠르게 검색할 수 있을 것

목표: 기술적인 측면

• Server Side Rendering(이하 SSR)을 적용할 것
  기존 블로그에도 적용되어 있어서 새로운 부분은 아니었습니다.
• monorepo(이하 모노레포)를 완벽히 구현할 것
  현재 개발팀의 FE챕터에서 모노레포를 사용하고 있지만, 오픈소스에서 일반적으로 보여지는 모노레포와 약간 다른 방식이기 때문에, 오픈소스에서 적용되는 모노레포를 최대한 직접 구현해보고 어떻게 작동하는지 알아보고자 했습니다. 모노레포에 있어서 ‘완벽한 구현’의 기준은 아래와 같습니다.
  • 통일된 커맨드로 전체 패키지를 빌드할 수 있을 것
  • 다른 패키지 간에도 버전 관리를 할 수 있을 것
  • @xyz/abc 형태의 scoped 패키지로 배포하고 재활용할 수 있을 것
  • yarn workspace를 사용할 것
  • CI-CD에서 소프트링크(symbolic link)를 품고 있는 yarn workspace가 정상적으로 작동할 것
• 운영 비용이 매우 저렴하거나, 무료에 수렴할 것
  기존에 운영하던 블로그는 docker-swarm및 terraform 을 활용한 오케스트레이션을 제대로 적용하기 위해서 어쩔 수 없이 유료 VPS 서버를 사용했습니다. 처음에는 가볍게 생각했는데 방문자가 거의 없는 상황에서 거의 1년 반 정도를 유지해 보았더니 유지비용이 상상 이상이었습니다. 무엇보다 결제를 처리하는 것도 귀찮았고, 수익이 없다시피한 블로그에는 맞지 않는 큰 옷이라는 생각이 들었습니다.
• mdx(마크다운)를 제대로 지원할 것
• full text search를 지원할 것
  기존에는 meilisearch 또는 elasticsearch를 사용하여 cached full text search를 지원하려고 하였으나, 시간여건상 제대로 구현하지 못하고 SQL에서 바로 텍스트 검색을 시도했습니다.
• 자료 덤프 및 추출이 가 가능한 환경을 구현할 것
  기존은 DB 인스턴스를 분리하기는 했으나, 수동으로 서비스를 돌리다 보니 빠르게 자료를 빠르게 덤프하거나 추출할 수 없는 시스템이었기 때문에 사고가 발생했을 때 DB가 같이 유실되는 불상사가 있었습니다.
• GraphQL
  크게 GraphQL이 반드시 필요하다고 보는 편은 아니지만, 테스트 운행 외에 실제 프로젝트에서 GraphQL을 적용해볼 필요가 있다고 느껴서 GraphQL을 적용해 보기로 했습니다.
• Headless CMS
  최초에 주어진 시간이 약 10일(격리기간)정도였기 때문에, 기간을 감안하여 기본 기능이 사전에 구현되어 있는 headless CMS를 사용하기로 했습니다.

기획하기: 진짜 기획자처럼 일해보기

와이어프레임 작업은 기획자분의 추천으로 whimsical(이하 윔지컬)을 사용해 보았습니다. 여러가지 장점 덕분에 생각보다 훨씬 빠르게 작업이 가능했습니다.

 

윔지컬은 컴포넌트의 유형이 한정되어있습니다. 웹 브라우저나 모바일 앱에서 실제로 사용되는 컴포넌트만 그릴 수 있습니다. 기존에 널리 활용되는 파워포인트, 어도비 XD, draw.io나 figma(이하 피그마)처럼 자유도가 높은 기획 도구를 사용하면 표현 방법은 훨씬 다양해집니다. 그러나 특정 컴포넌트를 표현하는데 별도의 약속이 없기 때문에 반대로 표현실력에 따라 같은 컴포넌트를 디자인에서 잘못 해석할 확률이 높아집니다. 만약 스케치를 할 때 버튼을 동그라미로 그릴지, 네모로 그릴지는 기획자의 자유지만 나중에 이 스케치를 해석할 때에는 이 도형의 형태만 보고 다르게 추측할 가능성이 있습니다. 반면 윔지컬은 컴포넌트에 따라 형태가 정해져 있어 용도를 명확하게 구분할 수 있었습니다.

draw.io에서 button을 검색할 경우 서로 모양이 제각각인 디자인이 등장합니다.

윔지컬에서 button을 검색할 경우 명확히 정리된 두 가지 형태만 제공합니다.

또한 윔지컬은 웹에서 인식하는 각 컴포넌트의 상태도 제공합니다. 이 상태값은 css 선택자 및 자바스크립트를 통해서 스타일링이나 기능 구현에 있어서 개발자가 실제로 사용 가능한 상태값입니다. 따라서 개발자에게 전달할 때 의미가 더욱 명확해집니다.

윔지컬에서 상태값을 선택하는 화면

그 외에도 설명 컴포넌트와 논쟁이 가능한 코멘트 기능을 별도로 마련해 놓는 등, 기획자-디자이너-개발자간의 의사소통에 최대한 신경을 쓴 기획 도구라는 느낌이 들었습니다.

윔지컬을 이용해 그린 전체 프로젝트 도식

페이지 종류는 크게 4 가지 정도로 나누었습니다.

• 메인 화면: 사용자가 처음 진입시 보게 되는 화면. 화려한 이펙트를 통해서 기선을 제압하고, 바로가기와 최근 활동을 정리해서 보여줍니다.
• 포스팅: 블로그 형식의 포스팅을 열람할 수 있는 화면. 마크다운으로 되어있는 글을 렌더하여 보여준다. 각 포스팅은 태그로 정리합니다.
• 작업물: 기존에 작업에 참여한 기여물을 자유롭게 보여준다. 기존 블로그에서 생각보다 작업물 페이지가 잦게 수정되어, 하나의 포스팅 페이지처럼 마크다운으로 렌더할 수 있도록 기획했습니다.
• 연락처: 연락처와 이름, 각종 관련 링크들을 보여줍니다.

결과물만 보면 전혀 복잡하지 않을 것 같습니다. 그러나 진행될 수록 의외로 고비가 많았습니다. 다른 개발범위와 달리 어디에서 작업을 멈춰야할지 종잡기 힘들었기 때문입니다.

 

대체로 기획은 이런 방식으로 진행되었습니다:

기획 완성→🎨디자인을 하다보니 전체 구성을 바꾸면 좀 더 이쁠 것 같음→📝다시 기획 수정→🎨디자인 수정
→💻개발을 하다보니 구현이 어려울 것 같은 부분이 있음→📝다시 기획 수정→🎨디자인 수정→💻개발 수정
→💭생각해보니 특정 기능을 추가해보고싶음→📝다시 기획 수정...

기획은 매우 주관적인 영역입니다. 점수나 수치가 없다보니 좋은 레퍼런스를 찾을 때마다 마음이 계속 바뀌기 쉬웠습니다. 기술적이거나 디자인적인 능력을 보여주고 싶은 욕심과 말이 되는 기획을 하고 싶은 심정이 엎치락 뒤치락 했습니다.

 

이러한 내적 고민을 피하기 위해 가능한 부분에서는 수치적인 뒷받침이 있는 쪽으로 최대한 결정해야 했습니다. 예를 들어 메뉴를 탑 메뉴 형식으로 할 것인지, 사이드 메뉴로 할 것인지를 결정할 때에는 어떤 글에 있던 연구 내용을 참조하여 결정했습니다.

• 탑 메뉴 vs 사이드 메뉴
  • 장비를 가지고 사용자의 시선을 추적한 연구결과에 따르면: 사이드에 메뉴가 위치할 때 훨씬 빨리 이해할 수 있다
  • 사이드 메뉴는 모바일, 데스크톱에 따라 scale하기도 쉽다

그러나 문제는 모든 논쟁에서 수치적인 근거나 과학적인 근거를 찾는 것이 사실상 불가능하다는 점이었습니다. 그러면 결국 다시 논쟁이 시작될 수밖에 없습니다.

실제로 기획이 해야할 일은 기능과 화면을 제시하는 것이 전부가 아니고, 다음 단계가 진행될 수 있도록 일을 맺음하고 결단을 내리는 것이 핵심이라는 생각이 들었습니다.

---

결국에는 스스로 개발과 디자인 피드백을 한 데 모아 기획 수정을 중단했습니다. 그제서야 다시 되돌아가는 일이 없어졌습니다. 기존에 혼자 작업할 때에는 기획과 디자인이 섞여있는 다소 방만한 기획을 했었는데, 역할을 확실히 나누어보니 개발 기간 단축에 있어서 기획의 역할을 나누는 것이 생각보다 중요하게 느껴졌습니다.

 

혼자하는 기획인데도 넘어야할 산이 많았습니다. 실무에서는 여러 사람의 의견을 함께 고려해야합니다. 그러니 혼자 기획할 때보다 이러한 용단을 내리기 더욱 어려울 것이 당연합니다. 따라서 기획을 당장 구현이 가능하고 분쟁이 적을 만큼 만큼 잘게 쪼개고 순차적으로 다음 기획을 제시해야 한다는 아주 당연한 결론에 도달할 수 있었습니다.

 

🙇🏻‍♂️기획자분의 노고에 감사 드리는 자리였습니다.

👉윔지컬 프로젝트 링크

Wireframe

 

디자인하기: 진짜 디자이너처럼 일해보기

좋은 디자인은 객관화하기 어렵습니다. 20세기 최고의 제품 디자이너로 손꼽히는 디터 람스는 심플함이 최고라고 하고, 2021년의 기업 브랜딩 사이트에서는 쓰레기장같은 대담한 브루탈리즘(brutalism)이 인기입니다. 블로그를 다시 디자인 할 때에도 과감한 색상이냐, corporate memphis를 섞은 정돈된 그리드냐를 한참 고민했습니다. 사실 정답은 알고 있습니다. 다만 어떤 디자인이 좋은지를 말하기 어려운 이유는 어쩌면 과감하고 새로운 디자인을 해보고 싶은 욕구와 목적에 맞는 디자인을 해보겠다는 생각 사이에서 누구나 고민하게 되기 때문입니다.

brutalistwebsites.com에 있는 브루탈리스트 디자인 예시

제 기준에서 영감이라곤 전혀 느껴지지 않는 회사 앞 골목을 걸으면서 쓰임새가 있는 디자인이란 뭘까를 한참 생각했습니다. 한 손에 찐빵과 찹쌀 도넛츠를 든 채로 회사 앞에 있는 GS25와 기사식당 앞을 지나가다가 문득 맘속에 있던 말이 튀어나왔습니다. “독산동도 이제 너무 지긋지긋해.” 정문을 지나서 10걸음 정도만 옮기면 안전제일 옷을 입고 면도도 하지 않은 아저씨들이 보이고, 간판들은 자간과 세로 높이도 맞지 않는 이상한 글자체로 되어있습니다. 이 동네가 가진 고루함이 영감을 가로막는게 아닌가 싶어서 괜히 미워하기도 했습니다.

 

어쩌면 영영 이 거리는 아무도 그리워하지 않을 거라는 생각이 들었습니다. 가끔씩 나와서 도너츠를 사먹기도 하고 업무 스트레스를 받은채로 털레털레 걸어가고 있을 때 미지근하게나마 햇볕을 비춰준 내 인생의 한 골목이었는데 말이죠. 생각해보니 그게 아쉬웠습니다. 디자인을 통해 이 거리가 가진 느낌을 그대로 그려보면 괜찮겠다 싶었습니다. 제게 좋은 목적이란 지금 이 때의 독산동이 아니면 가질 수 없는 기억들을 살리는 것이라는 생각이 들었습니다. 1998년의 홍상수 영화가 결코 최고의 영화도 아니고, 최고로 아름다운 강릉 해변을 담아낸 것도 아니지만 그 때가 아니면 나올 수 없었던, 아주 강렬한 강릉 해변의 모습을 담아냈던 것 처럼 말입니다.

1998년 영화 강원도의 힘 , 홍상수 감독

디자인하기: 공단의 기억을 위주로 무드보드 꾸미기

우선은 예전처럼 바로 피그마를 열지 않고 무드보드를 꾸며보기로 했습니다. 인터넷을 후비면서 독산동과 가산디지털 단지에서 느껴지는 공장과 근면한 노동의 느낌을 적극적으로 수집했습니다. 가산-독산동은 원래 디지털산업단지 혹은 G밸리로 지정되기 전에 1980년까지는 구로공단으로 더 유명했던 곳입니다. 실제로 우리가 공장으로 느끼는 많은 부분은 구로공단의 흔적이기도 합니다. 업무상 시간이 많이 주어진 것은 아니기 때문에, 인천에 살 적에 자주 보았던 남동공단과 동인천 화물창고의 분위기도 떠올려 보았습니다. 자료를 수집하고 예전의 공단과 비교해보니 편견에 비해 꽤 발전하고 첨단화된 곳이라는 생각이 들었습니다.

노션에 무드보드를 만들고, 공단과 관련된 이미지를 수집하기 시작했습니다.

공단의 느낌을 적극적으로 수집하다보니 오히려 상당히 재미있었습니다. 특히 공장의 위험요소를 상징하는 핑크와 노랑을 적극적으로 사용했고, 프린터 CMYK 색상의 빛바랜 오프셋 느낌을 살려보았습니다. 공단이라는 테마 자체가 키치하고 캠피한 요소들을 많이 가지고 있어서 이 분위기를 더욱 살려보려고도 했는데, 어느정도는 프로페셔널한 개발자의 느낌을 살리기 위해서 적당한 선에서 멈추었습니다.

시설좋다 자랑말고 안전설비 확인점검! 그 때는 아주 당연했던 것이 지금 보니 황당하고 낯설었습니다. 콜라주 중에 제일 유쾌한 부분이었습니다.

디자인하기:어셋과 컴포넌트 만들기

색상과 형태에 대한 충분한 무드를 수집하고 나서 자주 사용하던 UI 툴킷 템플릿을 불러와서 작업을 시작했습니다.

로고의 경우 공장의 느낌을 살릴 수 있는 도형과 오프셋 선을 위주로 만들어보았습니다.

로고 아이덴티티 작업을 완료한 다음에, 폰트와 글꼴을 정의했습니다.

국문 제목 서체로는 80년대 공장의 아크릴 간판 느낌을 주기 위해 북한의 붉은별 OS에서 추출했다는 천리마 폰트를 사용해 보았는데 의외로 꽤 느낌이 좋았습니다. 영문 제목 서체는 영국의 정부사업에서 자주 볼 수 있는 고전 서체인 Gill Sans와 최대한 유사한 Hammersmith One을 사용했습니다.

공단 근처의 슈퍼에서 흔히 볼 수 있을 것 같은 아크릴 간판의 무드를 폰트로 살려보았습니다. 생각해보면 정작 독산에는 이런 간판이 많지 않습니다.

영어 폰트에서 Johnston과 Gill Sans의 고전적인 미학은 거의 독보적입니다. 그러나 라이선스비용이 어마무시합니다. 대신 비슷한 형태의 Hammersmith One을 사용했습니다.

그 이후에는 툴킷에 정의되어 있는 컴포넌트의 Variant를 용도에 맞게 추가로 정의했습니다.

 

컴포넌트의 원본 컴포넌트(Main Component)를 선택하면 오른쪽에 Variant를 등록할 수 있는 기능이 생성됩니다. 이를 클릭해서 Variant를 등록하고, Asset메뉴에서 다시 가져다 사용하는 방식을 사용했습니다.

등록한 어셋과 컴포넌트를 한 프레임에 몰아서, 급할 때 빨리 export 할 수 있도록 작업했습니다.

등록한 컴포넌트는 이런 식으로 재활용할 수 있게 해두었습니다.

위와 같이 디자인을 피그마에서 완성하고, 본격적인 개발 작업에 착수했습니다. 기존에 기술공유로 전달드렸던 대로 Auto-layout을 최대한 활용해서 웹의 흐름을 살려 제작했습니다. 좌표로 작업하는 것에 익숙하다 보니 Auto-layout만으로 제작하는 것이 생각보다 굉장히 손이 많이 가는 작업이었습니다. 특히 흐름이 갑자기 변할 때나, 피그마 자체의 한계로 흐름이 명확하게 정의되지 않을 때가 있어서 상당히 어려웠습니다.

 

반면 흐름을 살려 제작한 덕분에 장점도 있었습니다. 모바일 작업은 거의 보지도 않고 화면만 줄여서 만들었는데 다행히 별 이상 없이 구현되어 바로 작업에 착수할 수 있었습니다.

 

그 외에도 난항이 많았습니다.

• 디자인을 위해 억지로 컴포넌트 생김새를 web semantic(이하 웹 시맨틱)에 맞지 않게 변경하는 사례가 은근히 있었습니다. 기획과 개발 과정에서는 웹 시맨틱을 위반하는 디자인이 매우 불안정하다고 생각했는데, 정작 디자이너의 입장에서 바라보니 디자인을 살리기 위해 웹 시맨틱을 희생하고 싶은 욕구가 돋았습니다.😬 i.e.)링크를 버튼 형태로 나타내기.
• 색상 보정 도구 없이 작업을 하다보니 마땅한 색상 기준점이 없어서 특정 모니터나 기기에만 잘보이도록 아무렇게나 작업을 하게 되는 문제점도 있었습니다.

🙇‍♂️디자이너분의 노고에 감사드립니다.

👉피그마 프로젝트 링크

Figma

---

 

당연한 이야기지만 개발은 어쩌면 아주 작고 작은 범위의 일인 것 같습니다. 기획과 디자인이 어떻게 결정되었느냐에 따라 개발기간은 무한히 길어졌다가 믿을 수 없을 정도로 짧아지기도 합니다. 짧게나마 체험해 보니 각 부서에서 보이지 않는 고민에 얼마나 많은 시간을 쏟고 스트레스를 받을지 감히 짐작도 가지 않습니다. 바로 내일이면 또 티격태격하며 작업하겠지만 말이예요.

 

다음은 개발 부분을 살펴보도록 하겠습니다.