아시는 분이 가지고 계신 이 책을 빌려서 잠시 읽은 적이 있다.

그 때는 무슨 내용일지 제대로 이해할 수 없었다.

Sony | D5833

지금도 그렇겠지... Orz...

그래도 지금은 요령이 생겨서... 한번의 완독을 하고, 시간이 지난 후 다시 완독하면서 '반복적인 책 읽기' 를 통해서 내가 쌓은 경험 만큼 깨달음을 얻을 수 있다는 요령을 터득했다.


프로그램을 짤 때는 자신과 컴퓨터뿐 아니라, 다른 사람들을 생각해야 한다!

이것이 구현 패턴이 전하는 메시지입니다. 이 책에서는 다른 사람을 배려하며 프로그래밍할 때의 경제적 이득을 강조했지만, 사실 이는 프로그래머 자신을 위한 것이기도 합니다. 자신이 더 큰 공동체의 일원임을 깨닫게 되면 공동체에 기여하는 것에 대한 만족을 느낄 수 있게 되기 때문입니다. 여러분도 이와 같은 만족감을 느낄 수 있으면 좋겠습니다. 즐거운 코딩 하시길.


- 미국 오레곤 주 메를린에서, 켄트 백 드림


기능적으로 올바르게 동작한다고 해서 모두 훌륭한 코드는 아니다. 훌륭한 코드는 프로그래머의 의도를 일관되게 전달해서, 다른 프로그래머들이 코드를 쉽게 이해하고 사용하며 자신 있게 수정할 수 있어야 한다. 그러나 훌륭한 코드는 쉽게 탄생하지 않는다. 훌륭한 코드는 프로그래머가 하루에도 수백 번 이상 내리는 작지만 중요한 결정의 산물이다. 이러한 중요한 결정들에 대해, 전설적인 소프트웨어 혁신자인 캔트 백이 "강력한 구현 패턴" 을 공개했다. 구현 패턴을 사용하면 더 간결하고 명쾌하며 체계적이고 비용 대비 효과적인 코드를 작성할 수 있다.


이 책은 다른 사람들이 이해하기 쉬운 코드를 만드는 프로그래밍에 대한 내용을 담고 있다. 하지만 너무 큰 기대는 금물이다. 아쉽게도 그런 코드를 만드는 비법 같은 것은 없다. 읽기 쉬운 코드를 작성하는 과정은 읽기 쉬운 글을 쓰는 것과 같다. 대상 독자를 정해야 하고, 명확한 전체 구조를 갖고 잇어야 하며, 전체 줄거를 생각해서 세부를 묘사해야 한다. 자바는 사람이 이해할 수 있는 코드를 작성하는 여러가지 방법을 제공한다. 이 책에는 읽기 쉬운 코드를 작성하는 자바 프로그래밍 습관을 모았다.


이 책은 "어떻게 하면 다른 사람들에게 코드를 전달(커뮤니케이션) 할 것인가?" 라는 고민에 대한 답이기도 하다. 프로그래머는 혼자 생각하면서 보내는 시간이 너무 많으므로, 다른 사람의 관점에서 코드를 바라보려 시도하는 것 자체가 커다란 변화이다. 프로그래머는 "컴퓨터가 이 코드를 어떻게 처리할까" 뿐 아니라 "내 생각을 다른 사람에게 어떻게 전달할까" 하는 고민까지 해야된다. 하지만 기존 코드를 이해하는 데 엄청난 소프트웨어 개발 비용이 투입되는 것을 감안하면, 이러한 변화는 건전할 뿐 아니라 경제적 이득을 가져올 수도 있다.


...


사실 이 책은 "좋은 코드는 중요하다" 라는 빈약한 전제를 기반으로 만들어졌다. 좋은 코드가 상업적 성공이나 광범위한 사용자 확보에 대한 필요조건 혹은 충분조건이라고 믿기에는, 사람들이 조잡한 코드로 돈을 많이 버는 사례를 너무 많이 봐왔다. 코드 품질이 회사나 개인의 미래를 좌우하는 요소가 아니라 할지라도, 나는 여전히 코드 품질이 매우 중요하다고 믿는다. 자신있게 코드를 개발, 출시하고 기회와 경쟁 상황에 따라 개발 방향을 바꿀 수 있으며 위기 속에서도 직원들의 사기를 높일 수 있는 회사는 조잡하고 버그가 있는 코드를 작성하는 회사에 의해 성공할 확률이 높다.


설사 좋은 코딩이 장기적으로 경제적 이득을 가져오지 못한다고 하더라도 나는 여전히 내가 작성할 수 있는 최고의 코드를 작성할 것이다. 인생이 70년이라 할 때 우리 인생은 20억 초에 불과하다. 그 소중한 순간들을 자랑스럽지 않은 일을 하면서 낭비하고 싶지는 않다. 코딩을 잘하는 것은 그 자체로도 프로그래머에게 만족감을 주지만, 다른 사람들이 내 코드를 이해하고 감탄해주며 내 코드를 사용하고 점차 발전시킨다는 점을 생각할 때 매우 중요하다.


결국 이 책은 책임감에 대한 이야기다. 여러분이 프로그래머로서 시간과 재능과 돈과 기회를 부여 받았다. 이러한 자원들을 책임감 있게 잘 사용하려면 어떻게 해야 하는가? 이 책은 이러한 고민에 대한 나의 답이다. 프로그래머는 자신과 CPU뿐 아니라, 자신의 코드를 보고 사용할 다른 사람들을 배려해서 코딩을 해야 한다.



저작자 표시
신고

아는 만큼 보인다.

라는 이 말을 나는 좋아한다. 내 자신에게 적용했을 때 '내가 보지 못하는 부분들에 대해서는 내가 알고 있지 못하기 때문이다.' 라는 위안 과

모른다는 거지. 모르는 건 모른는 거다 라는 것부터 인정해야 알아갈 수 있다.

'알아가야할 것들을 살피고 모르는 것을 알기 위한 노력을 아끼지 말자' 라는 자기반성을 주기 때문이다.


나는 '개발자'로 밥벌이를 하고 있다. 나는 스스로 '지식 노동자'라고 한다.

어떤 요청을 받고 그에 대한 문제해결을 위한 소프트웨어를 개발하는 것이 내 일이다. 이 일은 꾸준하게 '흥미'를 유발하고 더욱 성장하라는 자극을 부여한다.

물론... 그 자극의 효과는 지속적이지는 않다.

지속성을 유지하기 위해서는 '흥미'에 의한 단발적 시도가 아닌 '습관'과 '태도'로 만들어야 한다.

세상에는 많은 개발자가 있다. 그 개발자들 중에는 나보다 뛰어난 개발자들이 있다.

그 개발자들이 나보다 뛰어나고 많은 것을 할 수 있는 능력자들이라는 것을 아는 순간, 그들에게서 많은 것을 보고 배울 수 있게 된다.

아는 것을 늘리기 위해 멈추지 말자.


임백준님이 쓰신 글이 오늘 회자되었다:

거기에 나오는 다음 구절들이 인상깊다.

“진짜가 될 때까지 진짜처럼 행동하라 (Fake it till you make it)”는 원리는 프로그래밍만이 아니라 여러 분야에서 널리 회자되는 행동요강이다.

  • 성공을 위해서 필요한 기술과 재능을 이미 갖추고 있는 사람처럼 행동하라.
  • 되고 싶은 부류의 사람이 이미 된 것처럼 행동하라.
  • 승부가 이미 끝났으며 자신이 크게 승리한 것처럼 행동하라.
  • 처음 가보는 길을 이미 여러 번 왕래한 길인 것처럼 여기며 행동하라.

“캐리어를 통틀어서 저는 9,000번의 슛을 실패했습니다. 300번 가량의 시합에서 패했고요. 동료들이 믿고 패스해준 마지막 슛 찬스를 26번이나 놓쳤습니다. 인생을 살아오면서 저는 끊임없이 실패를 되풀이했습니다. 바로 그랬기 때문에 저는 성공을 거둘 수 있었습니다. - 마이클 조던”




P.S. 이 글은...

함수형 프로그래밍 언어를 공부하면서...

배치성 작업을 멀티스레드로 돌릴방법을 궁리하면서 문득 들었던 생각을 정리해봤다.


그리고 브런치로도 써봤다. https://brunch.co.kr/@ihoneymon/10

저작자 표시
신고

Sony | D5833 | 2016:01:08 08:23:50

오랜만에 올리는 입사후기다. 결론은,

탈락. Orz.

그래도 이번에는 지난 C사 때와는 달리 충분히 납득하고 스스로 이해할 수 있었기에 차분하게 글을 쓴다.


2016년 목표 중 하나는 어느정도 규모를 가지고 있는 회사로 이직을 하는 것이다.

그런 맘이었으면 열심히 했어야지.

우아한 형제들에 입사지원 해보는 것이 어떻겠냐는 이야기를 들은 것은 크리스마스 직전이었다. 회사에는 이야기 하지 않았지만 이미 주변에 이직을 준비한다는 분위기를 잡아놓은 상태였다. 같은 팀원에게는 솔루션(스프링부트를 기반으로 만든 ETL 스케줄링 웹애플리케이션)에 대한 GS(Good Software 인증, TTA 발급)인증을 마치는 대로 떠나겠다는 이야기를 해놓은 상태였다.

개발을 하면서, 나보다 잘하는 사람(훌륭한 개발자는 꾸준하게 학습하고 익히며 실력을 키워야 한다)과 일하고 싶다, 갈증이 더 심해져간다.

기본적으로 알려진 우아한 형제들의 입사지원에 대한 처리절차는

  • 서류전형
  • 서류전형 중 코딩테스트 진행
    • codility.com 를 이용한 코딩테스트를 하기 전에는 회사에 면접자가 방문하여 손코딩을 했다고 한다.
    • @_@)> 개인적으로는 손코딩이 참 힘들다. 의사코드로 코드를 작성하는 것도 대학교때 해본 이후에는 딱히 종이에 적어본 적이 없다.
    • 컴퓨터 앞에 앉아있으니 에디터에 적어서 하지. 타이핑과 손으로 쓰는 건 느낌이 많이 다르다. *
  • 서류전형 통과 후 실무면접
  • 임원면접

의 절차로 진행된다.


아는 분의 추천으로 우아한 형제들 CTO 김범준님과 연락을 하여 입사절차를 진행하기에 앞서 오리엔테이션이 있었다. 만나 뵙기전 인터넷을 통해서 관련된 기사와 영상을 살펴봤다. 현재 우아아한 형제들과 관련된 기술적 이슈는 '기술부채techincal debt' 일 것이다. 한국의 대표적인 스타트업으로서 성장한 우앙한 형제들은 그 폭발적인 성장을 지원할 수 있는 기술적인 한계에 다다랐다고 한다. 그 한계를 넘어서기 위해 새로운 준비를 하고 있다. 이를 위해서 시니어Senior 개발자들을 모집하고 있다는 이야기와 함께 현재 W.B. 의 문화에 대해 소개받았다. 성장가능성과 대기업과는 다른 문화를 가지고 있는 기업의 매력을 충분히 느낄 수 있었다. 입사지원을 하겠다고 하면서 입사절차가 진행된다. 입사지원을 위한 서류전형(이력서 제출)과 함께 코딩테스트가 온라인으로 진행되었다.

입사절차는 대략 3주 정도 걸린다고 보면 된다. 이력서를 제출하면서 서류전형이 시작되고 온라인 코딩테스트를 마치면 일주일 이내에 W.B. 실무 개발자들과 실무면접이 진행되고 그 결과 일주일 이내에 임원면접이 진행된다. 이런 입사절차는 대부분의 기업들과 유사하다.

최근 C사의 경우에는 지원개발자 인력풀을 보고서 각 팀별로 자신이 필요한 개발자인 경우에 팀에서 지원하여 입사절차를 진행하는 형식이라고 한다.

온라인 코딩테스트는 codility.com 기업 테스트를 통해 진행되었다. 총 4개 문제를 3시간 안에 풀어서 제출하는 것이었다. 3개는 정규식과 자바 API를 활용한 문제풀이였고, 하나는 SQL 풀이였다. SQL 문제는 못 풀었다.

ㅡ_-);; JPA를 사용하면서 SQL을 사용하지 않은 지 꽤 된지라 SQL은 당장은 못 풀겠더라.

나머지 문제는 충분히 준비만 해두면 풀 수 있지 싶다. codility.com 은 문제를 풀고 나면 평가를 하는데 그 중에 성능에 대한 평가도 포함되기 때문에 이를 고려해서 작성해야 한다. ㅡ_-);; 내가 잘 했는지는 잘 모르겠다.

앞으로의 추세는 이 codility.com 에 기업에서 링크를 던져주면 개발자가 그 링크로 접속하여 문제를 풀어 제출하고 그 평가점수를 가지고서 추후 입사 진행여부를 결정하는 흐름이 될 것으로 보인다. 그러니 https://codility.com/programmers/ 에서 많이 풀어보고 익숙해지길 바란다.

복.붙(Ctrl + C & Ctrl + V) 신공은 통하지 않는다. 내가 푼 문제의 평가점수도 바로 보여주면 좋을텐데... ㅡ_-);; 그건 안알려주더이다. https://codility.com/programmers/ 에서 풀면 각 영역별 평가점수를 알려준다.

온라인 코딩테스트를 준비한다면 알고스팟 에 가입해서 문제를 풀어보거나, 인사이트의 프로그래밍 대회에서 배우는 알고리즘 문제 해결 전략 을 구매해서 차근차근 준비하는 것이 좋다. 대부분의 기업들이 온라인 코딩테스트를 보는 형태로 갈 것이 분명하니까.

어쨌든... 손코딩보다는 온라인 코딩이 그나마 낫다. @_@);; 의사코드도 손으로 많이 작성하지 않는데 말이지...


온라인 코딩테스트가 끝나고 현 개발자들의 실무면접이 이튿날 잡혔다.

시간을 좀 넉넉하게 잡았으면 좋았을텐데, 이 때는 아무런 생각없이 후딱후딱 일정을 잡았다.

붙을 것이라는 안일한 생각을 가지고 있었는지도 모른다. 그러기 위한 준비가 부족했지만...

퇴근 후 석촌호수 부근에 있는 우아한 형제들 건물을 방문했다.

하필이면 무지 추운 날이었다. 거기다 새로운 건물로 이사한지 얼마 안되어서 어수선한 분위기.

3명의 면접관과 마주앉아서 면접을 진행했다.

면접은 이력서에 등록되어 있는 경력 위주로 질문하고 그에 대해 답변하는 식으로 진행되었다. 내가 했던 일들에 대해서 상세히 설명하면서 이야기를 나누었다. 면접자의 감정을 상하게 하거나 하는 분위기는 딱히 없었다.

만약 그랬다면, 아주 격하게 씩씩거리면서 글을 썼겠지.

어찌보면 자바와 관련된 기초적인 질문들에 대해서 답변을 못했다. ㅎㅎ...

    String, StringBufferStringBuilder 의 차이(<- 링크를 클릭해서 API를 보라~)

    • 곁들여서 불변객체가변객체 의 차이, 스레드와 프로세서의 차이, 자바의 메모리 구조: Heap, Perm...

      위의 String 과 관련된 질문에 대한 힌트라고 봐도 무방하겠다. 면접 때는 여기에 생각이 미치지 않았었는데, 면접 끝나고 나서 '아, String 은 불변객체였지. 그래서 String에 문자열을 붙이는 식으로 변경을 하게 되면 불변객체를 새로이 생성하면서 비용이 많이 들고 이를 피하기 위해 StringBuffer 를 써서 append() 로 문자열을 구성한 후에 마지막에 toString() 으로 결과를 반환받았지. 그런데 이 StringBuilder가 스레드세이프thread safe 하지 않단 말이야. 그래서 스레드 세이프한 StringBuilder 를 쓰게 되었지. 그런데 쓰레드세이프란 뭔고 하니, 멀티스레드 상태가 되어서 StringBuffer 인스턴스에 접근해서 조작을 해도 그 값에 대한 접근을 제어해주기 때문에 최종결과가 우리가 예상했던 대로 나오는거지. 그렇다면 스레드와 프로세스의 차이는 뭔가... '

  • 라며 생각의 끈이 이어졌지만, 이미 게임오버. 라고 정리를 했는데, 글을 다시 보니... @_@)> StringBufferStringBuilder를 반대로 알고 있었네. 흠.... 사실 이런 부분은 Java API 문서를 찾아봐야한다. 음트트.... 부끄부끄.

면접이 끝나고 돌아가려는 내게 '작은 선물 세트'를 건네주면서 면접과정에서 진행한 '온라인 코딩테스트'의 문제는 적절했는지 여부 등을 묻는 세심함을 보였다.

아, 내 코드 결과를 알려달라고 할 것을!! 깜빡했다.

아쉬운 마음으로 집에 돌아왔다.

다음날 오후 김범준님이 직접 전화를 주셨다.

지금 W.B. 에는 많은 주니어 개발자가 있다. 새로운 전환을 하는 과정에서 주니어들을 이끌어줄 경험이 풍부한 시니어 개발자를 뽑고 있는 중이다. 그런 요구사항에는 부합하지 못했다. 지금 찾고 있는 상황과 맞지 않은 것 뿐이다. 다른 기회가 있을 때 만날 수 있으면 좋겠다.

이야기를 들으면서 충분히 수궁할 수 있었다. 면접 후에 여러가지 생각을 하게 되었던 계기가 되어주었기에 나쁘지 않은 면접이었다.

현재 회사에서 팀원들과 함께 만들고 있는 솔루션은 스프링부트를 근간으로 해서 스프링프레임워크, 스프링 데이터 JPA, 타임리프, 그리고 기타 등등을 사용하여 만들고 있다. 그런데, 여기에 사용한 기술들에 대해서 문서로 정리하고 별도의 교육을 진행하고 했지만 제대로 이해하지 못하는 부분들이 많은 아쉬움(혹은 답답함)을 느끼고 있는 상황이었다.

그런 내가, 누군가를 가르치면서 이끌어가야 한다는 것은... 제대로 수행하지 못할 가능성이 높다. 주니어들을 이끌면서 그 과정에서 발생하는 다양한 문제들을 해결하고 이를 정리해서 알려주는 역할을 해줄 사람을 필요로 하고 있다.

그냥 다니면 그냥 다닐 수 있는 회사다. 그런 회사를 나오려고 하는 건 '보다 잘하는 사람들'과 일하면서 그들에게서 자극받고 공부하면서 일하고 싶은 욕심이 들었기 때문이다. 나는 취미생활을 즐긴다. 개발을 위해 많은 시간을 투자하기 보다는, 근무시간 안에 해야할 일들을 처리하고 그 이외의 시간에는 '클라이밍', '라이딩, '여행' 등을 즐기며 지내고 싶은 욕구가 강하다. 그 외의 시간에는 개인적인 공부와 커뮤니티 활동을 하면서 보내고 있는 '내성적인' 성격의 월급쟁이형 개발자다. 나이가 들어서도 이런 생활을 유지하기 위해서는

'늘어나는 경력 만큼 실력도 뒷받침이 되어야 한다'

라는 결론을 내렸다. 그 준비를 해야할 때가 되었다고 본다.

스프링 프레임워크를 사용하기 시작한건 '모바일 교보문고' 프로젝트에 참여하면서 부터였다. 스프링만 6년 정도를 사용해 왔다. 초창기에는 누군가가 구성해진 환경안에서 비즈니스로직을 구성하는 역할이었다면, 이제는 내 스스로 프로젝트를 구성하고 그 안에서 필요한 기능들을 추가하고 그에 대한 교육을 할 수 있는 수준에 이르렀다. 그 후로 지속적으로 스프링프레임워크를 공부하고 스프링프레임워크를 기반으로 프로젝트를 진행해왔다. 지금은 스프링부트를 열심히 이용하고 있다. 현재 내가 가장 잘 사용할 수 있는 도구가 스프링인 것이다. 이 스프링 프레임워크의 틀 안에 갇혀 있을지도 모른다는 이야기도 있었다. 그 이야기를 듣고 새로운 능력을 갖출 필요가 있겠다 싶어 함수형 프로그래밍 언어에 대한 학습을 시작했다. 우선은 하스켈Haskel 을 시작으로 해서 스칼라로 넘어갈 계획이다. 그리고 웹 애플리케이션 개발에서 벗어나 애플리케이션 아키텍처를 구성하는 시도를 해보려고 한다.

W.B. 의 면접을 통해서 이런저런 많은 생각을 했다.

  • 아 이제 나도 시니어 개발자Senior Developer 의 계열에 들어섰구나.

    늙었구나.

  • 그렇다면 시니어 개발자란 뭘까?

    난 그냥 비즈니스로직 개발하는데 집중하고, 필요하다면 아키텍처 구성하는 정도의 일이면 충분한데... 누군가를 가르쳐야하는 것인가? 이건 팀원들과 함께 프로젝트를 진행하면서 드는 의문이다. 프로젝트에 사용한 기술들에 대해서는 내가 전파교육을 하는 것이 맞다고 본다. 이를 위해서 프로젝트 초기에 매주 1~2시간씩 교육을 하고 필요한 내용을 문서로 정리해서 공유하고 질문에 대응도 해줬다. 그리고 매주 2시간씩 책을 읽으면서 스터디도 진행했다. 그 이상을 더 해줘야하는 것인가?

    하는 의문이 든다. ㅡ_-)> 내 계약서 상에는 직원 교육이 있는 것도 아닌데... 회사에서는 신입사원에 대한 교육도 요구하기 시작했다. 흠... 어찌되었든, 스쿠버다이빙 강사 자격도 획득했지만 그 교육을 받으면서 드는 생각은 '내가 누굴 가르치면 안되겠다' 였다.

  • 주어진 일을 완수하기 위해 노력하고 완수해내는 것만으로 내 역할은 부족한 것인가?

  • 기업들의 입사프로세스도 비슷해서, 실무면접에서 나올 수 있는 Java API 관련한 질문들을 정리한 자바실무면접정석을 하나 뽑아내도 되겠다 싶어졌다.

사실 짧은 면접절차동안에 면접자가 '어떻게 코드를 작성하고 이를 확인하고 구현하는지'를 모두 알아볼 수는 없다. 그래서 그 절차를 위한 통과규정을 잡고 그 규정을 통과한 사람만이 거길 통과하여 입사에 성공할 수 있게 된다. 7년 동안 5번 이상의 이직을 하면서 얻은 결론은 그렇다. 면접은 '복불복'성이 짙은 편이다. 서류전형, 코딩테스트, 실무면접과 임원면접에 이르기까지 사람과 사람이 연관되어 함께 일할 사람을 뽑아 가는 과정이기 때문이다. 이 과정은 많은 연습과 실전을 통해서 어느정도 익숙해지기 마련이다.

동물은 자신의 서식지를 옮길 수 있다.

개발자는 자신의 근무지와 환경을 옮길 수 있다. 잘 옮길 수 있다. 여전히 개발자를 찾는 곳은 많기 때문이다. 문제는~ 그 찾는 곳에 들어갈 수 있는 준비가 되었느냐 하는 것이다. 대부분의 기업들의 입사절차가 비슷해져 갈 것이다. 이력서를 받아 서류전형을 거치고 온라인 코딩사이트에서 코딩테스트를 진행하고 그 결과를 보고 실무면접을 진행하고 임원면접을 거쳐 채용을 결정하고 그 후에 연봉을 조정한 후에 입사 여부를 결정한다.

2016년 계획 중 하나는, '이직'이다. 웹 애플리케이션 개발에서 조금 더 나아가서 아키텍처를 설계하고 이를 구현하는 '아키텍트' 단계로 나갈 포석을 깔 수 있는 곳을 찾는 것을 목표로 하고 있다.


자랑할 만한 이야기는 아니지만, 여전히 자신의 자리를 찾아 방황하는 많은 이들을 위해 계속 작성해보려 한다.


읽을꺼리


저작자 표시
신고
  1. Favicon of http://okihouse.tistory.com/ BlogIcon OKIHOUSE 2016.01.21 15:37 신고

    잘 읽고 갑니다~

    생각보다 쉽지 않군요~

    허니몬님은 흔히 얘기하는 좋은개발자(?) 라고 생각하고있었는데~

    우형이 기회를 놓쳤다고 생각하시는것도 ㅎㅎ

  2. 2016.01.21 17:05

    비밀댓글입니다

  3. 아라한사 2016.01.22 05:34 신고

    저도 허니몬님이 좋은 개발자라고 생각하고,
    허니몬님 스타일이, 저와는 다르지만 (전 막 파려고 노력은 하는데 잘 안파지는 스타일 ㅎㅎ )
    즐길 것들을 즐기시고 때론 쿨한 모습이, 제가 좋아하는 개발자스타일입니다... !

    좋은 글 잘 읽었습니다~

    • 좋은 개발자라 해주시니 감사합니다.

      ㅎㅎ 사실 저 면접의 경우에는 좋고 그렇지 않고의 여부보다는 뽑는 자리에 적합한가 여부가 중요하다고 봅니다.

      '시니어 개발자'란 어떤 역할을 해야하는가에 대한 고민을 하는 좋은 계기가 되었습니다.

      ㅡㅅ- '시니어 개발자'는 저랑은 안맞는다는 최종결론에 닿았습니다.

  4. ㅇㅇ 2016.01.22 19:26 신고

    제가 심사위원이면 님 블로그 폰트 보고 안뽑을듯

    • 감사합니다.
      님같은 사람이랑 일하지 않을 기회를 주셨군요.

    • 코난이얌 2016.01.29 13:51 신고

      블로그 폰트를 무엇을 쓸지는 순전히 개인의 취향이죠.

      그리고 공식적인 프로젝트도 아닌 개인 블로그에 사용한

      개인의 취향 폰트가 맘에 안든다고 안뽑는 심사위원이라면

      당연히 거기 회사에 입사하고 싶어하는 경력자들이 있을지..

  5. BlogIcon 지나가던 사람 2016.01.22 20:05 신고

    잘 봤습니다. 그런데 제일 처음 사진에 C사가 무슨 회사인지 찍혀있는데 이걸 수정하는게 좋지 않을까요.. ㅎㅎ

  6. Favicon of http://... BlogIcon 주니어개발자 2016.01.23 11:58 신고

    하... 이런분도 떨어 뜨리다니
    우형은 어마어마한 곳이엇군요?!!

  7. 2016.01.23 15:01

    비밀댓글입니다

  8. BlogIcon 정호영 2016.02.05 03:38 신고

    우연히 링크타고 들어와서 잘 읽었습니다. 좋은 내용 공유해 주셔서 감사합니다. 다른 분들한테 많은 도움이 될 것 같습니다.
    요즘 안 사용한다고 하지만 손코딩하는 습관이 천천히 생각하는데 도움이 되기 때문에 온라인 져지 사이트도 좋지만 가끔은 손코딩도 좋은 것 같습니다.
    저도 종종 회사의 면접관으로 참여하는데, 한 언어에 대한 깊은 조예와 끊임없는 배움의 자세를 가지신 분들, 행복한 사람, 일 외에 다른 분야에서 깊이 있는 경험을 해 보신 분들에 대한 인상이 좋았습니다.

  9. BlogIcon ... 2016.02.05 07:28 신고

    WB는 원래 보통 인재를 좋아하는데... 기술면접 우수하게 통과하고 임원면접에서 "우리 회사 학벌 보는거 아세요?"라는 CTO 말 듣고 빡쳐서 대충 면접 끝내고 갔습니다.

  10. 가나다 2016.02.20 12:17 신고

    전 코딩 문제에서 떨어졌지만.

    2시간 내에 4문제 푸는게 쉽지는 않던데...

    실력을 조금 더 쌓아야 될 것 같네요.....

    • ^^ 코딩테스트는...
      충분하게 연습을 하시면 수월하게 통과하실 수 있을거에요.

      codility.com 의 온라인 코딩 테스트를 하는 경우가 많으니까 연습하시면 좋아요. ^^

  11. Favicon of http://multifrontgarden.tistory.com BlogIcon LichKing 2016.10.29 15:47 신고

    다른거 검색하다 이 글을 보게됐는데 저도 딱 저 시기에 우형 면접보고 떨어졌는데 왠지 모를 반가움(?) 이 느껴지네요 ㅎㅎ 당시 사무실이 되게 정리가 안됐다고 느껴졌는데 옮긴지 얼마안됐던거군요. 저도 그때를 다시금 추억할 수 있는 글이네요 ㅎㅎ

  12. Mia 2017.08.25 13:11 신고

    우연히 타고 들어왔다가 블로그 스크랩하고 갑니다.
    뭔가 저랑 같은 고민을 하고 계신듯 하네요... 반가운 마음에 글 남깁니다.

    • 벌써 1년이 지났지만....
      전 여전하네요. +_+) ㅎㅎ

      이럴 때,
      나를 자극할 수 있는 건!!
      '낙방'이 아닐까 하는 생각이 문득 드네요.

최근…
이전과는 다르게 협업을 하고, 다른 이들의 코딩을 지도하고, 기술전파를 하고 교육을 하고…
하는 등의 일들을 동시다발적으로 진행하면서 내 부족함을 새삼 깨닫는다.

전과는 다른 역할을 수행하고 있기 때문이겠지.

    특히나 부족함을 느끼는 것이 ‘정확한 의사전달력’이다.

이야기를 나누고 리뷰를 하다보면 말의 언성이 높아지면서 스트레스를 담게 되는 몹쓸 습관이 있다.
이건 다른 사람들과 대화를 나누는 것에 대한 경험이 부족했기 때문이겠지.

즉흥적이게 이야기를 하는 편인 내게,
현재의 상황과 다음 상황을 고려하면서 이야기를 주고받는 것이 쉬운 일이 아니다.

GoPro | HERO3+ Silver Edition | 2014:09:05 12:28:47


올해 들어서,
다른 사람들과 함께 일하는데 필요한 능력들이 부족함이 여실히 드러났다.
이건… 어떻게 하면 일정수준까지 향상시킬 수 있을까?

저작자 표시
신고

'logbook' 카테고리의 다른 글

20150815, GopherCon korea 2015 참관기  (0) 2015.08.16
0416, '대한민국' 이라는 이름의 배가 침몰한 날  (0) 2015.04.16
부족함.  (0) 2015.03.18
SpringCamp 2015 준비중.  (0) 2015.03.09
2014 드림엔터 IoT 해커톤 구경.   (0) 2014.12.20
티켓주도개발TiDD 라....  (0) 2014.12.20

20141130 SpringSprout’s Last Conference

침대에서 뭉기적거리다가 일어나 눈을 뜨니 10시 반.
습관적으로 열어본 스마트폰에 올라와 있는 일정알림.
봄싹의 컨퍼런스가 있다는 것을 뒤늦게 인지한 나는 부랴부랴 씻고 밥먹고(점심시간 넘겨서 도착할테니, 밥은 먹고가야지)
정자동 네이버 그린팩토리를 향했다.

멀긴 멀다. ㅡ_-);; 전 회사는 1년여를 전철타고 왔다갔다 했었지.

내가 도착했을 때는 이미 세미나 중반쯤 다다른 상황이었다. 접수대에는 익숙한 얼굴들이 있었다.
그중 한 사람은 마지막 까지도 발표자료를 정리하느라 정신없었다.


LG Electronics | LG-F240L | 2014:11:30 13:57:57


LG Electronics | LG-F240L | 2014:11:30 14:09:51


LG Electronics | LG-F240L | 2014:11:30 14:10:57


Front-end development process



  • 발표자: 변정훈(Outsider)
  • 발표자료: Adieu 2014, 봄싹에서 발표한 “프론트엔드 개발프로세스, 어디까지 개선할 수 있나” 발표자료

  • 게으른 개발자
    ‘게으른’과 ‘개발자’의 어울림
    개발자는 “1시간이면 할 일’을 ‘7~8시간동안 하는’ 사람이다.

  • 프론트엔드의 개발자동화는 서버사이드에 비해 많이 뒤쳐져 있었다.
    그러나 프론트엔드도 다양해지기 시작했다. 2~3년 사이에 빠르게 변화했다.
    그 중심에는 node.js 가 있다. 프론트엔드도 자동화된 개발프로세스를 가질 수 있는 환경을 가지게 되었다.
    언어에 대한 ‘커뮤니티, 문화’ 가 형성하는 문화였다?
    자바에서 쓰는 방법, 루비에서 쓰는 방법.
    node.js가 출현하면서 이런 환경이 생겨나기 시작했고, 2~3년의 짧은 기간 동안 일어나면서 앞으로도 빠른 변화가 일어날 것이다.

의존성 관리

  • 사용패턴
    1. 라이브러리 사이트 검색
    2. 프로젝트 폴더에 다운로드
    3. HTML에 코드 추가

      프로젝트, 라이브러리를 추가할 떄마다 반복

  • 패키지 매니저Package manager
    • Bower(http://bower.io, browserify(http://browserify.org)
      • browserify는 npm을 활용한다.

        도구들을 소개하지만 상세한 설명은 생략한다!

    • Bower 사용방법
      • bower install jquery bootstrap
      • 컴포넌트를 사용한다. 명령이 수행된 위치 하위에 component 폴더를 생성한다.
      • 노드의 npm과 유사
  • 패키지 매니저를 사용할 때의 장점
    • 라이브러리 파일을 형상관리에 넣지 않는다.
    • CSS나 JS가 아닌 컴포넌트 단위로 관리한다.
      = 도구들의 최근 배포형태가 JS, CSS 가 하나의 컴포넌트로 묶여 배포되는 형태에서는 ‘컴포넌트Component‘라는 이름이 이해가 된다.
    • 버전만 관리하면 필요에 따라 업데이트하기 쉽다.
    • 보통은 min 버전이 함께 제공한다.

웹서버 실행

  • 사용패턴
    • 로컬 파일을 브라우저에서 실행
    • Apache, nginx에 설정해서
    • WAS 실행(Tomcat 등)
      • 서버의 템플릿파일과 연동하여 보이는 것을 제공하지만,
      • 분리하는 것이 더욱 적합하다고 본다.
  • 빌드도구: Grunt와 Gulp
    • Grunt
      • grunt-contrib-connect, grunt-contrib-watch
  • 장점
    • 프로젝트 별로 필요한 환경을 자동화
    • 프로젝트 내에서 자동화된 환경을 공유
    • 다른 개발도구에 종속되지 않는다.
      • 에디터에 종속적인 기능?
    • CI 서버 등에서 사용할 수 있다.

코드의 품질관리


  • 여러가지 방법!?
    • Lint, Linting
  • recess!?
    recess style.css
    
  • JShint
    jshint util.js
    
  • Flow
    페이스북에서 내놓은 타입체크기
    /* @Flow */
    ...
    flow check hello.js
    

    Grunt를 이용한 설정을 할 수 있다.

Pre-processor

  • sass, less, coffeescript, stylus
  • 전처리자는 빌드가 필요하다. 빌드를 해서 그 결과물을 봐야한다.
    • grunt에 등록해두면 less를 수정할 때마다 자동으로 빌드되어, 브라우저에서는 자동빌드된 less의 결과물로 변경사항을 확인
  • 사용방법
    • 코드 수정
    • 빌드
    • 확인
    • 수정

Unit test

  • Assert: chai
  • test framework: mocha, jasmine
  • test runner: Karma
    • 브라우저에서는 별도로 실행할 방법이 없으나, Karma를 이용하면 실행해볼 수 있다.
    • 브라우저(지정한)를 띄워서 자동으로 불러들여서 실행시킨다.
    • socket.io와 브라우저가 연결되어 있어 자동으로 실행 및 확인이 가능하다.
    • 실행방법
      • 필요한 파일 로딩, socket.io로 쏘고~
  • 작성한 자동화 스크립트는 최대한 써먹자.
    • coveralls, BrowserStack, Gemnasium, SauceLabs

배포

  • 기존의 소스코드를 어떻게 배포할 것인가
  • 어떻게 사용하고 있는가?
    • CSS/JS 병합
    • CSS/JS 압축
    • HTML에서 링크변경
  • grunt
    • usemin
      • 압축대상 파일에 주석으로 build:와 endBuild로 처리가능하다.
      • 이게 JSP 에서도 적용이 될까… 했는데, JSP 하기전에 하면 되지.

정리

프론트엔드의 개발프로세스는 몇년 사이 매우 빠른 속도로 변화했다. node.js의 출현과 함께 npm의 패키지 관리 기능이 가져온 변화가 자바스크립트를 기반으로 하는 프론트엔드에 큰 변화를 가져왔으며, 그 변화는 앞으로도 지속될 것으로 보인다. 프론트엔드쪽에서도 백엔드와 마찬가지로 의존성을 관리하고 빌드, 배포를 자동화하려는 시도가 지속적으로 변화를 야기할 것이다. 다양한 자바스크립트 프레임워크들의 춘추전국시대가 당분간은 계속 될 것으로 보인다.

우선은, 현재에 사용목적에 적합하다고 생각되는 기술을 찾아 그것을 잘 활용하는 것에 집중하는 것만으로도 충반하다고 본다.


Resource Handling in Spring MVC


  • 발표자: 박용권(SK planet)
  • 발표자료: Slideshare
  • Github: resource-handling-in-springmvc

    Spring MVC에서 정적자원(css, js, etc)을 처리해본 경험을 공유
    프론트엔드에서 개발, 빌드된 정적자원을 백엔드에서 어떻게 가져와서 사용할 것인가?

Spring MVC: 리소스 제공(Serving)

  • ResourceHttpRequestHandler
  • 설정 간소화 기능제공
  • 리소스 제공 설정
     registry.addResourceHander("/resources/**").addResourceLocation("/resources/*")
    

    Spring Boot에서는 어떻게 설정할까나? -> classpath:를 붙여!!

     registry.addResourceHander("/resources/**").addResourceLocation("classpath:/resources/*")
    
     public class ResourceWebMvcConfiguration extends WebMvcConfigureAdapter {
     }
    

Resource 인터페이스에 대한 다양한 구현체

  • ServletCOntextResource
  • ClassPathResource
  • FileSystemResource
  • UrlResource
  • etc

캐시 설정이 가능하다.

registry.setCachePeriod(31556926); //캐시 주기는 1년이 적당하다!?
  • 로그를 보라~~
    • 캐시가 있을 때, 브라우저의 행동을 파악
    • 조건부 요청이 날아가는 경우!!

      웹을 확인하려고 하면,

Multi Module Web Application

  • Backend
    • SpringBoot
    • Thymeleaf
  • Frontend
    • NPM
    • Bower
    • Grunt
  • 핑거프린트(캐시에 대한 이야기, 두 파일의 내용, 조합)
  • assemble: hbs 파일들을 엮어서 HTML로…
  • 개발develop과 출시release 두가지의 형태로 처리
  • 개발에서는 usemin의 작업이 필요없다.

프론트엔드가 가출한 이유

  • 의존성관리
  • 사용된 라이브러리들의 모듈화, 조각으로 나누고 조합하여 사용한다.
  • 테스트
  • 빌드 자동화

    프론트엔드와 백엔드의 개발을 분리하여 진행

프론트엔드의 자원을 사용하는 방법

  • 프론트엔드의 의존성 다루기
  • WebJars
    • Client-side 웹 라이브러리를 JAR로 묶어서 제공하는 서비스
    • JVM 기반 빌드도구를 지원
  • Front-end를 빌드 후 jar로 만들기
    • 프론트엔드

개발 배포는 다르다.

  • 프론트엔드: 배포시에는 최적화된 자원을 사용한다.
  • 프론트엔드: 배포시에는 작성중인 css, js 사용
  • 백엔드: 환경에 따른 자원접근방법을 변경
    • Profile, Environment
    • 개발과 배포에 대한 캐시사용 전략도 변경하라~~ +_+)

회고

  • 학습의 요구곡선은 높아졌다.
  • 헨들바 + Thymeleaf만….

정리

코드에 금칠하던 냥겐의 비법공개의 느낌이랄까?

Spring Boot를 사용하면서 여기서 어떻게 더 나아갈까?

라는 고민을 하고 있던 찰라에 ‘희망의 빛’을 주는 발표였다.
지금 프로젝트는 Spring Boot를 기반으로 해서, 프로젝트의 resource 폴더에 static 폴더를 만들어 그 안에 css와 js 파일을 위치시켰는데, 생각해보니까 이녀석들을 최적화작업을 하고 하는 과정이 필요하다는 것을 간과했다. 두 개의 서브프로젝트로 나누고 프론트 프로젝트에서 최적화작업하고 그것을 백엔드 프로젝트에서 참조하는 형태로 가면 될 듯 싶다.


Building REST API Server


라이브 코딩!!

한국스프링의 살아있는 개발자, 백기선님의 발표!

  • 개발자 코드
  • ResponseEntity를 사용하면, HttpStatus 코드를 이용해서 응답상태를 결정지을 수 있어 좋다.

  • 크롬 확장플러그인: Postman 을 통해서 설정정보를 처리

  • DTO

    • static class Request {}
    • static class Response {}
  • ModelMapper 사용

    • Bean 등록
        @Bean
        public ModelMapper modelMapper() {
            return new ModelMapper();
        }
      

      Spock 과 MVC 테스트

  • spock-spring 추가

    • groovy 추가

      @ContextConfiguration(loader=SpringApplicationContextLoader.class, classes = Applications.class)
      @WebApplicationConfiguration
      public ExampleControllerTest extends Specification {
      @Autowired
      WebApplicationContext wac;
      
      def "POST /accounts"() {
           given:
        when:
        then:
      }
      }
      

      JSON으로 리턴할 때는 ObjectMapper(By Jackson)를 등록

  • Controller에 대한 테스트는 Spock를 사용해보자.

@Valid와 검증

  • 컨트롤러에서 @Valid ExampleDto exampleDto, BindingResult bindingResult 처리

스프링시큐리티 추가

  • starter-spring-security
  • Application을 재가동 시키면 스프링시큐리티가 켜져있다.
  • config 파일을 만들어서 WebSecurityConfigureAdapter를 생성
    @Configuration
    @EnableWebSecurity
    public class WebSecurityConfig extends WebSecurityConfigureAdapter {
      ..
      http.csrf().disabled();
      http.authorizeRequest()
      ...
    }
    
  • UserDetails 구현

    public class AccountUserDetails extends UserDetails {
    }
    
  • UserDetails를 제공할 서비스 생성

    @Service
    public AccountUserDetailsService implements UserDetailsService {
      @Autowired
      AccountRepository repository;
    }
    
  • WebSecurityConfig 에 userDetails 설정

    @Autowired AccountUserDetailService
    coufigure(AuthenBuilder auth) {
    ...
    }
    
  • 비밀번호 암호화
    @Bean
    public PasswordEncoder passwordEncoder() {
      return new StandardPasswordEncoder();
    }
    

패키징 및 배포

war로 패포하기 위해서는

  • build.gradle 혹은 pom.xml provide() 선언하고,
  • SpringBootServletInitializer 구현한 클래스를 선언하고
    public class ServletInitializer extends SpringBootServletInitializer {
      @Override
      protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
          return application.sources(Application.class);
      }
    }
    
    만들어진 war를 배포할 수 있다.

● 정리

SpringBoot는 스프링을 사용하는 사람이라면 결국 끌려들어올 수밖에 없는 블랙홀과 같은 강한 마력을 가지고 있다.
물론 이것을 바탕으로 보다 강력한 힘을 사용하기 위해서는 스프링에 대한 프레임워크가 어떻게 동작하는지 이해하고, 자바가 가지고 있는 언어의 특징을 이해하는 등의 학습이 필요하지만,

먼저 만들고 본다!

라는 논리로 보자면 Spring boot는 스프링을 기반으로 한 프로젝트를 구성할 때 부딪힐 수밖에 없는 설정의 벽을 많이 낮춰주는 것이 사실이다. 기선님의 라이브 코딩은 언제나 역동적이다. 이제는 능수능란하게 청중들과 반응하며 코딩을 이끌어가는 모습에서 라이브코딩의 관록을 느낀다.

따라올테면 따라와 봐.

라며 라이브코딩을 따라오던 자와의 신경전 또한 흥미로웠다. ㅎㅎ
스프링 시큐리티를 활용하는 방법에 대해서 힌트를 얻었다. 가볍게 던지는 이야기들 속에서 JavaConfig에 대한 막연했던 것들이 가볍게 정리되며 해소되는 이런 느낌 때문에 이런 컨퍼런스를 오게 되는 것이 아닐까?


Adieu, SpringSprout.



  • 2008.08 스프링 스터디를 하기 위해 모여든 사람들.
  • 2008.08.31. 스프링 첫스터디 진행
  • 2009.03 KSUG 에서 봄싹 독립
  • 2009.06 봄싹 첫 MT
  • 2009.08.27 아지트가 생기다. 봄싹 사이트
  • 2010.07 봄싹을 떠나는 윤군!
  • 2010.11 ~2011.11 봄싹 스웨거 스터디 개설, 기존 스터디에 문제가 생기다.
    • 봄싹 스웨거
  • 2012.06 기선, 스터디 은퇴
  • 2014.08.20 봄싹이 싹을 피워 무럭무럭 자라서 멋진 이들로 제어났다.
  • 2014.11.30 봄싹 세미나, Adieu, 2014

○ 총정리


LG Electronics | LG-F240L | 2014:11:30 18:44:15


LG Electronics | LG-F240L | 2014:11:30 18:45:09


끊임없이 공부하고 코드로 만들어내는 배움의 장이었던 봄싹의 활동이 2014년 11월 30일, 그 대단원의 막을 내렸다.

이름처럼 새싹개발자들이 무럭무럭 성장하여 자신의 분야에서 한몫하는 멋진 개발자들로 성장하였다. 그들은 앞으로도 꾸준하게 개발자의 길을 걷고 있을 것이라 생각한다. ^^

나도 2011년도엔가 잠시 봄싹 스터디에 합류했다가 3주 정도 참여했다가 꼬리를 내리고 도망간 하드코어한 스터디그룹이었는데…
멋지게 유종의 미를 거둔, 봄싹의 마지막 컨퍼런스를 보면서 많은 사람들이 무엇인가를 얻어갔다는 것만으로도 충분히 보람찬 것이지 않을까?

모두 수고하셨습니다. ^^ 많은 가르침을 받았습니다.


저작자 표시
신고

+ Recent posts