유스콘 2021 Spring Boot TDD Start! 회고

유스콘이란?

유스콘은 아는 것은 유쾌하게, 모르는 것은 진지하게 라는 모토로 젊은 개발자와 선배 개발자가 함께 가치 있는 기술에 관한 정보와 경험을 공유하는 콘퍼런스입니다.

지원 동기

2020 유스콘도 연사자로 참여해보고 싶었지만, 이런저런 이유로 다른 분들의 발표를 보는 참여자였습니다. 그래서 마음 한켠에 2021 유스콘에는 꼭 연사자로 참여하고 싶다는 막연한 마음이 있었습니다. 시간이 흘러 2021 유스콘 연사자를 모집하는 시기가 되었고, 지원을 해야겠다는 생각을 했습니다. 하지만 막상 지원서를 작성하다 보니 스스로의 부족한 점과 발표의 결과가 안 좋았을 때를 생각하게 되었습니다.

'남들보다 특출나게 잘하는 게 없는 것 같은데 발표를 해도 되는 걸까?'
'발표를 하다 큰 실수를 하면 어쩌지?'
'발표는 유명하고 뛰어난 사람들만 하는 건 아닐까?'

이런 생각들로 망설이고 있었는데 같이 스터디하는 분과 이력서에 대해 얘기를 하고 있던 중 '이력서에는 근거가 있어야 한다'라는 말을 하셨고 제 이력서에서 강조되고 있는 TDD에 대한 근거가 부족하다고 생각했습니다. 그래서 다시 한 번 마음을 다잡고 실력 있는 개발자가 되기 위한 성장통이라고 생각하고 지원하기로 마음을 먹었습니다.
다행스럽게도 며칠 뒤 연사자로 뽑혔다는 연락을 받게 되었고 본격적으로 발표 준비를 하게 되었습니다.

목표

발표 준비에 앞서 목표는 두 가지였습니다.

1. 스스로 알고 있던 TDD를 정리하자
작년 1월에 코드숨이라는 교육 프로그램에 Spring 1기로 참여했고, 여기서 가장 강조하는 내용 중 하나가 TDD였습니다. 그래서 작년 한 해 동안 TDD와 관련된 책들과 영상 및 블로그를 틈틈이 보게 되었고, 실무에서도 공격적으로 도입을 했었습니다. 하지만 TDD가 잘 안 되거나, 어떤 도구들을 언제 사용해야 하는지 정리가 되어있지 않은 상태였습니다. 그렇기 때문에 이번 기회에 꼭 정리를 해보고 싶었습니다.

2. TDD를 모르는 사람도 이해할 수 있는 재밌는 발표가 되자
그리고 작년 2020 유스콘과 우아한 테크에서 재성님(AKA Jason, 두두)의 코틀린 발표가 기본 지식이 부족한 사람(저처럼 코틀린을 잘 모르는 사람)이 봐도 따라갈 수 있고, 흥미를 유발할 수 있는 발표라고 느껴져 재밌고 감사한 마음으로 봤었습니다. 그래서 기회가 되면 저도 다른 사람에게 비슷한 영향을 주고 싶다는 생각을 가지게 되었습니다.

준비 과정

이런 목표를 가지고 부푼 마음으로 준비를 시작했지만 정말 막막했습니다.

'TDD 진행 방향은 상향식, 하향식, 샌드위치?'
'테스트 도구는 어떤 걸로 하는 게 좋지? Rest-assured?'
'TDD 하면 좋다는 것을 어떻게 명시적으로 보여줄 수 있지?'

그러던 중 저의 멘토가 재석님으로 정해졌고 감사하게도 퇴근하고 만나서 얘기해보자는 의견을 주셨고 (닭갈비 정말 맛있었습니다😀) 이때부터 막막한 부분이 조금씩 해소되었습니다.

특히 제가 하는 발표이니 제가 TDD를 하면서 겪었던 점들을 발표에 녹여내는 게 중요할 것 같다는 의견을 주셨는데 이 부분이 발표를 준비하는 데에 있어서 주요했던 것 같습니다.

저 같은 경우 실무에서 TDD를 어렵게 만드는 가장 큰 장애물은 테스트 코드를 실행하는 시간이었습니다.
주로 처음 테스트 코드를 작성할 때 많은 Spring의 자원을 활용해서 성공하는 케이스를 빠르게 만나며 자신감을 갖게 됩니다. 하지만 시간이 흐를수록 테스트하는 시간이 길어지게 되면서 테스트 코드를 실행하는 횟수가 줄어들게 됩니다. 그렇게 되면 결국 관리되지 못하는 테스트 코드가 작성되고 테스트 환경의 품질이 떨어지게 되었습니다. 그래서 이런 부분을 발표의 큰 틀로 잡고 진행을 하게 되었습니다.

물론 그 이후에도 순탄하지는 않았지만, 부족할수록 연습에 몰두하고 2~3일 간격으로 재성님과 재석님의 조언을 잘 받아들이려고 노력했던 점이 도움이 많이 되었습니다.

발표 당일

드디어 발표 당일이 되었고, 처음으로 많은 사람들 앞에서 발표를 해보기 때문에 정말 떨렸습니다. 이 때는 재성님의 조언이 도움이 많이 되었습니다.

'지금 발표를 들으러 오시는 분들은 모르기 때문에 들으러 오시는 거다.'

계속 이 말을 되새기며 자신감을 가지다 보니 발표를 침착하게 시작할 수 있었습니다.
발표를 하는 중에도 말을 조금씩 버벅거리거나 설명이 생각처럼 매끄럽지 않았던 기억도 있지만 큰 실수는 없어서 다행스럽게 생각하고 있습니다.

그리고 발표가 끝나고 난 후에 몇몇 분들이 질문을 주셨는데 이거에 대한 답변을 할 때가 정말 좋았습니다.
발표 시간 동안 전달하고 싶은 내용이 많았지만 시간이 부족해서 하지 못했던 말들이 있는데 이런 부분을 질문을 주셔서 말할 수 있는 기회게 되었습니다. 그중 기억에 남고 많이 주셨던 질문과 답변을 간단하게 요약했습니다.

1. mocking은 언제 쓰면 되나요?
mock데이터를 쓰는 이유는 테스트하고자 하는 대상에만 집중할 수 있도록 도와줍니다.
예를 들어 실제로 데이터가 필요한 경우 postman과 같은 도구를 사용해서 직접 input값을 만들게 되는데 이런 작업은 하나의 테스트를 하기 위해 너무 많은 자원을 사용하게 됩니다, 그렇기 때문에 원하는 데이터를 만들어서 해당 메서드의 input값을 만들어주면 테스트를 하기 위한 자원을 절약함으로써 테스트하고자 하는 대상에 집중할 수 있게 됩니다.

2. 단위 테스트, 통합 테스트 언제 하면 되나요?
우선 각각의 테스트 목적을 생각해보면 좋습니다.
단위 테스트의 경우 신뢰할 만한 코드를 만들기 위해 가장 작은 단위로 테스트를 진행하는 것이 목적입니다.
통합 테스트의 경우 이렇게 작성된 코드의 컴포넌트끼리 상호작용을 잘하는지 확인하는 것이 목적입니다.

제 답변은 대부분 마틴 파울러의 The Practical Test Pyramid 라는 글을 토대로 했습니다.

회고 모임

유스콘이 끝나고 다 같이 모여서 회고를 하자는 의견이 나왔고 설레는 마음으로 회고 모임에도 참여했습니다.
다른 분들의 회고를 보며 스스로 부족한 점을 다시 한번 느꼈고, 이런 분들과 함께 유스콘에 참여했다는 것이 뿌듯하기도 했습니다. 특히 저의 출퇴근을 책임지는 우테코 분들이 발표를 준비하는 과정을 알게 되어 좋았습니다.

이 글의 마무리

발표를 하기 전에는 발표를 듣는 사람들이 도움이 되는 자리라고 생각했습니다. 하지만 이번 유스콘 발표를 하게 되니 발표를 준비하는 사람이 가장 얻어가는 것이 많다는 것을 알게 되었습니다. 지금도 저에게는 발표가 두렵고 떨리는 일이지만 기회가 된다면 언제든 참여하고 싶은 행동이 되었습니다. 이 글을 읽으시는 분들도 저처럼 발표에 대한 막연한 두려움이 있을 거라고 생각합니다. 하지만 그 두려움을 설렘으로 조금씩 바꾸다 보면 언젠간 발표자로서 유명한 콘퍼런스의 연사자가 될 거라고 믿습니다.

마지막으로 유스콘을 준비해주신 재성님과 저의 멘토 재석님, 좋은 영향을 주신 유스콘 연사자분들, 그리고 부족한 제 발표를 들어주신 모든 분들께 감사드립니다.

특히, 같이 스터디하시는 분이 제 발표 후기 중 하나를 캡처해주셨는데 덕분에 정말 많이 웃었고 힘이 많이 되었다고 말씀드리고 싶네요. 감사합니다😀