2022년 6월 25일 TIL - 가장 중요한 게 뭔지 잡아내야 한다

 

메가테라 백엔드 트레이닝 과정 8주차는 1주차에 진행되었던 진행 방식에 프로그래밍이 얹어진 느낌이다. 오늘 오전, 주어진 조건 내에서 스스로 웹 페이지를 기획하는 것에서부터 시작해 금요일까지 완성된 결과물을 구현해내는 개인 프로젝트 주간 과제가 공개되었다. 오늘은 만드려는 웹 페이지에 대한 주제를 정하고, 어떤 형태로 보이도록 할 것인지 구상하는 시간을 가졌다.

 

웹 페이지의 주제를 세우고 배치 구조를 구상해본 뒤에는 그에 대한 트레이너님의 피드백이 주어졌다. 우선 첫 피드백 때는 구상한 웹 페이지의 구조를 파악하기 어려울 정도로 완성도가 높지 못했기 때문에, 다음 피드백을 받기 전까지 웹 페이지로 보여지는 구조를 좀 더 구체적으로 만드는 데 주력했다. 수행에 집중한 결과 다행히 적정 수준의 구조를 구상해낼 수 있었다. 구상 보러 가기

 

이후 트레이너님께서 내일부터 해당 과제에 대해 인지하고 있어야 할 내용에 대해 안내를 주시는 시간이 있었다. 그것은 과제 작성 시 고려해야 할 우선 순위에 대해 생각하는 것이었다. 트레이너님은 만약 당장 1시간 뒤에 사용자가 내가 구상한 프로그램을 사용할 수 있으려면 무엇이 완성되어 있어야 하는지 나에게 물었다. 나는 일단 문제의 요구사항에 게시판이 명시되어 있으므로 운행 기록을 남기는 게시판이 최우선적으로 만들어져야 한다고 답변했다.

 

그렇지만 시간이 1시간밖에 주어지지 않는다면 그 게시판조차도 내가 구성한 대로 만들기란 대단히 어려울 것이라는 생각이 들었다. 내 과제를 구성하게 될 그 게시판의 내용 중에서도 가장 최우선적으로 만들어져서 제공되어야 할 것이 무엇인지 판단해야 할 것이라는 생각이 들었다. 트레이너님은 그러한 것들을 고려하여 짧은 시간 동안 최소한으로 사용자가 사용할 수 있는 프로그램을 만들고, 그 프로그램의 부족한 점이 무엇인지 파악해 다음 결과물에서는 기능이 좀 더 추가된 프로그램을 만들고, 다시 그 프로그램으로부터 부족한 점이 있으면 부족한 부분을 추가하고, 중복되는 부분이 있으면 분리해내는 과정을 반복하면서 커다란 프로그램을 만들어내는 시도를 이번 한 주 동안 해나가야 할 것임을 설명해주셨다.

 

 

TDD는 여전히 쉽게 와닿지 않는 부분이 있다. TDD의 시작은 어디일까? 아무것도 없는 완전한 '무'일까, 아니면 TDD에서도 최소한의 방향성은 잡아놓고 가야 한다고 봐야 할까? 어제였던 금요일에 주어졌었던 코딩 테스트를 풀 때, 주어진 문제를 풀어내는 풀이를 수행하는 메서드들의 반환값, 인자를 먼저 정의한 뒤, 각각의 메서드들이 간단한 테스트 코드부터 시작해서 여러 경우의 테스트 코드를 통과할 수 있도록 소스코드를 작성해 메서드들을 하나씩 하나씩 완성해나가는 방식으로 코딩 테스트 풀이 소스코드를 작성했었다. 문제를 푸는 데 시간이 다소 소요되었었는데, 15개의 최종 Test Case 중 14번째의 Test Case를 풀이 종료 5분 전에 통과하지 못하는 사실을 확인했다. 풀이 시간이 종료되고 얼마 지나지 않아 한 가지 케이스에 대해 고려하지 않았다는 점을 확인하고 그에 대한 처리를 추가해준 결과 모든 Test Case를 통과시킬 수 있었다.

 

생각해보면 내 과정을 TDD라고 하기에는 어렵지 않나 싶다. 내 방식도 풀이과정 상의 각 메서드가 갖는 역할을 적절히 분리했기 때문에 고려하지 않았던 Test Case가 무엇이었는지 금방 찾아낼 수 있었지만, 달리 생각해보면 나처럼 순차적으로 메서드들을 만들어나가는 방식에서 중간 어느 부분의 메서드의 구조에 결함이 있을 경우 그 이전까지 열심히 구현해놨던 메서드들은 안타깝지만 무용지물이 되고 마는 것이다. 이로부터 생각해볼 수 있는 점은, '가장 중요한 게 무엇인지'를 생각하고 그것을 중심으로 구현해나가는 데 집중한다면 구조를 순차적으로만 따라가다가 잘못될 수 있는 부분을 최소화할 수 있지 않을까 하는 생각이다.

 

가장 중요한 작은 것들을 하나 둘 모아 나중에는 큰 것으로 모아내는 한 주를 보낼 수 있기를 바래본다.