첫 스터디 그룹의 참여 동기와 못다한 이야기
~ 2018 히스토리
나의 첫 프로젝트는 Spring 기반의 D2U e커머스 프로젝트이다.
신입이였던 나는 D2U 프로젝트의 일원이 아니었음에도, D2U 프로젝트의 PM이었던 연구소 부장님에게 학교와 교육원에서 습득한 Spring 프로젝트 개발 경험을 적극적으로 어필하여 UI 설계부터 전반적인 API 개발까지 참여할 수 있었다. 내가 만든 서비스가 운영 서버에서 동작되고 클라이언트에게 제공해준다는 그 자체가 즐거웠다.
프로젝트에서 담당했던 업무는 AngularJS를 사용하여 공통 컴포넌트를 개발과 전반적인 서비스 API를 개발했고, 평소에 부족함을 느꼈던 RDBMS에 대해선 View와 SP 개발 업무를 전담하여 부족한 부분을 다질 수 있는 좋은 경험을 했었다. 프로젝트의 방법론은 Agile을 도입하였고, 클라이언트와의 주간 회의에선 프로토 타입의 화면을 보여주고 이에 대해 산출된 todo-list를 토대로 Vacklog를 작성하고 주 단위의 Sprint Backlog를 트렐로를 통해 관리하는 업무를 겸했다. 그렇게 8 개월간의 진행되었던 프로젝트는 개발자로서 더 발전한 자신을 볼 수 있었고 성공적으로 마칠 수 있었다.
하지만 개발적으로 부족한 부분을 느꼈고, 더욱 좋은 개발자로서 성장하기 위해 SI에 지원하였다. 무엇보다 SI만의 빠른 일정을 소화할 수 있는 실무의 경험을 다지고 싶었고, 트렌디한 기술를 접목할 순 없겠지만 솔루션의 레거시 코드를 통해 공부를 하게 된다면 좋은 개발자로 성장할 수 있다는 느낌을 받았었기 때문이다.
주로 대기업들의 인사 통합 시스템을 개발을 담당하게 되었고 주된 업무는 사용자의 UI 설계부터 급여와 복리후생 파트의 전반적인 API를 개발했다. 여느 중소기업과 마찬가지로 개발자로서 요구되는 사항들이 막중했지만, 당시 팀 내의 분위기는 서비스의 질보단 일정을 소화하기 위해 퍼포먼스를 더 많이 요구했던 것 같다.
솔직히 나는 후자보다 전자를 더 중요하게 생각한다. 물론 개발자로서 퍼포먼스도 중요하지만, 새로운 기술을 습득하여 더 좋은 서비스를 제공하거나, 기존 개발 기술에 대해 이해하고 사용하여 특정 에러가 발생할 때 의연하게 대처할 수 있다. 하지만 부족한 개발 인원과 빠듯한 일정을 소화하기 위해, 시간에 쫓기다시피 개발을 하게 되고 어느 순간부터 정체되었다는 느낌을 받게 되었다.
업무와 스터디는 별개, 2018 스터디 그룹의 참여
우물 안의 개구리가 되는 기분이 들어 첫 프로젝트의 PL이었던 분에게 연락을 하였다. 지금 처한 상황과 어떻게 하면 지금 환경에서 좋은 개발자로 성장할 수 있는지에 대한 개발자의 방향성에 대해 상담을 받았다. 통화하게 되면 거의 1시간씩 했던 것 같다. 귀찮으실 법도 한데, 늘 친절하게 신입의 눈높이에 맞춰 대화를 해주셨다.
정확히 기억은 나질 않지만 2017년도 가을쯤 구로 디지털 단지의 한 참치집에서 약속을 잡게 되었고 반년만에 다시 보게되었다. 심도 있는 이야기를 나눴지만 이전의 통화했던 내용과 거의 같았다. PL님은 이야기를 듣고 나서 업무와 스터디는 별개라고 이야기를 해주셨고 스터디 그룹을 참여를 권유하셨다.
이에 나는 PL님이 스터디장으로 있는 Ahea 스터디에 가입할 수 있느냐고 물었고 이에 PL님은 난처한 얼굴로 잠시 고민을 했다. 사실상 Ahea 스터디의 가입 조건엔 반드시 스터디를 한 주제로 Conference 발표를 해야만 하는데, 나는 주로 SI 프로젝트를 파견을 나가 시간상 여유가 없어 보여 스터디를 잘할 수 있을지 의문이 든다고 했다. 하지만 간절했기 때문에 더욱 자신감 있게 할 수 있다고 말하였고 부족하지만, 나의 간절함을 보셨는지 Ahea 스터디 그룹에 2018년도부터 동참하게 되었다.
자신감이 충만했던 첫 스터디
우선, 처음 스터디 그룹에 참여하다보니 주제선정부터 어려움이 있었다. 스터디 당시에 TDD와 테스트 코드가 유행을 할 시기여서인지, 스터디 그룹원들이 TDD에 대한 주제를 하면 어떻겠냐며 추천을 했다. 나 또한 SI 프로젝트에서 여러 난잡한 레거시 코드와 중복코드를 많이 볼 수 있었고, 리펙토링과 테스트에 관심이 있었기 때문에 TDD를 스터디하게 되었다.
추상적인 TDD 주제선정
하지만, TDD를 아는 주변 개발자들이 없었고 무엇보다 주도적으로 주제를 선정하고 스터디를 하는 방법에 익숙하지 않아, 어디서부터 무엇을 공부해야되는지 갈피를 못잡았다. 우선 TDD에 대해 알기 위해 테스트 주도 개발 Test-Driven Development 책을 사서 틈틈이 독학을 하였다.
어느 정도 TDD에 대해 알 수 있었던 순간부터 주제를 잘못 선정했다고 생각이 들었다. 단기간에 스터디를 하기엔 TDD는 추상적이고 너무나도 큰 주제였다. 첫 스터디인 만큼 잘 마무리하고 싶은 마음에 포기는 할 수 없었다. 기업들이 어떻게 TDD를 활용하고 있는지 알기 위해 검색을 하였고, 페이스북에서 이규원 개발자님이 진행하던 TDD를 참관하게 되었다. 이규원님은 TDD는 양날의 검과 같고, 많은 프로젝트에서 TDD를 도입하려 시도하였지만 실패한 사례들을 많이 보았다고 한다. 더욱 혼란스러웠다. TDD를 하지 말라는 건가…. 개발자로서 그렇다면 어떻게 TDD의 습관을 기르면 좋은지 질문을 다시 물었다. 이에 이규원님은 똥들로 격리하는 것부터 진행해보면 좋다고 했다. (예를 들어 인 메모리 데이터베이스인 H2를 로컬 환경에서 구축하고 통합 테스트를 진행해보는 것부터 시작하는 것처럼)
여러 질문에 대한 답변을 통해 청중들이 TDD에 대해 무엇을 원하고 듣고 싶은지에 대해 알 수 있었다. 그렇지만, 이 과정까지 너무 많은 시간을 소비되었고 발표까지 한 달이라는 시간밖에 남지 않았다. 이미 Conference의 일정을 최대한 미뤘기 때문에 더 이상 미룰 수 없었다.
스터디의 실패, 2018 Ahea Confernece 취소
결국, 2018년도의 Ahea 세미나는 복합적인 내부 사정에 의해 진행할 수 없다고 판단을 했고, 진행하지 않았다. 이러한 결과는 나의 잘못이 크다 생각한다. 냉정하게 말하자면 스터디의 결과물이 좋지 않았기 때문이다. 근본적인 이유엔, TDD라는 추상적인 개념의 주제를 선정하였기 때문이라 생각한다. 물론 TDD는 발표에 있어 청중들이 원하는 베스트 주제였지만, 아무래도 이러한 추상적인 주제에 대해선 깊게 파면 팔수록 끝이 없고 자칫 잘못하면 주제에 대한 갈피를 잡지 못해 이도 저도 아닌 상황이 될 가능성이 크다. 나 역시도 이 케이스에 빠져버렸다.
나는 모든게 처음이었고 서툴렀으며 욕심이 많았다. 첫 스터디 참여, 첫 주제 선정, 첫 스터디 진행 그리고 실패. 돌이켜 생각해보면 그냥 자신감만 넘쳐 무작정 TDD를 선정했던것 같다. 당시에 나는 TDD의 배경 지식뿐만 아니라 기본적인 단위 테스트 코드를 작성하는 법도 몰랐다. 결론적으로 실패에 대한 원인은 “Spring에서 다양한 단위 테스트 작성 방법”처럼 청중들이 원하는 실무적인 기술보다는, 전반적인 TDD의 추상적인 개념에 대해 이해하는 시간을 많이 소비했기 때문이라 생각한다.
누군가에겐 3~4 개월이라는 스터디 기간은 짧다 생각하면 짧고, 길다 생각하면 길지만, 이 기간 동안에 주제선정 방식과 주체적인 스터디 방식에 대해 느낄 수 있었고 무엇보다 내 자신에 대해 반성하는 시간을 가질 수 있었다.
실수를 반복하지 않기 위한 메모
바보 같은 실수를 반복하지 않기 위해 마지막으로 실패에 대한 원인에 대해 실용주의 프로그래머 책에 나오는 글귀를 인용하여 정리를 해보려 한다.
WISDOM - 청중 이해하기
- 무엇(WHAT)을 배우길 원하는가?
- 얼마나 소양(sophisticated)이 있는가?
- 말하려는 것에서 그들이 관심(interest) 있어 하는 건 무엇인가?
- 어느 정도의 구체적인(detail) 내용을 원하는가?
- 누가 정보를 소유(owe)하길 원하는가?
- 그들이 경청하도록 동기(motive)를 주려면 어떻게 해야 할까?
우리는 전형적인 개발자가 난해한 기술의 장점에 대해 긴 독백을 읊조리는 동안, 앉아 있는 마케팅 부사장의 눈이 점점 흐리멍텅해지는 회의에 참석해 봤다. 그건 소통이 아니다. 단지 지껄임일 뿐이다. … 청중에 대한 뚜렷한 그림을 가져야 한다.
- 청중이 무엇을 배우길 원하는지는 명료했다. TDD를 하고 싶었다.
- 주제는 추상적인 개념보단, 구체적인 개념으로 선정하자.
- 실제 업무에서 어떻게 TDD를 접목하고 있는지 자료들이 부족했고 실제로 겪어보지 못해 많이 어려웠다.
- 업무와 연관된 주제를 선정하자.
- TDD는 추상적인 개념이고 하나의 방법론이기 때문에 호불호가 많이 났다.
- 차라리 Spring에서 단위 테스트 코드에 대한 주제로 스터디를 진행했다면 달라졌을 것 같다.
- 어디서 어디까지 전달해야 할지 감이 잡히질 않았다.
- 먼저 큰 목차를 선정하여 흐름을 만들고 구체적으로 진행하자.
- 주니어 개발자의 대상이다.
- 물론 발표는 주니어 대상이지만, 내용은 시니어급으로 목표를 두자.
- 이 부분에 대해선 많은 연습이 필요하다.
- 청중과 소통하고 여유를 가질수 있도록 발표를 연습해보자.