제이제이랩

자바로 웹 프론트 엔드, 백 엔드를 다루시는 분들이라면 필히 스프링의 Dependency Injection은 많이 다뤄보셨으리라 봅니다. 저 같은 경우는 안드로이드 native 개발자로 첫 단추를 풀어서 인지 몇년이 지나도록 DI에 대한 개념과 필요성을 인식하지 못했습니다. 물론 저의 게이름과 안일함 때문이긴 한데요;;;

이전에 벤처에 있을 때 여러 오픈소스를 탐닉하다 RoboGuice를 앱에 적용해 보고 DI 프레임 워크의 편리함을 맛 보았습니다. ButterKnife 또한 사용해 보면서 그 편리함에 감탄했었는데요. RoboGuice가 Guice로부터 파생된 걸 알게 되었고 런타임 도중 reflection의 과도한 사용으로 고질적으로 앱의 성능에 치명적인 단점을 제공하고 있었습니다. 다른 프레임워크를 찾다 Square에서 만든 Dagger를 접하였습니다. 구글에서 Guice를 대체할 DI 프레임워크로 Dagger에 주목하여 지금은 구글 core library team에서 Dagger 2를 주도하여 개발하고 있습니다. 

http://google.github.io/dagger/ [Dagger 2 설명보기]

런타임 Reflection을 완전히 없애고 Annotation processing으로 code generation해서 성능상 문제가 없게 만들었습니다. 모바일, 서버, 일반 자바 애플리메이션 개발에서 쓸 수 있습니다. 저야 저의 샘플앱에 Dagger, Dagger 2를 둘다 적용해 봤지만 지금도 이해가 되지 않는게 많답니다. 아직도 Object graph가 머리속에 그려지지 않네요. 

아무튼 회사에서 제가 드디어 테스트 코드를 짜면서 개발을 하게 된지라.(개발 6년차인데 지금 짜고 있습니다;;) 이전에는 샘플 프로젝트에 먼저 만들 코드 작업하고 실행시켜보고 이상이 있나 없나 검증한뒤에 실제 앱 코드에 적용하는 방식을 썼었습니다. QA팀에서도 버그가 걸러져 나오고 이러한 방식에 익숙하다 보니 앱 개발하면서 unit test, instrumentation test 코드 작성에 대한 필요성을 많이 못 느끼고 있었죠. 그 시간에 요구사항 개발하기도 바쁘고 현재 앱의 수많은 버그 잡는데 더 시간을 쏟겠다라는게 기본 철학이었죠. 현 회사에서 앱 시작 속도 개선이라는 메이저급 변경을 하면서 사이드 이펙트가 상당히 크게 나고 긴급 배포 2번이나 하면서 이대론 안되겠다 테스트 코드밖에 답이 없겠구나 절실히 느꼈습니다;;

그래서 이번에 저에게 떨어진 일은 junit4, hamcrest, mockito, robolectric, espresso 기반으로 테스트 코드를 작성하면서 진행하고 있습니다. 그러다 보니 진정한 테스트 가능한 앱 코드를 만들기 위해 기존 회사앱에 Dagger 2를 적용시켜야할 필요성이 생겼습니다. 그런데 제가 오픈 소스를 적용하면 귀찮은 일을 해야 합니다. 왜 이 오픈 소스를 적용해야 하는지 팀원들한테 설득시켜야 하는데요. 처음 입사해서 몇번 했는데 제 시간 쏟으면서 발표자료 만들랴 일도 하랴 너무 귀찮습니다. 그리고 이번에 인사 평가가 나왔는데 기대한 것보다 실망스러워서 회사에 대한 애정도 없어진 터라 더 이상 발표 같은건 아예 안할 작정입니다;; 아무튼 Injector가 필요한데 Dagger 2를 앱에 녹이면 귀찮은 일이 생길것 같아서 아주 단순한 Injector를 만들어야 겠습니다. 앱 뿐만 아니라 SDK를 만들때도 이 단순한 Injector를 사용하면 괜찮겠다는 생각이 드네요. 

생각해보니 SDK 개발할 때 Dagger 2를 사용해도 될지 의문이 들고 아주 간단한 Injector를 하나 만들어서 두고두고 써 먹으면 제 실력도 향상되고 재밌을것 같습니다. 그래서 JSR 330(https://jcp.org/en/jsr/detail?id=330)을 준수하는 Injector를 만들까 합니다. GitHub 페이지만 만들었네요. https://github.com/jayjaylab/syringe 별생각없이 주입하는거니까 syringe라고 이름지었습니다. 시작을 해야 하는데 이것저것 하느라 진행을 못하고 있네요;;