이런 스타트업 어떨까요.

[Moon James]

전철에서 이런 저런 생각을 하다가 문득 떠오른 생각인데요.

아마 다른 분도 생각하셨을 듯 합니다.

.. 클로져가 자바와 찰떡궁합인데요..

.. 우리나라 대규모 프로젝트의 대부분이 자바... 인 것으로 알고 있습니다.

.. 그런 대규모 프로젝트에서 자바의 한계로 고도화가 힘들거나..  기존에 구현되었던 것도 여러 문제가 있을 때  클로져가 해결사가 될 수 있을 것 같다는 생각..

.. SI 쪽을 잘 아시는 분이라면 이 부분을 비집고 뭔가 틈새 시장을 만들 수도 있을 것 같고..

.. 좀 알려지면, 클로져의 우수성과 더불어 클로져리안의 몸값도 올라가는 효과가... ㅎㅎㅎ

저는 이쪽의 경험이 전무하여 그냥 생각만 든 건데요..  잘 아시는 분들의 의견도 듣고 싶습니다.

..  내일 스터디에 나갈 수 있을라나 모르겠네요..  메르스와 야근...  ㅎㅎ 

[김영태]

기술적으로 뛰어나도 소스 코드의 유지/보수라는 측면에서 인력 수급의 문제 때문에 대부분의 SI 업체는 Clojure를 포함해서 신기술을 받아들이려 하지 않는게 우리의 현실입니다. 아울러 기술의 안정성(?)을 이유로 듭니다..그런데 그 안정성이라는 것이 늘 써오던 기술이라는 일종의 '관성' 이상의 의미는 없다고 저는 봅니다만, 어쨋든 그렇습니다.

그런데 한편으로는 이런 현상이 스타트업에게는 오히려 기회가 될 수 있습니다. 후발 신규 업체는 항상 틈새를 노리게 되고, 경쟁에서 기존의 중견 업체와의 경쟁에서 승리하려면 신기술로 무장하는 것 외에 달리 뾰족한 방법이 없으니까요. 현실적으로 창업자가 아니면 Clojure같은 신기술을 실무에 도입하기로 결정하기를 기대하는 것은 거의 제로에 가까운 희망이라고 저는 생각합니다. 실무자 차원에서 아무리 Clojure를 도입하려 용을 써도 그 윗선에서 No하면 더이상 달리 할 수 있는 일이 없지 않습니까? 그래서 제 생각에는 생산성 있는 Clojure로 프로그래밍을 하고 싶다면, 창업을 하시는 것이 가장 최선이라고 생각합니다. 제가 항상 하는 이야기지만, Platon의 철인 정치를 현실에 구현한다고 할 때, 왕이 철인이 되기를 기대하기보다는 철인이 왕이 되기를 기대하는 것이 훨씬 빠르다고 보기 때문입니다.

2015년 6월 23일 화요일 오전 8시 44분 55초 UTC+9, Moon James 님의 말:

[Moon James]

음.. 역시 그렇군요.  하기야, 루비나 스칼라.. 파이썬 조차 많이 안쓰는 것 같긴 합니다.

제가 이런 창업을 생각하는 건 아니구요.. ㅎㅎ  그냥 아이디어 차원에서.. 

답변 많이 참고가 됐습니다.  감사합니다.

[KI-YOUNG BANG]

기존에 JAVA 중심으로 개발해온 기업의 경우는 기존 개발자를 Clojure 개발자로 바꾸는데 시간과 비용의 문제가 가장 큰 듯 합니다.

그런 이유로 제가 아는 최신 기술을 적극 도입하는 기업도 JAVA 대안으로 주로 Scala를 사용하지 Clojure를 주 언어로는 사용하지 않더라고요.

함수형 언어와 Clojure 관련 한글 문서와 국내 컨퍼런스가 활성화 된다면 Clojure 도입 시기가 빨라지지 않을까 생각이 듭니다.

스타트업의 경우는 Clojure 개발자들이 으샤으샤해서 차린 경우는 몰라도, 개발자 외부 조달이 필요한 경우는 역시 어려움이 많다고 생각 합니다.

아무래도 Clojure 개발자의 경우는 어느정도는 경력도 있고 실력도 있어서 비용문제가 가장 크고, 학습 시간을 가지기에도 스타트업 일정상 어려운 경우가 많고...

제가 학교다닐때는 "함수형 언어로 Lisp가 있고 인공지능 등등에 쓰인다." 정도로만 배웠는데 (OOP는 두학기 정도 걸쳐서 가르쳤으면서...ㅠ.ㅠ) 요즘은 어떨지 잘 모르겠네요.

학교에서 함수형 언어에 대해서 깊게 가르치면 아무래도 대학생 스타트업에서도 Clojure 사용을 기대해 볼 수 있을텐데... (그래도 요즘 JAVA 대신 Ruby나 Python을 많이 사용하더라고요.)

그런데 저는 Clojure를 개발 언어 이상으로 생각하지 않고 있어서,

'.. 그런 대규모 프로젝트에서 자바의 한계로 고도화가 힘들거나..  기존에 구현되었던 것도 여러 문제가 있을 때  클로져가 해결사가 될 수 있을 것 같다는 생각..'

에 대해서는 납득하기가 어렵네요. 자바의 한계를 클로져로 어떻게 극복 가능한지 참고할만한 사례가 있을까요?

(우리말로 사랑을 고백해서 실패한다고 영어로 고백한다고 성공할까? 라는 말 안되는 비유를 들어 봅니다만...ㅠ.ㅠ)

2015년 6월 23일 화요일 오전 8시 44분 55초 UTC+9, Moon James 님의 말:

[박상규]

2015년 6월 23일 오전 11:05, KI-YOUNG BANG <ds5...@gmail.com>님이 작성:

기존에 JAVA 중심으로 개발해온 기업의 경우는 기존 개발자를 Clojure 개발자로 바꾸는데 시간과 비용의 문제가 가장 큰 듯 합니다.

그런 이유로 제가 아는 최신 기술을 적극 도입하는 기업도 JAVA 대안으로 주로 Scala를 사용하지 Clojure를 주 언어로는 사용하지 않더라고요.

함수형 언어와 Clojure 관련 한글 문서와 국내 컨퍼런스가 활성화 된다면 Clojure 도입 시기가 빨라지지 않을까 생각이 듭니다.

스타트업의 경우는 Clojure 개발자들이 으샤으샤해서 차린 경우는 몰라도, 개발자 외부 조달이 필요한 경우는 역시 어려움이 많다고 생각 합니다.

아무래도 Clojure 개발자의 경우는 어느정도는 경력도 있고 실력도 있어서 비용문제가 가장 크고, 학습 시간을 가지기에도 스타트업 일정상 어려운 경우가 많고...

제가 학교다닐때는 "함수형 언어로 Lisp가 있고 인공지능 등등에 쓰인다." 정도로만 배웠는데 (OOP는 두학기 정도 걸쳐서 가르쳤으면서...ㅠ.ㅠ) 요즘은 어떨지 잘 모르겠네요.

학교에서 함수형 언어에 대해서 깊게 가르치면 아무래도 대학생 스타트업에서도 Clojure 사용을 기대해 볼 수 있을텐데... (그래도 요즘 JAVA 대신 Ruby나 Python을 많이 사용하더라고요.)

그런데 저는 Clojure를 개발 언어 이상으로 생각하지 않고 있어서,

'.. 그런 대규모 프로젝트에서 자바의 한계로 고도화가 힘들거나..  기존에 구현되었던 것도 여러 문제가 있을 때  클로져가 해결사가 될 수 있을 것 같다는 생각..'

에 대해서는 납득하기가 어렵네요. 자바의 한계를 클로져로 어떻게 극복 가능한지 참고할만한 사례가 있을까요?

글쎄요... 클로저가 구세주 정도까지로 된 것인지는 모르겠지만...

아마도 대표적인 것은 Storm이지 싶네요. 

아래는 Storm을 만든 Nathan marz가 한 인터뷰에서 한 말인데요.

"By doing the implementation in Clojure, I was able to be a lot more productive and get the project working sooner."

그리고 CI 서비스를 하는 Circle-CI 에서는 서버와 클라이언트단 모두 클로저를 사요한는데요. 

매크로를 활용해서 14,000 라인 테스트 코드를 다른 테스트 라이브러리고 재작성하는데 24시간 걸렸다는 내용도 있구요.

http://blog.circleci.com/rewriting-your-test-suite-in-clojure-in-24-hours/

뭐 그리고 서버사이드의 경우에는 클로저로 개발하면서 LOC가 자바에 비해서 확 줄어서(자바에 비해 대략 30%~10% 수준?)

에러도 적고 안정적이었다는 보고는 많구요.

저의 경우 특히 게임 서버 개발할 때 스레드를 고민하지 않고 개발한다는 것의 장점을 체감했습니다. ^^;

(물론 스프링같은 프레임웍이 개발자의 스레딩 문제를 대신 처리해부는 웹 개발의 경우에는 좀 다르겠지만...)

이런 저런 경험으로 인해 클라이언트 사이드는 힘들더라도, 적어도 서버사이드는 스타트업에서 클로저를 도입하는 것은 매우 승산이 있는 게임이라는 생각이구요. 실제로 요즘 광고 많이 하는 '다방'이 서버사이드를 클로저로 개발한 것으로 알고 있습니다.

기업 입장에서 여러가지 문제로 자바 대체 언어로 자바와 비슷해 보이는 스칼라를 덥썩 무는 것은 한편으로는 이해는 갑니다만...

정적 타입과 OOP 그리고 스칼라의 복잡성으로 인해 생산성이 그리 많이 나아질지 의심스럽습니다.

(이에 대한 자세한 논의 : https://groups.google.com/forum/#!topic/lisp-korea/Ch7lJoHGix4)

 

(우리말로 사랑을 고백해서 실패한다고 영어로 고백한다고 성공할까? 라는 말 안되는 비유를 들어 봅니다만...ㅠ.ㅠ)

2015년 6월 23일 화요일 오전 8시 44분 55초 UTC+9, Moon James 님의 말:

전철에서 이런 저런 생각을 하다가 문득 떠오른 생각인데요.

아마 다른 분도 생각하셨을 듯 합니다.

.. 클로져가 자바와 찰떡궁합인데요..

.. 우리나라 대규모 프로젝트의 대부분이 자바... 인 것으로 알고 있습니다.

.. 그런 대규모 프로젝트에서 자바의 한계로 고도화가 힘들거나..  기존에 구현되었던 것도 여러 문제가 있을 때  클로져가 해결사가 될 수 있을 것 같다는 생각..

.. SI 쪽을 잘 아시는 분이라면 이 부분을 비집고 뭔가 틈새 시장을 만들 수도 있을 것 같고..

.. 좀 알려지면, 클로져의 우수성과 더불어 클로져리안의 몸값도 올라가는 효과가... ㅎㅎㅎ

저는 이쪽의 경험이 전무하여 그냥 생각만 든 건데요..  잘 아시는 분들의 의견도 듣고 싶습니다.

..  내일 스터디에 나갈 수 있을라나 모르겠네요..  메르스와 야근...  ㅎㅎ 

--
이 메일은 Google 그룹스 'Korean Clojure User Group' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 clojure-kr+...@googlegroups.com에 이메일을 보내세요.
이 그룹에 게시하려면 cloju...@googlegroups.com에 이메일을 보내세요.
웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/clojure-kr/c1ba958f-1c96-4c67-beab-a58233b8fb0b%40googlegroups.com을(를) 방문하세요.

더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

[Moon James]

자바의 한계를 클로져로 어떻게 극복 가능한지 참고할만한 사례가 있을까요?

아.. 그러니까.. 자바로 구현해서 디버깅이 힘들다던가,  쓰레드, 콜백 등 구조가 복잡하다.. 등등의 단점을 개선한다... 는 의미로 썼습니다.

클로져는 소스의 양 자체가 줄어드니까..  그 자체로 잇점도 있어서..

[정재훈]

좋은 글 감사합니다.

서버 개발하실 때 스레드 고민을 하지 않고 개발하셨다는 것에 대해 조금만 더 자세히 말씀해주실 수 있을까요?

상세할 필요는 없구 대략 어떤 상황에 어떤 라이브러리(STM이나 core.async 등)를 사용하니 좋더라.. 이 정도면 감사하겠습니다.

예전에  scala로 서버를 만드는 팀에 있었는데 future 모나드에 콜백에.. 개인적으로는 코딩이 힘들었는데,

나중에 회사 나와서 core.async를 보면서 당시에 이런걸 썼으면 괜찮았겠다는 생각이 들더군요.

요건 제 막연한 생각일 뿐이고, 실제 적용하신 분 입장에서 많은 도움이 되었는지 궁금합니다.

감사합니다.

2015년 6월 23일 화요일 오후 4시 38분 10초 UTC+9, 구르마 님의 말:

[박상규]

아네...

처음에는 서버를 클로저로만 개발했어요. 그때는 그냥 스레드 고민없이 했는데...

이걸 다른 회사에 팔아야 했는데... 

그 회사 사정으로 인해 결국 자바로 다시 바꿔달라고 해서...

처음부터 다시 자바로 짰어요.

그런데... 짜다보니 동기화 예외가 발생하더군요.

exception 이름이 정확히 기억은 나지 않는데 Mal....Exception이었던 것 같아요.

즉 같은 리소스를 동시에 2개 이상의 스레드에서 수정을 시도해서 발생한거죠.

그래서 스레드 문제를 해결하기 위해 설계를 바꾸고

테스트를 엄청 돌려(10000개 더미 클라이언트로 마구 서버 공격)서

해결했더랬습니다.

클로져로 된 서버에서는 core.async를 써서 작업을 했구요...

물론 이것도 쓰다 보니 아무렇게 나 막 쓰면 않되더라는...

이게 정확히게 어떤 내용이었는지...아...그게... 지금 당장은 막 떠오르지가 않네요.

나중에 관련해서 함 내용을 정리해 보겠습니다. ^^;;;

2015년 6월 24일 오후 1:23, 정재훈 <jae...@gmail.com>님이 작성:

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/clojure-kr/6afacc65-0480-46fe-a385-34324dfb1922%40googlegroups.com을(를) 방문하세요.

[박상규]

이건 지극히 개인적인 소견입니다만...

아직 제가 정리되어 있은 것이니 여기 clojure-kr 밖으로는 알리지 마시길...

(정말 이건 극비에요...위험한 내용이지만... 그냥 이런 생각도 있다는 차원에서...)

저는 모나드를 외계인이 인류의 지능의 진화 속도를 늦추기 위한 고도의 전략적 차원에서

Computer Science 학계에 주입한 복잡성이라고 생각합니다.

스칼라 말고 그냥 클로저 쓰세요...

모나드 몰라도 함수형 프로그래밍 잘 됩니다.

2015년 6월 24일 오후 3:54, 박상규 <psk...@gmail.com>님이 작성:

[박상규]

아악 이런 긴장해서 급히 쓰다보니....

아래 수정합니다.

2015년 6월 24일 오후 4:01, 박상규 <psk...@gmail.com>님이 작성:

이건 지극히 개인적인 소견입니다만...

 

아직 제가 정리되어 있은 것이니 여기 clojure-kr 밖으로는 알리지 마시길...

위 문장 아래와 같이 정정합니다.

"아직 제가 정리되어 있는 것은 아니니, 여기 clojure-kr 밖으로는 알리지 마시길..."

[정재훈]

답글 감사합니다. 이정도 내용이면 충분합니다. 많은 참고되었습니다.

그리고, 모나드 관련해서는 ㅋㅋ

예전에 모나드에 관한 글 보면서 이해하려 노력했는데 힘들었습니다.

스칼라로 코딩을 해보니.. 스칼라는 헤스켈 정도는 아니지만 일상이 모나드니까.. 자연스럽게 알게되더군요.

알고나니 사실 별 거 아닌데(실제로 사용하는 레벨에선요) 관련 글들을 읽어보니 옛날에 왜 그리 헤맸는지 알겠더군요.

category 이론부터 functor, applicative, monad 이런 식으로 설명이 되고,(메인 가기 전에 지칩니다..)

유일하게 모나드를 언어 차원에서 지원하며 실제로 많이 활용하는 언어가 헤스켈이다 보니 보통의 프로그래머들이 접할 기회가 별로 없기도 하지요.

그리고, lisp 계열 언어에선 모나드를 많이 쓰지 않고, 어쩌다 코딩하면서 모나드를 구현하는 경우는 있겠지만 그건 lisp 표현력이 좋은거라 봅니다.

하튼 잘쓰면 좋은 개념인 건 맞는데 클로저에선 별로 의식할 일은 없는 거 같습니다.

2015년 6월 24일 수요일 오후 4시 4분 1초 UTC+9, 구르마 님의 말:

[Ju-Heon Kim]

자바에서 동시에 접근해 발생한 예외는 이것입니다. 

ConcurrentModificationException

2015년 6월 24일 수요일 오후 3시 54분 19초 UTC+9, 구르마 님의 말:

[Ju-Heon Kim]

저는 구르마님이 말씀하신 클로져 게임 프로젝트를 총괄했던 사람입니다. 게임서버는 총 네번을 다시 제작했습니다. 두번째와 세번째 개발은 제가 설계를 했고 네번째 자바로 개발할 때는 같이 했습니다. 

1차 개발때는 개발자 혼자 클로져를 공부하며 개발을 했고 버그가 많이 발생했습니다. 클로져로 버그를 잡는 기법이 미약하거나 우리가 몰라서 애를 많이 먹었습니다. 그래서 다양한 방법으로 디버깅을 시도했습니다. 인텔리제이를 통한 브릭포인트 디버깅, REPL을 통한 디버깅, 스냅샵을 뜰 수 있는 함수를 통한 디버깅 등등 다양한 방법을 고안해 냈습니다. 클로져는 습관적으로 레인으로 실행을 하기 때문에 브릭포인트 디버깅을 할 수 없었습니다. 실행하는 방식을 바꿔야 가능하죠. 현장에 클로져를 적용해보고 많은 깨달음을 얻었습니다. 

2차 개발때는 일정은 몇일 안 남았고 버그는 줄지 않는 엄중한 상황이었습니다. 서버 개발자와 밤을 새며 고군분투하다 뼈대를 다시 설게하기로 결단하고 이틀동안 불이나케 작업해서 구조를 뜯어 고쳤습니다. 그리고 버그는 확 줄기 시작했습니다. 이 비법은 나중에 말씀 드리죠.

3차 개발때는 2차 개발에 적용하고 싶었던 설계 아이디어가 있었습니다. 클로져 코드가 증가하면 함수의 의존성이 늘어납니다. OOP에서 객채의 의존성이 늘어나는 현상과 비슷하더군요. 함수간 의존성이 늘어나면서 하나의 함수를 수정하면 딸려있는 많은 함수에 영향을 주고 버그가 발생했습니다. 이 지점을 고치는 아이디어로 두가지가 있었습니다. 

1. 클로저의 Watcher를 통해 의존성 제거 
2. 클로저의 core.sync로 의존성 제거 

2번을 부분적으로 적용해서 서버를 개편했습니다. 1주일안에 할 수 있는 부분만 시도해봤습니다. 클라이언트 디비와 다시 붙이는데 2주정도 걸렸습니다. core.sync를 적용하면서 데이터가 갑자기 튀어 나오는 현상들이 발생했습니다. 어디선가 체널에 변경을 가하면 갑자기 체널을 구독하던 코드가 인보크 됩니다. 순차적으로 실행이 되는 게 아니다보니 디버깅에 어려움이 있었습니다. 이 문제는 코어싱크 자체의 문제라기 보다 설계의 문제라 보았습니다. 코어씽크가 만능 키가 아니기 때문에 잘 나눠서 설계해야 혼동이 없어지겠죠. 

4차개발은 납품을 해야 되서 자바로 핵심 부분을 다시 개발했고 클로저로 개발된 부분은 라이브러리로 활용했습니다. 제가 온라인 게임을 오래 개발했던 경험이 있어 시간의 문제를 제외하곤 큰 문제는 없었습니다. 여기부터 본격적으로 구루마님이 참여하셨습니다. 구루마님이 워낙 OOP에 능숙하셔서 핵심 기능을 구현하는데는 3일정도 걸렸습니다. 물론 개발팀이 도메인지식이 풍부했고 재개발을 여러번하다보니 잇점이 있었습니다. 

도움이 되셨길 바랍니다. 

2015년 6월 24일 수요일 오후 1시 23분 38초 UTC+9, 정재훈 님의 말:

[박상규]

허걱... 그 당시 현장감이 생생하게 살아나는 듯...ㅋ

2015. 6. 25. 오전 10:51에 "Ju-Heon Kim" <no3...@gmail.com>님이 작성:

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/clojure-kr/961043cf-8598-450d-939d-82707cce8324%40googlegroups.com을(를) 방문하세요.

[정재훈]

아 현장감이 느껴지네요.. 상세한 경험을 공유해주셔서 감사합니다.

라이닝겐으로 디버깅하려면 프로세스를 붙여서 해야 하지 않을까 생각했었는데, 역시 아직까진 그렇게 해야 하나 보네요.

나중에 cursive에서 지원해 주지 않을까 기대해봅니다.

Watcher라 하심은 add-watch 로 붙이는 함수 말씀이세요?

저도 전에 서버 개발에 약간 발을 담구어 보니 상태에 대한 접근 제어보다는 future나 콜백 처리 등이 더 골치 아픈 경우가 많더군요.

그런 경우 core.async를 활용하면 좋겠다 싶은 생각이 들었습니다.

clojure를 java에 끼워넣는 방법도 좋다고 생각됩니다.

예전에 어디서 읽었는데 누가 Rich Hickey에게 클로저를 기존 자바에 끼워넣고 싶은데 어느 정도로 혼용하면 좋을까요? 이런 질문에 "그냥 넣고 싶은대로, 되는대로 많이 넣으심 됩니다." 했던게 기억나네요.

저는 rest api 서버를 클로저로 개발 중입니다.

아직은 초기라 잘 모르겠지만, 확실히 자바를 이용하는 기존 방법에 비해 편하긴 한 거 같습니다.

2015년 6월 25일 목요일 오전 10시 51분 56초 UTC+9, Ju-Heon Kim 님의 말: