Java 적응기 04 - Spring

C++로 개발하면서 답답했던 점은 바로 API 서버 개발에 편의성이 떨어진다는 점이었다.

C++에는 킬러 웹 프레임워크가 없고, 생산성이 떨어지는 언어라는 단점마저 존재한다. (최적화에 강할 뿐)

실제 지표상으로 C++이나 C언어로 된 REST API 프레임워크는 수도 적고, 사용자도 적은 편이지만 그를 넘어서는 장벽으로는 편견도 크다고 생각한다.

의외로 MS에서 제공하는 rest sdk는 괜찮은 완성도를 보여준다.

https://github.com/Microsoft/cpprestsdk/wiki

이 편견이 얼마나 크냐하면, C언어로 API 서버 개발기는 찬사와 함께 눈초리도 받았을 정도다.

http://bigmatch.i-um.net/2014/01/21/developing-api-with-c/

내 경험상 다른 언어들 (Rails, Django, Entity Framework)의 프레임워크를 접해봤지만 언어 차원을 넘어서는 어마어마한 유틸리티가 지원되지는 않았었다.

특히나 프레임워크에서 제공되는 기반 기능이 압도적으로 중요했는데, 이런 기능에 한정 짓는다면 C++ Rest API 서버 개발도 그리 나쁘지 않다. (언어의 생산성은 별개의 문제로 치부한다면 말이다)

자바를 주 언어로 선택하고, 웹 서버를 개발함에 있어 스프링 부트가 무난한 선택지였다 보니 나도 자연스레 익히고 사용하게 되었다.

내가 느낀 스프링의 단점

  1. Annotation 도배.
    • C#에서 property로 풀었던 문제를 annotation으로 지원하거나 해결하려는 경우가 많음.
  2. 에러메시지가 비 직관적인 경우가 많음.
    • 근본적 원인이 메시지 마지막에 나오지 않아, 어느 부분이 원인인지 찾는 데에 애로사항이 있다.
  3. 버전에 따라 크게 다른 스펙
    • 그만큼 많은 개선과 향상이 있다는 이야기지만, 변화가 꽤 잦고 위에 언급한대로 에러 메시지가 비직관적이라서 바뀐 스펙에 대한 체크를 세심하게 해야 한다.

내가 느낀 스프링의 장점

  1. Annotation과 라이브러리 지원을 통한 다양한 패턴 지원
    • 1번 단점과 상반되는 점이지만, 나는 장점도 많다고 생각한다.
    • 생산성 향상에 의미가 있다. 혹자는 Annotation이 Superb한 기능이라서 위험하고 각종 제약을 무시한다지만, 적절한 사용에서의 장점마저 희석시킬 정도는 아니라고 생각한다.
  2. 있을건 다 있는 라이브러리 풀
    • 진짜 거의 다 있다. 메이저한 라이브러리들은 당연스레 자바 & 스프링을 지원한다.
    • 특히 자연스레 스프링과 연동될거라 예상해서인지, 호환성 테스트가 완료된 점은 아주 맘에 들었다.
  3. 오류에 대한 글이 많다.
    • 메이저해졌다지만, 생각보다 python, ruby의 gem에서 발생하는 오류는 stackoverflow등지에서의 글이 없는 경우가 많다.
      • Rust나 go는 몇배는 더하고
      • 이런 오류 메시지에 대한 기본적인 삽질에서 마저 참고가 될 만한 레퍼런스가 아주 많다.
      • Node.js와 비견될 만한 사용자 풀의 유일한 프레임워크는 spring이란 점은 공감한다.
  4. 개발자 풀도 많다.
    • 다른 웹 프레임워크에 비해, 특히 국내는 압도적으로 스프링 사용자가 많고 지원자도 많다.
    • 그만큼 학습 코스트도 낮다는 점도 장점이라고 볼 수 있다.
  5. 사용자가 많은 만큼 많이 다듬어져있다.
    • MyBatis, JPA 등이 실무에서 다양한 런타임 이슈와 개념적 이슈를 모두 해결한 경험을 가진 훌륭한 라이브러리다.
    • 사실상 대다수의 라이브러리가 초기버전에는 문제의 소지나, 놓친 문제들로 인한 리스크를 안고 있는데 이런 문제가 많이 해결되어있다.

사실 자바가 표현력에 부족함은 여전히 여러 부분 존재함에도, 스프링 자체는 오히려 이를 annotation과 라이브러리 제공 기능으로 풀어낸 느낌이 강했다.

자바+Netty+Akka를 사용하며 느꼈던 아쉬움이 스프링에 대한 이해도가 높아질 수록 충족 됐음이 이를 반증한다고 생각한다.

의외로 이클립스가 쓸 만하다는 것은 자바 환경 기준인 거 아닌가 라는 생각이 들만큼 편의성 있게끔 만들어주는 plugin이 많았다는 점도 한 몫하지 않나 싶다.

지적 받아들이기

대 다수의 사람들은 생각이 다르다. 내 경험상 케미가 맞는다는 사람들 사이에서도 디테일한 부분에선 차이가 많았다. 그럼에도 그들 사이에서는 열린 소통이 많았다.

그 것이 가능했던 데에는 몇가지 생각이 근간이 되는 경우가 많았다.

1. 서로 간에 존중이 있다.

이견을 표하는 사람과, 그것을 받아들이는 사람 사이에 존중이 있다. 나보다 더 실력이 좋다고 느끼던, 경험이 많다고 느끼던, 그 사람과 개인적인 친분이 있거나 하는 이유 들로 존중이 있었을 때 서로 간의 발전적 대화로 이어지는 경우가 많았다.

2. 기술적 발전에 욕심이 있다.

이 케이스는 반대로 기술적 발전에 관심이 많아도 고집이 강해, 다른 사람의 이견을 전혀 들으려 하지 않는 성향을 보인 경우도 많았다.

그럼에도 위에 언급한 존중이란 생각이 개입되면 그런 고집 불통이 누그러지곤 했다. 지금 받은 지적을 바탕으로 내가 성장 할 수 있는지를 느끼면, 그 지적에 반감이 있어도 받아들이는 케이스가 많았다.

3. 내가 틀릴 수 있다.

내 생각과 다를 수 있다는 것을 인정해야 한다. 2번의 단점에 대한 보완인데, 내 생각과 판단과 경험에 대한 확신보다는 의문을 가져야 한다. 그 의문을 확신으로 가져다 주기까지의 과정은 근거여야 하는데, 이 근거를 만들기 쉬운 우리 프로그래머들은 좀 더 합리적인 사람이 될 수 있는 사람들이다.

내가 전에 얘기한 것 처럼 내가 본 가장 많이 들은 근거는 내가 해봤는데, 내 경험상, 남들에 많이 하니까 였다.

이런 근거들론 누군가를 설득 할 수 없다.

아니 정확히는 이런 어설픈 근거에 설득 당하는 사람이 많으니 문제다.

경험에 의한 근거는 현재 상황과 근거의 상황에 대한 명확한 파악이 선행 되어야 하는데, 그 과정을 잘 해낼 수 있다면 보통은 경험에 의한 근거를 제시할 필요가 없어지는 경우가 많다.


실제로 내가 낸 결론과 이견이 둘다 설득력 있는 상황일 때가 가장 논란이 커진다.

서로가 각기 다른 장점을 내포하고 있는 주장을 할 때, 타인의 의견보다는 자신의 의견에 더 많은 가치를 두는 것이 일반적인데 이 때 다른 사람의 의견에 대해 고민해볼 필요가 있다.

그 의견을 내 판단과 비슷한 가치를 두고 고민 할 수 있다면, 생각의 폭이 넓어지는 경우를 많이 봤다. 저 의견에 근거는 A이고, 내 생각의 근거는 B다. A를 선택하면 C를 얻을 수 있지만, D라는 단점이 있고, B를 선택하면 E라는 단점이 있지만, F라는 장점을 얻을 수 있다.

이런 장점과 단점을 수치화해서 비교할 수 있다면 합리적 판단에 도달 할 수 있다.

내 의견과 다른 사람의 의견을 동일 선상에서 (수치화 할 때의 기준에 차이는 있겠지만) 이런 고민을 할 수 있는 시점 부터가 지적 받아들이기가 가능 해졌다는 의미다.

이 글의 제목을 정하면서 했던 고민은, 다른 사람의 의견에 대해서 적극적으로 받아들이라는 의미로 전달되면 어떻게 하지? 였다.

시작은 간단하다. 다른 사람의 의견을 고민해보는 것 그거부터 시작하면 된다.

하지만 쉽지 않다. 특히 부정적인 의견에 대해서는 그게 더 어렵다.

부정적인 의견에 대해서 모두를 심각하게 고민하고 받아들이긴 특히나 어렵다.

어떤 이유에서 건 악의적인 사람, 근거 없는 네거티브를 가진 사람은 분명히 꽤나 많이 존재한다.

받아 들어야 할 부정적 의견은, 자신의 의견에 근거를 제시하며, 그 근거의 장단점을 설명하고 그 장점이 내 의견의 단점을 커버할 때 귀 기울이면 된다.

대안이 없는 지적 까지 고민하는 노력할 필요는 없다는 것이 내 생각이다.


나 역시 지적 받아들이기가 쉽지 않았고, 아직도 쉽지 않다.

하지만 이전보다 방어적인 태도는 확실히 줄었다. 내가 이 결론에 도달하기 위한 노력과, 확신에 대한 높은 가치 부여보다는, 결과물이 더 중요해졌기 때문이다.

그러기 위해서 귀를 열려고 노력하고 있고, 이전보다 다른 의견에 대해 더 많이 귀 기울이고, 반영할 수 있게 됐다.

위에서 언급한대로 근거없이 반대하거나, 목적성 없는 부정적인 의견을 들을 필요는 없다.

쓴 약이 몸에 좋다고, 듣기 좋은 말보다는, 듣기 거북한 말일 수록 고민해보는 시간을 가져보는 것이 나을 때가 많았다.

듣기 거북한 이유가 무엇이며, 그 것이 내 심리적 요인이나, 내 노력에 대한 높은 가치 부여 때문은 아닐지 고민해보자.

기록 집착

당시엔 잘 느끼지 못했지만 지금에 와서 돌이켜보면, 10대 20대때 참 기억력이 좋았다. 수없이 쏟아지던 업무 요청들을 암기로도 기억했다. (물론 이 때도 동시 다발적 요청은 메모를 안해두면 잊긴 했지만, 암기로 기억하면서도 수많은 일을 잘 처리했다.)

한 해 두 해 시간이 가며 기억력은 감퇴했고, 어느새 두가지 이상의 일을 할 때마다 놓치는 일이 늘었다.

그러다 보니 노트 필기부터 다시 시작했다.

노트 필기의 단점은 기록 양이 많아 졌을 때 색인 기능이나 카테고리화 해서 정리하기 어렵다 보니 한계가 있었다.

대략 2008년경 나는 에버노트로 디지털 메모를 시작했다.

처음 메모는 메모장 대신이었다. 메모장을 들고 다니기 싫었기 때문이었던 게 가장 큰 이유였다.

두번째 시작한 용도는 갈무리였다. 좋은 글을 갈무리 해 두고, 다시 보기 위해서 였다.

북마크로 관리하는 것도 좋지만, 그 당시나 지금이나 좋은 글임에도 사이트 폐쇄나 글 삭제가 빈번하기에 갈무리를 해 두는 게 안전하다.

그리고 글을 쓰기 시작했다. 2008년 티스토리를 시작으로 올해까지 10년여간 지속적인 글쓰기를 할 곳이 필요했다.

내가 쓴 모든 글을 블로그에 올리지는 못했지만, 그 기록들은 내 노트 여기저기에 남아있다.

그리고 어느새 업무 일지를 쓰기 시작했다. 하루 하루를 내가 어떻게 생활했는지 남기고 싶어 졌고, 얼마 만큼씩 나아지고 있는지 정확한 근거와 기록 위에서 느끼고 싶었기 때문이다.

그리고 2012년경 위키를 쓰기 시작했다. 처음엔 그저 위키에 작성된 내용을 보강하는 것이 시작이었지만, 이후엔 위키를 정리하는 것이 뿌듯해 졌고 어느새 나도 기록광이 되어가고 있었다.

그렇게 기록이 늘어갈 수록 놓치는 것이 줄어들었다. 그걸 몸소 느끼자 기록에 집착하게 됐다.

이전에 내가 하고 싶은 코딩을 방해하는 것처럼 느껴지던 회의마저 기록의 공간이 됐다. 회의에서 기록한 내용이 잘 정리되어 있으니, 내 텐션이 회의 내용을 복기하고 싶어 질 때 복기 하면 되기 때문이다.

다른 업무도 마찬가지다. 기존에 진행했던 업무의 연장선 혹은 멀지 않은 미래에 해야 할 업무에 대한 검토, 버그 수정 요청 등 크고 작은 인터럽트는 모두 업무의 방해요소이지만, 해소하기 쉽지 않은 인정해야 하는 현실인 경우가 많다.

한번에 한가지 업무만 몰입해서 진행할 수 없다면, 언제 태스크를 전환해도 무리가 없게끔 현황과 목표를 상시 기록하다 보니 유연한 태스크 전환이 가능했다.

업무에 대한 기록에 또 다른 장점은 개선 사항을 짚어 내기 쉽다. 내가 어떤 생각과 어떤 고찰 끝에 내린 결정인지를 회고 할 때 반성해야 될 상황인지, 적절한 판단을 내린 것인지 명확히 알 수 있었다.

좋은 기록은 언제 다시 돌아봐도 쉽게 찾아 볼 수 있어야 한다. 만약 기록한 대로 내가 무언가를 할 수 없다면 잘못 정리된 내용이다. 이를 완벽하게, 적은 공수로 기록하기 위해 지금도 지속적인 개선과 반복 중이다.

내 정리 과정에 대해 설명하자면, 나는 최소 세번의 과정으로 정리를 한다.

  1. 진행 상황을 나열하며, 가능하다면 소요 시간을 디테일하게 기록.
  2. 나열한 기록을 기반으로, 카테고리화 해서 정리.
  3. 카테고리화 해서 정리한 내용을 다른 기존 문서에 병합해야 하는지, 새 카테고리를 만들어야 하는지 검토 하고 정리.

아직 부족하지만 이런 저런 이유로 나는 기록 집착자가 됐다. 무리하지 않는 선에서 얼마나 기록을 더 많이 할 수 있는지, 또 언제든 잘 찾아 볼 수 있게, 반성할 수 있게, 개선 할 수 있게 쓸 수 있을지 고민하고 있다.

기록 집착이란 제목을 붙였지만, 사실상 기록과 정리에 대한 이야기다.

늘어 놓는 기록이 아닌, 정리되는 기록을 위한 좋은 생각과 아이디어를 위해 오늘도 고민하며, 이 글을 마친다.

(서평) 사소한 차이

사소한 차이. 제목에서 알려주듯 작은 차이가 누적되어 큰 차이를 만든 다는 것이 핵심인 책이다.

2. 이름과 직위를 정확하게 부르기

직위가 없다면 모를까 있다면 불러 주는 것이 좋다. 특히 누구는 직위를 불러주고, 누군가는 이름을 부른다는 차별 행위를 하는 걸 누군가 보게된다면, 그사람에 대한 인식이 나빠지는 계기가 될 수 있다.

12. 신용카드 잘라 버리기

어지간히 절제력이 좋지 않다면, 소비를 제어하기 어렵다. 쓸 수 있는 돈과 그렇지 않은 돈을 관리하기 어렵기 때문.

10. 처음 만난 사람에게 일주일 안에 이메일 보내기
18. 매일 다른 사람과 점심 먹기
9. 큰 소리로 먼저 인사하기

이런건…음 의미가 있을지 몰라도 실천하기 나에겐 아주 많이 어려운 일이다. 매일 다른사람과 밥먹기를 불편해 하지 않을 주변 사람도 있어야할테고.

14. 3초 기다린 후에 대답하기
15. 맞장구치면서 듣기

리액션은 나를 대하는 사람을 즐겁게하고, 3초 기다린 후에는 좀 더 신중하고 현명한 답변에 근접해 지는 경우가 많을 것이다.

23. 잠자리에 들기 5분 전, 스스로에게 질문 던지기

오늘 하루가 어땠는지 회고하는 습관을 가지자는 의미인데, 꽤나 나쁘지 않다. 내일 뭘 할지, 오늘 뭘 했는지, 잘했는지 아닌지 회고 하는 것은 언제나 긍정적이다.

30. 모르는 척 해주기

나쁜 일일수록 넘어가 주는 것이 좋을 때가 많다. 물론 그 일이 나쁘다는 것을 모른다면 알려줄 필요가 있을 수도 있겠다.

31. 안 좋은 이야기는 이메일로 보내지 않기

전쟁을 하겠다는 마음이 아니고서야, 최대한 네거티브한 소통은 안하는게 좋다. 심지어 모두가 보라고 보란듯이 기록 남기는 일은 더더욱.

32. 없는 사람 칭찬하기

이것도 참 어려운데, 없는 사람을 칭찬하는 습관을 들이다보면 나도 그사람이 본래보다 더 좋아질 거고, 그 얘기를 같이 들은 사람도 나에 대한 인상이 좋아 질 것이다.

33. 나에게 고맙다고 말하기

아주 중요하다. 내가 나를 사랑하지 않으면 남도 나를 사랑하지 않을 것이다.

아이러니 하게도 가장 공감이 간 것은

28. 가만 앉아 사람 구경하기

이 부분이었는데, 마음의 여유가 부족해 주변을 둘려보는 여유가 부족했다.

항상 무언가를 보고 있는 내 자신이, 할 것을 수도 없이 만들며 사는 내 자신을 돌아보는 데에 중요한 내용이었다.

25. 종이 신문 꼼꼼하게 읽기

종이 신문이 굳이 아니더라도, 기사나 보고서, 참고 문서, 책을 꼼꼼히 읽는 습관이 중요 하다.

26. 책 한 권 가지고 다니기

ebook을 많이 사다보니 수십권은 가지고 다니는 것 같다. 워낙 할거리가 많다보니 책에 손이 가는 빈도가 전보다 줄었는데, 좀 더 늘리려는 노력을 해야 겠다.

24. 5분 안에 꿈 일기 쓰기

꿈이 깨고 나서도 기억이 나는 빈도가 적다. 그래서 지키기 어려운 부분.

22. 모든 대답은 ‘예’로 시작하기

꽤나 의미 깊다고 생각한다. 나는 우려가 많은, 걱정이 많은 사람이 일을 잘한다고 본다.

하지만 해결책도 가지고 있는 사람은 더 좋다고 본다.

그럼에도 항상 좋은 해결책을 들고 있기 보다는 어떻게 하지에 대한 고민이 많다보니,

아니오, 그런데요, 그렇지만 이라는 얘길 먼저 꺼내게 된다.

실제 내가 관리자를 할 때도, 해결책 까지 들고 오는 친구들이 좋았음에도 나 역시 쉽지 않은 문제다.

아로새기고 싶다.

자기 개발서는 워낙에 많고, 뜬구름 잡는 소리가 많다고 거부하시는 경우도 많지만 나는 다르게 생각한다.

좋은 가르침이라면 많이 들어도, 자주 들어도, 조금은 내 상황과 달라도 받아들이고 반영하면 되는 문제다.

시대가 바뀌어서 적용하기 애매한 것들이 있다면 그 의미가 온전히 유지되도록 바꿔서 실천하면 충분히 의미가 있을 법한 내용들이 많다.

그 것들을 선별해서 잘 받아들이고 적용해나가면 나만의 좋은 습관들에 대해서 더 잘 정리해서 전달 할 수 있지 않을까 생각한다.


핵심 내용 요약

  1. 하기 싫은 일 3분만 더 하기
  2. 이름과 직위를 정확하게 부르기
  3. 가족과 함께 아침밥 먹기
  4. 맨 앞자리에 앉기
  5. 늘 펜을 가지고 다니기
  6. 핸드폰 바탕화면에 목표 띄워 놓기
  7. 약속 시간 15분 전에 도착하기
  8. 노는 계획 먼저 세우기
  9. 큰 소리로 먼저 인사하기
  10. 처음 만난 사람에게 일주일 안에 이메일 보내기
  11. 마감시한 이틀 앞당기기
  12. 신용카드 잘라 버리기
  13. 평생의 동반자, 취미 만들기
  14. 3초 기다린 후에 대답하기
  15. 맞장구치면서 듣기
  16. 닫힘 버튼 누르지 않기
  17. 한 숟가락 덜어 내고 밥 먹기
  18. 매일 다른 사람과 점심 먹기
  19. 흘리지 않고 밥 먹기
  20. 하루 30분 걷거나 뛰기
  21. 배웅은 엘리베이터 앞에서 하기
  22. 모든 대답은 ‘예’로 시작하기
  23. 잠자리에 들기 5분 전, 스스로에게 질문 던지기
  24. 5분 안에 꿈 일기 쓰기
  25. 종이 신문 꼼꼼하게 읽기
  26. 책 한 권 가지고 다니기
  27. 일주일에 한 번 다른 길로 출퇴근하기
  28. 가만 앉아 사람 구경하기
  29. 컴퓨터 끄고 퇴근하기
  30. 모르는 척 해주기
  31. 안 좋은 이야기는 이메일로 보내지 않기
  32. 없는 사람 칭찬하기
  33. 나에게 고맙다고 말하기

(서평) Head First Software Development

지금은 한층 사그러든지 오래지만, 애자일 개발 방법론은 한 시대를 뒤흔들어 놓았던 적도 있었다.

드리밍 인 코드에서 언급한 것 처럼 개발 방법론은 진리가 아니다.

그런 여러가지 방법론 중 현재 상황에 맞는 것을 잘 선별하고, 변형하고, 가다듬어서 적용하는 것이 매우 중요하다.

이 책이 애자일 방법론 다룬 것은 아니다.

사실상 전반적으로, 능률적인 프로그래머, Complete Complete, 실용주의 프로그래머처럼 실천 지침서 부류인데, 그 중 유독 애자일 방법론에 근접해 있는 책이었다.

아는 분들은 아시겠지만, Head First 시리즈가 그렇듯 그림이 아주 많은데, 입문서로썬 적격이지만 몰입을 방해하는 면도 있어 개인적으론 아쉬움이 들었다. (그래서 요새 Head First 시리즈가 안나오는건가?)

다루고 있는 내용 자체는 전체 개발 사이클 한 흐름을 보여주며, 고객과 어떻게 소통해야 하는가, 얼마나 솔직해야 하는가를 설명해준다.

사실상 장황한 내용들이지만 핵심은 변화에 유연하고, 예측 가능하면서도, 완성도 있고, 정말 필요하고 사용 될 것을 만들자를 부연설명하고 있다.

그런 제품을 만들기 위해 기울여야 하는 노력에 이 책의 조금은 장황한 설명이 도움이 될거라고 생각한다.

우리는 대충 돌아가는 소프트웨어를 만드는 대충 프로그래머가 아닌, 장인 정신으로 훌륭한 소프트웨어를 만들어 내야 하는 일류 프로그래머여야 하기 때문이다.

많은 주제를 다루고 있지만, 이 또한 실천 예제나 깊이는 부족하다.

이 책에서 다루고 있는 주제들에 대해서 좀 더 심도 있게 파고들고 싶다면, 아래 서적들을 참고하면 좋겠다.

참고 서적

  • 테스트 주도 개발
  • 클린 소프트웨어
  • Code Complete
  • 리팩토링

출간 된지 꽤나 오래된 책 (2008년)이고, 절판되서 구하긴 쉽지 않을 책이지만, 소프트웨어 품질 향상과 개발팀 문화에 관심이 많다면 꼭 읽어봤으면 하는 책이다.