2020년 상반기 회고 1편: 코드스쿼드 마스터즈 코스

지속가능한 학습 및 협업 역량을 어떻게 기를 것인가? 를 고민하다

고등학교 졸업 이후 3년 만에 졸업장(?)을 받다. 대학 졸업은 언제쯤 할 수 있을까?

2020년 상반기에는 풀타임 기술교육 학생으로서, 파트타임 기술교육 기획자로서 활동하였다. 주중에는 코드스쿼드의 마스터즈 코스를 들으면서 자바 백엔드를 학습했고, 주말에는 개발자들이 교육자로서 활동하는 설리번 프로젝트를 기획하고 진행했다. 지난 7개월 동안 교육자와 학생의 이중 생활(?)을 회고하고자 한다. 이번 글에는 코드스쿼드 과정에 대한 이야기를 해보도록 하겠다.

어쩌다 개발을 하게 되었는가?

어렸을 적부터 일반 사용자를 대상으로 실제 동작하는 프로덕트를 만드는 것에 대한 동경이 있었다. 대학생이 되어 블록체인 업계에서 인턴십을 거쳤다. 비록 나는 ‘탈블’ (블록체인 업계를 떠난다는 의미) 했지만, 소프트웨어가 공기처럼 보이지는 않지만 사회를 움직이게 하는 힘이라는 사실을 느꼈다. 세상과 사회의 동작 방식과 그 원리를 탐구하는 것을 원래부터 좋아했던 나는 자연스럽게 개발에 대한 흥미가 생길 수밖에 없었다. 복학하고 나면, 파이썬 수업을 들어야겠다고 생각했다.

2019년 1학기에 수강신청한 파이썬 수업은 컴공생의 1학년 필수 수업이었다. 그런데 내가 생각보다 잘 따라가지 못했다. 수업 자체는 정말 알찼음에도 불구하고, 나는 개념을 배우는 것이 그저 따분하다고 생각했다. 수강신청 당시의 흥미가 얼마 가지 못했다. 재미가 없으니 공부를 하지 않았다. 수업마다 있던 퀴즈에서 종종 낙제점을 받으니, 공부 한 번 제대로 하지 않았으면서 단순히 “소질이 없나” 생각하기도 했다. 그렇게 종강을 맞이했다.

보통 낙제에 가까운 점수를 받게 되면, 학습을 지속할 수 있는 동기가 크게 저하되고 만다. 하지만 본인은 적성이 안 맞는 것이 아니라 수업이 나랑 안 맞았던 것(?)이라고 생각했다. 왜 그렇게 생각했는지는 모르겠다. 지금 생각해보면 낮은 학업성취에 대한 합리화였다. 그럼에도 나는 운이 좋았다. 주위에 좋은 개발자들이 많았다. 종강을 하고 나니 그제서야 다시 공부를 해야겠다(?)고 생각했다. 떨어진 의욕을 되찾기 위해 학교 수업 외의 다른 대안을 찾아보기 시작했다.

하필 소프트웨어 분야에 개발자가 부족해서, 개발자만 전문적으로 양성하는 부트캠프가 많아지고 있다고 한다. 교육계획서와 각종 후기 블로그를 다 찾아보았다. 마음에 드는 곳이 잘 없었다. 조금 더 찾아보니, 세상 멋진 IT 회사 여러 곳에서 개발자를 육성하는 교육 사업을 하고 있다고 한다. 짱짱한 회사에서 여는 교육은 뭔가 재미있으려나?

우연한 기회에 네이버 커넥트재단에서 운영하는 부스트캠프 2019의 인턴으로 6개월 근무하게 되었다. 부스트캠프는 지속가능한 개발자의 학습 커뮤니티를 슬로건으로 내세우는데, 학교의 단방향 수업방식이 아니라 동료 간의 상호 학습을 강조한다. 수업이 겨우 일 주일에 2시간 정도 이루어지는데, 마치 게임을 하듯이 미션을 수행하고 동료와 함께 성취 내용을 피드백하며 성장하는 모습이 그저 신기했다.

요즘 사회는 각박하다보니 사람들이 마음이 맞는 친구를 찾기 위해 커뮤니티를 많이 찾는다고 한다. 그런데 커뮤니티는 참여하는 개개인의 성장이 담보되어야 지속 가능하지 않을까? 커뮤니티 안에서 서로 협력하면서 함께 자라기를 실천할 때 건강한 커뮤니티가 되지 않을까? 결국 커뮤니티의 성장은 교육에서 시작되지 않을까 생각했다.

개발자 커뮤니티는 어딘가 서로 공유하면서 성장하는 문화가 있어보였다. 단순히 하루하루 학습한 내용을 공유하는 개발자들의 TIL 마저도 신기해보였다. 공유하면서 성장하는 문화가 새로운 교육 시도를 해볼 수 있는 토양이 된다고 생각했다. 본인이 인턴으로 근무할 때는 스태프의 입장이었고, 교육 현장에서 다소 떨어진 위치에서 관찰하고 고민하는 것에 그칠 수밖에 없었다. 이 점이 아쉬웠다.

나도 학습자의 입장에서, 또는 기획자의 입장에서 현장에 다가가서 고민하고 싶었다. 기획자의 입장은 설리번 프로젝트에서 더욱 열심히 참여하면서 고민해보기로 하였다. 설리번 프로젝트에 대한 회고는 다음 글로 넘기기로 하자. 학습자의 입장에서도 서 보고 싶었다. 개발 학습에 대해 한 번 실패를 겪은 만큼, 다시 시도해보고 싶기도 했다.

하필 부스트캠프의 교육 파트너인 코드스쿼드에서 자체적으로 운영하는 마스터즈 과정을 선발한다고 한다. 시험도 본다고 하니, 무작정 JetBrains 사의 학생 라이센스를 발급받아 호눅스의 자바스크립트 입문 강의를 수강했다. 작은 프로젝트를 직접 만들어보면서 실전을 먼저 접하고, 이에 따라오는 개념을 이후에 접하는 교육 방식이 너무 재미있었다. 추석 전날에 집에서 1강을 들었는데, 정신을 차려보니 추석 연휴가 다 끝나 있었다. 현장 수업도 들어보고 마스터즈 코스 수강 여부를 판단하고 싶어서, iOS 스페셜 코스를 수강했다. 교육자가 직접 1:1 피드백을 제공하는 것이 성장에 있어 큰 도움이 된다고 느꼈다.

그렇게 과정 입학을 신청했다. 첫 입학 시험은 야구 게임을 만드는 것이었다. 2주 정도 날밤을 새가면서 만들고 부수고 다시 만들고를 반복했다. 인생 첫 코딩 과제였다. 오프라인 면접을 보러 가니 호눅스가 Git 강의를 해주고, 갑작스럽게 문제를 내 주었다. 옆 사람과 토론을 해도 된다는 기상천외한 규정이 있었다. 솔직히 나는 깃 강의를 잘 이해하지 못했는데, 옆 자리에 있던 사람에게 일일이 물어보면서 답을 채웠다. 그렇게 합격했고, 나도 개발자가 될 수 있는 건가(?) 하는 마음으로 2020년 1월 2일 과정에 합류하게 되었다. 닉네임을 하나 적어오라고 해서, 내가 좋아하는 노르웨이 가수 Sigrid에 영어이름 Jin을 합쳐 Sigrid Jin으로 정했다!

조급하지 않아도 괜찮다. 일단 한 바퀴를 완주해보고 생각하자.

1월 한 달 간에는 컴퓨터공학(CS) 지식을 훑어보는 시간이었다. 16개의 미션이 있는데, 하나의 미션은 하나의 지식 키워드를 담는다. 첫 미션은 반가산기와 전가산기에 대한 내용이었는데, 도대체 무슨 소리인지 이해가 되지 않았다. 13시에 미션이 발표되면, 다음 날 10시까지는 들고 가야 팀 동료들과 함께 구현 내용을 피드백할 수 있었다. 처음에는 어떻게든 밤을 새가면서 들고 갔지만, 날이 갈 수록 지치기 시작했다. 할 수 있는 게 맞는가!

코드스쿼드의 교육과정을 설계하는 마스터 JK에 따르면, CS16 과정을 통해 학부 과정에서 배우는 내용을 키워드로서 한 번 훑어보는 효과가 있다고 했다. 지금 모든 미션을 다 완수하지 못하더라도, 일단 미션을 해 봄으로써 한 바퀴 돌아본 것이 중요하고 못 채운 부분은 나중에 채워도 괜찮다고 했다. 나의 페이스에 맞게 학습을 조절하면 되는 것이 아닌가. 소위 ‘인공지능’ 시대에 우리는 평생 공부하면서 응용할 수 있는 방법을 찾아야 하는 것이 아닌가. 평가받지 않고, 미션을 수행하면서 학습한 과정을 서로 나누는 것이라면 일단 충분하지 않은가.

JK의 말대로 미션을 다 하지 못했다고 해서 잡아 죽이지는 않았다. 안 한다고 혼내거나 감점하지 않았다. 이 자체만으로 신기했다. 대신, 팀원 간의 미션 수행 과정을 공유하고 발표할 것을 권장했다. 평가 요소가 없기 때문에 내가 할 수 있는 만큼 했다고 보여줘도 괜찮았다. 날이 지날 수록 모든 요구사항을 완성해야 한다는 심리적 부담감이 사라졌다. 대신 하나를 하더라도 제대로 해야겠다고 마음 먹게 되었다. 이론으로 배우는 것보다, 직접 동작 원리를 하나하나 구현해보니까 학습 효과가 극대화되었다.

그렇구나. 마스터즈 코스에 입과한 사람들 모두 수준과 배경이 다르다. 누군가는 컴퓨터공학을 전공한 친구이고, 누군가는 현직에서 개발자로 일하다가 온 친구도 있다. 나처럼 아예 ‘문과 출신 노베이스’ 인 경우도 있겠다. 오전에 모여서 서로가 어떻게 진행했고, 각자의 느낀 점이나 사고 방식을 솔직하게 공유하면서 궁금증을 해소하고 때로는 토론을 한다. 일단 과거의 나보다는 성장하지 않았나? 누군가는 이를 ‘애자일 정신’ 이라고 부르더라.

다른 사람들과 고민을 나누며 친해지고 동료가 된다. 지식적으로도 성장한다. 때로는 너무 미션이 어렵다고 같이 욕하기도 한다. 경쟁자가 아니라 학습 동료임을 강조하고, 평가 대신 과정을 강조하니 생기는 선순환 구조이다. 지금 당장의 성취보다는, 함께 여러 바퀴를 완주하며 부족한 점을 끊임없이 발견하고 채워갈 수 있는 동료의식의 중요성을 느끼게 되었다. 모르는 부분은 다른 사람의 코드를 보고 틈틈히 시간날 때마자 학습하면 충분하다. 내가 무엇을 모르니, 어떤 것을 추후에 학습하면 되겠구나라는 생각만 있다면 우리는 꾸준히 성장할 수 있다.

일단 입문자라면, 모방은 성장의 어머니더라.

마스터즈 과정에서 크게 성장했다고 느끼는 세 가지 순간이 있다. 첫 번째 순간은 질문응답 게시판을 만드는 프로젝트를 진행했을 때였다. CS16이 끝나면 클래스 별로 모여서 수업을 진행한다. 해당 클래스가 반드시 구현할 수 있어야 하는 아주 기초적인 지식을 습득한다. 자바지기님이 직접 처음부터 질의응답 게시판을 만들어가는 강의를 보고 무작정 따라 만들어보는 과정이었다. 스프링 부트를 활용하여 처음으로 웹 서비스를 만들어보는 프로젝트로, 유튜브에 공개되어 있다.

GitHub의 Pull Request 과정을 통하여 선배 현직자로부터 나의 작업물에 대해 꼼꼼한 코드리뷰를 받을 수 있는 것이 큰 장점이다. 일단 기능이 완벽하지 않아도 괜찮으니, 요구사항을 모두 건드려보고 불완전한 작품을 제출한다. 리뷰어로부터 나에게 꼭 맞는 피드백을 제공받고, 궁금한 점은 슬랙으로 질문하고 때로는 토론하기도 한다. 수업은 주당 1~2회 진행한다. 프로젝트를 수행하기 위해 필요한 기초 지식을 알려주거나, 질문 사항에 대한 답변을 하면서 그 시점에 필요한 지식을 전달한다.

프로젝트를 진행하면서 유튜브 강의로는 부족함을 느끼고, 이동욱 개발자님의 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 책을 하나 구매해 예제 코드를 무작정 따라 치면서 요구사항을 충족하려고 노력했다. 과정을 함께 수강하고 있는 동료들의 저장소를 찾아본 뒤, 좋은 코드나 구현 아이디어가 있으면 이를 무작정 베끼려고 노력했다. 궁금한 점이 있으면 베끼려고 하는(?) 동료에게 의도를 물어본다. 내가 먼저 나서서 관심을 표명하고 질문하면 상대방도 용기를 내고, 서로 지식을 나누고 함께 성장하는 토양이 된다.

일단 내가 만든 게 돌아가면, “왜 이 코드가 동작할까” 가 항상 궁금했고 이를 탐구하려고 노력했다. 초심자 입장에서는, 좋은 작품을 모방하면서 학습하고, 그 과정에서 동작 원리에 궁금증을 느끼고 개념을 채워가면서 학습하는 것이 유효한 학습전략임을 느끼는 순간이었다. 한 번 사이클이 끝난 이후에는, 프로젝트를 새로 생성해서 참고자료 없이 처음부터 다시 만들어간다. 반복 주기를 계속 하다보면 일단 손에 익고, 추상적으로 다가왔던 개념이 구체적으로 다가옴을 느낄 수 있다. 일단 지금 이해 못해도 괜찮다. 푹 자고, 내일 다시 시도하자! 모르는 것은 모른다고 이야기하자! 그렇다면 많은 사람들이 발 벗고 도와주리다.

자바지기님은 침묵으로 가르치기라는 책을 언급하면서 교육자가 직접 강의하지 않더라도, 수강생이 능동적으로 지식을 습득하고 성장하도록 유도할 수 있다고 주장한다. 학습해야 하는 지식 키워드를 알려주고, 만들어야 하는 프로젝트를 알려주고, 동료와 함께 프로젝트를 무작정 완성해보고, 프로젝트를 만들어가는 과정에서 필요한 개념을 역으로 습득한다. 먼저 만들어가고 실습하면서 학습했을 때, 해당 개념이 어디에 쓰이고 왜 필요한 지를 자연스럽게 터득할 수 있다. 일방적인 강의보다는 리뷰어의 개인 피드백과 동료와의 거친 토론을 통해 기술적 역량이 성장한다는 사실을 피부로 체감했다.

커뮤니케이션과 사람에 대한 이해가 전부더라!

클래스별 수업을 통해 기초적인 역량을 길렀다면, 이제는 실전으로 넘어가야 한다. 실전은 다른 사람들과 함께 협업하며 하나의 완성된 Product/Service를 만들어가는 것이다. 실전을 최대한 모방하면서 주어진 기획서에 따라 서비스를 완성하라! 부족하다고 여겨지는 역량이 있다면, 다른 사람들과 협업 프로젝트를 해 보면서 깨져보고 이를 통해 시행착오를 겪으며 성장하라! 걸음마를 막 뗀 아이에게 뜀박질을 시키는 꼴이지만, 걸음마를 할 수 있다면 불가능한 것은 아니다.

낯선 지식과 낯선 환경에서 성장하려면 내가 지금 무엇을 하고 있고, 어떠한 성취나 실패를 겪었으며, 이러한 도움이 필요하다는 사실을 솔직하게 공유해야 한다. 1주에서 3주 간, 매일 8시간 이상을 함께해야 하는 팀으로 만났다면, 즐겁게 프로젝트를 진행하는 것이 우선 가치 아니겠는가. 팀원의 생활 패턴과 개발 상황을 이해하여야, 분쟁 없이 즐거운 환경 속에서 함께 자랄 수 있다. 서로의 고민거리와 기쁜 일 등을 서로 공유하고 개발 진척에 있어서 서로 자극이 될 수 있도록 스크럼과 회고의 규칙을 함께 정했다. 예를 들어 야구게임 프로젝트 규칙이 있겠다.

야구게임 프로젝트의 그라운드 룰 규칙이다. 이 때는 코로나로 재택이 자주 있어서 행아웃을 켜고 공지하는 역할을 내가 자임했다.

하지만 훌륭한 그라운드 룰을 정했더라도 실천하지 않으면 아무런 의미가 없었다. 특히 코로나19 사태로 인하여 팀원 간의 오프라인 소통이 어려운 시점이었다. 많은 시행착오가 있었는데, 먼저 팀 활동 알림을 던져주는 넛지(nudge) 역할이 있어야 일이 진행된다는 사실을 깨달았다. 넛지 역할을 반복하자 우리 모두가 어려운 상황 속에서도 팀 그라운드 룰이 일상이 될 수 있었고, 프로젝트를 즐겁게 마무리할 수 있는 토양이 되었다.

이 외에도 슬랙 채널에서 팀원이 올리는 메시지에 충분한 리액션을 달아주는 것이 팀원으로서 동질감과 연대의식을 느낄 수 있도록 도와주는 좋은 방법이었다. 슬랙 이모지를 사용하는 것도 좋은 방법이다. 내가 어떠한 제안과 도전을 하더라도 사람들이 진지하게 들어줄 것이라는 심리적 안정감을 제공하는 것이 팀 문화 조성에 있어서 최우선 가치라고 생각하기 때문이다.

코드리뷰를 통해 함께 자라기를 실천하자!

우리는 개발자이므로 코드를 통해 객관적으로 상태를 평가하고, 잦은 소통과 코드리뷰를 통해 서로의 성장을 도울 수 있다. GitHub의 Pull Request를 활용하여 내가 진행하는 작업에 대해 궁금증을 남기고, 상대 페어가 함께 고민하고 나름의 답을 달아주면서 함께 문제를 해결하고 성장하는 과정을 얻을 수 있었다. 서로의 고민 및 질문거리를 서면으로 남기고, 그라운드 룰로 정한 매일 오후 14시에 만나 함께 페어 프로그래밍을 하고 고민 내용을 해결한다. 이 과정을 통해 우리가 한 팀이고, 함께 성장하는 동료임을 느낄 수 있었다.

야구게임 프로젝트를 진행할 때 페어와 함께 분업하고, 서로의 작업에 대해 코드리뷰를 한 모습

한 예로, TODO 프로젝트를 진행할 때 그 동안 팀 내에서 혼자 백엔드 개발을 해 왔던 페어랑 함께 하게 되었다. 해당 페어는 모든 기능을 직접 구현해보면서 학습하는 것을 선호했다. 페어는 프로젝트 진행 이전에 많은 부분에서 학습의 기회를 잃을까봐 걱정하는 의견을 주었다. 이러한 걱정은, 초창기에 프로젝트를 진행할 때 저도 가지고 있었던 고민이었다. 기획서 요구사항이 담고 있는 영역을 최대한 많이 학습하고 싶다는 욕심, 이것의 학습기회를 프로젝트할 때 놓치면 다음 주기에는 학습하기가 어려울 것이라는 막연한 불안함이 존재했다.

하지만 TODO 프로젝트를 진행하면서 GitHub의 Pull Request를 통한 코드리뷰 과정을 거치면서 이러한 두려움을 씻어낼 수 있었다. 코드리뷰를 통해 내가 짜지 않은 기능에 대해서도 학습할 수 있는 기회를 얻을 수 있었기 때문이다. 오히려 내가 구현하지 않은 코드를 리뷰하면서, 나의 코딩 스타일에 적용해볼 수 있는 학습거리를 찾을 수 있었다.

이슈 관리 프로젝트에서 이슈를 활용하여 협업한 모습

이러한 경험을 통해 나는 과정에서 페어협업을 할 때 다음과 같이 하고자 노력했다.

가. 13시 30분: 백엔드 페어 스크럼을 통해 서로 기대하는 점이나 우려하는 점, 오늘 할 일을 공유한다.
나. 14시-18시: 공통 작업시간으로 두어 각자의 PR과 코드 리뷰를 설명하고 Merge한다. 작업할 때는 이슈를 만들자. 때로는 함께 작업해야 하는 기능 또는 리팩토링이 있을 경우 페어 프로그래밍을 진행한다.
다. 18시 30분: 백엔드 페어 회고를 통해 오늘의 작업 내용을 정리하고, 각자의 회고를 상대방이 적어준다.
라. 19시 이후: 서로 분업하기로 한 사항에 대해 자유롭게 작업하고, 작업이 완료되면 PR을 보냅니다. 상대방 PR이 있을 때에는 코드 리뷰를 진행한다.

예측 가능한 협업을 하기 위해 노력하자!

나는 백엔드 클래스를 수강하고 있으므로, iOS 및 Web 클래스 동료에게 API를 제작해야 하는 임무를 띄고 있다. 가장 어려운 점은 프로젝트를 시작할 때 API에 대한 합의를 어떻게 맞추느냐이다. 비즈니스 로직을 작업하다보면, API 명세가 자꾸 바뀔 수밖에 없다. 배포 버전마다 새로운 API가 추가, 삭제 또는 수정된다. 사전에 클라이언트 개발자와 충분한 대화와 토의를 통해 API 명세를 합의하지 않는다면, 협업하기 매우 어렵다.

또한, API가 나오기까지 상당한 시간이 걸리므로 클라이언트 개발자가 실제로 서버와 소통해볼 수 있는 시간이 너무 길어진다는 단점이 있다. 본인이 완벽주의 성향이 있다보니, 프로젝트를 처음 할 때에는 일정한 수준이 달성되지 않으면 1차 배포를 하지 않았다. 이는 클라이언트 개발자에게 불편함을 초래했다. 자꾸 배포 버전마다 API 명세가 달라지기 때문에 클라이언트 개발자가 API를 제대로 사용하지 못했다. 클라이언트 개발자는 어떤 기능이 어떤 배포 버전에서 구현되었는지 알기 어려웠다. 팀의 불화를 겪었다.

이후에 나는 내가 만드는 HTTP API는 클라이언트 개발자를 고객으로 둔 서비스(프로덕트)라고 생각하기로 결심했다. 미리 가짜 데이터라도 던져주고, 이후에는 중요한 비즈니스 로직부터 만들면서 기능을 빠르게 구현하자. 클라이언트 개발자가 API를 활용해볼 수 있도록 함으로써 우리가 만들어가는 API가 실제로 사용이 가능한 지 자주 테스트해보자. API 배포 주기 및 기능을 사전에 예고하여 클라이언트가 예측비용을 줄여주자.

야구게임 프로젝트의 API 명세서 예시

주 2일 배포(수, 금)을 목표로 백엔드 개발 마일스톤을 세우자. 해당 마일스톤을 깃헙의 기능개발 이슈마다 등록함으로써 클라이언트 개발자들이 마일스톤의 달성 일시를 예측할 수 있도록 도왔다. 매주 예정된 배포일 전날에, 다음 날의 배포 일정과 예상 추가/수정 기능을 문서로 제공하고 이를 슬랙 채널에 공지했다. 매일 스크럼 시간에는 추가되거나 수정될 기능에 대한 JSON 양식을 사전에 협의할 수 있도록 미리 문서를 만들어 클라이언트의 빠른 협의를 꾀했다. 배포가 이루어질 때 해당 배포의 목적(기능 추가, 핫픽스, 더미 데이터 추가, JWT 인터셉터 사용 중지 등)과 배포 차수를 명시하여 슬랙 채널에도 공지했다. 이러한 노력을 통하여 클라이언트가 충분히 예측 가능한 일정과 범위 하에서 안정적으로 개발에 전념할 수 있었고, 불필요한 소통 비용을 줄일 수 있었다.

뛰어난 엔지니어는 무엇이 필요할까. 기술적 역량이 탄탄해야 하는 것은 기본이다. 하지만 일정한 역량이 넘어가면 이야기가 다르다. Pivotal Software와 같은 곳에서 근무하며 프레임워크를 유지보수/발전시키며 기술적 역량이 Top 1%가 되는 방법이 있을 것이다. 하지만, 나를 포함한 많은 사람들이 기술적 역량이 세계 최고가 되는 것은 어렵다.

대신, 다른 엔지니어와 행복하게 협업하고 근무할 수 있는 ‘소프트 스킬’ 역량을 기를 수 있다. 이는 순위로 매겨지는 역량이 아니라, 누구나 얻을 수 있는 인간사회적인 역량이다. 해당 역량은 일반 사용자용 소프트웨어를 제작하는 개발자 입장에서, 나의 소프트웨어를 사용하는 소비자와 비즈니스를 이해할 수 있는 기초 체력이 될 것이다. 마스터즈 과정을 통해서 얻었던 가장 큰 자산은 기술적 지식이 아니라, 어떻게 협업할 것인지에 대해 고민할 수 있는 기회였다.

꾸준한 테스트를 통해 나의 의도를 남에게 알리고, 더 나은 방향을 고민하자!

코드스쿼드 교육과정의 가장 큰 장점은 실무에서 요구하는 역량을 기를 수 있다는 것이다. 앞서 언급했던 역량도 중요하지만, TDD와 리팩토링, 클린코드, 객체지향과 같은 설계에 있어 필요한 역량을 계속 키워드로 언급하며 고민할 수 있도록 한다. 덕분에 나는 테스트 코드에 대해 알게 되었고, 기능 하나를 구현할 때마다 테스트 코드를 먼저 작성하는 습관을 기를 수 있게 되었다.

테스트를 모두 통과한 순간에 이너피스를 느낄 수 있고, 그 자체만으로 개발을 계속하는 동기가 된다

실패하는 테스트를 통과시키는 과정에서 희열감을 느끼고, 더 나은 구현 방법을 고민해서 리팩토링한 뒤 이를 통과시키는 과정에서 보이는 초록색 불빛은 프로그래밍을 하는 과정에서 큰 성취감을 느낄 수 있도록 한다. 내가 지금 당장 어떠한 작업을 하면 되는 지 분명한 목표를 세울 수 있고, 해당 목표를 작지만 여러 번 통과시키면서 서비스를 빠르게 구현해보고 구현한 코드를 수정할 수 있다. 나는 테스트 코드의 팬이 되자, 자바지기님이 운영하는 NEXTSTEP 클린코드 8기 과정을 수료하면서 TDD를 주말에 따로 연습하였고, 주중에는 프로젝트에 알게 된 지식을 적용하고 다른 동료에게 전파하려고 노력했다.

TDD를 처음으로 적용하려고 시도했을 때, 관심을 보이는 동료가 있었다. 해당 동료와 우연하게 야구게임 프로젝트를 함께 하게 되었다. 우리는 중요한 비즈니스 로직을 먼저 구현하는 것을 목표로 마일스톤을 세웠다. 해당 로직을 통과하기 위한 테스트를 만들고, 해당 테스트를 통과하는 로직을 짝 프로그래밍을 통해 구현했다. 개별적으로 작업할 때는, 서로가 구현한 로직의 의도를 테스트를 통해 보여주고자 노력했다. 페어 프로그래밍 시간에는 해당 테스트를 통과하면서도 더 나은 방법을 고민했다. 이 과정을 통해 빠르게 API를 클라이언트 개발자에게 제공하고, 클린코드를 고민하는 기회가 되었다.

테스트 코드의 작성 및 TDD 지향이 처음에는 어렵더라도, 반복적으로 연습하다보면 빠르게 기능을 구현하는 데 도움이 되면서 동시에 협업에도 이점이 있다는 사실을 알게 되었다. 하지만, 다른 프로젝트에서 다른 동료와 함께 TDD를 적용하는 것은 다소 어려웠다. 테스트 코드를 작성하는 것조차 익숙하지 않은 동료에게 TDD를 강요할 수는 없는 노릇이다.

페어 프로그래밍 시간이 있으니 이 때 나의 방식을 소개하면서 흥미로워 보이도록 소개한다. 팀의 상황에 맞추어 왜 이 변화여야 하는 지 먼저 고민하고, 나의 의견을 솔직하게 제시함으로써 공감대를 형성해야 한다. 그 과정에서 만약 동료가 흥미와 관심이 있다면, 적용할 수 있도록 함께 고민한다. 테스트 코드를 작성하는 것조차 어려워하는 동료가 있다면, TDD를 하기 이전에 매번 비즈니스 로직을 만들고 테스트 코드를 이후에 추가하는 방식으로 짝 프로그래밍 시간에 구현했다.

컨트롤러 테스트가 어려우니 서비스 테스트에서 작은 로직 하나를 검증하는 것을 목표로 구현했다. 이 과정을 통해 동료와 함께 TDD, 테스트 문화를 함께 고민하고 만들어갈 수 있었다. 우리 함께 프로젝트에 적용해가면서 필요성을 느끼고, 팀의 상황을 생각하며 작은 변화를 여러 번 만들어가는 것이 큰 변화를 만들 수 있는 동력이라는 사실을 깨달았다.

결국 코드스쿼드에서 얻은 것은, 좋은 동료가 첫 번째이고 협업하고 학습하는 자세가 두 번째더라.

코드스쿼드 과정이 끝난지 약 2달이 지났고, 이후에도 나는 계속해서 공간에 나와서 코딩을 하고 있다. 코드스쿼드 공간을 돌아다니며 상대방이 어떤 것을 작업하고 있는 지 궁금증을 먼저 표한다. 키야(kiyaa) 한 번 외쳐주고 뭐하고 있는 지 동의를 구하고 살펴보면 된다. 그 과정에서 서로 도울 수 있는 것을 찾고, 서로 돕는다. 내가 작업하다가 어려운 점이 있으면 상대방에게 먼저 물어보거나 슬랙 채널에 도움을 요청한다.

때로는 코드리뷰어가 되어 동료의 프로젝트에 코드 리뷰를 남기고, 동의하거나 동의하지 않는 경우에 오프라인 공간이나 온라인 슬랙에서 늦게까지 열띤 토론을 벌인다. 그러다가 밤 11시가 되고, 자연스럽게 오늘 공간의 문을 닫는 ‘밤코 요정(밤에 코딩하는 요정)’ 이 되어 문을 닫은 뒤 그 날의 밤코 인증 멘트를 올린다. 이 과정에서 동료 및 학우와 함께 문제를 해결하고, 서로 성장하며, 그 과정에서 동료애를 느낀다. 가끔 술을 마시며 서로의 아쉬운 점, 기뻤던 점, 고민거리를 나누며 동료가 된다. 좋은 사람과 동료를 만났다는 것이 가장 큰 수확이다.

동료와 함께 코드스쿼드 강의실 칠판에서 ATDD에 대한 열띤 토론을 벌였다.

앞으로 내가 개발자로서 삶을 꾸려나갈 지는 선택에 달려있다고 생각한다. 좋은 커리어 옵션이 추가된 것은 사실이다! 언젠가 유명 벤처투자자 Anderssen Horowitz가 언급했듯 소프트웨어가 세상을 잡아먹는 시대(Software is eating the world)가 이미 도래했다. 그 과정에서 소프트웨어를 잘 이해하고, 소프트웨어를 통해 세상을 만들어가는 사람들과 함께 재미있는 일을 꾸려가고, 그 과정 속에서 더 나은 세상을 만들어가는 방법을 고민할 수 있었다는 것만으로도 아주 값진 6개월이었다.

어떻게 다른 사람들과 협업할 것인가? 빠르게 트렌드가 바뀌는 IT 세상에서 지속가능한 학습 역량을 쌓으려면 어떠한 태도를 갖추어야 할까? 위의 문단에서 언급했던 내용들이 모두 협업과 소통의 역량이다. 나는 대학을 다니다 말다 하다가 코드스쿼드에 합류했던 가장 막내 23살이었고, 다른 동료들은 다양한 배경과 나이를 갖고 있었다. 여기에서는 우리 모두 닉네임을 부르며, 평등한 관계에서 함께 자라기를 추구할 수 있었다. 다양한 배경의 사람들과 함께 프로젝트를 하고 미션을 수행하면서 성장하는 방법을 학습할 수 있는 기회가 또 어디 있겠는가? 그 자체만으로도 아주 크게 성장할 수 있었다. 누군가 코드스쿼드 마스터즈 과정을 고민하고 있다면, 적극적으로 추천하고 싶다. 단순한 부트캠프가 아니라, 소프트웨어 장인정신과 협업하며 함께 자라는 방법을 배우고 고민할 수 있기 때문이다.

다음 회고 2편으로는, 기술교육 기획자로서 설리번 프로젝트를 설계하고 추진했던 과정에 대한 이야기를 풀어보고자 한다. 정말 긴 글인데 읽어주신 모든 분들에게 감사하다.