프로그래밍을 시작하는 학생을 가르치는 입장에서 계속해서 고민하고 있는 내용입니다. 1년 이상을 고민했는데도 아직까지 어떤 방식으로 접근하는 것이 맞는 길인지 모르겠네요. 제가 지금까지 고민하면서 정리한 내용을 잠깐 공유해 볼께요. 아직 최종 정리는 하지 못했어요.

대표적인 프로그래밍 언어의 발전 단계를 추상화 수준에 따라 분리해 보려는 시도를 했어요. 제가 지식이 짧아서 정확하지 않을 수도 있으니 더 보태주세요.

1. 어셈블리 수준의 추상화 단계.
2. C 언어와 같이 인간에게 좀 더 친숙한 수준의 추상화 단계. 포인터 개념이 포함되어 있음. C 이외에도 인간에게 친숙한 언어들이 많이 등장했겠죠.
3. 가상 머신 기반의 추상화 단계

현재 3단계의 추상화 단계까지 진행됐으며, 미래는 어떤 모습이 될지 저는 잘 모르겠네요. 그렇다면 이 추상화 수준에서 우리 개발자들은 어느 수준에서 시작하는 것이 가장 좋을 것인가에 대한 이슈가 있는 듯합니다. 2단계 수준에서 시작해야된다는 관점과 3단계로 시작해야 된다는 관점이 팽팽하게 대립하고 있는 것이 현재의 상황이라고 봅니다. 그럼 1단계에서 2단계로 넘어올 때는 이런 논쟁이 없었을까요? 똑같이 있었을 것이라 생각합니다. 현 단계는 3단계 이후로 가기 위한 과도기 단계가 아닐까라는 생각을 합니다.

그럼 자바 기반 웹 서비스 개발 관점에서 추상화 수준을 살펴보면서 이야기해 볼께요.

1. 순수하게 Servlet/JSP 만으로 웹 서비스를 개발하는 추상화 단계
2. Struts, Spring 프레임워크 기반으로 웹 서비스를 개발하는 추상화 단계
3. Service or Aspect 기반으로 웹 서비스를 개발하는 추상화 단계. SOA나 매쉬업 수준이라고 생각하면 될 듯 합니다.

웹 서비스 개발 과정을 보면 현재 2단계에서 3단계로 빠르게 넘어가고 있다고 생각합니다. 이 단계에서 소프트웨어를 개발하는 친구들에게 어느 수준으로 접근하도록 하는 것이 좋을까요? 저도 아직까지 이 부분에 대한 확신이 서지 않아 많은 고민을 하고 있습니다.

이도현님이 이야기한 하향 평준화는 추상화 수준이 높아지면서 과거보다 소프트웨어를 좀 더 쉽게 접근하고 개발할 수 있는 환경이 되었다고 이해했습니다. 이 같은 추상화는 계속해서 진행될 것이고, 이 같은 추상화의 흐름 속에서 2단계부터 시작하느냐, 3단계부터 시작하느냐의 접근 방식의 차이가 있는 듯합니다. 3단계부터 접근한다는 관점으로 봤을 때 도현님이 이야기하신 "점점 더 중요해지는 건 창의력과 지루해하지 않고 계속 서비스를 개선, 개발할 수 있는 의지"에 대한 중요성에 대해서 저는 적극 공감합니다. 3단계 수준에서 필요로하는 개발자의 역량은 과거 1, 2단계에서 필요로하는 역량과는 확연히 달라질 것이라 생각합니다. 우리가 현 시점에 집중해야할 부분은 3단계라야 과거와는 다른 혁신적인 서비스를 만들 수 있는 개발자들을 만들어 낼 수 있다고 생각합니다.

물론 추상화 수준을 높이기 위한 다른 역량을 필요로하는 개발자들이 필요합니다. 따라서 우리가 미래의 목표를 정할 때 내가 어떤 일을 하고 싶은지를 정하고 그에 따른 역량을 길러야 된다고 생각합니다. 자신이 추구하는 길에 따라 1단계부터 시작할 수도 있고, 2단계부터 시작할 수도 있겠죠. 아무래도 우리에게 주어진 시간은 한정되어 있고, 배워야할 부분은 많기 때문에 선택과 집중은 정말 중요한 시대의 화두가 되었다는 생각이 듭니다.

@자바지기 우와 상세한 답변 감사드립니다. 모든 내용에 공감하고 있습니다. 과거에는 기술중심으로 어디의 어느 서비스가 Java기반의 OO으로 OO해서 만들어졌다. 어디서는 Scala로 만들어 졌고 어디서는 C#으로 개발했다더라가 주 관건이었는데 요즘에는 개발자(서비스를 개발하는, 대표적으로 웹, 앱)가 갖춰야할 마인드가 기술중심이 아니라 서비스 중심으로 변화되어야 된다고 생각하고 있습니다. 어느 서비스의 어느 기능이 사용자에게 편리한 느낌을 주는거 같더라 식으로 말이죠

결국 돈을 벌어오는건 기술이 아니라 서비스니까, 서비스중심에 맞춰서 기술을 선택하고 개발하면 된다고 봅니다. 어느 개발자건 중요한건 기술중의 접근방법이 아니라 서비스 중심의 사고와 커뮤니케이션 스킬인 것 같습니다.

@이도현 도현님의 의견에 제 의견을 몇자 넣어 봅니다.

---------------------------------- 제가 몸담고 있는 분야만 그런건지는 모르겠지만 - 아마도 다른 SW분야도 그리고 HW분야 조차도 오픈하드웨어로인해 기존 개발 방식에 대한 파괴가 일어나고 있다고 생각합니다. - 이유는 스톨만님의 오픈소스 영향으로 인해 시작되었다고 봅니다. - 나만 알고 있는 기술은 거의 없을 정도이고, - 또한 정보의 공개로(오픈소스 등) 인해 나만의 노하우도 점점 적어지고 있죠.

자바의 엄청나게 방대만 오픈소스와 대부분의 대안언어들이 JVM환경을 지원하면서 이제는 CS 학부에서 배우는 자료구조, 알고리즘을 모르더라도(일부 전문성 있는 분야 제외) 실무를 할 수 있는 시대가 온 것 같습니다. - 그렇습니다. - 자료구조, 알고리즘을 몰라도 실무를 할 수 있는 시대가 되었습니다. - 실무에 적용하기 위해서는 정렬알고리즘이나, 검색 알고리즘이 필요한게 아니고 - DBMS의 쿼리문을 더 최적화하는데 집중을 해야합니다. - 말했던 일부 전문성 있는 분야(임베디드 등) 조차도 SQLite라는 툴을 사용하는 추세로 바뀌고 있습니다. - 도현님이 말씀하신는 실무는 크게 화면, 비즈니스로직, 데이터로 나누고 - 이것에 맞춰 각 회사에서는 프레임워크를 개발하고 - 개발자들은 제공되 프레임워크와 일명 회사 표준안을 따르는 가이드라인에 맞춰 개발하도록 합니다. - 제시된 가이드라인을 따르지 않으면, 과장되게 말하면, 아주 죄인 취급까지 하기도 하죠. - 이것은 마지 자동차를 만드는데, 각자의 파트를 나누고 - 복잡하고 사람의 오류가 많이 나는 곳은 로보트로 자동화하고 - 어떤사람을 하루종일 나사를 조이는 등 아주 간단해 보이는 몇가지일을 반복하다 보면 - 아주 복잡한 기계인 자동차가 만들어 지는것과 같아 집니다. - 이런 상황에 자꾸 접하게 되면, - 학부에서 접했던(도현님이 언급했던 자료구조, 알고리즘 등) 부분이 사용되지 않고 - 전공을 했던 사람이나, 심지어 프로그램을 전혀 접하지 않은 사람들을 3~6개발 혹은 1년 정도 가르치고 - 실제 업무에서 개발하도록 합니다. - 실제로 얼마전에 모IT전문 회사에서 컴전공자는 1명만 뽑고 나머지 10여명을 컴전공과 전혀 상관없는 분야에서 - 뽑은걸 보고 놀란적도 있습니다. 그 신입사원들을 약 3개월정도 회사 프레임워크 관련 교육시키고 자그마한 프로젝트 진행하고 - 실무에 배치하는 것을 본적도 있습니다. - 회사에서 바라보는 관점의 IT인력이 이런것에 실망을 많이 했습니다. - 잠시 옆길로 샜는데, - 학부에서 접했던 부분들은 전공자들이 개발을 하는 와중에 그대로 사용할 순 없어도, 응용을 할 수 있습니다. - 일반적인 방법으로 처리할 수 있는데, - 100개를 처리하다 1000개를 처리하면 10배 늦어지는 것을 속도를 최적화하여 일정한 속도를 유지하게 하는 등등 - 부분등에 기존의 자료구조, 알고리즘 외에도 무수히 배운 전문지식이 기반이 되어 훨씬 좋은 품질의 - 개발을 할 수 있습니다. - 물론, 이런 부분이 겉으로 드러나지 않아 - 30분만에 뚝딱 만들어 버린것이나 몇칠을 고민하고 만들것이나 - 결과적으로 같으니 이런 부분에 대한 것이 딜레마로 와서 또, 고민을 하게 될것입니다. - - 결론은 전문성이 없어도 실무를 할 수 있다는 것이 아니라 - 전문성이 있는 상태에서 실무를 하게 되면 - 좀 더 좋은 품질의 상품, 혹은 서비스를 개발하게 된다는 것 입니다. - 이 품질이 좋다는 것은 - 추후, 소프트웨어 혹은 서비스를 유지보수 하는 비용을 많이 줄입니다. - 당장 눈앞의 것만 보면 전문성이 있던 없던 같아 보이지만, - 전체원가개념을 도입하게 되면, 또 많은 프로젝트 매니저가 느끼고 있는 - 경험있는 개발자를 원하는 것은 이런것들이 복합적으로 내재되어 있는것 입니다.

KLDP 커뮤니티의 어떤분이 말씀하신것처럼 3년차, 5년차, 10년차, 20년차들이 알고 있어야할 학습량이 같아졌고, - 위에서 언급한 프레임워크, 표준가이드 등의 도입등으로 개발자간의 러닝커브는 단축되어 격차는 많이 줄어들은것은 사실입니다. - 하지만, 그 프레임워크와 표준가이드 등에 내재된 원리나, 철학은 경력이 많은 개발자(이부분은 동의하지 않습니다. - 경력보다는 많이 학습한 개발자가 맞을 듯, 10년 넘어도 7~8년 전과 같았던 개발자도 많이 봐서...) - 샘풀로 제공된 템플릿을 보고 무조건 따라하도록 만들어 기술자가 아닌 기능인이 원하도록 하죠. - 이것은 회사의 관점에서 비용을 절약하는 부분이라 봅니다.

회사에서 필요한 자바프로그래머의 역량이 프로그래밍이 아니라 요구사항을 분석하고 결과를 도출하는 능력이 더욱 중요해지지 않았나 싶고 - 도현님의 의견처럼, 위에서 예처럼 경력이나 개발능력은 어느 정도가 되도 따라 올수 있는 수준이 되었으니 - 이제 평가나 판단의 근거가 - 사용자가 요청한 요구사항을 분석하고 - 사용자가 요청한 결과물을 만드는 능력이 되지 않을까요? - 즉, 회사에는 프로그램 개발 능력에 대한 부분에 따른 오차는 상당히 줄였지만 - 요구사항의 분석과 결과물을 만드는 능력에 대해서는 오차를 줄이 못한 것이지요. - 이 부분에 대해서는 아래에서 다시 언급하도록 하죠

결국 일부 유별난 천재성(대표적으로 임베디드나 기계학습, 인공지능분야 등등) 을 요구하는 분야가 아닌이상 프로그래밍 기술이 하향 평준화 되어가고 있지 않나 생각됩니다. - 회사에서 프레임워크등을 제공하는한, 자동차 공장의 고급적인 언어를 사용하면 - 테일러즘의 획일적인 생산성에 대한 사고를 바꾸지 않는한 - 회사에서는 점점 더 기능인만을 요구하도록 합니다. - 그 회사라는 틀안에서는 - 마치 프로그래밍 기술이 하향 평준화 되어가고는 것처럼 느껴지는 것이지요

점점더 중요해지는건 창의력과 지루해하지않고 계속 서비스를 개선, 개발할 수 있는 의지가 아닌가 합니다. - 맞습니다. - 하지만 틀렸습니다. - 서비스는 비즈니스 입니다. - @이도현님의 글에서 '서비스' -> '자신' 으로 바꾸는게 어떨까요? - 도현님도 개발을 하면서 느꼈겠지만, - 학부에서 배운것이 개발에 나름 도움이 된것이 있을 겁니다. - 이부분은 학부때 배운 이부분을 활용해서 훨씬 더 좋은 재밌는 개발을 한적도 있을 겁니다. - '이정도면 돼' 라고 했을 떄, 우리는 정지하는 겁니다 - '좀 더 좋은 방법은 없을까?' '더 간단하게 하는 방법은 없을까?' '더 빠르게 하는 방법은?' - 이렇게 생각하고 생각하고 생각했을 때 - 비로서 우리는 더 커지고 성장했음을 느깨게 됩니다.

여기까지가 제 개인적인 생각이고 어떤 비판이라도 환영합니다. 얼마전에 다른 커뮤니티에 올린 글이었는데 여러사람의 의견을 들어보고 싶어서 올립니다. - 다시한번 생각하게 하는 글 올려 주어서 감사합니다.

------------------------------- 아마도 개발자들이 대부분 @이도현님 처럼 SW개발에서 '하향 평준화' 하는 듯 생각하는 분이 많을 거라고 짐작합니다. 회사 vs 개발자 현재 한국내에서 SW개발을 원하는 소비자는 대분분이 회사입니다. 회사에서는 가장 우려되는 부분에 대해 가시적이기를 원합니다. 그러다 보니 오픈소스와 프레임워크등을 활용하고 기존에 우리들에게 놀라운 변화와 생산성을 일으킨 '테일러즘' 즉 생산성을 측정하고 이것을 지표로 성과를 측정하는 방식에 머물러 있는 측면이 강합니다. 회사에는 아직도 SW개발에 한사람당 하루에 몇라인을 개발해야 한다는 식의 추정으로 성과를 측정합니다. 마치 가로세로깊이 1미터를 파는데 삽질을 몇번을 하면 되니, 10평방미터는 그것의 100배 만큼만 하면 된다는 사고에 사로잡혀있습니다. 하지만, SW개발은 하루에 몇자를 타이핑할 수 있으니, 이만큼의 개발을 해야 한다라고 정형화 할 수 없습니다. 즉, 현재 SW개발 방식에 이러한 테일러즘 시스템을 도입해서 진행하는 프로젝트가 대부분이지만 여러가지 부작용도 만만지 않게 발생하고, 결과 예측, 성과 측정등에도 어려움이 있는 와중에 일부 개발자들을 중심으로 에자일방법론(Agile)을 도입하여 테일러즘이 아닌 성장하는 시스템으로 개발하는 추세가 많아 지고 있습니다.

개발자는 어떻게 해야 하는가?

개발자들이 주축이 되어 Top-Down방식이 아닌 Buttom-Up방식으로 접근하며 기존보다 나은 방안들을 생각하고 행동하면서, XP, TDD, SCRUM등을 적용하면서 실패와 성공을 거듭하며 개발자들 역시 진화하고 있습니다.

세계적인 석학 '피터 드러커'가 말했듯이 '육체노동자'가 아닌 '지식노동자'에 속하는 프로그래머는 자신의 성과로 자신의 모든것을 말해야 합니다.

우연찬게 본 글에 답글을 쓰다보니, 정리가 잘 되지 않은 상태에서 많이 부족하고 머리로 생각하는 부분을 제대로 표현도 하지 못했습니다. 지속적인 성장을 하기를 바랍니다.

참고로 프레드릭 브룩스가 1986년에 쓴 'No Silver Bullet(은 총알은 없다)' 읽어 볼 만하다고 생각 합니다. 추천하는 책으로는 '사람은 무엇으로 성장하는가'

부족하글 읽어 주셔서 감사합니다.

안녕하세요. 굉장히 좋은 의견들을 듣게 됐습니다. 제가 언제나 고민하는 내용입니다. 저는 디자이너로 8년 정도 근무하고 웹어플리케이션, 모바일어플리케이션을 개발하고 있습니다.

지금까지 아마존에 올라온 많은 개발서적을 읽었고 특히 루비온레일즈 기반의 책을 많이 읽었습니다. 실질적으로 레일즈로 계속해서 작업을 하고 있습니다.

제가 느낀 생각은 중요한 것은 연차와는 무관하고 서버스를 바라보는 자세의 문제가 아닐까 싶습니다. 연차가 높다고 굉장히 대단한 것을 만드는 것은 아니라고 보고 기획, 디자인을 얼마나 잘 이해하고 아주 디테일한 부분까지 그 서비스에 반영을 시켜줄 것인가? 에 대한 문제라고 보거든요.

대부분 많은 개발자들은 기획자 혹은 디자이너가 정말로 중요하게 생각하는 부분까지 잘 접근을 못하는 경우가 많더라고요.

개발을 어느 단계에서 공부하고 시작하는게 맞는가? 저는 최근에 빠르고 쉽게 자신의 창의성을 많이 보여주는 방향으로 가고 있다고 확신하고 있습니다.

아마도 그런 부분을 뒷받침하는 것은 아무래도 성능이 좋은 환경이 아닐까 싶은데 예전에는 꿈도 꿀수 없는 환경들이 현재는 너무나도 당연한 환경이 되가니까 성능과 최적화에 많은 부분 커버가 되가는 것 같습니다.

좋은 솔루션들도 많아지고요. 외국 커뮤니티에서 '가장 많이 듣는 바퀴가 있는데 왜 발명하냐' 이러한 질문이 많습니다. 물론 low level로 들어가야 할 필요성도 분명 있다고 생각합니다. 그리고 그게 정말로 필요한 서비스가 있으니까요.

근데 최근 개발방향이 많이 바뀌고 있는 건 분명합니다.