개발 과제를 준비하는 팁 10가지

Richard

6 min readJul 8, 2019

개발 과제도 대상과 목적이 있습니다. 모든게 그렇듯이.

주1. 낮은 경력의 개발자 또는 SI/에이전시 개발자에게 코칭한 내용이고, 많은 개발자들이 선망하는 회사의 코딩 과제를 통과했습니다. 물론 실행은 각자 몫이죠.

주2. 아래 내용은 서비스 개발자의 경우에 관한 내용이지만, 다른 개발자 또는 기획자/디자이너라고 핵심과 맥락은 다르지 않습니다.

서문

좋은 개발자를 채용하기 위해 온라인 코딩테스트도 하지만, 개발 과제도 요구하는 회사들이 있습니다. 뿐만 아니라, 개발자의 포트폴리오 또는 자기계발을 위해 개인 프로젝트를 준비하는 사람도 있습니다.

개발 과제는 왜 할까요? 무엇을 보려고.

개발 과제는 해당 포지션에 필요한 기본적인 역량과 좋은 태도를 가지고 있는지를 봅니다.

만약 간단한 서비스를 만드는 과제를 냈다면, 서비스를 만들어서 실행이 잘 되는 것만을 확인하기 위해서 개발 과제를 요구하지 않습니다. 개발할 때 무엇을 고려하고, 협업을 어떻게 하며, 어떤 코딩 태도와 습관을 가지고 있는지 보는 것입니다. 물론, 해당 포지션의 중요한 테크 트렌드를 구현하는 역량도 검증합니다. (가령, 프론트엔드 개발자라면 SPA 구현 역량)

하던대로 반복하는 것은 성실한 것이 아니라, 게으른 것이다.

1. 해당 포지션에 맞는 개발 과제를 선정하자.

해당 포지션의 채용공고(Job Description)을 참고하여 어떤 기술 스택이 필요한지 정합니다. 기술 스택은 개발 언어만을 의미하지 않습니다. 프레임워크와 라이브러리 등 다른 개발 요소도 포함합니다.

웹 서비스 API 개발자 포지션을 준비한다면, 단순한 생산성 유틸리티 과제는 적당한 후보가 아닙니다. 서비스를 개발할 때 요구되는 기술적인 특성이 과제 결과물에 보여지는 것이 중요하기 때문입니다.

웹 서비스가 동작하기 위해서 필요한 개발 요소를 모두 담고 있는 과제가 적당합니다. 물론, 서비스 API 개발자라면 클라이언트와 데이터베이스는 간략하게 준비할 수 있겠습니다.

지원하는 회사에서 개발 과제를 내준게 아니고 스스로 선정한다면,

희망하는 분야에서 유명한 서비스의 핵심 기능만 카피캣으로 선정
특정 모듈이 아닌 그 자체로 동작하는 전체 사이클을 범위로 선정

2. 과제 내용에 있는 모든 문장은 필수다. (우대사항도, 참고내용도 필수)

그렇게 해도 좋다는 것은 그렇게 하면 더 나음을 보여줄 수 있는 기회가 있다는 말입니다.

만약, 우대사항 둘중에 하나라는 표현이 있다면 그것은 둘다 하라는 말입니다.

3. 제3자가 코드를 열어보지 않아도 무슨 프로젝트인지, 어떻게 개발했는지 알 수 있게 쓰고, 코드만 봐도 무슨 프로젝트인지 알 수 있게 작성하자.

개발 과제를 살펴보는 대부분은 당신이 누구인지 정보가 없는 상태이며, 과제를 요구한 관계자가 아니라면 과제가 무엇인지도 모릅니다. 심지어, 해당 개발 언어를 모르는 사람일 수도 있습니다.

그래서, 아래 내용을 친절하게 작성해주자.

프로젝트 개요와 스펙, 기술적인 특성 그리고 구성
사용한 기술 스택과 라이브러리
실행 결과와 실행 방법, 그에 관한 링크, 이미지, 영상 등

4. 네이밍, 가독성, 주석, API 문서화, 테스트케이스, 예외처리, 불필요한 코드 제거를 상용 서비스 수준으로 작성하자.

개발 과제의 내용에서 코드 뿐만 아니라 다양한 것들을 봅니다.

협업하기 좋은 사람인지, 무엇을 고려하는지, 어떻게 다른 사람을 배려하는지, 유지보수를 대비하는지, 지속적으로 개선하고 노력하는 사람인지.

5. 유닛테스트를 꼭 작성하자.

테스트 코드는 TDD 같은 거창한 것을 말하지 않아도 중요합니다.

테스트 코드를 작성하는 것은 자신이 구현하려는 코드가 어떤 특성을 가지고 있으며 어떤 위험요소가 있는지를 이해한다는 것이고, 이것이 지속적으로 훈련되어 있다는 것은 좋은 개발자의 특성입니다.

6. 트래픽이 많고, 데이터가 많은 경우를 염두하고 구현하자.

개발 과제 결과물에 많은 트래픽을 담아내고, 데이터를 많이 적재할 필요는 없습니다. 수십개의 데이터만으로 충분합니다. 그러나, 트래픽이 많고, 데이터가 많은 경우도 고려해서 구현합니다. 그냥 실행해서 동작되는 코드는 매력이 없습니다.

데이터도 Lorem Ipsum 같은 무의미한 데이터를 사용하지 말고, 실제와 동일한 것을 만들어서 사용하세요.

7. 동시성 처리 고려 우대사항은 반드시 고려하는게 좋다. 파일럿 냄새는 버려라.

만약 채팅 서비스를 만든다고 가정해보죠. 여러가지 이유로 채팅 메시지가 순서대로 처리되지 않을 수 있습니다. 이럴때를 고려해서 구현되어 있어야 합니다. 즉, 복수의 유저 또는 요청과 응답을 고려해야 합니다.

읽기를 동시에 처리하는 방향을 고려하거나, 쓰기를 동시에 처리하는 방향을 고려하는 것입니다.

8. 확장성 이슈를 고려해서 구현하자.

개발과제 결과물이 복수의 서버에서 동작하도록 고려해서 구현해야 합니다. 다시 말해, 실제 상용 서비스가 동작하는 환경을 가정해야 한다는 말입니다.

가령, 서버A와 서버B가 있는데, 하나의 유저가 서버A와 서버B 어느쪽으로 요청/응답을 받아도 문제가 없도록 하는 것을 의미합니다.

9. 과제 떨어져도, 산출물 수준으로 다듬어서 개인 포트폴리오로 써먹어라.

개발 과제를 잘 준비해도 결과가 좋지 않을 수 있습니다. 그렇다고 과제 결과물을 그대로 두지 말고, 산출물 수준으로 다듬어서 개인 포트폴리오로 써먹으세요.

가령, 개발 과제 결과물을 작성하는 동안의 개발 일지를 추가로 정리하거나, 무엇을 배우고, 무엇이 문제이며, 무엇을 개선하고 실행했는지를 기록해두면 좋습니다. (물론, 실행도 하라는 말입니다.)

10. 과제를 어딘가에 제출하더라도, 제출한 회사명처럼 민감한 내용은 절대 드러나지 않도록 해라.

모든 것은 실제와 같아야 합니다. 그러므로, 제출한 회사명처럼 민감한 내용은 절대 드러나지 않아야 합니다. 뿐만 아니라, 최종 결과물 뿐만 아니라 과제의 출발점 그리고 실행 과정, 결과물 이후의 행적까지 다루어야 합니다.

이것만이라도!

위에서 이야기한 것 중에서 3, 4, 5번 만이라도 꼭 챙기자. 결국 다른 사람이 읽게 되고 그 사람을 배려하고 잘 정리된 결과물이라면 완성도는 그 자체로 훌륭합니다.

샘플!

아직 위에서 말한 10가지를 잘 지켜서 공개한 프로젝트를 보지 못했습니다. 유명한 오픈소스 프로젝트가 아니고서는.

그럼에도 불구하고, 개발 과제를 준비하는 분들께 조금이라도 도움이 되기를 바래서 샘플(?)을 링크합니다.

그럼, 좋은 개발자로 성장하며 좋은 영향을 주고 받길 바래요.