소프트웨어 전문 기업에서 연구 방법
최근 신입 연구원 지망자들을 면접하면서 소프트웨어를 직업으로 삼으려는 학생들 수준이 예전보다 많이 높아졌음을 느낀다.
국민적으로 소프트웨어의 중요성에 대한 평가가 그만큼 올라갔고, 또 소프트웨어를 통한 자기 실현의 기회가 상대적으로 많아졌기 때문인 것 같다.
아래는 소프트웨어 전문 기업의 연구소를 이끌면서 느끼는 개인적 감흥이라고 할 수 있겠다.
너무 당연한 이야기일지 모르지만, 실제로는 잘 되지 않는 것들에 대한 기록이다.
연구원별 과제 선정
소프트웨어 기업의 연구소는 어느 수준 이상의 연구개발 능력이 필요한 곳이다.
연구원들은 모두 동일한 능력을 갖지 않는다. 지적 노동을 하는 연구원들은 수준이 천차만별이지만, 일단 연구원으로서 연구개발 업무를 수행하기 위해서 필요한 기본 수준은 만족해야 한다.
우수한 인재
매우 우수한 사람은 흥미를 잃지 않을 주제를 주면 알아서 잘 한다. 이런 경우에는 어떤 가치 있는 주제를 기업 차원에서 연구해야 하는지 고민하고 이를 연구원과 잘 컨센서스를 이루는 것이 중요하다. 연구 주제에 흥미를 잃거나 포커스를 놓치게 되면 동기 부여에 실패하여 퍼포먼스가 급격하게 떨어지고, 타 회사로 이직을 고민하게 되는 경우가 있다.
연구의 가치와 방향에 대해서 항상 잘 조율이 되어 있어야 하고 초기에 궤도에 오를 때까지 주제와 방향을 잘 공유해야 한다.
평범한 인재
반면 상대적으로 평범한 연구원들도 많이 있다.
보통의 연구원들은 주제를 정해준다고 해서 충분히 방향을 잘 정하지 못하는 경우가 많다.
연구원의 능력에 따라 주제와 범위, 그리고 해결에 대한 방향까지 제시해줘야 하는 경우가 종종 생긴다. 이런 연구원들은 코칭이 늘 필요하고, 수준에 맞게 연구 수준과 범위를 좁혀줄 필요가 있다.
잠깐만 방향을 잃어도 퍼포먼스가 급격하게 떨어지는 경우가 많으므로 관리는 시간적으로 더 자주 일어나야 한다.
매니저와 연구원
연구 과제는 연구소에서는 누구나 진행할 필요가 있다.
단순 관리자가 필요하지 않은 연구소의 특성 상, 상위 관리자도 역시 기본적으로는 연구를 진행하고 또 리딩해야 한다.
매니저/디렉터는 전략적 판단이 필요하고 범위가 넓은 경우에 대해서는 직접적인 연구를 진행하거나 집중적으로 리딩하는 게 좋다. 물론 매니저가 개발까지 직접 담당할 필요는 없다.
개별 연구원은 상대적으로 범위가 좁고, 깊이가 필요한 경우에 대해 직접적인 연구 개발을 진행하는 것이 일반적으로 효율적이다.
(천재 연구원이라면 범위나 깊이 모두 고려 사항이 아니다. 가장 복잡도가 높은 핵심 연구를 맡겨야 한다.)
연구 과제를 공유하는 내부 세미나 준비
연구소의 소프트웨어 연구 개발은 주로 특정 영역을 이해하고 이를 아키텍처 측면에서 검토하고 설계를 진행하는 영역이 주가 된다.
시스템 소프트웨어는 특성 상 단순 개발보다는 늘 설계가 선행되어야 하는 복잡성 높은 소프트웨어이기 때문에 개발을 위한 개발은 지양하고 전체를 이해하는 설계를 전제로 개발하는 게 일반적이다.
설계나 특정 영역의 이해와 같은 연구를 진행하기 위해 필요한 단계들은 어떤 경우든 반드시 거칠 필요가 있는데 개별 연구원들은 다음 단계를 통해 검증된 결과를 연구소의 여러 단위(팀-실-연구소 등)에서 공유하도록 한다.
기술 세미나를 준비할 때에는 다음의 단계가 필요하다.
1. Analysis Phase
첫번째 단계는 해당하는 도메인 지식들의 분석과 관련 지식들의 탐색이다.
연구소에 있으면서 기술 회의를 매우 많이 진행하는데 신입 연구원들에 비해 타 기업이나 국책 연구소에 있다가 경력으로 들어온 연구원들이 잘 적응하지 못하는 경우가 있다.
대부분 분석 능력에서 차이가 많이 난다.
이것은 우리나라 소프트웨어 기업 문화의 문제라고도 볼 수 있는데 소프트웨어 개발자들이 설계 수준이나 이해의 수준이 별로 높지 않고, 스펙이나, buzzword나 블로그, 컨설팅 회사의 주장을 그냥 암기하는 경향이 강하기 때문이다.
비판적 분석을 하지 못하고 좋은 말들만 옮기기 때문에 이해의 수준이 떨어지고, 또 대부분 영어로 된 글들을 그저 암기하기 때문에 실제 그 영어 단어들이 무슨 뜻인지 모르고 고유명사처럼 옮기는 경우가 많이 있다.
단순한 외부 스펙이나 주장의 요약에 그치는 경우가 많아 그 주장의 배경이나 메커니즘을 설명하지 못해 이해조차 이루지 못하는 경우가 종종 있다.
또, 이해의 수준이 피상적이기 때문에 여러 사람들이 토론을 통해 인식의 오류를 지적하고 더 나은 대안을 찾는 문화에도 잘 적응을 하지 못한다.
오히려 신입 연구원들은 이러한 나쁜 습성이 없어서 적응을 빨리 하는 경향이 있다.
Analysis Phase에서는 분석과 bottom-up의 과정이 계속 반복되어야 한다.
분석의 반복 과정에서 명심해야 할 세 가지는 다음과 같다.
2. Storyline Phase
두번째 단계는 스토리라인을 만들면서 생각을 정리하는 단계이다.
스토리라인을 만들면서 다시 분석과 스토리라인 보완을 반복한다.
생각을 정리하는 단계를 굳이 스토리라인이라고 표현하는 이유는 생각의 전체적인 흐름이 표현되도록 기승전결을 갖추어 정리하는 게 좋기 때문이다.
3. Deepening Phase
세번째 단계는 스토리를 심화시켜 의도했던 바가 이루어졌는지 점검하는 단계이다.
원래의 의도가 현재까지 분석 속에서 이루어졌고, 또 스토리 라인에 반영이 되었는지 체크를 한다.
이 단계에서 각 기술 요소들의 배경, 원인에 대한 부분이 제대로 파악되었는지 재점검을 한다.
빠지거나 부족한 부분에 대해서 다시 Analysis와 Storyline 보완을 반복한다.
4. Decision Phase
결론에 해당하는 부분을 의도와 시나리오에 맞게 검토한다.
실질적인 판단이 이루어지고 결론이 내려져야 한다.
물론, 결론이 완성되지 못하고 다음 연구로 이어질 부분에 대해서는 다음 연구 과제 후보로 큐잉한다.
위의 Phase들은 세미나 발표의 단계라기보다는 연구의 일반적인 판단 및 결정의 단계라고 볼 수 있을 것이다.
많은 연구원들은 1,2단계를 한번만 거치고 세미나를 하는 경향이 있다.
하지만, 의미있는 연구의 결과를 공유하기 위해서는 훨씬 더 많은 iteration이 이루어져야 한다.
storyline을 1차로 구성한 이후에도 전체적인 맥락과 개별 기술적 논리 검증 과정에서 3단계가 한 번 이상 처음부터 끝까지 검토하면서 이루어져야 하고, 마지막 결론부를 작성하기 이르러서는 다시 한 번 전체적인 논지의 문제에 대한 점검이 이루어져야 한다.
여러번의 iteration을 거치면서 사고의 흐름을 계속 유지하고 있어야 하기 때문에 연구의 성과는 집중도에 의해 많이 좌우된다. 생각이 끊어지면 좋은 결론과 더 나은 아이디어가 나올 수가 없다. 몰입(Flow)이 필요하다.
한번만에 쉽게 좋은 결론을 내릴 수 있는 경우도 없다고 할 수는 없겠지만, 그런 경우는 상대적으로 잘 알려진 기술이거나 scope이 작은 경우일 것 같다.
성급한 결론이나 단순한 지식의 전달은 좋은 연구라고 하기 어렵다.
연구소는 늘 팀 이상의 집단 공유를 거쳐서 결과물을 검증하고 평가한다.
시스템 소프트웨어 기업의 유의미한 발전은 이러한 성과들 하나하나에 기초하기 때문이다.
맺는 말
연구원들에게 늘 동기 부여를 하고 또 가치있는 성과를 만들어내도록 하는 것은 정말 어려운 일이다.
연구소는 세미나 발표를 연구원의 성과를 공유하고, 또 평가하는 목적으로도 활용하며, 또 세미나 준비 과정에서 연구원들의 지적 성장을 유도하는 코칭의 목적으로도 활용한다.
교육 효과를 나타내는 교육 피라미드를 보면 일방적으로 수업을 듣는 방식은 학생들의 교육 효과가 그다지 높지 않다.
가장 효과가 좋은 방식은 학생이 선생이 되어 직접 가르쳐보는 것이다.
세미나 발표는 학생에게 선생이 되는 계기를 만들어준다.
물론 이런 회의에 참여하는 사람들의 적극적인 문답을 통한 공유도 중요하다. 소크라테스의 문답을 통한 교수 과정처럼.
깊이 있는 기술적 창의는 문화가 뒷받침해야 함을 많은 기술 세미나와 여러 규모의 회의 속에서 수없이 되새기게 된다.
국민적으로 소프트웨어의 중요성에 대한 평가가 그만큼 올라갔고, 또 소프트웨어를 통한 자기 실현의 기회가 상대적으로 많아졌기 때문인 것 같다.
아래는 소프트웨어 전문 기업의 연구소를 이끌면서 느끼는 개인적 감흥이라고 할 수 있겠다.
너무 당연한 이야기일지 모르지만, 실제로는 잘 되지 않는 것들에 대한 기록이다.
연구원별 과제 선정
소프트웨어 기업의 연구소는 어느 수준 이상의 연구개발 능력이 필요한 곳이다.
연구원들은 모두 동일한 능력을 갖지 않는다. 지적 노동을 하는 연구원들은 수준이 천차만별이지만, 일단 연구원으로서 연구개발 업무를 수행하기 위해서 필요한 기본 수준은 만족해야 한다.
우수한 인재
매우 우수한 사람은 흥미를 잃지 않을 주제를 주면 알아서 잘 한다. 이런 경우에는 어떤 가치 있는 주제를 기업 차원에서 연구해야 하는지 고민하고 이를 연구원과 잘 컨센서스를 이루는 것이 중요하다. 연구 주제에 흥미를 잃거나 포커스를 놓치게 되면 동기 부여에 실패하여 퍼포먼스가 급격하게 떨어지고, 타 회사로 이직을 고민하게 되는 경우가 있다.
연구의 가치와 방향에 대해서 항상 잘 조율이 되어 있어야 하고 초기에 궤도에 오를 때까지 주제와 방향을 잘 공유해야 한다.
평범한 인재
반면 상대적으로 평범한 연구원들도 많이 있다.
보통의 연구원들은 주제를 정해준다고 해서 충분히 방향을 잘 정하지 못하는 경우가 많다.
연구원의 능력에 따라 주제와 범위, 그리고 해결에 대한 방향까지 제시해줘야 하는 경우가 종종 생긴다. 이런 연구원들은 코칭이 늘 필요하고, 수준에 맞게 연구 수준과 범위를 좁혀줄 필요가 있다.
잠깐만 방향을 잃어도 퍼포먼스가 급격하게 떨어지는 경우가 많으므로 관리는 시간적으로 더 자주 일어나야 한다.
매니저와 연구원
연구 과제는 연구소에서는 누구나 진행할 필요가 있다.
단순 관리자가 필요하지 않은 연구소의 특성 상, 상위 관리자도 역시 기본적으로는 연구를 진행하고 또 리딩해야 한다.
매니저/디렉터는 전략적 판단이 필요하고 범위가 넓은 경우에 대해서는 직접적인 연구를 진행하거나 집중적으로 리딩하는 게 좋다. 물론 매니저가 개발까지 직접 담당할 필요는 없다.
개별 연구원은 상대적으로 범위가 좁고, 깊이가 필요한 경우에 대해 직접적인 연구 개발을 진행하는 것이 일반적으로 효율적이다.
(천재 연구원이라면 범위나 깊이 모두 고려 사항이 아니다. 가장 복잡도가 높은 핵심 연구를 맡겨야 한다.)
연구 과제를 공유하는 내부 세미나 준비
연구소의 소프트웨어 연구 개발은 주로 특정 영역을 이해하고 이를 아키텍처 측면에서 검토하고 설계를 진행하는 영역이 주가 된다.
시스템 소프트웨어는 특성 상 단순 개발보다는 늘 설계가 선행되어야 하는 복잡성 높은 소프트웨어이기 때문에 개발을 위한 개발은 지양하고 전체를 이해하는 설계를 전제로 개발하는 게 일반적이다.
설계나 특정 영역의 이해와 같은 연구를 진행하기 위해 필요한 단계들은 어떤 경우든 반드시 거칠 필요가 있는데 개별 연구원들은 다음 단계를 통해 검증된 결과를 연구소의 여러 단위(팀-실-연구소 등)에서 공유하도록 한다.
기술 세미나를 준비할 때에는 다음의 단계가 필요하다.
1. Analysis Phase
첫번째 단계는 해당하는 도메인 지식들의 분석과 관련 지식들의 탐색이다.
연구소에 있으면서 기술 회의를 매우 많이 진행하는데 신입 연구원들에 비해 타 기업이나 국책 연구소에 있다가 경력으로 들어온 연구원들이 잘 적응하지 못하는 경우가 있다.
대부분 분석 능력에서 차이가 많이 난다.
이것은 우리나라 소프트웨어 기업 문화의 문제라고도 볼 수 있는데 소프트웨어 개발자들이 설계 수준이나 이해의 수준이 별로 높지 않고, 스펙이나, buzzword나 블로그, 컨설팅 회사의 주장을 그냥 암기하는 경향이 강하기 때문이다.
비판적 분석을 하지 못하고 좋은 말들만 옮기기 때문에 이해의 수준이 떨어지고, 또 대부분 영어로 된 글들을 그저 암기하기 때문에 실제 그 영어 단어들이 무슨 뜻인지 모르고 고유명사처럼 옮기는 경우가 많이 있다.
단순한 외부 스펙이나 주장의 요약에 그치는 경우가 많아 그 주장의 배경이나 메커니즘을 설명하지 못해 이해조차 이루지 못하는 경우가 종종 있다.
또, 이해의 수준이 피상적이기 때문에 여러 사람들이 토론을 통해 인식의 오류를 지적하고 더 나은 대안을 찾는 문화에도 잘 적응을 하지 못한다.
오히려 신입 연구원들은 이러한 나쁜 습성이 없어서 적응을 빨리 하는 경향이 있다.
Analysis Phase에서는 분석과 bottom-up의 과정이 계속 반복되어야 한다.
분석의 반복 과정에서 명심해야 할 세 가지는 다음과 같다.
- Finding Key Problems 풀려고 하는 핵심 이슈는 무엇인가? 현재 다루는 연구 도메인의 핵심 문제를 파악해야 한다.
- Why 왜 이렇게 했을까? 각각의 메커니즘들의 배경을 유추해야 진정한 이해가 된다.
- Recognize Hidden Problems 각 결정들, 혹은 해법에 대한 문제점은 무엇인가? 문제가 없는 해법은 없다. 제시한 해법들에 대한 드러나지 않은 문제를 파악해야 한다.
2. Storyline Phase
두번째 단계는 스토리라인을 만들면서 생각을 정리하는 단계이다.
스토리라인을 만들면서 다시 분석과 스토리라인 보완을 반복한다.
생각을 정리하는 단계를 굳이 스토리라인이라고 표현하는 이유는 생각의 전체적인 흐름이 표현되도록 기승전결을 갖추어 정리하는 게 좋기 때문이다.
3. Deepening Phase
세번째 단계는 스토리를 심화시켜 의도했던 바가 이루어졌는지 점검하는 단계이다.
원래의 의도가 현재까지 분석 속에서 이루어졌고, 또 스토리 라인에 반영이 되었는지 체크를 한다.
이 단계에서 각 기술 요소들의 배경, 원인에 대한 부분이 제대로 파악되었는지 재점검을 한다.
빠지거나 부족한 부분에 대해서 다시 Analysis와 Storyline 보완을 반복한다.
4. Decision Phase
결론에 해당하는 부분을 의도와 시나리오에 맞게 검토한다.
실질적인 판단이 이루어지고 결론이 내려져야 한다.
물론, 결론이 완성되지 못하고 다음 연구로 이어질 부분에 대해서는 다음 연구 과제 후보로 큐잉한다.
위의 Phase들은 세미나 발표의 단계라기보다는 연구의 일반적인 판단 및 결정의 단계라고 볼 수 있을 것이다.
하지만, 의미있는 연구의 결과를 공유하기 위해서는 훨씬 더 많은 iteration이 이루어져야 한다.
storyline을 1차로 구성한 이후에도 전체적인 맥락과 개별 기술적 논리 검증 과정에서 3단계가 한 번 이상 처음부터 끝까지 검토하면서 이루어져야 하고, 마지막 결론부를 작성하기 이르러서는 다시 한 번 전체적인 논지의 문제에 대한 점검이 이루어져야 한다.
여러번의 iteration을 거치면서 사고의 흐름을 계속 유지하고 있어야 하기 때문에 연구의 성과는 집중도에 의해 많이 좌우된다. 생각이 끊어지면 좋은 결론과 더 나은 아이디어가 나올 수가 없다. 몰입(Flow)이 필요하다.
한번만에 쉽게 좋은 결론을 내릴 수 있는 경우도 없다고 할 수는 없겠지만, 그런 경우는 상대적으로 잘 알려진 기술이거나 scope이 작은 경우일 것 같다.
성급한 결론이나 단순한 지식의 전달은 좋은 연구라고 하기 어렵다.
연구소는 늘 팀 이상의 집단 공유를 거쳐서 결과물을 검증하고 평가한다.
시스템 소프트웨어 기업의 유의미한 발전은 이러한 성과들 하나하나에 기초하기 때문이다.
맺는 말
연구원들에게 늘 동기 부여를 하고 또 가치있는 성과를 만들어내도록 하는 것은 정말 어려운 일이다.
연구소는 세미나 발표를 연구원의 성과를 공유하고, 또 평가하는 목적으로도 활용하며, 또 세미나 준비 과정에서 연구원들의 지적 성장을 유도하는 코칭의 목적으로도 활용한다.
교육 효과를 나타내는 교육 피라미드를 보면 일방적으로 수업을 듣는 방식은 학생들의 교육 효과가 그다지 높지 않다.
가장 효과가 좋은 방식은 학생이 선생이 되어 직접 가르쳐보는 것이다.
세미나 발표는 학생에게 선생이 되는 계기를 만들어준다.
물론 이런 회의에 참여하는 사람들의 적극적인 문답을 통한 공유도 중요하다. 소크라테스의 문답을 통한 교수 과정처럼.
깊이 있는 기술적 창의는 문화가 뒷받침해야 함을 많은 기술 세미나와 여러 규모의 회의 속에서 수없이 되새기게 된다.
댓글