소프트웨어 마에스트로 15기를 마무리하며

어제부로 마지막 최종 발표가 끝났다. 프로젝트 퀄리티에 비해 발표가 잘된 것 같아 다행이다. 많은 것들을 얻은 시간인 만큼 후기 글을 써보려 한다.

합격하기까지

서류와 코테

많은 기업들도 그렇지만 어느 정도 이상을 채우면 서류를 비교적 쉽게 통과시키는 경향이 있는 듯 하다. 어차피 코테는 별다른 노력 없이 시행할 수 있고 그 이후에 서류를 검토해도 늦지 않기 때문이다. 심지어 소마 서류는 자기소개서가 큰 부분을 차지하니 화려한 이력보단 자기소개서에 집중하고 코테를 준비하는게 나을 듯 하다.

아무래도 기업의 채용 코테보단 허들이 낮다는 생각이 들었다. 경쟁률이 높다고는 해도 지원자의 대부분이 현역 대학생들이기 때문에 취준생들보다는 코테 실력이 떨어지는게 사실이다. 문제 자체는 크게 다르지 않지만 어차피 지원자들도 다들 고만고만하니 열심히 준비하되 너무 무서워할 필요는 없다.

포트폴리오 발표와 면접

지금와서 생각해보면 딱히 스펙이라고도 할 내용이 없었던 포트폴리오였다. 간단한 팀 프로젝트 몇 개와 운 좋게 몇몇 사람들이 써준 오픈소스 프로젝트 하나가 다였던 것 같다.

그럼에도 붙을 수 있었던 이유를 꼽자면 프로그래밍에 대한 열정이 잘 드러났던 것 같다. 돈이 부족함에도 어떻게든 클라우드를 써보려고 OCI 프리티어를 썼다든지, 컴퓨터공학과를 복수전공한 이후로 꾸준히 기술블로그를 운영해왔다든지 하는 것들 말이다. 멘토님들도 면접관으로 들어오시는데, 나중에 여쭤보면 열정적으로 마지막까지 꾸준히 할 수 있는지 여부를 제일 우선적으로 보신다고 한다.

그러니 새로 준비하시는 분들도 스펙이 없다고 미리 좌절하지는 않기 바란다. 화려한 스펙을 가지고 면접에 들어가면 취직을 하지 않고 굳이 소마를 들어오려는 이유를 캐물으신다. 취직을 이유로 중도에 이탈하는 연수생이 꽤 있기 때문에 그런 듯 하다. 번쩍번쩍한 스펙보다는 열정과 성실함을 증명할 수 있으면 되지 않을까 싶다. 꾸준히 하고 있는 활동이 있다던가, 굳이 과제로 주어지지 않더라도 자발적으로 진행한 프로젝트들에서 진실성이 느껴진다던가 하는 것들 말이다.

더 자세한 합격후기는 다른 글에서 소개했으니 거기서 확인해주시길 바란다.

예비과정

앞으로 반 년을 함께 달릴 팀원과 멘토님들을 만나는 시간이다. 단연코 가장 중요한 시간이 아닌가 생각이 든다. 본 과정에 들어서서는 HR과 관련된 결정을 내릴 수 없다. 아무리 팀원이 이상해도, 아무리 멘토가 마음에 안들어도 바꾸기 힘들기 때문에 이때 정말 잘 결정해야 한다.

한편으로는 아무리 사람보는 눈이 좋다 자부해도 2~3주 안에 자기와 잘 맞는 사람 5명을 찾기란 쉽지 않다. 가능한 모든 멘토링을 신청해도 시간적, 체력적 한계로 못 만나는 멘토님들이 계시고 아무리 활발하게 돌아다녀도 만나지 못한 연수생들이 있다. 이렇게 놓고 보니 어쩌면 반쯤 운에 맡겨야 하는지도 모르겠다.

심지어 이 기간 동안 프로젝트 주제도 정해야 했다. 나는 가능한 모든 멘토링을 나갔고, 그 와중에 사람들도 만나면서 주제도 고민하려니 정말 바쁘고 심한 스트레스를 받은 기간이었다. 예비과정 마지막에 기획평가가 있으니 이 시기에 기획서까지 완성해내야 한다. 눈코 뜰 새 없이 바빴던 기억밖에 없다. 다시 돌아가면 할 수 있을지 모르겠다 ㅋㅋ

팀원

첫 팀원은 다행히 OT에 가자마자 정할 수 있었다. Rust를 해본 경험을 흥미롭게 봐준 듯 했다. 또 다른 팀원은 멘토링 중에 만나게 되었다. 다들 착하고 열정적이었지만 처음 만난 팀원은 아무래도 스트레스가 심했는지 본과정이 시작하자마자 중도포기하게 되었다. 같이 해보고 싶었던 사람이라 아쉬웠다. 끝까지 같이 버텨준 다른 팀원은 힘들었을텐데 정말 고맙게 생각한다.

개인적으로 겹치지 않는 기술적 분야와 성실성, 그리고 활발한 소통 가능성을 기준으로 팀원을 만나는게 좋은 것 같다. 나와 내 팀원은 내가 백엔드, 팀원이 프론트엔드를 할 줄 알아서 서로의 영역을 존중하면서 자기 할 일을 열심히 할 수 있었던 것 같다. 또한 6개월 단기 프로젝트라고는 하지만 막상 착수하면 생각보다 높은 스트레스에 지속적으로 노출되고 그 와중에 한 번도 안해본 일들을 해야하기 때문에 잘 버티고 회복탄력성이 높은 사람일수록 유리한 것 같다. 아니면 본인이 그런 일들을 도맡아하고 팀원들을 개발에만 집중하게 하는 것도 좋은 방법 같다. 그리고 무엇보다 소통이 잘되는 팀원이 좋다. 정말 많은 결정을 내려야하고 과정 특성 상 결정자가 따로 없고 팀원들이 모두 동의해야 진행하는 경우가 많기 때문이다. 중요한 결정을 앞두고 연락이 안되거나 원활한 논의가 어렵다면 끝까지 가기 정말 힘들 것이다. 개인적으로 제일 중요하다고 생각한다.

멘토

멘토 선정도 굉장히 중요하다. 잘 맞는 멘토님을 만나면 정말 매주 뵙기도 하고 프로젝트 외적으로도 정말 많이 도와주신다. 하지만 반대로 멘토링 분야가 다르거나 잘 맞지 않는 멘토님을 만나면 딱히 멘토링할 만한 주제도 적고 불편해지기 마련이다.

다행히 우리 팀은 잘 맞는 멘토님만 만난 것 같다. 디자인패턴 스터디도 같이 진행했고 스프링이나 AWS에 관해서도, 취업에 관해서도 정말 많이 배울 수 있었다. 다만 초반에 이탈한 팀원이 적극적으로 요구한 멘토님의 경우 그 팀원이 없어서 그런지 많은 것을 부탁드리지 못해서 아쉬웠다.

사실 멘토님들이 많이 쓰는 기술 스택들은 거의 다 다룰 줄 아시기 때문에 게임엔진이나 모바일 네이티브 같은 특이한 스택이 아니면 어떤 멘토님을 선택해도 도움이 될 것이라 생각한다. 우리 팀은 내공도 있으시고 같이 이야기하기도 재미있는 멘토님들과 함께하게 되어 굉장히 유익하고 재밌게 마무리할 수 있었다.

인기있는 멘토님들은 맡을 팀을 선택하시기도 하기 때문에 마음에 드는 멘토님이 계시다면 괜히 뜸들이지 말고 빠르게 연락드리는게 좋은 것 같다.

본과정

기획

대망의 본 과정이 시작되었지만 다짜고짜 개발을 시작하지 않는게 좋다. 멘토님들도 말씀하시곤 하는데, 먼저 와이어프레임이나 화면기획서 정도는 완성시켜 놓고 개발에 들어가야 한다. 그렇지 않으면 나중에 개발을 중단하고 다시 화면이나 기능을 기획하는 상황이 발생하며 막상 그 상황에 들어가면 개발에 대한 부담 때문에 만족스러운 기획을 하기보다 보수적이고 소극적인 기획을 하게되어 결과물의 퀄리티를 낮추기 때문이다. 또 충분한 수준으로 초기 기획을 하지 않으면 나중에 다시하게 되어 일을 두 번하는 상황도 일어나곤 한다.

와이어프레임을 만들 기간이 6월 정도 밖에 없으니 그때 충분한 퀄리티로 만들어놓자. 디자이너 외주도 생각하고 있다면 더욱 깊은 수준으로 만들어 놓으면 좋다. 우리도 그렇게 해서 외주를 맡길 때 우리의 기획과 의도만 설명드리고 와이어프레임만 드려도 충분히 디자인 가이드가 나올 수 있었다. 작업 범위가 분명해지니 외주 협의도 단순해지고 서로 오해가 발생하지 않았다. 물론 결과물도 만족스러웠다. 우리 의도가 충분히 전달되었기 때문이다. 과한 기획보다 빠른 프로토타입이 좋다고들 하지만 어차피 한 달 정도면 과하긴 커녕 보통 수준의 기획도 하지 못하니 안심하고 기획에 집중하는게 좋다.

개발

기획과 인프라 작업에 한 달을 소비하고 나면 사실 상 개발할 시간이 7월부터 11월 전까지 네 달 밖에 없다. 11월 중순부터 최종 발표를 준비해야 하기 때문이다. 때문에 새로운 기술 스택을 시도하는 건 굉장히 위험할 수 있다. 우리 팀도 아이패드 네이티브 앱에 처음으로 도전했다가 도저히 못하겠어서 한 달 동안 한 프론트엔드 작업을 엎고 웹 앱으로 변경했다. 사실 상 한 사람 분의 맨먼스를 버린 셈이다. 결과물을 어느 정도 퀄리티로 빨리 내야하기 때문에 학습할 여유가 많지 않다. 시간을 갈아 넣을게 아니면 안전하게 하던 기술을 사용하자. 우리 팀 백엔드는 다행히 내가 써봤고 멘토님들도 많은 도움을 주실 수 있는 스프링 부트를 선택했기 때문에 그나마 퀄리티를 높일 수 있었던 것 같다.

이 때 사용하는 기술 스택을 나중에 바꾸기는 정말 어렵기 때문에 최대한 안전한 쪽으로 선택하는게 좋다. 아이패드 네이티브 앱을 개발할 때만해도 SwiftUI라는 최신 프레임워크를 썼는데, 이게 생각보다 stable하지 않아서 버그도 많고 도와주실 멘토님들도 별로 없었다. 조금만 오래된 iOS만 써도 돌아가지 않았다. 시간이 얼마 없는 만큼 실수할 여유가 별로 없으며, 따라서 오래되고 안전한 기술을 써야할 것이다.

스프링 백엔드를 이렇게까지 높은 완성도로 개발한 것은 처음이었다. 그 전까지 REST가 뭔지도 제대로 모르고 WAS를 만들어본 적도 제대로 없었다. 인터넷 강의를 보고 스프링으로 간단한 게시판만 따라 만들어본 수준이었다. 그래도 그나마 익숙한 프레임워크였고, 다른 기본기가 충실했기 때문에 충분히 좋은 품질로 진행상황을 따라갈 수 있었다. 그래도 처절하게 배웠던 것 같다.

멘토링

기술적인 도움을 주시는 멘토님이 계시다면 이 시기에 가장 많은 도움을 받을 수 있다. 나는 매주 멘토링마다 개발하면서 생긴 질문과 궁금한 점을 정리해갔다. 정말 열심히 준비해갔던 것 같다. 멘토링 내용도 모조리 정리했다. 내가 앞으로 나아갈 길을 먼저 걸어본 사람들의 지식과 생각을 얻을 수 있는 기회는 흔치 않으니 최대한 준비해서 많이 얻어갈 수 있었다.

나는 특히 언어나 자잘한 버그 같은 문제보다 AWS 인프라는 어떻게 구성해야 하는지, CI/CD 파이프라인은 어떻게 구축해야 안전한지, REST API는 어떻게 설계해야 하며 그 스키마는 어떻게 설계할 것인지와 같이 내가 알기 어려운 큰 그림의 문제들을 많이 여쭤봤던 것 같다. 이런 기술적인 측면 뿐만 아니라 프로젝트 관리의 측면에서도 많이 배웠다. 팀의 일정 관리는 어떻게 해야하며, 팀의 사기와 의욕은 어디서 오고, 목표는 어떤 수준으로 어떤 기간마다 달성하도록 해야하는지 배웠다. 특히 Jira를 관리하면서 PM에 대해 겉핡기라도 해볼 수 있었다.

Project Management

앞서 PM에 관해 배운 점을 짧게 설명했지만 생각보다 많은 통찰을 얻었다고 생각한다. 지금까지 조별과제 이상의 협업을 해본 적이 없었기 때문에 이렇게 본격적으로 장기간 동안 다양한 배경의 사람들과 같이 개발할 수 있다는 점이 많은 배움을 얻게 해준 것 같다.

특히 우리 팀은 중간에 고난이 많았다. 한 명은 나가고 다른 한 팀원도 높은 난이도의 기술 때문에 심한 스트레스를 받았다. 짧게나마 연락 두절 사태가 있기도 했다. 나도 여러 번 멘탈이 터질 위기가 있기도 했고 의욕을 잃어버리기도 했다.

처음부터 PM을 맡아주신 멘토님이 없었다면 나도 포기했을지도 모른다. 그 분이 가이드 해주시는 대로 Jira를 사용해 목표를 쪼개고, 예상하고, 달성하고, 기록하면서 많은 동력을 얻을 수 있었다. 작은 성공을 계속할 수 있으니 자기효능감이 낮아지지 않았던 것이다. 팀원과의 소통과 진척을 공유하기 위해 매일 슬랙으로 데일리 스탠드업을 진행했다. 굳이 따로 음성채팅을 하지 않더라도 봇을 연결해 매일 아침마다 채팅으로 봇과 대화하면서 기록하는 형식으로 진행했다. 스탠드업 내용은 정리되어 공유되었다. 지나치게 높은 기술적 난이도 때문에 고생하던 프론트엔드도 익숙한 웹 앱으로 과감히 틀었다. 프론트를 맡은 팀원이 부담이 줄어들어 굉장히 좋아했던 기억이 난다.

나도 그렇지만 팀의 사기를 위해서는 작은 성공들이 꾸준히 필요하고 긍정적인 사용자 피드백이 여기에 가장 좋지만, 그런게 없더라도 작은 목표를 지속적으로 성취해 나가면서 전체적인 진행을 돌아볼 수 있게 하는 시스템이 중요하다는 것을 배웠다. 팀 리더는 팀원들에게 작은 목표들을 설정할 수 있도록 유도하고 할당할 수 있어야 한다. 팀원은 진척을 끊임없이 공유하여 지금 막다른 길에 놓여있는지, 시간 낭비를 하고 있지는 않은지 알려야할 책임이 있다. 진척 공유는 또 다른 효과가 있는데, 남들과 비교하면서 긍정적인 자극을 얻을 수 있다. 남들과의 비교가 반드시 필요한 것은 아니고 가끔 파괴적이기도 하지만 진척이 빠른 상황에서는 뿌듯함을, 느린 상황에서는 위기감이라는 비교적 건전한 채찍을 줄 수 있다고 느꼈다. 상사로부터의 직접적인 타박보단, 본인 스스로 부족함을 느끼는 것이 더 나은 처벌 수단이지 않을까.

앞으로 어떤 팀원이 되어야겠다는 목표도 얻을 수 있었다. 먼저 성실한 팀원이 되어야 한다. 이런 짧은 프로젝트 기간 동안이라도 성실함은 끊임없이 시험받았다. 그리고 남들이 흔들리는 와중에 성실히 나아가는 팀원이 있다면 프로젝트의 중심을 잃지 않을 수 있다고 생각한다. 그리고 긍정적인 팀원이 되어야 한다. 달리는 열차에 탄 이상 목적지까지 가는 것은 내가 선택할 수 있는 일이 아니다. 부정적인 생각으로 열차를 멈추기보다 어떤 방향으로 어떤 속도로 가야 목적지에 안전하게 도착할 수 있는지 생각해야 한다. 소마 프로젝트에 참여한 이상 프로젝트 자체에 대한 의문보다는 현재 상황에서 프로젝트의 퀄리티를 높일 생각을 해야했다. 그리고 그런 현실적인 논의와 결정이 결국 프로젝트를 완성에 이르게 했다.

그리고 무엇보다 소통이 잘 되는 팀원이 되고 싶다. 이번 소마 프로젝트를 진행하면서 소통이 잘 되는 상황은 굉장히 기분 좋고 프로젝트에도 많은 도움이 되었다. 반대로 소통이 안되는 상황에서는 팀 전체의 사기도 떨어질 뿐만 아니라 프로젝트 자체도 의미를 상실한다. 결정은 미뤄지고 막다른 길에서 멈추는 것은 차선책으로 보이기까지 한다. 일을 잘하지 못해도 다른 팀원들에게 자기가 일을 잘하지 못한다는 사실만이라도 알린다면 더 잘하는 일을 맡거나 적어도 도움을 받을 수 있다. 소마를 마치며 가장 뼈아프게 배운 점이라 한다면 바로 이 커뮤니케이션의 중요성이라고 할 수 있겠다.

발표

소마를 하면서 총 세 번의 발표 자리가 있었다. 기획평가, 중간점검, 최종점검이다. 발표를 도맡아하며 내가 생각보다 발표를 꽤 잘하며 즐거워한다는 사실을 알았다. 아무래도 중고등학교를 다니며 토론 대회와 토론 동아리를 했던 경험이 많은 도움이 되었던 것 같다. 심사위원의 질문을 들으면서 그 의도와 내 답변을 준비하는 생각의 과정이 토론과 매우 유사했다.

게다가 단 한 장의 대본도 쓰지 않았음에도 세 발표 모두 높은 평가를 받으며 마무리할 수 있었다. 토론을 하며 즉흥적으로 반론하거나 반론에 대한 대응을 할 일이 정말 많았는데 그 경험이 이렇게 도움이 될 줄은 몰랐다.

물론 아직 보완할 점이 많다. 말버릇이나 제스쳐, 업무와 관련된 발표의 관행(PR과 IR의 차이와 같은) 등을 더 배우고 보완해야 하겠다. 그럼에도 앞으로 발표할 일이 있으면, 준비가 잘 되어 있다는 전제 아래에서 앞의 사람이 누구던 꽤나 즐겁게 발표할 수 있겠다는 자신감이 생겼다.

최종점검을 마치고

며칠 전에 마지막 최종점검 발표를 무사히 마쳤다. 좌충우돌 지나왔지만 결국 최종장에 오니 많은 감정이 든다.

배움

다른 것보다 더 넓고 깊은 시야를 얻을 수 있어서 좋았다. 소마를 하기 전에는 라이브러리를 만들거나 간단한 데이터 분석 백엔드 수준까지 만들 수 있었지만, 소마를 끝내고 나니 웹서비스의 인프라는 어떻게 설계해야 하며, 백엔드는 어떻게 구축해야 하는지, 그 사이사이 반드시 필요한 기능은 무엇이 있는지 알게 되었다. 심지어 서비스를 만들고 나서 어떻게 홍보해야 하고 사용자 데이터는 어떻게 분석해야 하는지까지 배웠다. 이제 나만의 서비스를 만든다해도 그 로드맵이 충분히 보인다.

앞으로 취준을 병행하면서 나만의 서비스도 만들어볼 예정이다. 게다가 난 홈서버가 있으니 여기에 개발서버와 운영서버를 나누어 두고 NAS에 서버 로그도 쌓아볼 생각이다. 기획부터 개발 이후에 홍보까지 어떻게 해야할지 감이 잡히니 이런 계획도 새울 수 있는 것 같다. 이런 시야가 생겼다는 점에서 정말 많은 성장을 했다고 생각한다.

마치며

처음 지원할 때는 제대로된 협업을 돈써보며 해보고 싶다는 마음이었지만, 다 끝나고 나니 협업 이상의 경험을 얻을 수 있었다. 프로젝트를 이끈 팀장으로서 많은 통찰과 넓은 시야를 얻게되어 정말 행복했던 한 해였다. 내년에 참여할 소마 후배들도 이런 알찬 경험을 하길 바라며 항상 응원한다.