알고리즘 개발하고 이런 새끼들은 어차피 상위 5%임


남들 전부가 쓰는 라이브러리, 프레임워크 만드는 애들 알고리즘 만드는 연구자 타입은 5%고 5%의 결과물을 바탕으로 조합하는게 내 일임


나는 카프카, 레디스가 대강 어떤건지는 알고 캐시가 뭐고 메세징이 뭐고 이벤트 드라이븐 아키텍쳐가 뭔지 알지만, 카프카, 레디스를 구현할 줄 모름. 근데 카프카, 레디스는 그냥 씀.


카프카를 처음 써본 곳은 스마트팜 만들때 IoT에서 특정 장비 일어났을때 이벤트 로그를 빠짐없이 기록해서 이걸 pdf 보고서로 연동하는 작업


C#으로 한 후에 이후에 파이썬으로 넘겨서 보고서를 만드는 이종 언어 작업이었는데 생각보다 난이도가 있었다.


어차피 둘다 전형적으로 문서가 잘되있고 sample 케이스가 잘되있어서 사실 그 샘플 케이스를 바탕으로 뼈대 확장하는 식으로 처음 공부해서 


카프카, 레디스 둘 다 샘플 코드에서 살을 붙이는 식으로 도입하고 이걸 나만의 라이브러리 화 시켜서, 사실 완전히 잘쓴다라고 하는지 모르겠다. 내 코드 대부분은 초고수 프로그래머들이 샘플 코드로 만들어 둔걸 래핑해서 내 프로젝트에 붙여두는 형식이라. 


말이 퍼사드 패턴 썼습니다. 어댑터 패턴 썼습니다라고 주둥아리 털지만 사실 그냥 검증 코드 래핑해서 붙여넣기 쉽게 만든것뿐.


그나마 내가 한건 불변식이랑 실패를 매핑해서 로그 형식을 내가 선호하는 방식으로 살짝 수정한 것뿐. 어차피 내 역할이라는게 결국 디버깅 로그 딸딸이 치는거니까.


어차피 사양서도 대부분 그걸 더 중점적으로 원하고 납기 기간내에 품질 보증하기위해서 더더욱.


막상 보면 대부분 하는 일은 원청 설득하기.


좋은 코드 서칭해서 템플릿 잡아두고 그위에 얹을 수 있는 코드들 잡기. 


장비 SDK가 물리적 제약 있을때 안되는거 입털어서 원청이랑 샤바샤바해서 B플랜으로 진행해서 살짝 다르게 구현해주기 등등.


그냥 사양서 받고 조립하고, 오히려 의뢰인이 요구는 하지만 뭘 원하는지는 모르는 상태에서 내 경험을 바탕으로 이게 아닐까요? 라면서 역 제시하면서 돈 뜯어내는게 역할인거 같다.


어차피 저수준 알고리즘 고쳐서 만들어봤지만 절대다수는 이 영역에서 나보다 잘하는 사람이 많아서 대강 어디에 쓰는지 알고는 있지만 구현은 못하는 상태.


최근에 그나마 저수준 프로그래밍한건 웹 소켓 관련한 구현이랑, Task 관련해서 컴파일러랑 연동해서 장난삼아 해 본 토이프로젝트. 실제로 저수준 프로그래밍 쓰는 영역은 대부분 잘없고


고가 정밀 장비의 경우에 잘못하면 내 책임이 될 소재가 농후해서 대부분은 한번 래핑해서 쓰는 경우가 절대다수. 고가 장비에 약간 성능 손실은 있지만 안전지향을 하게되니까.


정밀 장비라는게 포인터 잘못 나가면 모터각도 때문에 맛 갈 수가 있어서. 처음에 현미경 장비 프로그래밍 할때 돌아가면 안되는 각도로 돌아갈뻔해서 간신히 멈춘적 있는데, 결국 래핑하고, 입력값 검증하고 세이프티 버퍼 만드는게 중요하더라.


프로덕트 만들어서 세상에 내놓지 못한 개발자는 결국 최종적으로 원청서 원하는 납품형태를 납품하는 것으로 귀결되고 나도 이걸로 자본금 모으고 있는데


VC한테 IR 하는거든 뭐든 결국 전부 싸바싸바고 입터는거고. 절대다수는 10~15%정도의 성능정도는 감안하고 쓰더라. 그리고 요새 컴퓨터 좋아져서 이정도 수준은 대다수 별 문제 없고.


웹 애니메이션 존나 구현해서 내 자기 만족용 포폴 만드는건 막상 인기 없고, 정적 페이지가 인기 많듯이 대부분은 어디서 본거를 바탕으로 구현해달라고하는데


그 어디서 본거 구현한다는 건 결국 이미 공개된 프로덕트들은 대부분 따라한 습작들이 있어서 그안에서 성능 개선 조금만 하는 식으로 진행되서.


일이나 계속 끊기지 않고 들어왔음 좋겠다.