무엇을 하려는 건지 생각해보기

리뉴얼 된 블로그로 보기: https://solo5star.dev/posts/45/

 

우리는 종종 코드를 작성하며 중간 결과물을 확인하곤 한다. 이 과정에서 조금씩 욕심이 생기곤 한다.
 

버튼이 부드럽게 눌려지는 애니메이션을 넣어볼까?

기능을 좀 더 범용적으로 만들어보자! 라이브러리와 비슷한 수준으로 고도화를 해보자!

이렇게 완성된 페이지는 결국 처음에 그렸던 그림과 똑같을까? 나의 경험 상 아니었다.
 
처음에 피그마로 만들어진 시안을 보고 2~3일이면 충분할 것 같았지만 앞서 말한 것처럼 중간중간에 다른 길로 새는 낭비가 발생하게 된다. 이들은 모두 처음에 그렸던 그림에 있었던 것들일까? 아니었다.
 

딴 길로 새는게 즐거웠죠

만들고 싶은 것을 만들며 그저 코드를 타이핑하는 것이 재미있었다. 갑자기 해보고 싶은 시도가 생기면 해보면서 많이 배우기도 하고 그랬었다. 시간은 많이 들었지만 넓은 코드의 세계를 알아갈 수 있어 좋았다.
 
이런 코딩 인생을 걷다가, 우아한테크코스 5기에 입교했다. 코드 작성하는 것은 똑같은데, 마감 기한이라는 것이 생겼다. 그게 뭐? 라고 생각하며 별 것 아닌 줄 알았지만 생각보다 나를 힘들게 하는 것이었다! 밤늦게까지 남아서 하는 데도 마감 기한을 겨우 지킬 수 있을 정도였다.
 
별 생각이 없었다. 준의 TDD 강의를 듣기 전 까지는.
 

준의 TDD 강의

TDD가 뭔지 아는가? Test-Driven-Development로, 테스트 주도 개발. 즉 코드를 작성하기 전에 테스트를 작성한다는 것으로 알려져 있다. 나도 그렇게 알고 있었고 더 이상 배울 건 없다고 생각했었다.
 
그렇지만 준이 말하기를, 꼭 테스트를 먼저 작성한다고 해서 TDD라는 것은 아니라고 한다. 준이 설명한 TDD는 이렇다.
 

TDD는 결정과 피드백 사이의 갭에 대해 조절하는 테크닉, 사고 방식

 
TDD로 하고자 하는 건 단순히 테스트를 먼저 작성하냐, 나중에 작성하냐의 차이가 아니다. 불확실한 상황 속에서 무엇을 할 것인지 정하고, 코드를 작성하고 피드백을 받는 과정이라고 할 수 있다. 그렇다고 테스트가 필요 없다는 이야기는 아니다. TDD 과정에서 테스트가 있다면 피드백을 더욱 빠르게 받을 수 있기 때문에 유용할 것이다. 하지만 필수는 아니라는 뜻이다.
 
만약 마감 기한이 없고 시간이 많다면 딴 길로 새어도 어떻게든 다 할 수 있을 것이다. TDD가 정말 유용한 때는 불확실성이 높고 시간이 부족할 때이다.
 
준이 소개해준 TDD를 잘하는 절차는 아래와 같다.
 

1. 전체 문제가 해결되었을 때 어떤 상태일지 상상하기. 결국 내가 뭐 하려는 거지?
2. 적당한 난이도로 문제를 변형하거나 쪼개기. 단 핵심을 포함해야 한다.
3. 핵심과 가까우면서 할 수 있는 적절한 것 하나를 선택한다.
4. 결과치가 무엇인지 구체화하고 최대한 진짜처럼 시뮬레이션한다.
5. 동작 가능한 가장 작은 버전을 만들고 테스트가 통과하는지 확인한다.
6. 리팩터링 해서 중복을 줄이거나 의도를 드러나게 한다. (의도가 잘 드러나기 위한 중복은 허용). 단, 모든 리팩터링 단계마다 테스트 통과 확인
7. 다시 1번이나 2로 가서 반복한다.

 

TDD 체화하기

사실 테스트 작성은 아직도 서투르다. 위의 7단계 조차도 제대로 하지 못하고 있다. 그렇다 해도 핵심은, 결국 내가 무엇을 하려는 건지에 있다고 생각한다. 불확실한 상황일수록 핵심이 무엇인지 생각해 보자.
 
테트리스로 예를 들자면, 아래에서 어떤 게 핵심일까?

1. 모양을 바꿀 수 있는 테마 기능
2. 다양한 모양의 블록을 추가할 수 있는 기능
3. 블록이 떨어지고 한 줄을 완성할 시 없어지는 기능
4. 멀티 플레이 기능

4번이 제일 재밌어 보이네! 그러니 4번을 시도해 봐야지.

라고, 시간이 넘칠 시절엔 당연 4번을 골랐을 것이다. 네트워크를 배울 기회도 되고, 무엇보다도 재미있어 보이니까!
 
아무리 화려한 기능이 있다 하더라도 테트리스의 핵심 기능이 잘 동작하지 않는다면 아무런 의미가 없다. 블록을 쌓아 한 줄을 완성했는데 없어지지 않는다면 테트리스라고 부를 수 있을까?

너무 당연한 이야기 같지만, 이렇게 생각해내는 것이 의외로 잘 안될 때가 많다. 만들다가 영 아닌 것 같아서 그림을 지웠다 그렸다를 반복한다거나, 이것저것 다 해보고 싶다는 유혹에 이기지 못하거나.
 
무얼 할지 정했다면, 동작 가능한 상태를 빠르게 확인해야 한다. 지저분해도 돌아가는 쓰레기부터 만들자. 큰 그림을 대충 그려놓고 작게 채워나간다. 그 어떤 재밌고 신기한 기능이 있다고 해도, 핵심 기능이 동작하지 않으면 아무 소용이 없다. 핵심 기능이 동작하는 상태를 유지하며 큰 그림을 채워나간다.
 

결국 무엇을 하려는 건지 생각해보기

준의 TDD 강의를 통해 시작된 글이지만, 꼭 TDD에 얽매여 생각할 필요는 없을 것 같다. 물론 TDD의 7단계를 잘 실천할 수 있다면 좋겠지만, 아쉽게도 1단계 조차도 어렵다. 괜찮다고 본다! 결국 핵심은 내가 뭘 하려는 건지 생각해보는 것이다.

물론 프로젝트를 하는 데에는 반려동물 성장을 기록할 수 있는 앱, 정말 간단한 레시피 앱 처럼 목적이 있어 하는 것일 거다. 그렇지만 당장에 코드 작성을 시작한다면 무엇부터 하는게 좋을 지 모르는 상태로 길을 잃어버리기 쉬울 것이다. 

따라서 의식적으로 계속 생각해보자. 무엇을 하려는 건지. 포괄적이지 않고 핵심을 관통하는 것을.