오늘 스프린트의 속도에 조금씩 박차가 가해지는 느낌이었다. 사흘 동안 끊임 없이 아이디어의 구체화와 브레인스토밍을 진행하면서 한 서비스에 대한 생각이 이렇게까지 명료해질 수 있다는 것이 신기했다.
위 이미지는 서비스의 각 페이지의 레퍼런스를 각 팀원마다 조사하여 모은 것이다. 우리 팀에는 다른 팀과 달리 디자이너가 없어서 어떻게든 레퍼런스를 모아 뷰를 생각해보기로 했다. 그런데 모은 레퍼런스를 가지고 같이 이야기를 나누다 보니, 어떻게든 화면 안에 넣고 싶은 내용과 배치들이 정해진 느낌이 들었다. 디자이너 아닌 사람들(?)끼리도 힘을 모으면 쿰척쿰척 뭔가 되긴 하는구나 하는 생각이 들었다.
🧊 갑자기 아이스 브레이킹?!
총 5일 간의 스프린트 과정에서 사흘이 지난 시점인데 갑자기 아이스 브레이킹이 진행되었다. (이미 다 친해진 것 같은데) 주제가 재미있었는데, '외계인이 지구에서 와서 당신의 직업이 뭐냐고 물으면 우리는 외계어를 모르니 그림으로 어떻게 대답할까' 하는 것이었다.
한 팀원은 카톡에 키보드를 두들기는 고양이 이모티콘을 가져와서 '개발자는 키보드를 두들기는 사람'이라고 얘기했다. 다른 한 팀원은 공사장 인부의 모습을 가져와서 '개발자는 노동자'라는 생각이 들었다고 했다. (이건 맞는 얘긴지도 모른다)
나는 두 사람과 달리 일반 개발자가 아닌 '프론트엔드 개발자'라는 범위로 생각했어서, 기획자와 디자이너와 백엔드 사이에 있는 직군이라는 의미로 '샌드위치' 이미지를 가져왔다. (원래는 직관적으로 강 위의 '다리' 이미지를 떠올렸지만 가져오려고 보니 별로 예쁘지가 않아서 샌드위치로 바꿨다)
실제로 프론트엔드 개발자란 기획자의 서비스를 탐구하는 시선, 디자이너의 UI/UX를 고려하는 관점, 백엔드 개발자의 데이터 설계(속으로만) 능력을 모두 갖춰야 하는 직군이라고 생각한다. 그리고 이 모든 얘기를 다 이해하고, 만약 다른 직군에서 뭔가 오해가 생기거나 추가 기능 구현 요청을 한다거나 하면 이를 중간에서 조율하는 것도 프론트엔드 개발자의 역할이지 않을까 조심스럽게 추측해보았다. (이쯤 되면 샌드위치가 아니라 샌드백에 가깝다)
🧮 데이터 설계를 경험하다
데이터 설계라는 건 원래 백엔드에서만 하는 것인 줄 알았다. 화면에서 변하는 모든 것은 데이터이고 프론트엔드는 그걸 구현하는 입장이다 보니, 프론트엔드가 데이터의 설계 구조를 알면 무엇을 어떻게 개발해야 하는지에 대한 큰 그림을 그려볼 수 있다고 했다.
화면에서 변경되는 부분은 '상태(state)'이고, 이것이 사용자의 인터랙션에 따라 변동될 때마다 렌더링을 어떻게(아예 할지 말지, 한다면 어떻게 더 빠르게 할지) 등을 고민해야 한다. 팀원들과 함께 posts, users, comments 등의 페이지들마다 필요할 만한 데이터(상태)들을 뽑아내면서, 만들어질 기능들에 대해 머릿속에 더 구체화하고 수직적인 '위계화', 즉 '트리'가 그려지는 느낌을 가질 수 있었다. 데이터를 객체나 배열로 뽑아낸 뒤에는 타입까지 지정하였다.
🍯 given(A이거나 B일 때) - when(~하면) - then(~해라)
이후에 진행한 과정은 'given - when - then' 구체화하기 였다. 이 중에 가장 중요한 것은 when과 then이었다.
given은 하나의 when에서 파생되는 then이 2가지 이상일 때 어떤 조건을 가지고 그것들을 분기를 할 것인지에 정의하는 것이다. (if문의 조건문 같은 느낌)
when은 사용자가 인터랙션(예: 클릭)을 한 상황이고, then은 when의 이벤트 발생 시 화면에 나타나야 할(또는 변경되어야 할) 실행문이다.
즉, 이 세 가지를 잘 정의하면 then의 리스트가 곧바로 개발 구현 todo가 된다.
예를 들어 when에서 '사용자가 카드를 클릭했을 때'를 서술하면, 해당 then에서는 '카드 클릭 시 화면에 일어나야 하는 일'이 서술된다.
만약 카드의 '수정' 버튼을 누르면, 이후 수정을 하기 위한 input 창이 뜨고, 수정을 한 후에 '확인'을 누르면 수정된 내용이 화면에 반영되며, '취소'를 누르면 input창이 사라진다. 이렇게 when 이후에 일어나는 일에 대해 분기하는 것이 given에 해당한다.
데이터 설계와 given - when - then을 거치는 과정이 인상 깊었던 이유는 그동안 이렇게 데이터에 대한 구체적인 고려 없이 요구사항만 보고 바로 코드부터 치기 시작해서인 것 같다. 세부적으로 설계를 하고 개발을 시작하는 것이 본격적인 개발에서의 여러 가지 시행착오를 막을 수 있어서, 잠깐은 시간이 더 드는 것 같지만 장기적으로 봤을 때는 비용을 훨씬 줄일 수 있다고 했다.
3일차 과제
3일차 과제는 따로 없고 '내일부터 개발을 시작합니다!' 하고 끝이 났다. 팀원들과 얘기하여 오늘은 깃허브와 프로젝트 셋팅만 마치기로 했다. 이제는 정말 본격적인 구현이 시작될 예정이다. 👊
