후하하핫
9k
2021-12-05 18:38:26
27
4660

학생 때 디자인 패턴을 배워야 / 공부해야 할까?


디자인 패턴하면 어떤 것들이 떠오르실 지 모르겠지만, 저는 Singleton, Adapter, Proxy와 Producer-Consumer Pattern, Pub Sub 모델 같은 것들이 떠오릅니다. MVC나 MVVM, MVP 같은 것들이 떠오를 수도 있겠네요. 

저는 처음 Hello World! 를 출력한 날로부터 20년이 다 되어가는 사람으로서, 그리고 현업의 경험이 경력직으로서 의미있는 정도가 된 사람으로서 제 생각을 남기자면 학생 때 디자인 패턴을 배우는건 시간 낭비라고 생각합니다.


1. 개발 방법론은 유행을 따른다.

20년의 프로그래머 인생에서 수많은 설계 철학과 개발 방법론들이 떴다가 사라지고, 개발 방법론이 나타났다 사라지는 것들을 봐왔습니다.

- 그 당시엔 eXtreme Programming만 하면, Scrum만 하면 모든 문제가 해결될 거라고 (저조차도) 믿었던 순간들이 있었습니다. Scrum은 결국 살아남았지만 XP는 아마 지금 시작하시는 분들은 이름조차 모르실 것이라고 생각이 드네요.

- Code Complete 같은 책은 그 시절에는 명저였으나 (특히 설계나 테스팅이 아닌 구현의 측면에서 바라본다는게 신박한 책이었죠) 그 책의 어떤 부분은 유통기한이 지났다고 생각합니다.

예를 들어, if (3 == a) 와 같은 식으로 코딩을 하면 if (a = 3) 과 같이 동등비교 연산자와 대입 연산자를 헷갈릴 가능성이 줄어든다는 얘기가 유명했는데, 사실 지금 시점에서 생각해보면 저런 방식의 실수는 IDE가 잘 잡아주고, readability를 해치는 방식이 될 수 있기 때문에 권장되진 않습니다.

같은 맥락으로, 디자인 패턴 역시 개발방법론으로서 유행을 따릅니다. Singleton이 좋다고 했다가, 악이라고 했다가 논쟁이 참 많았지만, 결론은 살아남는 패턴이 강한 패턴인 것이고 Singleton을 개떡같이 쓰면 안좋고 잘 쓰면 좋은 것이죠. 이런 유행 논쟁에 뛰어 들어서 이익을 보는건 사기꾼 아니면 최첨단에 계신 분들인거고, 학생들은 시간만 날릴 뿐입니다. 나중에 진짜 자기가 판단해야 할 때는 이미 죽은 지식이 될거니까요.


2. 디자인 패턴은 쉽다. 혹은 쉽게 공부할 수 있다.


가장 중요한 학생 때 디자인 패턴을 공부하지 말아야 할 이유는 디자인 패턴이 쉽다는 겁니다. 애초에 개념적으로 이해가 어려운 패턴은 진짜 진짜 용도가 좋지 않은 이상에야 살아남기 힘듭니다. 개발자들이 자주 써와야 그게 패턴이 되는 거니까요.


그런 의미에서 디자인 패턴 책을 보는걸 바라보는 마음은 좀 복잡합니다. 애초에 production level의 코드 (진짜 product이든 open source든…) 를 많이 본 사람 입장에서는 디자인 패턴 책을 쭉 훑으면서 ‘오, 내가 아는 스타일이 패턴이랍시고 이름이 붙여져 있구나? 이런 장단점도 있네?’ 하면서 리뷰를 하는 것은 (솔직히 말하면 이것도 좀 시간 낭비라고 생각하긴 하지만) 그래도 괜찮다고 생각합니다만, 안그래도 공부를 해야 할게 많고 어렵고 시간 낭비 같아도 기초를 갈고 닦아야 하는 황금같은 학생 때 디자인 패턴 책 보고 외우고 있으면 그건 참 안타깝습니다. 차라리 그 시간에 소스코드를 직접 읽거나, 직접 짜면서 진짜 needs를 느끼거나, 그것도 아니면 그냥 청춘을 즐기며 노는게 나을텐데요. 어차피 그때 읽었던 디자인 패턴은 기억에 남지 않을 것이고, 지금 공부를 안해도 나중에 코드를 읽다보면 자연스럽게 이해하게 될 것이기 때문에요.


3. 진리의 No silver bullet.


“No Silver Bullet”은 튜링상을 받은 Fred Brooks 박사가 1986년에 쓴 책의 제목입니다. 소프트웨어 엔지니어링의 역사에서 하나의 기술, 하나의 개념의 발전이 order of magnitude의 향상을 가져다 준적이 없다는 것이 책의 요지입니다.

저는 소프트웨어 엔지니어링, 특히 개발 방법론 측면에서의 소프트웨어 엔지니어링에서 가장 맞는 말이 No silver bullet이 아닌가 싶습니다. 수많은 기술과 유행이 마치 자신만 있으면 세상의 모든 문제를 해결하고 개발 생산성을 올려줄 것으로 이야기 하지만, 실제 그런 기술은 86년에 바라봐도 없었고 지금 바라봐도 별로 없습니다.

어떠한 기술이 실제 우리의 삶을 바꾸게 되는 것은 그 기술의 철학이나 아름다움, 논리적 완결성 같은 이유가 아니라, 실제 우리가 당면한 문제들을 하나씩 맞서 싸워가다 보면서 생기는 needs들과 그 needs들을 풀면서 쌓여간 역사가 존재함으로 인해 발생하는 일이라고 생각합니다. 이건 비단 소프트웨어 엔지니어링이 아니라 공학이라는 것의 역사가 그랬듯 그렇습니다.


요약하면 지금 현실에 닥친 문제를 해결해 줄 멋지고 깔끔한 정답은 아마도 없습니다. 그러니 천재 철학자가 되지 마시고, 손을 더럽힐 줄 아는 엔지니어가 되시는걸 추천합니다.


4. 정리

정리하면, 학생분들, 디자인 패턴 공부하지 마시고 그 시간에 진짜 문제에 부딪혀 보세요.

면접관 분들, 디자인 패턴 모른다고 꼽주지 마세요. 그걸 기대하는 자신의 문제는 아닐까 한번 생각해 보세요.



19
6
  • 댓글 27

  • fender
    26k
    2021-12-05 22:16:45 작성 2021-12-05 22:21:18 수정됨

    저는 이 부분은 조금 생각이 다릅니다. 물론 프로그래밍에 있어서 '은탄환'이 없다는 건 진리에 가깝기 때문에, 저도 디자인패턴이나 특정 방법론 등을 교조적으로 떠받드는 것을 옹호할 생각은 없습니다.

    하지만 XP나 싱글턴 패턴 같은 것을 어떤 절대적인 것으로 공부해서 외우고 면접에서 암기여부를 물어볼 필요가 없다는 것과, 그런 개념이 등장한 흐름을 무시해도 좋다는 것은 좀 다른 이야기라고 봅니다.

    말씀대로 지금 XP를 기억하는 사람은 별로없고 스크럼도 많은 비판에 직면해 있다 쳐도, 그런 방법론이 제기한 문제의식은 상당부분 여전히 유효합니다. 즉, 더 이상 XP를 이야기하지 않는다고 해도 그것이 곧 RUP나 폭포수 모델이 상식이던 시대로 돌아가진 않는다는 것입니다.

    디자인 패턴도 비슷합니다. 지금 시점에 특정 패턴이 더 이상 쓰이지 않거나 언어 자체가 제공하는 기능으로 대체되었다고 해도, 그런 패턴에 내재된 고민을 이해하는 것은 여전히 중요하다고 생각합니다.

    소프트웨어 프로젝트를 진행하는데 짧은 주기의 반복을 통해 점진적으로 변화하는 요구조건에 대응하는 것이 유용하다던지, 아니면 if-else를 길게 늘여뜨려 가독성을 떨어뜨리고 불필요한 커플링을 만드는 상황을 팩토리로 대체할 수 있다던지 하는 종류의 깨달음(insight)은 암기로 얻을 수 있는 것이 아닐지는 몰라도, 그렇다고 혼자서 수련하듯 코딩만 하다보면 누구나 자연스럽게 깨닫게 되는 내용도 아닌 것 같습니다.

    그런 문제의식이나 해결을 위한 접근 방법은 소프트웨어 공학이 발달하면서 변화하기는 해도, 좋은 개발자라면 코딩을 하는 그 시점에 널리 좋은 관행으로 알려진 방법들을 능숙하게 적용할 수 있어야 하고, 다른 사람이 그렇게 작성한 코드 역시 이해할 수 있어야 합니다.

    말씀하신 것처럼 그런 방법론이나 패턴 등은 실무에서 오랜 기간 수 많은 개발자들이 고민과 시행착오를 거친 역사이고 끊임없이 변화하는 흐름의 일부입니다.

    그 흐름의 특정 시점을 잘라내서 무작정 암기를 하고 교조적으로 적용하는 것이 좋지 못하다고 해서, 아예 그런 흐름이 있는지, 어디로 가는지에 무관심한 상태로 코딩에만 집중하면 어느 시점엔가 자연스럽게 그걸 모두 깨닫게 되는 것도 아니라고 봅니다.

    모든 개발자가 그게 가능했다면 애초에 방법론이나 설계 관행의 발전에 수 많은 개발자의 시행착오가 필요하지도 않았을테니까요.

    이 부분에 대해 낙관적인 생각을 하기엔 솔직히 전 경력이 10년, 20년 넘은 개발자들이 조건문, 반복문 수준 이상의 고민의 흔적이 전혀 느껴지지 않는 코드를 양산하면서 무엇이 문제인지 조차 이해 못하는 것을 너무 흔하게 보았습니다.

    그래서 저는 방법론이나 패턴이나 이런저런 개발 관련한 개념들은 암기보단 일단 이해하고 직접 실무에 적용해보고 넘어가면 그 것으로 족하다고 생각합니다.

    이를 이해없이 암기하는 것이 나쁜 습관이라면 애초에 이해하려는 시도 조차 하지않는 것도 적어도 그 만큼은 위험한 접근인 것 같습니다.

  • 엡실론
    3k
    2021-12-06 07:07:26

    어느 정도 공감가는 바는 있습니다.

    디자인 패턴 같은 건 어느 정도 코드를 써보고 유지 보수를 해 본 경험이 있어야 더욱 잘 이해되는 면이 있다고 봅니다. 간단한 자료구조, 알고리즘 정도의 코드에서 디자인 패턴을 잘 이해해서 활용할 여지는 거의 없습니다. 어느 정도 프로젝트를 해봐야 유지보수의 어려움, 가독성에 대한 이해도 생기고, 새로운 패턴을 봤을 때 뭐가 좋은지를 쉽게 이해할 수 있는 것 같습니다.

    학생때 그 정도 경험을 쌓는 분도 많지만, 아닌 경우도 있죠. 결론적으로 디자인 패턴을 봤을 때 이게 왜 좋은건지가 보이면, 공부할 가치가 있습니다. 그렇지 않고, 왜 좋은지 모르겠지만 해야 된다니까 보는 거라면 조금 더 미루기를 권하고 싶습니다.

    하지만 공부의 방법이라는게 결국 개인의 취향 문제인 것 같네요. 예컨데 무언가를 배울때 정확한 이론과 방법을 익히고 실습을 하느냐, 또는 일단 실습을 해보고 문제를 느끼고 거기에 대한 이론을 배우느냐 정도의 차이 인 듯 합니다. 저는 개인적으로 후자가 취향이고, 그걸 더 추천하긴 하지만, 성격에 따르는 문제겠죠.   

  • shirohoo
    2k
    2021-12-06 09:16:12 작성 2021-12-06 09:19:24 수정됨

    XP는 놀랍게도 작년에 개정된 정보처리기사 시험에서 꽤 비중있게 다루는 부분입니다... ㄷㄷ


    2년차 개발자로서 보기에 디자인패턴 공부하는게 그래도 시간낭비는 아니었다고 생각되는게, 기존에 작성된 프로덕션 코드들을 이해하는데 큰 도움이 됐다는 부분입니다.


    특히 프레임워크의 구조와 동작원리를 이해하는데 아주 큰 도움이됐어요. 

  • 하마
    8k
    2021-12-06 11:56:41 작성 2021-12-10 15:33:00 수정됨

    무리한 결론인거 같습니다.  

    즉 A,B 모두가 필요한 상황에서 A를 강조하기 위해 지나치게 B를 등한시 하는 것 같습니다.
    혹시나 공부하시는 학생분들이 오해 할 까 걱정이 됩니다. 

    님 께서 말한 열심히 코딩을 해보는 (손을 더럽히는 )과정을 많이 겪어야하는 건 맞으며 그것이 더 중요하다고 봅니다.
    하지만  전부 그것에만 치중한다면 굉장히 비효율적인 공부법이라고 생각합니다. 
    일부 시간은 선대에 이뤄놓은 깨우침을 공부해보는 것은 많은 도움이 됩니다. 
    패턴은 구조를 공부(외우는)하는게 아니라 의도를 공유하는 것입니다. 눈을 넓히는 중요한 과정이죠. 뛰어난 학생이라면 그것이 필요하다는것을 스스로 알게 될 가능성이 크죠


  • 장독깨기
    5k
    2021-12-06 11:58:25

    "진짜 문제에 부딪혀 보세요"  이 부분이 특히 중요해 보입니다.

    학생 또는 입문하시는 분들 새겨 들으면 좋을 거 같네요. :)

  • ISA
    6k
    2021-12-07 13:09:29

    둘다 하면 안되나요?

    시간이 부족하지만..

    시간과 예산을 조금 더 주신다면...

  • 후하하핫
    9k
    2021-12-07 13:21:04

    대략적인 분위기는 그래도 디자인 패턴이 도움이 된다는 맥락인 것 같아서, 그에 대한 제 생각을 남깁니다.


    제 질문은 학생 때 디자인 패턴을 공부하는 것이 의미가 있냐는 것입니다.


    프로페셔널이 된다면 필요에 따라 공부를 할 수 있지만 (그래도 전 비추하지만...), 최소한 학생 때는 가성비가 안나오는 공부라고 생각합니다.


    디자인 패턴을 공부하는 게 물론 도움이 되겠죠. 하지만 같은 정도로 무엇을 공부하던 도움은 됩니다. 특히, 디자인 패턴은 말씀 드린대로 공부하는게 어렵지 않고, 짬이 쌓인 다음에는 훑어 보는 것만으로도 이해가 쉬운 영역이라고 생각합니다.


    그에 반해, 학생 때만 할 수 있는 공부들이 있습니다. 시스템에 대한 이해, CS fundamental에 대한 이해, 시간 낭비가 아닐까 싶은 삽질, 수학이나 물리학의 교양, 영어와 글쓰기, 친구들과 협동하는 시간 등등... 이런 것들은 중요한 경험을 주지만, 학교 바깥에서 하기에는 환경이 받쳐주지 않거나 효율이 극히 떨어지는 활동입니다.


    예를 들어 제가 채용을 한다면 (전제는 돈이 충분히 많고 포텐이 큰 사람을 뽑아야 하는 상황, 쓰고 버릴 사람 X), 디자인 패턴이나 소프트웨어 공학의 트렌드를 읊는 학생보다 알고리즘, 수학 잘하고 CS fundamental 튼튼한 사람을 뽑을 것 같습니다. 혹은 특정 분야 하나를 끝까지 파본 사람이나요. 트렌드는 그냥 Software Engineer로 살다보면 주워 듣는 것으로도 커버가 가능하지만, 저렇게 의식적으로 노력하여 만드는 결과는 돈을 줘서 구할 수 있는 성질의 것이 아니기 때문입니다.


    그래서 저의 결론은, 디자인 패턴을 학생 때 하는 것이 시간 낭비라는겁니다. 그 외에 해야 할 공부들이 많고, 프로가 되기 전 아마추어로서 밟아야 하는 과정들이 충분히 많다는 것입니다. 손을 더럽히는 것의 효율이 낮아보일 수 있지만, 그렇기 때문에 아마추어 때 그런 일들을 많이 해봐야 하는 것이지요.

  • choju
    1k
    2021-12-07 15:03:21

    학생때 디자인패턴 같은거 넣을필요가 없다고 생각합니다.

    컴퓨터를 다루는 기초적인 블록만 쥐어주면 된다는 생각입니다. 

    뭐 디자인패턴도 블록이 될 수도 있겠습니다만....

    그 목적이 무엇이냐... 학생들은 개인개발자가 될 수도 있고, 어디 소속되서 개발할 수도 있고, 그냥 개발의 인사이트만 가지고 다른일을 할수도있고.. 방향성이 무궁무진한대

    디자인패턴처럼.. 패턴화 시켜서 무언가를 해야 할일은... 그 패턴이 필요한 곳에서 배우면 될것 같습니다.



  • 하마
    8k
    2021-12-07 16:32:30 작성 2021-12-10 10:34:10 수정됨


    "디자인패턴만 읊는 사람 vs 알고리즘, 수학 잘하고 CS fundamental (자료구조,알고리즘 등등) 튼튼한 사람"

    이렇게 극단적으로 비교되면 안되겠지요. 

    그냥 선현들의 패턴 감각도 익히는 분이라면 다른 것도 더 잘 알고 있을 가능성이 크지 않을까요? 
    코딩을 열심히 한 학생은 당연히 선현들은 어떻게 짜는지에 대한 호기심이 생기기 마련이겠지요.
    그렇게  열심히 한 학생이라면 -백엔드를 파보다가- 엔터프라이즈 아키텍쳐 패턴들을 보고 유레카를 왜 치게 될 것이며 - 컴파일러로 손에 흙묻히다가 - 인터프리터 패턴과 ADT 구조를 보고 한단계 더 발전하게 될 것입니다. 

    예를들어 건축학 쪽에서도 수많은 디자인패턴책들이 있습니다.(https://www.arch2o.com/50-architecture-books-make-best-architect/) 이런 책을 보는 건축학 학생이라면 1,2학년때 기본과정 및 구조공학도 잘하리라 유추가능한거 같습니다. 

    학습이란 단계별로 이루어집니다. C언어를 익히고 자료구조 익히고 컴파일이 되는 과정등을 익히는 것과 마찬가지로
    코딩이 익숙해지고 나서는 설계에 대한 눈을 넓혀보는 과정 역시 중요합니다. 이런 과정은 학부 후반기때 이루어져야 합니다. 유명한 건축가의 작품을 관찰하고 음미하거나, 여러가지 형태에 대한 공통 추상화를 해 보는 습관은 후에 실전에서 자신의 결과물의 수준을 가를것이며, 성장해 나가는데 큰 반석이 될 거라고 봅니다. 

    결과적으로 아무것도 모르고 패턴만 공부하는 것은 당연히 잘못된 학습방법임에는 틀림없습니다만, 
    무작정 패턴구조를 외울필요는 없습니다. 어느정도 기본이 다져진 상태에서 의도를 공감해가면서 패턴을 공부한다는 것은 바퀴를 재발명하지 않아도 되고,책으로도 과거의 천재들과 대화해보는 간접 경험을 할 수 있게 되는 것 입니다. 굳이 아예 하지마라 라고 말하는건 경솔 한거 같습니다.


    좋은 책을 읽는 다는 것은 과거의 가장 훌륭한 사람들과 대화하는 것이다 - 데카르트

  • 후하하핫
    9k
    2021-12-07 17:17:47

    @하마: 정확히 제가 말씀 드린건 "디자인 패턴이나 소프트웨어 공학의 트렌드를 읊는 학생보다 알고리즘, 수학 잘하고 CS fundamental 튼튼한 사람을 뽑을 것 같습니다" 라는 문장인데요, 생각보다 신입 채용을 할 때 벌어지는 문제라고 생각합니다.


    A 학생은 RxJava도 써봤고, TDD도 해봤고, MVVM 패턴을 써서 앱을 디자인해 봤다는 점을 어필합니다. B 학생은 학부 수업 열심히 듣고, C랑 Java, Python 정도를 할줄 아는 상태에서 알고리즘 대회에서 좋은 수상실적을 갖고 있습니다.


    이 중에 어떤 학생이 더 가능성이 크냐고 물어봤을 때, 정답이 있는 문제가 아니지만 (각자의 preference는 있겠죠? && 그리고 전자의 학생도 굉장히 프로그래밍을 사랑하는 가능성이 큰 학생이긴 하지만), 저는 개인적으로 후자의 학생은 전자의 학생이 익힌 기술을 1년안에 익힐 수 있다고 보지만 반대 방향은 더 긴 시간이 필요할거라고 생각합니다.


    이런 sense에서 저는 디자인 패턴을 학부 때 공부하고, 트렌드를 학부 떄 따라가는 것에 대해서 시간이 아깝다고 여기는 입장입니다. 이론은 있을 수 있지만요!


    추가로, 저는 개인적으로 설계 능력이라는 가치가 과대평가 된 가치라고 생각합니다. 소프트웨어 엔지니어가가져야 하는 R&R은 최근에 굉장히 많아졌고, 설계를 잘하는 사람이 맡아야 하는 job도 있지만 그 능력만큼이나 다른 영역의 능력을 가져야 하는 방향도 너무나 많습니다. (DevOps, Machine Learning, Perception Engineer...)


    예를 들어서, 네이버에 가서 사내 graph database를 만드는 일을 한다고 합시다. graph database를 잘 만들기 위해서는 디자인 패턴이 그렇게 큰 영향을 끼치지 않습니다. 인터페이스적인 requirement가 어느정도 정해져 있고, 기존에 DB의 interface에 대한 역사가 길기 때문에 설계에서 선택할 요소가 이미 어느정도는 정해져 있거든요. 이때 더 필요한 능력은 DB와 OS를 잘 이해하고, 시스템에 대해서 이해를 하는 것인데, 이건 코딩 많이 해보고 잘한다고 잘할 수 있는 영역이 아니라 말그대로 CS 기초가 있어야 하는 일입니다.

    다른 예를 들어봅시다. Software Engineer로서 스노우에 갔다고 합시다. 이미 머신러닝 리서처가 돌려야 하는 vision 모델을 만들어 놓았고, 그걸 고성능으로 돌려야 합니다. 이런 상황에서는 디자인 패턴은 무쓸모고, 도메인을 빠르게 이해하고 최적화하기 위한 코드를 작성할 줄 아는 능력이 필요하죠.

    블락체인을 만드는 스타트업이 있다고 합시다. 분산 시스템을 만들어야 하는데, 여기서도 protocol은 이미 정해져 있습니다. 디자인 패턴보다는 역시 시스템에 대한 이해가 더 중요할 수 있죠.


    이게 domain specific한 문제이고, 모든 프로그래머가 고려해야 하냐? 라고 생각을 한다면, 저는 Software Engineer가 해야 하는 R&R이 폭발적으로 늘어나고 있고, 새롭게 부딪혀야 하는 새로운 응용들이 쏟아지고 있다고 생각합니다. 미래에는 더 그럴거라고 보고요. 그런 관점에서는 "패턴"을 답습하는 것보다 새로움을 만들어 낼 수 있는 fundamental을 길러야 합니다.


    제가 안타까운건, 학교의 학생들이 fancy한 buzzword들에 홀리는 경우가 많거나, 웹서비스나 앱 개발자로 시야가 좁혀진 경우가 많기 때문에, 저런 fundamental 보다는 새로 나오는 멋진 기술에 집중하는 흐름이 없지 않다는 것입니다. process와 thread의 차이도 제대로 얘길 못하면서 Go 언어로 goroutine을 짜고 있거나, 아마추어 수준에서 앱을 만들면서 생산성을 고려한답시고 곧 지나가버릴 트렌드를 공부하거나... 전 이게 참 안타깝습니다. 진짜 문제를 풀어야 할 시간에 답습이라뇨.


    정리하면 학생은 무궁한 가능성을 보고 미래를 바라봐야 하는데, 디자인 패턴이라는 가치 하나만 놓고 보면 이 토픽이 해당 학생의 미래에 도움을 줄 수 있는 영역은 제한적이고, 그마저도 취업을 한 후에 갖추기 너무 쉬운 능력이라는 얘길 하고 싶었습니다. 학생이 학교에서 뽑아먹을 것을 잘 뽑아먹고 시간이 남아서 본다면 모를까, 필수적이라고 말하기에는 어폐가 있다고 생각합니다.

  • fender
    26k
    2021-12-07 17:18:46
    학생때 디자인패턴 같은거 넣을필요가 없다고 생각합니다.
    컴퓨터를 다루는 기초적인 블록만 쥐어주면 된다는 생각입니다. 
    뭐 디자인패턴도 블록이 될 수도 있겠습니다만....
    그 목적이 무엇이냐... 학생들은 개인개발자가 될 수도 있고, 어디 소속되서 개발할 수도 있고, 그냥 개발의 인사이트만 가지고 다른일을 할수도있고.. 방향성이 무궁무진한대
    디자인패턴처럼.. 패턴화 시켜서 무언가를 해야 할일은... 그 패턴이 필요한 곳에서 배우면 될것 같습니다.

    GoF 같은 고전 객체지향 패턴의 유용성이 시간이 지나면서 얼마나 변했는가에 대한 논란은 접어두고, 지금 맥락에서 이야기하는 '패턴'이란 것은 틀에 맞춰서 페이지를 찍어낸다던지 그런 걸 뜻하는 것은 아닙니다.

    -2
  • fender
    26k
    2021-12-07 17:33:30 작성 2021-12-08 10:13:50 수정됨

    A 학생은 RxJava도 써봤고, TDD도 해봤고, MVVM 패턴을 써서 앱을 디자인해 봤다는 점을 어필합니다. B 학생은 학부 수업 열심히 듣고, C랑 Java, Python 정도를 할줄 아는 상태에서 알고리즘 대회에서 좋은 수상실적을 갖고 있습니다.


    이 중에 어떤 학생이 더 가능성이 크냐고 물어봤을 때, 정답이 있는 문제가 아니지만 (각자의 preference는 있겠죠? && 그리고 전자의 학생도 굉장히 프로그래밍을 사랑하는 가능성이 큰 학생이긴 하지만), 저는 개인적으로 후자의 학생은 전자의 학생이 익힌 기술을 1년안에 익힐 수 있다고 보지만 반대 방향은 더 긴 시간이 필요할거라고 생각합니다.

    저는 A 학생이 RxJava를 능숙하게 쓰고 파이썬으로 TDD에 익숙하다면, 단지 알고리즘 연습을 안했다고 B보다 잠재력이 부족할 거란 생각이 들진 않습니다.

    그렇다고 A를 마치 국비학원 수강생이 스프링을 "써봤다"와 비슷한 수준에서 그런 주제를 접해본 것으로 가정한 것이라면 애초에 B를 알고리즘 대회 수상을 할 만큼 능력있는 학생으로 전제한 것부터 공정하지 못한 비교인 것 같습니다.


    이게 domain specific한 문제이고, 모든 프로그래머가 고려해야 하냐? 라고 생각을 한다면, 저는 Software Engineer가 해야 하는 R&R이 폭발적으로 늘어나고 있고, 새롭게 부딪혀야 하는 새로운 응용들이 쏟아지고 있다고 생각합니다. 미래에는 더 그럴거라고 보고요. 그런 관점에서는 "패턴"을 답습하는 것보다 새로움을 만들어 낼 수 있는 fundamental을 길러야 합니다.

    말씀대로, 예시로 드신 내용은 특별히 도메인 자체가 저수준의 CS 지식을 요구하는 사례입니다. 그것을 일반화 할 수 있으려면 보다 고수준을 주로 다루는 개발자는 위의 A, B 두 개발자의 사례처럼 기본적으로 저수준 개발자보다 능력이 부족하다고 가정을 해야하는데 전 그 부분에 대해선 후하하핫 님과는 생각이 크게 다릅니다.

    그리고 디자인 패턴에서 새로움을 만들어 내는 것은 기존 패턴을 깊게 고민해보지 않고 알고리즘 같은 주제를 갈고 닦은 저수준 개발자가 아니라, 보통 아키텍트로 고수준 분야의 경험을 오래 쌓은 개발자의 역할입니다.

    -2
  • 하마
    8k
    2021-12-07 17:38:18 작성 2021-12-10 10:27:59 수정됨

    논점이 너무 많아지고 있고, 극단적 비교도 심해져서 무엇을 말해야 할지 모르겠는데요..
    님의 마지막 댓글에 대해서 그냥 저도 제 생각을 다시 말해 볼께요. 마지막으로요~~~~

    패턴은 선현의 지혜입니다. 블록체인코어를 만들때도, 데이타베이스를 만들때도 님이 생각하는 것보다
    더 영향을 미치게 됩니다. 소프트웨어는 그냥 돌아가게 만들고나서 끝나는 것이 아니라 유기물입니다. 
    계속 관리되야 하며,많은 사람들이 계속해서 읽어봐야 할 레거시들입니다. 발전시켜나가야 하고요..

    님께서 생각하는 것보다 더더욱 단순 스펙,프로토콜 이상의 것들이 필요하다고 생각합니다...
    그리고 결코 쉬운게 아니에요... 데이터베이스를 만드는것과 잘 설계된 데이터베이스를 만드는것은 천지차이입니다.
    프로세스,,파일구조,B트리,알고리즘을 (개별기술 자체를) 알고있다고 데이터베이스를 잘 만드는건 아닙니다. 

    간단한 데이터베이스를 만드는데에 스토리지 단에 Abstract Factory, Builder, Iterator, Stretegy 트랜잭션엔 Command  SQL 엔진만드는데 Interpretor패턴,FlyWeight, Chain of Responsibility,Proxy을  Cursor,ResultSet에는 Adaptor등이 사용 될 수 있습니다. 선현들이 저런 것을 기록해 놓았을 땐 단지 외워서 면접 잘 봐라~라는 단순의미가 아닙니다.

    지혜가 합의되어서 응축되서 만들어 진 것 입니다. 세상의 모든일은 그 웅축되어 만들어진 것 보다 훨씬 다양하게 발생하게 되는데, 이미 있는 것에 대한 선제 학습은 확장,발전에 도움이 되게 마련입니다. 

    각자 경험한바가 다르고,  분야 및 무게중심의 위치가 다르기 때문에 사람에 따라서 다르게 생각하는것은 당연하다고 생각합니다.

    그럼 수고하세요 ^^ 


    -1
  • 후하하핫
    9k
    2021-12-07 17:48:15

    @하마: 죄송하지만 저도 Software Engineer로서 NoSQL 개발하는 조직에 들어있었고, NoSQL 오픈소스 중 이름을 들으면 아실만한 곳의 커미터로 일을 했습니다. 말씀하시는 내용을 다 이해하는데, 그럼에도 불구하고 학생이 디자인 패턴을 배울 필요가 없다고 생각을 하는거고요.

  • 후하하핫
    9k
    2021-12-07 17:49:24

    @fender:

    학생때 디자인패턴 같은거 넣을필요가 없다고 생각합니다.
    컴퓨터를 다루는 기초적인 블록만 쥐어주면 된다는 생각입니다. 
    뭐 디자인패턴도 블록이 될 수도 있겠습니다만....
    그 목적이 무엇이냐... 학생들은 개인개발자가 될 수도 있고, 어디 소속되서 개발할 수도 있고, 그냥 개발의 인사이트만 가지고 다른일을 할수도있고.. 방향성이 무궁무진한대
    디자인패턴처럼.. 패턴화 시켜서 무언가를 해야 할일은... 그 패턴이 필요한 곳에서 배우면 될것 같습니다.

    GoF 같은 고전 객체지향 패턴의 유용성이 시간이 지나면서 얼마나 변했는가에 대한 논란은 접어두고, 지금 맥락에서 이야기하는 '패턴'이란 것은 틀에 맞춰서 페이지를 찍어낸다던지 그런 걸 뜻하는 것은 아닙니다.


    저도 그 뜻이 아닙니다 ㅎㅎ 저도 디자인 패턴 공부했고, 소프트웨어 엔지니어로서 회사에서 업무를 잘 수행하고 있습니다.

  • 후하하핫
    9k
    2021-12-07 17:53:09

    @fender:

    A 학생은 RxJava도 써봤고, TDD도 해봤고, MVVM 패턴을 써서 앱을 디자인해 봤다는 점을 어필합니다. B 학생은 학부 수업 열심히 듣고, C랑 Java, Python 정도를 할줄 아는 상태에서 알고리즘 대회에서 좋은 수상실적을 갖고 있습니다.


    이 중에 어떤 학생이 더 가능성이 크냐고 물어봤을 때, 정답이 있는 문제가 아니지만 (각자의 preference는 있겠죠? && 그리고 전자의 학생도 굉장히 프로그래밍을 사랑하는 가능성이 큰 학생이긴 하지만), 저는 개인적으로 후자의 학생은 전자의 학생이 익힌 기술을 1년안에 익힐 수 있다고 보지만 반대 방향은 더 긴 시간이 필요할거라고 생각합니다.

    저는 A 학생이 RxJava를 능숙하게 쓰고 파이썬으로 TDD에 익숙한 개발자가 단지 알고리즘 연습을 안했다고 B보다 잠재력이 부족할 거란 생각이 들진 않습니다.

    그렇다고 A를 마치 국비학원 수강생이 스프링을 "써봤다"와 비슷한 수준에서 그런 주제를 접해본 것이라면 애초에 B를 알고리즘 대회 수상을 할 만큼 능력있는 학생으로 가정한 것부터 공정하지 못한 비교인 것 같습니다.


    놀랍게도, 생각보다 후자 학생이 전자보다 취급이 좋지 않은 경우가 있습니다. 또한 수상을 할 정도의 알고리즘 문제를 푸는 실력은 단순히 연습을 했는지 안했는지의 수준이 아닙니다.


    이게 domain specific한 문제이고, 모든 프로그래머가 고려해야 하냐? 라고 생각을 한다면, 저는 Software Engineer가 해야 하는 R&R이 폭발적으로 늘어나고 있고, 새롭게 부딪혀야 하는 새로운 응용들이 쏟아지고 있다고 생각합니다. 미래에는 더 그럴거라고 보고요. 그런 관점에서는 "패턴"을 답습하는 것보다 새로움을 만들어 낼 수 있는 fundamental을 길러야 합니다.

    말씀대로, 예시로 드신 내용은 특별히 도메인 자체가 저수준의 CS 지식을 요구하는 사례입니다. 그것을 일반화 할 수 있으려면 보다 고수준을 주로 다루는 개발자는 위의 A, B 두 개발자의 사례처럼 기본적으로 저수준 개발자보다 능력이 부족하다고 가정을 해야하는데 전 그 부분에 대해선 후하하핫 님과는 생각이 크게 다릅니다.


    그리고 디자인 패턴에서 새로움을 만들어 내는 것은 기존 패턴을 깊게 고민해보지 않고 알고리즘 같은 주제를 갈고 닦은 저수준 개발자가 아니라, 보통 아키텍트로 고수준 분야의 경험을 오래 쌓은 개발자의 역할입니다.



    그냥 specialty의 문제인건 이해합니다만, 저는 일반적인 학생들을 고려했을 때 모든 학생들이 고수준으로 가야 한다고 생각하지 않고, 학생 때 쌓을 수 있는 고수준에 대한 경력에 대한 효율과 회사에 들어갔을 때 쌓을 수 있는 효율 중에 후자가 월등히 낫다고 생각하는 것 뿐입니다. 그래서 말그대로 학생 때 디자인 패턴을 공부하는게 시간이 아깝다는 뜻이죠. 모두가 고수준을 할 필요가 없고, Architect가 가장 잘하거나 가장 영향력이 큰 사람이 아닌 프로젝트도 굉장히 많은데요.

  • 후하하핫
    9k
    2021-12-07 17:59:47

    제가 좀 클리어하게 쓰지 못한 것 같아서 제 입장을 갈무리 하면, 저는 말그대로 학생 때 디자인 패턴을 공부할 필요도 없고 효율도 떨어진다는 얘길 하고 싶었습니다. 디자인 패턴은 굉장히 실용적인 영역이고, 그 영역에 대해 학생 때 공부해 봤자 실제로 회사나 오픈소스 커뮤니티에서 코딩을 하다 보면 다시 깨닫게 되거나, 그냥 안배웠어도 나도 모르게 쓰고 있을 확률이 높거든요.

    저는 살아있는 공부가 가장 좋은 공부라고 생각합니다. 문자로 쓰여진 것은 그 역할을 하기가 매우 힘들고, 결국 직접 부딪혀 보고 진짜 문제를 풀어봐야 한다고 생각합니다.

    그에 반해, 지금 취업 준비하는 신입 학생들을 볼 때 답답한 것은 보여지기 위한 공부를 하는 경우가 꽤 많다는 것입니다. 보여주기 위한 포폴을 만들고, 간지가 난다고 생각하는(?), 혹은 유행하는 기술로 만들기 위한 프로젝트를 만들고요. 그 시점엔 내가 잘하고 있다고 믿을 수 있지만, 그만한 시간 낭비가 없다고 생각합니다.

    그런 관점에서, 학생 때 디자인 패턴을 공부하는 것은 시간 낭비라고 생각합니다. 그 패턴이 왜 좋은지도 모르고, 어떻게 쓰일 지도 모를거고, 실제로 만들면서 느껴지는 작은 불편함들을 해결하면서 자기도 모르게 그 패턴들을 사용하고 있을거거든요.

    제가 좀 꼰대 기질이 있어서 그런지는 모르겠지만, 저는 학교에서 배울 땐 학교에서 뽑을 것을 다 뽑는게 좋다고 생각합니다. 그 뽑아먹을 것은 학교에서 배우는 것과 학교의 동료에게서 배울 수 있는 것들이라고 믿고요. 이 기준으로 줄을 세우면 디자인 패턴을 굳이 끼우는 게 시간이 아깝다고 생각합니다.

  • fender
    26k
    2021-12-07 18:07:48 작성 2021-12-07 18:11:53 수정됨

    그냥 specialty의 문제인건 이해합니다만, 저는 일반적인 학생들을 고려했을 때 모든 학생들이 고수준으로 가야 한다고 생각하지 않고, 학생 때 쌓을 수 있는 고수준에 대한 경력에 대한 효율과 회사에 들어갔을 때 쌓을 수 있는 효율 중에 후자가 월등히 낫다고 생각하는 것 뿐입니다. 그래서 말그대로 학생 때 디자인 패턴을 공부하는게 시간이 아깝다는 뜻이죠. 모두가 고수준을 할 필요가 없고, Architect가 가장 잘하거나 가장 영향력이 큰 사람이 아닌 프로젝트도 굉장히 많은데요.
    당연히 전 모든 컴공 학부생이 고수준 개발자가 되어야 한다는 주장을 하지 않습니다. 반면에 후하하핫님의 논지의 대부분은 패턴 같은 고수준 지식은 학부 때 알고리즘 열심히 배운 학생이라면 간단하게 익힐 수 있다거나, 새로운 패턴의 개발 같은 것도 그런 개발자가 더 능숙하게 할 수 있다는 전제에서 출발하고 있는 것이 아닌가요?

    그리고 특정 프로젝트에서 아키텍트 직함을 걸고 있는 사람이 반드시 뛰어난 개발자가 아닐 수는 있어도, GoF나 DDD, CQRS, 이벤트 소싱 같은 패턴을 고안하는 아키텍트는 뛰어난 개발자인 것은 분명합니다.

    그리고 그런 수준의 고민이 알고리즘만 열심히 공부하면 어느 순간 자연스럽게 배울 수 있는 지식도 아닐 겁니다.

    -3
  • 후하하핫
    9k
    2021-12-07 18:23:18

    @fender: 아하, 그렇게 읽힐 수 있겠네요. 그런 의미는 아니었습니다.


    제가 얘기하고 싶은건, 학생의 입장에서 이 학생이 나중에 어떤 개발을 하게 될지 모르는 생각한다면 이 학생은 언젠가 고수준을 다룰지 저수준을 다룰지 모르겠죠. 이런 상황에서는 저는 기초를 다지는게 제일 중요하다고 생각했습니다.

    새로운 것을 만들기 위해 기초는 중요합니다. 새로운 패턴도 기초가 있는 개발자이면서 그 방향에 뜻이 있다면 언젠가 만들 수 있겠죠. 하지만 기초가 없고 시야가 좁다면 세상에 어떤 문제가 있는지 알지 못할 가능성이 크죠.

    디자인 패턴은 기초보단 실용적인 기술이라고 생각하기 때문에, 이걸 학교에서 배우는 것의 효율이 떨어진다는 것이구요. 디자인 패턴을 공부했다고 해서 혁신적인 디자인 패턴을 만들 수 있는 것은 아니죠. (REST 같이 SE 박사를 한 사람이 만드는 경우도 있긴 하지만...)

    한마디로, DDD를 만든 사람은 훌륭한 개발자이지만 DDD를 공부한 학생은 그렇게 훌륭해 보이진 않습니다. 알고리즘 컨테스트 수상한 학생은 훌륭해 보입니다. (그것만으론 부족할지 몰라도) 언젠가 발전하다 보면 그 사람은 나중에 공부해서 DDD 보다 훌륭한 걸 만들 수도 있겠죠.

  • ISA
    6k
    2021-12-07 18:26:18 작성 2021-12-07 18:27:52 수정됨
    정리
    1. 실력 좋은 개발자는 cs와 패턴등 설계에 능해야한다.
    2. 어느 쪽이든 공부하는게 좋지만 cs적인 측면에 조금 더 집중해야한다.
    3. 패턴은 실용적인 영역이기에 실무를 하지 않고는 이해하기 힘들기에 공부 cs쪽에 집중하자.
    4. 설계에 대해서 고민과 경험 없이 좋은 설계를 만들기 힘들고 좋은 설계를 위해서는 cs 적인 기초가 중요하다.

    설계적인 지식 없이도 실력 좋은 개발자가 은연중에 어느 정도 좋은 설계를 짠다는 의견은 맞는 말인거 같습니다. 재능을 타고나면 가능한거 같구요.

    반대로 cs적인 부분을 공부를 별로 안한 실력 좋은 아키텍트가 좋은 설계나 성능 적인 부분을 못한다는 것는 주장 비스무리하게 되는데 재능을 타고나면 반대도 같지 않을까요? 좋은 설계라는게 결국 잘못된 구조를 개선하는 것이라 좋은 설계를 추구하다보면 저수준이 아닌 이상 성능이나 cs적인 측면을 극대화해서 설계하게 될텐데요.

    그냥 그 사람이 cs보다 설계 쪽에 흥미가 더 강할뿐인 것 같습니다. 반대도 그냥 패턴보다 cs쪽이 강하구요.

    추가적으로 채용 관련 트렌드는 cs쪽이 강세가 맞는거 같아요. 즉 학생들이 cs적인 부분에 좀 더 집중하는게 좋다는 발언은 맞을거 같습니다.

    글고 개인적으로  글쓴이님은 네이버 이실거같네요...글에서  네이버의 철학이  느껴집니다.

    -1
  • dandanny
    55
    2021-12-08 09:46:31

    큰 도움 되었습니다. 글쓴이님 + 덧글 적어주신 분들 지혜 나눠주셔서 감사합니다

  • fender
    26k
    2021-12-08 09:57:25

    후하하핫 // 저도 좋은 개발자가 되기 위해서 기초가 중요하다는데는 이견이 없습니다.

    다만 프로그래밍에 있어서 무엇이 그 '기초'에 해당하는가, 또는 과연 요즘처럼 개발 분야가 다양해지고 세분화 된 시기에 분야와 무관한 기초라는 것이 존재할 수 있는가, 혹은 존재할 수 있다면 그것이 과연 운영체제 이론이나 수학 같은 것을 그렇게 간주할 수 있는가라는 부분에서 좁히기 힘든 생각의 차이가 있는 것 같습니다.

    이 부분은 다분히 주관의 영역이고 이미 전에도 여러 번 꽤 장문으로 토론을 했던 주제이기 때문에, 여기서는 다양한 의견을 확인하는 정도로 정리할까 합니다.

    -1
  • 엔지니어의꿈
    1k
    2021-12-08 13:33:42

    다다익선이죠. 배우면 실무에서 재교육에 필요한 시간을 매우 줄일 수 있죠. 학교에서 디자인 패턴 등 실무적 지식을 가르쳐야 하는 이유가 코업이나 인턴 등의 실무 연계 과정에서 그러한 지식이 필요하기 때문이죠. 학생이 디자인 패턴을 배워야 하는가의 질문은 간단합니다. 네 그렇습니다. 그러한 지식이 코업 등의 학과 과정에서 실무를 수행할 때 쓰이기 때문이죠. 그러한 패턴의 장점은 패턴 자체를 익히는 것 보다 어떤 것이 좋다는 가이드라인이 되기 때문입니다. 반대로 어떤 것이 좋음을 아는 것을 통해서 무엇이 나쁜 것인지를 또한 알게 되죠. 


    개인적 경험으로 졸업 후 바로 스타트업에 입사했고 얼마 지나지 않아 서비스 레벨에서 설계를 해야 할 일이 많았습니다. 이 때 디자인 패턴 등을 알아서 많은 시행착오를 줄일 수 있었죠. 중요한 건 디자인 패턴이 실제 쓰이냐의 여부가 아니라 디자인 패턴을 앎을 통해서 무엇을 해야 하는지를 알 수 있다는 것이죠.

  • 엔지니어의꿈
    1k
    2021-12-08 13:41:56

    더불어 이미 북미는 산학 연계 형식으로 학기와 방학 중 인턴 혹은 코업 과정의 병행이 당연시 되고 있습니다. 4년 동안 주구 장창 이론만 판다고 기업에서 쓸만한 인재가 나오지 않는다는 걸 알기 때문이죠. 따라서 학생 때 디자인 패턴을 배워야 한다는 질문 자체가 트렌드랑 상당히 맞지 않는 것 같습니다. 코세라 코스만 봐도 소프트웨어 개발자 과정에 디자인 패턴이 함께 있는 걸 알 수 있죠. 우리가 컴공을 공부하는 이유는 학문에 뜻을 두지 않는 한 창업이나 취업에 있습니다. 학부 레벨에서 쌓을 수 있는 지식의 깊이는 어차피 한계가 있습니다. 따라서 필요한 것 학부 과정을 통해서 방향성을 잡는 것이겠죠. 즉, 스스로 공부할 수 있는 지식의 토양을 제공하는 것. 그런 점에서 디자인 패턴이나 아키텍처 등은 배워야 합니다. 일례로, 간단한 스크립트만 만들어도 맨땅에 헤딩하며 배우는 것과 파이프라인 아키텍처를 알고 접근하는 사람은 다르죠. 

    -1
  • Cyp
    567
    2021-12-09 19:45:33

    "학생 때 디자인 패턴을 배우는건 시간 낭비라고 생각합니다"


    전적으로 동의

  • mos
    58
    2021-12-12 16:01:35

    제가 학생이라 그런지 여기의 핵심 주제인 "학생 때 디자인 패턴을 배우는 것은 비효율적이다." 에 동의합니다.

    게임 개발을 목표로 기본 언어를 공부하고 툴을 공부하고 알고리즘을 공부하고 자소서, 포트폴리오, 기업 알아보기, 졸업 프로젝트, 면접 대비 CS지식과 자격증, 토익 등 제가 취업을 위해 중요하게 생각하는 능력과 지식을 조금 나열해봤습니다.

    숨이 턱 막히더군요.

    그래서 저도 디자인 패턴 공부할 바에 다른 "필요한" 공부를 하는게 더 효율적이라 생각해요

  • OKKY
    4k
    2022-01-01 02:46:18
    해당 게시물은 관리자에 의해 사는얘기에서 칼럼로 이동 되었습니다.
  • 로그인을 하시면 댓글을 등록할 수 있습니다.