연구와 회사일의 차이

연구 : 처음부터 좋은 생각과 취지, 적합한 구조가 아니면 디스커션에서 지적받기 쉽고 논문조차 낼 수 없다. 성능개념이 실 사례와는 동떨어진 기준이지만 더 나은 알고리즘을 개발했다고 한다면 성능향상은 기본적으로 증명해내야 한다.

회사일 : 목적이 우선시 되고 좋은 생각과 취지여서 시작하는 것으로 한다. (퉁친다)
처음부터 아키텍트가 참여하긴 할지라도 우선 목적을 위해 시작한다. 구조는 결과물을 우선 볼 수만 있다면 한다.
성능향상을 위해 시간과 비용이 더 소요된다면 낮은 수준의 구조를 택한다.
그리고 추후에 아키텍트 또는 이것을 아는 실제 참여자는 성능향상이라는 두번째 임무를 수행하게 된다.

연구는 첨부터 잘해야한다.
회사일은 두번째 유지보수를 더 잘해야한다.
 
연구에서 과정을 무시하고 결과물부터 만들고자 한다면 오래 견딜 수도 없으며 학자로 인정받기 힘들다. 남의 손을 빌리든간에 꼭 과정에 대한 증명이 필요하다.

회사일에서 처음부터 잘하려고하면 리더쉽과 실력도 없으면서 아는 척하는 사람으로 되기 쉽다. 소공의 공식은 애매한 것이다. 내가 만든 소프트웨어공식과 회사에서 만드는 공식은 서로 다를때가 많다.

제일 하지 말아야할 말 '이렇게 하면 나중에 유지보수 비용이 너무 많이 듭니다.' 
모두들 이 사실을 모르는 것이 아니다. 알고 있다.

하지만 추후에 어떤 일이 생기더라도 자신의 성과에 귀결되는건 좋은 구조가 아닌 '할일이 있다는 것'이다.

상사가 양보다 질이라는 것을 안다면, 앞만 보고 새로운 것을 하는 조직이라면 연구성격이 강한 형태를 띄지만 그렇지않은 경우가 적지 않다.

무지 단순한 것을 계획없이 되는대로 만들고 그 과정조차 힘들었다고 하는 그들이 나중에 이렇게 말하는 것을 들을 것이다.

"우리는 중대한 구조적 결함을 찾아내 수정하였으며 팀원전체가 리팩토링을 하니 속도가 크게 향상 되었어요"