0564.txt

안녕하세요, 포프입니다. 

오늘 말할 주제는 '싱글턴 패턴은 과연 안티 패턴인가?'라는 얘기를 해 보려고 해요. 이야기를 하기 전에 싱글턴이 뭔지 궁금하신 분들은 검색해보시면 잘 나옵니다. 제가 옛날에 만들어 놓은 '싱글턴은 하나라니까?' 이런 비디오도 있고요. 하지만 그전에 뭐가 안티 패턴이고, 뭐가 디자인 패턴 인지는 대충이라도 정의를 하고 넘어가는 게 이해하시기 쉽겠죠? 소프트웨어 개발에 있어서 어떤 문제를 해결하려고 하다 보면은 어떤 식의 설계를 계속 반복해서 하게 되는 경우들이 있습니다. 어느 정도 정형화가 되어 있죠. 그 정형화됐다는 것이 보통 패턴이에요. 그래서 소프트웨어 업계에서 이렇게 저렇게 봤더니 이런 식의 문제는 이런 식으로 해결하면 좋겠다, 이런 식으로 해결하는 게 올바르다, 이게 재활용성도 높이고 가장 쪽으로 일을 처리할 수 있는 방법이라고 업계가 많이 동의를 했다 라는 게 디자인 패턴이란 겁니다. 물론 실제 업계 나가보면 디자인 패턴 유명한 책들 있어요. 그 책에서 말하는 유명한 패턴들 중에 사용 안 하는 것도 꽤 있고, 거기 없는 데 사용하는 것도 꽤 있고, 심지어는 다른 이름으로 부르는 것들도 있어요. 무슨 이야기냐 하면은 업계에서는 다 필요에 의해서 비슷한 패턴을 찾아갈 수는 있는데 그게 그 책을 쓰신 저자 분들이 보고 있는 올바른 방법 하곤 다를 수 있다. 그리고 그런 책에 나와 있는 방법들이 그대로 코드로 옮길 수 있는 게 아니라 이런 방식으로 개체 지향적으로 뭔가를 설계하면은 이런 경우에 좀 더 유용할 수 있다. 하지만 네 프로젝트 갖다 쓸 때는 네 입맛에 맞게 적당히 빼고 끼고 해서 써라 라는 게 일반적인 디자인 패턴의 이야기입니다. 그래서 어쨌든 간에 디자인 패턴이 원래 추구하려고 했던 목적 자체는 어떤 문제가 있고 그 문제를 해결하는 일반적인 저 사람들이 동의하는 정형화된 방법론이 있으면 그 방법론을 얘기하는 겁니다. 하지만 그 자체가 코드로 그대로 가진 않는다, 이게 디자인 패턴.

그러면 안티 패턴이란 뭐냐? 역시 업계에서 많이 사용하는 거기는 한데, 올바른 방법이 아니라는 거예요. 이렇게 하면 그것보다 배보다 배꼽이 큰 거, 뭔가 문제가 더 날 수 있는 경우들이 있고 괜히 그 방법과는 문제들이 더 많아진다. 그리고, 그리고 에요 중요한 건. 이것보다 더 나은 방법이 있다. 더 나은 방법이 뭐냐면 당연히 재활용 성이 좀 높아서 다른 데서도 비슷한 방법을 적용할 수 있고 그리고 두 번째는 이거를 대체하는 다른 해법이 있다, 즉 다른 디자인 패턴 있다는 얘기죠. 요거를 더 효율적으로 해결하는 디자인 패턴이 있기 때문에 굳이 잘못된 거 쓰지 말고 더 나은 거 써라, 그래서 얘를 안티 패턴이라고 한다는 겁니다. 디자인 패턴과 안티 패턴이 뭔지 아셨어요. 그럼 결과적으로 말하는 게 뭐냐면 어떤 패턴이 있으면 이거는 디자인 패턴 이거나 안티 패턴이어야 하는 거지 둘 다 일 수는 없습니다. 물론 다수설, 소수설이 다르게 볼 순 있어요. 다수설은 얘를 디자인 패턴으로 보는데 일부 소수설은 예를 안티 패턴으로 볼 수가 있어요. 이해되시죠? 싱글턴은, 싱글턴은 디자인 패턴입니다. 끝. 다수설에 의하면. 그리고 소수설이 이제 얘를 안티 패턴이라고 얘기하는 경우들이 있어요. 그리고 이게 안티 패턴이라고 얘기했던 경우는 제 기억으로는 90년대 말부터 있어 왔어요. 2000년대 초 거나 그때는 안티 패턴이라 말한 사람들이 조금 더 많았던 거 같은데 지금은 많이 줄었어요. 그래서 이게 싱글턴이 안티 패턴이라 말하는 사람들은 소수설인데 그 수는 줄어 가고 있다라고 생각하시면 돼요.

자 그러면 왜 싱글턴은 안티 패턴이라 부르느냐? 그 이야기부터 잠깐 설명을 드리면 일단 싱글턴이 나온 백그라운드를 아시면요, 기본적으로 그냥 Global Variable, 전역 변수를 OOP 환경화에서 어떻게 쓸 수 있느냐를 고민하다가 나온 게 결과적으로 싱글턴이라는 꼼수는 사실 맞습니다. 근데 싱글턴은 설명을 할 때 보면은 무슨 개체 생성을 책임지는 건데 프로그램 실행 중에 언제나 개체는 하나만 있게 하겠다, 결과적으로 그냥 전역 변수라는 거 보면 맞아요. 전역 변수가 실행 중에 하나만 있는 거거든요. 그래서 그런 경우들인데, 그러면 얘를 안티 패턴이라고 하는 사람들의 얘기가 뭐냐면 과외 이렇게 뭔가 프로그램 전체에 있어서 하나만 있는 오브젝트가 말이 되냐? 그리고 이게 있음으로 인해서 사람 원래 싱글턴을 안 만들어도 되는 거를 싱글턴을 만들어서 오히려 코드를 해 치는 경우가 많다 이런 식으로 얘기하는 겁니다. 그 외에 solid principal의 뭐가 하나 틀리다고 얘기하는데 solid는 기본적으로 역시 그렇게 하면 좋은 건 반드시 지키기에는 어려운 부분들이 많고 실제 불가능한 것들이 많거든요? 그거 갖고 끌어 오는 것도 아닌 거 같고. 그리고 싱글턴을 만들면 테스트 하기가 너무 힘들어진다 이런 얘기도 하지만 그것도 테스트를 위에서 뭐가 패턴이고 안티 패턴을 나누는 건 올바른 방법이 실제 아니고 일반 좀 하는 얘기도 아니에요.

그래서 넘어가고, 결과적으로 하고 싶은 얘기는 어찌 보면 개체 지향 전에 있던 전역 변수를 마구 쓰고 있던 습관의 싱글턴으로 가져와서 그냥 개체로 잘 뽀개고 이래야 되는 거라 안 뽀개기 때문에 안티 패턴이 될 수 있지 않냐 라는 이런 얘기입니다. 그 주장 자체는 틀린 게 아니에요. 개체 지향 처음 나오고 디자인 패턴 처음 나왔을 때 당연히 그전에 이런 거 안 하셨으니까 이런 문제들이 당연히 있었죠. 그래서 많은 프로그래머들이 대충 싱글턴으로 떡칠을 했을 겁니다. 제가 지난 20년 동안 싱글턴이 안티 패턴이라고 사람들이 줄어들었다 그랬죠? 그 이유는 이제 그렇게 떡칠 사람들이 많이 줄어든 거예요. 왜냐면은 이제는 교육 자체를 기본적으로 개체 지향 먼저 하고 가는 경우가 많기 때문에 전역 변수를 만들어서 여기저기서 다 접근한다 라는 개념이 당연하다라고 느끼고 코딩을 하시는 분 보다는 그 반대 분들이 좀 더 많다는 거죠. 그래서 이제는 그게 널리 사용되는 게 좀 줄어들었기 때문에, 안티 패턴을 외치는 사람이 줄었고 하지만 더 중요한 거는 안티 패턴의 두 번째 요건이었어요. 이게 안티 패턴이라고 얘기했어요.

그러면 이 싱글턴을 없애고 이거 대신에 사용할 수 있는 패턴을 누군가 주면 됩니다 디자인 패턴을. 하지만 지난 2~3년 동안 누구도 그거를 제대로 만든 적이 없어요. 싱글턴 보다 더 효율적이고 재활용이 가능한 패턴을 줘야 되는데 프로그램을 제대로 만드신 분들은 다 알아요. 어느 정도 규모가 되는지 안 드신 분들은 알지만 당연히 우리가 개체라는 개념에서 어떤 클래스가 있고, 그 클래스가 여러 개체가 프로그램 안에 돌아야 되는 것들은 충분히 많고 그게 대부분이라는 건 알아요. 하지만 어쩔 수 없이 뭔가 하나, 프로그램 실행 동안에 딱 하나만 존재야 되는 것들은 당연히 있습니다. 대표적인 예가 파일 시스템 같은 경우도 그렇고요. 그럼 파일 시스템을 여러 개 만들어 놓을 거예요? OS에 파일 시스템 하나 있는데? 그리고 어쨌든 간에 딱 한 가지의 올바른 답을 해 주는 소스가 필요한 경우들이 사실 있어요. 없을 수가 없어요. 그리고 그 정도 규모를 했는데도 '나는 싱글턴 안 썼는데요?'라고 하시는 분도 있을 텐데 그 정도 규모를 하면서 아마 프레임워크를 갖다 쓰셨을 거예요. 그 프레임워크 내부를 보시면 싱글턴이 상당히 많습니다. 그래서 걔네들이 싱글턴을 사용해 줬기 때문에 제가 싱글턴을 안 써도 되는 거지 사실 웬만한 제품에 싱글턴 안 쓰고 나오기는 되게 어려워요. 어느 정도 규모가 되는 제품이라면. 그래서 그 프레임워크 대표적인 예를 몇 개 들어 드리면 그냥 웹 개발에서 흔히 쓰시는 DI 프레임워크들 있죠? Dependency Injection, 의존성 주입 프레임워크. 거기 의존성 주입 보면은 의존성이 주입될 때 이 개체는 싱글턴으로 하냐? 이게 채널 스코프마다 하냐? 이게 채널 언제나 만드냐? 이런 게 있어요. 거기도 싱글턴 개체란 개념이 들어가요. 안 들어갈 수가 없는 걸 누구나 아는 거예요. 싱글턴이 안티 패턴이란 얘기는 어쨌든 간에 소수설이고요, 그래서 그거 때문에 싱글턴이 안티 패턴이다라고 어디 가서 주장을 하시려면 소수설에 의하면 안티 패턴이고 저는 이렇게 동의를 하고요 그리고 이거보다 더 나은 방법이 이겁니다라고 말하면은 괜찮은 방법. 그게 아니라 어디 가서 싱글턴은 안티 패턴이기 때문에 사용하면 안 됩니다라고 끝나면은 그러면 다들 보통 무시하는 이야기, 이렇게 되는 겁니다.

그래서 패턴 이야기는 좀 잘 봐야 되는데 안티 패턴이라고 말하는 거 약간 논외로 빠질게요 약간 정신적인 문제로. 이게 어찌 보면 한국어에서 흔히 말하는 '너는 애가 왜 이렇게 이기적이니?'라는 약간의 꼰대질 그거랑 비슷합니다. '얘는 개인주의야. 얘는 그냥 남한테 피해 주기 싫어하고, 나도 그냥 혼자 있고 싶어 하는 애야' 역지사지가 된다는 얘기죠. 하지만 '얘가, 내가 원하는 걸 안 해줬어' 그러면 괜히 까는 겁니다. '야 너는 너무 이기적이야. 내가 원하는 걸 안 해 줬기 때문에.' 사실은 내가 이기적인 거거든요 그렇게 보면. 안티 패턴이라고 뭐를 지적하시는 분 대책 없이 그런 분들도 이런 식으로 말을 되게 잘하시는 거예요. 난 그 패턴 맘에 안 들어요. 하지만 그거에 대한 대체재는 없어요. 내가 마음에 안 드는 거예요. 누가 써? 그러면 가서 '안티 패턴입니다' 그러는 거예요. '왜 이게 안티 패턴이죠?' 그럼 어디 웹에서 블로그 하나 긁어와요. 이 사람이 안티 패턴이에요. 안티 패턴이 아니라고 하는 사람이 더 많다고 이게 안티 패턴이면요, 우리가 흔히 보는 디자인 패턴 책에 이게 들어가면 안 돼요. 왜냐면 아까 말했지만 패턴은 안티 패턴, 디자인 패턴 둘로 나눠야 되거든요? 그 책이 나왔고 그 책이 당연히 소수설일 수는 수 있죠. 하지만 그거를 대체할 다수설의 책이 또 나오겠죠? 업계에서 그게 문제라고 얘기하겠죠. 보통은 책보다는 업계가 다수설이니까요. 하지만 안 그러잖아요? 그러면 실제 다수설은 싱글턴이 패턴이다, 디자인 패턴이라고 하고 있는데 누군가 안티 패턴이라고 주장하면 그거에 대한 근거를 대야 되는 거예요. 어쩔 수 없죠. 하지만 그 근거나 대체재가 지금 없기 없기 때문에 필요악으로 쓴 거, 그게 첫 번째. 그래서 무조건 뭔가 안티 패턴이라고 말하는 사람들을 그냥 믿지 마세요. 그냥 위키 피디아를 보시던, 그 책을 보시던 거기에 디자인 패턴으로 있다면 일단 다수설은 디자인 패턴이라 믿고 넘어가시고요.

이게 첫 번째 번외 얘기고, 두 번째 번외 얘기는 이거는 제가 강의 중에도 말씀드리는 건데, 경력이 2년이 안 돼요. 그럼 디자인 패턴을 어쭙잖게 쓸 생각을 하지 마세요. 제가 앞에서도 말씀드렸지만 어떤 패턴이 있고, 그 패턴을 잘 못 쓰고 잘못된 배보다 배꼽이 커지는 경우가 안티 패턴이라고 얘기했어요. 하지만 디자인 패턴 그 자체는 정확히 무엇을 어떻게 하라고 얘기를 하지 않아요. 예를 하나 보여 줄 뿐이에요. 내가 경력이 충분치 않고 어떤 지금 하는 설계의 문제점을 충분히 못 느끼지 못했다, 그게 보통 2년 정도 걸려요. 그 상황인데 단지 책에서 어떤 패턴을 봤고 이거 하고 대충 비슷해 보인다고 사용을 하기 시작했다? 그러면 절반 이상이 사실은 그 패턴을 잘못 씁니다. 배보다 배꼽이 큰 일을 만들어 버려요. 그 순간 이 사람이 사용하고 있는 패턴은 디자인 패턴이나 안티 패턴이 돼버려요. 그래서 이런 문제들 때문에 2000년도 초반에 디자인 패턴 책 나오고 막 약팔이 열심히 돌았을 때는 학교에서도 열심히 가르치고 면접에서도 열심히 물어보고 이랬어요. 하지만 실제 주니어들이 이런 걸 사용하다 보니까 오히려 더 코드를 망가뜨리더라, 정말 엉뚱한 패턴을 갖다 쓰더라, 어댑터 패턴 쓰지 말아야 될 때 어댑터 패턴 써 갖고 오히려 안티 패턴을 만들더라 이런 일이 많았습니다. 그래서 업계에서도 많이 디자인 패턴에 대한 질문을 주니어한테 하는 일은 없어졌고, 학교에서 많이 가르치지 않게 되었고, 그리고 면접에서도 이제는 어떤 패턴의 특정 이름을 알고 있냐를 중요하게 여기지 않아요. 왜냐하면 이 패턴들은 이미 사람들이 동의하지 않는 이름으로 업계에서 사용이 되어 버리고 있어요. 그래서 똑같은 패턴을 말하는 이름이 한 4~5가지 됩니다 업계에서. 그래서 정형화가 안 돼 있기 때문에 보통 '어떤 일 하셨어요?', '어떤 문제 어떻게 푸셨어요?', '이건 어떻게 푸실 건가요?' 그런 설명을 해요. 아 그러면은 '이게 여기서 말하는 이 패턴인가요? 그러면 저는 이 패턴의 이름을 알고 있는데 어차피 같은 거죠' 퉁치고 넘어가요. 그래서 그런 식인 겁니다. 

디자인 패턴 같은 경우는 경력자들이 '내가 뭔가 설계를 못 하고 있는 거 같아. 남은 어떻게 하고 있을까?' 그러면 교양서적으로 보는 겁니다. 이 디자인 패턴은 그대로 따라 해도 안 돼요. 실제 업계에서 노노 하는 것도 많아요. 그래서 보고 취사선택해서 고르는 거, 그리고 당연히 같이 일하는 프로그래머 간의 서로 공통된 합의점을 찾는 게 중요합니다. 왜냐하면 각 프로젝트마다 어쨌든 간에 필요한 게 다르고 어떤 패턴을 적용해도 어느 것 빼고 어느 것 넣어야 될 수도 있고, 어떤 프로젝트는 당연히 인터페이스 기반의 다형성이 굉장히 중요할 수도 있고 어떤 프로젝트에서는 커플링을 좀 더 높이는 게 더 중요할 수도 있습니다. 그래서 이게 어떤 프로젝트를 만드냐? 내부 라이브러리냐, 외부 라이브러리냐에 따라서 다 달라요. 그거를 어느 한 가지로 재단할 수 없다는 거를 말씀드리고 디자인 패턴 얘기 나오면 이 정도 제가 언제나 말씀을 드려야 돼요. 그렇지 않으면 제가 디자인 패턴을 옹호하고 디자인 패턴을 되게 중요시하는 것처럼 얘기를 하는 사람이 되면 잘못된 정보를 전달하는 거거든요. 그걸 언제나 제가 주의하기 때문에 이 뒤에 거 한 2개 정도 말씀을 드린 거고 원래 주제로 돌아가면 어쨌든 간에 싱글턴 패턴은 안티 패턴이냐? 그렇게 주장하시는 분들도 있습니다. 하지만 그 주장하는 분들의 수가 줄어들고 있고 다수설은, 싱글턴은 그래도 필요한 것, 이것보다 나은 패턴은 없다라고 말하는 게 다수설이고 그래서 이거는 디자인 패턴입니다. 얘가 잘못 사용될 가능성이 있다라고 우기면서 안티 패턴이라고 주장을 해야 된다면 제가 잠시 예를 들었듯이 모든 디자인 패턴은 안티 패턴이 될 수 있습니다. 잘 못 사용할 수 있거든요? 그래서 그렇게 이해하시면 좋습니다. 포프였습니다.