2015-04-10 11:20:28 from blog.hazard.kr

지금 닷넷 하고 있지만 얼마 지나지 않은 자바 개발 시절 얘기다.
나는 자바스크립트의 비동기 패턴에 익숙했다.
그래서 가끔씩 이벤트 패턴을 사용하기도 한다. 웹인데도.
하지만 공통팀 개발자로부터 태클이 들어왔다.
Anonymous Class 사용을 하지 말라는 거다. 유지관리가 어렵다는 이유에서였다.
나는 어이가 없어서 따졌고, 프로그램도 문제없이 돌아가는데 대체 왜냐고 물어봤다.
결국 최종적인 답변은 듣지 못했으나, 한가지 단서를 발견했다.
원래 자바는 익명 클래스를 만들면 해당 클래스에 $숫자 가 추가된 파일을 생성한다.
아마 그가 걸고 넘어지려는게 그 파일이 아닌가 생각했다.
왜냐면 그 달러 파일 안넘기면 당연히 런타임 오류가 나서 프로그램이 동작하지 않으니까.
개발환경에서 멀쩡히 돌아가는게 가운영서버에서 안돌아가는 케이스 되시겠다.
Jenkins 쓰지만 운영 배포는 따로 관리를 통해 수동으로 배포하고 운영한다.
결국 얼마 지나지 않아 나는 익명 클래스 빼고 길고 긴 Procedural style 로 코딩할 수밖에 없었다.
야근했다. 그날. ㅅㅂ.

자바 SI 하면서 정말 힘들었다. 튀는 개발은 받아주지 않는다. 당연하겠지만.
게다가 정부부터 전자정부 강제로 쓰게 만드는데 뭐 그건 좋다 이거야.
하지만 확장성이 부족하고 (어려움) 틀 안에서만 개발해야 한다.
이래놓고서 대량 트랜잭션을 바란다. 미치겠다.
물론 불가능한 건 아니다. 단지 빡셀 뿐이다.

자바는 원체 동기와 비동기 유연하게 돌릴 수 있다. Quartz를 통한 스케줄링을 사용할 수 있다.
특히 웹에서 그 진가를 발휘하지만 역시 GC와 메모리 문제로 따로 돌리는 경우가 대부분이다.
닷넷의 경우 이벤트 지원이 확실하기 때문에 비동기 프로세스를 자바보다 더 간결하게 구성할 수 있다.
그러나 ASP.NET의 경우에도 웹 앱에 스케줄링 걸면 뻑나가기 때문에 따로 빼거나 COM+ 돌린다.
여기서 웹상에서는 자바가 ASP.NET 보다는 스케줄링 작업이 잘 되긴 하지만 둘다 결과적으로 메모리 관리는 쉣이다.
둘 다 웹에서 비동기 스케줄링 걸 수는 있지만 메모리 관리 측면에서는 올바르지 않은 방법이다.
하지만 비동기만 쓴다면 나쁜 선택도 아니다. 사실 관점지향개발(AOP)도 비동기의 한 부류이기 때문이다.
이벤트 돌리니까 말이지. 하지만 그렇게 생각 안하나보다. 게다가 AOP조차도 잘 안쓴다.
비동기 개발에 능한 자바 개발자는 이벤트를 효율적으로 운영하는 방법을 찾는 데에 열중했고,
그 과정에서 발견한 프레임워크가 바로 Akka 이다.

하지만 SI 출신 개발자들은 이런 방식의 코딩을 능멸하는 것 같다.
여전히 많은 개발자는 Procedural style 의 코딩을 즐긴다. 객체지향? 그건 클래스에나 통하는 거고.

당연히 전통적 방식에 익숙한 자바 개발자들이 아는 범위 내에서 문제 없이 코딩해야겠는데 어쩌겠는가.
절차지향이 아무래도 보기에는 좋으니까. 무조건 순서대로 처리하니까 말이다.
게다가 가능하면 절차대로 수행하는 게 프로젝트 면에서 안전빵이라 생각하고 있을 것이다.

하지만 요즘은 달라졌다. 코어 수는 늘어났고, 더 많은 작업을 더 짧은 시간에 해내기를 요구한다.
게다가 코어 수가 늘어난 것도 엄청 오래됐다. 전통적인 싱글 코어에 맞춘 프레임워크는 멀티코어를 자동으로 해결해주지 않는다.
그 어떤 언어라도 마찬가지다. 더 많은 작업을 더 빨리 작업하려면 개발자가 생각하고 잡아주고 코딩해야 한다.
그런 측면에서 Procedural style 코딩은 이에 한계가 있다.
자바와 닷넷이 아무리 멀티코어를 지원한다 해도, Procedural style 코딩은 결국 하나의 쓰레드만 쓰는 꼴이니까.
프레임워크가 알아서 필요하면 쓰레드 잡고 간다고 편안하게 생각한다면 그건 개발자의 자질이 글러먹었다.

그런 측면에서 병렬 처리는 많은 작업을 짧게 해내는 데 유용한 기능을 제공한다.
자바 닷넷 둘 다 제공하거나, 부족할 경우 채워주기도 한다.
하지만 아무리 커다란 프로젝트라도 여전히 이를 만족하는 개발은 없다. 본적도 없고.
공공데이터 시스템 빼고는. (이는 병렬처리 안하면 뻑나가는 구조임)
특히 금융권 개발은 이를 잘 반영 안하고 있다. 대부분 DB 프로시저에 익숙한 탓이기도 하다.
그리고 이를 개선할 생각도 없고 개선하려 해봤자 눈먼 돈만 나가고 결국 실패하고.

이 병렬 처리를 하려면 개발자가 갖춰야 할 기본 자세가 바로 비동기이다.
왜냐면, 병렬 처리는 동시에 이루어지기 때문에,
Procedural style 로는 동시에 누가 먼저, 나중에 시작 후 끝나는지 캐치할 방법이 없기 때문인 데다가,
Procedural style 은 싱글 프로세스이기 때문에 애초부터 접근할 방법이 없다.

비동기의 장점은 꽤 많다. 물론 비동기도 Procedural style 에 비해 단점도 있다.
특히 비동기는 작업 중간중간을 캐치할 수 있다는 크나큰 장점이 있다.
예를 들면, 1분 이상 걸리는 무거운 쿼리를 요청한다고 가정해보자.
Procedural style 로 하려면 이 쿼리를 마냥 기다려야 다음 작업을 진행할 수 있다. 과정보다는 결과가 우선시되는 작업이다.
하지만 비동기로 하면 이 무거운 쿼리가 성능에 어떤 영향을 미치는지, 이에 실패하면 어떨지 등 여러 경우를 캐치할 수 있다.
이는 결과와 과정을 둘 다 캐치해낼 수 있는 작업인 것이다.
그걸 잘 반영한 자바 프레임워크가 바로 Akka 이다.
하지만 그거 쓰는 자바 개발자들이 얼마나 있을까. 특히 SI 말이다.

Akka 가 이젠 닷넷 개발자도 배려해 주었다. 이런 비즈니스 요구를 잘 반영한 Akka를 말이다.
아. 생각해 보다 닷넷 개발자도 자바 개발자와 다를 거 없다. 둘 다 절차적 스타일에 따른다.

나는 이 글을 쓰는데 비동기를 강조하고 Procedural style 을 까내리려 하는 것은 절대 아니다.
Procedural style 은 당연히 피할 수 없는 코딩 구조이다.
하지만 나는 필요시 비동기 스타일을 권유하고자 글을 쓰는 것이다.
굳이 대안을 작성하자면, 비동기 개발 좀 하라고. 끝.

SI가 정말 한국 개발의 발전을 저해시키고 동결시키긴 했다. 나도 이런 답답한 개발에 지겨우긴 했다.
하지만 그렇다고 나를 받아주는 곳도 없다. SI에서는 튀고, 그렇다고 선진개발자에게 SI경력은 Procedural style 중점의 개발자로 낙인찍히니.
나는 이렇게 본의아니게 어정쩡한 개발자가 되버렸다.
뭐. 아무렴 어때. 이제부터 중요한 것은, 내가 직접 보여주는 수밖에.

어떤 패턴을 쓰던 나는 존중한다. 하지만 그 패턴만 고집하는 행위는 옳지 않다.
그런 사고방식이 전에 자바 개발했을 때 개발자의 사기를 떨어뜨렸다.
그래서 나는 어떻게 개발하던 존중해달라고 하고 싶어서
이런 뻘글 썼다.

아. 한가지 첨언하자면 Akka는 스칼라로 만들어졌지만 자바로 개발 가능하니 스칼라 태클 걸지 않도록.
자세한 소개는 Akka 로 한국어 웹 검색만 해도 좌르륵 나온다.