내 인생 첫 페어 프로그래밍, 빨간 우체통 마을 찾기 미션 회고

월-화까지는 주어진 미션 요구사항이 너무 어렵게 느껴졌으나 결국 주어진 기능 요구 사항, 프로그래밍 요구 사항을 모두 완료했다. 그리고 오늘 스쿼드 세션 때는 우리 코드를 막힘없이 설명할 수 있었고, 다른 동료 분들께서도 이해가 잘됐다고 해주셔서 뿌듯했다!

아마 제이와 페어가 아니고 혼자서 했다면 이렇게 모든 요구사항을 이 정도 퀄리티로 구현하지 못했을 것이다. 이정도 속도가 나지 않았을 것이다. 코드 품질도 중요하지만 구현 속도도 중요하다는 걸 알면서도 실천하기 어려웠는데, 앞으로는 어떻게 개선해야 할지 알게된 소중한 시간이었다.

알고리즘 문제 풀고 강의도 정리해야겠다. 오히려 알고리즘은 절차적으로 작성하는 것이 맞다는 확신도 얻었다. 그걸 인간이 이해하기 쉬운 코드를 작성하는 것도 중요하지만, 실제로 컴퓨터가 그 코드를 어떻게 연산하는지 아는 것도 너무 중요하다. 아무리 컴퓨터 성능이 좋아서 고려하지 않는다고 할지라도.

인상깊었던 리뷰는 자신들의 코드에서, 자신들의 케이스에서 정렬 알고리즘의 시간 복잡도 공간 복잡도를 비교해본 젤로와 카카모토비다. 그렇게 복잡하지 않은 계산이더라도 이걸 해봤느냐, 아니냐는 결국 태도의 차이라는 생각이 들었다.

Sort Algorithm은 정말 많다. Inserted method도 많고, 원하는대로 직접 만들 수도 있다. previous status에 따라(상황에 따라) 적합한, 더 효율적인 알고리즘이 있기 때문에 작동 방식에 대해 이해해두고 상황에 맞는 알고리즘으로 접근하는 것이 필요하다.

이처럼 데이터가 거의 원하는대로 다 정렬되어 있는 상황에 적합한 알고리즘과 지금과 완전히 역순으로 정렬하고자 할 때 적합한 알고리즘은 다르다.

이번 주 미션에 필요한 Sort Algorithm을 개인적으로 공부해서 merge sort를 구현했지만, 다른 알고리즘과 비교하지 못했다. merge sort를 선택한 이유는 단순히 우리가 우체통의 크기를 random 하게 생성하기 때문에 정렬이 아예 되어있지 않은 데이터라고 판단했기 때문이다. 그러나 이번 케이스처럼 정렬해야 할 데이터의 개수가 적을 때도 적합한지, 효율적인지 생각하지 않았다.

리뷰 이후에 계산해본 결과 우리 테스트케이스에서 n이 10일 때 시간복잡도를 계산해보면, bubble sort의 경우 O(n2) 10 _ 10, merge sort의 경우 O(n log n) 10 _ log 10 = 3x.xxx 이므로 merge sort가 약 3배 이상 효율적이다.

구현할 것도 많고, 고민할 것도 많고, 학습할 것도 많고, 그 과정에서 지치기도 하지만 중간 중간에 생각하지 않는 것을 가장 경계하고 점검해야 한다.