프로젝트 직쏘는 희망이 없다?

자바 9가 올해 7월 말 즈음 출시될 가운데 안타까운 소식이 들어왔다.

바로 JCP(Java Commnity Program) 총괄 리뷰에서 프로젝트 직쏘가 많은 반대에 부딪혀 빛을 못볼 위기에 처해 있다는 것이다.
DZone – Java Zone – EC Rejects Jigsaw

직쏘 프로젝트 참여자들은 30일 내에 보완 후 다시 리뷰를 진행해야 하는데,
다음 리뷰에서 실패하면 직쏘는 자바 9에서도 볼 수 없는 시스템이 될 것이다.

프로젝트 직쏘는 익히 알다시피 하여 짤막하게 소개한다. SI/SM 개발자들은 관심없이 1.6 이하 버전이나 쳐 만지겠지만.
현재 자바는 JVM 내에 돌아가는데, JVM이 자바에 있는 핵심 라이브러리 외에도 사용자가 추가한 라이브러리 모두 안고 가기 때문에
성능 문제는 여러 방면에서 제기된 문제가 있었으며, 이로 인해 특히 임베디드 장비에서 자바를 꺼려하는 이유이기도 하다.
그래서 안드로이드 자바는 아예 달빅 등으로 자바를 재구성 해서 안드로이드 전용 자바 환경을 만들었던 이유이기도 하다.
물론 안드도 성능 이슈는 피할 수 없긴 매한가지지만.

어쨌든, 이걸 해결하고자 모듈 시스템으로 필요한 라이브러만 쓰고, 쓰는 곳으로만 최적화하고, 이식 가능(Portable)한 프로그램을 만들기 위해
꾸려진 프로젝트가 JSR 376q번 프로젝트 직쏘다.

하지만 프로젝트 직쏘는 당연하겠지만 많은 반대에 부딪혔다. 특히 이번 반대의 가장 주역이 바로 상업용 리눅스로 유명한 대기업 “레드햇”인데,
프로젝트 직쏘에 대한 문제점을 34페이지를 썼다.

DZone에서 언급한 주요 내용은 아래와 같다.

The patterns introduced within Jigsaw are (in some cases) going to be extremely difficult to fix even in a later release, and will create backwards- and forwards-compatibility problems that will be very difficult to unwind

직쏘에서 제시한 패턴은 이후 자바 출시를 할 때 여러 면에서 거대한 장벽을 유발한다. 그리고 상위, 하위 호환성 측면에서도 난관이 많을 것으로 보인다.

Due to lack of one to one mapping of use cases (or sufficient interoperability capabilities) and other restrictions, we are concerned that there will likely be two worlds of Java software development: the Jigsaw world, and the “everything else” world (Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)

일대일 연계에 대한 문제와 여러 제한 사항으로 인해 우린 자바 개발자들이 직쏘 세계와 현재 자바 세계(Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)를 두가지로 나눠 개발하는 광경을 볼 지도 모른다.

그렇다. 레드햇은 자바의 기본적인 목표인 “하나의 코드를 여러 플랫폼으로”에서 거리가 먼 직쏘에 거리를 둔 것이다.
이외 IBM, SAP 등 여러 거대 개발기업도 반대 의사를 표시했으며, 세계에서 가장 큰 자바 커뮤니티인 런던 자바 커뮤니티는 강한 반대 의사를 표시했다고 한다.
우리가 많이 쓰는 개발 툴 제작사 이클립스 재단도 반대 의사를 표시했다.

물론 찬성도 있다. 자바를 주도하는 오라클, V2COM, 후지쯔 등인데,
후찌즈는 “EC 회원들이 직쏘에 많은 집중을 하는 만큼 다음 투표에서 해결되길 바란다.” 라며 찬성 의사를 표시했다. 그렇다. 실질적인 반대 의사인 것인데 찬성한 것이다.
SouJava 라는 업체는 처음에 찬성을 하다 반대 의사를 표시했는데. 역시 사용자 접근성 결여를 이유로 반대 표시를 한 것이다.

결국 접근성 문제와 여러 제한 사항, 호환성 문제를 이유로 많은 커뮤니티와 업체에서 반발한 것이다.
우려한 대로 말이다.

닷넷 진영에서는 프로젝트 직쏘 때문에 다 갈아엎어야 하는 iKVM.NET 개발을 포기하기로 했고, 자바를 기반으로 한 스칼라나 코틀린에서는 대응이 안되어 있는 상황.
이렇게 준비가 되어 있지 않은데 우린 대체 무슨 희망으로 직쏘를 지지했던 것인가를 다시한 번 생각하게 한다.

내가 보건데 자바 9에서도 직쏘는 보기 힘들 것으로 보인다.
별 거 아닌 것처럼 보여도. 자바 2.0이면 모를까 자바 1.x 에 직쏘를 넣는다는 건 엄청난 변화이고, 기존 자바 개발자들이 한국 SI/SM 개발자처럼 정체된 자바 환경을 접해야 할 지도 모르기 때문이다.
직쏘를 적용하는 순간부터 하위 호환성을 포기해야 하고, 상위 호환성을 걱정해야 하며, 그리고 자바 직쏘에 대한 또다른 지식과 구조를 개발자들이 알아야 하니, 기존 개발자들에게는 큰 난관이 아니 예상할 수 있겠는가.

composite / 2017년 5월 18일 / Piss Development, Waldo Translation / 0 Comments

자바 개발시 Hot Swapping 종류

Java Server Hotspot

  • JDK 설치하면 기본적으로 제공
  • 메소드 내용을 수정한 뒤 재시작 없이 반영
  • 그게 다임. 내용 수정 외의 수정은 모두 재시작해야 함.

jRebel

  • 상용으로 유료 솔루션
  • 자바 코드 어떻게 수정해도 재시작 없이 반영
  • Spring 플러그인에 한해 XML 설정도 재시작 없이 반영
  • 왠만한 WAS 및 환경에서 사용가능 (국내한정 JEUS는 되긴 하지만 공식 미지원)
  • 적은 코드 변경에는 아주 빠른 Reload
  • 변경 코드가 많을수록 Overhead 심각 (이건 어느 솔루션도 못피함. 이건 무조건 재시작삘.)

Spring loaded

  • 무료이며 오픈소스
  • 스프링만 적용 가능 (전자정부는 되겠지 뭐)
  • 스프링 자바 및 XML, properties 변경 시 적용
  • 스프링 외 플러그인 설정파일 변경 지원 안함.
  • 현재 톰캣만 지원. 나머지 WAS 보증불가
  • 몇몇 사용자에서 재시작이 안되는 문제가 보고되고 있음

Spring boot devtools

  • 무료이며 오픈소스
  • Spring boot만 적용 가능 (상속 때문에 일반 spring 적용 불가)
  • spring boot 및 상속 가능한 모든 자바 및 설정 파일 변경 시 적용
  • spring boot 돌아가는 어떤 WAS 상관 없이 지원 (JEUS는 모름)

닷넷커: ㅋㅋ ASP.NET (MVC 포함)은 기본 전체 홧스왑 수준인데 고생한다.
자바커: MS 종속적이고 비싸기만 하며 오픈소스 없는 놈이 말이 많어.
닷넷커: 이제 크로스플랫폼 지원하고 소스는 이미 오픈된지 오래임.
자바커: 그러던가. 어자피 한국에서는 영원히 잊혀질 기술임 ㅗ.

composite / 2016년 5월 12일 / Piss Development / 0 Comments

또다른 오픈소스 IDE: Consulo IDE

흐음… 한국에 자바 IDE 쌍벽은 아무래도 Eclipse 와 IntelliJ 일 것이다.
Netbeans 도 있긴 하지만 쓰는 사람이 드물어서…

어쨌든 간에, JetBrains 에서 .NET IDE 만든다고 한 지 2주.
근데 댓글에서 심상치 않은 IDE를 발견했다.

이름하여 Consulo IDE 이다.

Consulo는 IntelliJ IDEA Community Edition의 쉘 전신인 IDEA IDE 베이스로 만들어진 오픈소스 IDE이다.
현재 안드 공식 개발 툴인 IntelliJ IDEA 기반의 쉘 UI 프레임워크가 오픈했다라…
엉? IntelliJ에 썼던 UI가 오픈소스라고?

정말 있다. 오픈소스로. IntelliJ Community Edition

그렇다. 커뮤니티 에디션에 한해서 오픈소스로 공개하긴 했다.
게다가 Apache 2.0 라이선스다. 상업적으로 써도 문제는 물론 없다.
아니었으면 상업적으로 안드로이드 개발은 물건너 갔을테니.

어쨌든, 다시 Consulo로 돌아가자.

Consulo는 현재 C#, Javascript, Java 등을 지원하며, 모든 언어를 지원하는 하나의 IDE로 통일하겠다는 목표를 가지고 있다.
안타깝게도 안정된 버전이 아니라서 실무에 쓰기는 조금 어렵지만,
유니티 개발자들이 이 IDE를 주목하고 있다.
왜냐?
모노IDE가 좆같거든.

인텔리 기반이라 인텔리 플러그인을 지원 하기는 한다. 조금 손을 봐줘야 한다고 한다.
마이그레이션 과정을 거치는데, 아무래도 라이선스 이슈 때문이다.
불편하더라도 인텔리제이와는 분리해야 써야 하는 이유이기도 하다.

Add a plugin

JetBrains 에서 Project Rider 로 C# IDE를 꾀하고 있고.
아마 유니티 개발에서 하나의 변수로 떠오를 가능성이 큰 상황이다.
어자피 모노와 닷넷은 API가 틀리지 언어 구조와 스펙까지 틀린 건 아니니
지켜봐야 할 내용이고,

거기에 오픈소스로 강공을 펼칠 Consulo IDE에도 주목할 필요가 있다.

IDE 전쟁이 시작되는 것이다. 우오.

composite / 2016년 1월 28일 / Piss Development / 0 Comments

Javascript 파이프라인

어찌보면 나도 간과한 일일 수도 있다.
Javascript 로 열심히 삽질하다 보면 역시 콜백 늪에 안빠져본 자스 개발자는 없을 것이다.
이런 콜백 지옥을 빠져나가기 위해 여러 패턴이 도입되었고, 그 중 대표적인 게 Promise 패턴, Generator, 그리고 async/await 이다.

마침 Play.node() 라는 컨퍼런스가 이미 진행했었고, 공개된 발표자료 중 바로 한눈에 들어온 세션이 있었는데,
그게 바로 Session 3. Pipe: 콜백지옥의 또 다른 거짓 선지자 였다.

그리고 콜백 지옥을 빠져나갈 수 있다는 여러 선지자들, 그리고 세션 발표자가 이를 개선하기 위해 만든 또다른 선지자를 소개하는 시간이었다.
필자는 여기에 참여하지 못해 이 세션의 처음과 끝이 어땠는지는 잘 모르겠지만, 자스 개발자들은 뭔가 너무 차별화된 형식으로 접근하려는 시각이 눈에 띄었다.

그렇다. 너무 차별화되어 다르게 보일 수 있지만 결국 똑같은 패턴.

그게 바로 작업 흐름 관리이다. 영어로 Task flow management.
이를 관리하기 위해 보통 제공되어 사용하는 패턴이 바로 Pipeline pattern 이다.
작업 단위 간 통신을 위해 꼬리를 물고 무는 패턴.

자바스크립트는 싱글 쓰레드다. 그렇기 때문에 얻을 수 있는 이점이 있지만 이를 위해 잃은 많은 것들이 있다.
얻을 수 있는 이점이 바로 비동기 이다. 자스는 비동기에 능하다. 어떤 작업 흐름을 미꾸라지처럼 빠져 나가는 재주를 지녔다.

다른 언어에서도 이런 미꾸라지같이 작업 흐름을 마칠 수 있는 이점을 수용하려 하고 있었고, 이렇게 생겨난 것이
자바의 Future<T> 와 닷넷의 Task<T> 이다. 그리고 닷넷 4.5 에는 asyncawait 문법으로 비동기 작업 흐름 관리에 종지부를 찍을 것 같았다.
자스에서도 이런 종지부를 받아들여 ES7에 들어올 예정이긴 하지만… 언제 들어올지는 아직 모른다. 그렇기에 기대에 부응하지 못하고 오늘도 자스는 작업 흐름을 관리하고 있다.

동시성과 비동시성을 합쳐서 여러 케이스로 작업 흐름을 관리하는 업무는 의외로 많다.
하지만 많은 개발자들은 이를 동기적으로 처리하려고 한다. 왜냐, 그게 편하고 순서있고 보기도 편하기 때문에.

하지만 위 소개된 세션을 통해 이런 자스의 고충을 이해할 수밖에 없는 이유가 있다. 아니. 이해해야 할 수밖에 없다.
바로 자스는 아까 말했듯 싱글 스레드이다. 아까 말했듯이 자스는 어찌보면 너무 많은 것을 잃은 것만 같다.
쓰레드를 여러 개 사용할 수 있는 자바나 닷넷 등이 아니다 보니 쓰레드 단위로 Pipeline 을 갖는다는 것은 매우 어려운 일이다.
그래서 위 세션처럼 비동기 방식의 장점을 살려 바로 이벤트를 통해 작업 흐름을 관리하는 파이프라인을 구현한 것이다.
여기서 가장 핵심 공통점은 바로 작업 간 데이터를 주고받아야 한다. 그리고 이 때문에 구현한 것이다.
자스는 작업 흐름 관리를 위해 콜백 간에 데이터를 주고받아야 하는 일이 많다. 그렇다 보니 전통적인 방법으로는 콜백 지옥이 발생하는 것이다.

그렇다. 자스도 결국 파이프라인 패턴 써야 한다. 작업끼리 물고 물고 늘어진다. 이건 어느 언어나 업무 흐름에 피할 수 없는 숙명인 것이다.
자스는 작업을 관리하는 방식이 다를 뿐, 결국 작업은 파이프라인인 것이다. 어쩌면 동시에 해야 할 수 있고, 그리고 동시에 모두 끝나야 대기탔던 작업 해야 하고.

WE ARE THE HELLO WORLD.

참고자료

Play.node() 발표자료 http://d2.naver.com/news/2602887
자바 : 파이프 스트림과 쓰레드간 데이터 교환 http://javacan.tistory.com/entry/72
닷넷 : C# 쓰레드 이야기: 11. 이벤트(Event) http://www.hanbit.co.kr/network/view.html?bi_id=360

콜백지옥의 또 다른 거짓 선지자 관련 또다른 참고자료

Node.js Flow (part 1) – Callback Hell vs. Async vs. Highland http://blog.vullum.io/javascript-flow-callback-hell-vs-async-vs-highland/
Node.js Flow (part 2) – Fibers and Generators http://blog.vullum.io/nodejs-javascript-flow-fibers-generators/
yortus/asyncawait – Callback heaven for Node.js with async/await https://github.com/yortus/asyncawait

composite / 2016년 1월 6일 / Piss Development / 0 Comments

Cloud IDE를 통해 우리가 얻을 수 있는 프로젝트 이점들

Eclipse. 국내 자바 개발자들의 국민 IDE 도구이다.
현재 릴리즈는 MARS 이며, 나온 지 얼마 안됐다. Luna 를 쓴지 얼마 안됐는데…
하지만 아직도 꽤 프로젝트들이 Indigo 및 심지어 Galileo 버전을 쓰기도 한다. ㄷㄷㄷ
그리고 어떤 이들은 디스크 오버헤드가 큰 개발환경에 질려 유료 IDE인 IntelliJ IDEA 를 통해 모던 웹 개발을 꾀하기도 했다.
게다가 구글은 자사 안드로이드 개발에 Eclipse 를 떠나보내고 IntelliJ 를 수용하여 많은 국내 안드개발자들의 공분(?)을 얻었다.

그런 말도 탈도 많은 Eclipse에서 며칠 전 Che 버전이 오픈됐다.
몇년 전부터 웹 기반 Eclipse 개발을 발표했고, 그리고 꾸준히 개발해왔다.
그리고 이제 “쓸 수 있는” 웹 기반 Eclipse IDE가 생겼고, 이 버전 코드명칭을 Che 로 칭했다.
근데 Che가 뭔지 아직 모르겠다. 좀 더 자료를 수집해야겠다.

어쨌든, 이녀석은 웹 기반의 IDE이다.
Atom같은 쉘을 통하여 자체 브라우저를 통해 응용 프로그램 행세하는 에디터는 아니고 그저 브라우저에 돌아가는 녀석이다.
이녀석은 서버로 운영되며, 서버 내 개발자들에게 같은 개발 환경을 제공한다.

그리고 또하나 흥미로운 기능이 있다면 바로 Workspace 서버이다.
이클립스는 Workspace를 잡고 여기에 설정을 관리하고 개발 환경을 만든다.
이런 Workspace가 이제는 서버에서 관리되어 개발자들의 용량 부담을 최소화 했다.

Eclipse Che

요렇게 생겼다. 뭔가 인텔리제이같이 생겼다고? 디자인만 그럴 뿐 순전히 Eclipse 환경이다.
그리고 이 같은 개발환경을 여러 개발자에게 워크스페이스와 같이 제공한다.

그렇다면, 이런 개발 환경에서 얻을 수 있는 개발 이점은 무엇이 있을까?
가장 많이 쓰이는 자바 개발 환경 기준으로 설명하겠다.

1. 개발환경을 매우 쉽게 세팅할 수 있다.

한국의 SI 스러운 개발환경. 솔직히 말해 A부터 Z까지 표준을 맞춘다는 건 마음에 안들고 너무 꽉막힌 생각이다.
한국의 개발환경은 그리고 A-Z 모두 맞춰줘야 한다. 심지어 경로까지… 워워…
아무렴 어떤가. 클라우드 개발환경은 개발자들의 쓸데없는 개발환경 세팅 시간을 줄여준다.
관리자가 그저 개발자 계정과 워크스페이스 권한만 주면 개발자는 브라우저를 통해 접속만 하면 개발환경 세팅 끝이다.
물론 DB의 경우는 얘기가 틀리겠지만 Tadpole DB Hub를 통해 개별 관리하거나 하면 시간은 더 줄어들겠지만 그럴 일은 없어보이고…

2. 익숙한 개발환경을 그저 클라우드로 즐길 뿐이다.

Eclipse Che 는 Eclipse 기반이다. 당연히 자바로 만들었고, 자바로 돌아간다. 자바 개발환경이 모범을 보여줘야지.
자바 개발자들에겐 당연히 Eclipse 는 친숙함 그 자체이다. 이 친숙함 그대로 클라우드로 즐기면 된다. 뭐가 문제인가?
개인 프로젝트 개발해야 하는데? 그러면 별도 IDE를 쓰면 되잖나. 개발환경 분리되는게 일상인 프리랜서가 뭔 걱정인가?

3. 보안과 통합이 매우 쉽다.

워크스페이스를 서버가 관리한다는 게 무슨 뜻이겠는가? 개발 소스를 자기들이 관리하겠다는 거 아닌가?
그렇게 되면 개발자들이 개별로 소스와 구조를 가질 필요가 없어지고, 그리고 이로 인한 소스 코드 유출 피해를 줄일 수 있지 않겠는가?
아직 소스 구조를 다운로드 받기 기능과 이에 대한 권한에 대해서는 확인이 필요하지만, 만약 있다면 개발 보안도 한층 업그레이드 될 것이다.
그리고 개발자가 이제 철수한다면 철수할 개발자에게 권한을 빼면 끝이다. 뭐 삭제
또한, 통합을 하고자 한다면 그저 관리자가 Eclipse Che 서버만 관리하면 된다. 모든 개발자가 다 적용된다.
물론 각 개발자별 플러그인이 필요할 것이고, 이를 관리자가 맞춰줄 수 있다. 그렇지 않다면 분명 불편할 개발자도 있을 테니.
SVN? Git? 다 된다. 버전 관리는 공통으로 한번 세팅하거나, 사용자별 세팅하면 땡이다. 그다음 지속적 배포 환경 고민을 하면 된다.

4. 개별적 개발상 이슈를 최소화할 수 잇다.

개발하다보면 예상치 못한 문제에 직면한다. 갑자기 개발자 컴퓨터가 맛이 가버리거나, 팅기거나 등등…
여태까지 작업한 것들이 날아가는 모습을 본 개발자에게는 허망함과 부담감이 가득할 것이다.
또한, 개발 환경이 반드시 100% 맞춤형이 아니다 보니, 어떤 컴퓨터에서 잘 안돌아가기도 한다.
그래서 어떤 프로젝트는 심지어 OS와 브라우저 등 아주 원초적인 환경까지 통일해야 하는 표준을 규정하여 개발시키기도 한다.
피곤하다.
웹 환경은 그딴거 없다. 웹만 되면 된다. 구버전 브라우저만 아니라면 개발할 수 있는 모든 게 다 된다.
Eclipse Che는 그렇게 만들어졌고, 그게 목표이기 때문이다.
웹 브라우저 외에 어느 환경도 구애받지 않는 개발 환경이라면 피곤할 필요도 없지 않겠는가?
게다가 관리자가 허락만 한다면 재택 근무도 가능하고. 물론 그럴 가능성을 염두해 둘 리는 없겠지만.

이제 개발환경도 새바람이 불고 있다.
여태까지 나온 임대 기반 개발환경이 싫다면 언제든 개발환경을 구축하여 제공할 수 있다.
서버 기반의 개발환경으로도 데스크탑 못지 않은 개발환경을 구축할 수 있는 시대도 도래했다.
이를 친숙한 Eclipse 에서 Che 버전을 통해 제공할 것이다.

이제 자바 개발자들에게 고민해야 할 것은 무엇인가?
바로 인식의 전환이다.
다른거 다 필요없다.

composite / 2015년 12월 28일 / Dog's bullshit / 6 Comments

자바 개발자들은 왜 비동기를 싫어하는 걸까?

지금 닷넷 하고 있지만 얼마 지나지 않은 자바 개발 시절 얘기다.
나는 자바스크립트의 비동기 패턴에 익숙했다.
그래서 가끔씩 이벤트 패턴을 사용하기도 한다. 웹인데도.
하지만 공통팀 개발자로부터 태클이 들어왔다.
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 로 한국어 웹 검색만 해도 좌르륵 나온다.

composite / 2015년 4월 10일 / Piss Development / 0 Comments

자바와 닷넷의 문자열 연산자 차이

1. == 및 != 연산자

닷넷

닷넷은 == 연산자 오버로딩을 통하여 String.Equals 사용하여 값의 동일성을 비교.

자바

자바는 String이 닷넷과 같이 클래스이며 연산자 지원 안하는 특성상 레퍼런스 비교밖에 못하므로 동일한 값 비교 불가.
따라서 개발자가 직접 String.equals를 사용.

2. + 연산자

닷넷 :

string s = "asd" + b + "qwe";
//>> string s = string.Concat("asd", b, "qwe");

String.cs
.NET concat 원리

        [System.Security.SecuritySafeCritical]  // auto-generated
        public static String Concat(String str0, String str1) {
            //Contract 는 Test 및 유효성 검사를 위한 내부 클래스임.
            Contract.Ensures(Contract.Result<string>() != null);
            Contract.Ensures(Contract.Result</string><string>().Length ==
                (str0 == null ? 0 : str0.Length) +
                (str1 == null ? 0 : str1.Length));
            Contract.EndContractBlock();

            if (IsNullOrEmpty(str0)) {
                if (IsNullOrEmpty(str1)) {
                    return String.Empty;
                }
                return str1;
            }

            if (IsNullOrEmpty(str1)) {
                return str0;
            }

            int str0Length = str0.Length;
            //.NET 은 네이티브를 통해 포인터에다가 합칠 문자열 길이를 모두 합산하여 배열에 자리 부여
            String result = FastAllocateString(str0Length + str1.Length);
            //그리고 포인터에다가 순서대로 삽입
            FillStringChecked(result, 0,        str0);
            FillStringChecked(result, str0Length, str1);
            //그리하여 포인터 문자열 출력.
            return result;
        }

자바 :

String s = "asd" + b + "qwe";
//>> String s = new StringBuffer().append("asd").append(b).append("qwe").toString();

StringBuffer.java
자바는 문자열 증가 연산자 약속을 StringBuffer 클래스를 통해 합치며 원리는 닷넷과 차이가 있음.

닷넷과 자바의 문자열 합치기 차이점

닷넷 : 처음부터 합칠 모든 문자열의 길이만큼 자리를 포인터에 할당 후 삽입한 다음 포인터 결과값 출력.
자바 : StringBuffer 특성상 일정 자리를 부여 후 문자열 넣을 때마다 필요 시 일정량 증가 후 삽입한 다음 문자열 출력. (기본값은 +16)

닷넷과 자바의 문자열 합치기 공통점

반복문 등에서 문자열 추가시 닷넷은 StringBuilder, 자바는 StringBuffer를 쓰는 것이 성능상 이득.

여기까지.

composite / 2015년 4월 6일 / Piss Development / 0 Comments

스프링 4 나온 기념 예제 개발중.

개발환경은 다음과 같다.

  • 자바 1.6 이상
  • Spring 4.0.0.RELEASE
  • Spring MVC
  • 웹 서버는 내장형 톰캣 (Embedded Tomcat 7.0.47) 이므로 별도 웹서버 필요 없음.

실행 방법은 그냥 net.sample.app.Application 을 자바로 실행하면 내장 웹서버가 실행된다.

그런 다음 http://localhost:8080 들어가 Hello World! 나오면 된다.

아직 해결되지 못한 문제가 있다.

뷰 파일 경로 못찾고 있다.

오픈소스이며 누구나 참여할 수 있으니 같이 머리 맞대고 풀었으면 좋겠다.

https://github.com/composite/spring4-mvc-embed-tomcat7-example

composite / 2013년 12월 19일 / 미분류 / 0 Comments

DB도 튜닝이 있나? 앱도 튜닝이 있다.

아마 한국 IT 생태계의 고질적인 문제라 봐도 과언이 아니다.

물론 게임같은 경우 최적화 안하면 돌리기도 힘들어 뒤지겠지만 (근데 그래도 개적화하는 게임 몇개씩은 있다.)

앱들, 웹사이트던 응용이던 모바일앱이던 튜닝은 무시할 수가 없다.

뭐.. 이해는 한다. 왜냐면 대부분의 비즈니스 앱들은 DB 처리가 대부분을 차지한다.

쇼핑몰부터 은행까지. 작던 크던 대부분의 앱들은 DB를 타고 데이터를 가져오거나 설정한다.

그래서 DB 튜닝만 해도 최대 몇십배 빨라지는 희한한 앱도 나온다.

하지만 그렇다 보니 앱에 소홀해 하는 경향을 몇몇 체험하고 목격하면서 한번 프로그래머들에게 묻는다.

당신이 만든 앱이 느려지면, 무엇을 먼저 보는가?

아마 절반 이상은 DB 문제라고 할 것이다.

예전 프로젝트에서 DB 인덱스 안걸어서 SELECT 쿼리가 10초 이상 걸리는거 내가 0.3초로 만든 경험이 있어 내가 더이상 뭐라 할 수 없는 부분이 있기도 하다.

하지만 프로그램을 더 많이 타는 프로세스가 있다면 얘기가 달라진다.

비즈니스를 간단하게 예를 들면, 엑셀 업로드 후 해석해서 DB를 넣던 뭘 하던 하는것들.

그리고 특히 웹에서는 세션과 캐시.

메모리를 효율적으로 관리할 수 있는 메모리 키값 기반 DB Redis 를 도입했다면 조금 더 진보했다고 할 수 있지만,

왠만한 비즈니스 프로그램들은 대부분 기본적으로 제공하는 세션과 캐시에만 의존한다.

응용도 마찬가지다.

상당히 안좋은 전략이다.

그렇다고 세션과 캐시를 사용하지 말라는 말을 하고싶었다? 전혀 아니다.

세션과 캐시는 앱에 있어 상당히 중요한 역할을 하고 있는거 설마 내가 모를리가 있겠나?

하지만 최소화해야할 필요는 있다.

아시다시피 세션과 캐시는 메모리를 쓴다. 물론 캐시는 경우에 따라 저장공간을 활용하며, 메모리와 디스크를 오가는 역할을 하는 캐시 시스템도 존재한다.

이유는 간단하다. 필요한 만큼만 쓰고 나머지는 다른 프로세스에 양보하여 최대한의 앱 속도를 내기 위한 전략이다.

특히 메모리가 한정된 임베디드 앱이나 모바일 앱, 그리고 웹 사이트에서는 정말 필요한 전략이다.

자바 및 닷넷 고수들은 항상 이런 말을 한다.

“가비지 컬렉터를 믿지 마라.”

그들은 언젠가 객체 데이터를 날려먹을 수도 있다. 반드시 돌아가는 동안 영구적으로 가지고 있다는 보장이 없다.

그래서 영구적으로 보관하는 DB란 녀석이 있는 것이고, 세션이나 캐시를 효율적으로 관리하는 모듈이 따로 있는 것이다.

특히 세션은 사용자가 사용 안한다고 해서 지워지는것도 아니다. 웹사이트 말이다.

사용자가 언제 사용 안할 지도 모르고 다시 사용할 지도 모른다. 웹 기술의 한계라고는 하지만 그건 어쩔 도리가 없다.

그래서 세션의 경우는 세션 만료 시간이 존재한다.

하지만 그렇다고 해서 세션 만료가 지나거나 사용 안하는 등으로 해서 해당 사용자의 세션을 날리나? 그것도 아니다.

그리고 계속 사용한다고 그걸 계속 보관하는것도 아니다. 언젠가는 Recycle 로 날라갈 지도 모른다.

왜냐? 시스템 메모리 관리를 위해서.

자바던 닷넷이던 웹 서버의 세션 시스템은 은근 복잡하고, 불안정하다. 100% 신뢰가 안되는 시스템이다.

그렇다고 해서 100% 신뢰할 만한 세션 및 캐시 시스템 또한 없다. DB 기반 세션도 마찬가지다.

하지만 대신 DB는 디스크에 보관하기 때문에 데이터 가용성으로 신뢰도가 일반적인 것보다 더 올라간다.

또한, 메모리에 보관시 DB 특성상 리사이클 시스템이 철두철미하여 신뢰도가 한층 더 올라간다.

그래서 Redis 를 세션이나 캐시 용도로 적합하다는 얘기가 나오는 것이다.

그렇다고 해서 기본적으로 제공하는 세션이나 캐시 시스템이 “쓰레기” 냐? 이것도 아니다.

단지, 필요한 데이터만 필요한 공간에 담아서, 나머지는 DB 연동이나 프로그램 연동 등에 맡기고, 처리하는 게 좋은 전략이라는 것이다.

예를 들면, 사용자 로그인 하면 세션에 담을만한 건 사용자의 ID, 이름, 가지고 있는 권한 뿐이다. 전화번호, 이메일을 세션에 담을 이유가 없다. 그들은 세션에 담아서 어따가 쓰나?

이렇게 최소한의 정보만으로 최대한의 다른 메모리 사용을 위해 양보하자는 뜻이다.

특히, 공통코드를 메모리에 담는 비즈니스 앱이 상당히 흔하다. 물론 그렇게 하면 공통코드까지 DB를 안타기 때문에 성능은 올라가는 것은 사실이다.

나쁜 전략은 아니다. 단지 한가지만 지키면 된다.

공통코드 키와 값 외에는 어떤것도 넣지 않는 것을 추천한다.

그리고 변경사항 검색을 위해서라면 그냥 최근 업데이트 날짜를 가져오는 것이 좋다.

그런 다음에 매 요청시마다 날짜만 DB에 왔다갔다하고, DB가 최신이면 최신 공통코드만 가져와 교체하면 메모리 관리 측면에서 이득이다. “동기화” 의 장점을 이용한 것이다.

만약 이것도 지키고 있다면 이미 중급 이상이라 봐도 손색없는 개발자다.

물론 기술보다 업무를 프로그램으로 소화해내는 능력이 좌우하는게 개발자 수준인 거는 한국 사회에서는 부정할 수 없는 현실이다.

하지만 역시.. 개발자는 기술도 당신의 프로그램을 좌우한다.

10년지기 이상 개발자가 떵떵거리며 살 수 있는 이유가 바로 그것이다. 돈 많이달라고 징징해대기만 하는 그런 도둑놈이 아니다.

그런 기본적인 기술을 토대로 업무에 많이 녹아들여 빠르게 만들어내는 개발자야 말로 클라이언트에게 이상적인 개발자 아닌가?

그렇다고 돈 많이 주기 싫다면 걍 노트에 적어서 관리하는 것을 추천한다.

어쨌든 앱 튜닝이라 거창하게 말했지만 게임도 당연히 캐시가 중요하지만 비즈니스 앱 개발자가 많은 관계로 비즈니스 앱을 통해 중점적으로 언급했다.

앱도 군더더기를 줄이고 이 세션과 캐시를 관리만 잘 한다면, 사업자에겐 솔루션이 되며, 개발자에겐 테크닉이 된다.

composite / 2013년 10월 28일 / 미분류 / 0 Comments

PredictionIO, 예측하고, 추천하는 (내가 말고 걔가) 서버 프레임워크!

오늘 출근 후 메일확인을 해보니 하나의 생소한 영어 메일이 왔다.

내용인 즉슨, 프로젝트 리더 메일이 다이렉트로 보냈는지 모르겠지만, 나보고 PredictionIO 에 관심을 가져달란다.

아무래도 Play! Framework 에 참여한 사람들을 대상으로 메일을 보낸 듯 하다. (나? 글쎄..)

Prediction 이 예측이란 뜻은 뭐 다들 아실테고. 한번 훑어보기 시작했다.

Github 주소를 가르쳐줬다. 들어가봤다.

https://github.com/PredictionIO/PredictionIO

이녀석은 Play! Framework 를 사용하여 RESTFul API 로 구성된 하나의 추천 모듈인데.

Machine Learning Server 라고 명명했다. 직역하면 기계학습 서버. 기계가 학습하면서 사람들에게 예측과 추천을 하게 하는 모듈이라고 보면 되겠다.

대표적인 모듈이 심심이가 되시겠다. (물론 오픈소스는 아니지만)

어쨌든, 동영상으로 설명해놨다.

A Quick PredictionIO Demo from PredictionIO Team on Vimeo.

예를들어 레스토랑 추천을 하고싶다. 그러면 레스토랑에 맞는 메뉴를 넣고, 그리고 선택한 메뉴를 기록하면서, 많이 쓰거나, 많은 평점을 목표로 하여 쌓은 데이터를 이용하여 사람들에게 추천하는 그런 시스템이 되시겠다.

이 프로젝트는 작은 팀으로 구성되어 만들고 있다고 한다. 아직 스폰서는 없나보다.

하지만 한번 재밌는 프로젝트라 관심을 가지고 지켜보고 있다.

한국인들이 좀 다가가기 어려운 게 뭐냐면 바로 왠만한 프레임웍 코어가 “Scala” 로 만들어져 있다. 자바는 보조적일 뿐.

설마 스칼라 모르는 자바 개발자는 없겠지? 제발 자바 개발자라면 짚고 넘어가야 한다. 제발.

어쨌든 Play! Framework 가 원체 스칼라로 되어 있고 하니 그런 듯 한데 사실 자바로도 개발 가능하다.

하지만 이녀석은 스칼라를 선택했다. 하지만 굳이 스칼라 깊이 파고들지 않아도 된다. 자바로도 개발 되기 때문에.

아직까지는 추천 개념과 종류가 너무나 다양하여 아직 이 많은 것들을 담을 수 있는지는 아직 모르겠다.

하지만 지켜볼 만은 하다. 오픈 소스로 서버가 스스로 학습하고, 사람들에게 추천을 해줄 수 있는 모듈이라면,

레스토랑을 포함하여 다양한 서비스 사업에서도 영향이 안갈래야 안갈 수가 없기 때문이다.

참고로 클라이언트 코드를 PHP나 파이썬으로도 구성할 수 있으니 굳이 자바 몰라도 얘네들이 준 배려에 감사히 참여해 보도록 하자.

아직까지 단점이 있다면 리눅스 특화되어있다는 거. 그건 차츰 해결해 나갈 것으로 보이기는 개뿔 빅데이터 어쩔겨? 빅데이터 기반인데.

나랑 같이 지켜보지 않으련?

composite / 2013년 10월 18일 / 미분류 / 0 Comments