본문 바로가기
개발 - Coding/문돌이 출신 개발자 생존가이드

[SOMA] 소프트웨어마에스트로 13기 수료 후기

by dev_jinyeong 2022. 12. 10.

지원과정

서류 ➡️ 1차 코딩테스트 ➡️ 2차 코딩테스트 ➡️ 면접 ➡️ 최종합격

서류

서류의 경우 합격에 크게 영향주는 요소인 것 같지는 않습니다. 지금 돌아보면 정말 말도 안되는 내용이나 이상한 내용이 많았는데, 지원할 당시에 너무 정신이 없었다보니 솔직히 많이 신경쓰지 못했습니다. 그렇지만 면접관 분들도 많은 지원자들을 심사하다 보니 서류 내용을 꼼꼼하게 신경쓰지 않으셨고 면접볼 때 "제가 자기소개서에도 썼듯이" 같이 말했을 때 아무도 모르셨고 그제서야 서류를 보는 눈치셨습니다. 그렇기 때문에 서류의 경우에는 뭔가를 너무 꾸미려고 하지 말고 지원할 때 현재 자신이 어떤 경험을 했고, 어떤 역량이 있는지 솔직하게 적는 게 좋을 것 같습니다. 오히려 너무 거창하게 쓰려다가 면접에서 역풍을 맞는 경우가 꽤나 있는 듯 합니다.

1차 코딩테스트

1차 코딩테스트의 경우 매우 쉬운 편이었습니다. 오랜 시간이 지나 정확히 기억하지는 못하는데 알고리즘 문제가 3~4개 출제되고 SQL 문제가 하나, 웹 프로그래밍(HTML, CSS, JS) 문제가 하나 출제되었던 걸로 기억합니다. 문제 난이도는 어렵지 않은 편이고 보통 자료형 다루는 구현 문제들이 나옵니다. 어려운 알고리즘을 공부하기보다는 기본적인 코딩 능력을 기르는 것이 더 중요하다고 생각합니다.

2차 코딩테스트

2차 코딩테스트의 경우 쉬운 편이었습니다. 이것도 정확히 기억하지는 못하는데 1차와 구성 자체는 비슷했던 것으로 기억합니다. 다만 구현이 까다로운 문제들이 좀 있었습니다. 특정 알고리즘을 모르면 풀 수 없는 종류의 문제는 출제하지 않는 것 같습니다. 저는 다 풀었는데 다른 분들은 1~1.5문제 정도를 풀고도 합격하신 분들이 있었습니다. 사실 인터넷에서 열심히 찾아보셨다면 아시겠지만 SW마에스트로 코딩테스트의 경우 합격 커트라인이 낮은 편이라고 합니다. 실제로도 다른 분들과 이야기했을 때 문제를 잘 풀지 못했지만 합격하신 분들이 꽤 있었습니다. 문제가 어렵게 느껴지시더라도 포기하지 말고 최대한 많이 풀어보려는 것이 중요할 것 같습니다.

코딩테스트에 관련해서 조금 더 첨언하자면 Python3를 이용할 수 있는데 시간복잡도 기준이 높은 문제는 잘 출제되지 않는 것 같아 로직 구현이 빠르고 기본 모듈에서 다양한 기능을 제공하는 Python을 추천드립니다. 시간이 부족할 것 같아도 dictionary를 이용하는 선에서 해결되는 문제가 꽤 많았습니다.

면접

면접은 기본적으로 대면으로 이루어졌는데 저는 면접 기간에 코로나에 확진되어버려서 비대면으로 면접을 봤습니다. Webex를 이용해서 면접했는데 다른 비대면 면접과 크게 다를 것은 없는 것 같습니다. SW 전문가가 되기 위해서 어떤 식으로 노력하는지, 팀원들과 불화가 생긴다면 어떻게 할 것인지, CS 관련한 지식 확인 등을 질문받았고 면접관들이 질문하는 내용에서 특별히 난해하다거나 곤란한 질문은 없었습니다. 기본적으로 태도가 나이스하시고 면접자가 말하려는 바를 최대한 잘 들어주고 좋게 해석해주려고 노력하시는 느낌을 받았습니다. 나중에 생각해보면 멘토님들이 면접 보시는건데, 멘토님들은 기본적으로 연수생들이 예의를 지키는 한 매우 친절하고 가르치려는 의지가 강하신 분들이십니다. 그러므로 긴장하지 말고 차분하게 하고 싶은 이야기를 하는 게 제일 좋을 것 같습니다.

다만 자신의 역량을 지나치게 포장한다고 느끼시는 경우에는 날카롭게 파고드시는 것 같다는 느낌을 받았습니다. 반대로 프로젝트의 퀄리티나 기술 스택 등 기술적으로 쉽다고 느껴지는 부분에 대해서는 크게 신경쓰시지 않는 것 같았습니다. 전반적으로 이 사람이 어떤 노력을 얼마나 열심히 했고, 정말 그 사람이 한 것인지에 더 중점을 두시는 것 같았습니다. 그렇기 때문에 내가 잘 모르지만 피상적으로만 이용해본 기술이나 프레임워크 등을 작성하는 것은 지양하는 것이 좋다고 생각합니다.

자유멘토링 및 팀 빌딩

합격하고 나면 예비 과정을 하게 되는데, 이 과정에서 멘토님들의 멘토링도 듣고 미니프로젝트도 하고, 팀 빌딩도 해야 하는 등 매우 바쁩니다. 자유멘토링은 하나는 의무적으로 들어야 해서 다들 몰려서 신청하는데, 수강신청마냥 사람들이 순식간에 신청해서 진짜 듣고싶은 건 듣기 어렵고 저는 대충 아무거나 신청해서 의무를 다했습니다. 진짜 듣고 싶은 멘토링은 나중에 열리는 걸 신청하는 게 좋고, 너무 간절한데 안열리는 경우에는 멘토님께 가서 간청하면 들어주시는 경우가 많았습니다. 그렇기 때문에 멘토링에 집착하기보단 멘토님께 집착하는 걸 추천드립니다. 어차피 지식의 원천은 멘토님이고, 붙어서 이것저것 물어보고 도움을 요청하다 보면 기본적으로 연수생을 좋아해주시는 분들이기 때문에 다 알려주십니다. 담당 멘토님이 아니어도 도와달라고 요청하면 거의 도와주시는 것 같습니다.

 

미니 프로젝트는 이번 기수에서 시험적으로 도입된거라고 하고, 특별한 감상은 없었기에 스킵하겠습니다.

 

소마 팀빌딩은 기본적으로 자율입니다. 직접 팀을 하고 싶은 사람을 찾아서 연락하고 팀을 만들고 담당 멘토님도 우리 팀을 담당해달라 연락해서 구해야 합니다. 그렇기 때문에 센터에도 열심히 나가고, 연수생들에게 열심히 연락을 돌려보는 게 좋습니다. 저는 학기중이어서 센터에 나가진 못했고 대신 이메일과 문자, 전화를 많이 했습니다. 그러다보면 맘에 드는 분들을 만나기 마련인 것 같습니다.

저는 제게 연락주신 분 중 마음에 맞는 분이 있어서 같이 팀을 구성했고 결과적으로 팀이 깨지지 않고 프로젝트를 잘 완수할 수 있었습니다. 팀을 만들 때 비슷한 조건인 분들과 팀을 만드는 것이 좋다고 생각합니다. 저 같은 경우 소마 초기엔 학기를 이수해야 하는 분, 소마 본과정 시작 이후에는 소마에 집중할 수 있는 분, 소마 이후에는 취업을 목표로 하는 분을 찾았습니다. 애초에 팀의 분위기 자체를 세팅하고 가야 싸우는 일이 없이 즐겁게 개발할 수 있는 것 같습니다. 주변에는 팀이 분해되기도 하더라구요. 그렇지만 분해되도 잘 개발들 하시기 때문에 너무 걱정할 필요는 없는 것 같습니다. 부부도 40%는 이혼한다고 하잖아요.

포지션에 관하여

SW마에스트로 전반적으로 프론트엔드 자원이 없는 편입니다. 멘토님 중에서도 프론트엔드 관련한 멘토님은 1분 정도인 걸로 알고 있습니다. 특히 앱 프론트엔드를 꿈꾸고 소마에 온다면, 당신은 모든 정보를 자발적으로 찾고 연수생들과 머리를 맞대야 합니다. 그렇지만 그것도 순탄치 않을게 뻔합니다. 백엔드, 데이터 쪽 연수생들은 현직 멘토님들한테 지식을 흡수하고 편하게 답을 찾아서 개발하는데, 웹/앱 프론트엔드 연수생들은 자기들끼리 열심히 답을 찾아 나설수밖에 없습니다. 같은 팀 프론트엔드 담당 연수생 이야기를 들어보면 멘토님 도움을 많이 못 받는게 너무 어렵고 서럽다고 합니다.

 

혹시라도 13기 이야기니까 14기는 그렇지 않을 수도 있다고 생각하신다면, 그 희망은 여기서 버리는 게 좋겠습니다.

왜냐면 멘토님들은 2년 주기로 선발되기 때문입니다.

 

현재 프론트엔드 멘토님은 부족한 상태고 사실 프론트엔드 연수생들도 적은 상태입니다. 그렇기 때문에 프론트엔드 연수생들은 어딜 가든 귀한 존재들입니다. 프론트엔드 연수생 앞에서는 처신을 잘 하는 편이 좋겠습니다.

 

프론트엔드 중에서도 스택을 잘 정하는 편이 좋겠습니다. 프론트엔드도 웹, 웹앱, 네이티브 앱, 크로스 플랫폼 등 다양한 분야가 있습니다만, 최대한 자료가 많고 다른 연수생들도 선택하는 분야로 정하는 것이 유리하다고 생각합니다.

 

저희는 Flutter로 프로젝트를 진행했는데, 자료도 부족하고 성능도 떨어지고 멘토님도 잘 도와주지 못해서 저희끼리 노력하는 수밖에 없었습니다. 물론 그 과정에서도 배우는 게 있습니다. 그러나 다른 웹, 웹앱, 네이티브 앱을 선택해도 배우는 게 많다는 걸 명심하십시오.

 

만약 당신이 백엔드, 데이터 쪽 연수생이라면 소마는 쉽게 많은 것들을 배우고 얻어갈 수 있는 곳입니다. 그렇지만 그만큼 쉽게 대체될 수 있다는 것도 기억하는 것이 좋겠습니다. 경험상 백엔드, 데이터 쪽 연수생들이 정말 많았고 또 둘 다 할 줄 아는 사람도 많기 때문입니다.

 

그렇지만 백엔드, 데이터는 언제든지 인력이 부족한 분야이기 때문에 너무 걱정하지 말고 즐겁게 코딩하시면 되겠습니다.

백엔드, 데이터 쪽 연수생이라면 Spring, Node.js, 머신러닝 프레임워크 등을 학습하는 것은 기본이고, 클라우드 관련해서 이러한 서비스를 어떻게 운영하고 배포할 것인지 고민해보고 소마에 지원하는 것이 좋다고 생각합니다. 소마에서는 AWS를 이용하는 데 프로젝트 지원비를 사용할 수 있고, 다른 클라우드 플랫폼은 지원하지 않습니다. Azure인지, AWS인지가 중요한 게 아니고, 서버 운영을 하는 데 있어서 AWS라는 선택지만 있는 것이 문제입니다. 클라우드 환경에서 배포해본 적이 없다면 관련해서 공부하고 준비해보는 게 좋습니다. 막상 프로젝트 시작해서 배우면서 구현하려고 하면 무조건 일정이 밀리기 때문입니다.

 

물론 연수생 입장에서 프로젝트를 하면서 일정이 마음대로 안되고 밀리는 건 특별할 것도 없는 일입니다만 오버헤드를 줄일 수 있다면 줄이는 게 좋겠죠.

소마의 장점들

소마 장점은 역시 돈을 많이 준다는 것 같습니다. 장학금이나 개인 물품 구매하는 것도 좋지만 프로젝트 비용을 720만원 주는데, 돈을 써가면서 클라우드 환경에서 서비스 배포해보는 경험은 정말 좋은 것 같습니다. 프로젝트 비용은 UI 디자인에도 사용할 수 있기 때문에 아주 유용합니다. 돈을 써가면서 개발할 수 있다는 건 아주 짜릿하고 즐거운 일입니다.

 

현업에서 일하고 계시는 분들이 멘토로 도와주는 것도 아주 큰 장점입니다. 현업에서 일이 어떻게 이루어지는지, 기술적으로 어떤 스택이 유용한지, 프로젝트 중 생기는 고민들에 대한 좋은 해답은 무엇일지 다 알려주십니다. 멘토링 하면 밥도 많이 사주시고, 프로젝트 하면서 고민이 되는 사항이 있을 때(사적인 고민 포함) 많이 들어주시는 편입니다.

 

마지막으로 나와 다른 기술 스택을 가진 연수생과 협업해보는 기회를 얻을 수 있습니다. 아무래도 학생 입장에서 프로젝트를 진행하다 보면 분야별로 연수생을 모아서 진행하기보단 자기 분야에 국한된 토이프로젝트를 하고 끝나기 마련입니다. 그렇지만 팀 단위로 일하다보면 생각보다 아름다운 결과물이 나옵니다. 물론 그 과정에서 힘든 일이 넘쳐나긴 하지만, 인생이란 원래 힘들기 마련이니까요.

개발 스택 선택

저희 팀 스택은 다음과 같습니다.

 

웹 프레임워크: Spring Boot(JPA/Hibernate), FastAPI

DBMS: MySQL, MongoDB

앱 프레임워크: Flutter

그 외: AWS Lambda, AWS IoT Core

 

저는 백엔드 담당이었기 때문에 백엔드 기준으로 말하자면, 스프링을 선택한 이유는 대기업에서 많이 뽑아서입니다.

비단 저희 팀 뿐만 아니라 많은 팀에서 스프링으로 백엔드를 구현합니다. 그리고 이유도 동일합니다.

그렇지만 만약에 당신이 스프링을 잘 모른다면, 잘 아는 프레임워크를 선택하거나 구현이 쉬운 프레임워크를 선택하십시오

스프링은 무거운 프레임워크기 때문입니다. 러닝커브가 높기 때문에 자칫하면 팀의 걸림돌이 될 수 있습니다.

 

저는 스프링에 대한 배경지식 없이 선택했기 때문에 실제로 프로젝트 전체가 1달 정도 밀리게 하는 죄를 저질렀습니다.

그리고 그 죄는 나머지 기능을 빠르게 구현하는 것으로 갚을 수 밖에 없었습니다.

 

만약에 당신이 백엔드 연수생이고 스프링을 잘 모른다면, Node.js나 FastAPI 같은 쉽고 가벼운 프레임워크를 선택하십시오.

어차피 모든 백엔드의 길은 연결되기 마련입니다.

 

디테일의 차이는 좀 있을 수 있지만 결국 모든 프레임워크는 비슷한 부분이 생기기 마련입니다.

잘 기억은 안 나지만 톨스토이는 모든 불행한 가정은 서로 다른 이유로 불행하지만 모든 행복한 가정은 비슷한 이유로 행복하다고 말한 적 있는 것 같습니다.

결국 좋은 백엔드라는 건 비슷한 모습을 취하기 마련입니다.

Node.js가 너무 가벼워서 Nest.js가 나오는 걸 보십시오. 결국 비슷한 길을 걸을 수 밖에 없는 것입니다.

 

그러면 방금 말한 것들을 근거로 Spring 해도 되는 것 아닌가?

 

물론 그렇습니다만, 소마 특성을 고려해야 합니다. 소마에서 가장 중요한 것은 작동하는 MVP를 만들고 여기서 꾸준히 업데이트하는 게 중요합니다. 뒷단이 어떻게 작동하는지는 중요하지 않습니다. 심지어 Firebase로 구현해도 상관은 없습니다.

빠르게 만들고 업데이트할 수 있어야 하기 때문에 대규모 처리를 염두에 둔 Spring은 빠르게 만들기에는 좀 무겁습니다.

 

Spring도 물론 익숙하다면 빠르게 만들 수 있습니다만, Spring 숙련자면 이런 글을 보고 흔들리지 않을거니까 저도 열심히 조언해보겠습니다.

 

Spring 모르면 Spring 하지 마. 그냥 하지마.

결론

소마는 너무 유익하고 즐겁습니다. 열심히 노력하고 노력한 걸 잘 어필한다면, 선발될 확률이 높은 것 같습니다.

얻어가는 것도 많고, 소중한 인연을 얻기도 합니다.

그러나 주의할 점이 있습니다.

 

다음을 꼭 명심하도록 하세요.

 

1. 프론트엔드 개발자라면 Flutter를 멀리하십시오.

2. 웹, 웹앱, 네이티브 앱을 미워하지 말고 크로스 플랫폼을 미워하십시오.

3. 클라우드 인프라에 대해서 공부하십시오.

4. 스프링을 미리 공부하든가, 스프링을 멀리하십시오.

 

감사합니다.