기본 콘텐츠로 건너뛰기

소프트웨어 전문 기업에서 연구 방법

최근 신입 연구원 지망자들을 면접하면서 소프트웨어를 직업으로 삼으려는 학생들 수준이 예전보다 많이 높아졌음을 느낀다.
국민적으로 소프트웨어의 중요성에 대한 평가가 그만큼 올라갔고, 또 소프트웨어를 통한 자기 실현의 기회가 상대적으로 많아졌기 때문인 것 같다.
아래는 소프트웨어 전문 기업의 연구소를 이끌면서 느끼는 개인적 감흥이라고 할 수 있겠다.
너무 당연한 이야기일지 모르지만, 실제로는 잘 되지 않는 것들에 대한 기록이다.

연구원별 과제 선정

소프트웨어 기업의 연구소는 어느 수준 이상의 연구개발 능력이 필요한 곳이다.
연구원들은 모두 동일한 능력을 갖지 않는다. 지적 노동을 하는 연구원들은 수준이 천차만별이지만, 일단 연구원으로서 연구개발 업무를 수행하기 위해서 필요한 기본 수준은 만족해야 한다.

우수한 인재
매우 우수한 사람은 흥미를 잃지 않을 주제를 주면 알아서 잘 한다. 이런 경우에는 어떤 가치 있는 주제를 기업 차원에서 연구해야 하는지 고민하고 이를 연구원과 잘 컨센서스를 이루는 것이 중요하다. 연구 주제에 흥미를 잃거나 포커스를 놓치게 되면 동기 부여에 실패하여 퍼포먼스가 급격하게 떨어지고, 타 회사로 이직을 고민하게 되는 경우가 있다.
연구의 가치와 방향에 대해서 항상 잘 조율이 되어 있어야 하고 초기에 궤도에 오를 때까지 주제와 방향을 잘 공유해야 한다.

평범한 인재
반면 상대적으로 평범한 연구원들도 많이 있다.
보통의 연구원들은 주제를 정해준다고 해서 충분히 방향을 잘 정하지 못하는 경우가 많다.
연구원의 능력에 따라 주제와 범위, 그리고 해결에 대한 방향까지 제시해줘야 하는 경우가 종종 생긴다. 이런 연구원들은 코칭이 늘 필요하고, 수준에 맞게 연구 수준과 범위를 좁혀줄 필요가 있다.
잠깐만 방향을 잃어도 퍼포먼스가 급격하게 떨어지는 경우가 많으므로 관리는 시간적으로 더 자주 일어나야 한다.

매니저와 연구원
연구 과제는 연구소에서는 누구나 진행할 필요가 있다.
단순 관리자가 필요하지 않은 연구소의 특성 상, 상위 관리자도 역시 기본적으로는 연구를 진행하고 또 리딩해야 한다.
매니저/디렉터는 전략적 판단이 필요하고 범위가 넓은 경우에 대해서는 직접적인 연구를 진행하거나 집중적으로 리딩하는 게 좋다. 물론 매니저가 개발까지 직접 담당할 필요는 없다.
개별 연구원은 상대적으로 범위가 좁고, 깊이가 필요한 경우에 대해 직접적인 연구 개발을 진행하는 것이 일반적으로 효율적이다.
(천재 연구원이라면 범위나 깊이 모두 고려 사항이 아니다. 가장 복잡도가 높은 핵심 연구를 맡겨야 한다.)

연구 과제를 공유하는 내부 세미나 준비

연구소의 소프트웨어 연구 개발은 주로 특정 영역을 이해하고 이를 아키텍처 측면에서 검토하고 설계를 진행하는 영역이 주가 된다.
시스템 소프트웨어는 특성 상 단순 개발보다는 늘 설계가 선행되어야 하는 복잡성 높은 소프트웨어이기 때문에 개발을 위한 개발은 지양하고 전체를 이해하는 설계를 전제로 개발하는 게 일반적이다.

설계나 특정 영역의 이해와 같은 연구를 진행하기 위해 필요한 단계들은 어떤 경우든 반드시 거칠 필요가 있는데 개별 연구원들은 다음 단계를 통해 검증된 결과를 연구소의 여러 단위(팀-실-연구소 등)에서 공유하도록 한다.

기술 세미나를 준비할 때에는 다음의 단계가 필요하다.

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들은 세미나 발표의 단계라기보다는 연구의 일반적인 판단 및 결정의 단계라고 볼 수 있을 것이다.

많은 연구원들은 1,2단계를 한번만 거치고 세미나를 하는 경향이 있다.
하지만, 의미있는 연구의 결과를 공유하기 위해서는 훨씬 더 많은 iteration이 이루어져야 한다.
storyline을 1차로 구성한 이후에도 전체적인 맥락과 개별 기술적 논리 검증 과정에서 3단계가 한 번 이상 처음부터 끝까지 검토하면서 이루어져야 하고, 마지막 결론부를 작성하기 이르러서는 다시 한 번 전체적인 논지의 문제에 대한 점검이 이루어져야 한다.
여러번의 iteration을 거치면서 사고의 흐름을 계속 유지하고 있어야 하기 때문에 연구의 성과는 집중도에 의해 많이 좌우된다. 생각이 끊어지면 좋은 결론과 더 나은 아이디어가 나올 수가 없다. 몰입(Flow)이 필요하다.

한번만에 쉽게 좋은 결론을 내릴 수 있는 경우도 없다고 할 수는 없겠지만, 그런 경우는 상대적으로 잘 알려진 기술이거나 scope이 작은 경우일 것 같다.
성급한 결론이나 단순한 지식의 전달은 좋은 연구라고 하기 어렵다.

연구소는 늘 팀 이상의 집단 공유를 거쳐서 결과물을 검증하고 평가한다.
시스템 소프트웨어 기업의 유의미한 발전은 이러한 성과들 하나하나에 기초하기 때문이다.


맺는 말
연구원들에게 늘 동기 부여를 하고 또 가치있는 성과를 만들어내도록 하는 것은 정말 어려운 일이다.
연구소는 세미나 발표를 연구원의 성과를 공유하고, 또 평가하는 목적으로도 활용하며, 또 세미나 준비 과정에서 연구원들의 지적 성장을 유도하는 코칭의 목적으로도 활용한다.

교육 효과를 나타내는 교육 피라미드를 보면 일방적으로 수업을 듣는 방식은 학생들의 교육 효과가 그다지 높지 않다.
가장 효과가 좋은 방식은 학생이 선생이 되어 직접 가르쳐보는 것이다.
세미나 발표는 학생에게 선생이 되는 계기를 만들어준다.

물론 이런 회의에 참여하는 사람들의 적극적인 문답을 통한 공유도 중요하다. 소크라테스의 문답을 통한 교수 과정처럼.
깊이 있는 기술적 창의는 문화가 뒷받침해야 함을 많은 기술 세미나와 여러 규모의 회의 속에서 수없이 되새기게 된다.

댓글

이 블로그의 인기 게시물

Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다.

일단 생소하기 때문에 어렵다.

그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다.

먼저 G1GC를 이해하는 데 유용한 사이트이다.

Garbage-First CollectorGetting Started with the G1 Garbage CollectorUnderstanding G1 GC LogsTuning Garbage Collection for Mission-Critical Java ApplicationsControlling GC pauses with the GarbageFirst CollectorG1: One Garbage Collector To Rule Them AllGarbage First (G1) Garbage Collection Optionscompare JVM options for public메일 : G1 GC clean up time is too long
JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다.
(새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.)

지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다.
즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다.
앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다.

둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들에 대한 처리는 아직 최적화되지 않았다. 보통 한 region의 50% …

Heap Dump 분석을 통한 Perm Area Memory Leak 원인 진단

Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class…

새로운 관리자 모델은 훌륭한 코칭 능력을 필요로 한다.

"직원의 학습과 개발 70%는 일 자체에서 일어나지, 정형화된 교육 프로그램을 통해 일어나지 않는다."
관리는 많은 부분 코칭의 스킬을 필요로 하게 되었고, 코칭의 출발점은 Listening이다.
물론 관리자들도 코칭 및 관리 스킬을 개선하기 위해 코칭을 받을 필요가 있다.

코칭이 이루어지지 않거나 코칭 스킬이 개선되지 않는 회사는 미래 지향적 회사가 되지 못할 것이다.
시간을 이유로 좀처럼 사람들에게 귀기울이지 않는 기업은 결국 진보하지 못할 것이다.
Listening을 통한 Coaching과 Insight가 개선되는 조직이 지속적인 경쟁에서 성공할 수 있다고 할까.
그런 측면에서 위기는 listening을 징후로 하고 식별자로 리더의 코칭 능력 개선과 insight 능력을 들 수 있다.

그런데 듣기만 하고 insight가 없어서 코칭을 못한다면 이러한 기업은 정체할 뿐, 성장을 이끌지 못할 것이다.
코칭의 핵심은 멤버들과 코칭하는 관리자의 동반 성장이기 때문이고, 이를 통해 insight를 더 구체화하고 공유하는 것이기 때문이다.

코칭과 insight를 잘하는 리더 후보를 다수 보유한 기업이 진화하는 미래 지향 기업이라고 볼 수 있다.

관리자에 대해 코칭의 중요성을 지적한 아래 하바드 비즈니스 리뷰 글은 상당히 공감이 간다.

HBR 기사 원문 : 좋은 코치가 아니면 훌륭한 관리자가 될 수 없다.

아래는 기사를 대충 번역해본 것이다.

좋은 코치가 아니면 훌륭한 관리자가 될 수 없다. 2014년 7월 17일 Monique Valcour 글

가장 우선적으로 생각해야 할 리더십 덕목은 '사람들이 직장에서 경험하는 가장 강력하게 동기 부여하는 조건은 개인적으로 의미있는 무언가에서 진전을 이루는 것'임을 아는 것입니다.
당신이 누군가를 리딩하는 일을 하고 있다면 매일 해야 할 가장 중요한 일은 팀원들이 의미있는 일에서 진척을 경험하는 것을 것을 돕는 것입니다.

그렇게 하려면 각 멤버의 동인을 이해하고 각자의 일과 조직의 미션 및 전…