페이스북에 짧게 적었던 글을 좀 길게 적습니다.
---
지난 밤에 읽은 책에서 (전체 내용과 관계가 적으므로 책 제목은 생략합니다) "과학자는 해법을 찾은 뒤에 그것을 적용할 문제를 고민하는데 반해, 엔지니어는 문제를 규정한 이후에 해법을 찾는다는 차이가 있다"라고 적혀있었다. 순수학문과 응용학문의 차이를 잘 설명해준다.
똑같지는 않지만 비슷한 고민을 오랫동안 해왔다. 나는 또는 내가 속한 팀은 기술 스택에 집중해서 다양한 기술을 연마하거나 알고리즘을 개발해서 서비스 분야에 접목을 시켜야 할지 아니면 서비스 스택에 더 집중해서 도메인/비즈니스 지식을 쌓은 후에 다양한 기술/알고리즘을 차용해서 현재의 문제를 해결해야 할지를 결정해야 했다. 현재 이도저도 아닌 어중간한 상태에 머물러 있어서 갈피를 못잡고 표류하고 있는 듯하다.
인터넷 서비스 회사를 다니는 사람들이라면 비슷한 고민을 하고 있을 것이다. 매일 새로운 기술이 쏟아지고 트렌드는 급변하는 상황에서 기술적 완성도도 어정쩡하고 서비스의 디테일도 어정쩡한 상태에 이른 경우가 많을 것이다. 기술에 집중하자니 발등에 떨어진 불이 너무 커고, 그렇다고 발등의 불부터 꺼자니 시대에 뒤떨어지는 악순환이 이어진다. 작은 조직에서는 이 둘을 동시에 해결해야하기 때문에 어렵다. 그러나 웬만큼 큰 조직에서는 팀별로 성격을 나눠서 전문성을 가질 수 있고, 또 가져야 한다. 그래야지 기술 스택과 서비스 스택이 명확히 세워지고, 필요에 따라서 서로 결합해서 새로운 것을 창조할 수가 있다.
우리 팀의 핵심이 뭘까?를 항상 고민한다. 윗선에서 제대로 된 비전을 보여준다면 그것을 믿고 따르면 되겠지만, 최근 분위기가 녹록치가 않다. 그렇기에 혼자서 고민하는 것같다. 팀의 정체성은 팀이 맡고 있는 서비스일까 아니면 팀이 가지고 있는 기술/지식일까? 팀의 core competence가 뭘까를 고민하게 된다. 팀의 핵심 역량을 정하고 그것을 극대화시킨 이후에, 다른 영역에 적용을 하거나 아니면 다른 영역의 기술을 차용해야 방향이 잡힌다. 그러나 그러지 못하는 경우가 허다하다. 실질적으로 대부분이 그럴 것이다.
확실한 기술을 가지고 있으면 웬만한 문제에는 적용이 가능하고, 또 괜찮은 서비스/문제를 쥐고 있으면 또 다양한 기술들을 적용해볼 수가 있다. 그렇기에 (큰) 조직에서는 기술스택과 서비스스택을 명확히 구분해서 서브유닛별로 명확히 할 필요가 있다. 그리고 특화된 유닛끼리는 문제/상황에 맞도록 적절히 조화를 이뤄서 새로운 서비스를 만들어내거나 당면한 문제를 해결할 수가 있어야 한다.
(개인적으로) 스페셜리스트보다는 제너럴리스트를 더 선호하지만, 한두가지의 스페셜한 기술이 없는 제너럴리스트는 결국 허상을 쫓게 되고, 역으로 일반적인 시각이 없는 스페셜리스트도 그 길이 잘못되었다고 (늦게) 판명이 나면 필망에 이른다.
올바른 해답은 올바른 문제/질문에서 시작된다. 물론 문제가 옳다고 해서 옳은 해답을 찾는다는 보장은 없다. 그러나 잘못된 문제에서 옳은 해답을 찾을 수는 결코 없다. 그렇다면 올바른 문제부터 찾아야 하는 걸까? (기술에 특화된 조직이 아닌 또는 원천기술이 없는) 작은 조직이라면 문제를 먼저 찾아야 한다. 투명하게 정보 (지식)가 공유되는 요즘 시대에, 문제가 잘 정의되면 적당한 답을 찾는 것은 별로 어렵지가 않다. 그러나 그런 경우 자기만의 해답을 찾지 못할지도 모른다.
저의 개인적인 성향은 서비스 오리엔테이션입니다. 그리고 요즘은 데이터 사이언스라고 부르기도 하지만, 현실에서 데이터마이닝은 데이터 엔지니어링에 더 가깝고, 그래서 비즈니스/도메인 지식과 데이터 자체에서 오는 인사이트가 많이 필요합니다. 그러나 좀더 사이언스적인 접근을 해보고 싶다는 욕구도 있습니다. 팀 자체의 아이덴터티가 예전과 많이 바뀐 상황에서 여전히 한두개의 서비스에만 매여있으면 안 될 것같습니다.
글을 적다보니 논점이 자꾸 흐려진다. ... 어쨌든 현재 나 또는 우리 팀은 해법을 찾는 것에 집중해야 한다고 생각한다. 그러나 분위기가 그렇지 못 하다.
페이스북 페이지: https://www.facebook.com/unexperienced
