메가테라 웹 개발자 과정 5주차 (2) 주간 회고

 

충격의 Java 8주차 이월을 딛고 마침내 모두가 기초 과정 레벨 테스트를 통과했다. 다만 그 과정은 결코 쉽지 않았고, 지난 8주차 때의 첫 레벨 테스트때보다 험난한 과정을 거쳤다. 인상적이라 생각했던 몇 가지 부분을 되짚어본다.

 

 

투지와 실행력

프로젝트 과제가 처음 주어진 토요일부터 월요일 점심까지 만들고자 하는 프로그램의 핵심 가치를 지닌 MVP(Minimu Viable Product)를 제작해 시연하는 과정을 거쳐야 했고, 엄연히 '핵심 가치를 지닌 채 (기준은 다를지언정) 완성되어 작동하는' 프로그램을 짧은 시간 안에 빠르게 만들어야 했기 때문에 구현에 대한 압박이 거셌다. 팀원분들은 고통스러워하면서도 메서드를 찾아가고, 스스로 제시한 문제를 풀고, 더 나은 과정을 거치기 위해 무엇을 해야 하는지 역력히 고민하고 실행에 옮겼다. 그리고 그 노력은 빠르게 결과로 보여졌다. 뽀모도로 사이클을 몇 번 돌때마다 팀원분들의 작업물은 힘껏 덩치를 불리고 있었다. 더 나은 과정을 배워나가기 위한 투지가 느껴졌다. 얼마나 잘 설계하느냐뿐만 아니라 좋은 작업 수행이나 구현 과정을 갖기 위해 더 적극적으로 실행에 옮기고, 일단 어떻게든 해 보는 것이 중요하다는 것을 다시 한 번 팀원분들을 통해 느꼈다.

 

 

리팩터링은 일정 수준 이상 쌓이기 전에 처리를

이번 과제를 진행하면서 곤란했던 요소들 중 하나로는 소스코드 이곳저곳을 찾아 돌아다니면서 많은 시간을 소모했던 부분을 들 수 있다. 이번 프로젝트를 진행하면서는 일단 만들고, 리팩터링은 나중에 하자는 마인드로 구현을 진행했다. 그러나 소스코드의 양이 많아질수록 일간 계획에서 세운 작업의 달성도가 같은 시간을 사용했을 때에 비해 점점 낮아졌다. 여러 구간에서 중복이 반복되고 있어 어떤 특정 기능을 건드리기 위해서는 관련된 모든 중복된 내용들을 찾아다니면서 한번에 건드려줘야 헀다. 그 내용들을 빠짐없이 수정하고 난 뒤에야 의도한 대로 프로그램이 작동했기에 중복된 부분을 놓치지 않기 위해 소스코드를 볼 때 고도로 집중해야 했고, 그로 인해 작업을 하면서 빠르게 지치지 않았나 하는 생각이 든다. 일정 수준에서의 리팩터링은 그 다음 작업의 진행 속도를 높이는 데 좋은 영향을 끼칠 수 있음을 인식해야 한다.

 

 

스스로를 객관적으로 바라봐야 한다

화요일에는 스스로 세운 작업 계획 체크리스트 박스에 표시를 하나도 하지 못했다. 화요일에 세웠던 작업 리스트들 중 가장 먼저 있었던 작업은 '특정 기능을 호출하는 버튼을 누르면 각각의 Frame으로 출력시키던 구조에서, 하나의 Frame 내에서만 기능의 호출과 화면 출력이 이루어지도록 구조를 변경'하는 작업이었다. 일전에 트레이너님들로부터 application 수준의 객체를 직접 개별 클레스에서 인자로 받아 쓰는 것은 구조적으로 좋지 못하다는 피드백을 받아, 그렇지 않은 방식으로 어떻게 화면 갱신을 수행해줘야 하는지 고민했다.

 

해당 작업은 프로그램의 구조를 다시 설계해야 하는 수준인, 1분 1초가 아쉬운 시점에 꽤 많은 시간을 사용하는 작업이었으므로, 하루에 할당하는 일과를 아예 다른 생각 없이 해당 작업에만 집중시켜서 다른 작업으로 분산될 수 있는 인지자원을 분산시키거나, 혹은 적정 수준까지만 고민하고 해답이 나오지 않는다면 깔끔하게 내려놓고 다른 작업으로 전환하는 유연성이 필요했지만, 불필요한 뚝심을 부렸다. 결국 해당 작업은 수요일에 되어서야 그다지 깔끔하지 못한 대체 수준의 방법으로 해결하는 데 그쳤고, 이는 남은 날의 작업 방향에도 영향을 미쳐 작업의 결과물이 더디게 나오는 결과를 낳았다.

 

'내가 그래도 했었던 게 있는데 이 정도 찾는 건 금방 해내야지!' 식의 마인드는 객관적이지 못하다. 객관적이지 못한 판단은 비효율적인 작업 과정을 낳고, 좋지 못한 결과를 받아들이기까지는 오랜 시간이 걸리지 않는다. 스스로의 역량을 낙관적으로 바라보지 않고 냉정하게 이 작업을 하는 데에는 이 정도의 시간은 소요해야 할 것이다와 같이 판단을 내림으로써 적정량의 작업을 스스로에게 최적으로 분배할 수 있도록 해야 할 것이다.