자바 개발자의 10가지 기술

atie의 이미지

뉴욕의 Bank of America의 Java Architect이 기고한 글에 나열된 자바 관련 기술들입니다.

Quote:

Java servlets
JSP
Struts 또는 유사한 framework
EJB
JMS
Message oriented 미들웨어
JDBC
JNDI
HTML
XML
Ant
SQL
one of major 어플리케이션 서버
한두개의 RDBMS
UML 모델링 툴
몇가지의 design patterns (적어도 Singleton 한가지는 꼭!)
unix에 대한 친근감
내년에는, JSF 하고 Hibernate 추가

이 중 적어도 10가지 기술에, 덧붙여 "Abstract class vs Interface"의 이해 그리고 비지니스 용어에 대한 지식을 자바 개발자 특히, J2EE 분야에서 일자리를 구하려는 개발자가 알아야 할 것이라고 그가 적었군요.

ByB의 이미지

웁쓰~~ 장난 아니군요.. --a;

p.s. : JMS -> JMX (Java Management eXtensions) 인듯.. ^^a

----------------------------------------------------------=>
Be supercalifragilisticexpialidocious, run for your life!

fender의 이미지

ByB wrote:
웁쓰~~ 장난 아니군요.. --a;

p.s. : JMS -> JMX (Java Management eXtensions) 인듯.. ^^a


Java Messaging Service입니다. 저도 JMS는 많이 써본적은 없네요 :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

jee1의 이미지

이거... 장난이 아닌데요.. ㅠ,ㅠ

MS 개발자에서 JAVA 개발자로 옮길려고 하는 저는...

언제 저걸 다 공부하나... ㅠ,ㅠ

yielding의 이미지

저걸 처음부터 다 알필요가 없습니다.
제가 사장이면 10가지를 대충 아는것 보다 기본적인 프로그래밍 역량과 팀 플레이를 잘 할 수 있는 사람의 가치를 훨씬 더 높이 살것입니다.
MS에서 고급 개발자시면 Java에서 금방 고급 개발자 됩니다..

Life rushes on, we are distracted

crimsoncream의 이미지

이런 다들 써 본 경험이 있는 간혹 능숙하고 적어도 쓸 줄은 아는 분야군요. 다시 java로 옮기는게 나을라나..

근데 몇년전까지만 해도 구인란에 j2ee라고 써놔서 가보면 죄 jsp만 들고 설치고 있고 구직란에 j2ee라고 써놔서 불러보면 죄 jsp만 다룰줄 알던데 여전히 그런 상황이라면 저건 어디까지나 미국얘기일 것 같군요.

그리고 유관기술끼리 그룹핑을 해보면 갯수가 많이 줄 것 같군요. 일부러 겁줄려고 나열해놓은 건지도 :)

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

ㅡ,.ㅡ;;의 이미지

atie wrote:
뉴욕의 Bank of America의 Java Architect이 기고한 글에 나열된 자바 관련 기술들입니다.
Quote:

Java servlets
JSP
Struts 또는 유사한 framework
EJB
JMS
Message oriented 미들웨어
JDBC
JNDI
HTML
XML
Ant
SQL
one of major 어플리케이션 서버
한두개의 RDBMS
UML 모델링 툴
몇가지의 design patterns (적어도 Singleton 한가지는 꼭!)
unix에 대한 친근감
내년에는, JSF 하고 Hibernate 추가

이 중 적어도 10가지 기술에, 덧붙여 "Abstract class vs Interface"의 이해 그리고 비지니스 용어에 대한 지식을 자바 개발자 특히, J2EE 분야에서 일자리를 구하려는 개발자가 알아야 할 것이라고 그가 적었군요.

설치가 더어렵겠네 그냥 C로 하는게 낮겠군..


----------------------------------------------------------------------------

fender의 이미지

ㅡ,.ㅡ;; wrote:
설치가 더어렵겠네 그냥 C로 하는게 낮겠군..

흐... C로 메시징 서버와 RDBMS간에 분산 트랜잭션 적용되는 웹 어플리케이션 만들어 주세요... 로드밸런싱하고 fail-over는 기본이고 인증 LDAP으로 하면 좋겠군요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

atie의 이미지

crimsoncream wrote:
...

그리고 유관기술끼리 그룹핑을 해보면 갯수가 많이 줄 것 같군요. 일부러 겁줄려고 나열해놓은 건지도 :)

제가 볼 때는 어플리케이션의 전면을 짜느냐 후면을 짜느냐로 구분하면 크게 두가지로 그룹핑 됩니다.
후자인 백엔드(어플리케이션 간 메세징 미들웨어) 업무를 주로 하는 저로서도 위의 기술 중 최소한 6가지는 정통해야 하고, 4가지 정도는 업무에 적용할 정도가 되어야 합니다.
그러니, 말 그대로 10가지가 필요한 셈이죠.
나머지는 기술적 추이가 어떻다 정도는 들은 풍월, 인터넷 검색등으로 감은 잡고 있습니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

ddt의 이미지

servlets, jsp, struts, jdbc, html, xml, ant, sql, tomcat, mysql. 간단하게 웹 프로그래밍만 해도 10가지는 되네요.
그리고 singleton pattern과 unix에 대한 친근감까지 합치면 12가지.

fender의 이미지

근데 같은 J2EE라도 메이저 기술만 나열한 것 같군요... 실제 프로젝트에 적용되고 있는 기술은 (물론 외국 기준으로) 훨씬 다양합니다.

같은 문제를 매우 다양한 방법으로 접근할 수 있다는 건 MS 계열 솔루션에 비교할 때 장점일 수도 단점일 수도 있습니다. 하다 못해 간단한 MVC 구조의 웹어플리케이션 하나만 봐도 :

Quote:
표현계층 :
(1) JSP 날코딩
(2) Velocity 등 템플릿 엔진
(3) XML/XSLT
(4) JSTL
(5) JSF

MVC 프레임워크 :
(1) Struts
(2) WebWork
(3) JSF
(4) Spring MVC
(5) Tapestry

서비스 계층 :
(1) EJB Session Bean
(2) Spring
(3) Pico Container
(4) 일반 자바 빈으로 구현

퍼시스턴스 계층 :
(1) JDBC
(2) EJB Entity Bean
(3) JDO
(4) Hibernate
(5) OJB
(6) SQLMap
(7) Prevlayer

대략 많이 쓰는 것만 나열해도 이렇습니다. MS 쪽 솔루션이 MSDN 읽고 VS.NET에 익숙하고 기본적인 개념을 알고 있으면 누구나 쉽게 접근할 수 있는 반면 한 가지 문제를 상황에 따라 다양하게 접근할 수 있는 유연성이 떨어집니다.

반면 J2EE의 경우 IDE부터 각 계층에 적용되는 라이브러리, 프레임워크들이 매우 다양해서 유연성이 높지만 개발자들의 진입장벽이 높고 상대적으로 개발툴에서 서버까지 모두 통합이 되어 있는 MS 계열 솔루션에 비해 편이성이 떨어질 수밖에 없습니다.

이런 차이가 딱히 어느 한쪽 진영에 유리하게 작용하진 않습니다. 다만 위와 같은 J2EE의 특성상 예를들어 단순히 '서블릿 관련 기술'으로 뭉뚱그려 이야기 했을 때 이는 단순히 JSP 문법을 아는 수준에서 부터 Struts, JSF 등을 자유자제로 섞어 쓸 수 있는 수준에 이르기까지 광범위한 분야를 포괄하기 때문에 그 다지 의미있는 분류는 아니라고 생각합니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

chunsj의 이미지

ㅡ,.ㅡ;; wrote:
설치가 더어렵겠네 그냥 C로 하는게 낮겠군..

네 C로 저런 것들을 따라하려면 더 낮습니다, 즉 훨씬 힘들죠. Java가 더 낫습니다.

cjh의 이미지

JVM 소스는 C였죠 아마 ;_;
C가 자바보다 열등하다는게 아니라 할 수 있는 분야의 성격이 다른 거겠죠. 자바로 잘 할 수 있는 것, C로 잘 할 수 있는 것...

--
익스펙토 페트로눔

greatkgc의 이미지

그런데 이런 J2EE 기술을 익혀봤자 국내에서는 SI 업체행 아닌가요?
SI 업종에 대한 부정적인 현실을 고려해봤을 때에 왠지 우울해지는
군요. - :?

ㅡ,.ㅡ;;의 이미지

fender wrote:
ㅡ,.ㅡ;; wrote:
설치가 더어렵겠네 그냥 C로 하는게 낮겠군..

흐... C로 메시징 서버와 RDBMS간에 분산 트랜잭션 적용되는 웹 어플리케이션 만들어 주세요... 로드밸런싱하고 fail-over는 기본이고 인증 LDAP으로 하면 좋겠군요.

버스3번타고 지하철 3번갈아타고 택시2번타고 A역B역CDE등등을거쳐 서울 목적지에 겨우도착했다
차라리 xxx 타고 가는게 낮겠네.
xxx 타고 A역 B역 CDE등 다거쳐가보세요..
편하게 서울만 빨리가면됬지 거길거쳐야할이유가 있나요..

------------------------
언어마다 특징이 있는데 과정이야 어쨋든 동일한결과를 내면되지 그과정까지 따라구현할이유가 없죠.


----------------------------------------------------------------------------

fender의 이미지

ㅡ,.ㅡ;; wrote:
버스3번타고 지하철 3번갈아타고 택시2번타고 A역B역CDE등등을거쳐 서울 목적지에 겨우도착했다
차라리 xxx 타고 가는게 낮겠네.
xxx 타고 A역 B역 CDE등 다거쳐가보세요..
편하게 서울만 빨리가면ㅤㄷㅚㅆ지 거길거쳐야할이유가 있나요..

------------------------
언어마다 특징이 있는데 과정이야 어쨋든 동일한결과를 내면되지 그과정까지 따라구현할이유가 없죠.


물론 동일한 인력과 시간을 투자해서 동일한 결과를 낼 수 있다면 C던 자바던 VBScript이던 관계 없습니다.

그런데 J2EE 어플리케이션 서버를 만들고 EJB, JMS, JDO 등을 설계하고 구현하는 사람들은 C언어 배울 능력이 안되거나 단지 학구적으로 복잡한게 좋아서 그런 스펙들은 만드는게 아닙니다. 모두 다른 기술이나 언어에 비해 해당 분야의 요구사항들을 최적으로 충족시킬 수 있기 때문에 그런 기술들을 만들고 쓰는 겁니다.

실제로 C 언어로 EJB, JMS, JDO 등이 쓰이는 분야의 솔루션을 개발 해보셨는지 모르겠지만 그렇다면 과연 동일한 작업을 J2EE나 닷넷 등을 이용해서 개발한 것과 비교해서 비용과 결과 측면에서 어떤 이익을 보셨는 지 궁금합니다.

만약 실제로 구현 경험이 없으시다면... 글쎄요... 제가 아는 사람 중에 C/C++ 조금 쓸 줄 안다고 시간만 주면 MS 오피스나 윈도우즈도 쉽게 만든다는 사람도 많습니다 :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

youlsa의 이미지

greatkgc wrote:
그런데 이런 J2EE 기술을 익혀봤자 국내에서는 SI 업체행 아닌가요?
SI 업종에 대한 부정적인 현실을 고려해봤을 때에 왠지 우울해지는
군요. - :?

올인입니다.

아무리 잘 공부해서 능숙하게 쓰고 그래도 단지 맨먼스라는 숫자로 계산될 뿐이라는게 좀 우울하네요. Java가 그전같으면 비싼 엔지니어들 데려다 써야했던 기술들을 너무 대중화 시킨 일종의 폐해(?) 아닐까요? ^_^

=-=-=-=-=-=-=-=-=
http://youlsa.com

Seyong의 이미지

제가 그 본보기네요!

저는 10가지 전부 능숙합니다. 나열된 10가지 이외에도 수많은 기술이 필요한 미들웨어를 개발했거든요. (ebxml 서버입니다)

제가 핵심 개발자였습니다.

그런데 회사가 어려워지더니 월급이 밀리기 시작하고.. 그래서 결국 다른곳으로 옮겼습니다.

대학생 신분이 구직에 엄청난 패널티가 되더군요.. 지금 SI 업체에서 삽 갈고 있습니다.

sanori의 이미지

atie wrote:
뉴욕의 Bank of America의 Java Architect이 기고한 글에 나열된 자바 관련 기술들입니다.
Quote:

Java servlets
JSP
Struts 또는 유사한 framework
EJB
JMS
Message oriented 미들웨어
JDBC
JNDI
HTML
XML
Ant
SQL
one of major 어플리케이션 서버
한두개의 RDBMS
UML 모델링 툴
몇가지의 design patterns (적어도 Singleton 한가지는 꼭!)
unix에 대한 친근감
내년에는, JSF 하고 Hibernate 추가

이 중 적어도 10가지 기술에, 덧붙여 "Abstract class vs Interface"의 이해 그리고 비지니스 용어에 대한 지식을 자바 개발자 특히, J2EE 분야에서 일자리를 구하려는 개발자가 알아야 할 것이라고 그가 적었군요.

갯수만 보면 "뜨으악~!"인데, 자세히 읽어 보면 필요한 내용들이군요. :(

*Bank* of America의 architect라면서 JAAS나 JSSE, JAXP같은 것이 언급되지 않은 것은 조금 의외군요... J2SE에 있으니까 기본이라는 걸까요?

ㅡ,.ㅡ;;의 이미지

fender wrote:

모두 다른 기술이나 언어에 비해 해당 분야의 요구사항들을 최적으로 충족시킬 수 있기 때문에 그런 기술들을 만들고 쓰는 겁니다.

보는입장에따라서 적용할곳에따라서 최적이 아닐수 있겠죠.


----------------------------------------------------------------------------

fender의 이미지

ㅡ,.ㅡ;; wrote:
fender wrote:

모두 다른 기술이나 언어에 비해 해당 분야의 요구사항들을 최적으로 충족시킬 수 있기 때문에 그런 기술들을 만들고 쓰는 겁니다.

보는입장에따라서 적용할곳에따라서 최적이 아닐수 있겠죠.

일반적인 이야기를 하는 것입니다. 인용된 글도 "모든" J2EE 개발자가 저 기술을 전부 능숙하게 다뤄야 한다는 뜻도 아니고 "모든" 서버 프로젝트에 다 J2EE가 최적의 솔루션이라고 주장하고 싶지도 않습니다.

찾아보면 자바로 디바이스 드라이버 만들고 운영체제 만드는 사람도 있고 자바 스크립트로 GUI 응용프로그램 만드는 사람도 있습니다. 하지만 일반적인 경우는 아니고 대부분 상용프로젝트에서 그런 검증되지 않은 방법을 채택했을 때 기술적 문제를 고려하지 않아도 인력, 시간 등 비용측면에서 실패할 확률이 매우 높습니다.

그리고 예를들어 누가 "윈도우즈에서 GUI 응용프로그램을 만들려면 VS를 설치하고 MFC나 WinForms 등을 알아야 하고 어쩌고"그런 글을 올렸는데 "그거 설치하는게 더 어렵겠다 그냥 자바 스크립으로 짜서 브라우저로 테스트하는게 낫겠네"라고 반박을 했다면... 물론 그 사람이 정말 100년에 한번 나올까 말까한 프로그래밍의 천재라 wscript/jscript를 완벽하게 마스터하고 COM객체를 스크립트에서 자유자재로 다룰 수 있으며 GUI 개발, 디버그에 있어서 남들이 WYSIWYG IDE로 하는 것보다 훨씬 높은 생산성 및 런타임 성능을 보장할 수 있다면 모르겠지만... 대부분의 경우 실무에서 한번도 심각한 수준의 윈도우즈 응용프로그램 개발을 안해봤다고 가정하는게 훨씬 가능성 있는 이야기가 아닐까요?

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

kwon37xi의 이미지

저기 있는것 중 3분의 1만 할 줄알아도 잘하는거 같은데요...

저는 프로그램을 짜진 않고, 다른 회사 사람들이 짠 프로그램에 지원을 나가고 그런 역할을 하는데요,

지금까지 본 사람들중 저걸 반 정도 할 줄 알았던 사람은 단 1명이었구요..
대부분의 사람들은 JSP, Oracle, Servlet 흉내 조금... 이게 다 더군요.
JSP란 Struts 같은 것을 전혀 포함하지 않은 스크립틀릿 만으로 짜는 JSP를 말하는 거구요..

그리고 보면 몇몇 기술들은 그냥 API 배우고 프로그래밍 패턴 배우는데 쫌 빡신 1주일 정도면 되는 것도 있구요...(JMS같은거..)

하나 하나씩 정복해 나가야지~~

atie의 이미지

sanori wrote:
...

*Bank* of America의 architect라면서 JAAS나 JSSE, JAXP같은 것이 언급되지 않은 것은 조금 의외군요... J2SE에 있으니까 기본이라는 걸까요?


특정 기술을 언급한 그런 글이 아니었고, 그가 몇년간 job interview를 하면서 생각한 것을 적은 글에 있던 부분입니다.

참고로, 몇개 더 적어보면,

Quote:
요즘은 자바 디벨로퍼나 프로그래머 대신 java architect이라 스스로를 부르기 좋아한다. 그렇지만, 약간만이 J2EE component가 어떻게 동작하는지를 알고 디자인을 조언할 뿐이다.

일자리를 구하는 신청자가 점차 senior되는 추세다. Junior를 위한 일자리는 아웃소싱되고 컴퓨터공학의 석사학위도 별 볼일 없다.

자바 certification을 이력서에 언급하면 초보자이다.

삼, 사년전에는 EJB가 높게 요구되었으나 이제는 Struts가 좀 더 귀중한 자산이다.

JDBC가 어떻게 동작하는지 모르는 개발자도 있다. SQL을 wrapper 클래스에 전달할 뿐이다.

프로젝트 매니저를 거친 Java Architect들은 업무를 잘 알고, 어플리케이션 서버, 메세징과 클러스터 등은 잘 이야기 하지만, 자바의 기술적 질문에는 번번히 실패한다.

Recruiter들이 스크린을 잘해서 9 of 10의 기술을 이력서에 적어도 회사로는 제출되지 않는다.

Job을 얻기 위해서는 적어도 4가지의 인터뷰를 거칠 준비를 해라.

물론, 미국 이야기 입니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

bugslife의 이미지

Java servlets
JSP
Struts
EJB
JDBC
JNDI
HTML
XML
Ant
SQL
WebLogic
Sybase
SA
design patterns
unix + Pro*C

이번 프로젝트에 쓰인 것들이군요.
원래 자바쪽(?)이 아니라 개념만 아는 것도 있고...
대충 다뤄본것도 있지만..

저걸 다 능통하게 쓴다는건... ㅠ,.ㅜ;;

어느순간부터인가 하루살이의 하루를 알고싶다.

ㅡ,.ㅡ;;의 이미지

fender wrote:

그리고 예를들어 누가 "윈도우즈에서 GUI 응용프로그램을 만들려면 VS를 설치하고 MFC나 WinForms 등을 알아야 하고 어쩌고"그런 글을 올렸는데 "그거 설치하는게 더 어렵겠다 그냥 자바 스크립으로 짜서 브라우저로 테스트하는게 낫겠네"라고 반박을 했다면... 물론 그 사람이 정말 100년에 한번 나올까 말까한 프로그래밍의 천재라 wscript/jscript를 완벽하게 마스터하고 COM객체를 스크립트에서 자유자재로 다룰 수 있으며 GUI 개발, 디버그에 있어서 남들이 WYSIWYG IDE로 하는 것보다 훨씬 높은 생산성 및 런타임 성능을 보장할 수 있다면 모르겠지만... 대부분의 경우 실무에서 한번도 심각한 수준의 윈도우즈 응용프로그램 개발을 안해봤다고 가정하는게 훨씬 가능성 있는 이야기가 아닐까요?


님이 생각하는것만큼 C가 구현하기 힘든 것도 아니며 안되는것도 아닙니다.다.
심각한수준? 분량을 따지는것일까요.. 난이도를 따지는것일까요? 어쨋거나 둘다됩니다.
대단한것인양 홍보한것에 비해 그다지 기가막히다는 생각이 안들더군요.


----------------------------------------------------------------------------

greatkgc의 이미지

Quote:

자바 certification을 이력서에 언급하면 초보자이다.

JCP를 이야기하는 모양이죠. 우리나라에서도 미국에서 인정을 해주지
않는 모양이네요. :lol:

matrix의 이미지

윗분의 말들중.. 잘해봐야 SI행이다..란 말이 정답이군요.

기술set자체들은 그렇게 어려운게 아니죠.. 응용이 문제일뿐입니다.
필요한 경우에 필요한 기술.. 이게 맞겠죠..
Thread 하나에도 머리가 뽀개지는게 Java죠..

오히려 코딩은 하나도 못하는 자칭 Architect들이 이런 기술Set은 잘 알고 있습니다만.. 그렇게 부러워보이지는 않습디다..

Wrapping을 잘 한답시고 암호문같이 되어버린 페이지를 보고 흐뭇하게 기술 타령하고 있는 사람보면.. 참 한심한 생각이 듭니다.

P.S.

근데 언제부터 Struts이 이렇게 고난위도의 프레임웍으로 인식되고 있습니까?
의외네요..

How do you define Real?

fender의 이미지

matrix wrote:
근데 언제부터 Struts이 이렇게 고난위도의 프레임웍으로 인식되고 있습니까?
의외네요..

Struts보단 MVC 구성 자체가 단순히 자바에 대한 문법 지식 정도를 알고 있는 일반적인 2-3년 차 개발자 수준에서 어렵다는 뜻이겠지요.

그리고 실무에서 중요한 건 내가 이 API를 써서 어떤 돌아가는 코드를 만들어 내느냐 못만들어 내느냐가 아닙니다. 그건 기본이지요... 중요한 건 '결정'입니다. 즉, 똑같이 Struts를 쓰더라도 프론트를 struts tags를 쓸것인지 jstl로 대체를 할 것인지, 아님 struts-jsf로 JSF와 연동할 것인지... 혹은 클라이언트 validation이 좋은지 서버측이 좋은지, 자체적으로 제공하는 데이터소스 연동을 이용하는게 맞는지 별도의 서비스 계층에 연동하는게 맞는지, 혹은 다이나 폼이 좋은지 그냥 일반 액션폼이 좋은지, 업데이트 페이지를 하나의 dispatch 액션으로 구현해야 하는지 두개의 서로 다른 액션으로 구현할지 등등... 실무에서 써보면 중요한 건 이런 문제를 이미 겪어보고 해당 프로젝트에서 가장 적합한 선택을 하는 것이 바로 기술입니다.

스트러츠의 경우 사실 고난이도는 맞습니다. 문제는 개념이나 API자체가 특별히 어렵다기 보다는 실제로 적용을 하다보면 걸리는 문제가 한 두가지가 아니라는 점이고, 이런 문제에 대한 해결책은 튜토리얼 한번 보는 수준으로는 파악이 안되고 실제로 실무에서 프로젝트를 많이 해보거나 메일링 등을 꾸준히 검색해봐야 알 수 있기 때문에 어렵습니다.

그래서 개인적으로 스트러츠의 이러한 한계 때문에 대안이 될만한 다른 프레임워크를 모색하는 중에 있습니다. 쓸데없이 어려운게 결코 바람직한 것이 아니니까요...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

chocoheim의 이미지

fender wrote:

그래서 개인적으로 스트러츠의 이러한 한계 때문에 대안이 될만한 다른 프레임워크를 모색하는 중에 있습니다. 쓸데없이 어려운게 결코 바람직한 것이 아니니까요...

JSF 는 어떠신가요?
SunTechDays 가니까 JSF를 열심히 밀어주는 분위기던데..

WaitplzplzWait