사내 내부 개발자 교육 필요한가?

사내 내부 개발자 교육 필요한가?

한달에 두어개 정도 블로그 포스트를 작성하는게 이렇게 어려울 줄이야.. 계속 되는 과업 변경과 끊임없는 성능개선 사이드 프로젝트 그리고 사내 내부 개발자 교육 준비..

회사 일이 바빠지니 집안에도 또 소홀히 되는 나쁜 습관들이 또 고개를 쳐들고 슬금슬금 나오기 시작했다.

호랑이 굴에 아주 제대로 빠져있다 이제 겨우 좀 숨 쉴 만하니 미뤄 왔던 블로그질을 몸에 배게 습관이 되도록 억지로라도 계획을 좀 짜야 겠다는 생각이 든다.

이번 포스팅은 사내 개발자 교육필요성에 대해서 얘기해보려 한다.

다니고 있는 회사에서 AA팀 팀장을 맡기 오래전 부터 내가 수행하고 있는 프로젝트에는 그래도 꾸준히 내부 개발자 교육을 수행하고 있다.

이전 포스팅에서 진행했던 기반시스템 관련된 교육과 개발표준(컨벤션, 개발환경, 개발표준가이드 등), 수행하는 프로젝트마다 레거시 시스템의 프레임워크가 있다면 약간의 학습 후 교육을 실시했다.

그러다가 AA팀으로 배속받고 나서는 전사 개발자를 대상으로 하는 교육을 일년에 한번(대부분 스프링이나 전자정부 프레임워크)씩은 진행하고 있는 것 같다.

사실 최근의 교육은 자의로 내가 필요해서 교육을 실시하기보단 회사 차원에서 어떤 정책에 의하여 반강제로 교육을 실시하다보니 듣는 수강생들도 그렇고 교육하는 내부 강사도 그렇고 배움이나 가르침에 대한 강력한 동기부여가 되지 않는다는 기분이다.

무엇이 문제가 되는가?

프로야구 선수가 구단에서 공치는 법이나 포구하는 법에 대해 배우는가?

혹은 본인 몸관리를 위한 기초적인 방법을 가르쳐주는가?

아마도 프로이기 때문에 프로의식을 가지고 기본적인 본인의 몸관리나 본인에 맞는 타격 매카니즘이라던지 야구에서 쓰일 수 있는 스킬들은 본인들이 우선적으로 신경써야 할 부분이고 스스로 관리를 철저히 할 것이다.

물론 그렇지 않은 선수도 있을 것이다. 그런 선수들은 신문이나 뉴스에서 "추락! 비운의 *** 선수 몸관리 실패 후 나락으로~"라는 제목의 타이틀로 기억되게 마련이다.

개발자 세계에서도 대동소이 할 것 같다. 어차피 개발자도 구단(회사)와 계약하고 연봉 받고 일 잘하면 인센티브도 받고 우리가 사는 세계도 프로의 세계이다.

Java의 기초나 Spring Framework(혹은 전자정부 프레임워크.. 이건 왜 만든거니..)의 MVC Framework 개발 과정에 대한 교육 등은 어찌 보면 야구선수가 공치는 법을 구단에서 가르쳐 주는 교육을 여는거나 마찬가지 아니겠는가.

그렇다면 어떤 내부 교육이 효과적일까?

Code Convention, Naming Rule로 시작해서 여러 사람이 함께 개발함에 있어서 혼돈을 줄이고 생산성을 높이기 위한 가이드 수준의 개발과 관련된 표준 교육은 반드시 필요하다고 생각된다.

예를 들면 아래의 교육들이 대표적일 것 같다.

  • Code Convention
  • Naming Rule
  • 공통 개발 원칙
  • 개발 환경설정 가이드
  • 테스트 개발 가이드
  • 형상관리(디렉토리 구조 포함), CI(통합빌드) 가이드
  • 개발 표준 가이드
  • 개발 보안 가이드

물론 이런식의 가이드는 문서화가 아주 잘되어 있다면(?) 굳이 교육을 통해 진행하지는 않아도 상관은 없겠지만...

경험 상 문서로만 가이드하면 대부분 잘 지키지 않았다. (wiki로 다 만들어놔도 잘 찾아보지 않는다.) 그래서 표준과 관련된 교육은 Eye to Eye로 주입교육이 필요할 것 같다는 개인적인 생각이 든다.

자유로운 개발 문화 지원이 필요하다.

그 외의 교육이 필요한 부분들은 내부 세미나나 스터디 모임처럼 자유로운 분위기에서 배움의 열정을 쏟아 부을 수 있는 여건을 만들어 주는 것이 훨씬 더 효과적일 것으로 본다.

외부 세미나 참가라던지 외부 전문 교육, 외부 전문 강사 초빙, 개발서적 구입 지원 등을 지원해 주고 눈치보지 않는 자유로운 교육 문화를 만드는 것이 훨씬 개발자 개개인의 능력 향상에 더 도움이 될 것 같다.

무엇보다 개발자 스스로 뭔가를 이루어내겠다고 하고는 의지를 복돋을 있는 동기부여 장치는 반드시 필요하다고 본다.

그래서 사내에서 강의 했던 자료들

작년까진 model 1방식부터 model 2로 변환 그리고 Spring MVC를 활용한 방식으로 기본적인 웹 개발 교육을 신입/대리 직원을 대상으로 교육했었는데 오히려 이런 교육은 필요한 사람이 외부에서 전문 강사에게 듣던 인터넷을 찾아보던 책을 보던 본인의 열정 가지고 공부 할 수 있도록 동기부여를 해주자는 측면에서 일부 교육들은 조금 다르게 구성했었다.

각종 시스템 오픈과 계속되는 트러블 슈팅으로 바쁜 와중에서도 교육 준비해주느라 고생 해준 OPENSNS AA팀 여러분들에게 감사의 말씀을 전한다. 수고 했어 친구들!

누군가에게는 별것 아닌 지식이겠지만, 또 누군가에게는 꼭 필요했던 내용이길 바라며 이번 교육에서 교육했던 자료를 공개해 본다.

ps.
많은 분들이 들려주시는 건 아니지만 다양한 의견을 청취하고 변화하고픈 욕구가 있으니 어떤 내용이든 댓글로 피드백 주시면 열심히 듣겠습니다.

Softskills from 혁 권
Agile SW 개발 from 혁 권
SVN에서 GIT으로 전환하기 from 재윤 정
Java performance and trouble shooting from Anna Choi
Sonarqube 20160509 from 영석 조

Read more

나의 프로그래밍 폰트 사용 일대기

나의 프로그래밍 폰트 사용 일대기

시작은 2003년 이제 막 프로그래머로써 첫발을 내딛을 때부터 나는 프로그래밍 폰트에 대해서 관심이 많은 편이었다. 화면 붙잡고 매일 글자들과 씨름하는 직업이다보니 당연하게도 좀더 눈에 잘 보이고, 보기에 좀더 미려하고 조화스러운 폰트를 찾는 것이 어찌보면 약간 본능(?)적으로 관심을 가졌던게 아닌가 싶기도 하고 말이다. 최근까지도 이 주체할 수 없는 본능에 따라

By Kevin H. Kwon
Istio 를 통한 path(url) 기반 Local Rate Limit 적용

Istio 를 통한 path(url) 기반 Local Rate Limit 적용

몇 년 전인지는 기억나진 않지만 Rate Limit 적용은 항상 애플리케이션 쪽에서 처리하는 것이 당연하다는 것이 주된 의견이었다. 그래서 그때 당시 Bucket4J 를 통해서 Spring 쪽에서 처리하고 했던 기억이 있다. 이제는 당연하게도 Istio와 같은 Service Mesh쪽에서 처리하는 것이 응당 맞다고 생각되는 것이 개발 세상이 이제 점점 더 클라우드향으로 이동된다는 느낌이다. 강력한

By Kevin H. Kwon
Istio를 통한 header기반 API 라우팅/호출 시 cors preflight request 이슈 트러블슈팅 기록

Istio를 통한 header기반 API 라우팅/호출 시 cors preflight request 이슈 트러블슈팅 기록

현재 개발하고 있는 일부 컨테이너 기반의 서비스들을 Istio를 통해 서비스들을 구성하고 트래픽을 관리하고 있다. 이때 컨테이너 서비스가 같은 규격이 여러개가 같은 url과 port를 할당 받아서 사용해야는 애로 사항이 있어 Istio에서 header 기반으로 특별한 헤더가 있는 경우에만 라우팅이 될 수 있도록 구성하고 테스트를 진행했었다. Istio Request Routing 예제와 같이 header

By Kevin H. Kwon