시나몬 브레드
개발과 관련된 이야기를 하는 곳입니다. 쉽게 찾을 수 있는 소개 형식의 글 보다는 실무를 통해 얻어진 깊이있는 정보와 전체 흐름을 이해할 수 있는 지식을 다루려고 노력중입니다.
java bean mapper와 DTO 소개

Overview

spring, jpa 기반으로 개발할때 도움이 있는 java bean mapper 라이브러리를 소개합니다.

 

 

아래와 같은 간단한 JPA Entity 객체를 가지고 설명합니다.




  

Http 기반의 api 개발할때 필요에 따라 JPA Entity 바로 api 응답으로 내보내는 경우가 있습니다. 아래는 샘플 코드입니다. 


 

그러면 다음 그림과 비슷한 결과를 응답하게 됩니다.


 

 

이럴 경우에 발생하는 순환 참조 문제같은 몇가지는 jackson json 라이브러리가 해결해주기도하지만 일반적으로 아주 작은 프로젝트가 아니라면 추천할만한 방식이 아닙니다. JPA Entity 도메인 데이터와 api 응답 데이터간에 생명주기가 틀리기 때문입니다.







데이터 생명주기

프로젝트의 초기에는 요구사항에 맞춰서 데이터베이스가 설게되기 때문에 이렇게 Entity 바로 응답해도 문제가 안되지만 프로젝트가 실제 운영을 시작한후에 발생하는 요구사항을 위한 기능추가가 반복되다보면 처음 설계된 데이터베이스 구조로는 수용이 불가능한 경우가 발생하기 시작합니다. 이때부터 다양한 코딩 기법을 동원하여 문제를 해결하게 되는데, 데이터베이스를 통한 물리적 관계(relation) 이용하지 않고 논리적인 관계 프로그램 코드 상으로만 연관관계를 형성하게 되는 데이터들이 발생하게 됩니다.

 

이렇게 처리할 밖에 없는 이유는 관계형 데이터베이스는 일반적으로 한번 만들어져서 데이터가 쌓이기 시작하면수준의 변경이 거의 불가능하기 때문입니다. 데이터베이스는 한번 서비스를 시작한 이후에는 거의 바뀌지 않지만 서비스의 요구사항은 계속해서 추가, 변경을 반복하면서 이애 대응하는 api 응답 데이터 포맷은 짧은 주기에 변할 수 있습니다. 그래서 JPA Entity 객체를 바로 api 응답으로 사용하는 것은 적절하지 않습니다.

 

이렇게 생명주기가 다른 데이터베이스델과 api 응답 데이터 간에 사이를 매꿔주는 역할을 하는 것이 바로 DTO(data transfer object) 입니다. JEE(java enterprise edition) 에서 소개되었으며 VO(value object) 라고도하는 DTO model -> service -> controller 이어지는 MVC 어플리케이션에서 계층간에 데이터를 전달할 목적으로 사용합니다. 간단하게 말하면 DTO 로직을 포하하지 않고 데이터의 전달만을 목적으로 사용하는 객체입니다.

 

도메인 모델 데이터를 DTO를 통해서 전달하게 되면 원래의 데이터 넣고 빼거나 조합거나, 혹은 또 다른 데이터와 병합하거나 하는 등의 조작을 통해 데이터 포맷을 효과적으로 조정할 수 있습니다.

서버 api 응답 데이터를 DTO 이용해서 만들게 되면 도메인 모델과 비지니스 로직간의 생명주기 간극을 훌륭하게 매꿀 있습니다.







DTO 사용하기

위의 Entity 대해서 아래와 같은 DTO 만들고 어떻게 사용하는지 확인해보겠습니다.



 


 


1. Brute-force 방식 DTO 객체 사용

먼저DTO  객체를 가장 단순게 사용하는 코드를 한번 보겠습니다.


 

위와 같이 작성후 실행해보면 아래와 같은 응답을 받게 됩니다. 


jpa entity 에는 있지만 DTO 에서는 정의 하지 않은 필드가 응답에 포함되지 않았습니다. 이와 같이 일차적으로 DTO는 entity 객체에서 불필요한 정보를 제외하고 값을 전달하는 마스킹의 역할을 하게 됩니다.

 

위 코드는 잘 작동하지만 이런 방식은 지루한 반복작업이 필요한 코드가 만들어질 아니라 어플리케이션의 유지보수 관점에서도 문제가 있습니다. 만약 새로운 기능 개발로 인해 Entity 변경이 생기고 DTO 같이 수정 되야 한다면 코드도 추가적인 필드 매핑 작업이 필요 합니다. 만약 이런 매핑코드가 여러곳에 존재한다면 코드들을 모두 추적하여 수정을 해야 합니다. 이런 방식은 유지보수과정에서 오류를 유발가능성이 높고 개발자를 피곤하게 만듭니다.

 


 

2. Bean utils 를 사용

다음으로 생각해볼 수 있는 방법은  Bean util 객체를 사용하는 것입니다. Apache commons spring    BeanUtils 객체가 있습니다. Source 객체에 있는 필드들의 값을 target객체의 필드에 똑같이 set 해주는 역할입니다. 이를 이용한 코드는 아래와 같습니다.

 

 

 BeanUtils 객체를 분석해서 동적으로 복사를 해주기 때문에 코드가 단순해졌습니다. 다만 이런 BeanUtil 들은 기본적인 기능만을 가지고 있어서 문자, 숫자같은 단순한 값복사는 잘되지만 그이상의 복잡한 상황에서는 제대로된 값 복사가 되지 않습니다. 코드를 실행한 결과는 아래와 같습니다.



 

위와 같이 String, Long 필드는 복사가 되었지만 MenuGroup Entity 값이 MenuGroupDto 로는 복사되지 않았습니다. 이름이 같아도 객체입이 상황등은 해결해주지 못합니다.

 

 

 

3. Java bean mapper 사용

Java bean mapper 라이브러리는 java 객체간에 값을 전달하는 기능을 체계적으로 관리해주는 솔루션입니다. 찾아보면 여러 종류의 mapper 라이브러리가 있는데, 이글에서는 modelmapper (http://modelmapper.org) 라는 라이브러리를 사용합니다.

 

사용하는 코드를 한번 보겠습니다. 



 

한줄로 간단하게 처리가 가능하고 BeanUtils 처리해주지 못하는 여러가지 상황에 대해서 복사를 해줍니다.



위와 같이 MenuGroup 객체의 값이 다른 타입인 MenuGroupDto 객체로 복사되었습니다.

이렇게 bean mapper 지능적으로 값복사를 해줍니다.

 

대략적인 기능을 정리해보겠습니다.

  • 필드의 이름이 같다면 다른 타입의 객체로도 매핑 가능
  • 객체안에 중첩되어 있는 다른 객체나 List 같은 collection객체의 값을 계속 따라들어가면서 매핑 가능
  • 설정을 통해 다양한  매핑 조건 설정가능
    • 값이 null 필드 복사 여부 설정
    • 특정 필드 매핑여부 결정
    • 지정한 다른 이름의 필드로 매핑
    • Access levle(public, protected, private..) 따라 매핑 여부 결정
  • Custom 변환기를 통해 원하는 형태로 매핑 가능





결론

프로젝트 진행 초기에 DTO 만들면 도메인 Entity 객체와 거의 비슷한 클래스를 만들게 되어 지루하게 객체 생성을 반복하고 도메인 객체와 같은 값을 그대로 내보내게되는 경우가 대부분입니다. 때문에 DTO 객체의 효용성에 대해서 의문을 가지는 경우를 종종 보았습니다.


그러나 DTO객체 사용의 진가는 서비스 운영중에 확인이 됩니다. 앞서 말한데로 운영중인 서비스의 데이터 베이스구조를 크게 바꾸기가 어려운데, 비즈니스 요구사항은 보통개발 설계상 애로사항이나 적정 일정등이 고려되지 않고 결정됩니다. DTO 이런 문제들을 해결하는데 도움을 줄것입니다. 물론 이런 데이터 조작이 많아 수록 프로그램의 최초 설계가 점점 깨져갈것입니다. 저는 이것도  프로그램의 생명주기상 자연스런 과정이고 개발자가 밤을 세는것 보다는 훨씬 낫다고 생각합니다.

 

 


참조

http://blog.naver.com/kbh3983/220988245343

  Comments,   0  Trackbacks
댓글 쓰기
개발자 이직 취직 가이드, 면접 후기2

이전글 개발자 이직 취직 가이드, 면접 후기1 에서 이어지는 글입니다.

단기적 준비

전반적인 준비

이직을 마음먹고 바로 지금부터 뭘 하면 될지에 대한 부분으로, 이글의 핵심 내용이다.


면접 경험담

인터넷을 통해 이직에 대해서 다양한 정보를 먼저 습득한다. 이 글을 포함하여 다양한 입사지원 경험담을 찾을 수 있다. 필자도 처음에 무작정 지원을 하려다가 그런 글들을 읽고 준비가 한참 필요하다고 느끼고 공부를 시작하였다. 아래는 필자가 읽었었던 글들인데, 좀 더 최근의 글들을 찾아보는 것이 좋을 것 같다. 이런 글들을 통해서 업체들의 분위기라던가 면접 난이도 등을 파악해두면 좋다.


개발자 면접 준비 책

이글 같이 가볍게 짚어보는 글과 달리 아주 자세하게 필요한 과정을 소개하는 책도 있다. 여러 업체들의 채용 특성과 채용 단계별 준비사항과 면접에서 필요한 기술문제와 풀이 등 다양한 내용들이 포함되어 있다. 최근에는 알고리즘 문제들에 대한 설명과 풀이법 등을 다루는 책도 많이 발간되어 있다.

실제로 면접관들도 이런 책들을 통해 출제 문제를 고를 것이기 때문에 똑같은 문제를 만날 수도 있다. 다만 출제 범위가 넓어서 모든 걸 외워서 문제를 해결하기는 불가능할 것이다.



지원업체에 대해 분석

이번에 여러 업체에 면접을 보면서 지원동기나 해당 업체에 대한 호감도를 묻는 식의 질문은 받은 적이 없다. 여기서 말하려는 지원업체에 대한 분석이라는 것은 해당 업체의 면접 과정에 대한 분석이다. 어떤 질문을 받게 될지, 난이도는 어느 정도일지 등을 파악하고 있으면, 당황할 일이 적어지고 마음이 편안해진다. 정보가 부족한 상태로 전화, 1차, 2차 면접 등을 진행하게 되면 막막하고 막연한 느낌에 긴장감이 커지고 실수할 가능성이 커진다. 인터넷 검색을 통해 다양한 정보를 얻을 수 있다.

광고는 아니지만 잡플래닛이라는 구인구직 서비스 플랫폼이 있는데 이곳에는 실제 면접자들의 면접 경험 공유나 재직자들 이직 접 작성한 기업 리뷰 등 정보는 신뢰할만하다고 생각되며 어디서도 볼 수 없는 정보를 얻을 수 있었다. 실제로 지원할 업체 선택도 이런 곳의 리뷰에 영향을 받게 된다.


추천받기

큰 업체들은 생판 모르는 사람 중에 선발하는 것보다는 어느 정도 검증된 소개받은 개발자들을 선호하는 경향이 있다고 본다. 소개를 받았다고 해서 무조건 합격하는 것은 아니지만 진행 과정이 좀 더 수월해질 수는 있다. 큰 업체에 취직하면 아는 개발자들을 만날 가능성이 높다. 왜냐면 큰 만큼 많은 개발자가 모여 있고, 그런 곳에 계신 분들이 주로 비슷한 수준의 업체들로 이직을 하기 때문이다.  주변에 자신을 소개해줄 사람이 있는지 찾아보는 것도 좋겠다.



자기소개서 준비

이직의 첫 관문은 바로 자기소개서이다. 면접 준비를 아무리 열심히 해도 서류전형에 합격하지 못한다면 아무 의미가 없을 것이다. 자기소개서에서 중요한 것은 지금까지 진행했던 프로젝트들에서 어떤 역할을 맡았었느냐 하는 부분이다. 당연히 주도적으로 설계와 핵심 기능을 개발하고 어려운 문제를 적극적으로 해결하는 사람을 선호한다. 단순히 팀원으로 참여해서 일부분을 진행한 경험만 많다면 큰 매리트가 없을 수도 있다. 


스토리텔링

찾아보면 자기소개서 작성방법이 많이 있지만 필자는 이번에 SCAR기법이라는 방법을 사용해보았다. SCAR는 상황(Situation)-위기(Crisis)-행동(Action)-결과(Result)의 약자로, 먼저 주어진 상황을 설명하고 어떤 문제/위기/갈등이 발생했는지를 알려주고, 그것을 구체적으로 어떻게 해결해서 어떤 성과/결과를 만들어냈는지를 이야기하는 기법이다. 이런 방법들을 가지고 스토리텔링을 통해서 좋은 이야기를 만들어내는 것에 집중했다. 쉽게 말하면 내가 어떤 어떠한 애로사항에 직면했을 때 그 문제들을 이러이러한 방법으로 해결해서 무슨 무슨 성과를 이뤄냈다 와 같은 식이다. 아마도 개발자의 스토리텔링이라는 것은 아래와 같은 내용들일 것이다.

상황

기존 개발된 프로그램에 문제가 많았다.


위기

그로 인해 업무효율이 저하되고 개발 일정이 늘 부족했다.


행동

새로운 기술, 프로세스 혹은 더 나은 설계 등을 도입하여 프로젝트 진행하였다.


결과

팀의 생산성이 향상되고 새로운 개발 지식을 습득할 수 있었다.


위와 같은 내용들을 본인의 경험에 비추어서 이야기 형식으로 전달하면, 읽는 사람도 지루하지 않으면서 개발자 자신이 어떤 사람인지 알 수 있게 해준다. 다만 글이 너무 길어지면 안 되므로 핵심적인 내용만 잘 간추려야 할 것이고, 특정 기술에 대해서 너무 자세하게 작성해도 해당 기술을 모르는 사람은 읽다가 지루함을 느낄 수 있다.

아래 글을 참고해서 실제로 자신의 스토리를 만들어보기 바란다.


지원분야 맞춤 내용

본인의 경력사항이 가장 중요하겠지만, 그 외 필자가 서류 합격에 주효했다고 생각하는 부분은 바로 지원 분야에 대한 맞춤 자기소개이다. 각 업체에 이력서를 작성할 때 공통 경력 소개는 똑같은 글을 올리지만, 구인공고에 표시된 지원하는 부서, 혹은 포지션에서 어떤 기술로 무엇을 만드는지를 보고 그와 관련된 경험이나 나의 생각에 대해서 추가적으로 작성하였다. 이때 당연하게도 없던 경험을 억지로 만들어내면 안 된다. 그렇기 때문에 지원을 할 때 실제로 본인이 관심이 많고 경험이 많은 곳을 지원해서, 해당 업무에 대한 본인의 진심이 담긴 견해와 깊은 관심을 표현하는 것이 도움이 될 것이다.


코딩 테스트 준비

코딩 테스트 준비를 통해서 면접 전 온라인 혹은 오프라인으로 진행하는 코딩 테스트와 면접 중에 화이트보드나 종이에 작성하는 손 코딩에 대한 준비도 포함된다. 간단한 알고리즘은 아예 외워 버리는 것이 좋다.


자료구조, 정렬, Thread, 그 외 알고리즘.

단골손님으로 기본적인 자료구조나 정렬하는 코드를 직접 작성하거나 이를 응용하는 코딩을 할 수 있다. Stack, queue, 혹은 bubble sort 의 코드를 아예 외워 버리자. 필자는 반복적으로 종이에 같은 코드를 써보는 방식으로 외웠다. 이보다 어려운 binary tree, map, quick sort, merge sort 등등의 알고리즘도 최소한 몇 번은 코딩해보고 작동방식을 이해하고 있어야 한다. 자바 개발자라면 thread 여러 개를 원하는 데로 컨트롤하는 등 thread에 대한 이해도를 확인하는 코딩 문제를 만날 수도 있다.

아래 사이트들은 스택, 트리, 맵 같은 자료구조부터 시작해서 탐색, 정렬, 길 찾기 알고리즘까지 다양한 종류의 문제들을 온라인으로 풀어볼 수 있는 알고리즘 사이트이다.

Baekjoon Online Judge

https://www.acmicpc.net


초급 난이도 문제도 결코 쉽지 않았다. 실제 코딩 테스트는 보통 몇 시간 안에 몇 문제를 풀어야 하기 때문에 너무 수준 높은 문제는 풀이 시간이 많이 걸려서 출제가 쉽지 않을 것으로 본다. 그래도 어느 정도 다양하게 이해하고 있어야 막상 쉬운 문제라도 풀 수 있을 것이다. 본인의 실력을 확인하고 알고리즘 문제들의 일반적인 코딩 패턴도 숙지해두는 것이 좋다.


온라인 코딩

기업의 온라인 코딩 테스트를 위한 사이트가 여럿 있다. 구직자는 이런 사이트를 통해 코딩을 하게 될 것이다. 문제를 주고 익숙한 언어로 풀이를 진행하며, 시간제한이 끝나면 자동으로 종료된다.

 이런 사이트들은 개발자가 어떻게 코딩을 해나가는지를 시간순으로 추적할 수 있게 되어 있어서 어디서 만들어진 코드를 붙여 넣기 한다거나 하면 바로 알 수 있다. 그리고 이런 곳에서 코딩을 할 때 보통 코드 자동완성 기능이 없다. 평소에 IDE 환경에서 자동 완성 기능을 많이 사용했다면 유틸 성격의 클래스 이름이나 메서드 이름을 끝까지 직접 코딩하는 것이 어려울 수 있다. 되도록 자동완성 기능 없이 코딩을 해보고 필수적인 것들은 스펠링을 외우도록 한다.

아래 사이트에서는 실제 채용을 위한 코딩 테스트도 진행할 수 있으며, 개발자들이 재미로 풀어볼 수 있는 수준별 알고리즘 문제들이 만들어져 있다. 



전화면접 준비

전화면접의 내용은 아래 기술면접의 내용과 비슷할 것이다. 물어보는 것들에 대해서 잘 대답하면 된다. 몇 가지 추가해보면 편안하게 30분~1시간 정도 않아서 전화할 수 있는 장소 찾아 놓고 일찍 가서 준비를 하고 있는 것이 좋다. 만약 현재 재직 중이라면 30분~1시간 정도 자리를 비우기가 쉽지 않을 수 있으므로 주의해야 한다. 필자는 업무시간 중에 회사와 멀리 떨어진 커피숍에서 전화면접을 진행하였다. 이때 이어폰을 준비하면 좋다. 직접 폰으로 오랫동안 통화하기가 어렵다. 그리고 알고리즘이나 설계 같은걸 물어볼 수 도 있으므로 필기도구도 준비하자.



기술 면접 준비

이직의 핵심은 바로 기술면접이다.

내가 잘하든 못하든 평소 실력으로 합격하는 곳으로 가겠다.라고 생각한다면 사실 이 글이 도움이 별로 안 될 수 있다. 좋은 기업이고 누구나 가고 싶어 하기 때문에 경쟁률이 높은 곳이라면 당연히 준비를 해야 한다. 실수하지 않고 본인의 실력을 100% 드러내기 위한 준비라고 생각하도록 하자. 


면접 예상 질문 답변 연습

면접 예상 질문들에 대해서 직접 답을 해보는 연습을 한다. 개발자 면접 예상 질문에 대한 목록은 검색해보면 많이 나오고 아래 링크에서도 확인할 수 있다. 뭔가를 마음속으로 알고 있다는 것과 그것을 말로 상대방을 이해시킨다는 것은 전혀 다르다. 아래 링크에 포함된 질문들에 대해서 실제 본인의 말투로 어떻게 설명할지를 직접 써보고 직접 말을 해보는 연습을 한다. 

필자는 아래 링크들에 나온 질문들을 모두 취합해서 답변을 작성하고 그 내용들을 어느 정도 외워 버렸었다. 실제 입으로 말할 내용을 그대로 작성해야 머리에만 있고 입으로 설명이 안 되는 상황을 피할 수 있다. 여기저기서 검색한 내용들과 실제로 면접 때 단골로 나왔던 주제들은 아래와 같다.

자바 GC의 동작 방식에 대해서 설명하세요.

대용량 트래픽을 감당해야 하는 시스템을 어떻게 설계할지 설명하고 설계도를 그려보세요.

본인이 개발한 것 중 가장 큰 프로젝트에 대해서 아키텍처를 그리고 설명해보세요.


아래 링크들은 면접 예상 질문이 나온 글이다.

카카오 면접 시 듣게 되는 70가지 질문

http://www.bloter.net/archives/245529


네이버 면접시 듣게 되는 41가지 질문

http://www.bloter.net/archives/245110


“개발자 면접 예상 질문, 오픈소스로 공유해요”

http://www.bloter.net/archives/246472


기술 면접 자료

https://hyogij.wordpress.com/2014/09/11/기술-면접-자료


요즘은 잘 안 물어본다고 하는데, 보통 수수께끼 성 질문으로 불리는 창의성이나 논리력 사고력을 시험하기 위한 질문들이다. 아래는 구글 채용 시 나온 질문들이라고 한다.

구글 채용 면접에서 가장 답하기 어려운 질문 11가지

http://www.huffingtonpost.kr/2016/03/28/story_n_9555240.html


그리고 아래는 너무 고맙게도 위와 같은 문제들에 대한 어느 블로거님의 답변이다.


필자의 경우 실제로 위 답변을 보고 이런 애매한 문제들을 어떻게 접근해야 할지 감을 잡았다. 한번 감을 잡은 이후로는 이제 비슷한 문제들을 풀어나가는 요령에 대해서 알게 되었다. 통계학적인 접근이 주요 방법이다. 실제 기업들이 난해하고 추상적 인문제들을 해결하려는 미션에서 사용하는 방식으로 알고 있다.



인성면접 준비

2차 면접이면서 인성 면접, 문화 면접 등 업체마다 불리는 이름이 다양하다. 사실 이 2차 면접에 대한 정보가 거의 없으며 필자도 한 번밖에 경험을 못해봐서 간단하게만 적어 본다. 일단 입사동기, 회사에 대한 이미지 이런 건 어디서도 질문받은 적이 없다. 개발에 대한 좀 더 포괄적인 질문을 받았을 뿐이다. 업무 진행상 어려운 경험이 어떤 게 있었는지, 그 위기를 어떻게 극복했는지에 대해서 현재 진행하고 있는 프로젝트의 설계도 같은걸 그려보라는 등의 질문을 받았다. 문화면접이라고도 부르는 이유는 구직자의 성향이 회사의 문화와 잘 맞을지 확인한다는 의미인데, 상당히 추상적이고 주관적 이긴 한 것 같다.





결론

이번에 이직을 준비하면서 이직/취직을 위해서 면접 공략책을 읽고, 알고리즘을 외우고, 종이에 코딩하는 등의 과정이 과연 나의 개발실력을 입증하는데 도움이 되는 것일까에 대한 의문이 많이 있었다. 신입도 아니고 경력 10년이 넘었는데, 실무에서 자료구조, 검색 알고리즘 같은걸 코딩하게 될 일은 거의 없다고 볼 수 있다.

하지만 요즘 기업들이 원하는 사람은 기초 알고리즘 풀이와 손 코딩이 되는 사람이다.(물론 이것만 잘하면 된다는 뜻은 아니다.) 이런 기본적인 것이 되면 실무에서 접하는 문제들도 해결할 수 있는 능력이 된다고 보는 것이다. 이점을 이해하고 충실하게 준비를 해나가야 할 것이다. 최근 지인이 지원한 어떤 업체에서는 프로젝트 초기 세팅에서부터 배포까지를 진행해야 하는 문제를 코딩 테스트로 진행했다고 한다. 좋은 개발자를 선발하기 위해 업체들도 고민을 계속하고 있으며 변별력을 높이기 위해 다양한 시도를 계속하고 있다고 생각한다. 사전 조사와 확실한 준비가 성공의 지름길이다.

마지막으로 역시 개인적인 이직 전략중에 하나는 업체별 지원 순서이다. 가장 합격이 어려울 것으로 예상되면서 마음속의 0순위로 조금은 버겁게 느껴지는 업체부터 지원한다. 그렇게해서 1순위 2순위로 내려오면서 시간 간격을 두고 입사지원을 하게되면 내가 갈 수 있는 최선의 업체에 합격을 하게 될가능성이 높다. 또한 더 어려운 면접을 먼저 보고 다음으로 좀더 쉬운 면접을 보게 되면서 점점 마음의 여유을 가질 수 있을 것이다.


Good luck..!

  Comments,   0  Trackbacks
댓글 쓰기
개발자 이직 취직 가이드, 면접 후기1

약 6개월간 긴 준비 끝에 나름 괜찮다고 평가받는 IT 업체로 이직을 하게 되었다. 이 과정에서 이름만 들으면 알 수 있는 IT 업체 5곳에 이력서를 넣고, 4곳에 면접까지 진행했으며 마지막으로 면접을 본 업체에 최종 입사까지 하게 되었다. 필자는 이전까지 주로 작은 개발업체에서 일했었기 때문에 이번 입사지원과정에 생소한 것들이 많았다. 이렇게 진행하면서 얻은 나름대로의 노하우를 공개해보고자 한다. 이 글을 읽는 소프트웨어 개발자들에게 많은 도움이 되기를 바란다.

참고로 이 글은 필자의 개인적인 견해와 경험이므로 글을 읽는 분들의 상황과 100% 일치하지 않을 수 있다. 필자는 경력 약 13년 차 정도의 자바언어를 주력으로 하는 서버 개발자로 신입사원이나 저 경력차 개발자의 상황과는 다를 수 있다.

먼저 업체들의 일반적인 구인 과정을 소개하고, 다음으로 각 단계에서 준비할 것들을 짚어보려고 한다.



일반적인 개발자 구인 과정

필자가 신입사원 시절에는 IT기업으로 이름이 알려진 업체는 naver, daum 정도 말고는 거의 없다시피 했다. 그에 비하면 요즘은 대기업이라고 부를 만한 IT업체들이 적지 않다. 그리고 아직은 스타트업 단계지만 개발자 친화적인 문화를 가지고 있고, 투자금도 넉넉한(?) 기업들이 많아서 개발자들이 일하기 괜찮은 업체로 가기 위한 선택권이 어느 때보다도 넓어졌다고 생각한다. 하지만 괜찮은 업체들은 그만큼 실력 있는 개발자들을 채용하려고 하기 때문에 적당히 해서는 합격이 쉽지 않다.


보통의 일반 중소기업이라면 사실 서류전형 후 바로 실무자 면접에서 합격 여부가 갈리는 식으로 평범하지만 규모가 큰 기업, 그리고 개발자의 가치를 중요하게 생각하는 기업이라면 이보다는 좀 더 여러 단계를 거쳐 선발하게 된다. 또한 채용진행과정이 상당히 길다. 최종 합격통보를 받기까지는 보통 2달은 예상하는것이 좋겠다.

 실제로 경험해본 결과 회사별로 구인 과정이 똑같지는 않았지만일반적으로 아래와 같은 절차로 진행된다.

    • 서류전형
    • 코딩 테스트
    • 전화 면접
    • 1차 면접
    • 2차 면접


위의 각 과정에 대해서 간략하게 소개한다.


서류전형

큰 업체는 보통 자체 구축된 채용 시스템을 통해 입사지원을 하게 된다. 각사가 서로 다른 포맷과 입력항목을 가지고 있으므로 지원하려는 회사의 채용시스템에 지원을 해서 입력방식을 미리 확인하면 좋다. 특히 자기소개서 같은 경우는 업체별로 원하는 내용 원하는 글의 분량등 많이 틀려서 미리 확인해두고 따로 천천히 작성하면 좋을것 같다. 어쨋든 지원하려는 업체마다 비슷한 내용을 반복적으로 입력해야 하는 번거로움이 있을 수 있다.

개인 활동을 어떻게 하고 있는지 물어보는 경우도 있다. Github에 개인 프로젝트를 진행하고 있느냐, 오픈소스에 컨트리뷰트를 해 본 경험이 있느냐, 개발 지식공유 블로그 같은 것을 운영하고 있느냐 이런 활동들이 도움이 될 것으로 생각한다.

코딩 테스트

온라인, 혹은 오프라인으로 주어지는 문제를 코드로 작성해서 제출한다. 문제 수준은 기본적인 프로그램적 사고를 할 수 있는지 물어보는 문제가 대부 분지만 지원하는 포지션에 따라 특정 알고리즘을 구현하거나 응용하는 수준의 문제도 제출된다. 약간 복잡한 SQL문을 작성하는 문제도 있었다. 온라인 코딩 테스트는 보통 약 3시간 동안에 3~4 문제를 풀어야 한다. 오프라인 테스트는 좀 더 복잡한 프로그램을 24시간 안에 제출해야 하는 형태도 있다.

전화면접

미리 지정한 시간에 전화를 걸어오면 약 30~40분간 면접관의 질문에 답을 해야 한다. 질문내용은 일반적으로 알아야 할 개발 관련 용어에 대한 설명이나 간단한 알고리즘을 말로 풀어보라는 식이다. 자바 서버 개발자라면 http, spring 관련 지식, JPA 관련 지식에 대해서 물어볼 확률이 높다.

용어 설명이라는 것이 머리로는 이해해도 말로 다른 누군가에게 설명하기는 생각보다 쉽지 않다. 알고 있는 내용을 말로 풀어서 설명을 해보는 연습이 필요하다.


1차 면접

이직 과정의 핵심은 역시 1차 면접이라 할 수 있다. 전화 면접과 마찬가지로 개발 용어에 대해서 물어보거나, 간단한 개발 문제를 직접 풀어보라는 등의 질문을 한다. 이 과정에서 화이트보드나 종이에 손 코딩을 하게 될 수 있다. 그리고 지금까지 진행했던 가장 큰 프로젝트에 대해서 자세하게 설명하고 그 내용에 대해서 아주 깊이 있는 설계 방법이나 애로사항 등에 대한 질문들을 받게 될 수 있다. 또 대형 시스템에 대해서 얼마나 이해하고 있는지도 물어본다. 실제로 어떻게 설계를 할지 그림을 그려야 할 수 있다. 그 외 경력이 좀 된다면 부하직원을 어떻게 리딩 할지 등 직급에 맞는 역할에 대해서도 물어볼 수 있다. 여러 명이 동시에 들어와서 면접을 보는 경우도 있고 1대 1 면접을 여러 명과 진행하는 경우도 있었다. 면접관이 면접 진행 과정을 글로 적고, 그림을 그렸다면 사진도 찍어간다. 이 자료를 바탕으로 내부 평가를 통해서 결정하게 된다고 한다.


2차 면접

보통 작은 업체들은 사실상 1차 면접이 끝이지만, 큰 기업들은 2차 면접도 중요하다. 인성 면접이 2차에 이루어지게 된다. 필자는 이번에 2차 면접은 합격한 마지막 업체밖에 경험이 없기 때문에 정보가 제한적이긴 해서 간단한 경험담만 전달한다. 인성 면접이라고 해서 입사지원 이유나 성격의 장단점, 등과 같은 내용을 준비를 해갔으나 1차 면접과 별 차이가 없는 기술면접의 연장이었다. 다만 차이점은 좀 더 포괄적인 질문들로써 개발 과정에서 어려운 문제를 어떻게 해결했는지, 개발자로서 어떻게 성장해나가길 바라는지와 같은 질문들을 받았다.


지금까지 각 단계에 대해서 간단하게 한번 짚어 보았다. 이제는 좋은 자리로의 이직을 위해서 장기적인 관점에서의 준비와 단기적인 관점에서의 준비로 나누어서 한번 생각해보기로 한다.




장기적 준비

필자가 생각하는 장기적인 준비라는 것은 결국 실력 있는 개발자로 성장해 나가는 것이다. 내가 실제로 좋은 개발자라면 특별히 더 노력하지 않아도 입사전형 과정에서 저절로 티가 날것이다. 혹시라도 어떤 족집게 과외를 받고 본인의 실력에 넘치는 포지션에 이직하는 것은 본인에게도 해당 업체에게도 손해만 될 것이다. 

새로운 기술에 대해서 항상 관심을 가지고 공부하여 실 프로젝트에 적용해보려는 자세를 가지는 것이 좋다고 생각한다. 기존에 문제가 무엇이었고, 그 해결하기 위해 어떤 아이디어를 적용했는지를 이해하려고 해보면 새로운 기술을 더 쉽게 배울 수 있다. 그리고 회사일을 통해서는 실제 적용해보기 어려운 특정 기술이나 관심 분야에 대해서 개인 프로젝트를 진행해보는 것이 도움이 될 수 있다. 다만 개인 프로젝트라는 것은 저녁시간, 주말 시간 같이 놀거나 쉬어야 할 시간에 진행해야 한다는 것이 어려운 점이다.


다음글 개발자 이직 취직 가이드, 면접 후기2 에서 필자가 이직을 마음먹고 어떤 준비를 했는지 소개 한다.

  Comments,   0  Trackbacks
댓글 쓰기