SoC Kill Me..
SoC 에대한 애기를 그만두길 원했으나, 영회님이 또 글을 포스팅 하셔서 저의 생각을 적습니다. 일단 잠이 오지 않습니다. 🙂 누워도 누워서 잘려고 해도 계속 마음이 아파옵니다.
일단 SoC 애대한 애기는 어느 정도 마무리 해야 될듯 합니다. 더 글을 적는다고 해도. 참 이게 소모적인 논쟁만 될까하고 생각이 듭니다.
영회님이 적은포스트 입니다. SoC – Separation is not components.
이 글을 보면 저의 의견과 약간 대치 됩니다. Concern이라는 것은 Component가 될수도 있고 아닐수도 있습니다.
Component라는 단어에 대한 정의를 무얼로 보느냐에 중요하겠죠. 솔직히 말해서 Separation의 단위를 배포의 문제가 중요시 되는 경우 얼마든지 Component 단위로 볼수가 있다는 것이 저의 생각입니다.
.NET Framework Design Guidelines에 언급한 것처럼, Component를 하나의 진화되는 유닛 (a evolving unit)으로 정한 경우죠.
그리고 Separation에 영향을 미치는 Concern들은 결국 그 프로젝트에서 가장 적합한 요소들이 상호 균형을 맞추어 정해진다고 봅니다.
그게 생각의 범위든, 부하의 분리든, 배포의 문제든 기타 등등.
저 같은 경우는 배포가 중요시 되기 때문입니다. Robert C. Martin의 Principles of Package Architecture가 제가 하고 있는 프로젝트와는 밀접한 관련이 있기 때문입니다.
또한 Toby님이 적을 글 딱 한마디에 반박을남깁니다.
“결국 결론은 이것인 것 같다. 잘못설계된 구조에서는 많은 문제를 일으킬 수있다는 것 아닌가? Arload님 경험이나 관찰로는 그렇지 못한 경우(변화를 잘 수용할 수 있게 설계지 못한)가 많다니 안타까울 뿐이다.” by Toby
잘되고 잘못된 설계 구조는 결국 변화를 잘 반영하는 구조라고 하시는데는이견이 없으신거 같습니다. 안타깝다고 하셨는데. 과연 어디서 예측하지 못한 모든 변화를 수용할 수 있는 아키텍쳐를 만날수 있을가요?
천하의 MS도 경영진의 빈번한 요구 사항 변경으로 힘들어 했는데.. 나는 어떻게 해야할지.. 모르겠습니다.
AOM (Adaptive Object Model), Reflection, Dynamic Invocation.. 답이 보이지 않습니다… 그럼 xDepend 관련 툴을 사용해서 복잡성과 싸우는 소프트웨어는 다 잘못 만들어진것인가?
과연 모든 변화를 예측할 수 있는 신같은 통찰력은 가지지 못한 나를 탓해야 하는 것인가?.. 🙂
씁쓸할 뿐이네요.. 그리고 과연 유연성 하나 만으로 SoC를 정하기를 어렵습니다. 배포, 성능, 정치적인 문제로 인해 어쩔수 없이 Separation 하는 경우는 없는지요..
왠지 이글은 꼭 적어야 잠이 올거 같아 적었습니다. 두 분이 또 SoC에 대한 애기가 또 올라오지 않는 한 포스팅은 중지 됩니다.
남아일언 중천금인데. 죄송합니다. 🙂 마음의 상처가 깊습니다…
Architecture 101 
힘내세요 🙂
두분의 접근 방식 자체가 너무 과격하셨네요.. 상대방의 생각에 바른 의견개진이 필요한듯합니다.
그리고 개념이란 이해하는 측에 따라 다를 수 있다고 생각합니다. 개념을 바탕으로 적용하면서 새로운 시각을 가지게 되므로 같은 개념을 바라보는 측면에 따라 시각 차이는 분명히 존해합니다.
그런 시각의 차이를 인정하지 않으려는 태도는 너무 심했다고 생각합니다. 프로그래밍 언어가 무수히 많은 이유는 서로 하드웨어를 바라보는 시각의 차이때문이 아닐런지요?
그나저나 좋은 글들을 당분간 접하지 못하게 되어서 서운합니다.
훨훨 털어내시고~ arload 2.0 시대를 열면 좋겠습니다. 😉
나름 흥미롭게 지켜보고 있었는데,결말이 좋질 않아 씁쓸하군. 서로가 틀린게 아니라, 다름을 인정한다면, 너무 마음속 깊이 받아들이지 않았으면 좋겠습니다. 옳고 그름의 결말보다, 논쟁으로 자신이 성숙해 졌음을 높이 생각했으면 합니다.
화이팅 입니다. ^^*
이런 문제로 논쟁이 붙으면 결론내기가 참 어렵더군요.
양측 글을 다 읽어보았는데, 영수님이 맘 고생 많이 하셨을 거 같습니다.
힘 내시고 금방 다시 돌아오세요.
사람이다 보니 실수할 수도 있고 한데,
처음에 서로에게 상처주는 발언들을 하셔서
더욱 그랬던 것 같습니다.
생각이 다를 수 있기 때문에 서로의 실수를 포용하고
잘못된 부분이 있으니 이렇게 고치는게 좋을 것 같다
정도의 의견을 주시고 토론해 나갔다면 좋았을 것을…
금방 오실 것이라고 믿고 기다리겠습니다! 🙂
“다를수 없다 너는 틀렸다 , 나는 옳다”
우리나라 사람들 특징이랄까
“예측하지 못한 모든 변화를 수용할 수 있는 아키텍쳐”
월화수목금금금면 뭔들 못하겠습니까
냉정하게(?) 조금 이야기하자면…
1. 첫 글을 읽을때 “SoC라는 말이 왜 나오지?”하는 생각이 든 것은 비단 저만이 아닌 것 같습니다. 저도 댓글이 하나도 없을때 읽었고 이상해서 댓글 조금 적어볼까하는 생각이 있었지만, 적지는 않았습니다.(자랑은 아닙니다. 저도 단지 자극적이기 싫었을 뿐입니다.)
2. SoC는 복잡성을 줄이기 위해서 적용하는 것임에는 틀림이 없습니다. 이건 Definition인데 왈가왈부하는 것이 좀 이상하죠.
3. 위의 1,2에 대한 반발로 영회님/Toby님이 글을 적은 것 같네요. 근데 누가봐도 자극적으로 적어주시고, 댓글에도 기분상하신 분이 볼 수 있는데서 할만한 이야기가 아닌 내용을 주고 받는등 좋지 않은 모습을 보였네요. 서로 이해하시고 다시…
4. 다시 제대로된 토론이 되었으면 좋겠습니다.
위의 해프닝을 제외한 제 생각은:
5. arload님의 글에서의 용어는 국한된 내용에 일반적인 용어를 사용한 면이 두드러져보이는 것 같습니다.
6. Concern이라는 것은 추상적인 용어이기에 무엇이든지 Concern이 될 수 있다는 점은 맞다고 봅니다. Apache Cocoon(+알파)등으로 Java 세계에 SoC를 심화시킨 Stefano 역시도 다양한 문제에 SoC를 들이댑니다.(http://www.betaversion.org/~stefano/linotype/news/143/)
7. 위글에서도 시간이 지남에 따른 Concern의 변화에 의한 필연적인 복잡성의 증가에 대한 이야기가 나옵니다. 하지만 Context가 상당히 다르죠. 여기서는 arload님이 주장하는 바와 같이 Concern을 정의하는데 있어서 복잡성이 존재한 것이 아니라 Concern의 변화(물론 Requirement에 의한 변화겠죠)에 의한 복잡성입니다.
9. arload님의 글이 일리가 없지는 않습니다. 예를 들어 AOP에서 이야기하는 The Tyranny of The Dominant Decomposition 문제도 SoC의 문제로 이야기될 수도 있습니다. 말씀하신 내용도 이에 준해서 이해가 가능하다고 생각합니다.
10. 위처럼 이야기한 제 생각의 결론은 SoC 자체와 복잡성은 Orthogonal하다는 것입니다. SoC의 취지는 복잡성을 감소시키는 것이지만, 실세계에서는 이것이 Problem Domain에 따라 될 수도 안될 수도 있다…는 이야긴데, 이는 결국 SoC와 복잡성과의 인과관계가 성립되지 않는다는 것이겠죠. SoC라서 어쩌고가 아니기에 SoC가 그림에서 빠지면 글이 더 이쁘지 않을까 하는.
블로그 까지 닫으시다니. 많이 힘드신가 봅니다.
Toby님, 영회님은 Spring에 많은 애착을 가지시고 국내에서 리딩하시는 분이라서, 이 분에게 복잡성이라는 단어는 굉장히 민감하게 보일수 밖에 없었을겁니다.
Spring이 복잡성의 세계와 전쟁을 선포했거든요. 🙂
이 상황이 연출될수 밖에 없습니다.
재미난건 이 논쟁중에 SoC의 개념을 창시한 Edsger W. Dijkstra (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html) 글을 아무도 인용하지 않았다는 겁니다. 말을 빌리자면 “focusing one’s attention upon some aspect” 입니다. (더 재미난건 실제 논문에는 complexity 라는 단어는 나오지도 않습니다….)
즉 한 곳에 집중할 수 있게 생각하는 것이지요.
복잡성이라는 포괄적인 단어보다는 말 그대로 “걱정거리를 분리”해서 생각하자 라는 의미입니다. 즉 인간의 인지의 한계에 기반을 둔 단어지요. 인간이 거대한 문제를 다 한꺼번에 생각할 수 없으니 나누어서 생각하자 라는 겁니다.
결국 소프트웨어의 복잡성을 줄이는 것보다는 인간의 인지의 한계로 인해 나누어 생각하자는 의미이며, 큰 일을 각각 나누어 처리하는 분업에 가깝습니다.
분업의 장점은
1. 다른 사람이 무슨 일을 하든 상관없이 자기의 일만 하면 됩니다. (장점 – 자신의 일 하나만 생각하면 된다)
단점은
1. 생상공정에 신규 제품 적용이 어렵다
(결국 새로운 요구가 발생하는데는 부적합하다.)
2. 전체 공정 중 일부만 안돼도 생산에 차질을 가져올 수 있다. (arload님이 말한 파문 효과)
결국 Toby님은 장점적인 측면으로 복잡성을 바라 봤고, arload님은 단점적인 측면으로 복잡성을 바라 보았다는 겁니다.
저의 생각으로는 어울리지 않지만 결국 분업으로 보니 결국 두분 말이 다 맞다고 봅니다.
Toby님이 arload님이 적은 글에서 “이 철학으로 인해 너무나 잘게 클래스들이 쪼개져서, 실제 프로젝트를 할때 기능 하나를 추가하기 위해 여러개의 객체를 수정해야 하는 엄청난 고통을 가져오는 상황이 발생합니다.” 라는 부분에서 분업(SoC)이 가져오는 단점을 인지하지 않고 전자의 측면으로만 글을 읽은 면도 있다고 봅니다.
물론 arload님도 “발생합니다 -> 발생하기도 합니다” 라고 적었다면.. 하는 아쉬움도 있습니다. 말 한끝 차이가 너무 큰 댓가를 치르지 않았나 쉽네요..
결국 글을 명확히 못 쓴 부분도.. 그리고 읽으려는 분도. 좀더 면밀하게 글을 읽었으면 그리 충돌나지 않았으리라 봅니다. 두분의 잘못이 서로 있으니 이해하시고 너그러이 넘어갔으면 좋겠습니다.
그리고 영회님은. 좀… 적절한 어휘 선정이 필요할듯 합니다. 인신성 공격의 말은 자제하십쇼. 이번 사건을 통해 영회님은 .. 많은 분들이 실망했을 겁니다… 저를 비롯한 영회님의 팬들도 많은데.. 그런식으로 글을 적으시면 어떻게 하시나요? 논쟁을 떠나 arload님에게는 큰 상처가 되셨을것 같습니다. 남을 대접해야 결국 다른 사람에게 대접받습니다.
arload님!! 지식 나눔 여기서 멈추지 마시고, 나누어 주시길 바랍니다. 🙂 언제오실지 모르지만 기다리겠습니다..
이번 토론은 첫 단추부터 잘 못 끼워진듯합니다. 영수님의 글중 가장 흥미있을만한 것을 제목(‘SoC가 가져오는 복잡성을 극복하는 법’)으로 사용하셨는데 이 제목이 전체 글을 대표하지 못하는 것은 사실입니다.
https://arload.wordpress.com/2009/03/27/seperation-of-concerns-problems/
그러나 그 뒤에 영회님의 적절하지 못한 용어선정(평소에 존경하던 분이라 더욱 실망스러운 면이), 그리고 이런 영회님의 생각을 스스로가 아닌 토비님을 통해서 표현한 것도 약간은 이해가 되지 않는 부분 입니다. 더구나 두 분의 댓글은 너무 오해하기 쉽습니다.
http://toby.epril.com/?p=714
토비님은 정확히 arload님의 포스트의 문제점을 지적하셨습니다.(SoC는 복잡도를 증가시키는가?) 이에 대하여 arload님이 자신의 의도가 아니었음을 밝히셨는데 조금 아쉬운 점은 첫 포스트의 의도 설명이 아니라(자세히 읽으면 나오나) 토비님의 의견에 대한 반박이 이었습니다.
https://arload.wordpress.com/2009/04/01/soc_n_complexity/
이에 토비님이 다시 포스트를 달아주셨는데 이 때부터는 토비님도 감정이 실린 듯한 합니다. (물론 그 사이에 arload님과 메일을 주고 받은 듯 한 내용이 보이긴 합니다만… …)
http://toby.epril.com/?p=714
결국 두 분 모두에게 상처가 되겠지요. (세분 이겠군요.)
http://toby.epril.com/?p=716
https://arload.wordpress.com/2009/04/02/soc_kill_m/
arload님이 너무 큰 상처를 입지 않으셨으면 합니다. 어느 토론이나 그렇듯이 한쪽이 모두 옳고 다른 쪽은 모두 틀릴 수 는 없습니다.
영회님과 토비님도 옳다고 생각하는 바를 행하는 것이 나쁜 것은 아니나, 다른 사람에게 상처를 추는 행위는 다시 생각해보실 필요가 있습니다.
arload님 힘내세요…
안녕하세요
많은 격려의 메세지 감사합니다. 힘내서, 곧 돌아오도록 하겠습니다. 🙂
이번 논쟁으로 인해 전 많은 것을 배웠고, 지식적으로 좀더 갖추어야 하는 부분들을 배웠습니다.
Toby님과 영회님 역시 좋은 지식을 나누어 주시는 분이시므로, 제가 새겨 들어야 할 부분은 새겨 들어야 될듯 합니다. 🙂
물론 저도 아닌건 아닙니다만…
개인적으로 charlz의 말씀에 적극 동감합니다. 결국 도메인에 이것이 될수도 있고 아닐수도 있습니다. 그리고 지적해주신 말씀 잘 새겨 듣겠습니다. 감사합니다.
여러분들에게 SoC 에 대해서 여러가지 고민을 하게 만들었고, 이 논쟁으로 인해 결국 좋은 소프트웨어를 만들기 위한 하나의 징검 다리 역활을 했으면 그걸로 만족합니다.
전 SoC를 절대 노가다의 원횽으로 표현한 적이 없습니다. 다만 SoC를 적절히 나누기가 어렵다는 애기를 하고 싶을 뿐이고, 그걸 잘하기 위해서 EA를 사용해서 해결하는 팁을 공유하고 싶었을 뿐입니다.
(전 SoC를 적절히 어떻게 나누냐가, 아키텍팅의 Key라고 생각하고 있습니다.)
혹시나 SoC에 대해서 좀더 깊게 생각하실 분이 있다면, 좋은 글을 하나 발견했습니다.
challenge problems for separation of concerns – http://www.cs.cmu.edu/~aldrich/papers/challenge.pdf
혹시 저처럼 SoC 를 하면서 고충을 느끼시는 분에게는 좋은 자료가 될듯 합니다. 읽어 보시면, SoC 하실때 도움이 될듯 합니다.
어서 마음을 정리해서 돌아오겠습니다. 그때까지 모두 건강히 계세요.
ps) 그리고 저나 반대쪽으로 악플을 다신 몇분 들에게.. 일단 서로의 입장을 이해해 주시길 정중히 부탁드립니다.
이것이 서로 상대방측에 더 이상 상처가 되지 않았으면 합니다. 여기서 그만 해주시길 정중히 요청드립니다.
더 이상 이 논쟁이 가해져, 커뮤니티 간에 싸움으로 까지 번지지 않길 바라고 있습니다.. 서로의 길을 열심히 걸어갔으면 합니다.
Frame효과라는 것이 있습니다.
저의 블로그를 통해 다른 두분의 글을 보신 분은 그분들을 안좋게 보실수 밖에 없고, 또한 저 역시 평소 Toby님이나 영회님의 블로그 애독자분들이 저의 블로그를 보면 저를 안 좋게 보실수 밖에 없습니다.
디키님이 말씀하신 것처럼 양측간에 더 이상의 피해는 원치 않습니다.
어느 분의 말처럼 고개를 숙이고 살때니, 너그러이 이해해 주시길 바랍니다. 감사합니다..
정말 떠날 필요가 있는지 모르겠습니다.
아키텍처에 정답이 있다고 누가 그러던가요?
정답 없습니다. 검증 쉽지 않구요…
그참…. 의견도 맘대로 인터넷에 못쓰겠네요 -_-
이러한 상황들이 연출 되면 애독자의 한 사람의로서 안타깝습니다…….더 나은 것을 위해 생각과 의견을 공유 하고자 하는데.. 아직 우리네 의식 수준이 여기까지 밖에 안되는가 하는 아쉬움이 남습니다.
무언가로 무장을 해야하고 그것으로 성처를 남기고..
씁슬합니다.
arload님 힘내세요…
마음 추스리고 다시 뵙수있길 기대 해 봅니다..