Design of Experiment
입사 후 처음 맡게 된 프로젝트는 제조 공정의 DOE(Design of Experiment) 를 수행하는 프로그램을 개발하는 일이었다.
느낀점 몇 가지.
- 데이터는 두 가지 종류가 있다. 쓸모 없는 데이터 또는 그냥 없는 데이터
어디선가 들은 말이고, 맞는 말이다.
그래서 데이터 수집과 정제가 정말 중요하다.
쓸모 없는 데이터라도 얻기 위해서는 많은 노력이 필요하고, 또 힘들게 데이터를 얻었다고 해서 끝이 아니다.
열심히 정제해서 의미 있는 데이터를 찾는 일이 결코 쉽지 않다.
- 데이터 시각화, EDA(Exploratory Data Analysis), 도메인 지식의 중요성
(무엇을 봐야 할 지 알고 난 다음의 시각화)
데이터가 있다고 해서 이 그래프처럼 특성이 보이는 feature 가 저절로 드러나지는 않는다.
도메인 지식이 없는 상태에서 어떤 feature를 어떻게 봐야 하는지 알아내는 데만 많은 시간과 노력이 필요했다.
예를 들면 위 데이터에서 두드러지는 autocorrelation 의 경우, 나중에 알고보니 도메인 전문가들은 모두 짐작하고 있는 특성이었다.
도메인 전문가의 도움을 받아 문제 해결의 실마리를 찾을 수도 있겠지만, 도메인이 복잡하면 복잡할수록 이것도 쉽지 않은 일이다.
스스로 도메인 전문가가 돼야 한다.
이 프로젝트는 여러가지 이유로 중단됐다.
나중에 이 프로젝트에 대해서 별도로 글을 써 보려고 한다.
새로운 언어 : C# 그리고 OOP
첫 프로젝트가 중단되고 C# 으로 구현된 솔루션의 유지보수를 맡게 됐다.
C# 과는 Hello world 인사도 해 본적이 없는 상태.
회사에 있는 책으로 C# 기본 문법을 익히는 일 부터 시작했다.
언어를 처음 배울때는 인터넷으로 찾아보는 것도 좋지만, 체계를 갖춰 기술한 책을 보는게 효율적인 것 같다.
그리고 다른 비슷한 개념을 알고 있으면 새로운 것도 쉽게 익힐 수 있다.
예를 들면 LINQ 의 경우 D3.js 의 chaining 개념과 비슷하다.
또 새로운 언어, 라이브러리를 익힐 때 좋은 방법 하나를 알게 됐는데, 이른바 Learning Test 를 작성하는 방법이다.
이게 뭐냐면 API 를 익히면서 sample code 를 테스트로 작성해 두는 것이다. 이렇게 했을 때 주요 장점중의 하나는
나중에 외부 라이브러리가 업그레이드 되면서 API 가 바뀌었을 때 쉽게 알아챌 수 있다는 것.
이건 클린코드 라는 책에서 봤다.
유지보수 업무를 진행하면서 언어는 도구에 불과하다는 말이 어떤 의미인지 알 수 있었다.
C# 은 한 번도 본 적이 없는 분이 C# 프로젝트를 맡자마자 바로 문제를 해결해 나가는 모습을 어깨 너머로 봤다.
언어가 중요한게 아니다. 기본이 중요하다.
그런데 기본이라는게 뭔가 ?
이 맥락에서의 기본은 객체지향 패러다임이다. (라고 배웠다.)
기본을 익히고자 객체지향의 사실과 오해 라는 책을 봤다.
이 책은 바로 나처럼
'객체지향 관점을 구현하기 위해 클래스라는게 있고, 클래스란 상태 변수와 메소드의 묶음이다.
그리고 클래스는 재사용 가능하도록 작성해야 한다'- animalgo, 초보
정도로 아는 사람을 위한 책이다.
물론 책 한 권 봤다고 저절로 기본이 쌓이지는 않는다.
객체지향 개념과 함께, 이것을 실제로 구현하기 위해서는 패턴과 아키텍쳐를 알아야 한다.
singleton 패턴, layered architecture 같은 기본적인 패턴, 아키텍쳐 단어 자체를 몰랐다.
이런 것에 이름이 있다는 사실 자체를 몰랐다.
물론 상식적인 수준에서 위 개념들을 이용하고는 있었다. 그러나 그 이상으로 알아야 할 필요성을 느꼈다. 왜냐하면
'개발자는 패턴을 가지고 이야기한다'
- DK, 고수
라는 가르침을 받았기 때문이다.
또 공부하지 않고 그 개념을 이해하고 적용하기 어려운 것도 있기 때문이다.
예를 들면 MVVM 이 그 중 하나다.
MVVM 이라는 게 있고, 여기서 VM 이란 ViewModel 의 약자라는 것 자체를 들어본 적이 없었다면 정말 많은 고생을 했을 것이다.
기존 코드의 ViewModel 이라는 단어를 보면서 도대체 이게 뭔지 감을 잡을 수가 없었을 테니까.
사실 아직 잘 모르겠다. 일단은 용어에 익숙해 졌다는 것 정도로 만족한다.
문서화
C# 을 익힌 것 만으로는 C# 업무를 하기에 부족했다.
처음으로 맡게 된 일은 솔루션의 DB 커넥션과 관련된 부분을 바꾸는 일.
일단 커넥션 정보를 바꾸려다 보니 솔루션 배포 구조를 수정해야 했다.
확인해 보니 인스톨러 생성에 NSIS 라는 것을 이용하고 또 batch script를 많이 활용하고 있었다.
두가지를 잘 몰랐지만 별 문제는 아니었다. 익히면 되니까.
가장 도움이 됐던 참고자료 :
- 실전코딩 NSIS 튜토리얼 : https://opentutorials.org/course/3362Steve
- Jansen 님의 Batch script 가이드 : http://steve-jansen.github.io/guides/windows-batch-scripting/
여기까지는 별다른 어려움이 없었다.
문제는 도저히 시스템 구성 요소, 구조를 알 수가 없다는 것이었다 !!!
아무도 아는 사람이 없고, 아무도 구조를 문서로 남겨놓지 않았다.
(사실 아는 사람이 없는게 아니라 그냥 아무도 없었다. 팀이 망했다...)
할 수 없이 하나 하나 테스트 해 보고, 소스를 보면서 알아가는 수 밖에 없었다.
<의존/호출 구조 Diagram>
(프로세스 호출 구조의 일부. 저 모든 호출 구조와 개별 단위의 역할이 뭔지 아무것도 모르는 상태였다.)
이 과정에 많은 시간과 에너지가 소모됐다.
문서화의 중요성을 정말 뼈저리게 느꼈다.
문서화란 단순히 주석 몇 줄 달아놓는 게 아니다.
참고로 테스트 문서를 작성할 때 크게 도움이 된 자료가 있어 링크를 남긴다.
https://www.softwaretestingclass.com/what-is-difference-between-test-cases-vs-test-scenarios/
: 테스트 케이스와 테스트 시나리오가 어떤 차이가 있는지 설명하고 또 테스트 문서의 예시를 보여준다.
업무 관리
업무를 관리하는 일도 중요하다.
개발자 이전에 회사원이다.
업무 관리가 안되면 매일 바쁘게 움직이고 이것 저것 했는데 뭘 했는지 알 수가 없다.
여기저기서 요청한 일들에 휘둘리고 돌이켜 보면 중요한 일은 마무리 된게 하나도 없다.
이런 상황을 타개하려고 여러가지 방법을 시도해 봤다.
그리고 아래 3 가지 단순한 일만 가지고도 많은 효과를 체감할 수 있었다.
- 일지 쓰기
- 하루 업무의 끝은 다음날 아침 할 일을 적는 것
- 칸반 보드 이용하기
업무 관리 기법도 갈고 닦아야 할 skill 이라고 느꼈다.
충분한 시간과 노력을 들일 가치가 있는 skill 이다.
기타
RabbitMQ
기존 솔루션에 RabbitMQ 를 도입하려는 작업을 진행하다가 시급한 문제가 해결되면서 일단 중단됐다.
Message broker 라는게 어떤 것인지, 또 어느 경우에 유용한지 감을 잡을 수 있었다.
나중에 기회가 되면 기존 솔루션에 RabbitMQ 를 도입해서 실시간 통계 분석 기능을 추가해 보고 싶다.
Query Tuning
위에서 말한 시급한 문제란 DB 와 관련된 성능 문제였다.
당연히 DB Query Tuning 이 빠질 수 없다.
어깨 너머로 EXPLAIN ANALYZE 같은 것을 활용하는 것을 봤다.
DB 관련해서 아는 것은 CRUD 작업, pk/fk 연결, 그리고 내부적으로 데이터 찾기는 B- tree 같은 indexing을 이용한다는 것 정도였다.
튜닝은 그냥 이런게 있구나 정도로 본게 전부지만 아무튼 DB의 세계가 넓고 깊다는 것을 느꼈다.
좋은 Log
로그만 잘 남겨도 많은 수고를 덜 수 있다.
나중에 문제가 발생했을 때, 믿을건 log 밖에 없을 수도 있다.
한 번은 어떤 기능이 제대로 작동하지 않았는데, 최신 버전으로 패치했음에도 불구하고 같은 문제가 반복된다며 해결 방법을 요청받았다.
도대체 뭐가 문제인지 알 수 없어 난감해 하고 있었는데...
얼핏 실행 로그를 보니 못 보던 숫자가 있었다.
버전이 안 맞는 것이었다 !
이름 짓기
(아마도) 개발자의 글쓰기 라는 책에서 개발자는 작명가라는 표현을 봤다.
어떤 일을 잘 해야 하는지 명확하게 표현해 주는 말이다.
예를 들면 함수를 사용할 때 이름만 보고 바로 쓸 수 있을 정도로 명확한 이름을 가지고 있다면 크게 도움이 된다.
아니, 반드시 그렇게 돼 있어야 한다.
어떤 함수가 있고 또 어떻게 구현돼 있는지 소스를 일일이 찾아서 읽어야만 알 수 있다면 생산성이 크게 하락한다.
어깨 너머 선배 개발자분을 보니 그런 식으로 코딩하지 않았다.
그냥 . 찍고 뜨는 이름만 보고 호출해서 썼다.
작명을 잘 해 둬야 이렇게 할 수 있다.
단순히 잘 읽히는 코드를 쓰기 위해서가 아니라, 높은 생산성을 위해서 이름을 잘 지어야 한다는걸 깨닳았다.
읽지 않아도 되는 코드를 쓰기 위해서.
점만 찍고 쓰기 위해서.
마무리
쓰고 나니 갈 길이 멀다는 생각 뿐이다.
하지만 시작했다는 것.
그것만으로도 스스로 칭찬할 만 하다.
물론 혼자서는 하지 못했을 일이다.
많은 것을 알려주고 앞으로 갈 방향을 제시해 주신 DK 님이 없었다면 시작조차 할 수 없었을 것이다.
특별히 감사의 말씀을 드린다.
또 짧은 시간 동안 많은 것을 보여주신 JK 님, 첫 발을 내딛게 해 주신 TH 님께도 감사드린다.
