시작하며
20년이상 숙련된 시니어 개발자가 겪어온 방법과 모던한 개발부터 학습을 시작한 주니어의 개발경험의 차이가 생김에 따라~
세대간 문화차이와 함께 기술선택에서도 충돌이 발생하게 됩니다.
그래서 오늘날의 개발리더는 과거보다 더 많은 과제에 직면해 있습니다.
- 라떼는 말이야~ 제네릭 그런거 없음 자료구조직접 작성 했다구
- 라떼는 말이야~ GC의 성능을 믿지못해 메모리 관리를 직접했다구
- 라떼는 말이야~ ORM이 있었긴했지만 쿼리실행 계획이 더 중요하다구
장르를 불문하고 메모리를 잘 관리하는 주제가? 엔지니어에게 불필요한 이슈일까요?
최신 블록버스터 SF영화가 CG로 무장되어있지만, 과거로부터 이어진 영화기법및 촬영기법들을
무시하고 있을까요?
이런 고민을 할수 있지만 메모리관리 이야기를 시작하면 어쩌면
주니어개발자가 받아들이는 기술적 거부감에 따라 시니어 꼰대 개발자가 될수도 있습니다.
최근 주니어 개발자에 맥락이 전달되지 않으면 이것을 왜 해야하는지? 꼭 해야하는지? 그렇게 해야하는지? 판단하는 능력이 있으며
맥락이 완성되지 않으체 일이 시작되면 불만으로 표출하기도 합니다. 이것이 항상 나쁘다란 의미는 아닙니다.
이러한 마찰을 해결하고 그 과정속에서 함께 성정해야 하는 시대가 된것같습니다.
시니어는 주니어의 능력을 끌어올리기 위한 임무도 있기때문에 기술만큼 맥락 전달을 위한 노력또한 해야합니다.
이것이 과거 사수역활보다, 수평적 개발문화에서 시니어 역활을하기 힘든 이유이기도 합니다.
과거에는 사수가 책한권 던지면 그것이 무엇인지는 모르지만 주말에 공부해야하는 시대가 있었던것은 분명합니다.
사수를 원하는 주니어에게 현재 시니어가 가진 기술을 전수한다고 받아들일수 있을까요?
이러한 물음에서 이야기를 시작해봅니다.
수평문화에서 시니어가 어느정도 가이드를 할수 있으나 주니어의 능력을 올리는데 책임이 있지는 않습니다.
최근 입사준비하는 신입분들이 가장 많이 하는 이야기가 다음과 같다.
"수평문화가 좋아서 지원했습니다. 사수는 있나요?
엔지니어의 세계는 사실 프로와 아마추어로 분류되며 프로에 가깝게 성장을 하는것에 대한 년차의 기준은 사실 없습니다.
10년차도 아마추어일수있고, 1년차도 프로일수 있습니다.
고정형 사고방식으로 유지보수 10년차 한 개발자의 경우 , 협업과 업무적 경험은 프로일수있으나
자신이 10년동안 다룬 프레임워크를 처음부터 배포까지 직접 하지 못하는 경력자를 수없이 봐왔습니다.
이런경우 엔지니어의 세계에서는 아마추어로 분류됩니다.
반대로 주어진 환경은 동일하지만, 성장형 사고방식으로 최근 기술트렌드를 파악하며 업무외적으로 자기개발을 게을리하지 않는
2년차의 경우 프레임워크에대한 이해를 포함 다양한 개발방법론을 활용한 문제해결능력등 프로에 가까운 개발자가 존재할수 있습니다.
고정형 사고방식이란 성격, 지능 및 창의력은 절대 변하지 않는다는 생각입니다. 사람들은 절대 변하지 않는 특정 능력을 타고난다고 믿는 것이 고정형 사고방식입니다.예를 들어 고정형 사고방식을 가진 사람은 “나는 기술에 재능이 없어”라고 생각합니다.
고정형 사고방식을 가진 사람은 새로운 상황을 자신의 능력을 드러내는 것으로 바라봅니다. 각 상황은 그 사람의 성과에 따라 그 사람이 타고난 기술을 보여주는 테스트가 됩니다.
성과가 좋으면 그 일을 위한 능력을 타고난 것입니다.
성과가 나쁘면 그 일을 위한 능력을 타고난 것이 아닙니다.
그리고는 모든 상황을 내가 할 수 있는 일과 할 수 없는 일로 분류합니다. “예, 할 수 있습니다” 또는 “아니요, 할 수 없습니다”로 상황에 대응합니다.
고착형 사고방식을 갖고 있다는 것은 다른 사람의 인정을 원한다는 뜻이기도 합니다. 이러한 사고방식으로 인해 이미 잘 하고 있는 일에 집착할 수 있고 위험과 자발적 도전은 회피할 수 있습니다. 위험과 자발적 도전은 실패할 가능성이 높고 그 결과 비난받을 가능성도 큽니다. 실험과 위험이 없으면 효과적인 학습과 성장이 안 될 수 있습니다. “내가 성공할까 아니면 실패할까?” 또는 “나는 똑똑한 사람으로 보일까 아니면 부족한 사람으로 보일까?”와 같은 내면의 소리 내면의 소리는 잠재력 개발을 가로막는 장애물입니다.
- 추천 아티컬 -고정형사고방식과 고착형 사고방식
스타트업에서 기술선택의 책임이 있는 리더및 시니어는 다양한것을 고민합니다.
- 기술을 선택하는과정에서 주니어와 함께 의논하고 합의과정이 길어져 선택이 길어지면 개발을 언제 시작할수 있을까요? 빠른결정을 내려야할까요?
- 반대로 그것을 사용해야할 대부분의 주니어가 기술적 선택에 부정적인채로 시작되면 그 프로젝트가 완주할수 있을까요?
- 발전을 원하는 주니어 높은학습곡선 또는 사용하기 쉬운기술 기술선택에 따른 개인의 각기 다른 기회발생등 복합적인 이슈를 어떻게 조율해야할까요?
기술선택을 해야할 책임있는 시니어는 더 많은것을 고민해야하며 단순하게 업계 표준이되어가는 최고의 기술 선택만으로
팀마다 선택해야 할 기술선택은 업계최고가아닌 우리팀이 잘할수 있는것과 함께 기술적 비용도 고려해야하기 때문에
단순하게 한가지 기준만으로 이 문제를 해결할수 없음은 분명합니다.
주니어에서 리더가 되기까지 저의 경험을 경험기준 주제별로 그때의 나로 돌아가 IT주제와함께 이야기를 정리해보았습니다.
현재의 내가 과거의 나에게 보내는 메시지입니다.
시대별 역할 :
- 주니어 : 5년차 미만 ( 2007 ~ 2011 ) - C++
- 시니어 : 10년차 쯤 ( 2017~ ) - C++ / JAVA
- 리더 : 20년차가 가까워지는 즈음 ,현재 ( 2019~ ) - C# / JAVA
신기술과 기술 채택
주니어
젊음은 새로운 기술을 흡수하기에 뛰어날수 있으며, 새로운 기술을 통한 기회를 잡을수 있기때문에 새로운 기술에 적극적이지
않은 시니어에게 불만이 있을수 있습니다. 우리팀이 사용중인 기술은, 내가 조사한 기술만으로 충분히 대체가능하며
그들은 내가 새롭게 발견한 기술적 가치를 이해하지 못하고 사용하기 어려운 과거 기술에 집착 하는것 같았다.
나와 다른 기술을 사용하는 집단을 그들 또는 당신들이라는 용어를 쓰기도 합니다.
팀원이 할수 있는 가치보다 나만이 할수 있는 기술을 이용해 기회를 잡으려는 욕심이 있었습니다.
팀원중 하나가 더 잘하면 팀내 경쟁력이 없다 느꼇기때문에 빠르게 갈아탈려고 합니다.
당시 큰소리내어 적용하고 싶었던 기술스택은 C++/STL 이였으며
선배들은 자료구조및 알고리즘을 모두 직접 작성하여 대용량 트래픽 서버를 만들때였으며
비록 신입이 그 활동에 주도할수 없지만 ,그러한 활동에 참여한것이 현재의 기본기가 되었습니다.
초기 템플릿및 STL은 안정적인 개발문화로 자리잡기까지 조금더 걸렸으며
표준화되지 않은, 심지어 디버깅이 안되는 새로운 기술스택을 ( VC6 + StlPort )
바로 적용하는것은 지금 생각해보면 엄청난 리스크입니다.
좋은 기술과 스택은 사실 빠르게 적용하지 않더라도, 여러스택과 경쟁에 살아남아서
언젠가가 업계의 표준이 되어 그것을 자연스럽게 사용할수 있게됩니다.여전히 최신 기술을 빠르게 도입하는것은 많은 책임과 고민이 필요할수 있습니다.
단순히 내 개발환경에서 작동하는것과 사용자가 있는 그라운드에서 잘 운영되는것은 하늘과 땅 차이입니다.
시니어
새로운 기술에 의해 거만해지는것을 조심해야한다.
기술을 선택할수 있는 권한이 조금 생기는 즈음 조금더 주도적으로 이 과정에 참여하게 됩니다.
과거의 기술을 이해하지 못하고 과거의 것을 모두 대체하는 완전한 신기술은 존재하지 않으며
기술이란 과거로 부터 연장선이자 최신정렬순 이 아닌 과거 정렬순으로 배워야합니다.
대용량 상용서비스를 안정적으로 운영해야하는 책임감이 더 있기때문에
생산성이 향상 되는것처럼 보이는 새롭게 등장한 기술을 무조건 채택하지 않습니다.
다음 그때 즈음 ORM을 선택을 해도 되는가? 란 주제로 고민을 한 분입니다.
ORM이 SQL을 몰라도됨을 의미하는가? 그리고 생산성이 과연 향상되는가?
그 의미를 알려고 관련 책을 2~3정독을 하고 샘플프로그램을 작성해 보았다.
책한권은 ORM이였고, 다른 책한권은 쿼리 튜닝에 관련된것이였다.
쿼리 튜닝의 샘플을 ORM으로 옮겨보는 샘플프로그램을 작성하는것이였는데
처음에는 ORM의 생산성에 신났지만, 쿼리 튜닝의 우수 사례를 변환하는과정에서
좌절이 생겼다. 단순하게 성능의 문제가 아닌, DB와 함께 OOP를 더 깊이 있게 알아야하는것이다.
DB가가진 튜플,릴레이션,제약등의 특성을, OOP의 특성을 이용해 변환해야 하는것이다.
구체적으로 다음과 같은 질문이다. DB의 관계도가 OOP의 특성으로 변환이 가능한가?
다양한 조인/유니온에 의한 컬렉션변환등이 단순하게 상속기능을 활용하여 표현가능한가?
관계형 DB와 OOP의 특성 불일치가 분명 존재한다란것이다.
여기서 말하는 불일치를 이해하려면 관계형 DB의 정규화문제를 OOP의 특성을 활용하여 해결 할수 있는가?
란 문제이며, 이러한 문제가 있다란 사실을 인지하기위해 더 많은 학습을 해야한다란것이다.
ORM을 활용하기위해 새로운 개발패러다임을 알게되었고 관계형 DB의 의존을 단순화하고
CRUD가 아닌 CQRS,이벤트 소싱등 개발패러다임 자체를 바꿔야하는 난이도 있는 주제였다.
그동안 축적된 DB에서 해결할수 있는문제를 수준높게 어플리케이션을 통해 해결해야하는것이다.
NOSQL(NotOnlySQL)역시 SQL문만을 쓰지 않겠다는 의미이며, 이것은 SQL을 쓰지말라는 이야기가아니다
역설적으로, 도구가 두개생겼으니 SQL+NOSQL 두개다 잘 활용해야한다란 의미다.
ORM도 마찬가지로 DB를 덜 알아야되는것이 아니고 관계형 DB의 특성과 함께 OOP를 활용해야하기때문에 평균이상 더 알아야한다.
ORM을 사용하려는 개발자들이 그것을 잘못해석함으로 개발생산성이 높아진다란 이야기만 하는 실수를 범하는것같다.
참고 링크 : SQL PART-B
학습곡선
이것은 학습곡선이 높아 채택 안하는것이 좋을것같습니다.
학습곡선이 낮은것을 채택하는것이 항상 도움이 될까요?
- 학습곡선이 높은것은 항상 포기하고 적정한 스택을 선택하는 개발사에 있고싶습니까?
- 기술수준을 높이기위해 높은곡선이 필요한것을 연구하고 노력해야하는 개발사에 있고싶습니까?
높은 개발수준을 유지하기위해 개발비용을 조절하여, 개발비용은 얼만큼 투입할까?
이것은 비즈니스적인 관점이며
"새로운 PasS를 사용하면 코딩이 필요없고 개발자도 없어도됩니다. 월사용료는 개발자보다 높지 않습니다."
이런날이 점점 오겠지만.......
엔지니어가 스스로 낮은 수준을 요구하는 기술을 선택하는 성향이 되지 말는 이야기입니다.
복잡성을 잘다루기위해 높은 수준, 학습곡선이 높아질수 있으며, 복잡성을 다루기위해 적합한 기술을 선택할수 있습니다.
학습곡선이 낮은것은 모든 구성원이 쉽게 사용할수 있겠지만 이것이 항상 채택의 우선순위가 되어서는 안됩니다.
기술부채에 대해 :
오래된 기술을 또는 나쁜 아키텍처를 채택해 나중에 부채가 될수도 있지만,
최신기술을 채택한다고 기술부채가 해결되는 것은 아닙니다.
요즘 인프라의 대세인 쿠버의 경우도 초기 도입 학습곡선을 낮추려고
서버관리가 필요없는 AWS파케이트를 선택해 지금당장 쿠버가 잘작동하는것처럼 보이지만
OS를 선택하고 새롭게 뛰우는 프로비저닝을 AWS가 공지없이 해버려서 서버가 중단되는 사태가 실제 발생했습니다.
SLA에 대한 보장을 AWS가 항상 할수 있는것은 아니며
서버리스 클라우드로만 모두 구성을 하는것이 빠른생산성으로 좋은것처럼 보이지만
결국 클라우드 종속이 되어 다른환경는 재 구성할수 없는 부채가 발생할수 있습니다.
기술부채에대해 조금더 철학적이고 기술적인 내용은 다음 영상을 추천합니다.
리더
온고지신의 의미는 좋으나, 급격하게 변하는 IT트렌드에 맞지 않을수 있습니다.
클라우드의 등장과 함께 복잡하게 사용해야할 기술들은 조금더 쉽게 사용할수 있게 발전하고 있습니다.
하지만 비즈니스는 훨씬더 복잡해지고 요구되는 트래픽은 높아지고 있습니다.
경력이 적은 개발자가 그동안 축적된 과거의 기술스택을 모두 이해하고,지금까지 축적된 개발스택의 요구사항을 준수하기 어려울수 있습니다.
이것은 과거부터 항상 경력자를 채용해왔고, 개발팀에서 사용할 기술 스택의 격차의 중간점이 있는것이아닌 0과 100이 존재할수 있으며
이 간격을 주니어가 단시간에 메울수 있는것이 아닙니다.
인스턴스 메모리를 빠듯하게 관리하려고 가비지컬렉터의 라이프사이클을 들어다 보는 시대에서
인스턴스 헬스에 문제가 좀 있으면, 서버를 손쉽게 갈아치우는 시대가 되었습니다.
그렇다고 일주일을 못버티는 인스턴스의 문제를 파악하지 않은체, 자동으로 교체하는것으로 문제해결을 하지말아야합니다.
기술채택에 있어 어느정도 기준점을 과거 사용한 안정적인 기술만 선택하는 길이 아닌
수준높은 개발수준을 추구하고 어느정도 시장 보편적인것을 선택하여 커리어도 보장
하는것이 팀원들 모두 윈윈 하는 방법이지 않을까? 고민해봅니다.
도메인 분쟁편
주니어
개발자가 도메인을 조금더 알게 되었을때, 도메인 지식없는 기획자를 무시하기도 하고 그들이 필요없다고 판단하기도 합니다.
지식은 힘이며, 지식을 가진자가 그들의 위에 서는게 당연하다고 생각합니다. 개발이란 기획자가 절대 할수 없는것을 한가지더 할수 있기때문입니다.
기획의 다음 고급영역인 BA,BI등 대규모로 채용하기 시작했으며 그들은 분석을 위해 개발자에게
정기적으로 방문하여 도메인을 묻기 시작하였습니다. 같은것을 여러번 알려주는것에 염증이 났으며
이때 코드에 숨겨진 서비스 로직이 무기였으며 그들의 위에 서는 거만한 개발자 였던 시절입니다.자신이 지금 특수하게 알고 있는 그 도메인의 가치가 현재 밥그릇이라고 생각할수 있습니다.
하지만 조금만 생각해보면 회사내에서 쌓아왔던 업무지식이 다른곳에서는 아무런 가치가 없을 가능성이 큽니다. - 특허와관련된 내용이 아니라면
자신이 업무중 발생하는 중요한 도메인의 발견을 주위사람에게 공유하다보면
훨씬더 가치있는것을 점점 발견하게 되고 성장을 하게됩니다. - DDD 도메인의 발견편( 우리의 도메인이 발명인것같지만, 사실은 발견의 연속이다. )
시니어
회사에서 일어나는 활동은 회사의 자산이다.
도메인 지식을 자신에게 가둬두고 혼자만 알고 있는것은 단기적으로 영향력을 행사할수 있습니다.
하지만 공유없이 계속 가지고 있음으로, 새롭게 발생하는 가치있는 기회 새로운 활동 또는 기회를 잡지못할수도 있습니다.
당신의 코드는 다른곳에서는 아무런 가치가 없을수도 있으며, 리팩토리로 연장이 안될 가능성이 훨씬 높습니다.
하지만 누군가에게 잘 넘겨주면 당신이 다른 새로운것을 하는동안 당신의 코드는 생명연장이되어 조금더 살아있을수 있습니다.
이때가 글로벌 솔류션에 중요한 특정 파트 개발자였으며 이것을 가지는것이 힘을 가지는것이라고 착각하던 때가 있었습니다. 그 우물안에서는 그랬습니다.
기획자를 포함 도메인지식을 모른체 합류한 각각의 전문가를 빠르게 인정하지 못하기도 하였지만
돌이켜보면 그들은 각각의 분야에 최고의 사람들이였습니다.( 기획자란 단어보다 BI/BA/PO 등 조금더 세부적인 역할로 나뉘었습니다. )
공유하는 문화를 배우고, 누군가에게 시원하게 털어버린순간 오픈마인드가 되었으며
세계각지에서 더 넓은 개발문화를 배우는 기회가 왔으며, 동시에 제 개발코드가 경계를 뛰어넘어외국개발자에의해 생명을 이어나갔으며 더 넓게 생각하는 개발자가 되었습니다.
나만 아는코드로 힘을 가지는것 보다 내가 작성한 코드 자체가 다른 개발자에게 넘어가
더 좋은 코드로 리팩토링이 되고라이프 사이클을 이어가는것 자체가 더 가치 있는 것입니다.
물론 당신이 상위 1%, 엄청난 코드를 짜고 그것이 가치 있는것이라면 git에 커밋을 안해도됩니다.
압축에 패스워드를 걸고, 당신의 코드를 보호하십시오
리더
도메인은 그 누구든 오랫동안 다룬 담당자가 가장 잘 알수있는 영역이며, 역활과 상관없이
그 도메인 지식을 퍼트리는것이 가치있는 일이며 협업및 커뮤니티로 발전에 영향을 준 사람들은 또다시
나의 좋은 인적 네트워크가 될수 있습니다. 그리고 그런 사람들이 회사의 가치를 만들어 내며 성장이란
의미는 내적 성장을 의미하기도 합니다. 이것은 개발/기획 구분이 없습니다. 모두가 개발에 참여하고있으면
도메인과 관련된 개발자입니다. 도메인의 발견관련 내용은 DDD 학습을 도전합니다.
계획과 업무시작시간의 정의
주니어
왜 1분 지각은 , 1분 야근으로 채워지지 않는가?
야근수당, 초과근무라는 개념이 거의 없었던 시절입니다.
새벽 운영대응도 잦았으나 야근한만큼 늦게출근가능하였지만
지각은 왜 항상 측정하는가?
시니어
수영장 강습을 예를 들어봅시다. 수영을 하기 위해 10분전에 도착하여 샤워를 하고 수영복으로 환복
을 하여 수영수업을 받을준비를 합니다. 수영이 끝나고 샤워를 위해 10분의 정리 시간을 더 사용합니다.
그 누구도 수영강습을 위한 이용시간에 20분이 깍이는 것을 원하지 않을것입니다.
업무시작을 위한 준비의시간, 업무를 마치고 정리하는시간이
각각 다를수 있지만 개인적인 시간이며 존재한다는것입니다.모닝커피를 허용할수는 있겠지만
업무시작은 책상에 앉아 업무를 바로 시작할수 있는 상태를 의미합니다.
급한일이 있어 개인의 책상을 미리정리하고 빠르게 퇴근할수 있지만
정시 퇴근을 의식하여 퇴근 30분전 업무를 마무리하고 자신의 짐정리를 미리 하는것은 프로적인 마인드가 아니란점입니다.
이것은 거의 대부분의 케이스에 적용할수 있습니다.
스포츠선수가 경기 시작전 최상의 컨디션을 위해 몸을 풀어주는것, 배우가 최상의 연기를 위해
자신의 메이크업을 일찍나와 신경을 쓰는것 촬영이나 경기가 끝났지만 더 좋은 결과를 얻어내기위해
동료와 이야기하거나 피드백을 받는것등 이있으며 +-30분정도 준비와 정리시간을 가질수 있습니다.
영화관에서 2시 10분에 시작하는 영화를 예매했을때도, 정확하게 2시 10분에 도착하지 않습니다.
영화를 재밌게 볼 상태를 만들기 위해 일찍와서 팝콘및 음료도 구매하고 광고타임에 미리 착석을 합니다.
우리는 알고 있습니다. 영화 시작타임에 입장을 하여 자리찾으려고 입장하는 사람들때문에
중요한 인트로 화면을 놓치게 된 케이스를요
화장실이 급해서 . 중요한 아침미팅때 지각은 안했지만 아침미팅때 자주 늦는 아마추어가 있을수 있습니다.
아침 미팅때 업무할당을 했지만 그 이야기 진행이 막히게 되는 케이스를요
축구경기에서 이것은 경시 시작 스타트멤버가 시간을 지키지 않게될경우 감독이 스타팅멤버를 바꿔야하는 전략수정 문제로서
만약 당신이 그렇다고 한다면 팀원에 막대한 피해를 주는것입니다. 유연근무및 재택으로 인해 일의 시작가능시간이 늦어 질수도 있지만
개인및 팀 또는 협업을 위해 근무가능 시작 상태와 시간을 명확하게 아는것이 중요합니다.
과거 이것은 지각체크와 같은 단순한것이지만 자율이 부여되었다고 하면 각자가 자신의 스케줄을 책임이 지는 PM이여야합니다.
업무준비와 업무정리시간을 전체 근무시간으로 포함할수도 있겠지만 ( 은행의 경우 업무정리자체가 업무일수도 있습니다. )
개인마다 차이가 있을수 있지만 업무준비와 업무정리를 하는 근무외 시간이 존재할수 있습니다.
리더
해야할 개발일의 수준은 계속 높아지고 비지니스의 가치를 달성하기위해 더 많은 시간이 필요하지만, 업무시간을 단축하고
워라벨을 실천하려는 개발사가 점점 늘어나고 있습니다.
시간과 공간제약없는 근무환경을 만드려는 시도도 일어나고 있으며, 절대적인 근무시간이 생산성과 이어지지 않는 다란것입니다.
무엇을 해야하는지 정확하게 생성하고 분배하고 그것을 관리할수 있는 방법등이 필요하며 이것은 생각보다
수준높은 개발 프로세스와 함께 높은수준의 Task관리가 필요합니다.
여기서 Task는 단지 만들어놓고 잘 옮긴느것만을 의미하지도 않습니다. Task가 가진 그 가치 자체를 팀이 이해하게 만드는것입니다.
시간은 중요하지 않습니다. 맥락이 잘 전달되면 그 Task는 굴러가게 됩니다.
배움의 기회
주니어
업무에 시달리다 보니,회사가 자기개발을 위한 시간을 주지 않는다.
업무를 빨리마치고, 다양한것들을 연구하는 것에 눈치가 보인다.
내가 발전 못하는것은 환경에 기인한다.
현재는 다양한 분야의 개발서적을 책상에 올려놓는게 미덕이지만,
개발팀에서 사용하지 않는 진영의 개발서적을 책상에 올려놓는것을 눈치를 보던 시절이 있었습니다.
시니어
회사는 당신의 능력을 증명 해야하는곳이며 그 과정속에 기회를 찾고 성장을해 야하는 곳입니다. 물
론 그러한 찬스가 많은곳이 좋은 회사이며 그러기위해 노력해야합니다.
하지만 회사는 단지 그러한 기회를 당신에게만 주기위해 노력하는 곳은
아니다란 점입니다.
넷플릿스,구글,MS 개발문화는 직원을 성장시키기 위해 부득이 노력을 하며
모범이 되는 케이스도 많이 있습니다.
하지만 다음과 같은 일반 개발사가 할수없는 공통 전제조건이 있습니다.
- 상위 10%에 이상에 해당하는 개발자 수준 유지(수준이 낮으면 입사불가)
이러한 회사의 문화는 다른관점으로 생각도 해봐야합니다. 그 그룹내에서 경쟁을 해야하며
수준이나 평가가 낮았을때 언제든 해고될수 있습니다.
상위 좋은 개발회사의 문화를 비교하기전에, 그속에 속해있는 개발자의 수준을
먼저 비교해야하는데, 안타깝게도 그러한 자료는 별로 없습니다.
단순하게 상대편의 좋은 개발문화를 가지고 투덜되는 최근 주니어들의 마음은 이해하지만
자신의 개발수준에대해서는 비교하는것은 싫어합니다.
제 경험을 간단하게 이야기하면
호주에서 대학을 지원하고 대학의 최고인재를 등용하고 카프카를 공식후원하는
수준높은 개발사에 일할 기회가 있었으며, 이곳에서 주니어가 발표하는자료가
"리액트 + 타잎스크립트" 활용하여 웹페이지 만들기, 우리나라 서점에서
흔히 볼수 있는 듀토리얼 문서에해당하는 책 내용이 아닙니다.
"타잎스크립트로 게임로직 만들기" 란 주제였으며 데모가능하고 상용까지 할수 있는
수준을 빈백지에서 시작하여 완성하는 과정이였습니다.
리액트+타잎스크립트를 공부할 시간을 회사에서 주었을까요? 아닙니다.
주니어이지만 이미 그것을 깊이있게 학습하였고, 비지니스 가치를 위한 기회를
잡으려고 아이디어 있는 게임로직 개발을 시연하였습니다.
기술적 수준만 보았을때, 주니어가 시니어(저)보다 더 휼륭할수 있구나 반성하는
시간이였습니다.
주니어이지만 기초적인 서적들은 이미 배워서 옵니다. 회사에서 그것에대해
공부할 시간이 없다고 투덜되지 않습니다. 큰 차이점은 우리팀이 가진 책장을보면
인터넷에서 한나절정도 투자하면 익힐수 있는 그런 기초서적만 즐비합니다.
"닷넷기초","앵귤러익히기","시작하세요 MYSQL" 이런 책들입니다.
해외 개발팀의 책상에 놓여진 책들이 어떠한것이 있는가 스캐닝을 한적이 있는데
놀라운것은 기초서적으로 불리는 책이 개발팀에 돌아다니는것을 단 한권도 본적이없습니다.
기초서적이 나쁘다란 의미는 아니고, 구성원이 이미 기본으로 배워서 탄탄한 상태라는것이며
운동선수가 기초 체력단련을 경기시간에 하는것이 어딘가에서 항상 하고 있는것처럼 느꼇습니다.
그리고 사내 토이 프로젝트의 의미도 다릅니다. 단순하게 회사업무에 사용되는
스킬이 한정되니 기술의 폭을 넓히는 목적이 아니였습니다.
그들이 하는 토이 프로젝트는 책한권 따라하면 나오는 프로젝트 수준이 아닙니다.
비즈니스에서 발생하는 가치 있는 기회를 잡으려는 목적으로
전문가들이 모여 수준있는 다양한 실험을 하는것이였습니다.
국내에서 발생하는 우리의 수준을 돌아보면
"학습곡선이 어려워 못하겠어요, 쉬운거 할래요" 라고 하는 대부분의 투덜거림이
서점에서 책한권 듀토리얼보고 따라할수 있는 내용들이 대부분입니다.
시니어 프론트개발자가 웹의 기초에대해서 가르쳐줄까요? 답은 아니오입니다.
웹의 기초를 모르면, 당신이 가고싶은 회사에 입사할 자격조차 없는것입니다.
그리고 주니어가 자신의 웹 기초는 탄탄하다란것을 다양한 기술을 활용하면서
증명하는 활동을 많이 합니다. 시니어개발자가 오히려 주리어 개발자가 준비한
최근기술동향에 대해서 배우기도하게 됩니다.
해외이야기가 아닌, 다시 우리의 이야기로 넘어와서
시니어가 당신의 개발능력을 아직 인정하지 않지만 코칭을 해주는것에대해 나쁘게
생각하지마세요, 그것을 극복하고 배워 나감으로 더 가치있는 개발자가 될수 있습니다.
시니어 개발자가 주니어의 성장을 시키는것은 점점 없어질수 있습니다.
팀자체가 구성원들을 성장해 가는 방향으로 가고 있기때문이며, 이것은 주니어역시
스스로 성장하는 팀문화에서 프로여야 합니다.
리더
아무것도 모르는 신입을 양성해야하는 사수의 개념이 사라진지 오래되었습니다.
주니어 시니어로 주로 구분하기 시작하였으며
주니어도 인터넷을 통해 충분히 고급 기술들을 배울수 있는 기회가 많고
시니어라고 주니어보다 모든 분야에 띄어난것을 의미하지 않으며
역설적으로 주니어또한 교양을 포함 수준 높은 개발자에대한 자기개발을 멈추지 않아야한다는것입니다.
자기개발을 업무시간에해야하는것일까요? 아니면 업무외 시간에 해야하는것일까요?
개발 유형별로 자기개발에 대한 요구를 가상으로 체크해보았습니다.
- 서비스(운영)개발자 : 업무중 자기개발이 뭥미~장애처리로 바쁨, 나도 하고싶음 ( 이미 번아웃 , 퇴근후 자기개발없음 )
- 솔류션/플랫폼 개발자 : 우리가 맡은 영역외의 운영업무가 추가되는 프로젝트에 엮이고 싶지않습니다. 새로나온 플랫폼을 활용하여 팀의 역량 강화를 항상 시도하고 있습니다.
- 공통 : 업무외 다른항목도 자기개발할수 있게 지원 해달라~
사내 자기 개발시간은 특정 집단,그룹에게 주는것이 아닌 기회제공이 같아야합니다.
동등한 개발자이지만, 특정팀에 소속된 이유만으로 자기개발을 업무시간에도 하고싶지만
할수없는 팀이 있다란 사실을 인지하는것이 우선입니다.
단순하게 업무중 자기개발의 기회를 주는것이 아닌, 자기개발을 할수없는 팀이 있다란 자체를 인지하고 그것을 해결하는 아이디어를 고민하는것입니다.
PA와 PP의 구분
아래표는 최근 10년간 기준으로 함께일한 개발자를 기준으로
몇가지 주제로 업무적 주제에 따라 Pa와 Pp로 구분하여 보았다. 이 구분법은 30년전 출간한고약한문제 합당한 해결에서
정의한 방식이며 최근 기준으로 다시 다시 정리해보았다.
브룩스와 피터스는 우리들, 즉 프로그래머가 소프트웨어 공학에서 긍정적 변화의 핵심이라고 지적한다.
이것은 프로의식(professionalism)과 관련이 있다. 사람들 대다수는 프로그래머가 아마추어인지
프로인지는 깔끔하게 구분된다고 생각하고 있다고 레거스는 적었다. 그러나 이런 부류가 있다.
바로 프로라고 불리는 아마추어다.
- 30년전 고서 고약한 문제 합당한 해결 책내용중 Pa(아마추어같은 프로그래머)와 Pp(프로페셔널한 프로그래머)를 구분
고약한 문제는 결국 사람이 해결해야하며 프로페셔널한 프로그래머가 많아야한다는것이다.
단지 경험이 많아 연차높은 개발자를 의미하는것이아닙니다. 이 시대 프로페셔널한 프로그래머도 우리나라 경력측정기준 길어봐야 2년차 이내였을것입니다.
특정 역활을 하는 사람이 아니라, 우리의 일하는 방식을 Pa(아마추어와 같은 프로그래머)와 Pp(프로페셔널한 프로그래머) 로 구분을 하였습니다.
이 책에서 소개하는 PA와 PP를 구분해보고 고약한 문제를 해결할수 있는 아이디어를 함께 살펴보겠습니다.
| 주제 | Pa |
|---|---|
| 기획 | 기획서가 완벽하기를 기대한다. 기획서가 부실하면, 모든 개발의 지연을 기획탓으로돌린다. 사용자가 원하는것이 아닌, 자신이 원하는것을 기획한다. 프로덕트를 완성시켜가는 기획과정에서 탑다운 자체를 문제로 삼지만 |
| PM | Task에 대한 명확한 이해가 없고 PM이 기획이야기를 하고, 개발을 이야기를 더많이하는 순간 그 프로젝트는 뭔가 잘못되어 가고 있는것임으로 처방이 필요하다. |
| 문서 | 문서화는 찾아볼수 없으며, 자신이 작성하고 자신의 머릿속에 있는 코드가 회사의 무기라 생각한다. 당연하게 이렇게 작성한 코드는 어떻게 작동하기도하고 수익을 발생하기도한다. 이것을 받을수 있는 사람은 존재하지 않으며 코드의 수준이 유지할수 있는 상태가 아니기때문에 폐기될 가능성이 높다. |
| QA | 디버깅능력은 찾아볼수 없으며, 운영에 반영한뒤 즉각 테스트한다. 문제를 고치기까지 운영의 코드를 수집번 고치고 올리고를 한다. 잠수함 패치라고도 불리며, QA가 필요하지 않느냐 라고하면 단호하게 말한다. "QA는 필요없으며 이것은 QA가 감히 접근할수 없는 일입니다. 시간되면 0부터 풀테스트 하십시오~" |
| CI/CD | 자신이 빌드한 릴리즈를, 수동으로 자신만이 할줄 아는것에 자부심을가진다. 이것을 뺏기는것에 두려워하며 자동화를 방해할때도 있다. 하지만 진정한 문제는 CI/CD란것 존재 자체를 모른다. 이렇게 작성된 코드는 시스템의 디펜던시가 정리가 안되고 때로는 복원자체가 안될수도 있다. 운영서버에서만 유일하게 작동되며 이것이 장애로 없어지게될시 회사의 서비스하나를 유실하는 심각한 문제가 될수 있다. |
| 주제 | Pp |
|---|---|
| 기획 | 기획에서 무엇을 놓치고 있는지? |
| PM | 해당 Task가 무엇때문에 얼만큼 걸릴지 PM은 그것의 완료가 목적이 아닌 |
| 문서 | 개발중 문서화를 한거나 개발 시작전 어떻게 개발할지 고민하는 문서를 먼저작성한다. 그리고 코딩은 컴퓨터가 아닌 다음 이 코드를 맡게될 사람을 위한 코딩을 한다. |
| QA | 운영에 발생하는 문제를 찾기위해 원격디버깅 및 로깅등을 철저하게 활용한다. 유닛테스트를 작성하기도 하지만 적어도 변경범위에대한 영향범위를 어느 정도예상하며 QA를 위해 테스트범위를 줄여준다. |
| CI/CD | 배포및 구동과같은 반복작업에 대한 시간을 최대한 줄여보려고 노력하여 더 가치있는 일을 할수있는 시간을 만들어낸다. 대부분 이러한 부류에 개발자들은 젠킨스와 같은 툴들을 스스로 찾아내어 적용한다. (데브옵스가 없던시절 기준) |
| 주제 | 고약한 문제 해결방법 |
|---|---|
| 기획 | 폭포수모델에서는 기획서가 완벽해야했다. 기획서가 작동되는동안 또는 개발이 착수되는동안 요구사항이 이러한 요구사항을 수집및 분석하는 과정을 기획서라는 하나의 이벤트스토밍,스토리맵핑,이그잼플맵핑등 |
| PM | 칸반보드의 Task를 완료로 옮기는것이 전부가 아니며, |
| 문서 | 문서는 개발이 완료된후 그것을 정리하는것이 아닌 개발과정의 일부로, 모델을 생성하는 문서일수 있고 |
| QA | Api Base의 자동화 테스트는 물론 UI를 테스트할수 있는 테스트툴을 도입한다. 사람은 단지 자동화 테스트가 할수없는 더 고급적이고 복합적인 테스트를 한다. 그리고 이렇게 작동된 베이스로 로드 테스트또한 가능해진다. |
| CI/CD | CI/CD를 위해 과거에는 여러가지 복잡한 빌드,배포 기술들을 조합 해야했지만 도커의 등장으로 배포자체는 단순해졌으며 Code As 인프라 , 특히 Github이 CI/CD를 통합하면서 배포는 훨씬더 단순해졌습니다. |
공유와 폐쇄
소프트웨어를 만들어내는 팀활동에서, 단지 프로와 아마추어구분이 있는것이아니라
중요한 한가지가 더 있다란 사실을 알게되었습니다. 팀의 공유된 지식이며 오픈소스의 활동을 통해 가치를 알수 있습니다.
소프트웨어 그 이상을 의미하는 오픈소스 운동
오픈소스는 코드 그 이상을 의미합니다. Red Hat은 오픈소스 성공 사례를 통해 오늘날 다양한 커뮤니티에서 오픈소스 기술을 어떻게 활용하고 있는지 공개하고 있습니다.
오픈소스 성공 사례는 커뮤니티, 능력 위주의 환경 및 자유로운 의견 교환을 통해 다양한 분야에서 잠재력을 활용하는 방법을 널리 알리는 멀티미디어 시리즈입니다. 최근 공개된 주요 내용은 다음과 같습니다.
- 오늘날의 농부는 미래를 위해 오픈 툴과 원칙을 어떻게 활용하고 있을까요?
- 열린 리더십을 통해 선생님과 방과 후 클럽이 창의적인 커뮤니티를 구축하고 학교와 도시를 변화시킨 사례를 알아보세요.
- Femi Owolade-Coombes는 오픈소스와 커뮤니티가 어떻게 젊은 코더들을 위한 가능성을 열어주는지 이야기합니다.
- Alicia Gibb이 오픈 하드웨어 운동의 정의와 의의를 설명합니다.
오픈소스를 우리는 이미 우리의 플랫폼에서 활용하고 있으며, 이것이 없다고 하면 어쩌면 우리가 만든 프로덕트는 없을수 있으며
개발자가 되기 어려웠을수도 있습니다. 팀의 문화에서도 오픈적인 마인드가 팀을 성장으로 이끄는 중요한 요소임에도 불구하고
안타깝게도, 오픈소스를 잘 이용할줄아는 개발자가되 었지만 오픈의 가치를 이해하지 못하고 폐쇄형으로 가는 주니어 개발자가 많이 있는것 같아
정리 해보았습니다. 이것은 경력자라고해도 다르지 않습니다. 자신의 오랜 업무경험이 문제해결을 위한 유일한 방법이다라고 생각하는
폐쇄적 고착형 부류로 팀의 가치성장에 가장 큰 방해가 될수 있습니다.
오픈소스의 활동은, 기업단위 이상의 가치있는것을 오픈을 하는데~
우리의 단일 기업에서 팀간 중요정보를 폐쇄형으로 가야하는 이유는 뭐가 있을까요?
| 주제 | 폐쇄(고착형) |
|---|---|
| 문서 도메인 | 도메인 이슈를 포함, 자신의 커리어에만 이러한 팀은 항상 '사수가 없어요, 온보딩이 없어요' 라고 이야기를 합니다. |
| 새로운문제에대한 팀경계 | 우리는 토마토를 키우는 비닐하우스를 가지고 있고있고 토마토가 잘 자라지 않는 문제에대해 이야기를 하기 시작하였습니다.
토양의 품질을 관리하는 팀은 토양의 품질이 하루 평균적으로 문제없다고합니다. 물을 공급하는 팀은 우리의 물 공급량은 이상이 없다고 합니다. 아무것도 해결 하지 못하고 고약한 문제로 남게되었습니다. |
| 메신저 | 우리의 대부분 중요한 도메인 처리 활동을 Private 채널이 아닌 관련업무자를 초대하여 진행합니다. |
| 주제 | 오픈(성장형) |
|---|---|
| 문서 도메인 | 자신이 고민하고 해결한 도메인지식을 새로운 참여자가 들어오게되면 팀이 정리한 문서를 통해 업무투입시기를 앞당길수 있습니다. 이러한 팀은 항상 새로운 팀원을 위한 문서를 만듭니다. |
| 새로운문제에대한 팀경계 | 토양 품질을 관리하는 팀은, 물을 공급하는 팀의 물공급시기에 관심을 가지기 시작하였습니다. 토마토가 자라야할 시간에 최적의 토양품질이 아님을 알게되었고 물공급팀에게 시간대별 공급량에 대한 아이디어를 제공하였습니다. 몰을관리하는 팀은, 토양품질팀의 토양상태에 대해 관심을 갖기 시작하였습니다. 토양품질은 우리가 제공하는 물의 수질상태에 의존적인것을 알게되었으며 알게되었습니다. 오래된 파이프를 결국 교체를 하게되었으며 |
| 메신저 | 메신저는 즉각적 활동이며, 목적성이 있는 공개채널로 분류될수 있습니다. cc가 메일수준의 참조가 역활이 되어선 안됩니다. 우리의 업무적 메신저 공간에서는 사소롭거나 중요한 업무적 이야기를 언제든 할수 있는 상태여야하며 언택시대에서는 특히 더 중요합니다. 업무적 이야기를 진행할때 대부분 최근참여한 멤버는 이 문제를 누구에게 어떻게 이야기해야될지 cc참조 대상을 모른다고하면 벙어리가 되어야 할까요?
|
| 종합본 |
|---|
정리한 내용을 오픈을 두려워 하는 실무자의 공통점은 내용의 실수를 할수 있기때문에 조심스럽다란것입니다. 해결방법에 실수가 있을수 있지만, 우리는 그러한 문제가 있다란 사실을 알게된것에 더 가치를 여길수 있으며 |
가상의 이야기이지만, 팀이 다르지만 우리는 결국 비닐하우스의 토마토의 생산력을 높이는 공통 관심사가 있습니다. 생산력증가는 결국 팀을 더욱더 가치있는 팀의 경계를 나누는것은 그 경계내에 전문성에대해 더 집중하는것이지 타팀의 일을 몰라도됨을 의미하는것이 아닙니다.
협업을 통한 공유를 잘하는것 자체를 능력으로 간주해야할 만큼 폐쇄적팀은 시간이 지남에따라 아무런 발전을 할수가 없습니다. |
주니어 시절 새로운것만 추구하면서 경솔하기도 했고 시니어어가 되는 시점 익숙해지면서 거만해지기도 했고
리더가 되는 시점 팀이 잘하지 못하는것을 채택하기도 했습니다.
신기술을 쫒아가는것만이 열린 마인드라고도 볼수 없으며, 과거의 기본기를 무시하려는 자세는 닫혀 있는 마인드일수 있습니다.
열린 마인드는 과거의 기술과 함께 새로운 기술을 조화하는것이고 기술만이 중심이 아닌 우리가 가진 문제를 공유된 팀의 인지를 통해
해결해나가는것이며 성장하는 오픈 마인드로 마무리해봅니다.
Add Comment