Web

블로그 봐주시는 모든 분들께 진심으로 감사드립니다.

Note&pen — Tue, 25 May 2021 00:14:54 +0900

블로그를 잘 관리도 못하고 있는데

꾸준히 방문자수가 있고 댓글도 달아주시고

정말 감사드립니다.

빠른 시일내로 다시 글 하나하나 포스팅 해보도록 하겠습니다.

'악덕 보도방' 구분법. [펌]

Note&pen — Fri, 6 Nov 2020 15:58:50 +0900

[펌] 출처 : https://www.facebook.com/groups/codingeverybody/permalink/4294604973913339

==========================================

SI 업체에 다녀본 경험으로 취업 준비생분들, 
그리고 이직 준비중이신 분들께 이 글을 바칩니다.

시작하기에 앞서 제가 지금 말하는 SI 업체는 일부 악덕 SI업체를 말하는 것이며
SI 회사를 다니시는 분들께는 미리 죄송하다는 말씀 드립니다.

제가 말하고자 하는 SI 업체는 소위 보도방 이라고 불리는 업체이며
IT랑은 전혀 관련 없는 회사라고 생각합니다.

이 업체들의 특징을 나열하며 여러분들의 선택에 도움이 되시길 바라겠습니다.

1. 면접을 보러 갔는데 공고란에 표기된 총 직원수 반의 반도 안되는 인원들만이 있다.

2. IT 기업이라고 하지만 사실상 개발자 인력파견소 라고 하는것이 맞다
싶을정도로 파견업무 이외에는 다른 업무를 거의 하지않는다.

3. 면접을 보러가면 경리분 1명, 사장 1명만 있는 경우가 많다

4. 관행이라며 개발자 경력을 3~5년 뻥튀기 시켜서 파견시킨다

5. 회사 입사를 하면서 면접을 이미 봤는데 프로젝트 투입시에도 또 면접을 본다

6. 신입사원 교육을 개발툴다루는 법 위주로 교육시킨다

7. 취업포털에 언제나 구인 공고가 올라와 있으며
구체적인 업무내용 없이 "웹 개발"이런 식으로 적혀있다

8. 개발 경력을 뻥튀기 시켰기 때문에 개발자에게 거짓말 잘 하는법을 가르친다

9. 업체 사이트로 들어가보면 알만한 대기업들
마크가 빼곡하며 협업회사인것처럼 꾸며 놓았다

10. 대리급이 어렵게나마 차장급의 일은 할수있어도 신입이 과장급의 일은
할수없어 튕겨 나오는 일이 허다하다

11. 버티고 버텨 경력을 쌓았건만 사장이 자기를 키워 준 줄 안다

12. 경력이 뻥튀기 되어 월 단가 500에 계약되었어도
정작 자신은 200도 못받는경우가 대부분이다

13. 1년 정도의 경력을 쌓으면 업체는 "반프리랜서"라는
방식을 권하며 정직원에서 빼내려 한다

14. 파견없이 대기가 길어질경우 임금을 주지 않는다

15. 개발자 80% 이상이 경력 3년이하 개발자이며
10년차 이상은 전무하다고 봐도 된다

16. 갓 입사한 신입일지라도 뻥튀기 시킨 경력으로 단독 파견한다

SI관련 글이 종종 보이는 것 같아 썼습니다

저는 입사후 바로 도망나왔습니다.

혹여 다른 분들께 도움이 될까 싶어 적습니다

경력 뻥튀기는 문서 위조이며 명백히 사기입니다

감사합니다

- 지금은 좋은 회사 잘 다니고 있습니다^^

[펌] 비전공자분들께 말씀드리는 제 경험과 조언

Note&pen — Sun, 23 Feb 2020 15:16:22 +0900

최근 OKKY 에서 비전공자분들을 위한 좋은 글이 나와

내 블로그로 퍼왔다.

OKKY에서 많은 좋아요를 받아 Weekly Best에 올라갔다.

비전공으로 개발입문을 하고자 한다면 꼭 읽어보자

원글 주소 : (https://okky.kr/article/680617)

=======================================

Okky라는 국내 최대의 개발자 커뮤니티를 꽤 오랜기간

눈팅하면서 때로는 자신감도 얻었고,

때로는 자괴감도 얻었습니다.

'와 저렇게까지 공부하고 노력하는 사람도 있구나... 대체 난 뭐하는 놈이지?'

사실 자신감보다는 자괴감을 더 많이 얻었습니다.

(그 자괴감이 채찍이 돼서 겨우 여기까지 오게 된 것 같습니다.)

그렇습니다. 저는 그렇고 그런, 비전공 학원출신 개발자입니다.

정말 힘들었습니다. 두 번의 우울증 치료를 받았고,

제가 처한 환경과 맞물려 한 때 극단적인 생각을 하기도 했었어요.

그래서 저 같은 비전공 학원출신 개발자가 여기까지 오게 된 사연과,

제가 온 길을 힘들게 걷고계신 분들께 현실을 좀 이야기해보려고 합니다.

이 글은 신세한탄이면서 조언이기도 하고,

제 과거이기도 하면서 여러분 앞에 펼쳐질 미래이기도 합니다.

비전공자이시거나 혹은 학원 등록을 준비하시는 분들이 이 글을 읽고

공감, 혹은 무언가 하나 깨닫고 가신다면 더 할 나위 없이 좋겠습니다.

그리고 개발자의 길을 걷고자 하시는 모든 비전공자 분들을 응원합니다.

1. 개발을 시작해보고 싶어요!

비전공자가 개발을 시작하게 되는 계기는 별거 없을 겁니다. 저도 그랬습니다.

(1) 지금 내가 가진 전공으로는 번듯한 직장에 취업하기 힘들다는 소문 혹은 사실 때문에

(2) IT 직종이 비교적 단기간에 쉽게 직장을 구할 수 있다는 소문 때문에

(3) 그렇게 구한 직장이, 다른 직종에 비해 연봉이 꽤 된다는 소문 때문에

솔직히 그렇지 않나요? 가끔 몇몇 분들은 이렇게 이야기하기도 합니다.

'아무것도 아닌 것 처럼 보이는 코드에서 무언가 아웃풋이 나올때 희열을 느꼈다'

'코딩이라는 과정이 하나의 퍼즐을 푸는 과정과도 같았다. 해보니 너무 재밌었다' 등등..

이와 같은 말이 진심인 분도 물론 계실겁니다. 일반화 하는건 결코 아닙니다.

하지만 대다수는 그렇지 않습니다. 이제 솔직해집시다.

지금 이 글을 읽고 계시는 비전공자분께서는 '개발'이 좋으신 겁니까?

아니면 그냥 '컴퓨터'가 좋으신 겁니까?

이 말은 같은 것 같으면서도 절대 같지 않습니다.

이 길을 준비하시는 비전공자 분들은 반드시 가슴 깊이 생각해 보셔야합니다.

혹시 컴퓨터로 즐기는 온라인 게임이 너무 좋아서

게임 개발을 해보자! 라는 생각을 하고 계시지는 않습니까?

'나는 웹서핑, 온라인 게임 등이 즐겁다' → '컴퓨터로 하는 일들이 좋다' → '개발이 좋다'

나 혹시 컴퓨터랑 잘 맞는거 아냐?

학원에 가시게 되더라도, 만족감을 얻지 못하고

육체, 정신적으로 매우 힘들 가능성이 높습니다.

그게 취업까지 이어지더라도, IT 특유의 기업문화때문에

금방 질려버리거나 환멸할 가능성 역시 높습니다.

'컴퓨터' 와 '개발' 이 둘의 차이를 반드시 깨닫도록 하셔야 합니다.

그 차이를 깨달았을때, 그래도 개발자가 되고 싶다면 도전하시면 됩니다.

둘의 차이를 깨닫는 방법은 어렵지 않습니다.

서점에 가셔서 C언어든, Python이든, Java든

언어에 상관없이 가장 느낌이 오는 개론서를 하나 구매하세요.

아니면 평소 많이 들어보았던 언어라도 괜찮습니다.

오늘날의 개론서들은 대부분 도서를 구매할 시 인터넷 강의를 제공합니다.

해당 강의를 진득하게, 일주일 정도만 들어보세요.

내가 좋아했던 '컴퓨터' 와, '개발'의 차이가 조금은 감이 오실겁니다.

2. 학원을 너무 믿지 마세요.

오랜 심사숙고끝에 학원에 등록하신 분들. 정말 고생많으셨습니다.

치밀하게 짜여진 커리큘럼. 짱짱한 커리어의 강사진을 자랑하는 학원!

이 곳에서 내 위대한 첫 걸음이 시작될 거라는 마음에 가득 부푼 당신.

혹시 취업이 급해서, 아니면 선택지가 없다는 이유로 단순한 사실 하나를

잊어버리고 계시지는 않습니까?

무슨 사실이냐구요? 그것은 '학원은 절대 자기 안좋을 이야기는 하지 않는다.' 입니다.

저는 한 번의 오프라인 멘토링 교육과 두 번의 학원 교육을 거쳤습니다.

세 번의 교육 기회에서 제가 얻은 결론은 유감스럽지만 바로 저겁니다.

오히려 두 번째 교육 기회에서는 정해진 커리큘럼대로 수업이 흘러가지도 않더군요.

그야말로 허송세월을 했습니다.

학원에서 교육받은 대로만 하면 취업 할 수 있을 것이라는 생각은 버리시는게 좋습니다.

국비교육 한 두번으로 위 1번에서 이야기했던 좋은 조건의

회사에 취업할 수 있을 것 같으면 대체 누가 개발자를 하지 않으려 하겠습니까?

학원에서 교육하는 내용을 그 시간 내에 100% 머릿속에 흡수하고,

그와는 별도로 코피터지게 공부해야 합니다.

만만치 않습니다. 힘들고, 고독하며, 냉혹하고 가차없습니다.

전공자는 4년에 걸쳐 배우지만, 우리같은 사람들은 짧게는 3개월,

길게는 8개월만에 다 헤쳐내야 합니다.

(학원에서 분명 이런 말을 합니다.)

그래야 학원 수료할 때 쯤에 겨우겨우 취업이 될까 말까 합니다.

그리고, 취업한 곳은 십중팔구 여러분이 생각했던 처우와 연봉과는 다릅니다.

제 첫번째 우울증이 이렇게 왔습니다.

아마 저와 같은 비전공자 분들은 정도의 차이만 다를 뿐

이와 같은 아픔을 겪었거나, 겪고 계시거나 혹은 앞으로 겪을 겁니다.

3. 당신을 먼저 뽑아야 할 이유

저는 2018년 중후반부터, 2019년 중까지 1년 가까운 기간동안

이력서를 내고 면접을 봐 왔습니다. 대부분 탈락이었죠.

탈락 문자나 메일이 오면 염치불구하고 제가 부탁드렸습니다.

탈락한 것은 내가 실력이 부족해서 그렇다는 것을 안다.

그렇다면 어떤 점이 부족했으며 앞으로 어떻게 하면 좋겠는지

솔직하게 조언 한마디만 해주셨으면 감사하겠다...

떨어뜨린게 미안해서였는지, 아니면 진심으로 저를 걱정해주셔서 그런지는 몰라도

몇몇 기업이 문자든 메일이든, 짧든 길든 답장을 해주셨습니다.

내용은 각양각색이었지만 주제를 뽑으면 다음과 같습니다.

'당신의 포트폴리오와 이력서를 잘 보았다. 열정과 의지가 느껴진다.

하지만 그 이상이 없다. 당신과 다른 지원자들의 포트폴리오들을 비교해 보았을때,

그들보다 당신을 먼저 뽑아야 할 이유가 보이지 않는다.'

망치로 뒤통수 한 대 맞은 기분이었습니다.

그렇습니다. 당신이 가고 싶은 그 회사. 비전공자만 지원하는거 절대 아닙니다.

당신이 취업하기 위해 넘어서야 하는 사람들은 바로 여러분보다 학력도 높고, 자격증도 많고,

포트폴리오도 많고 퀄리티마저 높은 그 전공자들입니다.

학원에 있다보면 시야가 좁아집니다. 그리고 자연스럽게 이런 착각을 하게 됩니다.

세간에서 많은 분들이 하시는 말씀 중 하나입니다. 다음은 불행일까요? 다행일까요?

세상의 모든 전공자들이 모두 월등한 실력을 갖추고 있는 것은 아니다.

컴퓨터 공학과를 나왔지만 코딩이 마음에 들지 않아 다른 길로 가는 사람도 있다.

애석하지만 취업을 준비하는 비전공자 개발자 입장에서는 불행에 가깝습니다.

왜냐하면 저런 사람들이 떨어져나가고 남은 전공자들은 개발자가 되기 위해

어떤 식으로든 우리보다 많은 노력을 기울였을 것이기 때문입니다.

포트폴리오도 여럿 만들었을 것이며,

누군가는 공모전 등에서 입상한 경력도 있을 수 있습니다.

개발자를 준비하시는 비전공자 여러분!

학원 한 번 수료한 상태로 이 분들과 경쟁할 수 있으시겠습니까?

그래서 이유가 필요합니다. 내가 적어도 이 사람보다는 이런 면에서 더 낫다는 이유.

이 회사에서 다른 지원자들 보다 내가 돋보이는 이유.

경영자가 나를 뽑을 수 밖에 없는 이유.

특히 다른 곳에 취업한 경력이 없는 신입분들에게는 꽤 중요합니다.

또 세간에서 많은 분들이 물어보시는 것입니다.

'신입이 이 정도만 할 줄 알면 되나요?', '신입에게 필요한 스킬에는 뭐가 있을까요?'

그 정도는 신입이 할줄 몰라도 괜찮다고 한다면,

그 부분은 공부하지 않으실건가요?

필요한 스킬 목록에 없으면, 그냥 무시하실건가요?

그 말에 그대로 따랐다가, 여러분이 면접보러 간 그 회사에

그 기술을 알고 있는 지원자가 있으면 어떡하실래요?

여러분이 경영자라면 누구를 뽑겠어요?

학원에 다니는 비전공자분이 하기 쉬운 실수는 학원에서

'이 정도만 하면돼~' 라는 기준에 매몰되기 쉽다는 겁니다.

천편일률적으로 가르치는 모델2, 알지도 못하고 사용하는 MVC...

회사에서 보고 뭐라고 생각할까요?

다 알고 있습니다. '이 친구는 그냥 학원에서 하라는대로만 한 친구구나...'

면접관 입장에서 다 보인다고 합니다.

학원에서 만들어주는 포트폴리오. 절대 그대로 내지 마세요.

좋은 곳에 취업할 수 있다면, 10달이 걸려도 늦지 않습니다.

그 프로젝트를 갖고 못해도 2달은 보강하고

살을 붙이고 더 풍성하게 만들 각오를 하세요.

학원 포트폴리오를 바탕으로 해서 자신이 공부하고 배운 내용을 덧붙이고,

여러가지를 시도하면서 증거를 남기세요.

그것만으로도 포트폴리오에 쓸 내용이 많아지고,

전체적으로 퀄리티 자체가 달라보입니다.

보통 학원에서 모델2 방식이나 Spring을 가르친다면

MVC 패턴으로 DB 연동해서 게시판 만들겁니다.

게시판을 통해 CRUD 학습하고, 결과물 눈으로 확인하기 좋죠.

대다수 학원이 게시판 만들어보라고 합니다.

그런데, 게시판이 쉬우려면 한없이 쉽고, 어려우려면 한없이 어려운 프로젝트에요.

그 게시판 프로젝트에 만약 사진 게시판을 따로 추가한다면?

다중 파일 첨부 기능을 추가한다면?

관리자 페이지를 추가한다면?

비밀글 기능을 추가한다면?

댓글을 비동기로 추가할 수 있게한다면?

에디터를 추가한다면?

각종 작업을 새 창에서 처리하도록 하게 만든다면?

진입시 팝업이 나오게 만든다면?

게시물에 좋아요 기능을 추가한다면?

게시물 통계 페이지를 구축한다면?

당장 생각나는것만 해도 우루루 나옵니다.

학원에서 준 포트폴리오 프로젝트의 DB를 수정해서

좀 더 많은 정보를 수집하게 만든다던지,

컬럼을 더 만들어서 이에 따른 기능을 늘리던지 하는 식으로

얼마든지 포트폴리오를 풍성하게 만들 수 있습니다.

CRUD만 딸랑 되는 게시판 포트폴리오보다 훨~씬 나아요.

기술면접에서 할 말도 많을 거구요.

저의 경우 '나를 뽑아야 할 이유'를 그렇게 잡았습니다.

여러 프로젝트에 참여해서 포트폴리오를 여러 개 남길 수 없고,

아이디어가 흘러 넘쳐서 생각나는걸 족족 만들어 볼 수도 없었습니다.

그래서 학원에서 받은 포트폴리오라도 그 깊이를 다르게 하려고 했어요.

같은 학원 출신이지만 그들 보다는 좀 더 많이 공부했다는 사실과,

많은 걸 접해봤고 또 그러한 지적 욕구를 충족시키기 위해 노력하는 타입이라는 것을

어필할 수 있는 괜찮은 방법이라 생각했습니다.

다른 분들의 성공 후기만큼 거창하고 엄청난 노력을 했느냐? 아니에요.

제가 보통 평범한 분들과 다른 것은 학원에서 준 포트폴리오가

완성되고 난 이후에 추가하고 싶거나 실험해보고 싶은 것 두어 개 정도를

일주일 정도 시간을 두고 구글링 및 직접 코딩해보면서 적용시키고,

에러가 나면 해결하기 위해 삽질하고,

해결이 되면 내가 무엇을 착각해서 잘 안되었던 건지

그 원인과 해결 과정을 블로그에 썼어요.

하루 두~세시간정도 고민할 시간이 있으면 일주일에

기능 한 개 내지 두 개 정도는 기능을 추가할 수 있더라구요.

그런식으로 한 달 반 ~ 두 달 정도 학원 포트폴리오를 업그레이드했습니다.

다중 게시판, 계층형 게시물 구조, Ajax를 통한 댓글 통신,

알림형 게시판, 비밀글 기능, 관리자 페이지, 통계 페이지, 팝업 기능 정도의 기능을 갖췄네요.

또한 기본 html 프레임이 좀 보기 싫어서 부트스트랩을 이용해 페이지를 꾸몄습니다.

또한 프로젝트 버전 관리를 위해 Git을 개인적으로 공부했습니다.

어느 선에서 무언가 다른 시도를 해보고 싶을때,

branch를 새롭게 따서 시도해보고, 영 안된다 싶으면

다시 엎고 새로 짜는 식으로 공부를 계속 했어요.

쉬운 기능은 직접 개발했지만, 텍스트 에디터나 모달 경고창 같은 것들은

시중에서 무료로 사용할 수 있는 예쁜 오픈소스 라이브러리를 사용했습니다.

물론 그것까지 제가 다 개발하면 좋지만 시간적, 금전적 요소를 고려했을 때

다른 사람이 만들어 둔 라이브러리를 잘 사용하는 것도

하나의 방법이라고 여겼기 때문입니다.

어라? 그냥 제가 했던 일을 서술했을 뿐인데

마치 기술 면접처럼 느껴지지 않으신가요?

이 정도면 면접에서 꿇리지는 않을 겁니다.

위의 사례는 제 이야기인데,

실제로 기술 면접 시에 3명이 들어가서 30분간 저만 이야기했습니다.

면접관분들께서도 꼬리에 꼬리를 물고 계속 물어봐주시더라구요.

마치 그냥 대화 나누듯 면접을 봤어요.

'오~ 해 본거 많으시네~ 웬만한 전공자보다 많이 공부했네요.'

이 때 합격을 예감했고, 예감은 실제가 되었습니다.

지속되던 우울증, 무기력감 증상이 2주 만에 사라지더라구요.

저는 지금 업력이 20년이 훨씬 넘고,

근무자가 80명쯤 되는 꽤 규모있는 SI 회사에 다니고 있습니다.

연봉이 엄청 높지는 않지만, 그래도 야근이 잦지 않고,

만약 하더라도 수당을 주지 않는 곳은 아닙니다.

오히려 제게는 과분한 회사지요.

저라서 가능했던 것 아닙니다. 여러분도 할 수 있습니다.

하지만 포기하면.. 거기서 끝입니다.

-마치며-

경험을 끄집어내서 쓰는 글이다 보니 중간중간 표현이 거칠거나

어쩌면 좀 언짢으실지도 모르겠다는 생각이 듭니다.

제가 무슨 경력이 몇 십년 쯤되는 신선도 아니고, 인생사에 달관한 달인도 아닙니다.

그렇기에 당연히 제 말은 진리가 아닙니다.

저는 오히려 취업하기 어려워서 도망치듯이 국비학원으로 들어간 축에 속합니다.

그 안에서 웃고, 때로는 펑펑 울기도 하고,

옥상 끝에 서보기도 하는 고단한 시간을 겪고 난 뒤에야

이제 겨우 어디가서 개발자라고 말하고 다닐 정도가 되었습니다.

원래 새로운 세상으로 나아가려는 자는,

원래 살던 세상을 부숴버려야 한다는 말이 생각납니다.

자신이 안주하던 세상을 부수는 것은 분명 어렵고, 힘들고, 두려운 일이지만

겪어보니 못할 일은 아닙니다.

정말 강조하고 싶은 것 하나는,

저라서 가능했던 것이 아니라 비전공자인 누구든

할 수 있다는 사실이 전해졌으면 좋겠습니다.

두서없는 글을 읽어주셔서 감사드리고,

다시 한번 개발자가 되고자 하는 비전공자 분들을 응원합니다.

[펌] 나이먹은 아저씨가 초보분들에게 그냥 쓰는 뻘글

Note&pen — Sat, 22 Feb 2020 15:28:41 +0900

최근에 OKKY에서 많은 좋아요를 받아

Weekly Best 에 오른글을 퍼왔다.

신입이던 신입이 아니던 한번 읽어보면 좋을것 같다.

원글 출처 : (https://okky.kr/article/681218)

============================

2001년 1월말에 신입으로 입사해서 이제 만 19년이 막 지났네요.

배도 안나왔고, 머리숱도 아직 멀쩡하고 결혼도 했으니 나름 성공했네요.

뭐 딱히 글을 잘 쓰는것도 아니라서 필력좋게 길게는 못씁니다.

그간 많은분들과 일해봤었는데 (회사에서 일하거나 SI를 하거나)

생각나는 아쉬운 부분들만

몇가지 써볼께요. 시간 되시면 그냥 슬쩍 읽어보세요.

아.. 저는 여전히 코딩합니다.

설계도 하고요. 그냥 개발자1 입니다.

1. 디버깅

디버깅은 공부를 시작했건 현업에서 일을 하건 언제나 늘 하죠.

HelloWorld를 짜도 디버깅합니다.

그런데, 디버깅을 못하는 분들을 참 많이 봅니다. 잘 안되는게 아니라

아예 방법을 모르는 분들이요.

이게 딱히 정석적인 방법이 있다고는 할 수 없습니다만, 전혀 감을 못잡고

그냥 파라미터가 안넘어와요~ 하는 분들 많이 봤습니다.

7~8년차되는 중고급자들이 디버깅 하면서 어버버 거리는 모습을 정말 많이 봤답니다.

감은 경험적으로 생기는거니까 많이 하다보면 늘긴 합니다만,

그 이외의 것들은 방법을 찾아보거나 연습을 해서 알아 두시면 좋겠네요.

자신의 메인 개발툴에서 대부분 훌륭한 기능들이 많이 있으니

공부하면서 디버거의 좋은 기능들을 잘 활용해보시면 좋겠습니다.

2. 문서읽기

예나 지금이나 남들이 적어놓은 글들을 읽는건 여전히 중요하다고 생각합니다.

요즘은 책으로 공부하는 시대가 아니니 훨씬 좋아졌죠. 눈은 더 아파옵니다만.

본인의 관심분야나 프레임워크들과 관련된 좋은 분들이 적힌 블로그들이 차고 넘칩니다.

쉴때 자주 읽어보면 좋겠네요.

원서로 써있는게 상당히 많으니 대강이라도 꾸준히 읽으면 어느정도는 눈에 들어옵니다.

어차피 우리는 번역을 할게 아니니까 필요한 만큼만 대충 알아들으면 됩니다.

개발 문서들은 대부분 설명+코드로 되있으니

읽기가 많이 어렵지는 않죠.

3. 환경에 대한 기본이해

코드는 그럭저럭 잘 짜는데, 환경에 대한 이해도가 전혀 없는 경우도 종종 봅니다.

이건 주로 경험이 없는(적은)신입

시절에 당연히 흔히 있는 일인데,

경력이 어느정도 있는 분들도 그런 경우가 많이 있습니다.

이건 아마 시각이나 상황에 따라 이견이 있을수 있겠습니다만,

만약에 웹 개발을 한다면 최소한 웹 브라우저에서 도메인주소를 입력해서

최종 html결과물을 받아보는데까지

무슨 일이 벌어지는지는 대충 이해를 하고 있어야 만약에 문제가 발생하면

어느부분 혹은 담당자가 확인해야하는지

알수가 있는데, 그렇지 못하면 그냥 에러나는데요? 에서 진도가 안나갑니다.

관리하는 사람들 입장에선 답답한 노릇이죠.

4. 확실한 전공 하나

지금 공부하시는 분이라면 딱 한가지는 확실하게 할 수 있는것을

만들어 두시는게 좋다고 생각합니다.

프레임워크도 워낙에 많고, 언어도 많습니다. 그걸 다 아는 사람도 없고,

다 잘 하는 사람은 더욱이 없죠.

또 프로젝트마다 환경도 제각각이라 새 프로젝트를 들어가면 새로 공부하는 기분입니다.

하지만, 한가지를 잘 해두면 문서좀 찾아보고 샘플 만들어보고 적응좀 하면

오래지나지않아 작업할수가 있게되죠.

웹 프레임워크라면 최소 한가지는 자신이 익숙한것을 만들어두고,

해당 언어는 정확히 쓰는법을 알고나서 확장을 하면

좋겠습니다. 유행따라 이것조금 저것조금하면 아무것도 모르는것과 동일하게 되죠.

5. 대인관계

뭐가됐든 결국은 사람들과 함께 하는 일이니 대인관계는 중요하다고 생각합니다.

맨날 술마시고 다니라는 얘기는 아니고,

서로 예의바르게 지내는거면 충분하다고 생각해요.

요즘은 몇몇 주당들 빼곤 술 잘 안마시죠. 어쩌다 회식이나 하면 모를까.

개인적으론 술을 좋아하지만, 회식문화 별로 안좋아합니다. 걍 퇴근하는게 좋죠.

잘 모르는 사람이라도 마주치면 가볍게 인사하고, 지나가다 눈 마주치면

목례라도 하면 나중에 부탁할일이 있을때

반드시 큰 도움이 됩니다.

사람관계라는게 사실 별게 없거든요. 학연,지연 뭐 그런게 아니더라도,

자주 웃으며 인사하고 얼굴 본 사이라면

큰 소리 낼것도 덜하게 되고요. 문서로 싸울일을 메신저로 주고 받으며 끝낼수 있습니다.

6. 할말은 하자

위 대인관계와 관련있기는 한데, 예의와 절차를 맞춰

본인의 의사는 정확히 밝히는게 좋습니다.

거절을 못하다가 혼자 모든 일을 떠 안고 자폭하는 경우를 많이 봤습니다.

완급조절이 중요한데, 그렇다고 전부다 거절을 하면 그것도 문제니까,

적당한 선을 조절하는 방법을 익히면 좋습니다. 이게 어렵기는 하죠.

말할 상황이 아닌데, 어떻게 할말을 하느냐고 생각할순 있습니다만,

그래도 한번 하면 그 다음은 쉽습니다.

다만, 팀장한테 할 얘기를 대표이사에게 떡하니 메일보내는 상황은

피하시는게 좋겠죠. 같이 죽자고 생각했는데, 혼자만 죽는 경우가 생깁니다.

7. 결정은 빠르게

게시판에서나 실제로도 회사 혹은 동료가

너무 맘에 안들어서 엄청난 스트레스로

고민하는 경우를 많이 봅니다.

지금 하고 있는 업무가 너무 마음에 안들거나 불합리한 대우를 받고 있다고 느끼지만,

이도 저도 결정을 못하고 고민만 하다 시간만 갑니다.

지금 다니는 곳이 본인 경력에 전혀 도움이 안될것 같다면,

최대한 빨리 판단하는게 좋습니다.

상급자와 술한잔 마시며 고민상담해봐야 돌아오는건 시간 지나면 괜찮아질꺼야~

정도일 확률이 높습니다.

다만, 다른 업무를 받을 수 있는 여지가 있고, 회사는 마음에 든다면 우선 상담을 추천하고요.

직급이 높은 사람들도 결국은 사람이니까 대체로 대화가 되기는 할겁니다.

하지만, 지금은 어렵지만 다음에 봐서 해줄께~ 같은 대답이 돌아오면

그날부터 날짜를 계산해서 시나리오를 짜보세요.

경력인정은 받을수 있는 기간인지,

언제쯤 퇴사를 해야 다음 회사로 매끄럽게 연결되서 입사를 할수 있을지

등등을 계산해서 최대한 빨리 결정하고 진행하세요.

시간이 지나면 나이와 경력만 까먹습니다.

이변이 없는한은 3년 이내에 결판을 보는게 좋다고 봅니다.

적당히 경력도 있으니 이직의 우위를 가질수 있죠.

뭐 더 쓰라면 더 있긴한데, 굳이 뭐...싶기도 하고

이것저것 써봐야 꼰대인거 들킬까봐;;;; 아.. 이미 들킨건가..

여러분 주변의 아저씨들도 다 같이 어버버 거리던 시절이 있었는데,

나이먹고 기억력이 흐려져서 다 잊어버린거죠.

자바스크립트 table, tr, td 핸들링 하기

Note&pen — Sat, 3 Aug 2019 15:04:18 +0900

이번엔 저번 포스팅에서 다룬 table, tr, td 태그를

핸들링을 해보도록 하자.

저번 포스팅과 다르게 rowSum function을 추가했다.

그리고 행을 추가할때도 "수량" 이라는 로우에는 onkeyup 을 추가했다.

onkeyup에 this를 파라미터로 넘겨주었다.

rowSum 함수에서는 parentNode를 2번이용해 tr 태그 까지 접근한다.

(input 태그 -> td태그 -> tr태그)

cells를 이용해 내가 입력한 로우의 열에 접근한다.

cells[0]은 과일이름 [1]은 가격 [2] 은 수량이 된다.

가격을 입력하고 수량을 입력하면 가격 * 수량의 합계금액이

계산되어 자동으로 입력되어지게 된다.

자바스크립트 HTML 테이블 행 추가하기 (td태그 복사)

Note&pen — Sat, 3 Aug 2019 14:44:15 +0900

HTML에서 table, tbody, tr, td 를 이용해

간단하게 표를 만들고 버튼을 눌러 행을 추가하는 기능을 만들어보자.

일단 행을 추가해줄 버튼과 아이디, 이름, 전화번호, 주소를 td 태그를 이용해 만들어 주자.

이제 "로우추가" 라는 버튼을 누르면 행이 추가될 수 있도록

function을 만들어주자. 간단하게 insertRow() 를이용해 행(로우)을 추가할 수 있다.

insertCell() 은 열을 추가하는 것인데 insertRow 가 tr 태그를 추가하는거라면

inserCell은 td 를 추가하는 것이다.

innerHTML을 이용해 input 태그를 넣어줬다.

로우추가 버튼을 누르면 아래와같이 로우가 추가되고

innerHTML을 이용해 input 태그가 들어가 있는 상태이므로

아래처럼 값을 입력할 수 있다.

[펌]회사 선택시 고려 사항

Note&pen — Sat, 25 May 2019 16:52:34 +0900

보통 취업을 한다고 이력서를 낼때 대부분이

여러 회사에 이력서를 넣어 몇십, 몇백에 가까운 이력서를

내게된다. 하지만 몇가지 고려사항이 있는데

이것은 이력서를 낼때나 회사에 합격해 입사선택에 있어서

고려해야 할 사항들이다. 개인적으로 1, 4번 은 정말 필수 사항이다.

특히 1은 어떤 사수를 만나냐에 따라 나의 성장속도가 달라지기 때문이다.

출처 : (https://okky.kr/article/581302)

=========================

학원 수료를 맞치시거나 다른업종에서 일하시다가

개발자 하실려는 분들 회사고르시는데 무척이나 고생하시는거 같은데

저의 첫 개발회사 입사할때느낌이라 오버랩이 많이되네요..

제가 회사 고르는 기준으로 가시면 못해도 막장은 아닐꺼라 생각합니다.

1. 사수가 있는 회사로 간다.

바로 위에 대리 및 과장급 개발자가 있어야 됩니다 무조건입니다.

신입이면 아무것도 모르는상황인데 사수가없다. 절대 비추하는 회사이며

바로위에 PL 급은 있어야 제대로 된 회사라 생각하시면됩니다.

2. SI라도 사내에서 개발하거나 한곳에서 상주하여 개발하는 회사를 가야합니다.

매번 지방으로 팔려나가듯이 팔려나가는 SI말고

갑인회사를 제대로 물고있는 SI회사를 가시기 바랍니다.

아니면 사내에서 프로젝트수주에서 개발하는 회사거나

둘 중에 하나 아니면 SI는 고려하지 않는게 좋습니다.

3. 신입연봉을 최저시급이하로 줄려는곳은 피하라.

신입연봉 2400도 안되는되는 쳐다보지도 말고 갈생각도 하지마세요

그런회사는 배울것도 없을뿐더러 가더라도 고통만 있을곳입니다.

4. 집과 회사의 거리가 1시간 이상이면 후순위로 고려하세요

집과 회사거리가 1시간 이상이면 하루하루 다니는 피로도가 상당합니다.

출퇴근 시간2시간이면 개인의 역량을 키울수 있는시간이 없다시피합니다.

출퇴근 시간은 최소 40~50에 맞춰보시고 그이상은 후순위로 선택하세요.

5. 야근을 지향하는 회사는 피하라

면접시 물어보세요 야근을 하냐고 ?

야근을 당연시하는 회사는 그냥 답이없습니다.

자기가 맡은 업무가 끝나면 바로바로 퇴근할수있는 회사 그런회사 위주로 가세요

6. IT 노조 Q&A 게시판에 회사명을 검색하세요

IT노조에 올라온회사들은 정말 악질인 회사만 올라옵니다

그런회사는 무조건 피하고 봅니다.

위에 적힌대로만 회사고르고 입사하시면 평균적인 회사는 다니실거라 봅니다.

신입 및 새로이 개발자로 일을 시작하시는분들 좋은회사 취업하시길 바랍니다.

[펌]SI 개발자의 잡담입니다.

Note&pen — Sat, 11 May 2019 16:07:50 +0900

출처 : (https://okky.kr/article/576238)

==================

경력을 쌓다보니 이런저런 일을 많이 겪었습니다.

그리고 이런저런 생각을 하게 되었습니다.

지난 세월동안 만난 IT쪽 인연들을 소홀히 하지 않으려 노력한 결과

조금의 주기적으로 만나는 사람들이 생겼습니다.

그리고 그 모임들 속에서 듣던 이야기들이 기억나서 조금 적어봅니다.

주로 신입 분들, 특히나 비전공 SI 개발자들에게 해당되지 않을까 싶습니다.

건강을 우선으로 챙기세요.

건강이 무너지면 정말 모든게 무너집니다.

쌍코피 터트리며 치열하게 일하고 공부하는 것도 좋지만

더 좋은 것은 건강하게 공부하고 건강하게 일하는 거라고 생각합니다.

공부라는것은 오래 달리기라 생각하고 하는 것이 좋고

일하는 것도 오래 달리기라 생각하고 하는 것이 좋다고 생각합니다.

공부나 일하는 것은 단거리를 죽자고 달리는건 아니라는 생각이 들더군요.

그래서 건강을 우선으로 챙기세요.

워크앤라이프밸런스, 좋습니다.

좋은데, 신입 때는 마음을 비우시는게 좋습니다.

이런저런 책이나 이야기를 듣다보면 무시무시한 이야기를 들을 때가 있습니다.

투자를 받은 스타트업의 경영진 및 핵심 임원을 일일 13시간 이상 일해야 한다.

신입이라면 달을 보고 출근해서 달을 보고 퇴근해야한다.

선임보다 10분 먼저 출근하고 30분 늦게 퇴근해야 한다.

꼰대의 말처럼 들리기도 하고 무시무시하기도 합니다.

근데 비전공 개발자시라면, 특출나게 잘하는 것이 아니라면,

자신의 시간을 쏟아부으셔야 할겁니다.

그게 일, 특히 개발 업무라면, 자신의 시간을 많이 쏟아 부으셔야 할겁니다.

그 인내의 시간은 길지 않을 겁니다.

개발 업무에 많은 시간을 투자하고, 여유 시간엔 운동과 자기계발에 투자하면,

어느 순간 여러분의 곁에서 알게 모르게 손짓하는 사람들이 많아집니다.

여러분과 같이 일하고 싶어하고 프로젝트에서 동료가 되어 주었으면 하는

사람들이 생기기 시작할 겁니다.

좀 더 직설적으로 말하자면, 처음 신입 1년 동안은 워크앤라이프밸런스에 대해 미련을

접어두시는게 좋은거 같더군요.

이걸 굳이 적는 이유는 저 역시 신입때 워크앤라이프밸런스에 대한 미련이 너무나도 컸고

그게 안되서 불만도 많았기 때문입니다.

근제 지나고 보니 그게 저를 좀 더 끌어 올려주는 시간이 되기도 했더군요.

그렇다고 아름다운 기억이란 건 아닙니다. ㅎㅎㅎ...

마치 군대를 다녀온 뒤라면, 그래, 그땐 그랬지, 하는 마인드와 비슷한거 같아요.

연봉은 상대적인 겁니다.

꼭 실력이 연봉이 되진 않습니다.

시스템이란 것이 정해져 있고 그 틀을 크게 벗어나지도 않는것 같습니다.

하지만 사람들 사이에서 차이란 것이 생기고 사람들이 이것이 표준이다. 라는 것을

벗어나는 사람들을 많이 봤습니다.

저 역시 연봉인상률이 표준의 것과는 거리가 멀고

초봉 역시나 제가 시작할 당시 저와 비슷한 스펙을 가진 이들이

받는 초봉과는 거리가 멀었습니다. 초봉은 안 좋은 쪽으로 거리가 멀었습니다.

연봉인상률 역시 들쭉날쭉 했습니다.

분노할 때도 있었고 기쁠 때도 있었는데 결론은 지금은 스스로 생각하기에

잘 받는 편이라 생각하며 만족합니다. 물론 앞으로도 성과를 더 보이고

더 많이 받고 싶습니다...

적고 싶은 것은...

초봉에 너무 집착하지 마세요.

물론 말도 안되는 초봉은 문제가 있겠지만.

"저 사람도 저렇게 받는데" 에 집착하지 마세요.

자신이 그럴만한 가치가 있다고 생각하고,

또 그 가치를 주변에서 인정해주고,

또 그 가치에 맞는 만큼의 기회를 주면

그 기회를 잡는 것도 좋다고 생각합니다.

좀 더 직설적으로 정리해 보자면...

자신의 가치를 쌓아가시고

자신의 쌓은 가치를 증명하시고

증명한 가치를 주변에 알리세요

물론 자신이 가치를 쌓았고 그것을 증명하였고

그것을 주변에서 모두 인정해 주는데,

그걸 회사에서 인정해주지 않는다면

그때는 깊은 고민이 필요한 시점이라고 생각합니다.

사람들과 잘 지내세요

물론 이런 글 적는 저도 잘 지내려 노력해도 안될때도 있었습니다.

하지만 그럼에도 저도 매번 사람들과 잘 지내려고 노력합니다.

그 사람이라는 것은 고객사 직원, 수행사 직원, 협력업체 직원, 상사, 동료,

부하, 프리랜서 모두 포함될 것입니다.

프로젝트를 할 때마다 느끼겠더군요

프로젝트는 여러 명이 모여서 같이 협동하여 시스템을 만들어

나가는 것이란 것을,

사람들과 잘 지내세요

그렇다고 호구가 되라는 것은 아닙니다.

하지만 그렇다고 까칠한 사람이 되라는 것도 아닙니다.

이건 뭐라 적기 힘드네요.

그저 이렇게 밖에 적을 수 밖에 없네요...

사람들과 잘 지내세요.

꾸준히 공부하세요.

꾸준히 운동하시고

꾸준히 사람들을 만나시고

꾸준히 커뮤니티에도 참석하세요

가족도 챙기시고.

바쁘네요 ㅎㅎㅎ.

꾸준히 공부하고 운동하고 사람들을 만나고

가족들을 챙기다 보면은 사람들이 그다지 관심도 안 가지고

존중해 준다는 느낌도 안드는 신입 시절이 지나고

어느 순간 상사도 존중해주고, 주변에서도 인정해주는

자신을 발견하실 겁니다.

세상엔 일정한 규칙, 시스템이 존재하는것 같아요

그래서 그것을 크게 벗어나는건 힘들죠

하지만 반드시 불가능하다는 것만도 아닌것 같아요

크게 벗어나지만 않는다면 다른 이들이 보기에는

그렇게 큰 차이가 아닐 수도 있지만.

또 다른 이들이 보기에는 큰 차이라 할 수 있는 것을 만들어가며

경력을 쌓아가는 사람들을 보곤 했습니다.

결국, 비전공 개발자로서 경력을 쌓아가며 나가는 길에서는,

딱딱 구분되어지는 정답이란 것은 없는것 같습니다.

벌써부터 여러 갈래로 갈라져 가는 저의 주변 사람들을 보면요.

너무 먼 미래를 생각하면서, 그리고 초라한 지금을 생각하면서

좌절하지 마시고 인내하고, 그리고 스트레스도 풀어가며 관리하시고,

꾸준히 노력해보세요.

글이 길었네요.

이런 글 적는 저도 앞으로 갈 길이 많이 남았습니다.

어쩌면 길이 짧을 수도 있지만, 그래도 많이 남았을 거라 생각합니다.

저도 제가 여기에 적은 것처럼, 그렇게 꾸준히 살아보려 합니다.

왜냐면 저는 지나간 시간 속에서 그게 저에게 좋은 영향을 끼쳤다는 것을 경험했으니까요.

그래서 여기에 글을 남깁니다.

화이팅하세요.

토비의 스프링 Vol.1 후기..

Note&pen — Sat, 11 May 2019 15:43:47 +0900

저번주 토비의 스프링 3.1의 Vol.1 을 다 읽었다..

엄청 오래 걸렸다. 원래 금방 읽을수 있었는데..

보기 귀찮아서 미루다보니 뭔 책 한권 보는데

몇달이 걸린건지...

원래는 토비의 스프링을 보면서 중간중간 좋은 부분들을

블로그에 정리하려했는데 이건 뭐 내용이 계속 이어져있어서

정리를 못했다. 일단 토비의 스프링 Vol.1을 읽으면서

느낀건 "참.. 오래된 책이다..." 라는것이다.

okky 에서도 많은 분들이 스프링 공부를 할때

이제 토비의 스프링을 추천하지 않는다.

너무 오래된 책이고 책안에 많은 내용들이

이제는 쓰이지 않거나 너무 심오있게 필요없는 것까지

깊게 알려주기 때문이란다.

Vol.1을 읽고 저 말에 동의했다.

너무 오래된듯한 느낌이다. 그리고 너무 내용이 깊다

JDBC 커넥션을 뭐그렇게 깊게 설명하는지 모르겠다.

확실히 입문자용은 아니고 나중에 경력이 쌓여

진짜 개념 하나하나 스프링의 역사를 다 알고 싶을때 읽으면 되는 책같다.

이제는 Vol.2만 남았다. 빨리 Vol.2 까지 읽어버리고

다른 책을 읽어야겠다는 생각이 든다. 뭔가 비싸게주고 사놨는데

지금 읽기엔 버거우니 너무 아깝다. 2~3년 썩혀두고 나중에 좀

자세히 읽어봐야겠다. 이러다 개정판이 나온다면... 저 책은 라면 받침대로..

- 토비의 스프링 Vol.1 후기 -

1. 책이 오래됨, 읽다보면 내용들이 올드함.

2. 필요없는 내용들이 섞였있음.(지금은 몰라도 되는내용)

3. 읽으려면 3~4년 이상의 경력쌓고 읽기 추천.

4. 스프링을 깊게 공부하기에는 정말 좋은책.

2019 스택오버플로우 개발자 설문조사

Note&pen — Sun, 5 May 2019 17:30:38 +0900

스택오버플로우... 이 사이트는 개발 공부를 해본사람이라면

한번쯤 들어가봤을 사이트이다.

전세계의 수많은 개발자들이 이 사이트를 이용해

개발관련 정보를 공유한다.

나또한 웹개발 공부를할때 정말 많이

사용했던 사이트이다. 지금도 많이 사용하고있다.

그런데 스택오버플로우에서 올해초 재밌는 설문조사를했다.

여러 방면의 재밌는 주제로 설문조사를 했으며

약 9만명의 개발자들이 설문조사에 참여했다.

심심할때 한번쯤 보면 재밌을것같다. 물론 영어로 되어있어서

보기좀 힘들지만 우리에겐 한글번역이있다.

https://insights.stackoverflow.com/survey/2019

[펌] - 후배 개발자에게 - 2019

Note&pen — Sun, 7 Apr 2019 13:55:11 +0900

블로그에 올릴 포스팅 소재거리를 찾다가

SI관련 글이 보여 내 블로그로 퍼왔다.

일단 글쓴이 분은 오랜 개발자 경력을 갖고있다

지금은 SI를 떠나 교육을 주로 두고 있는 듯하다.

우아한형제의 우아한 테크코스 과정을 만드신분 같다.

원글 : (https://brunch.co.kr/@javajigi/4)

=========================

좋은 소프트웨어(이하 SW) 개발자를 키우고 싶다면

좋은 SW교육자를 키워라. 라는 글을 썼다.

이 글은 정부에 전하고 싶은 메시지였다. 이런 글을

쓰고 많은 사람들의 공감을 받는다고 세상이 쉽게

변하지 않는다는 것을 안다. 특히 정부는 쉽게 바뀌지 않는다.

변화는 SW개발자인 우리가 만들어야 한다. 더 빠른 변화를 만들어 가려면

SW 개발자인 우리가 행동해야 한다.

나는 2011년에도 후배 개발자에게 비슷한 글을 썼다.

OKKY에 올라온 "옛날 선배 개발자분들 정말 짜증 납니다." 라는 글에대한

답변으로 쓴 후배 개발자에게 -2011 글을 소환해봤다.

SW 개발 문화는 2011년과 큰 틀에서 달라진 점이 많지 않은 듯하다.

하지만 좀 더 세분화해서 살펴보면 서서히 변화가 생기고 있다.

이런 변화에 집중해 몇 가지 이야기를 하고 싶어 글을 쓴다.

SI 업계에서 일하는 개발자라면 SI 업계를 떠나라.

지금 SI 업계에서 일하고 있는가? SI 업계를 떠날 수 있는 방법을 찾아라. 특히 2, 3년 차의

주니어라면 더더욱 수단과 방법을 가리지 말고 다른 업계로 떠날 방법을 찾아라. 너무 가혹한가?

SI 업계에 얼마나 많은 개발자들이 일하고 있는데 함부로 그렇게 말할 수 있냐? 라고

이야기할 수 있다. 알고있다. 욕을먹는 한이 있더라도 나의 대답은 같다. 하루라도 빨리 떠나라.

지금까지 우리는 정부와 갑/을 회사들에게 변화할 수 있는 시간을 많이 줬다.

하지만 내가 SW개발자의 길을 걷기 시작해 20년이 지나도록 SI업계는 크게 변화하지 않고있다.

아니 오히려 후퇴하고있다. 역량 있는 개발자가 피하는 곳이 되면서 SI프로젝트의 품질은

점점 더 떨어지고 있다. 특히 우하한형제들, 네이버, 카카오와 같은 일반 사용자용 소프트웨어 회사들과의

기술 격차는 점점 더 벌어지고 있다.

개발자에 대한 처우는 어떠한가? 나아지고 있는가? 일반 사용자용 소프트웨어

회사들의 개발자에 대한 인식과 처우는 점점 더 좋아지고 있다. 반면 SI업계의 개발자에 대한 인식과

처우는 10년 전에 비해 나아진 점이 거의 없다. SI 업계에서 5년, 10년을 일했을 때 미래의

비전이 보이는가? SI 업계에서 5년, 10년을 일한 후 일봔 사용자용 소프트웨어

회사로 이직하려고 도전해 봐라. 쉽지 않다. 두 분야의 기술 격차, 협업하는 개발 문화, SW를 바라보는

인식 등에서 엄청난 차이가 발생한다. 지금도 많은 SI 개발자가 일반 사용자용 소프트웨어

회사로 도전하지만 실패하는 이유가 이런 차이 때문에 발생한다.

피치 못한 사정 떄문에 SI업계에서 일하고 있다면 5년 이상은 너무 길다.

5년이 되기 전에 뼈를 깎는 노력을 통해서라도 일반 사용자용 소프트웨어

회사로 이직해서. 정부, 수많은 갑과 을 들은 아직도 자신들이 무슨 잘못을 하고

있는지 모른다. 과거보다 좋은 개발자가 없다고 불만만 제기할 뿐 개발자의 역량을 키우고

개발 문화를 개선하기 위한 노력은 여전히 부족하다. 무엇을 주저하는가?

개발자로서 성장할 수 있고, 더 좋은 처우가 보장되어 있는 곳으로 떠나라.

우리가 빨리 더나야 저들도 변한다. 우리가 행동하지 않는 한 저들은 변하지 않을 것이다.

취업 준비 중이라면 성장할 수 있는 스타트업도 고려해라.

취업 준비생이라면 복지 좋고, 안정적이고, 연봉도 높은 회사를 찾는 것은 당연하다.

하지만 이런 좋은 조건의 회사가 입사하는 것이 쉽지않다. 이런 회사에

입사하기 쉽지 않은 이유는 채용하는 개발자의 수가 적기 때문이 아니라 요구하는

역량 수준이 너무 높기 때문이다. 이 회사들이 요구하는 수준의 역량을 갖춘 신입 개발자는 거의 없다.

신입 개발자에게 협력 능력까지 요구하는 것은 너무 과한 것 아닌가? 자신들은

투자하지 않고 바로 현업에 투입해 일을 시키겠다는 도둑놈 심보가 따로없다.

하지만 어쩌겠는가? 현실이 그런 것을.....

SW 개발자로 성장하는데 있어 좋은 조건의 회사로 취업하는 것도 좋은 시작이지만 작은

스타트업에서 시작하는 것도 좋은 방법이다. 단, 조건이 있다. 내가 보고 배울 수 있는

선배 개발자들이 있는 곳이어야한다. 체계적인 교육 과정이 없어도 괜찮다.

일하면서 눈동냥으로라도 배울 수 있는 선배 개발자가 최소 3, 4명 이상은 있는 스타트업

이어야 한다. 면접 과정에서 반드시 확인해야 한다. 자신과 같은 분야에

몇명의 선배 개발자가 있는지, 어떤 방식으로 일하고 있는지는 내가

성정하기 위해 정말 중요한 요소인 만큼 반드시 확인해야 한다.

스타트업 힘들다. 맞다. 힘들다. 힘든만큼 배우는 것도 많다. 단, 자신이 배우고자 하는

의지가 있고, 성장하고 싶은 의지가 있을때 배움이 크다. 자신이 주도적으로 문제를

해결하고, 더 많은 분야에 기여할수록 더 많은것을 배우고 성장할 수 있다. 누군가 체계적으로

가르쳐주지 않는다. 나 스스로 학습하고, 성장하고, 해결책을 찾아야 한다.

이렇게 선택한 스타트업의 개발 문화가 좋고, 성장 속도로 빠르다면 회사의

성장속도에 맞춰 같이 성장하면 된다. 단, 그렇지 않은 상황이라면 2, 3년 후에 이직하면 된다.

내가 노력한 만큼 성장해 있을테니까. 인생에 길이 하나만 있는 것은 아니지 않는가?

좋은 조건을 가진 회사만 집착하지 말고 내가 성장할 수 있는 곳이라면 도전해보자.

꾸준히 학습할 수 있는 시간을 만들어라.

상당수 개발자들은 이미 알고 있다. 현재 일하고 있는 곳에서 비전을 찾을 수 없으며,

무엇인가 잘못되었다는 것을 알고 있다. 악순환의 고리에 빠져 있따는 것도 알고 있다.

하지만 이런 악순환의 고리를 어떻게 풀어가야 할 것인지를 알 방법이 없다.

현실은 너무 바빠 새로운 도전을 할 수 있는 마음의 여유가 없다. "어떻게 되겠지?" 라는

막연한 희망을 품고 1년, 2년의 시간을 보낸다. 변화를 이야기하는 개발자도 주변에 없다.

자신이 지금 이런 상황이라면 어떻게 하겠는가? 어떻게 하는 것이 변화를 만들어 낼 수 있을까?

변화를 만들기 위해 가장먼저 바꿔야 할 부분은 문제를 바라보는 시각이다.

혹시라도 문제의 원인을 사회 시스템의 문제, 갑/을/병/정으로 이어지는 하청 구조의 문제,

선배 개발자의 문제와 같이 외부에서 찾을 수 있다. 맞다. 본진적인 문제의 원인은

이런 구조적인 문제 때문에 발생한다. 하지만 문제의 구체적인 해결책을 이런 구조적인 부분에서

찾고, 해결되기를 기대하는 것은 너무나도 먼 미래의 이야기이며, 내 영향력 하에서 바꾸기도

힘들다. 이런 구조적인 문제는 장지적으로 해결되기를 기대하면서 일단 나의 영향력 하에서

바꿀 수 있는 것부터 바꾸려는 시도를 해야한다.

나의 영향력 범위 내에서 바꿀 수 있는 시작은 나의 역량을 키우는 것이다. 바쁜 회사 생활이지만

내가 목표로 하는 역량을 가진 개발자가 되기 위해 최소 1년, 2년은 꾸준히 학습에 집중 투자해야 한다.

내가 교육 과정을 시작할 때 다음 몇가지 조정을 통해 시간을 확보하라고 가이드한다.

시간확보(이건좀.......;;)

1)애인과의 만남 시간 조정. 예로 2주에 1회

2)친구들과의 관계 끊기

3)TV보지 않기, 게임하지 않기

우선순위 조정

1)프로그래밍 관련 책만 읽기

2)야근하면서 장난감 프로젝트하기

나는 업계에서 인정할 만한 수준의 개발자가 되려면 최소1, 2년의 프로그래밍

관련 학습에 집중 투자해야 한다고 생각한다. 컴퓨터 공학과를 전공했다고

하더라도 현장에서 필요한 역량이 다르기 때문에 이런 시간 투자는 반드시

필요하다. 최소 1, 2년이다. 상황에 따라 더 길어질 수도있다. OKKY 커뮤니티에서 평생을

저 기준으로 살라고 이야기했다고 해서 오해를 산 경우도 있다.

평생을 어떻게 저런 기준을 가지고 살 수 있겠는가? 우리가 전문가라고 인정을

받으려면 최소한의 시간이라도 투자해야한다. 1, 2년 집중 투자한다면 점차 학습할 내용도 적어지고

경험도 쌓이기 때문에 더 적은 시간을 투자할 수 있다.

주변을 정리하고 우선순위를 조정해 꾸준히 프로그래밍 학습과 연습에 투자할 수 있는 시간을

확보하자. 내가 변화를 만들 수 있는 시작점이 될 수 있다.

지금 일하는 곳에서 변화를 만드는 시도를 해라.

나의 영향력 범위 내에서 바꿀 수 있는 좋은 해결책은 나의 역량을 키워 내가 원하는 다른 곳으로

이직하는 것이다. SI 개발자라면 역량을 키워 일반 사용자용 서비스를 개발하는 회사로 이직하거나,

내 몸을 갈아 넣는 느낌을 받는 스타트업이라면 성장할 수 있는 다른 곳으로 이직하면 된다.

무작정 이직만을 생각하라는 것이 아니다. 현재 내가 일하는 곳에서 나의 영향력을 발휘해 변경할 수 있는

부분을 바꾸기 위한 노력은 게을리 하지 않았으면 한다. 이 같은 시도는 아무리 열악한 곳이라도

나를 성장시킬 수 있는 계기가 되며, 이런 성장으로 인해 내가 원하는 곳으로의 이직을 가능하게 할 것이다.

우리가 괜찮다고 생각하는 회사들이 원하는 인재는 주어진 환경에서 시키는 일만 잘하는 개발자가

아니라 자기 주도적으로 환경을 개선하고 문제를 해결하는 개발자이기 때문이다. 어쩌면 해결해야 할 문제가

많은 SI와 작은 스타트업이 이런 역량을 경험할 수 있는 좋은 곳이 될 수도 있다.

"개발 문화가 좋은 곳에서 일하고 싶다." 라고 많은 개발자들이 이야기 한다. 하지만 어느 곳이나

몇 개월이 지나 적응이 되면 문제점과 불합리함이 보인다. 어떻게 하겠는가? 또 다시 이직을 준비해야 하나?

내가 생각하는 이상적인 개발문화를 가진 조직은 없다. 자신이 지향하는 이상적인 개발문화를 만들기

위해 도전할 수 있는 기회가 있는 조직을 찾아야 한다. 그런 조직이 아니라면 지속적으로

개발문화를 개선해 나갈 수 있는 조직으로 변화 하는데 기여해야 한다. 이런 시도는

결국 나 자신을 성장하게 만들고 나의 영향력은 점점 더 커질 수 있다.

변화는 큰 변화가 아니어도 괜찮다. 현재 자신의 위치에서 영향력을 미쳐 바꿀 수 있는 부분부터 바꾸면된다.

처음부터 너무 큰 변화를 시도하다 포기하고 실망하는 것보다 작은 변화부터 하나씩

시도해보면서 성공하는 경험을 만드는 것이 더 중요하다. 이런 성공 경험은 변화를 만들어 가는 것에 대한

자신감과 용기를 준다. 실패해도 괜찮다. 결과적으로 가장 많은 것을 배우고 성장하는 것은

나 자신이기 때문이다. 영향력이 적을 때는 적은 만큼의 변화부터 시작해 경력이 쌓이면서

영향력이 커지면 더 큰 변화를 만들어 가면 된다. 경력이 쌓이고, 리더가 된 후에 변화를 만들어

가야지 라고 생각할 수 있지만 막상 영향력을 발휘하는 위치가 되면 쉽지 않다. 변화를 만들어 가는 것 또한

연습이 필요하기 때문이다. 경력이 적더라도 자신이 주도적으로 개선해 나갈 수 있는 부분은 찾아

조금씩 바꿔 나가는 연습을 해보자.

클린코드 구현하는 연습을 해라.

우리는 프로그래밍을 배우는 시작 단계에서 클린코드의 중요성에 대해 배울 수 있는

기회가 적다. 컴퓨터 공학과를 졸업해 취업 준비 중이거나, 국비지원 과정을 통해

취업 준비 중인 친구들을 만나보면 백이면 백 구현자체에만 집중하지 코드 품질을

이야기 하는 친구는 없다. 하지만 우리가 흔히 좋은 회사라 이야기하는 곳은 클린코드를

구현하는 역량을 가진 친구들을 원한다. 이런 경향은 점점 더 강해지고 있다.

지금까지 우리는 어떻게 하면 빨리 만들 수 있을까에 집중해 왔다. 빨리 구현하는 개발자를

인정해 준 것 또한 사실이다. 특히 SI는 빨리 구현하는 것에 집중하는 경향이 좀 더 강하다.

계약 관계의 구조상 프로젝트 개발과 유지보수를 분리하고 있는데, 이런 분리는 개발 단계에서

빨리 구현하는 것에만 집중할 수 밖에 없는 상황을 만들고 있다. SI 환경에서 인정받는 대부분의

개발자를 보면 결과물을 빨리 구현하는 경향이 강하다. SI 개발자가 일반 사용자용 서비스를

개발하는 회사로 이직하려 할 때 가장 큰 걸림돌이 클린 코드를 구현하는 역량이다.

일반 사용자용 서비스를 개발하는 회사는 빨리 구현하는 것보다 읽기 좋고, 유지보수 하기 좋은

클린코드를 구현하는 역량을 더 중요하게 생각한다. 이런 불일치가 인력 수급의

불일치를 만드는 주요 원인 중의 하나이다.

자신이 생각하는 좀 더 좋은 회사로 이직을 원한다면 클린코드를 구현하는 연습에

시간을 투자해라. 클린코드를 구현하는 연습은 참 쉽지 않은 연습이다. Computer Science 지식과 같이

일정 시간을 투자해 꾸준히 학습하면 알 수 있는 그런 영역이 아니다. 책을 통해

연습할 수 있는 영역이 아니다. 꾸준한 연습을 통해 조금씩 향상해 나갈 수밖에 없다.

나는 회사 프로젝트를 통해 클린코드를 연습하는 것이 아니다 자신만의

장난감 프로젝트를 통해 다양한 시도를 하면서 연습하는 것이 가장 좋은 연습이라 생각한다.

오프라인 커뮤니티에 참여하자.

주변에 조언을 구하고, 코칭을 해줄 선배 개발자가 있다면 정말 운이 좋은 경우다.

주변에 같이 일하는 선배, 동료 개발자가 없거나, 선배, 동료 개발자가 있어도 정치적인 상황

때문에 조언을 구하지 못하는 경우도 다반사다. 이 같은 문제를 해결하는 좋은 방법 중의 하나는

오프라인 커뮤니티 활동에 참여하는 것이다. 커뮤니티는 정치적인 목적이 없는 상태에서

소통할 수 있기 때문에 자신의 고민을 마음 터놓고 이야기 할 수 있고, 도전하고 싶은 일 들을

마음껏 도전하고 시도해 볼 수 있다. 내가 리더십 능력이 부족해서 리더십 능력을 키워보고 싶다면

커뮤니티에서 도전해 볼 수 있다. 커뮤니티를 리딩하면서 발생하는 다양한 이슈를 해결해 볼 수있다.

자발적으로 하겠다는 사람을 아무도 말리지 않는다. 내가 많은 사람 앞에서 발표하는 것이

부담스럽다면 소규모인 스터디 내에서 발표 연습을 할 수 있다. 나는 커뮤니티 속에서 내가 꿈꾸고,

생각하는 다양한 것들을 시도하고 실패하고, 성공하면서 여기까지 왔다. 커뮤니티 내에서의

도전은 반드시 완벽하지 않아도 된다. 약간 부족하더라도 새로운 도전을 기꺼이 받아들이고,

성장할 수 있는 기회를 주는 곳이 커뮤니티이다.

나는 이런 도전을 할 수 있는 기회가 있어 커뮤니티를 한다. 커뮤니티에 참여하고 싶다.

자신의 관심사와 일치하는 커뮤니티가 있다면 참여하면 된다. 그런데

자신의 관심사, 성향과 맞는 커뮤니티가 많지 않다는 것이 문제이다. 자신이

찾는 커뮤니티가 없다면 내가 직접 만들고 운영해 보자. 생각하는 것만큼 어렵지 않다.

힘든 순간도 있지만 노력에 비해 얻는 것이 훨씬 더 많기 때문에 적극 추천하고 싶다.

"목마른 사람이 우물판다."는 속담이 있듯이 성장하고 싶은 간절함이 있다면

누군가 만든 커뮤니티를 찾고 기다리기보다 내가 직접 만들어보자. 커뮤니티를

직접 만들고 운영할 계획이라면 시작부터 너무 거창한 목표, 준비를 하지 않아도 된다.

오히려 빈틈이 있을 경우 다른 구성원이 빈틈을 채워가면서 커뮤니티에 대한 주인 의식을

가지게 된다. 일단 용기를 내어 시작하는 것이 중요하다. 부족한 부분은 커뮤니티를 운영하면서

지속적으로 개선하면 된다.

내가 같이 일하고 싶은 개발자는...

교육자의 길을 걷기 시작한 지 벌써 6년이 되었다. 현장을 떠난 지 오래되어 현장의 감이

떨어진 만큼 같이 일하고 싶은 개발자의 상을 제시한다고 의미가 있을지 모르겠다.

하지만 내가 다시 회사의 팀장으로 돌아가 같이 일하고 싶은 개발자를 채용한다는 생각으로 써 본다.

-소통, 협업 능력이 뛰어나지 않아도 괜찮다. 자신의 부족한 부분을 인식하고 개선하려는

의지를 가진 친구이면 좋겠다. 문제의 원인을 외부에서 찾는 것이 아니라 자신으로부터

해결책을 찾아 나가는 모습을 보이면 좋겠다.

-기술적인 역량이 부족해도 괜찮다. 프로그래밍 자체를 즐기고, 전문가로서 성장하기 위해 노력하는

자세를 가진 친구면 좋겠다.

-중요한 문제를 해결하지 않아도 괜찮다. 프로젝트에 항상 중요한 일만 있는 것은 아니다. 우리가

소홀하게 생각할 수 있는 부분의 문제점을 찾아 해결하는데도 관심을 가지는 친구면 좋겠다.

특히 업무 영역이 명확하지 않은 부분에도 서비스의 성공을 위해 관심을 가지고

적극적으로 참여하는 친구면 좋겠다.

-삶에 약간의 여유와 유머가 있는 자존감이 높은 친구면 좋겠다.

너무 욕심이 많은가? 맞다. 내가 사람 욕심이 좀 많다.

요구 조건이 너무 많다면 "혼돈의 상태에서 질서를 만들기 위해 주도적으로 문제를

해결하는 자세를 가진 친구" 면 좋겠다. 역시나 나는 욕심이 많나보다.

자신이 꿈꾸는 삶이 있는가?

아무도 나의 꿈을 대신 실현해 주지 않는다.

내가 행동해야 한다.

자신의 영향 내에서 변화시킬 수 있는 작은 것부터 시작해보자.

오라클에서 계정 생성, 권한, 테이블 덤프하기.

Note&pen — Sun, 31 Mar 2019 14:31:55 +0900

cmd 에서 오라클 계정을 생성하고

권한을 주고 테이블을 덤프하는 명령어이다.

sqlplus "/as sysdba" -> cmd에서 sqlplus로 오라클 접속

create user abc identified by 1234;

->abc라는 계정을 생성하고 비밀번호는 1234로 설정한것이다.

alter user abc account unlock;

-> abc계정의 lock을 푼다.

grant connect, resource, dba to abc;

-> abc계정에 db작업에 필요한 모든 작업을 준것이다.

grant create session to abc;

-> 세션생성 권한

grant create table to abc;

-> abc 계정에 테이블 생성권한 주기

grant drop any table to abc;

-> abc 계정에 테이블 drop 권한 주기.

테이블 덤프(복사)

cmd 에서 exp userid=abc/1234 file='C:\~~~\파일명.dmp'

abc 계정의 모든 테이블,데이터를 저장하고싶은 경로에

저장한다 그럼 파일명.dmp 의 형태로 덤프파일이 생성된다.

위에서 익스포트한 dmp 파일을 다시 임포트하여

사용할 수 있다.

imp userid=abc/1234 file='C:\dmp파일경로\파일명.dmp' full=y

file 에는 저장되어있는 dmp 파일의 경로를 써준다.

학벌이 낮아도 일 잘하는 사람일수도? - 문제해결능력은 어디서 오는가?

Note&pen — Sun, 24 Mar 2019 13:53:40 +0900

요즘 블로그에 신경을 못쓰고 쓸만한 소재를 못찾아서

포스팅을 계속 미루고 있었는데

이러다가 블로그에서 손을 뗄거같다는 생각이들어

오늘은 무조건 글 하나를 포스팅해야겠단 생각이 들었다.

한 달 동안 포스팅이 없어서 쓸만한 글 을 찾던중

okky에서 좋은 글 하나를 발견했다.

원글 : (https://infiniteinformation.tistory.com/73)

=========================

학벌이 낮아도 일 잘하는 사람일 수 있다?

1.문제해결 능력의 중요성

-자본주의는 크게 3가지 자본으로 구성된다.

물적 자본, 지적 자본, 인적 자본 이다.

그 중에서 인적 자본에서 늘 교육 수준을 이야기 한다.

일반적으로 인재라고 생각하면 대체로 학력이 좋은 사람을 꼽는다.

그렇다면 교육 수준이 높고 좋은 학력을 가질수록 일을 잘할까?

확실한것은 학력이 좋다고 해서 업무능력이

좋다고 볼 수는 없다. 하지만

업무 능력이 좋을 가능성은 높다고 할 수 있다.

그러므로 학력과 업무능력은 인과관계라고 하기보다

상관관계라고 하는것이 적절하다.

2.무엇이 인력의 수준을 결정할까?

-살다보면 모르는것 투성이다. 12년 정규교육에 대학을

나와도 다 받아도 모르는 것이 많다.

심지어 간단한 물건을 사는데도 몰라서 리뷰를 검색한다.

해외에 가려면 일이 더 커진다.

비즈니스에서도 마찬가지다.

뭔가 좀 해보려고 하면 생각지도 못한 것이

불쑥 튀어나온다. 이쯤 되면

우리 인생에서 되는게 없는 것이 정상인 것 같다.

이 세상 만물은 현재 지금 상태가 최적화된 값이기 때문에

이를 변화시키는 것은 자연의 최적값을 거스르는 행위다.

그러므로 새로운 최적값을 찾아내는 사람이 승리의

달콤함을 맛볼 수 있다. 우리 삶은 이렇게 문제가 산더미고

이 문제를 해결하는 능력이 중요하다.

3.월급 = 문제해결 능력

그래서 인력의 수준은 문제해결 능력이라고 봐도 무방하다.

높은 직급에 있는 사람은 본인이 직접 문제해결 방법을

생각해내고 실행할 수 있다. 하지만 신입사원 같은

낮은 직급에 있는 사람은 상사가 알려준 문제해결 법대로

실행하기도 벅차다. 마치 상사는 미적분을 풀고 있을때 신입사원은

이제 겨우 구구단을 깨친 수준이니 방정식 수준의 문제만

나오면 문제해결은 커녕 무엇이 문제인지도 모른다.

4.문제해결 능력의 근간 "학습능력"

그렇다면 문제해결 능력의 핵심은 무엇일까?

한 문제 풀면 새로운 문제가 또 나온다.

이럴때 필요한 것이 학습능력이다. 학습능력이란

새로운 것을 배워서 내것을 만드는 능력을 의미한다.

특히나 지식의 유통기한이 짧아지는

21세기에 중요한 능력으로 꼽힌다.

1)첫째, 아는것이 많은게 유리하다.

영어공부를 막 시작하면 일단 알파벳부터 배우고

단어를 외운다. 그리고 그 단어들이

문장을 구성하고, 그 문장은 문법으로 구성된다.

문법을 배우려면 일단 알파벳부터 알아야된다는 뜻이다.

이는 아는것이 많으면 새로운 것을 배우기 쉽다는 뜻이다.

2)둘째로 경험이 풍부해야한다.

일단 배운 것을 실제로 써보면 생각처럼 안되는게 부지기수다.

이론과 실전은 다르다. 그래서 아는 것을 여러번 반복하다보면

시행착오가 생기고 평균값을 알게된다.

이것은 노하우다. 노하우를 획득하면서 문제풀이를 하기위한

나만 알고 있는 공식이 생긴다.

3)마지막으로 태도가 요구된다.

배우는 것은 인내가 필요하다. 대부분의 사람들은 공부하는 것을

싫어한다. 그 싫어하는 것을 하면서 인내력이 향상된다.

또한 사고가 유연해야된다. 사고가 꽉 막혀 자신만의 정의로

가득차면 새로운 것이 들어올 틈이 없다. 그리고 이 모든것은

스스로 할 줄 알아야 된다.

이 세 가지 요소가 학습능력을 구성한다.

에어비앤비 창립자 브라이언 체스키는 독서광으로 유명하다.

학습하는 기계로도 불리는 체스키는 CEO임에도

지금도 수백권의 책을 읽으며 멘토를 찾아다닌다.

그리고 새롭게 배운 것을 정리해 매주 일요일 밤마다

전 직원에게 이메일을 보낸다. 이것이 그의 성공 비결로 불린다.

5.학력지상주의는 효율의 단면

그렇다면 학습능력이 좋은 사람을 어떻게 찾을까?

이론적으로 모든 사람을 직접 찾아 일일이 테스트해 보면 된다.

하지만 이 과정은 효율성이 없다. 왜냐면 비즈니스의 생명은

적은 자원으로 산출량을 극대화하는 것이기 때문이다.

이럴 때 기가 막힌 방법이 있으니 바로 학력으로 필터링 해버리는 것이다.

학력을 기준으로 필터링하는 이유로 일단 학력이 좋으면

아는것이 많을 가능성이 높다. 그리고 배우는 과정에서

인내를 경험해봤을 가능성이 높다. 그 외에 다양한

사람들과 교류하면서 인적 자본을 형성했을 가능성이 높다.

어떤 사람은 고졸과 대졸의 임금이 다른 이유로 위의 이야기를 한다.

모르는 것이 있으면 선배나 후배한테 물어가면서 해결해 나갈 수 있는 것이

학연의 힘이라는 것이다.

6.학력은 어디까지나 평균값일 뿐

하지만 학력은 좋을지라도 학습능력은 떨어지는 사람도 많다 못해 흔하다.

실제로 주변에 주입식 교육코스 덕에 시험은 곧, 잘보았던 사람이 있다.

학력만 봤을때 부족함이 없다. 시험 기간이 되면 엄청난 암기력으로

교재와 족보를 달달 외워버리니 언제나 성적은 좋다.

하지만 스스로 무언가를 새로 배우는 것 자체를 싫어했다.

비즈니스 필드는 학교랑은 완전 다른 데다가 자고 일어나면

새로운 이슈가 발생하니 본인의 약적이 점점 눈덩이 처럼 커져 버렸다.

학습능력이 없다보니 시간이 갈수록 점점 아는게 없어져 갔다.

누군가 교육을 하려고 해도 기초가 부족하니 새로운 것을 받아들이는

것이 어려워져만 갔다.

결국 아무 생각이 없는 수동적인 업무만 반복하는 무능한 일꾼이

되는 악순환에 빠지게 되었다. 이런 케이스의 경우 회사가

연공서열을 채택하고 있다면 조만간 앉아서 시간만 보내는

무능한 상사로 등극하게 된다.

7.인간관계가 아니라 상관관계

위의 이야기는 학력이라는 변수가 업무능력이라는 결과값으로 연결되는

인과관계가 아님을 보여준다. 인과관계가 아니라

상관관계이므로 학력이 좋다고 일을 잘 한다는 보장도 없고

학력이 낮자고 일을 못 한다는 보장도 없다. 그러므로

항상 색안경을 벗고 열린 마음가짐을 갖는 것이 중요하다.

톰캣 lib 실행 순서 (4)

Note&pen — Sun, 24 Feb 2019 16:26:44 +0900

이전 포스팅에서 톰캣의 lib 실행순서를

직접 확인했다. 첫 번째로

.class 파일을 읽고

두 번째로 WEB-INF/lib

세 번째로 tomcat/lib 를 읽었다.

사실 이 lib 실행순서는 톰캣 문서에 적혀 있다.

나는 톰캣7을 사용했으니 톰캣7문서를 읽어보겠다.

톰캣문서 : (https://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html)

톰캣은 클래스나 리소스를 로딩할때 아래의 순서로

로딩한다고 적혀있다. 이전 포스팅에서 테스트했던 순서이다.

<Loader delegate="true"/>를 사용하면

순서가 바뀌는데 한번 사용해보자.

먼저 위에서 바뀌는 실행순서를 보면

기존에는 WEB-INF/lib 가 먼저 로딩됬지만

tomcat/lib 가 먼저 로딩되는것으로 순서가 바뀌게 된다.

WEB-INF/lib에는 first.jar를 넣고

tomcat/lib 에는 second.jar를 넣고 준비를해보자.

이제 <Loader delegate="true"/>를 사용해보자.

아래의 경로에서 context.xml을 수정하면된다.

<Context> 안에 <Loader delegate="true"/>를 추가해주면 된다.

다음 실행을 해보면 second getMessage~~!!가 출력된다.

<Loader delegate="true"/>를 사용하지 않았을때는

WEB-INF/lib 가 먼저 로딩되어 first getMessage~~!! 가

출력되었지만 <Loader delegate="true"/>를 사용하여

실행순서가 바뀌어 tomcat/lib가 먼저 로딩되어

second getMessage~~!!가 출력된것이다.

마지막으로 톰캣 문서에있는 endorsed 에 대해 알아보자.

대충 읽어보니 자바9까지 지원되는것 같다

endorsed 폴더를 생성해 lib를 넣으면 가장 먼저

로딩된다고 설명되어있는것 같다.

아래경로에 endorsed 폴더를 생성해주고

third.jar 파일을 넣어주자

그리고 WEB-INF/lib 에 first.jar

tomcat/lib 에 second.jar를 같이 넣어주도록 하자.

그리고 실행시켜보면 third getMessage~~!!가 출력되게된다.

classes 폴더에 .class를 넣어줘도 endorsed폴더의 lib가

가장 먼저 로딩되게된다.

톰캣 lib 실행 순서 (3)

Note&pen — Sun, 24 Feb 2019 16:04:26 +0900

이번엔 명령프롬프트 창에서

직접 톰캣을 구동해 직접 lib 를 읽어보는

테스트를 해보자.

먼저 이전 포스팅처럼 getMessage.java 클래스를 만들고

getMessage~~!!를 출력하게끔 만들었다.

이제 jsp 에서 한번 실행한 후

.class 파일을 바탕화면으로 복사해둔다.

.class 파일은 생성경로를 따로 설정하지 않았으면

아래처럼 Navigator 에서 classes 경로에서 가져올 수 있다.

이제 아래처럼 first getMessage~~!!를 출력할 jar 파일을

만들어준다. first 부터 thrid 까지 총 3개를 만들어준다.

getMessage.class 파일과 3개의 jar파일, 실행할 jsp파일을

생성해 모아두면 된다 jsp파일은 이전 포스팅에서 사용하던것과

같은 jsp 파일이다.

이제 위에서 생성한 5가지 파일들을 사용해보자

third.jar 는 아직 사용하지 않을것이다.

먼저 아래 경로에 들어가 jsp파일을 넣어준다.

다음 아래경로에 들어가 .class 파일을 넣어준다

만약 classes 폴더가 없으면 만들어준다.

test 폴더는 이클립스에서 getMessage.java 클래스를

test 패키지안에 생성 후, 실행했기 때문에

똑같이 test 폴더를 생성하고 그안에 .class 파일을 넣어줬다.

다음 WEB-INF/lib 경로에 first.jar 파일을 넣어준다.

tomcat/lib 에는 second.jar 파일을 넣어준다.

이제 직접 톰캣에서 서버를 구동시켜 jsp를 실행시켜보자.

우린 아래의 경로에있는 startup 으로 서버를 올리고

shutdown으로 서버를 내릴것이다.

명령 프롬프트 창에서 cd.. 를 사용해 기본으로

잡혀져있는 실행경로에서 나온다.

다음 cd를 이용해 톰캣/bin 경로까지 가야한다.

이제 startup을 실행하여 서버를 올리고 jsp파일을 실행시켜보자.

서버를 올리게되면 새로운 Tomcat 창이 열리며 서버가 올라가는걸

확인할 수 있다. 이제 서버는 올라갔으니

인터넷창을 하나 켜서 jsp 실행을 해보자.

getMessage~~!! 가 출력되었다.

이것은 .class 파일 안에있는 문자이다.

즉, 톰캣은 classes 폴더안에있는 .class 를 가장먼저

읽고있다는 것이다. 그럼 이제 shutdown을 실행해

서버를 내린다음 classes 안에있는 .class 파일을 삭제해보자.

.class를 삭제했다면 다시 서버를 올리고 실행시켜보자.

그럼 아래와같이 first getMessage~~!! 가 출력된다.

WEB-INF/lib 에있는 first.jar 파일을 읽고있다는 것이다.

이제 WEB-INF/lib 에있는 first.jar 을 삭제하고 실행시켜보자.

second getMessage~~!! 가 출력되었다

이제는 tomcat/lib 에있는 second.jar를 읽고있다는 것이다.

즉 tomcat은 lib를 실행시킬때

classes에있는 .class 파일을 제일 처음 읽고

두 번째는 WEB-INF/lib

세 번째는 tomcat/lib 를 읽고 있다는것을 확인할 수 있다.

다음 포스팅에서 톰캣문서를 보며 몇가지 더

확인을 해보자.

톰캣 lib 실행 순서 (2)

Note&pen — Sun, 24 Feb 2019 14:45:59 +0900

이제 저번 포스팅에서 만든

getMessage.java 클래스를 jar파일로

만들어 lib 에 jar파일을 넣고 실행을 해보자

우선 아래처럼 java 파일을 선택후 Export 해준다.

다음 JAR file을 선택해 Next해준다.

JAR file이 없다면

위 Select an export destination 에서

검색을 해준다.

다음 아래처럼 해당 패키지를 클릭하면

오른쪽에 패키지 안에 존재하는

java파일들이 보이며

원하는 java파일을 선택해 Finish를 눌러준다

JAR 파일이 생성될 경로도 정해준다.

아래처럼 jar파일이 생성된것을 볼 수 있다.

이제 생성한 jar파일을 아래처럼

이클립스의 WEB-INF/lib 경로에 넣어준다.

다음 test 패키지 안에있는 getMessage.java 파일을

삭제해준다. 이제 실행을 해보면

jar파일을 읽고 "getMessage!!" 를 출력한다.

이제 WEB-INF/lib 에 있는 jar파일을 삭제하고

아래처럼 아파치톰캣이 설치되어있는

경로에 들어가 jar파일을 넣어준다.

다음 jsp파일을 실행시켜보면 tomcat/lib 경로에있는

jar파일을 읽어 getMessage!!를 출력하게 된다.

이렇게 WEB-INF/lib 경로와

tomcat/lib 경로에 직접 jar파일을 생성해 넣어보고

실행 시켜보았다.

이클립스에서는 아래처럼

Java Build Path에서

lib를 불러오는 순서를 바꿀수도 있다.

아래는 기본 설정으로

제일처음으로 읽어오는 경로는

맨처음 getMessage.java를 만들었던

src의 java파일이다.

원하는 폴더를 클릭후 오른쪽의 Up , Down으로

위 아래로 욺기며 변경할 수 있다.

다음 포스팅에서는 cmd로 직접 tomcat를 구동해

좀 더 확실하게 lib의 실행순서를 알아보자.

톰캣 lib 실행 순서 (1)

Note&pen — Sun, 24 Feb 2019 14:09:03 +0900

개발을할때 엄청난 양의 lib를 사용한다.

보통 프로젝트에서 우린 lib를 추가할때

WEB-INF/lib 경로에 라이브러리를 추가해 사용한다.

하지만 lib의 경로는 WEB-INF/lib 에만

있는게 아니다. 톰캣을 설치받은 경로 안에 lib도 있다.

이제 직접 lib에 jar파일을 생성해 넣어보고

위에서 말한 두 가지 경로의 lib를 사용해보자.

일단 아래처럼 테스트용 프로젝트를 생성하고

아래에 표시된 클래스와 jsp파일을 하나씩 만들자

test패키지를 하나 생성해주고 그 안에

getMessage 라는 class를 생성했다.

다음 아래처럼 getMessage!!라는 문자를 반환 하게 했다

jsp에서는 위에서 생성한 클래스를 사용하게했다.

다음 클래스가 잘 만들어졌는지

jsp를 실행시켜보자.

아래처럼 클래스안에 정의했던 문자가 나온다면

정상적으로 실행이 된 것이다.

남은 내용은 다음 포스팅에서 이어서 하겠다.

jQuery 공부 사이트

Note&pen — Thu, 14 Feb 2019 23:10:00 +0900

jQuery는 앞단에서 중요 핵심이라고 생각한다.

제이쿼리를 사용할때 타겟을 잘 잡아서

원하는 값을 java단으로 보내줘야 원할하게

데이터가 흐를수 있다. 제이쿼리는 책을보며 따라치는 것도

좋지만 미리 만들어져 있는 예제들을

수정해보며 타겟잡는 연습을 해보는것이 좋다고 생각한다.

아래 링크에 들어가

https://www.w3schools.com/jquery/jquery_traversing_descendants.asp

여러가지 제이쿼리 예제를 볼수 있으며

아래처럼 Try it Yourself 를 눌러

실행 예제를 볼수있다.

소스를 직접 수정해 Run을 눌러 실행도 해볼 수 있다.

input 태그 속성 ime-mode

Note&pen — Sat, 2 Feb 2019 22:37:29 +0900

로그인, 회원가입 등 화면에서 우리는

여러가지 값을 입력 할때가 많다.

로그인을할때 ID에 우린 영어를 입력하고

주소, 이름 등에는 한글을 입력한다.

입력 폼을 우린 jsp에서 input 태그를 사용하는데

input 태그를 사용해 기본적인 로그인, 회원가입 등에서

쓰이는 입력 폼을 만든다.

회원가입을 할때 이름, 주소에는 보통 한글을 입력한다.

근데 간혹 영어부터 입력되는 사이트들이 있다.

또한 로그인을 할때도 ID란에 우린 영어를 입력해야 하는데

한글이 써지는것을 보고 꼭 한/영 버튼을 누른다.

별거 아니지만 굉장히 귀찮다.

그래서 이를 방지하기 위해 input 태그에서 ime-mode라는 style 속성을

사용할 수 있다. ime-mode를 통해 한글 또는 영어를 기본값으로 넣어

입력되는 언어를 선택할 수있다.

사용법은 아래 이미지를 보면 바로 알 수 있다.

ime-mode를 사용하지 않으면 기본적으로

영어부터 입력이 된다.

하지만 ime-mode에 active 값을 주면

처음 입력시 한글부터 입력이 된다.

이름, 주소 란에는 ime-mode에 active값을주어

한글부터 입력이 될 수 있도록 하면

사용자 입장에서도 한/영 버튼을 누를 필요도없어

편할것이다. 사소한 것이지만 사용자를 위해 이러한 부분도

생각할줄 알아야 한다.

토비의 스프링 (8)

Note&pen — Tue, 29 Jan 2019 22:58:17 +0900

예외 처리

- 자바 개발자가 가장 신경 쓰기 귀찮아하는 것

정상적인 결과와 흐름을 보여주는 것도 힘든데

예외상황까지 처리해야 한다.

그래서 예외와 관련된 코드는 자주 엉망이 되거나

무성의하게 만들어지기 쉽다.

아래는 자바 기초를 배울때 만들어내는 JDBC 코드에서

흔히 볼 수 있다.

예외를 잡고 아무것도 하지 않는다.

예외 발생을 무시해버리고 정상적인

상황인 것처럼 다음 라인으로 넘어가겠다는

의도가 있는게 아니라면 절대 만들어서는

안되는 코드이다.

예외가 발생하면 catch로 잡아내는 것까지는 좋은데

아무것도 하지않고 넘어가는것은 정말 위험한 일이다.

왜냐하면 프로그램 실행 중에 어디선가

오류가 있어서 예외가 발생했는데 그것을 무시하고 계속

진행해버리기 때문이다.

최종적으로 오작동을 하거나 시스템 오류가 나서 운영자가

알아차렸을 때는 이미 늦었다.

아래의 두 방법도 마찬가지이다.

예외가 발생하면 화면에 출력해주는데

뭐가 문제일까? 개발 중에는 IDE 콘솔이나

서버 실행창에 이 메시지가 눈에 확 띄게 보이니

문제가 생겨도 금방 알아차리고 조취를 취할수 있다.

운영서버에 올라가면 콘솔 로그를 누군가가 계속 모니터링

하지 않는 한 이 예외느 코드는 폭탄으로 남아있다.

예외는 처리돼야한다.

예외를 처리할때는 반드시 지켜야 할 핵심 원칙은 한 가지다.

모든 예외는 적절하게 복구되든지 아니면 작업을 중단시키고

운영자 또는 개발자에게 분명하게 통보돼야 한다.

SQLException이 발생하는 이유는 SQL에 문법 오류가 있거나

DB에서 처리할 수 없을 정도로 데이터 액세스 로직에 심각한

버그가 있거나 서버가 죽거나 네트워크가 끊기는 등의

심각한 상황이 벌어졌기 때문이다

때문에 SQLException은 반드시 처리 되어야 하며

위처럼 메시지만 출력하는 것보단

아래와 같은 방법이 100배는 좋을 것이다.

물론 실전에서 저렇게 하라는것은 아니다.

예외를 무시하고 넘어가지 말라는 뜻이다.

토비의 스프링 (7)

Note&pen — Mon, 21 Jan 2019 22:53:57 +0900

스프링은 IoC/DI 를 이용해 객체지향 프로그래밍

언어의 근본과 가치를 개발자가 손쉽게 적용하고

사용할 수 있게 도와주는 기술이다.

동시에 스프링은 복잡한 엔터프라이즈 애플리케이션을

효과적으로 개발하기 위한 기술이다.

애플리케이션은 계속 변하고 복잡해져간다.

그 변화에 대응할 수 있는 것이

기술, 테스트이다.

스프링으로 개발을 하면서 테스트를 만들지 않는다면

이는 스프링이 지닌 가치의 절반을 포기한 셈이다.

테스트는 스프링을 학습하는데 있어 가장 효과적인 방법의 하나이다.

보통의 웹 프로그램에서 사용하는 DAO를

테스트하는 방법은 DAO를 만들고

서비스 계층, MVC 프레젠테이션 계층 까지

포함한 모든 입출력 기능을 만든후,

웹 화면을 띄어 폼을 열고 값을 입력하고

버튼클릭하여 값을 컨트롤러로 보내고 서비스 걸쳐서

DAO까지 갔다가 화면에 원하는 결과값이

출력 될 때까지 테스트를 한다.

위의 방법은 굉장히 비효율 적이다.

그래서 나온 것이 작은 단위 테스트

테스트는 가능하면 작은 단위로 쪼개서 집중해서

할 수 있어야 한다.

예를들어 메소드 하나씩 쪼개서 테스트하는것

단위 테스트 라고한다.

단위 테스트를 하는 이유는 개발자가 설계하고 만든

코드가 원래 의도한 대로 동작하는지를 개발자

스스로 빨리 확인받기 위해서다.

단위 테스트는 주로 개발자가 만든 코드를 스스로

확인하기 위해 사용하는데 그래서

이를 개발자 테스트 또는 프로그래머 테스트라고도 한다.

개발자의 삶 - 나이 들면 후회하는 37가지

Note&pen — Sat, 19 Jan 2019 15:30:39 +0900

인터넷을 돌아다니다 좋은 글을 발견해

내 블로그로 퍼왔다. 개발Tip 과는 거리가 멀고

인생과 관련이 있지만 내 블로그에 딱히

글을 쓸만한 카테고리가 없기에 개발Tip에 쓴다.

어떻게 생각해보면 개발과도 관련이 있다고 생각된다.

(인생 -> 내인생 -> 개발자 -> 개발)

원문 : (https://www.buzzfeed.com/mikespohr/37-things-youll-regret-when-youre-old)

글 쓴이는 BuzzFeed 의 부 편집장이자 블로거이고 세 아이의 아빠이다.

===============================

1.기회가 왔을 때 여행하지 않았던 것

당신이 나이들수록 여행하는 것은 점점 더 어려워진다.

특히 가족이 있다면 적어도 세 사람의 비용을 고려해야 한다.

2.외국어를 배우지 않았던 것

고등학교에서 3년간 외국어를 배웠지만 아무것도

기억기 안날때 자책하게 된다.

3.악연을 남겨두는 것

만일 당신이 악연을 그대로 두기로 선택했다면 당신은

그 부분에 대해 불행하기를 선택한 것과 같다.

악연을 벗어버리길 원한다면, 더 미리 움직여라.

4.선크림을 바르지 않았던 것

주름, 주근깨, 피부암은 선크림을 바르는 것으로 충분히

예방할 수 있다.

5.좋아하는 음악가를 만날 기회를 놓친 것

Nirvana가 다시 우리 도시에 온다면 꼭 만나도록 하자.

6.어떤일을 무서워한 것

되돌아보면서 생각할 것이다. 내가 뭘 무서워했지?

7.운동을 열심히 하지 않았던 것

너무 많은 사람들이 소파에서 대부분의 시간을 보내고 있다.

사십, 오십, 육십 세가 될 때마다 운동하지 않았던 걸 후회하게 될 것이다.

8.남성, 여성의 역할에 갇혀서 산 것

나이 든 사람이 "글쎄, 그때 그렇게 하지 말아야 했어." 라고

말하는 것만큼 슬픈 것은 없다.

9.끔찍하게 싫은 직업을 그만두지 않은 것.

물론 써야할 돈은 많다. 그러나, 상황을 개선할 계획이

없다면 매일같이 지옥에서 사는 것과 같다.

10.학교에서 더 열심히 공부하지 않은것.

물론, 학교 점수가 당신의 인생을 결정하지는 않는다.

그러나, 좀 더 열심히 공부하고 노력하는 것이 깔끔했다는 걸 깨닫게 될 것이다.

11.당신이 얼마나 아름다웠는지 모르는 것

우리가 보기에 너무 많은 사람들이 젊은 시절을 불행하게 보내고 있다.

그러나, 그 시절이 우리가 가장 아름다웠던 때이다.

12.사랑한다고 말하지 못한 것

나이가 들면, 사랑에 대한 대답을 바라지 않게 된다.

그냥, 얼마나 사랑하는지 표현하라.

13.부모님의 충고를 듣지 않은 것

어렸을 때는 그것을 듣고 싶지 않았을 것이다.

그러나, 정말 화가나는 것은 부모님이 인생에 관해 이야기한

대부분의 것이 진실이라는 것이다.

14.젊은 시절 자신에게만 몰두해 있었던 것

당신은 솔직히 그 사실을 부끄러워하게 될 것이다.

15.다른 사람이 어떻게 생각하는지 지나치게 신경쓴 것

당신이 지금 그렇게 신경쓰는 사람도 20년이 지나고 나면

하나도 신경쓰지 않게 될 것이다.

16.자신보다 다른사람의 꿈을 더 우선시 한 것

다른 사람의 꿈을 지원하는 것은 아름다운 일이다.

그러나, 그것이 당신이 전혀 빛나지 않는 것을 의미하는 거라면 전혀 아름답지 않다.

17.더 많이 움직이지 못한 것

노인들은, 벌떡 일어나서 움직이지 않고 앉아서 보냈던 긴 시간들에 대해 후회한다.

18.원한을 품고 사는것, 특히 당신이 사랑하는 사람들과 함께

화를 반복해서 내는 삶의 포인트는 무엇인가?

원한을 품는 것은 그 사람이 당신의 머릿속에 영원히 살게 해주는 것이다.

19.당신 자신을 옹호하지 않은 것

노인들은 다른 사람의 욕을 듣고 가만히 있지 않는다.

당신도 그럴 필요가 없다.

20.충분히 봉사하지 않은것

나이가 들면 세상을 좀 더 좋은 곳으로 만들기 위해

나서지 않았던 것을 슬퍼하게 된다.

21.치아를 무시한 것

칫솔질하고 치실도 써라 정기적으로 닦아라

틀니를 하게 되면 그러지 않았던 것들이 몹시 후회된다.

22.할머니, 할아버지가 돌아가시기 전에 질문을 하지 않았던 것

우리들은 할머니, 할아버지들이 놀라운 지혜를 가지고 계신 것을

너무 늦게 깨닫는다. 그 분들은 당신이 어디서 왔는지 등

궁금해 하는 모든 것에 대해 설명해준다.

단, 그들이 살아 계실때 질문을 해야한다.

23. 너무 열심히 일한 것

아무도 죽음의 순간에 좀 더 많은 시간을 사무실에서 보냈으면

하고 생각하지 않는다. 대부분의 사람들은 가족들과

친구들과 취미로 더 많은 시간을 보냈기를 희망한다.

24.멋진 요리 하나를 배우지 않은 것

군침을 흘릴 만한 음직을 알아두는 것은 저녁식사 파티나 기념식을

좀 더 멋지게 만들어 준다.

25.감사한 순간을 위해 잠깐 멈추지 않았던 것

젊은 사람들은 계속 앞으로 나아간다.

그러나 때때로 주변을 둘러보기 위해 모든것을 잠시 멈추는것은 좋은 것이다.

26.시작한 것을 끝마치지 못한 것

'난 간호사가 되고 싶었어요. 그래서 수업에 참가했지만...'

27.재밌는 파티 마술 하나는 익히지 못한 것

당신은 인생에서 수천 번은 아니지만, 수백 번의 파티를 가게 될 것이다.

하나쯤 익혀두는게 인생을 재밌게 하지 않을까?

28.사회적 기대에 맞추어 당신을 가둔 것

사회적 기대들이 '우리는 그걸 하면 안돼.' 라고 말하게 내버려 두지 마라.

29친구들이 자기 길을 가지 못하게 붙잡은 것

사람들은 헤어진다. 모든 것이 변한다는 사실을 인정하지 못하고, 지나간

것에 매달리는건 불안과 슬픔의 원인이 될 수 있다.

30.아이들과 충분히 놀아주지 못한 것

나이가 들면 당신 아이들이 놀아주기를 원하기보다 자기 방에서

나가주기를 원한다는 것을 알게 된다.

31.한 번도 큰 위험에 도전하지 않았던 것(특히 사랑에 있어서)

적어도 한 번 맹목적인 믿음에 빠졌다는 것은 (비록 실패라도) 나이 들었을 때

큰 위안이 된다.

32.사람들을 만나거나 관계를 넓힐 시간을 갖지 않았던 것

사람을 사귀고 대인관계를 넓히라는건 젊었을 때는 헛소리 같았을 것이다.

그러나 나중에는 그것이 직장을 구하는 좋은 방법이었음을 알게 될 것이다.

33.너무 많은 걱정을 했던 것

Tom Petty가 노래했다

'내가 걱정하는 대부분의 일은 절대 일어나지 않을 것들이다.'

34.쓸데없는 드라마에 빠져 있었던 것

도대체 누가 그걸 필요로 하는가?

35.사랑하는 사람과 충분한 시간을 보내지 않았던 것

사랑하는 사람과의 시간은 유한하다.

그 시간을 가치있게 사용하라.

36.많은 사람들 앞에서 한 번도 공연해보지 못한 것

모든 사람들이 이런 후회를 하는것은 아니다

그러나, 많은 노인들이 대중앞에서 자신의 재능을 한 번 보여줄 수

있었다면 하고 생각한다.

37.좀 더 빨리 감사해 하지 않았던 것

처음부터 그러기는 어렵다.

그러나 시간이 지날수록 지구 상의 모든 순간들이

(일상에서부터 놀라운 일들까지) 우리가 함께 나누어야 할 매우

소중한 선물이라는 사실을 느끼게 된다.

토비의 스프링 (6)

Note&pen — Tue, 8 Jan 2019 23:48:46 +0900

제어의 역전

- 프로그램의 제어 흐름 구조가 뒤바뀌는 것

일반적 프로그램의 흐름은 main() 메소드와 같이

프로그램이 시작될때 다음에 사용할 오브젝트를 결정하고

결정한 오브젝트를 생성하고 생성된 오브젝트의

메소드를 호출하고 그 오브젝트 메소드 안에서 다음에 사용할

것을 결정하고 호출하는 식의 작업이 반복됨

제어의 역전은 오브젝트가 자신이 사용할 오브젝트를

스스로 선택하지 않음.

생성하지도 않음.

모든 제어 권한을 자신이 아닌 다른 대상에게 위임하기 떄문이다.

제어의 역전 개념은 이미 많이 적용되어있다.

대표적으로 서블릿

서블릿은 개발을해서 서버에 배포할 수는 있지만

그 실행을 개발자가 직접 제어할 수 있는 방법이 없다

대신 서블릿에 제어 권한을 가진 컨테이너가

적절시점에 서블릿 클래스의 오브젝트를 만들고

그 안의 메소드를 호출한다.

이것이 컨테이너 안에서 동작하는 구조는 간단한 방식이지만

제어의 역전 개념이 적용되어 있는것이다.

프레임워크도 제어의 역전 개념이 적용된 대표적인 기술이다.

보통 프레임워크 위에 개발한 클래스를 등록해두고

프레임워크가 흐름을 주도하는 중에 개발자가

만든 애플리케이션 코드를 사용하도록 만드는 방식이다.

애플리케이션은 프레임워크가 짜놓은 틀에서

수동적으로 동작해야한다.

제어의 역전에서는 프레임워크 또는 컨테이너와 같이 애플리케이션

컴포넌트의 생성과 관계설정, 사용, 생명주기 관리 등을

관장하는 존재가 필요하다.

스프링은 IOC(제어의 역전)을 모든 기능의 기초가

되는 기반기술로 삼고 있으며, IOC를 극한까지

적용하고 있는 프레임워크다.

스프링에서는 스프링이 제어권을 가지고 직접

만들고 관계를 부여하는 오브젝트를 빈(bean) 이라고 부른다.

자바빈 또는 엔터프라이즈 자바빈(EJB) 에서

말하는 빈과 비슷한 오브젝트 단위의

애플리케이션 컴포넌트를 말한다.

스프링 빈은 스프링 컨테이너가 생성과 관계설정,

사용 등을 제어해주는 제어의 역전이 적용된 오브젝트를 가르키는 말이다.

스프링에서는 IOC 오브젝트를 빈 팩토리 라고 부른다.

보통 빈 팩토리 보다는 이를 좀 더 확장한 애플리케이션 컨텍스트

를 주로 사용한다. 애플리케이션 컨텍스트는

IOC방식을 따라 만들어진 일종의 빈 팩토리 라고 생각하면 된다.

빈 팩토리는 빈을 생성하고 관계를 설정하는 IOC의 기본

기능에 초점을 맞춘 것이고 애플리케이션 컨텍스트는 애플리케이션

전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IOC엔진이라는

의미가 좀 더 부각된다고 보면 된다.

getBean("myUserDao", UserDao.class)

는 UserDao.class 에서 myUserDao 메소드를 호출한다는 의미.

애플리케이션 컨텍스트 사용의 이점.

1. 클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다.

2. 애플리케이션 컨텍스트는 종합 IOC 서비스를 제공해준다.

3. 애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공한다.

스프링 IOC의 용어

빈 - 스프링이 IOC 방식으로 관리하는 오브젝트

스프링을 사용하는 애플리케이션에서 만들어지는 모든 오브젝트가

다 빈은 아님. 그 중에서 스프링이 직접 생성과 제어를 담당하는 오브젝트만을

빈이라고 부른다.

빈 팩토리 - 스프링의 IOC를 담당하는 핵심 컨테이너를 가르킴.

빈을 등록, 생성, 조회, 반환 하는 빈을 관리하는 기능을 담당.

애플리케이션 컨텍스트 - 빈 팩토리를 확장한 IOC컨테이너.

빈 팩토리의 기능에서 스프링이 제공하는

각종 부가 서비스를 추가로 제공함.

ApplicationContext 는 BeanFactory를 상속함.

설정 정보 / 설정 메타정보 - 스프링의 설정 정보란 애플리케이션

컨텍스르 또는 빈 팩토리가 IOC를 적용하기 위해

사용하는 메타정보를 말함. 영어로 configuration

애플리케이션 컨텍스트는 싱글톤을 저장하고

관리하는 싱글톤 레지스트리 이기도 함.

스프링은 기본적으로 별다른 설정을 하지 않으면

내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다.

싱글톤으로 만드는 이유는 스프링이 주로

적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버 환경이기 때문.

서블릿은 자바 엔터프라이즈 기술의 가장 기본이 되는

서비스 오브젝트이다.

서블릿은 대부분 멀티스레드 환경에서 싱글톤으로 동작한다.

서블릿 클래스당 하나의 오브젝트를 생성하고 사용자의 요청을 담당하는

여러 스레드에서 하나의 오브젝트를 공유하여 동시 사용한다.

이렇게 애플리케이션 안에 제한된 수, 대개 한 개의 오브젝트만

만들어서 사용하는 것이 싱글톤 패턴의 원리.

싱글톤 패턴 구현 방식의 문제점

1. private 생성자를 갖고 있기 때문에 상속할 수 없다.

2. 싱글톤은 테스트하기가 힘들다.

3. 서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.

4. 싱글톤의 사용은 전역 상태를 만들 수 있기 떄문에 바람직하지 못하다.

자바스크립트 date.getFullYear()

Note&pen — Mon, 7 Jan 2019 22:33:06 +0900

자바스크립트를 공부했을때

Date를 사용해 오늘 날짜를 구했을때가 있었다.

new Date()를 사용했는데

오늘 회사에서 새로운 사실을 알았다.

Date 에서 난 연도를 가져올때 당연히 getYear()로

값을 가져올 줄 알았는데

getYear() 이 아닌 getFullYear()로

연도를 가져온다는 것이였다.

지금까지 공부해오면서 사실 new Date() 를 사용해본적이

자바스크립트를 공부할 때 처음에 한 번 써본게 다 였던것같다.

왜냐하면 현재 연도나 오늘 날짜를 가져올 일 이 없었기 때문이다.

게시판같은걸 만들때 오늘 날짜와 현재 시각을 insert할때는

그냥 DB에서 바로바로 넣을 수 있었기 때문에

new Date() 같은게 필요없었다.

근데 오늘 오랜만에 자바스크립트로

오늘날짜를 구해오는 부분을 봤다.

오늘 날짜가 20190107 처럼 8자리가 나와야하는데

8자리가 나오지 않아 조건문을 제대로 타지 못하는 부분이였다.

alert 을 찍어보니 1190107이 나오는것이였다.

앞에가 왜 2019가 아닌 119가 나오는지

한참을 생각해봤다. 혹시몰라

getYear()을 검색해보니

웹 표준에서 사라졌단다...

getYear()를 사용하지말고 getFullYear()을 사용하란다.

2019가 아닌 119가 나온 이유는

getYear()은 현재 연도에서 1900 이라는 연도를 빼서

반환한다고 한다.

getFullYear()는 1000 에서 9999년 까지

반환을 한다고 한다.

getFullYear()은 웹 표준이라 브라우저에 상관없이

사용할 수 있다.

토비의 스프링 (5)

Note&pen — Wed, 2 Jan 2019 23:13:09 +0900

객체지향 설계 원칙(SOLID)

객체지향 기술은 어느 날 한 번에 만들어진 것이 아니다.

오랜시간에 걸쳐 점진적으로 발전 해온 기술이다.

때문에 객체지향 기술을 받아들이고 적용하는 관점과

기법에 차이가 조금씩 있다.

객체지향 설계 원칙은 객체지향의 특징을

잘 살릴 수 있는 설계의 특징을 말한다.

예외는 있겠지만 대부분의 상황에 잘 들어맞는

가이드라인과 같은 것이다.

디자인 패턴은 특별한 상황에서 발생하는 문제에 대한 좀 더 구체적인

솔루션이라고 한다면 객체지향 설계 원칙은 좀 더 일반적인

상황에서 적용 가능한 설계 기준이라고 볼 수 있다.

높은 응집도와 낮은 결합도

응집도가 높다는 것은 하나의 모듈, 클래스가 하나의

책임 또는 관심사에만 집중되어 있다는 것.

높은 응집도

응집도가 높다는 것은 변화가 일어날 때 해당 모듈에서

변하는 부분이 크다는 것으로 설명할 수 있다.

즉, 변경이 일어날 때 모듈의 많은 부분이

함께 바뀐다면 응집도가 높다고 말할 수 있다.

낮은 결합도

낮은 결합도는 높은 응집도보다 더 민감한 원칙이다.

느슨한 연결은 관계를 유지하는데 꼭 필요한 최소한의 방법만 간접적인

형태로 제공하고 나머지는 서로 독립적이고 알 필요도 없게 만들어 주는것.

결합도가 낮아지면 변화에 대응하는 속도가 빨라지고,

구성이 깔끔해진다. 또한 확장성도 좋아진다.

낮은 결합도란 하나의 변경이 발생할 때 마치 파문이 이는 것처럼

여타 모듈과 객체로 변경에 대한 요구가 전파되지 않는 상태를 말한다.

토비의 스프링 (4)

Note&pen — Wed, 2 Jan 2019 22:21:31 +0900

추상화란 어떤 것들의 공통적인

성격을 뽑아내어 이를 따로 분리해내는 작업이다.

자바가 추상화를 위해 제공하는 가장

유용한 도구는 인터페이스이다.

인터페이스는 자신을 구현한 클래스에 대한

구체적인 정보는 모두 감춰버린다.

인터페이스는 어떤 일을 하겠다는 기능만 정의해놓은 것이다.

이말은 인터페이스는 "어떤 기능을 하겠다." 하는 구현체가 없다

구현은 인터페이스를 구현할 클래스들 안에서 해야한다.

아래처럼 인터페이스를 정의하자.

DB커넥션을 가져오는 메소드 이름을 makeConnection()

이라고 정했다.

위 인터페이스를 사용하는

UserDao 는 ConnectionMaker 인터페이스 타입의

오브젝트라면 어떤 클래스로 만들어졌든지

makeConnection() 메소드를 호출하면 Connection타입의

오브젝트를 만들어서 돌려줄 것이다.

위 인터페이스를 사용할 때에는

아래와 같이 ConnectionMaker를 implements(구현)하고

Connection makeConnection()을 자기만의 방법으로

만들어 주면 된다. 예를 들어 위에서 makeConnection()은

DB커넥션을 가져오는 메소드라 정했으니

아래의 makeConnection()은 자기가 사용할

DB에 맞게 커넥션을 가져올 수 있도록 하면된다.

아래는 특정 클래스 대신 인터페이스를 사용해서 DB커넥션을

가져와 사용하도록 수정한 UserDao이다.

UserDao의 add, get 메소드와 필드에는 ConnectionMaker 라는

인터페이스와 인터페이스의 메소드인 makeConnection만 사용하도록 되있다.

그러니 이제는 위 클래스를 옆에 있는 친구에게 주고 사용하라고 하고

이 친구가 DB접속용 클래스를 다시 만든다고 해도

UserDao의 코드를 뜯어 고칠 일은 없다.

하지만 위에서 connectionMaker = new AConnectionMaker()를 보면

AConnection 클래스의 생성자를 호출해서 오브젝트를 생성하는

부분이 아직 남아있다.

UserDao의 다른 모든 곳에서는 인터페이스를 이용하게

만들어서 DB커넥션을 제공하는 클래스에 대한 구체적 정보가 모두 제거됬지만

초기에 한 번 어떤 클래스의 오브젝트를 사용할지를 결정하는

생성자의 코드는 제거되지 않고 남아 있다.

결국 아직도 UserDao의 변경없이는 DB커넥션 기능의 확장이 자유롭지 못하다.

완벽하게 분리를 하여 독립적으로 사용하려면

UserDao의 클라이언트에서 UserDao를 사용하기 전에

먼저 UserDao가 어떤 ConnectionMaker의 구현 클래스를 사용할지를

결정하도록 만들어야한다.

즉, UserDao 오브젝트와 특정 클래스로부터 만들어진

ConnectionMaker 오브젝트 사이에 관계를 설정해주는 것이다.

클래스 사이에 관계가 만들어진다는 것은 한 클래스가 인터페이스 없이 다른

클래스를 직접 사용한다는 것이다.

따라서 클래스가 아니라 오브젝트와 오브젝트 사이의 관계를 설정해줘야 한다.

오브젝트 사이의 관계는 런타임 시에 한쪽이 다른 오브젝트의 레퍼런스를 갖고 있는

방식으로 만들어진다. 따라서 위에서 말한

connectionMaker = new AConnectionMaker() 는

AConnectionMaker의 오브젝트의 레퍼런스를 UserDao의

connectionMaker 변수에 넣어서 사용하게 함으로써

이 두 개의 오브젝트가 사용 이라는 관계를 맺게 해주는 것이다.

이제 위소스를 완벽히 독립시켜보자.

현재는 UserDao 클래스의 main()메소드가 UserDao클라이언트라고 볼 수 있다.

좀 더 깔끔하게 구분하기 위해 UserDaoTest라는 이름의

클래스를 하나 만들고 UserDao에 있던 main()메소드를 UserDaoTest로 옮겨보자.

그리고 UserDao의 생성자를 수정해서 클라이언트가 미리

만들어 둔 ConnectionMaker의 오브젝트를 전달 받을 수 있도록 파라미터를 하나 추가한다.

UserDao의 생성자는 이제 아래와 같이 바뀌었다.

클라이언트와 같은 제3의 오브젝트가 UserDao 오브젝트가

사용할 ConnectionMaker 오브젝트를 전달해주도록 만든 것이다.

이렇게 하고 나니 UserDao에는 ConnectionMaker의 구체적인

구현 클래스 이름인 AConnectionMaker가 사라졌다.

AConnectionMaker를 생성하는 코드는 UserDao와 특정 ConnectionMaker 구현

클래스의 오브젝트 간 관계를 맺는 책임을 담당하는 코드였는데

그것을 UserDao의 클라이언트에게 넘겨벼렸기 때문이다.

이제 UserDaoTest는 아래와 같이 바뀐다.

UserDaoTest 는 UserDao와 COnnectionMaker 구현 클래스와의

런타임 오브젝트 의존 관계를 설정하는 책임을 담당해야 한다.

그래서 특정 ConnectionMaker 구현 클래스의

오브젝트를 만들고, UserDao생성자 파라미터에 넣어 두 개의 오브젝트를 연결해준다.

그리고 원래 자기 책임이던 UserDao에 대한 테스트 작업을 수행한다.

클라이언트인 UserDaoTest가 이렇게 해줌으로써 UserDao의 변경없이도

자유롭게 DB커넥션의 기능을 확장할 수 있다.

이제 BConnectionMaker라는 이름으로 새로운

커넥션을 사용하고 싶다면

ConnectionMaker connectionMaker = new BConnectionMaker(); 를

사용하면 된다.

StringBuilder, StringBuffer 의 차이 (멀티 쓰레드)

Note&pen — Sat, 29 Dec 2018 23:12:25 +0900

이번 포스팅에서는 StringBuilder와 StringBuffer의

차이에 대해 알아보자.

StringBuilder와 StringBuffer의 차이는 대표적인

면접 단골 질문이기 때문에 면접 준비를 해봤던 사람이라면

누구나 한번쯤 들어봤을거라 생각한다.

StringBuffer, StringBuilder 클래스는 String 클래스와는 다르게

값이 변한다. 예를 들어 String aaa = ""; 선언을 하고

aaa 에 반복문을 이용해 aaa += 1 과 같이 값을 계속 넣어준다면

aaa 는 1,2,3,4,5. . . 값을 계속 해서 가지게 된다.

aaa 가 4에서 5가 됐을때도 4라는 값을 계속 가지고 있기 때문에

메모리 낭비가 된다. 반복문을 이용해 적은양의 데이터를 String에 저장한다면

큰 문제는 없지만 몇만 건 이상의 값을 String에 저장을 하게된다면

메모리낭비와 과부화가 걸릴 수 있다. 이때 사용되는것이

StringBuffer나 StringBuilder 이다. String클래스와는 다르게 GC가 되어

메모리 낭비가 되지 않고 과부화 걱정도 덜어지게 된다.

보통은 StringBuilder를 더 많이 사용할 것이다.

왜냐하면 StringBuffer보다 StringBuilder의 속도가 훨씬 빠르기 때문이다.

하지만 멀티 쓰레드를 사용하게 된다면 말이 달라진다.

StringBuffer는 멀티 쓰레드에서 안전하고

StringBuilder는 멀티쓰레드 에서는 불안전하고 단일 쓰레드에서만 안전하기 때문이다.

아래의 소스를 사용해 간단하게 비교해 볼 수 있다.

A를 6번 붙이고 5개를 삭제하기 때문에

addChar() 메소드가 한 번 돌때마다 A는 한 개가 생성된다.

그리고 for문을 10000번 타기 때문에

A는 10000개가 생성되어야 하고

2개의 쓰레드가 사용되기 때문에 A는 총 20000개가 생성되어야 한다.

멀티쓰레드에서 안전한 StringBuffer는 20000개가 정상적으로

생성되어 저장되지만 그렇지 않은 StringBuilder는 20000개가

정상적으로 생성되어 저장되지 못한다.

그렇기 때문에 StringBuilder와 StringBuffer를 사용할 때는

상황에 맞게 사용해야 한다.

토비의 스프링 (3)

Note&pen — Mon, 24 Dec 2018 23:27:02 +0900

리팩토링은 기존의 코드를 외부의 동작방식에는

변화없이 내부 구조를 변경해서 재구성하는 작업 또는 기술을 말함.

리팩토링을 하면 코드 내부의 설계가 개선되어

코드를 이해하기 좋아지고 변화에 효율적으로 대응할 수 있다.

코드의 품질이 올라가고 유지보수가 용이해진다.

ex) 중복코드를 없에는 작업

상속을 통한 확장

추상메소드 사용하기

추상클래스로 만든 나의 UserDao 클래스를

옆에 친구에게 준 후 이 친구도 내가 만든

UserDao클래스를 사용할 수 있게 해줘야한다.

그럼 이친구는 나의 UserDao 클래스를 상속해서

자기 마음대로 서브클래스를 만들어 사용하면 된다.

서브클래스에서 내 UserDao클래스 안에 있는

추상메소드로 선언한 getConnection() 메소드를

원하는 방식으로 구현해 사용할 수 있다.

이렇게 함으로써 UserDao의 소스코드를 제공해서

수정해 쓰도록 하지 않아도 getConnection() 메소드를 원하는 방식으로

확장한 후에 UserDao의 기능과 함께 사용할 수 있다.

위처럼 슈퍼클래스에 기본적인 (커넥션 연결, sql생성 실행 반환)을 만들어

이 기능의 일부를 추상메소드나 오버라이딩이 가능한 protected 메소드

등으로 만든 뒤 서브클래스에서 이런 메소드를 필요에 맞게 구현해서

사용할 수 있도록 하는 방법이 디자인 패턴에서 템플릿 메소드 패턴.

템플릿 메소드는 스프링에서 자주 사용됨.

디자인 패턴

- 소프트웨어 설계 시 특정 상황에서 자주 만나는 문제를

해결하기 위해 사용힐 수 있는 재사용 가능한 솔루션을 말함.

디자인 패턴은 주로 객체지행 설계에 관한 것임.

패턴에서 가장 중요한 것은 각 패턴의 핵심이 담긴 목적이나 의도이다.

DAO의 확장

클래스의 분리

완전한 독립적인 클래스 만들기.

상속을 사용하지 않으니 abstract는 필요가 없다.

SimpleConnectionMaker의 오브젝트를 만들고

add 나 get 같은 다른 메소드에서 이를 이용해

DB커넥션을 가져와 사용한다.

DB커넥션 기능을 하는 SimpleConnectionMaker는 아래와 같이

아예 분리를 시켜 독립을 시킨다.

위처럼 커넥션 기능을 하는 기능을 분리했더니

상속을 통해 커넥션 기능을 확장해 사용하던게 다시 불가능해졌다.

UserDao가 SimpleConnectionMaker 라는 특정 클래스에

종속 되었기 때문이다.

때문에 다음 포스팅에서 인터페이스를 볼 것이다.

토비의 스프링 (2)

Note&pen — Wed, 19 Dec 2018 23:23:20 +0900

UserDao

-사용자 정보를 DB에 넣고 관리할 수 있는 DAO클래스이다.

스프링을 공부할 정도라면 JSP로 게시판 한번쯤은 다 짜봤을것이다.

Dao를 한번씩 다 사용해봤을거란 말이다.

그럼 Dao에서 JDBC를 연결해보는 작업도 해봤을것이다.

JDBC를 이용하는 작업의 일반적인 순서

-DB 연결을 위한 Connection 가져오기

-SQL을 담은 PreparedStatement 생성

-만들어진 PreparedStatement 실행

-조회의 경우 SQL 쿼리의 실행 결과를 ResultSet으로 받아 저장한다.

-작업중에 생성된 Connection, Statement, ResultSet 반환하기.

ex)

위 소스에서 2,3,4 line을 기억하자.

main()을 이용한 테스트

만들어진 코드의 기능을 테스트 해볼때는 오브젝트

스스로 자신을 검증하도록 만들어주는 것이 가장 간단하다.

모든 클래스에는 자신을 엔트리 포인트로

설정해 직접 실행이 가능하게 해주는 스태틱 메소드 main()이 있다.

내가 어떠한 코드를 만들었다면 테스트는 main()을 사용하자.

public static void main(String[] args){ }

위 ex)에 있는 코드에서는 user의 아이디, 이름, 비밀번호를

DB에 넣는다 그리고 DB에 넣기 위해

DB와 연결을 하는데 그부분이 2,3,4 line이다.

위에서 user의 값을 넣을때 뿐만아니라

user의 데이터를 select 해서 가져올때도

DB와 연결을 해야하는데 매번 위의 2,3,4 line을 적어줘야한다.

이런 중복코드를 방지하기 위해 나온것이

커넥션이고 프로그래밍 개발에 있어

중복코드는 최소화 해야한다.

위 2,3,4 line의 코드를 아래처럼 독립된 메소드를 만들어준다.

이제 DB연결이 필요하면 getConnection()메소드를 이용하면 된다.

이렇게 독립된 메소드로 빼줌으로써

DB종류가 바뀌거나 드라이버 클래스의

URL이 바뀌거나 로그인 정보가 변경돼도

getConnection()메소드 안의 데이터들만

수정해주면 된다.

토비의 스프링 (1)

Note&pen — Tue, 18 Dec 2018 23:07:20 +0900

스프링은 자바를 기반으로 한 기술.

때문에 스프링은 자바의 객체지향 프로그래밍 기술을

가장 중요한 가치로 둔다.

스프링의 핵심 철학은 객체지향 프로그래밍이

제공하는 폭넓은 혜택을 누릴수 있도록 하는것이다.

그래서 스프링은 오브젝트에 가장 큰 관심을 둔다.

오브젝트의 기술적인 특징과 사용법을 넘어선 오브젝트의 설계에는

다양한 목적을 위한 재활용 가능한 설계방법을 할 수 있도록 하는

디자인 패턴, 구조가 깔끔해질수 있도록 개선하는 리팩토링

오브젝트가 설계대로 동작하고 있는지 확인할 수 있는 단위 테스트

등의 여러가지 응용 기술과 지식이 요구된다.

DAO(Data Access Object) - DB를 사용해 데이터를 조회하거나

조작하는 기능을 전담하도록 만든 오브젝트

자바빈 - 원래는 비주얼 툴에서 조작 가능한 컴포넌트를 말함.

자바의 주력 개발 플랫폼이 웹 기반의 엔터프라이즈 방식으로

바뀌면서 비주얼 컴포넌트로서 자바빈은 인기를 잃어갔지만, 자바빈의 몇 가지

코딩 관례는 JSP 빈, EJB와 같은 표준 기술과 자바빈

스타일의 오브젝트를 사용하는 오픈소스 기술을 통해 계속 이어져 왔다.

이제는 자바빈이라고 말하면 비주얼 컴포넌트라기보다

다음 두 가지 관례를 따라 만들어진 오브젝트를 가리킨다.

디폴트 생성자 - 자바빈은 파라미터가 없는 디폴트 생성자를 갖고

있어야 한다. 툴이나 프레임워크에서 리플렉션을 이용해 오브젝트를

생성하기 때문에 필요하다.

프로퍼티 - 자바빈이 노출하는 이름을 가진 속성을 프로퍼티라고 한다.

프로퍼티는 set으로 시작하는 수정자 메소드(setter)와 get으로 시작하는

접근자 메소드(getter)를 이용해 수정 또는 조회할 수 있다.