개발일지 (2월 회고)

 

 

 

 

Team Blueprint

프론트엔드 개발을 2년 정도 하면서 "프론트엔드"라는 분야에 대해 가장 크게 느낀 점이라고 한다면 "갖추어야 할 것들이 너무 많다"라는 것이다. 물론 갖추어야 할 것이 적은 분야가 어디있겠냐 마는 "Front-End"라는 용어의 특성상 애플리케이션 개발의 모든 부서들(기획 + 디자인 + 서버 + 클라이언트 등등)과 소통을 "잘"해야 하고, 매일매일 새로운 업데이트가 적용되는 브라우저에 대해서도 잘 알고 있어야 하며, SSR의 이점으로 인해 웹 애플리케이션을 서빙하는 서버까지도 어느 정도는 알아야 한다. 이 때문에 프론트엔드 개발을 할 수는 있어도 "잘"하기는 정말 정말 어렵다는 생각이 많이 든다. 프론트엔드 개발자에게 요구되는 능력이 이렇게 다양해지면서 "잘하는 프론트엔드 개발자"가 어떤 역량을 갖추어야 하는지에 대해 확실한 정의를 내리기가 어려워졌다는 생각이 든다. 물론 말 그대로 "다" 잘하면 너무 좋겠지만, 그런 개발자들이 흔하지도 않을뿐더러 "다" 잘하는지를 검증할 방법도 마땅치 않은 것이 사실이다. 

 

 

생각해보면 실제로 지난 1년간 일을 하면서 느꼈던 아쉬움도 이와 맞닿아 있었던 것 같다. 다들 열정을 가지고 열심히 하지만 각자 열심히 하는 부분들이 달랐고, 이 부분들이 공유가 잘 되지 않으면서 좋은 사람들과 함께 열심히 일을 했지만 정작 그 좋은 사람들의 좋은 역량을 충분히 소화하고 서로의 것으로 만드는 과정들이 결여되어있었다고 해야 할까. 따라서 올해는 "팀"이 나아가야 할 방향에 대한 "청사진"을 그리고, "잘하는 개인"이 아닌 "성과를 내는 좋은 팀"으로서 성장하기 위한 여러 가지 발판을 만들어보려 했고, 파트 리드 분과, 팀 리드 분과, 여러 구성원들과 이런저런 이야기들을 하고, 계획도 세워보면서 그렇게 첫 두 달을 보냈다.

 

 

우선 가장 먼저 한 일은 팀이 가장 중요하게 생각하는 목표를 정한 것이었다. 우리는 프론트엔드 개발자로서 "유저"를 가장 중요하게 생각하기로 했다. 이미 그렇게 하고 있었다고 느낄 수도 있었겠지만 실제로 그렇게 느끼는 것과 공식적으로 이야기하는 것은 다르다. 유저를 중요하게 생각한다는 것은 "유저가 아닌 것"에는 힘을 덜 쏟겠다는 이야기다. 즉 팀이 함께 나아가야 할 우선순위를 "더 나은 유저 경험을 만드는 것"으로 확실하게 정한 것이다. 우리 애플리케이션을 사용하는 유저가 "와 이 앱은 진짜 가볍다" "깔끔하다" 라고 했을 때, 그 가벼움은 애플리케이션의 용량을 의미하는 것이 아니며 깔끔함은 화면이 단순하다는 이야기가 아니다. 유저가 생각한 바로 그 위치에 버튼이 있고, 버튼을 누르면 유저가 생각한 바로 그 동작이 수행되는, 그런 UX적인 부드러움과 함께, 짧은 Latency를 제공하여 많이 기다리지 않고 원하는 화면을 볼 수 있는 그런 것이다. 

 

 

그렇다면 "유저"를 가장 중요하게 생각하는 팀은 어떠해야 하는가? 우선 가장 중요한 건 서비스의 안정성을 높이는 것이라고 생각했다. 빠른 로딩 시간도 중요하지만, 그것보다도 애플리케이션이 사용자에게 항상 의도된 화면만을 보여주고, 의도된 동작에 대한 의도된 결과를 가져다주어야 한다.(안정적인 게 빠른 것보다 우선이다) 그러기 위해서는 매번 이런저런 핑계들로 미뤄왔던 테스트 코드의 작성, 더 나아가 테스트 주도 개발 방법론을 도입할 필요가 있겠다는 결론에 이르렀다.(그다음 플랜도 어느 정도는 그려두었지만 지면상 지금 하고 있는 내용만 설명하려고 한다.)

 

 

"유저"의 입장에서 더 나은 애플리케이션을 만들기 위한 플랜을 이렇게 정했지만 애플리케이션의 코드를 작성하는 것은 개발자들이다. 우리는 성장에 대한 강한 욕구를 가지고 있고, 개선에 대한 열정을 가지고 적극적으로 문제를 제기하는 팀원들을 채용하려고 하는 것 같다. 때문에 더 나은 애플리케이션을 만들기 위해서는 무엇보다도 개발자들이 적극적으로 토론하고 배우며 성장하는 문화를 만드는 것이 중요하다고 생각했다. 팀 차원에서 개발자들이 성장하는 문화를 제공하면, 그 문화 안에서 더 좋은 UX를 위한 아이디어들이나 의견들이 나오고, 의욕과 개선을 부추기는 문화가 이를 적극적으로 반영하도록 도와줄 것이라는 기대감이 있었다. 내가 느끼기에 기존에 팀이 가지고 있었던 가장 큰 문제였던 "따로 열심히 개발하는" 문화를 없애고 서로가 열심히 개발하면서 배운 서로 다른 것들을 적극적으로 공유하고, 코드를 섞고, 리뷰하는 문화를 만들면, 위의 "유저"를 중요하게 생각하는 팀의 목표와 함께 보다 "한 팀"으로서의 단단한 무언가를 만들어줄 것이라는 기대감이 있었다. 

 

 

 

 

 

팀의 공통 목표에 대해서 이야기 한 후에 바로 테스트 주도 개발 문화를 마련하는 팀을 꾸렸다. (사내에서는 이를 공식적으로 "레이드"라고 한다. "테스트 코드 레이드"). Group, TF단위로 서로 흩어져 각자 다른 부분들을 개발하던 팀원들을 한데 모아서, 서로의 경험에 따른 의견을 주고받으면서 여러 규칙들을 정하고 어떻게 테스트할 것인지, 어떤 어려움들이 있었는지를 정리하면서 문화를 수립하는 중이다. 아마 3월 회고록에는 이 레이드에 대한 결론을 어느 정도 내릴 수 있을 것 같다.

 

 

 

 

 

레이드와 더불어 매주 목요일 Web.dev 스터디를 같이 진행하기로 했다. 유저에게 더 나은 애플리케이션을 제공하기 위해 접근성, 부드러운 애니메이션, 네트워크, 보안등의 심도 깊은 주제들을 다루는 학습 코스인 것 같아서 팀원들에게 같이 해보자고 제안했고, 팀원들이 모두 각자 공부하고 싶은 주제들을 정해서 일정을 짜고 계획을 세웠다.  적지 않은 분량의 Document들을 읽고 정리하고, 해당 주제에 대해서 서로가 느낀 점들, 코드 레벨에서 당장 개선이 가능한 것들을 이야기하면서 스터디가 진행 중이다. 물론 굉장히 힘들다. 하지만 다들 이러한 니즈가 어느 정도는 있었는지 모두가 잘 참여하고 있으며, 내가 가장 많이 배우는 것 같다.

 

 

 

 

 

 

 

 

 

Test Driven + Behavior Driven

위에서 나온 테스트코드 작성 관련 이야기를 조금 더 해보려 한다. 물론 결론은 다음 달 회고에 다 나와있을 것이라 생각하지만, 테스트 코드를 짠다는 것이 단순히 "테스트를 통과하는 안정적인 코드"를 작성한다는 것 이외에 생각보다 더 많은 효과를 보여줄 것으로 기대하게 만드는 요소들이 있었다. 몇 가지 요점만 간단하게 추려보고자 한다.

 

조금 더 능동적이고 효율적인 협업

아래는 이번 테스트코드 레이드에서 최종적으로 산출된 테스트 코드의 일부이다. TDD + BDD를 같이 사용하기로 최종적으로 결정했으며, BDD를 사용했을 때 다음과 같이 직관적인 문장의 형태로 테스트 코드가 작성되게 된다. 이러한 형태의 테스트 코드가 갖는 장점은 "개발자가 아니라도" 이 코드가 무슨 일을 하는지 알 수 있다는 점이다. 실제로 기획 > 디자인 > 백엔드 > 클라이언트 > 프론트엔드로 돌아가는 애플리케이션 개발 사이클에서 프론트엔드가 개발을 시작하는 시점을 기획과 디자인 사이의 시점으로 당길 수 있으며, 기획자와 디자이너에게 이 문서를 기반으로 의도한 행동을 실제 컴포넌트를 구현하기 전에 확인하고 논의할 수 있다는 장점이 있다.

 

또한 코드리뷰를 받기에도 용이하다. 실제로 PR 생성 시에 기획 문서와 함께 해당 테스트 코드를 첨부하면 기획문서에 있는 케이스들을 체크해보면서 빠진 케이스들이 없는지, 기획 의도를 올바르게 테스트 케이스로 옮겼는지를 서로 다른 사람들과 리뷰하기가 용이하다. 해당 리뷰가 기획자, 디자이너, 다른 개발자들과 이야기하면서 완료가 되면 말 그대로 해당 테스트 케이스가 통과하는 코드만 작성하면 된다. 막말로 이 단계부터는 졸면서 코딩해도 테스트 코드만 통과하게 만든다면 애플리케이션은 프로덕션에서도 정상 동작할 것이다.

  # TestCode Sample
  # list.feature
  
  Scenario: 안드로이드에서 열린 경우 안드로이드 백버튼 노출
    Given 일반 사용자
    Given "aos" 파라미터가 넘어옴
    Given 콘텐츠 리스트 정상 응답
    When 콘텐츠 리스트 화면 방문
    Then 안드로이드 백버튼 노출

  Scenario: IOS에서 열린 경우 IOS 백버튼 노출
    Given 일반 사용자
    Given "ios" 파라미터가 넘어옴
    Given 콘텐츠 리스트 정상 응답
    When 콘텐츠 리스트 화면 방문
    Then IOS 백버튼 노출

  Scenario: 스크롤시에 마지막 페이지가 아닌 경우 인디케이터 노출
    Given 일반 사용자
    Given 콘텐츠 리스트 정상 응답
    When 콘텐츠 리스트 화면 방문
    When 화면 최하단으로 스크롤
    Then 로딩 인디케이터 노출

  Scenario: 스크롤시에 마지막 페이지인 경우 인디케이터 미노출
    Given 일반 사용자
    Given 마지막 콘텐츠 리스트 정상 응답
    When 콘텐츠 리스트 화면 방문
    When 화면 최하단으로 스크롤
    Then 로딩 인디케이터 미노출

 

적절한 구조와 리팩토링할 수 있는 용기

켄트 벡이 이야기했듯, 올바르게 작성된 테스트 코드가 주는 가장 큰 장점은 "용기"이다. 의도한 동작들에 대해서 테스트 코드가 통과하기만 한다면 컴포넌트를 합치든, 나누든, 변수명을 바꾸든, 함수형 패러다임을 도입하든 아무 문제가 없다. 즉, "용기"내서 구조를 고치고 변경할 수 있다는 의미이다. 또한 TDD 방법론의 특성상 우선 빠르게 실패하는 테스트케이스를 통과하도록 만드는 게 중요하기 때문에 보다 핵심적인 로직의 작성을 우선적으로 진행할 수 있게 된다. (우선 큰 뼈대의 로직을 잡고, 그 뒤에 CSS나 세부적인 로직을 작성하는 식이다.)