현재 버전

다른 글을 보니 디자인 패턴은 실무에서 잘 사용하지 않는다거나 자연히 알게되는 것이라는 주장이 있더군요. 따로 글을 쓸까 하다가 이어지는 내용이라 그냥 여기에 적습니다.

제 생각에 그런 이야기는 절반은 맞고 절반은 틀린 내용입니다. 우선 국내 SI 기준으로 디자인 패턴 같은 건 사실상 거의 쓸일이 없다는 점에는 동의합니다. 그런데 애초에 커리어 목표가 그런 방식의 개발을 벗어나지 않는다면 디자인 패턴을 볼 시간에 차라리 SQL이나 데이터베이스 튜닝 같은 주제를 공부하는 것이 더 유용할 것입니다.

이 글은 무슨 이유에서 건 스프링 속성으로 배워서 페이지 찍어내는 식의 국내 SI 환경 이상의 실력을 원하는 분들을 위한 것입니다. 그리고 그 단계가 되려면 스프링을 하던 대로 사용만하는 게 아니라 이해하고 비슷한 걸 만들 수도 있어야 하며, 그런 수준이 되려면 바로 본문에 언급한 내용들이 필요해 집니다.

디자인 패턴은 하다보면 알게된다는 이야기는 어느 정도는 맞는 이야기입니다. 특히 팩토리 같이 흔하게 사용하는 패턴 같으면 그런 소스를 자주 본다면 개발 감이 좋은 분들은 의도까지 짐작하는 경우가 없진 않겠죠. 그런데 일반적인 SI 환경에서 하다 못해 팩토리라도 몇 번이나 써보셨나요? 그런 환경에서는 다양한 디자인 패턴을 쓸 기회도, 볼 기회도 많지 않습니다.

디자인 패턴은 외우는 게 아니라는 부분까지는 저 역시 거의 전적으로 동의합니다. 특히 리팩터링 지식이 없이 패턴만 외워서는 별 쓸모가 없는게 사실입니다.

하지만 흔히 쓰는 디자인 패턴이 어떤 것이 있는지 각각 의도와 예제를 한 두 번 쯤 읽고 이해하고 잊어버리는 것과 아예 접하지 않은 것은 꽤 차이가 있습니다.

일단 스트래티지라는게 왜 존재하고 어떻게 생겼는지, 팩토리라는 건 어떤 부류의 문제를 해결하기 위해 쓰는 것인지를 한 번이라도 읽어보고 완전히 이해한 적이 있다면, 나중에 비슷한 소스를 보거나 그런 부류의 문제를 적용할만한 상황을 접하면 전에 보았던 내용이 떠오르게 되는 것입니다.

반면에 그런 정도의 지식도 없이 스프링 API 같은 걸 한참 쳐다보고 있으면 어느날 갑자기 "패턴이 보인다!" 하고 각성하게 되는 그런 일이 가능할지는 의문입니다.

프로게이머가 될 수 있는 천재적 소질을 가진 게이머라면 그냥 프로들 리플레이만 아주 많이 보다보면 무언가 초반 패턴을 발견하고 나름대로 분석해서 패턴 사이의 상성을 파악하고 나름의 빌드 이론으로 정립하는 그런게 가능할 수도 있습니다.

그런데 특히 본인이 남들보다 늦게 시작한 게이머라면 본인에게 그 수준의 소질이 없을 가능성이 높습니다. 빌드 한 번 훑어보는거나 디자인 패턴 한 번 훑어보는 거 기껏해야 몇 일 안걸립니다. 그 시간이 아깝다고 본인의 커리어 걸고 그런 모험을 할 이유는 없다고 생각합니다.

빌드만 집착하면 좋은 프로게이머가 못된다? 패턴만 쓰면 창의적인 개발자가 못된다? 일단 평범한 프로게이머나 기본은 하는 개발자가 되고 나서 고민해도 늦지 않습니다. 아직 남들처럼 뛰지도 못하는 데 무슨 창의적인 스타일로 날아야 멋질까 고민해봐야 쓸 데 없습니다. 

그리고 디자인 패턴 같은 건 한 번 알아두면 적용한 코드가 보이고 적용할 만한 문제가 보이기 시작하지만 아예 안봤다면 이런 부분은 패턴을 적용해서 풀만한 문제라는 생각 자체가 들지 않습니다.

반면에 패턴을 한 번 이해하고 잊어버리면 패턴이 적용된 코드가 자연히 읽혀지고 스스로도 패턴이 적용된 코드를 굳이 이런저런 패턴을 써야겠다는 생각을 하지 않아도 쓰게 됩니다.

특히 SI 실무에 종사하는 중이라면 그런 건 의식적으로 공부하지 않으면 자연히 깨닫게 되는 건 어렵습니다. SI 하면서 프레임워크가 아닌 프로젝트 소스에서 무슨 팩토리 같은 게 들어간 코드를 몇 번이나 보셨나요?

디자인 패턴까지 갈 것도 없이, 그런 실무 프로젝트에서 인터페이스나 추상 클래스는 몇 번이나 써보셨나요? 이유도 모르고 그렇게 배웠으니 그냥 서비스나 매니저에 습관처럼 인터페이스 나누는 걸 제외하고 진짜 설계의 이유로 인터페이스를 만든 적이 있나요?

그런 환경에서 그런 코드만 보면 그냥 그 수준에서 개발하는 것이 익숙해지는 것입니다. 그래서 시간이 지나면 디자인 패턴을 깨닫게 되는 것이 아니라 그런 건 실무에서 필요가 없다는 생각이 들게 되는 것이고 그럼 점점 더 스프링 같은 걸 이해하고 직접 만드는 그 이상의 수준에서 멀어지는 것입니다.


수정 이력

2019-03-18 07:14:37 에 아래 내용에서 변경 됨 #4

다른 글을 보니 디자인 패턴은 실무에서 잘 사용하지 않는다거나 자연히 알게되는 것이라는 주장이 있더군요. 따로 글을 쓸까 하다가 이어지는 내용이라 그냥 여기에 적습니다.

제 생각에 그런 이야기는 절반은 맞고 절반은 틀린 내용입니다. 우선 국내 SI 기준으로 디자인 패턴 같은 건 사실상 거의 쓸일이 없다는 점에는 동의합니다. 그런데 애초에 커리어 목표가 그런 방식의 개발을 벗어나지 않는다면 디자인 패턴을 볼 시간에 차라리 SQL이나 데이터베이스 튜닝 같은 주제를 공부하는 것이 더 유용할 것입니다.

이 글은 무슨 이유에서 건 스프링 속성으로 배워서 페이지 찍어내는 식의 국내 SI 환경 이상의 실력을 원하는 분들을 위한 것입니다. 그리고 그 단계가 되려면 스프링을 하던 대로 사용만하는 게 아니라 이해하고 비슷한 걸 만들 수도 있어야 하며, 그런 수준이 되려면 바로 본문에 언급한 내용들이 필요해 집니다.

디자인 패턴은 하다보면 알게된다는 이야기는 어느 정도는 맞는 이야기입니다. 특히 팩토리 같이 흔하게 사용하는 패턴 같으면 그런 소스를 자주 본다면 개발 감이 좋은 분들은 의도까지 짐작하는 경우가 없진 않겠죠. 그런데 일반적인 SI 환경에서 하다 못해 팩토리라도 몇 번이나 써보셨나요? 그런 환경에서는 다양한 디자인 패턴을 쓸 기회도, 볼 기회도 많지 않습니다.

디자인 패턴은 외우는 게 아니라는 부분까지는 저 역시 거의 전적으로 동의합니다. 특히 리팩터링 지식이 없이 패턴만 외워서는 별 쓸모가 없는게 사실입니다.

하지만 흔히 쓰는 디자인 패턴이 어떤 것이 있는지 각각 의도와 예제를 한 두 번 쯤 읽고 이해하고 잊어버리는 것과 아예 접하지 않은 것은 꽤 차이가 있습니다.

일단 스트래티지라는게 왜 존재하고 어떻게 생겼는지, 팩토리라는 건 어떤 부류의 문제를 해결하기 위해 쓰는 것인지를 한 번이라도 읽어보고 완전히 이해한 적이 있다면, 나중에 비슷한 소스를 보거나 그런 부류의 문제를 적용할만한 상황을 접하면 전에 보았던 내용이 떠오르게 되는 것입니다.

반면에 그런 정도의 지식도 없이 스프링 API 같은 걸 한참 쳐다보고 있으면 어느날 갑자기 "패턴이 보인다!" 하고 각성하게 되는 그런 일이 가능할지는 의문입니다.

프로게이머가 될 수 있는 천재적 소질을 가진 게이머라면 그냥 프로들 리플레이만 아주 많이 보다보면 무언가 초반 패턴을 발견하고 나름대로 분석해서 패턴 사이의 상성을 파악하고 나름의 빌드 이론으로 정립하는 그런게 가능할 수도 있습니다.

그런데 특히 본인이 남들보다 늦게 시작한 게이머라면 본인에게 그 수준의 소질이 없을 가능성이 높습니다. 빌드 한 번 훑어보는거나 디자인 패턴 한 번 훑어보는 거 기껏해야 몇 일 안걸립니다. 그 시간이 아깝다고 본인의 커리어 걸고 그런 모험을 할 이유는 없다고 생각합니다.

빌드만 집착하면 좋은 프로게이머가 못된다? 패턴만 쓰면 창의적인 개발자가 못된다? 일단 프로게이머나 기본은 하는 개발자가 되고 나서 고민해도 늦지 않습니다. 아직 남들처럼 뛰지도 못하는 데 무슨 창의적인 스타일로 날아야 멋질까 고민해봐야 쓸 데 없습니다. 

그리고 디자인 패턴 같은 건 한 번 알아두면 적용한 코드가 보이고 적용할 만한 문제가 보이기 시작하지만 아예 안봤다면 이런 부분은 패턴을 적용해서 풀만한 문제라는 생각 자체가 들지 않습니다.

반면에 패턴을 한 번 이해하고 잊어버리면 패턴이 적용된 코드가 자연히 읽혀지고 스스로도 패턴이 적용된 코드를 굳이 이런저런 패턴을 써야겠다는 생각을 하지 않아도 쓰게 됩니다.

특히 SI 실무에 종사하는 중이라면 그런 건 의식적으로 공부하지 않으면 자연히 깨닫게 되는 건 어렵습니다. SI 하면서 프레임워크가 아닌 프로젝트 소스에서 무슨 팩토리 같은 게 들어간 코드를 몇 번이나 보셨나요?

디자인 패턴까지 갈 것도 없이, 그런 실무 프로젝트에서 인터페이스나 추상 클래스는 몇 번이나 써보셨나요? 이유도 모르고 그렇게 배웠으니 그냥 서비스나 매니저에 습관처럼 인터페이스 나누는 걸 제외하고 진짜 설계의 이유로 인터페이스를 만든 적이 있나요?

그런 환경에서 그런 코드만 보면 그냥 그 수준에서 개발하는 것이 익숙해지는 것입니다. 그래서 시간이 지나면 디자인 패턴을 깨닫게 되는 것이 아니라 그런 건 실무에서 필요가 없다는 생각이 들게 되는 것이고 그럼 점점 더 스프링 같은 걸 이해하고 직접 만드는 그 이상의 수준에서 멀어지는 것입니다.

2019-03-18 07:14:00 에 아래 내용에서 변경 됨 #3

다른 글을 보니 디자인 패턴은 실무에서 잘 사용하지 않는다거나 자연히 알게되는 것이라는 주장이 있더군요. 따로 글을 쓸까 하다가 이어지는 내용이라 그냥 여기에 적습니다.

제 생각에 그런 이야기는 절반은 맞고 절반은 틀린 내용입니다. 우선 국내 SI 기준으로 디자인 패턴 같은 건 사실상 거의 쓸일이 없다는 점에는 동의합니다. 그런데 애초에 커리어 목표가 그런 방식의 개발을 벗어나지 않는다면 디자인 패턴을 볼 시간에 차라리 SQL이나 데이터베이스 튜닝 같은 주제를 공부하는 것이 더 유용할 것입니다.

이 글은 무슨 이유에서 건 스프링 속성으로 배워서 페이지 찍어내는 식의 국내 SI 환경 이상의 실력을 원하는 분들을 위한 것입니다. 그리고 그 단계가 되려면 스프링을 하던 대로 사용만하는 게 아니라 이해하고 비슷한 걸 만들 수도 있어야 하며, 그런 수준이 되려면 바로 본문에 언급한 내용들이 필요해 집니다.

디자인 패턴은 하다보면 알게된다는 이야기는 어느 정도는 맞는 이야기입니다. 특히 팩토리 같이 흔하게 사용하는 패턴 같으면 그런 소스를 자주 본다면 개발 감이 좋은 분들은 의도까지 짐작하는 경우가 없진 않겠죠. 그런데 일반적인 SI 환경에서 하다 못해 팩토리라도 몇 번이나 써보셨나요? 그런 환경에서는 다양한 디자인 패턴을 쓸 기회도, 볼 기회도 많지 않습니다.

디자인 패턴은 외우는 게 아니라는 부분까지는 저 역시 거의 전적으로 동의합니다. 특히 리팩터링 지식이 없이 패턴만 외워서는 별 쓸모가 없는게 사실입니다.

하지만 흔히 쓰는 디자인 패턴이 어떤 것이 있는지 각각 의도와 예제를 한 두 번 쯤 읽고 이해하고 잊어버리는 것과 아예 접하지 않은 것은 꽤 차이가 있습니다.

일단 스트래티지라는게 왜 존재하고 어떻게 생겼는지, 팩토리라는 건 어떤 부류의 문제를 해결하기 위해 쓰는 것인지를 한 번이라도 읽어보고 완전히 이해한적이 있다면, 나중에 비슷한 소스를 보거나 그런 부류의 문제를 적용할만한 상황을 접하면 전에 보았던 내용이 떠오르게 되는 것입니다.

반면에 그런 정도의 지식도 없이 스프링 API 같은 걸 한참 쳐다보고 있으면 어느날 갑자기 "패턴이 보인다!" 하고 각성하게 되는 그런 일이 가능할지는 의문입니다.

프로게이머가 될 수 있는 천재적 소질을 가진 게이머라면 그냥 프로들 리플레이만 아주 많이 보다보면 무언가 초반 패턴을 발견하고 나름대로 분석해서 패턴 사이의 상성을 파악하고 나름의 빌드 이론으로 정립하는 그런게 가능할 수도 있습니다.

그런데 특히 본인이 남들보다 늦게 시작한 게이머라면 본인에게 그 수준의 소질이 없을 가능성이 높습니다. 빌드 한 번 훑어보는거나 디자인 패턴 한 번 훑어보는 거 기껏해야 몇 일 안걸립니다. 그 시간이 아깝다고 본인의 커리어 걸고 그런 모험을 할 이유는 없다고 생각합니다.

빌드만 집착하면 좋은 프로게이머가 못된다? 패턴만 쓰면 창의적인 개발자가 못된다? 일단 프로게이머나 기본은 하는 개발자가 되고 나서 고민해도 안늦습니다. 뛰지도 못하는 데 무슨 스타일로 날아야 멋질까 고민해봐야 쓸데 없습니다. 

그리고 디자인 패턴 같은 건 한 번 알아두면 적용한 코드가 보이고 적용할 만한 문제가 보이기 시작하지만 아예 안봤다면 이런 부분은 패턴을 적용해서 풀만한 문제라는 생각 자체가 들지 않습니다.

반면에 패턴을 한 번 이해하고 잊어버리면 패턴이 적용된 코드가 자연히 읽혀지고 스스로도 패턴이 적용된 코드를 굳이 이런저런 패턴을 써야겠다는 생각을 하지 않아도 쓰게 됩니다.

특히 SI 실무에 종사하는 중이라면 그런 건 의식적으로 공부하지 않으면 자연히 깨닫게 되는 건 어렵습니다. SI 하면서 프레임워크가 아닌 프로젝트 소스에서 무슨 팩토리 같은 게 들어간 코드를 몇 번이나 보셨나요?

디자인 패턴까지 갈 것도 없이, 그런 실무 프로젝트에서 인터페이스나 추상 클래스는 몇 번이나 써보셨나요? 이유도 모르고 그렇게 배웠으니 그냥 서비스나 매니저에 습관처럼 인터페이스 나누는 걸 제외하고 진짜 설계의 이유로 인터페이스를 만든 적이 있나요?

그런 환경에서 그런 코드만 보면 그냥 그 수준에서 개발하는 것이 익숙해지는 것입니다. 그래서 시간이 지나면 디자인 패턴을 깨닫게 되는 것이 아니라 그런 건 실무에서 필요가 없다는 생각이 들게 되는 것이고 그럼 점점 더 스프링 같은 걸 이해하고 직접 만드는 그 이상의 수준에서 멀어지는 것입니다.

2019-03-18 07:11:32 에 아래 내용에서 변경 됨 #2

다른 글을 보니 디자인 패턴은 실무에서 잘 사용하지 않는다거나 자연히 알게되는 것이라는 주장이 있더군요. 따로 글을 쓸까 하다가 이어지는 내용이라 그냥 여기에 적습니다.

제 생각에 그런 이야기는 절반은 맞고 절반은 틀린 내용입니다. 우선 국내 SI 기준으로 디자인 패턴 같은 건 사실상 거의 쓸일이 없다는 점에는 동의합니다. 그런데 애초에 커리어 목표가 그런 방식의 개발을 벗어나지 않는다면 디자인 패턴을 볼 시간에 차라리 SQL이나 데이터베이스 튜닝 같은 주제를 공부하는 것이 더 유용할 것입니다.

이 글은 무슨 이유에서 건 스프링 속성으로 배워서 페이지 찍어내는 식의 국내 SI 환경 이상의 실력을 원하는 분들을 위한 것입니다. 그리고 그 단계가 되려면 스프링을 하던 대로 사용만하는 게 아니라 이해하고 비슷한 걸 만들 수도 있어야 하며, 그런 수준이 되려면 바로 본문에 언급한 내용들이 필요해 집니다.

디자인 패턴은 하다보면 알게된다는 이야기는 어느 정도는 맞는 이야기입니다. 특히 팩토리 같이 흔하게 사용하는 패턴 같으면 그런 소스를 자주 본다면 개발 감이 좋은 분들은 의도까지 짐작하는 경우가 없진 않겠죠. 그런데 일반적인 SI 환경에서 하다 못해 팩토리라도 몇 번이나 써보셨나요?

디자인 패턴은 외우는 게 아니라는 부분까지는 저 역시 거의 전적으로 동의합니다. 특히 리팩터링 지식이 없이 패턴만 외워서는 별 쓸모가 없는게 사실입니다.

하지만 흔히 쓰는 디자인 패턴이 어떤 것이 있는지 각각 의도와 예제를 한 두 번 쯤 읽고 이해하고 잊어버리는 것과 아예 접하지 않은 것은 꽤 차이가 있습니다.

일단 스트래티지라는게 왜 존재하고 어떻게 생겼는지, 팩토리라는 건 어떤 부류의 문제를 해결하기 위해 쓰는 것인지를 한 번이라도 읽어보고 완전히 이해한적이 있다면, 나중에 비슷한 소스를 보거나 그런 부류의 문제를 적용할만한 상황을 접하면 전에 보았던 내용이 떠오르게 되는 것입니다.

반면에 그런 정도의 지식도 없이 스프링 API 같은 걸 한참 쳐다보고 있으면 어느날 갑자기 "패턴이 보인다!" 하고 각성하게 되는 그런 일이 가능할지는 의문입니다.

프로게이머가 될 수 있는 천재적 소질을 가진 게이머라면 그냥 프로들 리플레이만 아주 많이 보다보면 무언가 초반 패턴을 발견하고 나름대로 분석해서 패턴 사이의 상성을 파악하고 나름의 빌드 이론으로 정립하는 그런게 가능할 수도 있습니다.

그런데 특히 본인이 남들보다 늦게 시작한 게이머라면 본인에게 그 수준의 소질이 없을 가능성이 높습니다. 빌드 한 번 훑어보는거나 디자인 패턴 한 번 훑어보는 거 기껏해야 몇 일 안걸립니다. 그 시간이 아깝다고 본인의 커리어 걸고 그런 모험을 할 이유는 없다고 생각합니다.

빌드만 집착하면 좋은 프로게이머가 못된다? 패턴만 쓰면 창의적인 개발자가 못된다? 일단 프로게이머나 기본은 하는 개발자가 되고 나서 고민해도 안늦습니다. 뛰지도 못하는 데 무슨 스타일로 날아야 멋질까 고민해봐야 쓸데 없습니다. 

그리고 디자인 패턴 같은 건 한 번 알아두면 적용한 코드가 보이고 적용할 만한 문제가 보이기 시작하지만 아예 안봤다면 이런 부분은 패턴을 적용해서 풀만한 문제라는 생각 자체가 들지 않습니다.

반면에 패턴을 한 번 이해하고 잊어버리면 패턴이 적용된 코드가 자연히 읽혀지고 스스로도 패턴이 적용된 코드를 굳이 이런저런 패턴을 써야겠다는 생각을 하지 않아도 쓰게 됩니다.

특히 SI 실무에 종사하는 중이라면 그런 건 의식적으로 공부하지 않으면 자연히 깨닫게 되는 건 어렵습니다. SI 하면서 프레임워크가 아닌 프로젝트 소스에서 무슨 팩토리 같은 게 들어간 코드를 몇 번이나 보셨나요?

디자인 패턴까지 갈 것도 없이, 그런 실무 프로젝트에서 인터페이스나 추상 클래스는 몇 번이나 써보셨나요? 이유도 모르고 그렇게 배웠으니 그냥 서비스나 매니저에 습관처럼 인터페이스 나누는 걸 제외하고 진짜 설계의 이유로 인터페이스를 만든 적이 있나요?

그런 환경에서 그런 코드만 보면 그냥 그 수준에서 개발하는 것이 익숙해지는 것입니다. 그래서 시간이 지나면 디자인 패턴을 깨닫게 되는 것이 아니라 그런 건 실무에서 필요가 없다는 생각이 들게 되는 것이고 그럼 점점 더 스프링 같은 걸 이해하고 직접 만드는 그 이상의 수준에서 멀어지는 것입니다.

2019-03-18 05:45:48 에 아래 내용에서 변경 됨 #1

다른 글을 보니 디자인 패턴은 실무에서 잘 사용하지 않는다거나 자연히 알게되는 것이라는 주장이 있더군요. 따로 글을 쓸까 하다가 이어지는 내용이라 그냥 여기에 적습니다.

제 생각에 그런 이야기는 절반은 맞고 절반은 틀린 내용입니다. 우선 국내 SI 기준으로 디자인 패턴 같은 건 사실상 거의 쓸일이 없다는 점에는 동의합니다. 그런데 애초에 커리어 목표가 그런 방식의 개발을 벗어나지 않는다면 자바 언어를 볼 시간에 차라리 SQL이나 데이터베이스 튜닝 같은 주제를 공부하는 것이 더 유용할 것입니다.

이 글은 무슨 이유에서 건 스프링 속성으로 배워서 페이지 찍어내는 식의 국내 SI 환경 이상의 실력을 원하는 분들을 위한 것입니다. 그리고 그 단계가 되려면 스프링을 하던 대로 사용만하는 게 아니라 이해하고 비슷한 걸 만들 수도 있어야 하며, 그런 수준이 되려면 바로 본문에 언급한 내용들이 필요해 집니다.

디자인 패턴은 하다보면 알게된다는 이야기는 어느 정도는 맞는 이야기입니다. 특히 팩토리 같이 흔하게 사용하는 패턴 같으면 그런 소스를 자주 본다면 개발 감이 좋은 분들은 의도까지 짐작하는 경우가 없진 않겠죠. 그런데 일반적인 SI 환경에서 하다 못해 팩토리라도 몇 번이나 써보셨나요?

디자인 패턴은 외우는 게 아니라는 부분까지는 저 역시 거의 전적으로 동의합니다. 특히 리팩터링 지식이 없이 패턴만 외워서는 별 쓸모가 없는게 사실입니다.

하지만 흔히 쓰는 디자인 패턴이 어떤 것이 있는지 각각 의도와 예제를 한 두 번 쯤 읽고 이해하고 잊어버리는 것과 아예 접하지 않은 것은 꽤 차이가 있습니다.

일단 스트래티지라는게 왜 존재하고 어떻게 생겼는지, 팩토리라는 건 어떤 부류의 문제를 해결하기 위해 쓰는 것인지를 한 번이라도 읽어보고 완전히 이해한적이 있다면, 나중에 비슷한 소스를 보거나 그런 부류의 문제를 적용할만한 상황을 접하면 전에 보았던 내용이 떠오르게 되는 것입니다.

반면에 그런 정도의 지식도 없이 스프링 API 같은 걸 한참 쳐다보고 있으면 어느날 갑자기 "패턴이 보인다!" 하고 각성하게 되는 그런 일이 가능할지는 의문입니다.

프로게이머가 될 수 있는 천재적 소질을 가진 게이머라면 그냥 프로들 리플레이만 아주 많이 보다보면 무언가 초반 패턴을 발견하고 나름대로 분석해서 패턴 사이의 상성을 파악하고 나름의 빌드 이론으로 정립하는 그런게 가능할 수도 있습니다.

그런데 특히 본인이 남들보다 늦게 시작한 게이머라면 본인에게 그 수준의 소질이 없을 가능성이 높습니다. 빌드 한 번 훑어보는거나 디자인 패턴 한 번 훑어보는 거 기껏해야 몇 일 안걸립니다. 그 시간이 아깝다고 본인의 커리어 걸고 그런 모험을 할 이유는 없다고 생각합니다.

빌드만 집착하면 좋은 프로게이머가 못된다? 패턴만 쓰면 창의적인 개발자가 못된다? 일단 프로게이머나 기본은 하는 개발자가 되고 나서 고민해도 안늦습니다. 뛰지도 못하는 데 무슨 스타일로 날아야 멋질까 고민해봐야 쓸데 없습니다. 

그리고 디자인 패턴 같은 건 한 번 알아두면 적용한 코드가 보이고 적용할 만한 문제가 보이기 시작하지만 아예 안봤다면 이런 부분은 패턴을 적용해서 풀만한 문제라는 생각 자체가 들지 않습니다.

반면에 패턴을 한 번 이해하고 잊어버리면 패턴이 적용된 코드가 자연히 읽혀지고 스스로도 패턴이 적용된 코드를 굳이 이런저런 패턴을 써야겠다는 생각을 하지 않아도 쓰게 됩니다.

특히 SI 실무에 종사하는 중이라면 그런 건 의식적으로 공부하지 않으면 자연히 깨닫게 되는 건 어렵습니다. SI 하면서 프레임워크가 아닌 프로젝트 소스에서 무슨 팩토리 같은 게 들어간 코드를 몇 번이나 보셨나요?

디자인 패턴까지 갈 것도 없이, 그런 실무 프로젝트에서 인터페이스나 추상 클래스는 몇 번이나 써보셨나요? 이유도 모르고 그렇게 배웠으니 그냥 서비스나 매니저에 습관처럼 인터페이스 나누는 걸 제외하고 진짜 설계의 이유로 인터페이스를 만든 적이 있나요?

그런 환경에서 그런 코드만 보면 그냥 그 수준에서 개발하는 것이 익숙해지는 것입니다. 그래서 시간이 지나면 디자인 패턴을 깨닫게 되는 것이 아니라 그런 건 실무에서 필요가 없다는 생각이 들게 되는 것이고 그럼 점점 더 스프링 같은 걸 이해하고 직접 만드는 그 이상의 수준에서 멀어지는 것이라고 생각합니다.