[Fail Log] 나의 카카오 도전기(6) - 왜 탈락 했을까? & 총평

왜 탈락 했을까?

탈락했다. 이유가 무엇인지 궁급했다. 알수 없었다. 알려주지 않았기 때문이다. 답답했다. 온 정신을 다 쏟았기에 더욱 그랬다. 문제가 쉬웠다. 천하의 카카오가 이런 문제를 낼 이유가 없었다. 비록 자회사라고 해도 말이었다. 문제가 쉬워서 핵심은 문제 풀이에 있지 않을 것이라고 생각했다.

빠르게 결과를 낼수록 채용절차가 빨라진다는 시험 요건이 있었다. 나는 간단한 문제였던 만큼 문제풀이 시간에 핵심이 있다고 생각했다. 일주일 기간을 주었는데 나는 위와 같은 생각으로 4일만에 처리해서 보내주었다.

결과는 탈락이었다.

일단 분노에 휩싸여 한동안 그로기 상태에 놓여 있었다. 4일 동안 온힘을 다했기 때문에 더욱 그러한 기분이 깊게 빠졌었다. 카카오에 대한 분노가 생겼다. 사람가지고 장난치는 것 같은 기분이었다.

분노와 좌절의 기간이 지나고 스스로에 대한 객관적인 상태 평가가 이루어지게 되었다. 나의 개발을 보며 평가를 내리는 상대가 내 결과를 보고 매력응 느끼지 못한 이유가 았을 것이었다. 한 마디로 무언가 놓치고 과제를 수행한 것이다. 지금의 이글은 과연 내가 무엇을 놓친 것인가에 대한 스스로의 반성문이다. 무언가 내가 놓친것이 있었을 것이며 그 놓친 것이 나에게 있어서 중요한 지점인것 같다.

열심히 한게 중요한게 아니었다. 잘하는 것이 중요했다. 스프링 부트 답게 처리하는 것이 중요해 보였다.

탈락원인(내 생각)

1. JPA를 사용하지 않았다. -> 스프립 부트에서 이전과 다른 부분 중 가장 큰 부분을 차지 하는 것은 JPA의 존재 유무라고 생각한다. 자바 1.8버전 이상에 java stream을 적극적으로 이용하고 람다식을 활용하는 것은 이제는 일상이 되어야 했다. 특히나 새로운 시스템을 만들려하는 신생기업에서 가장 최신의 프로그래밍 기법이 적용될 것이 분명했다. JPA의 경우 가장 최근의 기법이라고 해도 나온지는 꽤 오래된 기법이었다. 내가 학원에서 공부하면서 배웠던 전자정부 시절부터 JPA는 세상에 등장했고 이미 꽤나 많은 사이트에서 쿼리를 대체하여 사용되고 있는 데이터 시스템이었다. 스프링 부트를 접한지 이제 막 6개월이 안된 시점에서 mybatis와 쿼리의 익숙하다고 혹은 부산은행 과거에 그렇게 사용햇다는 이유로 Mybatis를 사용했다는 점이 아마 평가 요소 자체를 날려버린 것일지도 모른다슨 생각이 문득 들었다. 시간을 좀 들였더라도 JPA를 활용하여 결과를 출력했어야 했다고 생각했다.

2. TDD를 제대로 이해하지 못했다. -> TDD, 테스트 주도형 개발이라는 것은 결국 문화이자 습관이다. 모든 기능을 개발하기 앞서 테스트를 먼저 구상하고 나중에 개밥진행한다는 어렴풋한 지식이 코드에 녹아 내렸다는 생각이 전혀 들지 않았다. 솔직히 일단 먼저 개발 부터 하고 보여주기식 테스트 코드를 만들었다. 개발주도형이있다. 일반적인 코딩을 하고 테스트 한 것 처럼 보였을 것이다.

3. 과연 DB 서버가 필요했을까? -> 1번의 내용괴 곂치는 것이다. 이미 데이터를 JSON으로 재공 받았으면 그 제공 받은 데이터는 고대로 데이터로서 안에 목업 파일의 형식으로 사용할수 있었다고 생각한다. 어쩌면 스프링 부트의 내용보다도 스크립트의 구현 내용도 중요햇을 것 같다.

4. 문제를 너무넘겨 짚고 생각했었는지도 모르겠댜. -> 굳이 내가 실수했던 것을 솔직하게 밝혀야 했을지, 지난 신용보증기금에서의 이수관 경력을 들먹이며 굳이 안해도되는 부분을 나서서했던게 아니었을까? 말그대로 택스트 그대로 문제를 읽었어야 했는지도 모르겠다. 1번문제에 국한된다는 총액에서 수수료를 빼는것이 나머지 문제에서도 영향을 주었던것이 아니었을지. 너무나 자의적인 판단으로 인해서 문제자체에 답을 잘못 낸것인지도 모른다는 생각이 들었다.

5. 긍융 경력 그중에서도 증권사의 경력이 있는가 자문해 보고 싶다. -> 카카오 이후 증권사 3곳을 도전해 보았지만 다 탈락이었다. 키움증권도 탈락이었고 이전에 미래에셋도 탈락이었다. 어느정도 이름있는 기업에게 아직 내 경력은 그렇게 매력적으로 다가 오지 않는 것이 분명했다. 아버지의 말대로 아직은 좀더 기어야 하는 건지도 모르겠다.

6. 정말 정말 빠르게 제출했어야 했는지도 모른다. -> 문제가 정말 말도 안되게 쉬웠다. 이걸 문제라고 내는건지 의심스러울 만큼 내용에 대해 의구심이 들었던 것이다. 사실 일정상에 중간에 개천절이 끼어있어서 개천절까지가 마지노선이 아니었을까 생각한다. 이 정도 뭔가 큰것을 바라고 만들라는 것이 아니라 테스트를 해보라는 것이니 3일 이면 충분하다고 생각했을 것이다.

7. 아니면 남은 기간을 충분히 활용하지 못했거나. -> 남은 3일을 기다리며 내가 짠 코드를 복기 하거나 수정하거나 테스트 해보는 과정을 생략햇는지도 모르겠다. 위에 1번과 같은 경우는 테스트 기간동안 충분히 인지하고 있었다. 남은 3일 동안 JPA 버전으로 따로 프로그램을 만들까 하는 고민이 들었지만 그러지 못했다. 지금 생각해보니 정말 최선을 다했는가 의심스럽다. 4일째 끝내고 나서 기운이 빠졌는지 충분히 되돌아 보지 못했던것 같다. 절박한 심정이 있었던 것인지 스스로에게 물어 보고 싶다. 제출한 이후 계속 코드를 수정할 수 있지 않았을까. 짧은 시간안에 제출해야한다는 조급함이 나를 몰고 간것 같다.

8. 과거에 했던 것을 자랑 하려고 했던것이 오히려 문제를 낳은 건지 모르겠다. -> 인터셉트를 가져와 사용했다. 쿼리의 로그를 보여주고 싶었고 개발에 용의하기 때문이었다. 그 점이 문제가 아니었을까 생각한다. 붙여넣기하여 사용하는 안일함 또는 그 코드를 자산의 일부라고 생각했는지 그걸 여기에 버젓이 사용하는 것이 윤리적으로 문제가 있다고 생각한 것일지도 모른다. 전체 간단한 패턴 디자인에 갑자기 복잡한 프로그램이 나온것, 그리고 결국에는 예외처리로는 처리하지 못해서 모델에 메세지를 보내 처리하게 했음에 필요없었던 예외 처리 클래스도 남겨두어 봐야 필요없는 부분임에도 자랑하고 싶어서 남겨 두었던 것이 거북하게 느껴졌을 것 같다.

9. Rest API 를 만들었는가? -> 컨트롤러에 @RestController를 선언 했다고 Rest API 서버가 아니다. Rest API의 기능을 하기 위해서 갖추어야 하는 부분이 있는가. 인프런에 스프링 교육을 다시 신청하게 된것도 바로 이러한 의문점 때문이었다. 내가 알고있는 것이 아직 많은 것이 부족하다는 반증이었다.

총평

테스트 결과에 대해 한마디로 다시 평하자면

스프링 부트로 프로그램을 짰음에도 스프링 부트 답지 못했다.

이렇게 표현을 하고 싶다. 프레임워크에 담긴 방식을 100% 활용하지 못한것이 문제일지도 몰랐다. 결국 모든 것이 원점으로 돌아간다. 아직은 많이 부족하고 좀 더 공부해야 한다. 내가 일부 알고 있는 지식이 모든 것을 반영하지 못한다. 급하게 생각하고 안일하게 대응했다. 꾸준하게 해야 결과가 나오고 그 결과에 대한 반영도 서서히 들어나게 된다.

프로그래머로서 알고리즘이 부족하고 프래임워크에 대한 지식도 많이 부족했다. 업무 개발자로서 업무에 대해 많아 아는가? 그렇지도 않았다.

모든 것이 부족한 상태에서 욕망으로 도전했다. 그것이 실패의 원인이었다.