최근에 드는 몇 가지 생각

오만과 편견(?)

나름 개발자들에게는 올바른 방향을 제시하고 공감하며 의미 있는 무엇인가를 만들어 왔다고 생각했다. 그런데 내가 생각한 개발자의 범위는 너무 좋은 것 같다. 케타포에서는 기획자, UX, 데이터 분석가도 개발 조직에 있고, 나는 그들이 개발 조직에 있는 게 맞다고 생각하고 그들에게도 내가 좋은 방향을 제시할 수 있다고 생각하고 지난 4달 정도를 보냈다. 그런데 지난주 한분이 이직을 하시겠다고 하셨고, 나는 그분을 말릴 수 없었다. 내가 그분에게 잘해 준 것도 없고 도와드릴 방법도 몰라서...

그러고 나서 생각을 해 보니 내가 아는 개발은 주로 자바, 데이터베이스, 웹 등을 활용한 서버 개발이었다. 자바스크립트, 브라우저에 대한 지식과 경험이 필요한 프런트엔드 개발만 봐도 나는 아는 게 너무 없었다.

답답하고 급한 마음에 내 생각을 너무 강요한 것은 아닌가 하는 생각이 많이 든다.

어쩌면 그분은 우리 회사나 나와 안 맞는 분일 수도 있을 것이다. 여기서 내가 더 확신을 가지고 내가 생각하는 방향으로 나가야 하는 것인지 의문이 들었고, 좀 더 겸손하게 배우는 자세로 임해야겠다는 생각이 들었다.

때와 장소에 맞는 전략과 전술

이 주제가 다소 거창하게 들리지만 과거와 요즘 겪었던 사례들로부터 지금 우리가 어떻게 일하는 게 좋은지 정리해 본다.

90년대 말, 2000년대 초에 개발을 할 때는 Unix 서버에 들어가서 vi로 코딩을 하기도 했었다. 이때는 잘 설계된 자료가 없다면 제대로 구현을 하기 어려웠다. 마치 거대한 숲의 어디에 있는지? 어디로 가야 하는지? 모르는 그런 상황에서 원하는 목적지로 가야 하는 것과 같은 그런 상황이었다. 그래서 그때는 사전 설계가 매우 중요했다. 설계도가 없으면 어디로 가야 할지 알 수 없었기 때문에...

이때를 보면 내가 처음 운전을 했던 때가 떠 오른다. 나의 첫 직장은 부평에 있었고, 그때 우리 집인 안양에서 부평으로 가는 가장 편한 방법은 제2 경인고속도로를 타고 가는 것이었다. 그때 나는 운전 초보였고, 내비게이션이나 티맵이 없을 때여서 미리 지도를 조사하고, 어느 길을 타고, 어디 교차로를 조심해야 하고 등을 세심히 설계(메모?)했다. 심지어 일요일에 예행연습을 하기도 했다.

지금은 어떤가? 작년에 아들이 운전면허를 땄다. 아들은 지도를 조사하는 등의 사전 준비를 하지 않는다. 그저 시동을 켜고는 티맵이 가라는 데로 간다. 마치 지금 개발자들이 요구사항을 들으면 설계 없이 바로 IDE를 띄워서 코딩을 하는 것과 유사하다. 물론 아들은 티맵이 가라는 길보다 나은 길을 경험으로 알게 되어도 아직은 티맵이 가라는 길로 가서 동승자를 다소 답답하게 한다. 이것은 리팩터링을 하지 않아 좋은 설계로 점진적으로 개선하며 좋은 아키텍처로 개선하지 못하는 것과 유사하게 대응되는 상황인 것 같다.

아들이 차량 운전에 정말 익숙하면 아마 다음에 같은 곳을 갈 때는 보다 최적화된 경로로 갈 수도 있을 것이다. 또 도구 사용에 정말 익숙하다면 목적지로 가는 것 외에 운전 자체를 좀 더 즐길 수 있을 것이다. 이 상황은 개발자들이 언어, 도구, 설계, 패턴 등에 익숙하면 프로그램이 동작하게 하는 것을 넘어서 변화하는 요구사항을 빠르고 안정적으로 수용할 수 있는 것과 유사한 상황인 것 같다.

나아가 내비로 목적지를 검색을 하고 바로 출발하기보다 전체 경로를 한번 살펴보고 출발을 한다면 운전 중에 헤매는 상황이 발생할 확률이 훨씬 줄어들 것이다. 이는 IDE로 바로 시작을 할 수 있더라도 한 주 정도에 개발할 것에 대해서 화이트보드나 종이에 간단하게 설계를 해 보는 것과 유사할 것이다. 이런 대략의 설계를 가지고 개발을 하면 꼭 설계대로 진행을 하진 않더라도 올바른 방향으로 전체를 고려하면서 개발을 하는데 큰 도움이 될 것이다.

우리는 지금 우리가 처한 상항에 맞는 기술(지도, 내비게이션)을 잘 익혀서 비즈니스 가치를 빠르게 만들고 지속적으로 변경할 수 있는 전문성을 키워야 한다고 생각한다. 지금도 지도에만 의존하고 사전 설계에만 의존해서는 안될 것 같다. 적합한 도구를 잘 익히고 활용해서 좀 더 애자일 하게(TDD, Refactoring, Simple Design, Pair Programming 등의 애자일 기술 실천 방법을 통해) 더 큰 가치를 빠르게 또 향후 변경 비용(변경으로 인한 복잡성은 SW 공학의 피할 수 없는 본질)을 고려하여 높은 품질로 만드는 것이 중요하다고 생각한다.

채용에 대해서

이직 후 2달 정도 되었을 때 이전 직장에서 인재 한 분을 모셔왔다. 그분은 내가 기대했던 것보다 더 우리 회사에 잘 맞는 분이었다. 너무 감사한 경우였다.

이 외에 같이 했으면 하는 서너 분에게 의견을 물었는데 다 퇴짜를 맞았다. 그리고 한분은 오시겠다고 했지만 협상이 잘 되질 않았다. 아무래도 케타포가 개발자 중심의 회사도 아니었고, 판교에 있는 IT 회사들이나, 잘 나가는 스타트업에 비해 매력도 적고, 안정성도 적어서였을 것이다. 그때 현실을 좀 깨우친 것 같다. 지금의 나를 바라보는 시각은 내가 Daum / Kakao를 거쳐서 SK에 임원으로 갈 때랑은 다르다는 것을...

이후 아름아름 두 분이 입사를 하셨고, 한분이 차주에 입사를 하신다. 한분은 헤드헌터를 통해서이고 나머지 두 분은 고맙게도 내게 연락을 주셔서 함께 하게 되었다. 그런데 이 분들이 나를 포함한 기존 인력들의 기대 이상으로 역량도 갖추고 계시고, 우리와 화합도 잘 되는 것 같다.

그래서 지금은 이제부터는 알고 있는 분들에게 연락을 하는 것보다 우리가 한 일, 할 일 등을 잘 설명하고 이런 일들을 잘하실 수 있는 분들을 모시는 게 맞는 것 같다는 생각이 든다.

이기적 직원들이 만드는 최고의 회사에서 처럼 우리 회사가 최고여서가 아니라 우리 회사에서 기여하고 성장해서 최고가 되기를 원하는 분들을 많이 모시고 싶은 생각이다.

우려의 말씀

이번 글에는 다소 편협한 제 경험에 기반해서 불편하게 보실 분들도 계실 것 같습니다. 또 오만과 편견이 있는 것도 같습니다. "이런 고민을 하는 사람이 있구나" 정도로 봐주시면 감사하겠습니다.