요사이 개발자로써의 목표는 "새로운 것을 접할 때 빠른 결과와 좋은 성능을 보장하는 개발하기"였다. 실제 여러가지 실제적인 상황을 보다보면 대부분 아는 것보다 모르는 것이 많은 것이 당연한데,  늘 그러한 일을 할 때면 밑바닥부터 모든 것을 만들겠다는 아집에 많은 시간을 쓰는 경우가 많았다. (알고보면 모든 것을 밑바닥부터 만들는 경우는 없는 것과 마찬가지이다.)

해야할 일은 TCP로 돌아다니는 패킷을 캡쳐 => 캡쳐된 패킷을 스트림으로 전환 => 특정 프로토콜에 맞게 파싱

장님 코끼리 만지기 식으로 도입한 프로세스
1. 고객에게 정보 수집
2. 먼저 빠르게 사용할 수 있는 라이브러리를 찾기.(libpcap)
3. lightweight framework language( Ruby, Python과 같은 유연하고 제네릭한 언어)에서 해당 라이브러리 찾기 (pcapy, Pcap/Ruby)
 그중 Pcap/Ruby에서 아주 쓰기 편하고 이쁜 라이브러리를 기반으로 구현을 해서 나머지 기능을 모두 기 능 구현을 했었다.
4. 그 외에 세부적으로 필요한 기능상의 내용은 TCP가 어떻게 돌아가는지는 오픈소스 구현물 tcpflow, wireshare, 그리고 관련 자료 wikipedia, the TCP Guide를 참조해서 Ruby로 만든 프로그램에 적용하는 식으로 개발을 했었다.

  3주 정도의 기간에 결과물을 대략 산출해내는데 성공했으나 - 아직 진행중 - , 몇 가지 문제점 및 개선방안을 발견할 수 있었다. 결국 실용주의 프로그래머에서 본 내용을 다시 한번 뼈저리게 느끼게 된다.

 수행하면서 좋았던 점
 1. 1주일 이터레이션 : 피곤하고 많은 시간을 뺏긴다고 생각했으나, 가야할 방향을 알려주는 나침반 역할을 수행했다.
 2. Lightweight framework language 활용 : ruby,python과 같은 유연하고 쉬운 언어를 통한 접근은 새로운 기능을 사용하는데 있어서 지렛대 역할을 수행했다. 또한 어떤 부분이 성능이 필요한지, 아닌지에 따라서 사용 여부를 판단할 수 있었다.

 개선해야할 점 및 반성점
 1. 기존에 있던 구현물을 최대한 활용하기(Unix 철학처럼 simple is best를 최대한 활용하라.)
 기능을 구현하는데 있어서 라이브러리보다 더 좋은 수단은 이미 구현된 프로그램이다. 그것을 최대한 재활용할 수 있는 방법을 먼저 강구했었으면 더 빠르게 그리고 안정적으로 구현이 가능했을 것이다. tcpdump를 이용해서 파일을 주기별로 만든 다음에 그걸 파싱하는 프로그램을 작성한다던지 하는 등의 개발방법론을 적용했다면 더 빠르게 개발이 가능했었을 것이다.
 2. 고객 그리고 같이 일하는 사람들의 얘기를 좀 더 주의깊게 들으라. 해당 문제를 좀 더 쉽게 단순화시킬 가능성이 높아진다. 받은 데이터를 기존에 같이 일할 때처럼 csv파일과 같은 형태로 만들기 위해 모두 파싱을 하느라 3-4일 정도의 기간을 소요했는데, 오프셋으로도 처리가 가능했었다. 기존에 같이 일할 때 방법만을 생각하고 개발하느라 그러한 문제점이 발생했었는데 생각해보니 지나가는 말로 이 안건을 개발하면서 관련 얘기를 들었던거 같다.
 3. 그중에서도 실시간성을 어떻게 감안하느냐에 따라서 concurrent 모델 혹은 배치작업(분리된 프로세스)로 처리하는 것이 월등히 좋은 성능을 발휘할 수 있다. 실시간의 DB 트랜젝션 그리고 실시간의 raw data를 파싱하는 작업등은 시간에 민감한 다른 작업에 지대한 영향을 줄 수 있다. 다량의 로그데이터를 처리하거나 실시간성이 중요한 패킷캡쳐등을 할 때 작업을 분리해 배치처리를 하는 방향으로 모델을 작성했었어도 나쁘지 않은거 같다.

프로세스 수정안
1. 고객에게 여러가지 제반사항에 관한 정보를 수집하기.
2. 같이 개발할 사람들과 협업할 부분에 대한 정보를 얻기
3. 모델을 쉽게 재구성하기
4. 해당 기능과 같은 혹은 비슷한 프로그램을 찾기
5. 실행해보기(기능, 성능체크)
6. 역할에 맞게 최소한의 수정 (라이센스 정책을 어기지 않게 모델을 구성하는데 참조)
7. 그 외의 부분은 상황에 따라 lightweight framework language와 기존의 언어로 빠르게 구현