개발지식 정리 및 인생회고 블로그

 이전에 개발한 소프트웨어를 문서화하였다. 프로토콜에 대한 정리를 다른 회사와 공유하고 팀내에서 협업을 위해 사용하고자 함이다. 대외적으로 공개 할 수도 있는 문서니이 양식은 좀 신경쓴거같다. 용어 정리, 통신 흐름도, 아키텍처 구성 ..

 공유하고자 하는 문서에는 어느 내용이 들어갈지도 되게 중요하다. 우리 회사 소프트웨어 자체적으로 쓰이는 로직도 넣을지 외부 통신하는 로직만 넣을지... 팀 내에서는 어떤방식으로 프로토콜을 만들지 논의한다.

음 ... 여러 방식이 있는데 무조건 내주장을 내세우진 않았고 일부러 이런 방식을 생각한다고 떠 보았다.. 조금은 RestFul한 방식으로 설계하고자 미리 생각했는데 팀원분 코드를 보니까 원하는 방향으로 되진 않아서 떠 본 것이기도 했다. 

"난 항상 이런식으로 개발했어~" 라는 말에 바로 상대가 원하는 방식으로 바꿨다. 이왕이면 서로가 알고 있는 방식으로 개발하면 좋다고 생각했다. 

 문서를 만들 때는 귀찮았는데 만들고 나니까 오히려 업무 소통도 명확해지고 상대가 크로스 체크 해주면서 문서 오탈자도 잡아주고 좋았다. 또한 업무 의존성 분리가 가능했다. 한 쪽이 기능개발 + 문서화 해놓으면 다른쪽에서 이후에 그대로만 따라하니까 업무 진행이 편했다. 

 이전에 문서화를 대충 해놓았더니 그 문서가 버려지고 오히려 코드로만 업무 소통이 된 적이 있었는데... 

이번에는 뭔가 달랐다. 문서화의 필요성....!

 개발할 때 일관성을 유지하는 것은 매우 중요하다. 

 어디서 일관성을 지녀야 하냐면  DB테이블, 컬럼명 작명 스타일, 함수 작명 스타일, 프론트쪽에서 attribute 작명 스타일, 예외처리 방식, 스프링 서버코드 작성 방식 등 이런 모든 것들은 일관성을 지녀야하는 부분들이다. 어떨 때 어떤 방식으로 코드를 짤지 다 패턴화되어 있어야 한다. 현재 진행하는 프로젝트에선 이게 제대로 안되어 있으니 매번 코드가 바뀔 때마다 고치고 고민하느라 고생좀 했다. 애초에 일관성을 가져야 겠다는 생각을 하지 않으니 그때 그때마다 할 수 있는 생각이 다르고 나도 모르게 일관성이 많이 흐트러지게 되었었다.

 고민할 시간을 줄여서 일관성을 갖추게 되면 개발 시간도 줄어들고 협업을 하거나 또는 내 코드를 인수인계 받는 사람에게도 좋다. 입사 초에 전임자가 해놓고 간 코드에서 고통을 받았던 적이 있다. 여러 사람의 코드가 섞여 있지만 일관성이라고는 전혀 없는 코드, 따로 노는 느낌의 코드였다. 하지만 그때는 그것을 내 스타일 대로 고치려하지 않았다. 코드의 당위성이나 효율성은 그다지 없던 코드.. 그리고 뭔가 구현하다 말은 코드... 업무를 모르고 구현한 코드 등 ..

 최근 그 전임자의 스타일이 묻은 프로젝트에서 나와서 내 프로젝트로 다시 만들었다. 내가 처음부터 다시 만들면 뭔가 다르겠지라고 생각했는데 일관성이라는 것을 갖추는게 좀처럼 쉽지가 않았다. 

 여태까지 많은 일들이 있었다. 올초에 했던 프로젝트는 기능동작의 프로토타입을 만들고 한 사이클의 시연을 하고 

 해당 기능이 개발이 가능하다는 것을 보였다. 그 후 부터는 사람들이 같이 붙어서 이것 저것의 기획 또는 디자인이 추가가 되었다. 

 다른 사람들과 함께 일하는 순간부터는 문서작업이 많이 추가 되었다. 일정관리는 정말 중요했고 그 과정에서 많은 커뮤니케이션이 필요했다. 서로의 업무 우선순위를 체크하고 언제 그것이 가능한지 조율하면서 목표일정을 맞추는 것이 중요한 과정이었다. 

사실상 개발 자체는 빨리 끝나도 이런 문서작업이 정말 많은 시간을 잡아먹었다는 아쉬움이 있었다. 근데 이것도 익숙해지면 엄청 빨라지겠지.. 

OS 및 연동

작년에도 많은 고민을 했었지만 개발상에는 여러 문제점과 제약사항들이 많았다... 개발서버가 따로 없었고 개발환경 구축의 어려움 등이 있었으나 Docker 컨테이너 안에서의 빌드환경 구축으로 개발이 가능했고 연동에 있어서의 문제는 굳이 JNA나 JNI로 무거운 알고리즘 로직을 직접 돌리는 방법보단 해당 프레임워크에서 제공하는 연동 로직을 사용하였다. 실제로 자바 서버로직에서 무거운 dll 알고리즘을 돌리는 것은 엄청난 부하를 가져와서 절대 하면 안되는 것이라는 것을 느꼈다. 그래서 dll 알고리즘 단의 로직은 서버와 별도로 분리된 서버로직에서 돌아가게 해야한다. 이를 자바스프링 서버에서 interface를 만들어서 웹소켓 통신을 하고 c++ 서버로직에서 그것을 처리한다.

 알고리즘 개발자분이 윈도우 개발자이셨고 만든 알고리즘이 dll로 만든 것이기에  리눅스 서버 운용환경에 맞추기 위해서 so파일로 뽑아지게 변경하였다. 이 과정에서 해당 객체에서 메모리 누수가 나지 않도록 객체 동작 라이프사이클을 자바서버쪽에서 컨트롤 할 수 있게 맞추었다. 타이머, 유저 인터렉션 등의 이벤트가 있어서 스레드를 써야 하는 부분 등이 있었고 만일 해당 객체가 도중에 죽게 되면 스레드 또한 잘못하면 자원회수가 안될 수 있는 이슈도 있었다. 그래서 메인 동작 객체의 소멸자 부분에 스레드 자원회수하는 코드도 넣어서 자바쪽에서 혹시나 통신이 끊기면 해당 객체를 제거해서 밑에 딸려있는 메모리도 해제한다. ( 이 당시 스레드의 개념은 얼핏 알고 있었으나 뭔가의 필요성에 의해서 실무에는 처음 적용해보았고 다음 프로젝트에서 리뷰하던 코드에서 스레드를 사용하는 상황이 나의 상황과 비슷한 점을 확인함... )

 아키텍처 구성도 많은 고민이 있었다. 알고리즘 개발자분이 하는 말로는 해당 기능을 처리하기 위해서 반드시 어플리케이션 자체가 분리 되어야 한다는 얘기를 해주셔서 또 다른 기능은 다른 서버에서 돌게하였다. 웹서버 로직에서 A서버(C++), B서버(Python)를 사용하는 MSA 구성인데 이 작은 기능을 구현하기 위해서 이렇게까지 하다니 현타가 오기도 했다.... 업무의 범위가 매우 넓기도 하였다. 언어만해도 java, javascript, c++, python에 프레임워크도 이것저것... 

 처음 계획했던 것은 고도화 느낌의 작업도 할 생각이었다. 그런데 도중에 다른 프로젝트로 붙게 되어서 고도화쪽은 나중에 할것같다.. 그 때 되면 엄청 힘들어지겠지? 

java라는 언어는 jvm 기반으로 동작하기 때문에 OS가 다르더라도 돌아간다. 하지만 java라는 언어만 사용해서 개발하면 좋겠지만 현실은 그렇지 않다. 연산량 많은 알고리즘이나 자바가 아닌 특정 언어에 특화되어서 어떤 기능을 제공하는 경우 다른 언어를 자바에서 써야 한다. 예를 들면 영상처리 알고리즘이나 누군가 구현한 암호화 알고리즘을 자바에서 쓰는 경우가 많다. 그런 경우에는 자바에서 다른 언어의 동적 라이브러리를 load해서 사용할 수가 있는데 이 경우에 자바 언어 자체의 단점을 보완하게 된다. 

가장 큰 문제는 OS를 고려하여 빌드된 파일을 따로 가져야 한다는 것이다. 즉 빌드된 동적 라이브러리 형태가 OS마다 다르기에 배포 환경에 따라 라이브러리를 맞춰서 빌드해야 한다는 것이다. 요즘은 이런 번거로움에 대한 해결책이 나와서 윈도우도 wsl을 지원하지만 그것이 없던 시절에는 aws ec2에 리눅스 환경을 따로 마련하거나 듀얼 부팅으로 개발을 하던 시절이 있었을 것이다. 물론 wsl도 온전한 리눅스 환경을 그대로 제공할지는 의문이다. 

단순히 윈도우 개발자들 기준에서는 별도의 리눅스용 빌드된 파일이 필요가 없겠지만 웹개발자들 기준에서는 대부분 리눅스에서 배포하기 때문에 리눅스용 빌드된 파일이 필요하고 빌드 방법을 알아야 한다. (아니면 그것을 아는 개발자가 따로 있거나..) cmake를 사용해서 딥러닝이나 opencv 소스 빌드를 하는것이 블로그에서 보면 명령어 몇 줄 입력하는 걸로 보여서 간단해 보이지만 사실 그거 하느라 하루 꼬박 날리는 경우도 있으니 돌아버릴 노릇이다.

그렇지만 배워두면 좋은 기술인데 뭔가 현재로선 압박감이 있다. docker라는 기술은 이에 대해서 좋은 제안을 하지만 이러한 것들을 잘 다루는 사람들만 보던 시니어들은 왜 이걸 바로 못하는지에 대해 눈치를 준다는 느낌을 받는다. 환경셋팅하는데만 왠종일 걸릴 것으로 예상되는데 왜 아직도 개발의 윤곽이 안나오는지는 많은 고민이 있는 것이다.. 

회고

회사에 들어온지는 좀 됬는데 입사하고 나서 제일 중요했던 일정 하나가 저번달에 마무리 되었다.

정부과제 평가였는데 평가 하루 전날까지 애매한 기능을 손 보느라 재배포 하는 과정을 수없이 반복했다. (Jenkins를  써보고 싶었으나 그 때는 t2.micro 계정이라 Jenkins 쓸 여건이 나진 않았다. 근데 지금 클라우드 리소스는 넉넉함) 해당 업무는 처음 써보는 라이브러리와 처음 해보는 업무 도메인이다.

Back 단에는 그렇게 많은 코드가 필요하진 않았고 Front단 기능 동작 부분에서 많은 시간을 할애하였다. 클라이언트 단에서 UI 디자인 쪽은 딱히 내가 관여한 것은 없으나 화면단 인터페이스 정의와 기능 동작이 굉장히 중요했다. 

프로젝트 자체는 전임자에게 받아서 진행하는 상태이고 같이 하는 분도 계시고 기획도 이미 정해져 있어서 그렇게 업무 강도는 빡쌔진 않았다. 빡새게 하려고 작정했으면 더 많은 기능을 넣을 순 있었겠지만 굳이 그렇게 하지 않아도 됬다.

기능을 구현하는 것도 고통이지만 어떻게 구현할지 계획하고 무슨 라이브러리나 어떤 기술을 쓸 것인지 상급자와 협의하는 것도 중요했다. 구현없이 뜬구름 잡는 계획으로만 구성된 ppt 보다는 기능 구현을 해보고 어느정도 윤곽을 보여주는 것을 좋아했다.

단순히 기능만 돌아가는 것만 중요한 것이 아니었다. 이 기능을 논리적으로 어떻게 동작시킬지 정의하는 것도 굉장히 골치아픈 문제였다. 회사에 기획자 분이 계시긴 하는데 그 당시에는 없었다. 

그래서 테스트 시나리오 라는 것을 만들었다. 해당 업무 도메인에서 이 소프트웨어 사용시에 어떠한 방식으로 사용할 것인가를 다룬 UseCase 문서 느낌인데 나름 기능에 대한 정리가 잘되고 그걸 보면서 내 기능이나 UI도 수정하고 또한 남들에게 제시할만한 좋은 문서가 된다. 

평가는 잘끝났다. 좋은 평을 받긴 했는데 많이 그래도 부족하다고는 생각한다. 

새로 구상하는 것을 위해 이제 또 다른 일정을 시작했다. 가능성을 일단 계속 구상하고 길을 만들어 가야 하는데 업무 영역이 매우 넓어서 쉽게 트라이가 되진 않는다. 또한 기술적으로 "이제 왜 안되? 그냥 하면 되나?"하고 로직을 만들려고 하면 또 다른게 걸리는게 많다. 그래서 요즘 대부분의 시간을 공부하면서 어떻게 하면 되게 할지의 방향을 잡는데 많은 시간을 보낸다. 

잡생각들

기록

Notion에다가 다시 기록을 시작했다. 원래 강의 들었던 것을 word에 기록했는데 365 기한이 끝나버려서 Notion에다가 땜빵으로 쓰고 있었는데 계속 쓰다보니 워드보다 좋았다.. 특히 Backup 기능이 있어서 삭제한 파일 복구가 가능한게 인상 깊었다. 지금은 물론 회사 ms365 계정을 받았지만 ppt 만드는거 아니라면 거의 Notion에서 주로 공부했던 것을 기록한다. 

InteliJ

무겁고 불편한 sts에서 벗어나서 InteliJ ultimate 버전을 사용하기 시작했다. 다양한 플러그 인과 툴 자체도 덜 무거워서 갑자기 sts처럼 팅기는 일이 없어졌다. 작업하는 것에 있어서 많이 쾌적해졌다. 최대한 다양한 기능을 써서 기록해서 정리할 예정이다.

S/W 아키텍처

최근 프로젝트 하나를 새로 만들 일이 생겨서 이전에 패키지 구조를 고민하다가 스프링 코드에 관련해서 아키텍처에 대한 유튜브 강의를 많이 보게 되었다. 일반적으로 우리가 많이 사용하는 레이어 아키택처와 도메인 별로 나누는 도메인 아키텍처, 그리고 요즘 유행하는 클린 아키텍처 등에 대해서 공부하였다. 사실 이걸 공부하게 된 이유도 어떤 시니어 개발자분이 프로젝트를 클린 아키텍처로 새로 만드는 것을 유튜브로 보고 난 후 였는데 공부를 하고나니 이것을 굳이 쓸 이유가 없다는 것으로 결론이 내려졌다. 내 프로젝트와는 맞지 않았다.

TDD/Rest Docs

남들과 협업을 한다거나 문서로 기능 명세서를 남겨야 하는 상황이 많다. 기존에 몇몇 프로젝트는 그러한 명세를 엑셀에다가 일일히 수작업으로 했었다. 하지만 이러한 수작업으로 기록하는 것도 만약에 코드가 변경되면 그것에 맞추어 문서도 수작업으로 따라서 변경해야하는 단점이 있다. 그러한 상황을 위해 실무에서는 Rest Docs나 Swagger를 많이 쓴다고 한다. API 문서 자동화 라이브러리인데 API 명세를 코드가 자동으로 만들어주는 것으로 웹페이지가 자동으로 만들어지고 그것을 보면서 협업을 한다는 그림이었다. Swagger와 Rest docs 이 두개가 많이 알려졌지만 동작 난이도는 Swagger가 낮으나 배포코드가 지저분해진다는 단점으로 Rest docs를 많이 쓴다고 한다. Rest docs의 단점이 있다면 테스트 코드 강제하는 형태로 되어 있어 나름 귀찮을 수도 있다는 것이다. 하지만 이 기회에 앞으로 TDD로 코드 짜는 습관을 익혀두면 좋을 수 있다. 그 전까지는 왜 TDD로 짜야 하는지에 대한 뚜렷한 명분이 없었으나 Rest Docs 를 위해서라면 나름 훌륭한 명분이 될 것이다. 

Docker/Kubernetes/Kafka/Redis 

나중가서는 꼭 알아야 하는 부분이다. 개발한 프로젝트에 dockerfile을 작성해서 환경울 구성해야 하고 docker Compose로 db와 다른 어플리케이션 단을 연결해야 한다. 쿠버네티스 쪽은 사내 프로젝트에 관련된 것을 하고 있어서 어떻게 돌리는지에 관한 것은 꼭 알아야 한다. Kafka도 주변에서 알아야 한다고 말은 해준다. 요즘 github에서 남들 프로젝트 하는거보면 죄다 Redis쓰는데 Kafka 비슷한거라고 검색하면 나오긴 하는데 왜 쓰는지는 나도 좀 알고 싶다. 

강의를 열심히 듣자

8, 9, 10 월 달에는 강의를 많이 못들었는데 최근에는 과거에 등록해놓았던 인프런 강의를 하나씩 격파하려 하고 있다. 정말 배울 게 많다. 클라우드, 프론트, 백엔드, 인프라, CI/CD 등 .. 

 어느덧 회사에 들어온지 두 달 가까이 되었다. 전혀 생각지도 못했던 회사로부터 입사 제의를 받고 1차 면접에서 2차 면접까지 속전속결로 진행되어 바로 그 다음주에 입사하게 된다. 입사 후에는 그동안 블로그를 하지 않았다. 약간 게을러진 것도 있었고 내가 생각했던 방향과 개발자로서 가져야할 마인드 셋이 달랐었기 때문이다. 

 입사 초반에 사무실에 들어오자마자 새 PC 하나를 받았다. 환경 셋팅하는거 좀 오래 걸리고 번거로운 일이라는 것을 그 때 또 다시 깨닫는다. 이클립스 sts는 뭐이리 불편한건지, 자바는 무슨 버전을 설치해야 하는지 DB는 뭘 설치해야 하는지 등의 이슈가 있고 워드나 오피스 등을 설치하는 것도 나름 시간이 걸렸으니 말이다. 받은 pc가 속도도 너무 느려서 이것저것 문제를 검토해보니 HDD에 OS를 설치해놔서 그랬다. 그래서 SSD에 OS를 재설치 하는 과정도 거치니까 하루가 갑자기 끝나 있었다..

 우리회사는 딱히 맞사수가 있는 그런 회사는 아니다. 각자 자기할 일 잘 맡아서 하는 방향으로 업무는 진행된다. 동료 한분이 많은 조언을 해주었다. 내가 신입이라고 하니까 개발자가 가져야할 마인드셋부터 시작해서 본인이 어떠한 회사들을 거쳐왔는지 등 이야기 해주시고 먼저 말씀해주시진 않았지만 내가 귀찮게 캐물어서 어떤 코딩 스타일을 선호하는지, 어떤식으로 코드를 짜야 하는지에 대해서도 대답을 들었다. 

 사수가 없다보니 초반에 나름 방황할 수가 있는데 신입 때는 뭘하더라도 크게 터치를 받지 않는다는 것을 이용하여 새로운 디비 공부나 신버전의 스프링 배치, 시큐리티 등을 공부하면서 신입한테 주는 숙제를 했다. 다행히도 업무 자체가 내가 기존의 알던 것들과 크게 다르지 않아서 새롭게 공부할 것이 많지는 않다. 그것도 오래하는 것을 원치 않아하는 분위기여서 일주일 정도하고 pass 하였다. 그 과정에서 대표님의 많은 가르침이 있었다. <- 생략 ->  그러고 실무에 들어가게 되었다....

 그러면서 회사생활을 하다보니 문득 어떤 개발자가 좋은 인재인가라는 생각도 하게 된다. 지금은 아래와 같은 생각을 하고 있다. 

 회사에서는 어느 정도 단순히 어떤 지식에만 매달려서 공부하고 카피하는 것이 아니라 본인의 생각으로 구성하고 방향성을 의논할 개발자를 원한다. 세상이 많이 좋아져서 요즘 개발할 때 chatgpt를 많이 쓰게 된다. 단지 "코드를 구현해줘"의 차원이 아니라 이 코드가 좋은 코드인지, 어떤 구성으로 코드를 짰는지, 그리고 라이브러리의 사용법을 익히는 차원에서도 많이 쓰게 된다. 과거보다 학습속도와 개발속도가 매우 빨라진 셈이다. 물론 백그라운드도 많이 아는 것을 좋지만 단지 그것만이 주가 되면 안되고 그것을 이용해 어떻게 활용하고 문제를 다루고 그림을 그릴지가 주가 되어야 한다. 

그래서 예를 들자면 단지 "나 리액트, 뷰, 스프링 잘해요." 라고 어필해서 세부 사용법에 대해 논하는 사람들보단 사내 프로젝트에서 어떤 문제를 접하고 그 과정에서 어떠한 생각을 가지면서 그 문제를 해결했는지에 대한 주관이 있는 개발자가 빛을 볼 수 있다는 것이다. 

 개발자라는 직업이 아이러니 한게 주말에도 공부를 하지 않으면 현재 업무에 매몰되어서 트랜드에 뒤쳐지는 일이 쉽게 일어난다. 공부라는 것이 개발자에겐 숙명이다. 하지만 취준 때 처럼 목적성 없이 단순히 해당 도메인을 익히려는 공부보단 이제는 응용의 측면에서 학습을 해야 한다고 생각한다. 

 강남의 어느 회사의 면접을 보았다. 이번엔 회사에 대해서도 조사를 해보고 업무 도메인에 대해서도 알아보는 등의 준비를 많이 해갔다. 기업 유튜브, 블로그, 잡플래닛에 있는 기록을 모두 정리해서 예상 답안을 만드는 등 어떠한 기술적인 질문이 나오더라도 준비를 다 해놓은 상태이다. 걱정되는 것은 처음에 1분 자기소개 부분에 약간의 긴장으로 인한 떨림을 제어하는게 어렵다는 것이었다. 물론 내가 떨면 옆에 있는 지원자도 떨리니까 이건 주변 사람들에게도 민폐이기도 하다. 또한 코로나 후유증으로 인해 생긴 기관지염은 잦은 기침을 하게 하여 질의응답 하는걸 걸리적 거리게 하는 것도 걱정이었다.

 면접은 이번엔 지원자 3인, 면접관 2인의 그룹면접으로 진행되었고 기술면접과 인성면접이 동시에 진행되었다. 오히려 이날 느낀건 그룹 면접이 더 재밌었다는점이다(???). 반면에 옆에 지원자들은 나보다 어린 친구들이었는데 매우 절실해보이고 초조해 보였다는점...(오히려 나보다...)  그리고 모두 학원을 수료한 친구들이다. 질문의 난이도는 그렇게 높진 않았다. 인성면접도 나름 평범하고 솔루션 직무이다보니 아마도 학원에서 배우지 않은 것을 새롭게 배워야하니 그 걱정에서 나오는 질문을 한분께서 주로 하셨다. 또한 다른 한분은 배움의 중요성을 강조하는 분위기였다. 퇴근 후에 무엇을 공부할 건지에 대한 내용도 있었고 프로젝트 질문으로 가서는 좀더 기술적인 측면으로 질문이 좁혀져서 일부로 특정 기능 부분을 구현해 보았냐고 물어보셨다.

 그 질문에 한 친구는 구현하지 않았다고 답했고 다른 친구에게도 그 친구가 구현하지 않은 기능을 일부러 물어보는 눈치였다. 나는 그 두 질문에 대해서 이미 해답을 가지고 있는 상태였는데 나에게는 일부러 물어보진 않았다. 나는 적당하게 프로젝트에 대한 나의 역할을 대답하였고 나 같은 경우엔 TMI식으로 조금 장황하게 풀어서 얘기하는걸 약간 줄여서 얘기해달라는 눈치를 받았다. 그래도 최대한 열의를 가지고 대답은 했는데 다음부터는 정리를 잘해서 요점만 말해야 겠다는 생각을 했다. 면접 내용은 이래도 그렇게 압박 면접은 아니었다. 나름 좋은 분위기속에서 진행되었고 두분다 친절하게 회사에서 무엇을 하는지 등, 회사에 대한 궁금점 등을 답해주셨다. 이것도 나름 좋은 경험이었다. 이전 면접에서는 프로젝트 얘기 할 때 오히려 면접관님들이 기술적인 측면은 안물어보셨고 이번에는 기술적인 측면을 주제를 좁혀서 물어보셔서 대답할 기회가 됬다. 또한 이전에는 성과만을 중요시 하는 면접관님들 이었다면 이번에는 조금은 달랐다. 배움과 성장을 중요시 하는 분들이었는데 이분들 밑에서라면 정말 열심히 일하고 싶다는 생각도 하였다. 

 면접이 끝난 날부터 다음날은 기침 증세가 다시 나타나서 약먹고 자고 약먹고 자고 그냥 이틀이 삭제되었다. 사실 그날 결과가 나올 줄 알았는데 그렇게 빨리 나오진 않았다. 오늘 아침이 되서야 결과를 받긴 했는데 기대와는 달랐다. 

결과는 떨어졌다. 뭔가 다른 관점이 개입되었던 것 같다. 대답은 나름 잘한 것 같았고 준비도 잘 해간 느낌이었는데 무엇이 나를 뽑는 것을 망설이게 한 것인지는 모르겠다. 어떤 기준일까? 무엇을 준비해 가야할지 모르겠다. 한편으로는 좀 더 열심히 준비해야 한다는 생각도 한다. 이대로 좌절하기보단 다른 기준이 개입될 수 없도록 확신이 서도록 준비를 할 필요성이 있다고 느꼈다. 코딩 테스트 준비도, CS 지식 준비도, 사이드 프로젝트도, CI/CD쪽 공부도.... 

 특정 인터넷 강의사이트에서 자바 알고리즘 강의를 결제하고 수강하고 있었다. 해당 사이트는 특정 날짜가 되면 강의를 오픈하는 형식으로 구성이 되어 있는데 전체 강의를 모두 오픈하기도 전에 비싼 강의료를 받고 사전에도 강의를 판매하고 있다.

이 강의가 올해 초부터 사전예약을 받고 판매하고 있었는데 타사의 강의보다 매우 비싼편에 속해서 학생들 보단 직장인들이 많이 듣는다. 나도 이걸 이전부터 듣고 싶었으나 시간이 없어서 못듣고 최근에 일주일 전에 막 결제를 했고 이제 마지막 강의가 오픈된다고 들떠 있었는데 갑자기 메일 한통을 받았다. 

해당 강사님이 건강상의 문제로 인하여 강의마지막 파트를 공개할 수 없다는 점과 오픈 일정을 2달가까이 연장시킨다는 점이었다. 심지어 강사가 교체된다는 말은 정말 최악이었고 보상절차가 바로 이야기가 안나온점은 조금은 많이 황당하게 하였다. 이러한 대처에 많은 항의를 받아서 그런건지 3일이 지나서야 나름 만족할만한 보상이야기가 나왔다.

 모든 프로그래밍 강의를 대략 3달정도 기간제를 들을 수 있는 이용권이 지급되었다. 놀랍게도 진짜 평소에 듣고 싶었던 강의가 모두 포함되었으며 뷔페식으로 무제한으로 모든 강의를 들을 수가 있다.. 지금 들어야할 강의도 많은데 이렇게까지... 되버리니 정말 할게 많아지고 배가 부르다 정말..