Taeguk's Blog

오랜만에 글을 쓰는 거 같다.. 최근 근황은 뭐 계속 회사 생활의 반복이다.. 눈깜짝하니 입사한지도 1년이 어느새 훌쩍넘었다. 뭔가 해보고 싶은게 많은데, 회사 다니면서 출퇴근 시간도 길고, 내가 체력도 안좋고 부지런한 편도 아니라서 진짜 회사만 다니기 벅찼던 것 같다. 그래도 나름 뭔가 해보려고 최근에 2가지 활동을 했었다.     그중에 하나는  컨트리뷰톤 이다. 작년이나 올해 초까지만해도 오픈소스 활동을 했었는데, 회사다니면서 자연스레 멈추게 되었다. 다시 한번 오픈소스 활동을 시작하기 위한 계기를 삼으려고 컨트리뷰톤이라는 프로그램에 참여하여  uftrace  라는 C/C++ function tracing 툴 프로젝트에서 활동을 했다. 현재는 컨트리뷰톤 활동은 끝났고, 이번 달 말에 폐회식?시상식? 이 있을 예정이다.     또 하나는 블록체인 스터디이다. 반년전쯤부터인가 블록체인쪽에 관심이 생겨서 한번 공부를 해보려고 스터디를 하게 되었다. 스터디는 현재 진행형이다. 회사를 다니면서 이렇게 2가지 활동을 동시에 했다. 이 활동들에 내가 투자하려고 했던 시간/에너지 양이 대략 있었는데, 막상 해보니 실제로 투자한 시간은 내 예상의 20% 도 안되는 것 같다. 신규 기능개발로 인해 회사 일이 최근에 바쁘기도 했고, 생각보다 내가 시간과 자기관리를 제대로 못했다. 시간투자를 많이 못한게 아쉽긴 한데, 일단 뭐라도 해본 것에 의의를... 아 그리고, 최근에  우리 팀 우리 파트 채용공고 를 새로 냈다. 기존의 채용 공고가 너무 모호하고 매력이 떨어진다고 생각해서 내가 건의를 해서 채용공고의 내용을 바꿔봤다. 채용공고 보기/숨기기 모집부분 - C++ 기반 공용 모듈 개선 및 개발 - C++ 기반 엔진 모듈 개선 및 개발 담당업무 - 사내 C++ 공용 라이브러리 개선 및 개발 - C++ 기반 악성코드 탐지/치료 엔진 개선 및 개발 - 코드 품질...

어쩌다가 2년 반 전에 내가 했던 프로젝트의 코드를 보게 되었다. 코드가 너무 구렸다. 그때도 나는 나름 설계나 코드 품질에 신경을 많이 썼었는데, 지금 돌이켜보면 역량이 많이 부족했었던 것 같다. 내가 개발다운 개발을 한 지가 얼마나 됐을지에 대해 생각해보았다. 길게봐도 반년이 채 안되는 것 같고, 깐깐하게 보면 아직도 많이 부족한 것 같다. 이제서야 슬슬 뭘 좀 알아가고 개발다운 개발을 시작하는 단계라고 생각이 들었다. 아무튼 그래서 내가 생각하는 "개발다운 개발" 의 기준에 대해 써보려고 한다. 물론, 지극히 개인적인 생각이며 각자가 일하는 도메인과 상황에 따라 매우 다를 것임을 인정한다. 1. 프로그래밍 언어와 Good Practice 들에 대한 깊은 이해. "언어는 도구에 불과하다" 라는 말이 있다. 그냥 문장 자체적으로만 보면 물론 맞는 말이다. 하지만, "불과하다" 라고 표현하기에는 언어는 너무나도 중요한 도구이다. 그리고 정말 공부를 많이 해야하는 도구이다. 언어는 사고를 지배하고, 언어를 공부하고 이해한다는 것은 생각하는 법과 철학을 배우는 것이다. 오랜 시간동안 전 세계적으로 여러 프로젝트들이 개발/연구되고 다양한 사람들이 토론/합의하면서 발전한 소프트웨어 기술과 패러다임들이 프로그래밍 언어에 그대로 녹아들어간다. 즉, 언어를 깊게 공부함으로서 소프트웨어 개발에 대한 철학과 통찰, 패러다임, 트렌드를 알 수 있다. 그리고 언어를 깊게 공부한다는 것은 그 언어에서의 Good Practice 들을 공부하고 숙달하는 것을 포함한다. 언어의 feature spec 이 도구라고 한다면, Good Practice 는 도구를 사용하는 방법이다. 단순히 언어의 문법을 익히고 라이브러리에서 어떤 기능을 제공하는 지 아는 것이 중요한게 아니라, 어떤 상황에서 어떻게 사용해야하는 지에 대한 Good Practice 를 제대로 아는게 핵심이다. 내 개인적 기준에서, 이 부분에 대...

7/13 (금) ~ 7/16 (월) 3박 4일 간 일본 오사카 지역으로 여행을 갔다왔다. 내 생애 2번째 해외 여행이었다. 첫 해외 여행은 2년 전쯤 삼성에서 단체로 보내준 해외연수(?) 차원의 여행이였기 때문에, 이번이 내가 태어나서 처음으로 자의적으로 해외여행을 간 것이었다. 비행기 타기전. 인천공항. 비행기는 2년전에 처음탔을 때는 매우 신기했는데, 이번에는 하나도 신기하지 않았다. 밤에 일본에 도착했다. 그리고 남바역으로 왔다. 일본에 왔구나 라는 느낌이 들었다. 직장인들이 회식을 한건지, 양복입고 서로 신나보이더라. 그리고 엄청 더웠다. 간단하게 다코야끼를 먹었다. 맛있었다. 2일 째에는 교토로 갔다. 이 사진에 보이는 곳을 먼저 갔는데.. 여기가 이름이 뭐더라.. 디지몬 만화에서 맨날 보던 기찻길이다. 진짜 디지몬 만화에서 기차올때 나오는 소리가 그대로 난다~ 여기도 갔는데, 이름이 어딘지 까먹;; 암튼 좋았다~ 날씨는 무지더웠다;; 이날 완전 땀 범벅이였다. 대나무숲. 날씨가 화창하구만! 일본 편의점에 가면 이렇게 꼭 잡지가 모여져있는 곳이 있었다. 아~ 아사히 시원~하다~ 여기는 우메다 공중정원(?) 셋째날은 유니버셜 스튜디오에 갔다! 옛날에 LA에서 갔었는데 거기랑 느낌이 비슷했다! 고베에 가서 먹은 고베규! 완전 맛있다! 세명이서 간단하게만 먹었는데 17000엔정도 나온듯? 야간에 보면 더 멋있는 오사카성! 반짝반짝하니 좋다~~ 이츠란 라멘~ 맛있다! 아사히도 넘나 짱짱~ 나는 편의점에서 파는 빙결 맥주가 왜케 맛있던지... 일본이 제일 부러웠던 점 같다.. 레몬/자몽 들어간 맥주 다 맛있다! 마지막날 아침의 번화가 모습. 일본은 역시 번화가가 느낌이 좋다~ 아무튼 해외여행을...

얼마전 아는 후배가 C++ 개발자 채용공고라면서 링크를 하나보여줬다. https://www.think-cell.com/en/career/jobs/development.shtml 독일에 있는 think-cell 이라는 회사의 개발자 채용공고인데, 내가 봤던 채용공고 중에 가장 멋있었다. (내가 봐봤던 채용공고가 몇개 안되긴 하지만..) 일단 회사 내에서 하는 일과 기술 스택 등에 대해 구체적으로 적어놓은 점이 맘에 들었다. 그리고 그 내용은 더더욱 맘에 들었다. 적어놓은 항목 하나하나가 실력있고 열정있는 C++ 개발자라면 누구나 혹할 만한 내용과 키워드들이었다. 정말 멋진 회사라고 생각되서 블로그에 포스팅을 하게되었다. 반면에 우리나라에 저런 C++ 회사가 있는 지 생각해보면 아무 회사도 떠오르지 않는다. Java/Python 등을 주로 사용하는 서비스 분야 쪽에서 생각해보면 '괜찮은 회사' 들이 몇몇 떠오르지만, C++이나 시스템/로우레벨 쪽에는 그런 회사가 상대적으로 적다고 느껴진다. (여기서 '괜찮은 회사' 은 내 주관적인 기준에서, 기술적으로 트랜디하고, 오픈소스에 참여하고, 의사결정과 정보가 투명하고, 실력과 성과에 부합하는 보상을 지급하고, 열정있고 실력있는 사람들이 모여있는 회사를 의미한다.) 아무튼 회사가 좋고나쁨을 떠나서, 채용공고를 저렇게 세부적으로 적는다는 점 자체가 많은 회사들이 본받아야할 점 같다. 저 채용공고를 보면, 어떤 언어,컴파일러,라이브러리를 사용하는지, 어떤 버전컨트롤을 쓰는지, 어떤 툴들을 쓰는지, 사내 코딩컨벤션이 있는지, 유닛테스트를 하는지 등에 대해서 많은 내용을 써놨다. 즉, 저 회사는 저런 점들에 대해서 중요하게 생각하고 신경을 쓰고 있기 때문에 채용 공고에 저런 점들을 적어놓은 것이고, 평소에 저런 점들을 중요시 여기는 개발자가 채용 공고를 본다면 자연스럽게 호감이 가고 회사에 지원하게 될 것이다. 채용 공고에 적어놓은 내용들이 내가 관심있거나 하고싶은 내용들이 아니...

산업기능요원으로서 육군훈련소에서 4주간 (5/24 ~ 6/21) 기초군사훈련을 받았다! 수료 후 사회로 다시 돌아왔는데, 수료 당일과 다음 날에는 모든 것이 어색했다. 컴퓨터 마우스를 사용하는 것도 잘 못하겠어서 신기(?)하고 이상했다. 아무튼 2일이 지난 오늘은 사회에 대한 적응이 어느정도 됐다. 물론 아직도 군인말투(?) 가 종종 튀어나오긴 한다. 4주간의 훈련 강도는 너무 낮았다. 훈련 자체는 진짜 별로 힘든거 없고,, 훈련 중간에 쉬는 시간도 지나치게 많고,, 개인 여건도 많이 보장해준다. 밥도 준수한 편이고, 간식(부식) 도 엄청 많이 나온다. 그리고 잠도 많이 자고, 주말에 하는 종교활동도 되게 재밌다. 또, 일 생각이나 복잡한 생각을 안하고 그냥 단순하게 지낼수 있어서 스트레스를 적게 받는다. 개인시간이 없고 24시간 단체생활을 한다는 점이 유일하게 힘들었던 점이었다. 개인적으로, 진짜 4주동안 받은 훈련이 별거 없다고 생각한다. 진짜 맛보기만 한 것 같은 기분이다. 아무리 산업기능요원/전문연구요원/의무소방을 위한 훈련이라지만.. 훈련의 퀄리티와 강도를 좀 더 높여야 되는 거 아닌가라는 생각이 들었다. 훈련소 생활을 하니까 새삼 자유롭게 사는 것의 소중함을 깨달은 것 같다. 그리고 현역으로 군대를 갔다온 친구들이 대단하고 존경스러워졌다. 또, 조국을 위해 목숨바쳐 헌신하고 싸웠던 위인들이 참 대단하다는 생각이 들었고, 나도 그정도까진 못하더라도 살아가면서 조국과 세상을 위해 뭔가 좋은 일을 해야겠다는 생각이 들었다. 아무튼 훈련소 수료하니까 좋다! 근데, 목감기가 지독하게 걸려서 낫지가 않네....ㅠㅠ

별점 : ★★★★ 한줄평 : 더 나은 소프트웨어 개발자가 되고자 노력하는 모든 이들의 필독서. 소프트웨어 장인의 길로 안내하는 이념서. 번역 :  http://book.naver.com/bookdb/book_detail.nhn?bid=9585753 원서 :  https://www.amazon.com/Software-Craftsman-Professionalism-Pragmatism-Robert/dp/0134052501 이 책은 Robert C. Martin Series 5권 중에 하나로서, "소프트웨어 장인정신" 에 대한 책이다. (저자는 밥아저씨가 아니라 다른 분이지만, 마틴 시리즈로 분류되고 있다..) 소프트웨어 장인정신은 마스터가 되어가는 긴 여정이다. 소프트웨어 장인정신은 소프트웨어 개발자 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다. 위는 이 책의 저자가 말하는 소프트웨어 장인정신의 정의이다. 아래는 이 책을 읽고 생각하면서 내가 이해하고 받아들인 "소프트웨어 장인정신" 에 대한 내용이다. (개인적인 생각이 포함되어 있다.)     소프트웨어 장인정신이란, 다른 것은 무시하고 단순히 아름다운 코드만을 추구하는 것이 아니다. 철저히 프로페셔널리즘과 실용주의에 입각하고, 비지니스적인 가치를 첫째로 추구한다. 다만, 비지니스 가치를 극대화시키고 고객을 만족시키며 끊임없이 추가되고 변경되는 요구사항에 대응하기 위해서는, 결국에 높은 수준의 소프트웨어 품질을 성취해야한다 .     소프트웨어 장인은 비합리적인 것들과 잘못된 의사결정에 대항하며 , 회사와 비지니스 가치를 위해 올바른 실행 관례를 배우고 실천하며 널리 퍼뜨린다. 그러한 실행 관례로서, 책의 저자는 애자일, XP, TDD 등을 들고 있다. 하지만, 이러한...

안녕하세요~ 새롭게 인사드립니다! http://blog.naver.com/likeme96 에서 이사온 taeguk (전공체육) 입니다~ 이유는 4가지 입니다! 구글 검색에 노출되는 빈도를 높이기 위해 카테고리 기반이 아닌 태그 기반으로 포스팅을 하기 위해 변화를 도모하기 위해 포스팅 시간을 맘대로 바꿀 수 있음. (포스팅 마이그레이션 작업에 용이.) 기존 블로그에 있던 상당수 글들 (기술 포스팅 위주) 을 대부분 마이그레이션 해온 상태입니다! (100% 수동 작업... 한 5~6시간 걸렸어요... 너무 힘들었어요 ㅠㅜ) 새 마음 새 뜻으로... 잘 부탁드립니다!

회사에 온지도 8개월이 넘었고, 병특을 시작한지도 반년이 넘었다. 회사 입사 지원 서류를 쓴게 엊그제 같은데,, 시간이 진짜 빨리 흐르는게 느껴진다. 아침에 일어나서 회사에 출근하면, 좀 만 지나면 점심시간이 되고, 또 눈 깜박하면 퇴근 시간이 된다. 그리고 집에 와서 저녁먹고 그러면 또 자야할 시간이 된다. 일주일에 이런 생활을 5일 반복한다. 회사 일 자체는 즐겁게 하고 있다. 기존 레거시 코드베이스에서 요구사항을 추출/개선해서 새롭게 코드를 재작성하고 있다. 아예 리포지토리부터 새롭게 파서, 프로젝트를 처음부터 정립해나가다보니 많은 것들을 도입하고 개선할 수 있다. 설계, 자동화된 테스트, 문서화, CI, 정적분석툴, 예외처리 등 다양한 부분들을 고민하면서 진행하고 있다. 나름 소프트웨어 장인 정신을 가지고 개발을 하기 위해 노력중이다.. 학생때부터 나는 리펙토링, 코드깍기를 좋아했는데 그냥 아무생각없이 병특으로 들어온 회사에서도 내 흥미/적성에 맞게 일을 하게 되서 신기하고 감사하다. 무튼, 회사에 오고나서 실력은 많이 늘은 것 같고, 앞으로도 실력이 많이 늘꺼 같아서 좋다. 물론 아쉬운 점도 있다. 기존 레거시 코드베이스(프로젝트) 의 품질과 프로세스에 대해 실망감이 많았다. 테스트코드의 부재... 구조화되지 않은 요구사항... 당장은 돌아가지만 '찜찜한' 코드들... 스파게티처럼 꼬여있는 의존성... 이것들이 입사 후부터 지금까지 나에게 많은 스트레스를 안겨준다. 지금 내가 하고 있는 작업이 결국 이러한 소프트웨어 품질과 개발프로세스를 개선하기 위한 작업이다. 주인을 잃은 지 오래된 코드들에서 요구사항을 추출하는게 종종 지치고 의욕이 꺽기기도 하지만,, 전반적으로는 재밌게 하고있다...ㅎㅎ (조급함을 버려야만 한다...ㅜㅜ) 아무튼,, 이렇게 회사원의 삶을 살고 있다.. 슬슬 회사에 다니는 게 뻔하고 질린다.. 이런 회사 생활을 나보고 평생 계속 해야한다고 하면... 흠... 회의감이 들꺼 같다...

Visual Studio 2015에서 C++프로젝트 플랫폼 도구 집합으로  vc140_xp 을 사용했을 때, vc140에 비해 내부적으로 바뀌는 점들을 한번 분석(?) 해봤다. (완벽한 내용은 아닐 수 있다..) 1. Windows SDK을 XP를 지원하는 옛날 버전으로 변경.   * VC Directories에서 Windows SDK의 include, lib, bin 폴더 경로를 변경   * 원래 vc140이 v8.1 버전을 사용했다고 하면, vc140_xp로 플랫폼도구집합 변경 시, v7.1A를 사용하는 식으로 바뀜.   * v7.1A는 xp를 지원함.  (https://en.wikipedia.org/wiki/Microsoft_Windows_SDK ) 2. CL 컴파일시 _USING_V110_SDK71_ 매크로를 정의함.   * VC++의 라이브러리들 (ATL/MFC 라이브러리, C++표준라이브러리의 헤더파일들이 이 매크로에 영향을 받음.)   * _USING_V110_SDK71_ 매크로가 큰 영향을 주진 않는다. (하지만, 조금이더라도 분명 영향을 미친다.)   * 예를 들면, 이 매크로가 정의되어 있는 경우, C++표준라이브러리에서 std::shared_mutex 가 정의되지 않는다. 3. 링크시, /SUBSYSTEM:CONSOLE",5.01" (or 5.02) 옵션을 사용. (구성 형식이 EXE 일 경우)   * vc140의 경우에는 /SUBSYSTEM:CONSOLE 옵션이 링크시 사용되는데, vc140_xp의 경우 /SUBSYSTEM:CONSOLE",5.01" 이 사용됨. (64bit에서는 5.01이 아니라 5.02)   * 이 링크옵션은 완성된 PE파일의 서브시스템 버전에 영향을 줌.   * 서브시스템 버전이 명시되지 않은 채로 링크되면, PE파일의 서브시스템이 6이상이 되고, 프로그램이 XP에서 실행되지 않음.  ...

이번에 인텔 CPU 보안취약점 (멜트다운) 관련해서 쉽고 잘 설명해놓은 좋은 글을 발견해서 공유합니다~ http://blog.cyberus-technology.de/posts/2018-01-03-meltdown.html (Trying it all together 부분만 읽으시면 됩니다. 짧습니다.) 간단하게 한번 끄적여보자면,,,, 다음과 같은 연속된 instruction들을 실행합니다. 1. 값을 얻으려는 특정 커널메모리 주소에 접근하여 값을 1바이트 읽습니다. 2. 1번에서 얻은 값에 4096을 곱합니다. 3. (미리준비된 충분히 큰 버퍼의 주소 + 2번에서 얻은 값) 의 주소에 접근합니다. (여기서 "충분히 큰" 이란 4096 * 256 바이트를 의미합니다.) 실제 cpu는 이 instruction들을 동시에 실행하게 됩니다. 그러나 instruction들의 실행 결과가 실제로 반영이 되는건 차례대로 반영이 되게 되는데, 1번에서 접근권한이 없어서 예외가 발생하므로, 저 instruction들의 결과가 실제로 반영이 될 순 없습니다. (Exception Suppression을 위해서는 Intel TSX 를 사용한다고 합니다. 사용할 수 없는 환경에서는 그냥 Exception handling) 그러나, 3번에서 비록 실행결과가 반영이 되진 않더라도, 실행과정에서 (미리준비된 충분히 큰 버퍼의 주소 + 2번에서 얻은 값) 의 주소의 메모리가 cache 되게 됩니다. 그 후 (미리준비된 충분히 큰 버퍼의 주소 + 4096 * 0~255) 의 주소에 각각 접근하면서 시간을 잽니다. (엄밀히 말하자면 Flush-Reload 라는 기법을 사용합니다.) 만약 가장 시간이 적게 걸렸을 때가 0~255중 74라고 한다면, (미리준비된 충분히 큰 버퍼의 주소 + 4096 * 74) 의 주소가 cache 됐다는 뜻이고, 즉 따라서 처음에 읽으려했던 커널메모리 1바이트의 값이 74인것 입니다! ...