Github으로 구직하기(과제 편)
#코딩 테스트 #과제 #Homework
코딩 테스트에는 두 가지 종류가 있다
하나는 알고리즘 문제풀이. 다른 하나는 요구사항을 개발하는 과제. 신입 개발자 채용의 경우 과제보다 알고리즘 테스트를 통해서 역량 평가를 주로 한다. 대기업 아이티 회사의 경우 신입 지원자들이 많기 때문에 비교적 짧은 시간에 평가가 가능한 알고리즘 테스트를 주로 활용한다. 코딩 테스트를 대신해주는 서비스 플랫폼들도 많아졌기 때문에 회사 입장에서 간편한 장점도 있다. 반면 개발 과제의 경우 애플리케이션의 구조, 코드 가독성, 요구사항 평가, 테스트 커버리지 등등 다소 시간을 들여 코드를 분석하고 평가해야 한다. 자동화된 도구를 통해서 일률적인 평가가 불가능하기 때문에 인력이 투입된다. 개발 과제가 주로 지원자 수가 적은 경력직들을 뽑을 때 많이 활용되는 이유이다.
이번 글에서 다룰 내용은 Github을 통해서 개발과제를 하는 방법이다. 서두에 개발 과제가 경력직 채용에 주로 활용된다고 했다. 하지만 개발 과제에 신입/경력 구분은 없다. 나의 경우 신입 채용 평가를 과제를 통해서 받았다. 알고리즘 테스트는 현장 면접 때 받았다.
개발 과제는 알고리즘 테스트와 달리 긴 시간을 제공받는다. 보통 1.5일 ~ 2일 내에 과제를 완료해서 제출하면 된다. 직장을 갖고 있는 경력자들은 보통 주말에 시간을 내서 해야 하기 때문에 더러 싫어하는 개발자도 있다. 나는 짧은 시간 안에 타임어택(Time Attack)해야 하는 알고리즘 테스트보다는 개발 과제를 선호하는 편이고 자신 있는 편이다(=개발 과제 평가에서 탈락해본 적 없다). 과제를 선호하는 이유는 다음과 같다.
1) 코드 작성법을 보여줄 수 있다.
2) 활용 가능한 개발 언어와 프레임워크, 기타 기술을 보여줄 수 있다.
3) 개발 실무 능력을 보여줄 수 있다(요구 사항 구현 및 테스트 작성법).
4) Github을 활용해서 형상관리 습관 및 협업하는 능력을 보여줄 수 있다.
정리하면 과제를 통해서 개발 실무 능력을 어필하기에 좋다.
Github을 통해 과제를 제출함으로써 4번 항목도 덤으로 어필할 수 있다. 회사는 결국 협업하고 싶은 개발자를 뽑고 싶다. (자매품: Github으로 협업하는 법) 개발 과제를 통해서 기능 구현 그 이상을 보여줘야 한다.
이 글에서 예시로 활용할 프로젝트는 아래 Github 링크를 참고 바란다. 개발 과제 샘플 프로젝트
링크로 이동해서 함께 보면서 얘기해보자. 참고로 위 프로젝트는 최근에 이직할 때 제출했던 과제이다(블라인드 글을 통해서 유추해보건대 탈락자가 적지 않았던 과제로 알고 있다). 100점짜리 과제인지 아닌지는 평가관만이 알 수 있고 시각에 따라 다양하게 해석될 수 있으니 정답표라고 생각하진 말자.
이 글은 참고로 코드 작성법과 기술 구현법에 대해서 다루지 않는다. Github을 활용해서 과제 결과물을 어떤 식으로 구성하고 제출할지에 대해서 다룰 예정이다.
1. Github에 Repository를 만들자.
과제 제출이 자율인 곳들도 있지만 Github에 프로젝트를 올려서 제출하자.
혹시 Github을 아직 접해보지 않았다면 이번 기회에! (참고: Github을 사용해보자)
왜 굳이 Github에 올려서 제출해야 하냐고? 개발자에게 프로젝트 형상 관리는 기본이다.
2. 요구사항 및 채용 포지션에 부합하는 언어, 프레임워크, 빌드 도구 등을 활용해서 프로젝트를 셋업 하자.
과제의 요구사항을 꼼꼼히 읽어보자. 어떤 언어와 프레임워크 또는 도구를 사용해서 개발을 하라고 명시돼있을 것이다. 자유롭게 구현하라고 한다면 채용공고에 명시된 요구 기술이나 도구를 최대한 활용해서 프로젝트를 셋업 하자. 본인의 경우 Java, SpringFramework를 활용하는 백앤드 개발자 채용의 과제였다. 최신 버전의 스프링 프레임워크와 Java를 활용해 프로젝트를 셋업하고 빌드 도구는 Java 개발에서 많이 사용하는 Maven을 선택했다.
프로젝트를 셋업 할 때 주의할 점
(1) 가급적 최신 버전을 사용할 것
최신 버전의 언어와 프레임워크 사용을 통해서 최근 프로그래밍 동향과 개발을 파악하고 있음을 간접적으로 어필할 수 있다. 물론 최신 버전을 추가만 해놓고 그에 걸맞은 코드를 보여주지 못한다면 소용없는 일이다. 최신 버전에 포함된 기능과 프로그래밍 모델을 이해하고 사용하자. 나에 경우 reactive programming 모델의 reactor api가 포함된 spring-boot 버전을 사용하여 해당 api 대한 이해와 숙련도를 증명하려 했다.
(2) 불필요한 라이브러리나 파일을 포함하지 말 것 (feat: .gitignore)
불필요한 파일은 프로젝트를 지저분하게 만들어 관리도 어렵지만 필요한 것만 봐야 하는 평가자를 불편하게 만든다. 불필요한 파일을 프로젝트에 포함해놓은 것은 바람직한 관리법이 아니다.
.gitignore에 명시된 파일 또는 폴더는 git repository에서 tracking 되지 않는다. 따라서 Github Repository에 올라가지 않는다.
(3) 프로젝트의 구조(파일과 디렉터리 구성)를 정리하자
파일의 위치와 폴더(패키지) 구성의 이유를 설명할 수 있어야 한다. 나의 경우 maven 프로젝트의 기본구조 src/main/java, src/test/java 구조를 따랐다. package는 단순한 구조의 Controller-Service-Repository에 맞춰 구성했다. 나를 따라 프로젝트를 구성하라는 얘기가 아니다. 프로젝트를 다음과 같이 구성한 이유를 질문한다면 다음과 같이 얘기할 이유가 있어야 한다는 걸 강조하고 싶을 뿐이다.
4. 채용 자격조건에 명시된 기술이나 역량을 보여주자
예를 들어 요구하는 자격에 'Reative API를 이해하고 사용할 수 있는 자'가 명시돼있다면 reative api 프로그래밍 모델을 사용하여 코드를 작성해야 한다. 'Functional 프로그래밍 유경험자'가 명시돼있다면 Fuctional Programming을 코드를 통해 보여줘야 한다. 'Rest API를 이해하고 설계 가능한 자'라면 REST 아키텍처에 맞춰 API를 개발해야 한다. 채용담당자는 과제를 통해 뽑고자 하는 포지션의 기술 역량을 갖고 있는지를 보고 싶을 뿐이다.
5. Git과 Github을 제대로 사용하자
단순히 파일 공유용으로 Github을 사용할 거라면 그냥 파일 압축해서 메일로 보내는 거랑 다를 바가 없다. 홀로 작업하는 과제일지라도 브랜치를 분기하여 작업하는 것을 추천한다. 일정한 단위로 변경 내용을 커밋하여 기록하자. 커밋 메시지도 자세하게 작성하자. (참고: 브랜치 사용법)
그리고 PR도 작성하자.(참고: PR 작성법) 이건 좀 과한 거 아니냐고? 그럴 수도 있다. 하지만 Github을 굳이 사용하는 이유는 git과 Github을 사용해서 코드 협업을 어떻게 하는지 보여주기 위해서다. 코드를 작성하는 것만큼 관리하는 것도 매우 중요한 능력이다. 버전 관리도 못하고 커밋 메시지도 제대로 작성하지 못하는 개발자와 누가 같이 협업을 하고 싶겠는가.
6. 복잡한 디자인 패턴은 피하고 가급적 단순하게
디자인 패턴 책에서 배운 수준 높은 패턴의 코드를 보여주고 싶은 욕심이 있을 수 있다. 대부분의 개발과제의 요구사항은 단순하고 작다. 요구사항에 맞는 프로그램을 짜는 안목도 필요하다. 평가관들이 파악하기 쉬운 코드일수록 좋은 인상을 남길 수 있지 않을까? 평가관들의 인내와 시간은 많지 않을지도 모른다.
7. 테스트는 어떤 방식으로든 반드시 작성하자.
과제에서 명시한 요구사항에 맞춰 테스트 케이스를 정해서 작성하자. 테스트 코드를 통해 1차적으로 기능 검증을 할 수 있다는 것은 누구나 알 것이다. 하지만 이건 실제 개발이라기보다는 평가를 위한 과제를 위한 테스트 작성이다. 최소한 과제에 명시된 요구사항을 검증하는 부분을 검증하는 테스트만큼은 반드시 작성하자. 과제 제출 전에 검토용으로도 반드시 필요하고 평가관 입장에서 테스트 코드를 돌려봄으로써 요구사항 충족 여부를 판단하는데 도움이 된다. 성공/실패 케이스 모두 고려하여 테스트 코드를 작성하는 것을 추천한다. 테스트가 쉬워 보이지만 테스트를 작성하면서 개발하는 개발자가 생각보다 많지 않다. 평가자가 테스트 코드를 먼저 찾아 볼지도 모른다. (참고: 테스트 코드 예제)
8. 프로젝트에 대한 소개글을 Readme.md에 작성하자
Readme.md는 프로젝트의 간판과 같다. 프로젝트 구조, 애플리케이션 실행법과 테스트 방법이 readme.md에 설명이 돼있으면 프로젝트를 방문한 사람(평가관)의 입장에서 큰 도움이 된다. 잘 관리된 프로젝트는 readme.md도 사용자 친화적으로 잘 작성이 돼있다. 코드 작성뿐만 아니라 개발 문서 작성 능력도 매우 중요하다. Readme.md 작성을 통해 자신의 프로젝트(과제)를 장점을 어필하고 공유 능력도 보여주자. 가능하다면 영어로 작성하는 것을 추천한다.
9. 애플리케이션 Runbook을 작성하자
Runbook(작동설명서)을 통해 애플리케이션을 어떻게 설치/실행하고 테스트 하는지 알려주자. Runbook은 사용자를 위한 사용설명서이다. 사용자 친화적인 프로그램 개발과 문서화는 엔지니어의 중요한 덕목이다. 실행하기 어렵고 복잡하다면 좋은 인상을 받기 어려울 것이다.
평가관이 한 줄의 명령어로 프로그램을 실행할 수 있다면 베스트다. 실행에 필요한 복잡한 스크립트를 함수로 정의해둔 Makefile을 만들어두었다. 이를 통해서 나는 스크립트 작성 능력과 자동화 능력을 보여주고 싶었다.
마무리
음흉하게 과제를 통해 뻔지르르하게 보이는 방법을 소개해준 거라고 생각할지도 모르겠다. 하지만 위에서 설명한 과제 노하우들은 결국 실무에서도 똑같이 하는 개발 업무들이다. 실제 개발 업무에 꼭 행해지는 절차들을 과제를 통해서도 보여준다면 실무 능력까지 보여줄 수 있을 거라고 생각한다. 개발자는 코딩만 하는 게 개발자가 아니다. 개발자는 개발의 전 과정에 참여하는 직업이다. 포괄적인 관점에서 개발을 바라보자.
다시 한번 강조하지만 내가 소개한 방법은 나만의 방법이고 노하우이다. 내가 예시로 제시한 과제도 정답이 아닐 수도 있다. 그럼에도 불구하고 어디 가서 책잡히는 프로젝트는 아닐 거라는 확신은 있다.
더 좋은 방법이 있거나 프로젝트에 대한 리뷰를 받고 싶은 사람이 있다면 댓글로 Github 링크를 남겨주길 바란다. 함께 공유해보자.
