미리 알아야 할 개발 공부와 개발 실무의 차이
실무 실무 하는데, 실무에서 일을 잘한다는 것은?!
오늘은 실무에 대한 이야기를
해보려 합니다.
학생 때 늘 실무가 중요하다는 이야기를
많이 들었는데요.
정작 그 당시에는 그 실무에 대해서
실체도 모르겠고 공부하는 것이랑 일하는 것
그 차이점이 무엇인지
몰라서 많은 시행착오를 겪었는데요.
회사에 들어가기 전에
미리 알아두면 좋은 것들을
실무를 한다고 할 때 필요한 것들을
좀 정리해서 말씀드려볼까 합니다.
시간의 중요성 (일정 관리)
학교 공부 혹은 학원 공부와 달리 가장 많은 비중을 차지하는 것 중에 하나는 일정 관리가 아닐까 생각을 해봅니다. 무엇보다 나의 시간이 아닌 의뢰자의 시간, 회사의 시간관리라는 점이 포인트입니다.
실무에서는 매우 시간이 빠르게 흘러갑니다. 그 시계가 빠르다는 말은 일을 해야 하는 사람이 바빠진다는 이야기입니다. 어느 정도 예상을 할 수 있겠지만, 일이란 것들의 대부분은 일정이 존재합니다. 뭐 개발자라면 일정이라는 게 늘 바뀌는 것이 아닌가?라고 생각하거나 예측해 볼 수도 있지만, 일정에 대한 규칙이 없으면 모든 일들은 처리가 되지 않은 채로 계속 둥둥 떠다니고 말 것입니다.
첫 프로젝트는 2달 만에 뭔가를 해야 하는 상황이었습니다. 보통은 신입사원에게는 약간 리스크 있는 일들을 주지 않습니다. 이것은 좋은 점이기도 하지만 안 좋은 점이기도 합니다. 왜냐면 신입의 입장에서는 일을 배워야 그 배운 일을 써먹을 수 있고, 그래야 그다음에 다른 일들이 오더라도 당황하지 않을 수 있고, 경험이 생겨야 그 경험을 다시 활용할 수 있는데, 이것이 없으면 세월은 흐르고, 연차는 쌓이고, 자신감은 없어지고.. 뭐 그런 일들이 발생하거든요. 옛말에 어려서 일은 사서도 한다고, 뭐 그런 비슷한 측면으로 신입에게 일이 주어지는 건 어찌 보면 러키 한 일입니다. 처음에 엔지니어링이라는 회사에서 해외 관련 업무들을 많이 했는데, 신입 입장에서 해외 현지에서 사용하는 블로그 시스템을 만들라는 이야기가 나왔습니다. 대신에 조건은 기존에 소스가 있으니까 해당 소스를 잘 커스터마이징 하라는 것이었고, 제 입장에서는 이 제안을 마다할 필요는 없었습니다. 아직 업무에 배정되지 않는 상황에서 해보겠다고 했습니다.
2달 만에 완성해야 하는 기획, 디자인이 있는 일을 해보게 된 거죠.
회사를 오기 전에 절대 경험할 수 없는 것들 중의 하나는 협업입니다. 누가 기획서를 작성하게 되는지, 일은 어떤 방식으로 넘어오는지, 디자인은 누가 하는지, 디자이너와 트러블에 대한 이야기들을 들어본 적은 있는데 그게 실제로도 그러는지 등등 이런 협업의 관점에서 사실 첫 단추는 운이 좋았습니다.
퍼블리싱을 하는 디자이너를 만났기 때문입니다. 2달 안에 모든 것들을 해야 한다니 신입의 입장에서 매우 빡빡하고, 누가 뭘 알려주는 것도 아니고, 게다가 웹이라는 것이 익숙하지 않은 저로선, ajax에 대한 개념 조차 매우 희박해서, 댓글이 달린다는 것 자체만으로도 매우 신기한 상황이었습니다. 화면 전환이 없이 뭔가 처리되는 상황.. 문제는 혼자서 이 시간적인 압박을 보내야 한다는 것이었는데요.
처음엔 문제가 많았습니다. 디자인만 입히고, 대강 들어가야 할 위치에 다 들어가고 하니까 끝이 난 것 같았는데, 충분한 경험이 없는 신입의 입장에서는 빈구석이 많았던 것입니다. 예를 들면, 댓글, 대댓글 쓰기, 그리고 관리자의 권한 문제, 글에 대한 권한, 글에 대한 수정, 게시글 형태와 블로그 형태 타입 별로 다르게 들어가는 로직들, 댓글의 순서 문제... 그냥 네이버 블로그 보면, 혹은 블로그 프로젝트한다고 하면 그냥 별 볼 일 없게 생각하던 것들이, 실제로 블로그를 하려고 하다 보니, 보이는 것부터 보이지 않는 것까지 해야 할 게 많았습니다. 그리고 생각보다 생각을 해야 할게 많았는데요. 와 근데 시간은 짧은데 이걸 다 해야 하고 발견해야 하고 수정해야 하고 다 고쳐야 한다니. 시간에 대한 막막함.. 이 것을 종결시켜야 한다는 그 압박 생각들 아마도 이런 게 가장 시간 관리에 있어 어렵고 힘든 게 아니었나 생각을 해봅니다. 이런 어려운 상황 속에서도 시간 내에 어떻게든 끝을 냈었는데요. 그렇게 하니 그런 부분들이 인정받게 되고, 개발 부서로 변경되는데 이런 상황이 고려받게 되었습니다. 이렇게 시간을 관리하고 일정을 지켜내는 것들. 이것을 하나씩 하다 보면 자연스럽게 회사 내에서 인정받게 됩니다.
내가 하고 싶은 공부가 아닌 해야 하는 일을 하는 것
회사에 들어가기 전에 전 안드로이드 개발을 하고 싶어 했습니다. 그런데 업무적 배정은 웹 개발자가 되었죠. 물론 다른 선택의 기회들이 더 있었는지는 모르겠지만, 회사에서 그렇다고 안드로이드를 개발할 수 있는 상황들이 많이 주어지진 않았습니다. 즉, 업무적 특성이라는 차원인데요. 지금은 9년 동안 개발해오는 시간적인 혜택(?) 때문에 많은 경험들로 안드로이드 외주도 해보고, 안드 개발 업무들도 해보았었지만, 그 당시 업무가 정해지고 나면, 해당 업무를 바꾸거나 하는 일들은 거의 일어나지 않는 일이었습니다. 즉, 내가 하고 싶은 일을 무조건 할 수 있는 상황은 아니었던 거죠. 하지만 그 안에서 회사가 바라는 목표점과 지향점이 있는데, 그것들은 해야 했습니다.
9년 전에 스트럿츠라는 프레임 워크가 있었습니다. 토인비라는 시스템도 있었죠. 그 당시로써도 상당히 오래된 프로그램이었지만, 이런 프로그램들을 걷어낼 수가 없었는데요. 이런 것들을 걷어내려면 새로운 개발이 필요하고, 또 새로운 개발은 돈이 들고, 이 새로운 개발에 생기는 버그들도 고스란히 비용이기 때문에, 아마도 최대한은 적은 비용으로 유지 보수를 하기 위해서 예전 것들을 활용하는 상황. 파워 빌더도 꽤 오랫동안 사용되고 있던 것이긴 했는데요. 사실 그 당시 실무로 스프링을 써보고 싶었지만, 내부에서 사용하는 것이 스트럿츠였기 때문에 스프링을 접하기까지는 2년이라는 세월이 더 걸린 뒤에나 해볼 수 있었습니다.
이렇듯 하고 싶은 일을 하고 싶어도, 회사에서 경험할 수 있는 환경이 주어지지 않으면, 하기 어렵다는 것이 이런 실무의 단점이라고 할 수 있습니다. 즉 첫 단추가 중요하다는 이야기가 많은데, 첫 회사에서 지금 자주 쓰이거나 많이 쓰이는 것들을 학습하지 않다 보면, 나중에 이걸 하려고 해도 너무 늦었다고 느껴지거나 도저히 지금 회사들이 나아가는 방향들을 따라갈 수 없게 되어버려서... 다시 도전하기 어려워질 수 있기 때문인데요.
그럼에도 불구하고, 그 안에서 최선을 다하고, 그것들도 익숙하게 되는 것이 이런 실무들의 경험들이라는 생각이 드네요.
배운 것은 절대 남 주는 게 아니다! 결론은 부지런히 다른 일들을 해보기
회사를 다니면서 매년 목표가 있었습니다. 신입이든 경력이든 성장에 대해서 갈급함은 누구나 있는데요. 처음에는 메일링 시스템이 궁금했습니다. 누가 안 알려줬거든요. 그러다가 메일 관련해서 돈 안 되는 프로젝트를 하나 하게 됐는데, jsp, jstl 관련해서 메일을 운영하는 서비스를 하나 만드는 거였는데 그게 약 150만 원짜리 일이었는데 누가 도와달라고 해서... 2명이서 나눠서 했고.. 2달 동안 약 한 달에 35만 원이라는 금액으로.. 일종의 간식 먹는 기분으로, 나름대로 이 프로젝트를 통해서 메일 프로토콜 pop3와 smtp를 공부하게 되었고, jstl을 공부하게 되었었는데요. 이게 사내에서 사용하는 프로젝트가 jstl을 쓰고 있었기 때문에 삽질(?)들을 토대로 회사에서는 나름대로 삽질을 적게 하고 일을 하게 됩니다. 그 바람에 일의 생산성이나 능률은 훨씬 좋아졌는데요. 삽질이 들어간 만큼 정보를 취득하는 시간은 짧아집니다. 그 시간을 미리 경험했기 때문에 그 안에서의 프로젝트가 훨씬 수월 할 수 있었습니다.
그 뒤에 궁금했던 것은 쉘에 대한 궁금증과 인프라에 대한 궁금증이었는데, 그 당시에 엔지니어링에서 인프라를 꽉 쥐고 계신 차장님께서 인프라 관련된 다양한 것들을 시키셨는데, 그때 사내 메일링 관련된 항목과 인프라 장비의 모니터링 툴 개발도 한번 수정해보라고 시켜보시는 바람에 그런 업무적인 서버 내에 대한 접근 권한들을 가지고 서버에 대해 공부할 수 있는 기회들도 주어졌습니다. 사실 첫 업무가 인사 업무에다가, 경영지원 쪽 개발 업무였기 때문에 인프라 관련된 업무들을 접하기 쉽지 않았지만, 결국 관심이 있으면 다양한 업무에 대해 경험해볼 수 있는 기회들이 생기더군요.
그다음 궁금했던 것은 DB 설계하기, 학생들이 많이 궁금해하는 것들 중 하나는 DBA 가 되고 싶어요. 디비 관리자가 돈을 많이 받는다고 들었어요. 저도 초기엔 이런 측면에서 기획을 하는 분과 디비를 설계하는 분들이 너무 멋있어 보여서, 어떻게 하면 데이터를 다룰 수 있을지 디비를 만져 볼 수 있을지, 뭐 그런 기대감 들로 한껏 마음이 부풀어 있었는데요. 실무에서는 약간 더 데이터에 관해서 예민하기 때문에 데이터를 관리하는 권한을 잘 주지는 않습니다. 물론 그에 대한 책임감과 결과를 잘 알고 잘하는 사람들에게는 좀 더 그 시점이 빨라지기는 하지만, 종종 잘못된 쿼리로 실무 데이터를 날려버린 사람들의 이야기들은 전설로 전승되기 때문에 이런 데이터에 대해서 만져보고 만들어보기 까지는 시간이 걸렸는데요. 경영 지원 업무들을 하면서 신규 프로젝트가 내부에 많았는데요. 인사 데이터 기반, 부서 데이터 기반 강연 시스템, CEO 블로그, 사우 협의회 블로그, 사내 포탈 관리, 팝업 관리 등등 내부 시스템에 대해서 유지보수 후에 신규로 프로젝트할 일이 많아졌고, 그런 데이터를 많이 만지다 보니, 데이터가 있어야 할 곳에 데이터를 있게 하고, 복잡한 칼럼들은 개발을 어렵게 만들고, 쿼리 하나에 30~50줄 되는 걸 보면서, 꼭 이렇게 했어야 했을까 생각을 하다가도, 그래야만 하는 상황을 납득하기도 하면서 조금씩 데이터에 대해서 많이 생각해보게 되었는데요. 이처럼 실무를 하다 보면 그래도 실제로 사용하는 사람들이 사용하는 데이터를 만져보게 된다는 것. 그 학생 때는 엄청 막연하다 보니 프로젝트를 진행하게 되어도, 그 사용자를 생각하면서 만드는 것이 아니라, 만들어 보고 싶은 것을 만들어보게 되어있는데요. 이런 시각적인 차이가 아무래도 실무과의 가장 큰 차이가 아닌가 싶어요. 고객이 원하는 것. 그것을 얼마나 잘 만들어주는지..
그 뒤에도 프로젝트를 해보고 싶다고 늘 생각하고 있었는데, 차세대 프로젝트에 투입도 해보고, 스프링을 써보고 싶다고 생각했는데 스프링 프로젝트도 써보게 되고, 엥귤러를 쓰고 싶다고 생각했는데 스타트업에서 엥귤러도 써보고, 리엑트도 해보고 싶다고 생각을 했는데 지금은 리엑트를 하고 있네요.
경험을 쌓는 과정들이라고 생각해요. 어떤 지점에 가기 위해서는 하나의 단계 단계들을 밟게 되어있는데 계속 멈추어 있을 순 없으니까, 지금 하고 있는 일들은 앞으로 더 나아가기 위한 성장 동력들이 아닌 가 싶네요~ 하시는 것들의 의미들을 잘 생각해보시고, 지금 하는 일들에 낙심하지 마시고, 한 번에 원하는 것을 얻는 경우도 있지만, 돌아가는 경우도 많다는 것.. 생각해 보시면 좋을 것 같네요.
실패를 통한 성장(회사는 완벽한 사람을 좋아한다)
첫 실패는 대학 졸업 미스였어요. 여러 가지 과정 중에 실패가 없었을 거라고 생각하는 분들도 계시지만, 누구나 실패는 하잖아요? 제 실패는 경영학 복수전공을 하고 싶어 했는데, 그것 실패했어요. 그 부분도 사실 중요한 실패 중 하나라고 생각하고 있지만, 대학 학부 때 삼성 관련해서 특점 학점을 채우면 준다는 제도가 있었는데요. 굳이 생각하면 왜 그걸 했나 싶지만, 마지막 학기에 그 때문에 1학점이 비게 되고, 졸업을 한 학기 정도 뒤에 하게 되었는데요. 복수전공을 한 뒤에 회사를 가려던 계획이 물거품 되면서, 갑자기 회사를 가야 한다는 압박과 실무를 경험해야겠다는 생각이 들게 되었는데요. 그 실패를 통해서 개발자의 삶이 시작되었던 게 아닌가 싶네요.
그때 첫 회사로 내비게이션에 들어가는 음성 인식 회사, 지금은 꽤나 커져버린 회사에 들어가게 되었고, 그 회사에서 음성 인식 관련 업무를 2달 정도 했었었어요. 그 뒤에 이직을 하게 되었지만, 이 앞의 과정에서 게임 회사 면접도 해보고, LG 관련 프로젝트도 해보고, 그리고 안드로이드 개발 외주도 취업 전에 해보았었는데, 그 실패의 경험도 매우 쓴맛으로 남아있습니다. 2달 정도의 프로젝트였는데, 기존에 합의했던 내용을 번복하면서, 마지막 날 다 바꿔달라고 하더라고요.. 그냥 깔끔하게 포기했지만, 세상엔 별별 사람이 다 있다는 것을 인정하는 계기가 되었죠.
경험을 가진채 새로운 회사에서 시작하는 것은 마치 전직과도 같은 느낌입니다. 처음부터이기도 하지만, 새롭기도 하지만, 이미 경험치가 있어서 조금 더 빠르게 성장할 수 있으니까요. 많이 실패해보는 것이 좋다고 생각합니다. 프로젝트도 많이 해보고 많은 사람들이랑 프로젝트도 해보고, 또 다른 성공의 발판이 될 수도 있고 실패했다고 해서 결코 그게 부끄러운 일은 아닌 것 같아요.
다만 그 실패를 통해서, 남는 건 있어야겠지만 말이죠. 개발 외주 관련해서는 검증된 회사와 일해야 하고, 그리고 지인을 통해서 하는 게 무조건 좋은 일이 아니라는 점. 누구랑 일하는지 어떤 일을 하는지도 매우 중요하다는 것들.
하지만, 다른 곳에서는 많은 실패를 하더라도, 지금의 회사에서는 최소한의 실패를 보여야 한다는 것이 실무적 관점이라고 생각을 합니다. 회사에서는 딱 성과를 보여야 하는데, 그 성과가 안 나오면, 낙인이 찍힙니다. 이 낙인은 매우 무서운 거라서, 평가는 가중되거든요. 잘하는 사람이라고 인식되면, 계속 평가가 좋아요. 그리고 못한다고 생각되면 계속 평가가 안 좋죠. 이게 실전인 건데요. 그럼 어떻게 잘하는 사람으로 인식될 것인지, 이게 바로 핵심적인 일입니다. 다른 곳에서 실패하더라도 회사에서는 실패하지 않아야 합니다. 즉, 다른 곳의 실패의 이유는 회사에서 실패하지 않기 위해서라는 것이죠. 뭐 그렇다고 삶에서 일부러 프로젝트를 망치거나 어그러트리라는 것은 아닙니다. 늘 실패하지 않기 위해서 최선을 다하는 것은 동일하지만, 실패에 대한 리스크 햇징.즉, 실패를 분산해야 한다는 거죠. 최대한 회사에서는 실패하지 않는 것을 의도함으로써, 그나마 가장 완벽한 것들을 회사에 가져다줄 때, 비로소 찾아오는 보상들.. 그것을 경험해야 합니다.
새로운 언어에 대한 진입 장벽 낮추기(언제든 갈아탈 준비)
개발자의 입장에서 다양한 언어들을 배우는 것은 중요합니다. 존경하는 선배님이 계신데, 그분은 저와 1년밖에 차이가 안 나셨지만, 이미 학부 졸업 시점에 10가지 정도의 언어를 하셨어요. 아직도 너무 대단하신 분이시라!
(찬란)
언어의 개수가 개발 실력을 판가름 내진 않습니다. 한우물만 파는 게 나을 수도 있죠. 하지만, 거시적 관점에서 너무 한우물만 파다가는 물이 안 터지는 경우도 있습니다. 시대가 급변하고 있고, 언어의 종류도 너무 많아지고 있습니다. 언어적 기준점 이외에도 플랫폼적으로도 세분화되고 있기 때문에 개발자의 이름을 붙이기도 너무 복잡해지고 있습니다. 자바 개발자, 파이선 개발자, 안드로이드 개발자, 아이폰 개발자, 리엑트, 뷰 (프런트 개발자), 백엔드 개발자 - 뭐 언어를 붙여야 할지 플랫폼을 붙여야 할지... 너무 많아져서 서로가 서로를 알아보기에도 헷갈리는 느낌까지 듭니다. 그만큼 학생들 입장에서도 배워야 할 것도 너무 많아지고 있고, 뭐부터 해야 할지 몰라서, 기본적인 개발 언어들을 배우다가 끝이 나버리기도 하는데요.
실무에 있다 보면 필요에 따라서 언어가 바뀌기도 합니다. 갑자기 CGI를 해야 하는 경우도 생기고 php를 해야 될 때도 있고, 또 자바나 기타 안드로이드, 아이폰까지 하게 되는 경우들도 있는데요. 원래 한 회 사에 계속 근무하는 경우는 오히려 근무 환경상 변화가 없는 경우도 많지만, 프로젝트를 하거나, 다양한 업무 선상에 있게 되다 보면 다양한 언어에 노출되고 해야 하는 경우들도 생깁니다. 즉, 기회가 생기게 되는데요. 만약 그런 기회가 있어도, 만약 기존에 준비가 되어있지 않으면 시도도 못해보는 경우도 오게 됩니다. 현재 회사는 몽고 디비에 리엑트를 사용 중입니다. 전 자바 개발자이지만, 3년 전부터 엥귤러에 관심이 있어서, 엥귤러 뷰 리엑트 3가지 중에 하나는 해야 한다는 생각이었고, 거의 엥귤러에 관련해서 해외 사이트를 통해서 공부하면서 일을 해보고 있었어요. 근데 실제로 오퍼는 리엑트로 들어오게 된 거죠. 리엑트 관련해서도, 책을 통해서 흐름을 익혀놓긴 했었는데요. 만약 리엑트에 관해서 준비를 하나도 하지 않았다면 아마 일을 받지 않거나 거절했을 것이라는 생각이 드는데요.
마찬가지로, 새로운 언어에 대해서 미리 준비하지 않고 있다면, 시대의 변화에 대응을 하지 못하면, 결국에는 도태거든요. 과거의 것들로부터 탈피할 준비를 계속해야 합니다.
학부 때 배우는 너무 오래되고 낡은 것들.. 그런 낡은 것들도 구수하긴 하지만, 새로운 것들에 대해서 받아들일 준비를 해야 해요. 실무 다른 것 없습니다. 지금 현재 회사들에서 필요로 하는 스펙들을 조사하는 것부터 시작해보는 게 중요하다고 생각합니다.
그리드, 컴포넌트, 엑셀 그 외 세팅하기
실무에 자주 쓰이지만 잘 모르는 것 중에 하나는 그리드입니다. 그리드라는 것이 아주 공통적으로 사용되는 용어는 아닌데요. 대부분의 툴에서는 그리드라고 이름을 많이 붙이는 듯합니다. 그리드는 엑셀 같은 표와 같이 데이터를 처리하고 수정하고 저장할 수 있게 만들어주는 라이브러리 중 하나입니다. 다양한 그리드가 있는데요. 관리자 페이지들이 이런 그리드 형태로 많이 되어있습니다. 이런 그리드의 데이터 처리가 중요한데요. 실제로 실무상에서는 조회 페이지나 검색 페이지들을 개발할 일이 아주 많습니다. 실무자들이 보는 화면들 중에는 데이터를 검색해서 봐야 하고 수정해야 하고 검색해야 하는 것들이 매우 많습니다. 이런 일들을 처리해 주기 위해서는 이런 그리드 화면이 필수라고 할 수 있죠. 그리고 컴포넌트는 그런 그리드들을 사용하거나 다양한 것들을 사용하기 위해서 필요한 항목들인데요. html로 보면 <input>, <areatext>, <select>, <datepicker> 등등의 컴포넌트를 의미합니다. 즉 화면상에 나오는 입력화면, 텍스트 화면, 에디터, 선택하는 버튼, 그리고 날짜 선택이나 캘린더 등등 개발에 필요한 다양한 컴포넌트들이 있는데요. 자주 사용한 사람의 입장에서는 뭐 뭐가 되었든 가져다 쓰면 되는 게 아닌 건가 싶지만, 실무를 안 해보거나 이런 부분을 자주 접하지 않은 입장에서는 이런 칼렌더 하나도 가져다 쓰는 것을 생각하는 것이 아니라 다 하나씩 개발하느라고 시간들을 보내는 경우가 많거든요. 물론 이런 하나하나를 개발하다 보면 내부 로직을 이해하고 실력이 쌓이긴 하지만, 개발 시간을 단축시켜줄 수는 없습니다. 이런 차원에서 이런 컴포넌트들을 찾아보고 이해하고 알아두는 것은 매우 중요합니다.
시간 날 때 깃허브에 들어가서 다양한 컴포넌트나 라이브러리를 찾아보는 일도 매우 중요한 일이죠. 그리고 이미지를 업로드하거나 엑셀을 업로드 다운로드하는 다양한 라이브러리를 사용해 보는 것, 그리고 개발 환경을 세팅해보는 일들, 이런 사사롭고 소소한 일들은 매우 시간이 걸리지만 누가 잘 파악하지 못하는 일들 중 하나일 것입니다. 지금 처음에 배울 때 이런 항목들을 잘해보면서 많이 찾아보면서 배워두는 일 중요한 것 같아요.
회사에서 특정 일들을 하다 보면 대부분이 매뉴얼화되어있기 때문에 설치 과정 조차 거의 매뉴얼 대로만 하면 되어서, 거의 개발에만 집중하게 되어있기 때문에 관심을 가지지 않다 보면 프로젝트를 하려고 하더라도 이런 세팅에 대해서는 매우 난감한 상황이 발생할 수도 있으니까요.
커뮤니 케이션 하기 (사람마다 다른 상사)
실무에 가장 어려운 것 중 하나는 커뮤니케이션입니다. 요새 회사들은 이런 커뮤니케이션 스킬을 배우거나 늘리기 위해서 다양한 것들을 하고 있는데요. 기업문화를 바꾼 다던지, 지라나 빗 버킷, 깃허브 같은 툴을 도입한다던지, 노션 같은 것들을 도입한다던지 하는 툴을 바꾸고 문화를 바꾸는 문화들이 조금씩 자리를 잡고 있습니다.
하지만 가장 어려운 것 중에 하나는 나의 상사가 어떤 사람일지 알 수 없다는 부분인데요. 대표가 어떤 사람인지 모르고, 상사가 어떤 사람인지 모르기 때문에 그냥 커뮤니케이션을 잘한다. 일을 잘한다. 이것 자체가 성립하기 위해서는 윗사람과의 코드를 잘 맞추어야 합니다.
윗사람이 야근을 좋아하는 사람일 수도 있고, 자리를 오래 지키는 걸 좋아하는 사람일 수도 있고, 일을 너무 잘하지 않길 바라는 사람일 수도 있거든요. 이 모든 것들은 회사가 각기 특이한 특이점들이 있기 때문입니다. 윗사람의 생각을 뜯어볼 수 없기 때문에 우리는 그 불안감들로부터 자유로울 수 없습니다.
회사가 커지면 정치라는 이야기를 들어본 적이 있을 것입니다. 막 성장하는 회사들은 이런 것을 느낄 틈이 없습니다. 일만 잘하면 되거든요. 근데 이미 커져버린 회사는 이미 수익 구조가 탄탄해졌기 때문에 성장이 도태되는 느낌이 들기도 합니다. 그 뒤에 일어나는 일들은 성장의 맛을 본 사람들이 떠난다는 것입니다. 새로운 성장으로 가야 하거든요. 그렇게 되면 그 뒤에 일은 뻔합니다. 남은 사람들이 나누어 먹기를 하게 되는 거죠. 그럼 그 남은 사람들 밑에 있는 사람들이 바로 그 정치의 피해자가 됩니다. 일을 왜 많이 했는지, 왜 적게 했는지, 그리고 수많은 부서이동, 성과와 실적 같은 것이 어떻게 평가되는지 아랫사람들은 매우 난해해지는 상황들, 현상을 이해하기 위해서는 한 가지만 보는 것이 아니라 여러 가지 상황들을 맞물려 해석해야 합니다. 이렇게 정치적인 상황은 매우 복잡한 상황이 됩니다. 평가의 방식도 난해해지고, 결과도 난해해지니까요.
우린 이런 상황들을 회사기 때문에 보다 자주 겪습니다. 그래서 소통은 어렵습니다. 가치와 주관이 다르고 그리고 이런 상황 속에서 선택을 해야 하기 때문입니다. 따라서 소극적으로 대응할 수 있는 한 가지 방법은 소통에 있어서 그 사람의 성향과 상황에 따라서 맞추어 주는 것입니다. 그리고 그렇게 맞추어 갈 때 소통을 잘한다. 커뮤니케이션이 되는 사람이다라는 이야기를 듣게 됩니다.
사람에게 먼저 맞추면 그다음에 일은 매우 수월합니다. 사람과 사람의 상대가 어그러지면, 일처리도 매우 힘들어집니다. 그건 비단 개발의 문제만은 아니죠. 그렇기 때문에 커뮤니케이션의 가장 중요한 것 중에 하나는 그 사람이 원하는 것이 무엇인지를 파악하는 것입니다. 그때 비로소 일정을 조율할 수 있고, 우선순위를 조절할 수 있고, 그리고 개발 시간과 역량과 결과들이 뒤따르게 됩니다.
그리고 최근 깃과 관련된 기업의 요구사항들이 많아지고 있는데요. 혼자 개발을 하다 보면, 내 코드를 오픈한 적도 없고, 피드백받은 적도 없고, 현재 잘하고 있는 것인지 아닌지를 판단할 기준들이 없기 때문에 함께 코웍을 하면서 개발에 대해서 같이 리뷰 시간을 가져보는 것이 중요합니다.
맺음말
몇 가지 개발의 실무적 상황과 필요한 것들에 대해서 이야기를 해보았는데요.
처음엔 무엇보다 뭔가를 해야 하는데 잘할 수 있을까라는 생각들,
할 수 있을까? 이런 생각들 때문에 머뭇거리는 경우들이 생기는 것 같습니다.
일단 책과 실무의 차이점은, 책은 다 봐야 그다음 뭘 시작할 수 있는데
실무에 있어서는 책을 다 볼 시간이 없다는 점이고요.
시간을 단축하기 위해서는 모든 방법을 동원하게 됩니다.
지인 찬스, 웹 서핑, 분석
일을 잘한다는 건 이런 전제조건에 개입하는 것이 아니라 결과 대해서 이야기하는 것입니다.
과정도 너무 중요합니다만, 개발의 시간을 단축시키는 다양한 방법들
타인의 소스를 이해하고 분석하는 것들을 자주 하다 보면
그 역량이라는 것이 실무라는 것이 좀 더 쉽고 보다 빠르게 이해되는 시점이 오지 않나 생각해 봅니다.
처음부터 잘하는 사람이 어딨나요. 부딪혀보다 보면 잘하게 되지 않나 싶네요!!
