우테코 백엔드 5기에 지원하여 현재 프리코스를 진행 중이다. 금일 자정에 제출 마감하는 1주차 과제를 진행하며 느낀 점에 대해서 작성하려 한다.
지원 동기
프리코스 1주차 회고에 앞서, 지원 동기에 대해서 곱씹어보았다. 나는 2가지의 큰 목적을 가지고 지원했던 것 같다. 성장과, 도전, 내 자신을 평가하고 싶은 마음이다.
대부분의 지원자는 우테코에 지원하여 합격하고, 과정을 수료하는 과정에서 경험하게 될 개발자로서의 성장을 목표로 지원할 것이라고 생각하고, 나 역시 그러한 목표를 가지고 지원했다.
성장하고 싶은 마음에 더해, 내 자신을 평가하고 싶은 마음도 있었다. 도전이라고도 할 수 있겠다! 휴학을 결심한 뒤로 나름대로 열심히 공부하며 공부 시간만큼은 전보다 많이 늘었고, 여러 부트캠프/동아리에 지원해보며 자소서 작성 능력(나를 어필하는 능력?)도 전보다는 나아졌다고 생각하는데 과연 우테코에도 열정을 가지고 지원하면 합격할 수 있을까? 라는 생각이 들었다.
나는 우테코 4기에도 지원했는데, 그때는 실력이 안 좋을 뿐 아니라 개발 공부에 전혀 열정을 가지고 있지 않았을 때라서 1차 코테에서 광탈했다. 내 나름대로 열심히 공부하고 있다고 느끼는 지금, 나는 우테코가 원하는 인재상에 해당되는 사람인지 알고 싶어졌다.
물론 우테코에 붙고 싶은 마음은 여느 지원자만큼 크고, 내가 실력이 좋다고 생각하며 오만함에 빠져 우테코 선발 과정을 테스트해보겠다거나 하는 마음은 전혀 없다. 비전공자도 뽑는 과정이니만큼, 실력보다도 내가 합격할 수 있을만큼의 열정을 불태울 수 있는가에 대한 도전인 것이다.
1주차 과제
1주차 과제를 진행하며 느낀 점
문제 난이도
문제 유형은 코딩테스트와 유사했고, 총 7문제를 풀어야 했다.
내가 PS에 능한 것은 아니라서 문제 난이도를 논하는 것이 부끄럽지만, 특정 알고리즘을 구현해야 한다거나 하는 문제는 없었고 자바로 코드를 짜본 사람이라면 문제 난이도 자체는 그렇게 어렵지 않게 느껴졌을 것이라고 생각한다.
제일 어려운 문제가 백준 solved.ac 기준 실버3,4쯤이지 않을까 싶다.
과제를 진행하며 신경 쓴 부분
변수명, 메서드명 작명
개발자의 크고 어려운 업무 중 하나가 변수 이름 짓기라는 농담을 들은 적이 있다. 근데 농담이 아니었다는 것을 과제를 진행하며 깨달았다.
나는 다른 누군가가 내 코드를 볼 일이 별로 없었기 때문에, 가독성이 좋은 코드, 클린 코드를 작성해야겠다는 생각을 하지 않고 코드를 작성해왔다. (int는 무조건 num이지 ㅋㅋ)
하지만, 우아한형제들이 코드의 가독성을 중요시한다는 것을 알게 되니 평소 내가 짜던 코드대로 작성할 수가 없었다.
변수,메서드 네이밍 컨벤션을 열심히 찾아가며 변수명,메서드명만 보고도 어떤 의미를 가지는지 짐작이나마 할 수 있도록 작성했다. 이것도 역시 내 기준이기 때문에 남이 본다면 어떨지 모르겠다..
이렇게 고민해가며 네이밍을 하며 느낀 점은
1. 창작의 고통
2. 변수명, 메서드명이 너무 길어진다
그 예시로, 비슷한 닉네임을 가진 크루의 이메일을 찾는 함수를 만들었는데.. 함수명이 findSimilarNicknameCrewEmail이었다. 어떤 의미를 가지는 메서드인지 설명할 수 있는 이름을 짓다보니 길이가 너무 길지는 않은가 싶고, 지금 봐도 괜찮게 작명한 건지 모르겠다.
기능 목록 작성, 기능 단위 커밋
과제 명세서에 기능 목록을 만들고, 기능 단위로 커밋하라는 내용이 있었다.
협업 경험이 적은 나는 그 적은 협업 경험 속에서도 기능 단위로 커밋한 경험이 없었기에 신경을 쓰며 진행해야 됐다.
사실 이 명세는 사람마다 해석이 나뉘는듯 했다.
슬랙의 커뮤니티를 참고했을 때, 1주차 과제의 경우 7개의 문제를 풀어서 제출하는 것이기 때문에 한 문제를 하나의 기능으로 보고 총 7번의 커밋만 하면 된다는 해석, 하나의 문제 속에서 구현할 기능을 각각 커밋해야 되기 때문에 7번 이상의 커밋을 해야 된다는 해석으로 나뉘었다.
나는 처음에 전자의 입장이었지만, 후자의 얘기를 들으면서 각각의 기능 별로 커밋을 하는 열정을 보여서 나쁠 것 없다는 생각에 후자를 택했다.
모듈화
변수,메서드명 작명과 같은 맥락으로 클린 코드를 작성하기 위해 모듈화에도 신경썼다.
변수명 작명, 기능 단위 커밋과 비교했을 때 모듈화는 그나마 신경을 덜 써도 됐다. 왜냐하면, 기능 목록을 작성하고 보니 그 기능대로 모듈을 만들면 됐기 때문이다.
이것이 우테코가 의도한 바가 아닐까 생각했다. 기능 목록을 만들어 놓고 보니, 기능 별로 구현을 하게 되고 자연스럽게 모듈화를 하게 되는 것 말이다.
그 외
채점을 이렇게 할 수 있다고?..
1주차 과제를 끝내고 제출하며 신기하다고 느낀 부분이 있다.
과제 제출은 과제를 완료한 뒤에 내 github repository에서 우테코의 repository에 Pull Request를 하고, 웹사이트를 통해 다시 한 번 제출해야 하는 구조다.
근데 !!
웹 사이트를 통해 과제를 제출할 때, Pull Request 주소를 첨부하면 자동으로 코드를 실행하여 테스트를 진행한다.
나는 이게 신기했다. 코드를 따로 제출해야 되는 건가 하고 들어갔는데 Pull Request 주소만 제출하면 알아서 코드를 실행한다는 것이 신기했다. 다른 사람에겐 별 거 아닐 수 있지만, 나에게는 이러한 디테일이 '역시 우테코인가..'라고 생각하게 만들었다.
전반적인 느낌
우테코는 프리코스만으로도 얻어갈 것이 많고 도움된다는 얘기를 들은 적이 있다. 프리코스를 진행하기 전까지는 체감하지 못 하고 있었는데, 참여해보니 왜인지 알 것 같다.
클린 코드를 지향한다는 점에서 가장 크게 느꼈다. 나처럼 협업의 경험이 적고, 프로그래밍 학습 이력이 그렇게 길지 않으며 남이 보지 않는 코드만 작성하는 사람들은 클린 코드를 의식하며 코딩할 일이 많지 않다고 생각한다.
그런 사람들도 우테코가 지향하는 바를 알고 있고, 우테코에 열정을 가지고 있다면 가독성 좋은 코드를 짜기 위해 노력할 수 밖에 없다.
나는 하나의 문제를 풀면서, 문제를 어떻게 풀어나가야 좋을지에 대한 고민은 한 적이 많았지만 변수명, 메서드명을 어떻게 의미 있게 작명할지와 가독성 좋은 코드를 짤지에 대한 고민은 한 적이 없었다. 이렇게 신경 쓰지 않았던 부분에 대해서 일깨워준 것만으로도 내 부족함을 깨닫는 좋은 경험을 했다고 생각한다.
고작 1주차 진행하면서도 이렇게 느낀 점이 많으니, 남은 3주도 열심히 참여하여 비록 합격하지 않더라도 많은 것을 얻어갈 수 있도록 해야겠다.
