간단한 crud 를 구현했다. 계층 구조 없이 구현했고, Controller 에서 어떻게 요청하고 응답받는지 알아볼 수 있었다. Spring 공식 문서가 굉장히 잘되어 있다는 걸 새삼 느꼈다. Spring 으로 코딩할때는 개발을 처음 시작했을때라 블로그 문서를 보고서 트러블슈팅하기 바빴는데, 지금은 좀 더 천천히 공식 문서를 보면서 리뷰도 달아가면서 하고 있다. Spring 사용법보다 Spring 자체를 감상?하는 느낌으로 공식문서를 보고 있다. 역할 구분이 잘되어 있어서 이해하기도 쉽고, 정돈되는 느낌이 든다.
다 만든 이후에 Kotlin 으로 똑같은 것을 한번 더 만들었다. 요구사항이나 스프링에 대한 내용보다 코틀린을 쓰면 어떻게 다르게 할 수 있는지에 초점이 맞춰줬다. 단순한 요구사항이라 크게 차이점이 있진 않았지만, 자바 특유의 verbose 함이 많이 줄어드는 것 같아 사용감은 대만족이었다. 특히 collection API 가 자바와 다르게 매우 쓸만해서 좋았다. 단순한 자료구조에 연산이 짱짱하게 지원되는 함수형 스타일을 선호해서 그런지, 이것도 대만족이었다. 공식문서를 참조해가면서 더 익숙해지면 좋을 것 같다.
예전에 사두었던 아샬님 강의를 다시 보는 중인데, TDDBE 와 딥하게 만난 후라서 그런지 몰라도, 피드백 고리가 계속 눈에 들어온다. 아샬은 구현하고자 하는 바를 체크리스트로 한번 말하고, 실제 피드백 가능한 형태로 두번 말하고, 구현 상세로 세번 말하신다. 실제 피드백 가능한 형태가 중요한데, 행동전에 미리 피드백을 어떻게 받을지를 미리 생각하고 구체적으로 정의한다는 뜻이다.
감정이나 해석이 들어간 글들을 쓰고 나면 다시 못읽겠다는 생각이 든다. 쓸 당시의 맥락에서는 매우 자신에 차있었지만, 맥락에서 조금만 빠져나오면 이사람 왜이러나 라는 생각이 들때가 많다. 내일 읽어도 부끄럽지 않을 만한 것을 써야 하는데, 그러려면 지금보다 정성을 들이고, 시간을 들여야 한다는 생각이 든다. 코드도 그렇고 글도 그렇고 다시 보고 고치는 횟수가 많아져야 할 것 같다.
Samchon 이라는 분의 인터뷰 영상을 보면서, 내가 아는 개발자 들 중 존경할 만한 분들의 공통점을 하나 찾을 수 있었다. 형태는 다르지만 자신의 생각을 되돌아보는데 투자하는 시간의 비중이 굉장히 크다는 것이다. 물론 그것을 실행하는 형태는 다 달랐다. 어떤 분은 직접적으로 다양한 피드백을 면대면으로 계속해서 받기도 했다. 또 어떤 분은 자신이 작성한 것들을 주기적으로 고쳤다. 어떤 분은 검증된 사람들의 의견을 계속해서 관찰하고 필요한 경우에는 의견을 구했다. 어떤 분은 마이크로 한 단위에서 자신이 쓰는 글 한줄한줄에서도 회고를 반복했다.
나는 터널비전에 빠질 때가 많다. 하나의 법칙으로 단순하고 명쾌하게 정리되는 것을 매우 좋아하기 때문에, 성급하게 단정지을 때가 많아서, 충분히 생각할 기회를 놓친다. 피드백 고리의 설계가 익숙해졌다면, 다음 단계는 다시 보기와 다시 생각하기의 시간을 지금보다 훨씬 늘리는 것일것 같다. 피드백을 설정하고 통과했다고 해서 끝난게 아니기 때문이다. 피드백 자체가 틀렸을 수도 있다. 훨씬 좋은 구현 방법론이 존재할 수도 있다.
아직 생각이 정리되지 않았지만, 다시 생각하기 를 위해서는 다음이 중요할 거라고 본다. 까먹기, 맥락 탈출하기, 낯설게 보기