프로젝트 회고1

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

 

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

 

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

 

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

 

OS 및 연동

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

 

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

 

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

 

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