2016년 10월 1일 토요일

카산드라 ON MAC

이스트소프트에서 세미나했던 피드백에 삘 받아서 쓴다. DATASTAX를 이용하여 6 NODES 카산드라를 애저에 설치하고 각 노드끼리 교신하는 방법을 세미나 했었는데, 무진장 쉽고 이렇게 된다는 결과만 보여줬음에도 뒤에 들었던 많은 피드백이 모르겠다. 였다. NoSQL이 뭔지도 모르는 사람들이 많아서 그렇다. 그래서 몇자 적어 본다. 

그동안의 필체와는 사뭇 다른 일기 형식이라 다소 거북하실 수도 있겠으나 항상 그렇듯이 구독자들을 위해 글은 금방 내린다.(공유 많이 된거 빼고) 지식을 배운다기 보다 이런 엔지니어는 이런 생각을 가지고 있구나 라고 보는게 좋겠다.

1. 왜 카산드라인가?
우선 우린 MySQL을 많이 쓰고 배운다. 네이버도 MySQL, PHP로 지식in 만들어서 겁나 떠서 지금의 네이버가 되었다. 지금은 라인이 돈 벌지만. 솔직히 MySQL을 쓰는 이유는 오라클을 쓸 돈이 없어서다. MySQL도 라이센스 어쩌구 해서 마리아 DB나 포스트그레스 큐엘을 쓰기도 한다. 나 역시 프리랜싱할 때 MSSQL은 몇번 안했다. 중소기업인데 800만원 들여서 MSSQL샀던 일신정공...  CPU 라이센스라서 라이센스 파일과 윈도우 레지스트리 찾아서 다 옮긴다고 개고생했었다. 물론, 일급 80만원으로 쳐줘서 좋았다. 3일 작업에 240 ㅡㅡ; 대학생때라 비싼 술집 갔었던 기억이 난다. 트위터도 그렇고 국내 기업들도 모두 카산드라로 갈아 타고 있다. 왜... JOIN에 지쳐서 샤딩이 뭔지 몰라서... RAID까지 끼면 이건 뭐 어떻게 복구해야 하는겨. 걍 데이터 센터 번개 맞아서 죄송합니다. 난 최선을 다해서 돈을 못 물리겠네요. 당신이 더 잘할 수 있으면 잘해보세요. 하다가 분산 시스템 간단하게 가면 되는데 어려웠기 때문에. 카산드라다. JAVA에서 C++로 바꾸는 프로젝트도 있는데 10배 빠르다고 한다.

2. NoSQL의 대표.
Not Only SQL이라고 한다. 아니다 걍 NO SQL 이다. SQL이랑 다르다. 뭐가 다른가? 인터넷에 자료 많다. JOIN없고, 소팅, 그룹등 SQL에서 하는거 없다고 한다. 스케일링이나 데이터 가용성에 집중했다고 한다. 데이터 베이스는 단순한 파일일 뿐이다. 파일이 아니라고 하면 운영체제 없이 구현해야 하고 그럴려면 SSD, 하드디스크 등을 지원하는 자원 관련 메카니즘을 다 짜야 한다(장치 관리, 장치 접근 스케쥴링, 디바이스 드라이버, 파일 시스템, 또 관련 드라이버, 등...) 운영체제 짜기 어렵다. 그래서 오라클이던 MSSQL이던 돈 안드는 데이터베이스던 모두 운영체제 위에 올라간다. 제대로 만들려면 데이터 베이스 만의 펌웨어로 동작시켜야 하겠지만 그 ㅈㄹ 안하려고 운영체제 만든것이다. 자 그럼 NO SQL 인데, 결론만 말하면
SQL 맞다. 카산드라 쿼리 랭귀지인 CQL이 나온지 오래다. 그전에는 이게 없어서 소스코드 짜서 드라이버 이용해서 접근해야 했다. MSSQL Client 없어서 드라이버 쓰는 거랑 같다. 

받아서 압축 풀고, bin 풀더 들어가서 카산드라 실행 시키면 데몬이 뜬다. ./cassandra -f 자바 기반이니 자바 깔려 있으면 된다.
./cqlsh 로 SQL 비스무리한 것을 실행시킨다.

CREATE KEYSPACE tumblbug_user WITH replication = {'class' : 'SimpleStrategy', 'replication_factor' : 3};

데이터 스택스 참고해서 만든다. 전략은 3가지 인데 한개는 레거시고 심플은 단일 노드, 네트웍 전략은 여러 데이터 센터를 연결할 때 쓴다고 한다. 사실 제대로 알려면 어떤 방식으로 데이터가 오가는지 데이터 복제, 이동 타이밍도 설명서가 아닌 소스 코드로 다 봐야 한다.(트랜젝션 없다고 하는데 서버끼리는 트렌젝션 안할리가.) 그래야 RDBMS로 이해하면 안된다고 할 자격이 생긴다. 링 구조니 다르게 이해해야 한다면서 정작 데이터가 여러 갈래로 깨졌을 때 백업만 할게 아니라 완벽히 복구할 복구 메커니즘을 설계할 정도로 다 파악하지 않는다면. 표나 그림도 소용없다.(그래도 한번 봐 두는 것은 좋다)

SQL에서 말하는 데이터 베이스 만들었다.

use tumblbug_user;

네임 스페이스를 바꾼다. 

create table user ( name text, phone text, PRIMARY KEY (phone) );

이렇게 만들고

select * from user;
하면 

 phone | name
-------+------

이렇게 나온다.

자료 넣으려면 INSERT INTO 하면 된다.

이정도 보면 이제 NoSQL 구조가 궁금할 것이다. RDBMS와 용어도 다르도 구현 메카니즘도 완벽하게 다르다. 그러나 그렇게 접근하지 말라고 사람들이 CQL 만든거다. 제대로 보려면 소스 레벨로 봐야 한다.

4. SQL이랑 같다.

물론, 카산드라와 오라클이 같을 수 없다. 그래서 다들 다르다고 포스팅 하더라. 아쉬운 건 어차피 오픈소스인데 소스 레벨로 분석해 주면 더 좋을 것 같다. 
MAC 이랑 LINUX는 다르다. 완벽하게. 그러나 bash shell 로 mac에 쓴 포스팅을 참고로 linux 도 똑같이 실습해 볼 수 있다. windows에도 이제 bash shell 이 들어간다.

이기종으로 쉽게 접근하려면 우선 이런 공통점으로 접근해야 한다. CQL을 만드는 이유도,
비얀 스트라스트럽이 C++을 C with classes로 만들어서 접근을 쉽게 했던 이유도.

모두 창시하는 사람들이 유저를 생각해서 였다.

그러나 DATASTAX 공식 문서가 아닌 포스팅을 보다 보면... 죄다. 다르다는 말은 하는데 소스 코드 한 줄 없다. 물론, 이런 시각 저런 시각도 필요하다.

고급자를 위해서라면. 

고급자를 위한 포스팅 같아 보이진 않아서 몇 자 써봤다. 또한 그런 포스팅으로 미리 공부를 해도 쉬운 내용을 어렵게 받아들이는 학생들을 위해서도.

이 포스팅은 월요일 쯤 삭제 예정이다.

이런 글 휴지통 대용으로 쓰는  블로그로 잠시 올려서 광고 수입도 올리기도 한다.

누군가가 잘 다듬어 주겠지. 쓰는데 20~30분... 제대로 다듬어서 올리는데는 3시간 이상. 쓰는건 정말 쉽지 않다. 그러나 구독자는 위대하다. 물타기 아니고. RDBMS와 NoSQL은 다르다. 그러나 한번 다르게 보면 난 똑같은 리눅스라도 버전만 달라도 완전 다른 프로그램이라고 생각한다.

아마 오래된 개발자는 리눅스 업데이트로 리눅스 다시 인스톨 해야 했던 경험이 많았을 것이다. 나 같은 경우 수십번도 넘게 했었다. 업데이트 안하면 뚫려서 나라에서 연락오지(호스팅 사업 때). 업데이트 하면 풀지 못하게 꼬여버리지.(커널 패닉 어케 고치라고... 노태상씨도 반도 디버깅 못한다고 했었는데)

어디든 SW최고수는 업데이트 시스템을 담당한다. 삼성전자 무선사업부 있을 때도 항상 고수 선배가 FOTA를 담당했다. 

세계 1위 브랜드 가치 애플도 OS 업뎃 잘못해서 모두가 서비스 센터로 가야 한다면? 그리고 그것이 한번이 아니고 두번이나 그래서 일년내내 수리 센터 불난다면. 회사 망하는 거다. 업뎃 2번 실패하면 회사는 망한다. 업데이터 뚫려서 아직도 보안 업계에서 회고되는 국내 회사도 많다.

사족이 참 길었는데 핵심만 말하면 카산드라 깔고 실행해서 SQL처럼 써 보시고 어라? 괜찮네? 쉽네? 라는 느낌이 든다면 많이 참여해서 RDBMS 보고서 나오는 것과 같이 더 쉬운 클라이언트들을 많이 만들어 줬음 해서... 이쪽이 전문 분야가 아니지만 써야 하기에 

2016년 9월 26일 월요일

작은 시스템 설계

가장 공유가 많았었던 문맥에 맞도록 코드들과 합치고 변형해서 넣을 예정.


최근 작은 시스템 설계 및 검수 의뢰가 들어왔다. 수백억 짜리 공사인데 IT 관련 기술이 들어가야 한다고 했다. 이와 관련한 일련의 고민 과정들을 적어 보려고 한다. 자세한 것은 공개하기 힘드므로... 
Embedded + SI +  X(비공개)였다. 시스템 통합에는 DB와 원격 관리, 백업 기능은 기본 중의 기본이다.

1

시스템이 나누어져 있으면 큰 시스템이 아니고 작은 시스템이라고 보면 된다. 가장 먼저 고려되어야 할 것은 가용성이다. 학부 과정에서 배우는 고가용성이란 다음과 같다. 간단히 말해서 고장 없이 잘 돌아야 한다는 것이다.
ko.wikipedia.org
이 말은 맞기도 하지만 보험회사의 광고와 비슷하게 내면을  들여다보면 조금 다른 점이 있다.
고장 나지 않는 시스템은 없으며, 버그 없는 소프트웨어는 없다는 것

작은 시스템 설계에서 가장 먼저 고려되어야 할 것은 이 고장들을 관리할 수 있는 수준으로 만들어야 한다는 것.

2

공사가 들어갈 때 일단 콘크리트를 치고 나면 바꾸기 힘든 부분이 있다. 특수한 부분에 설치되는 케이블 등은 再공사가 힘들다는 것이다. 보안전문가에게는 크레커에게 뚫려봤던 경험이 중요하듯이 책에서 모아서는 볼 수 없는 작은 것들이 성패를 결정한다. 이미 많은 책 내용의 사이사이에는 조금씩 노하우가 적혀있지만 무심코 지나치는 것들의 중요성을 아는 것. 사람들은 그것을 노하우라고 부르고. 공개하지 않으면 '비법'이 된다.

 네트워크 연결은 유선/무선을 다 고려해야 한다. 무선과 보안 기술이 많이 발전했기에 하드웨어상으로 문제가 발생했을 때 Alternative 할 수 있도록 구성을 해야 한다. LAN선은 100미터 넘게도 설치할 수 있겠지만 15M 이상 리피터나 게이트웨이, 허브 등의 구성이 없을 때는 노이즈가 낀다. 튀는 값 때문에 어느 순간에는 네트워크 오류가 자주 발생한다. 네트워크 계층에서 알아서 해 주겠지만 TCP/IP만 믿지 말자. 디버깅 단계에서는 모든 것을 믿어야 하고 설계 단계에서는 모든 것을 의심해야 한다. 비용이 높아질 수 도 있기 때문에 임베디드 장비에 무선 기능 탑재는 옵션으로 두고 사람 손이 닿을 수 있는 곳에 동글을 꽂을 수 있도록 하자. 침수, 누수, 랜선 불량 등으로 IT 문제 때문에 수십 년 뒤에 벽을 뜯어내는 수고로움을 덜기 위해서다. 

케이블은 기가비트 지원이 기본이겠지만 영상 용량이 4K로 가면서 계속 늘고 있기 때문에 10기가 이상 지원으로 할까? 

IDC에서의 최근 트렌드를 검색해 보고 비용 문제와 고려해서 선택해 보자. 이미 해봤다고 자만하지 말고 최신 트렌드를 계속해서 검색하고 이미 검증된 부분과 아닌 부분들을 잘 선택해야 한다.

3

소프트웨어 설계할 때 고려해야 할 것은 고장이 나면 어느 파트에서 고치는 것이 가장 빠르고 비용이 적게 들어  가는가?이다. SI 중에 임베디드 장비와 연결된 부분이 있다. 영상 PLAY 부분인데. 이 프로젝트에서는 임베디드 장비에서 다운로드 후에 영상을 PLAY 할지. 스트리밍으로 지원할지 2가지 옵션이 있었다. 연결 장비가  수십대였는데 중앙에서 관리가 가능해야 했다. 영상을 보내주는 서버는 따로 구성을 하는 것이 맞다. 확장 가능한 것도 이유겠지만 백업 플랜에서 저 비용으로 갈 수 있기 때문이다. 여기서 왜 기술 공개를 잘 안 하는지에 대한 이유가 나온다. 백업 플랜을 아마존 Unlimit 같은 개인 클라우드로 저 비용을 노린다고 하면? 한국 상륙한 아마존이 뭔가 대책을 세우지 않겠나... 물론, 이 시스템에서도 고려를 하고 있고. 또 B2B 기업들이 가격이나 내부 정책을 바꾸었을 때의 대안도 마련되어 있어야 한다. 자잘한 툴의 경우 삼성같이 큰 기업에서도 엔터프라이즈 라이센스가 아닌 개인 라이센스로 개발하는 일이 많았었다.

 이번 시스템에서는 대세에 따라 스트리밍으로 가는 것이 맞다는 의견이 있었지만 이번 프로젝트에서는 임베디드 장비에서 PLAY 되는 것으로 했다. 대신 Bittorrent나 곰플레이어가 지원하는 기능처럼  다운로드하면서 플레이가 가능하도록 해야 했다. 그 이유는 임베디드 장비 1대가 고장 났을 때는 1대만 영상 PLAY가 되지 않는다. 그러나 제어 서버나 영상 서버가 고장 났을 때는 전체 PLAY에 문제가 생긴다. 중앙 서버의 고장을 고칠 동안 받은 영상들은 PLAY를  계속되도록 해야 마치 고장 나지 않은 것처럼 보일 수 있다. 임베디드 장비에 어느 정도 코드를  집어넣을 수 있는, 프로그래밍을 할 수 있는 수준이라 많은 고민들은 임베디드 장비로 이관하기로 하였다.
 이렇게 되면 중앙 제어 서버도 특정 정보들만 제공을 하는 수준이고 임베디드 장비가 알아서 서버에 접속하고 서버에서 환경설정 정보를 받아오고 스스로 판단해서 행동하게끔 되어 있다. 가령 자동으로 전원 on/off 하는 경우도 메시지 큐 형식으로 서버에서 상태 변화  configuration  format을 만들면 임베디드 장비가 필요한 시간에 스스로 접속해서 정보를 읽고 사람들이 있는지 영상 PLAY는  어디까지 되었는지 등 알아서 판단하고 전원을 off 하는 것이다.
 고가용성을 지키기 위해서는 시스템 간 연결고리를 최대한 느슨하게 해 주어야 한다. 이것 하나만 생각하면 된다.

4

이제 고려해야 할 것은 소프트웨어 개발의 문제점이다. 나 역시 기업에서 개발팀장을 하고 있는 입장이지만 프로젝트 성공을 위해서는 사람을 다룰 줄 알아야 하고. 실무적 측면에서 사람 다루는 데는 돈, 혹은 기술 밖에는 없다. 비전만 맞추고 각자 알아서 일하면 되는 큰 시스템과는 달리 작은 시스템에서는 전통적인 상하 방식이고, 장점은 그것이 실패했을 때 아랫사람에게는 책임을 지우지 않는 방식이라는 것. 즉, 독박쓰는 시스템이다. 그래서 보수가 괜찮다.
 나 역시 입으로 일하거나 일정한 위치 선점을 해서 내 것을 챙기면 된다. 그러나 그런 마음가짐으로는 설계를 할 수 없다. 최근 아키텍트가 코더에 비해 낮은 위상으로 인식되는 것도 이와 같은 이유에서이다. 최근 가트너에서 연락 왔을 때도 내가 컨택 채널로 고정되어 권한도 받았으나, 초기 세팅을 하고 실무는 실무자를 정해서 넘겨줬다. 어떤 포지션이던 중간자 역할이 되어 버리면 중간자 입장만 고수하고 문제 발생시 책임 소재를 한정 지어 버린다. 확실하게 일할 기회를 주기 위해서는 '중간자'를 만들면  안 된다. 물론, 그 기회를 받고 싶은지 물어봐야 한다. 강압적으로 책임감이 요구되는 일을 주고 결과를 보면 대부분 '퇴사'로 이어진다.
법적으로 이미 폐지된 연대보증 시스템을 싫어하기는 하지만  '무한책임'에서 오는 긴장감은 본받아서 유지해야 한다는 것.

자, 그럼 초기 셋업 코드는 내가 짜 놔야 한다. 해당 프로젝트가 시작되면 결국엔 실무자가 가장 잘 알기 때문에 프로젝트 중반부터는 담당 엔지니어가 잘하면 잘할수록 설계자의 말을 듣지 않는다. 그러나 초기 코드를 만든 사람의 발언은 먹혀든다. 그래서 초기 코드를 만들거나 초반에 도움을 많이 줘야 프로젝트를 성공시킬 수 있다. 어차피 대부분은 실패해도 덕지덕지 붕대 감아서 무조건 성공시켜야 하는 입장이기는 하다.

초기 코드는 생짜로 전부 직접 짜지 않는다. sourceforge, github 등을 검색해서 쓸만한 애들을  찾아본다. 그리고 라이브러리 구매는 기본이다. 메신저나 화상회의 같은 경우 라이브러리를 사면 손쉽게 구축이 가능하다. 고급 개발자 1달 인건비만 따져보더라도 남는 장사고, 고급 개발자가 한 달 안에 구현해도 품질 테스트에 시간이 또 걸린다. 시간은 가장 큰 '비용'의 척도고, 돈을 쓰는 사람 입장에서는 가격보다는 기간을 더  중요시한다. 4계절이 뚜렷한 국내 사정은 더 심각하다. 공사가 포함된 프로젝트는 계절도 고려해야 한다. 그래서 견적을 뽑을 때 프로젝트 기간을 길게 잡고 싸게 저렴하게 하면 더 선택을 잘 할 거라 생각하는데 그렇지 않다. 대기업과 계약도 그렇다. 그들과의 계약은 모두 비공개이기에 제대로 공개되지 않는다. 한 가지 분명한 점은 결과물을 빨리 보여주고 초반에 빨리 달릴 수 있는 팀을 더 선호한다. 그리고 대기업 구조상 지인을 이용하는 것이 아니라면 그럴  수밖에 없다. 여담이지만 대기업과의 거래에서는 진행에 따라 많게는 70%까지 단가를 후려치는데  대기업 프로젝트를 했던 작은 IT 기업들이 그것을 포트폴리오로 표현할 때는 돈을 많이  벌었다고 생각하면  안 된다. 이름을 남기기 위해 남는 게 거의 없지만 프로젝트를 성공적으로 마쳤다. 정도로 이해하면 된다. 애플스토어의 액세서리들도 애플이 70% 먹는다. 

초기 코드들을 구하더라도 기존 유지될 시스템과 마이그레이션이 가능한지 안 한지 잘 따져봐야 한다.
msdn.microsoft.com
지금도 MSDN Subscription에서 찾을 수도 없는 Visual Studio  6로 시판되는 프로그램을 생산해 내고 있다. 그러나 Windows 10에서 문제가 점점 나오기에 64비트 빌드 옵션으로 처리를 하긴 했다만 언젠가는 마이그레이션 해야 한다. Visual Studio 마이그레이션 하면서 느끼는 점은... 버전 간의 호환성이 없다고 보면 된다는 것이다. 어느 정도 규모가 되고 라이브러리와 연계된 프로젝트는 자동으로 마이그레이션 된 적이 단 한 번도 없다. 개인적으로 말하자면 2008이 명작이고, 2008은 아마 향 후 5년은 더 지원할 것이라 본다. 다만 새로 진행하는 프로젝트는 2015로 갈  수밖에 없다. 최소 10년은 바라봐야 하기 때문이다. 일 년 일 년이 판이하게 다른 스타트업에서의 플레이와는 별개의 세계다.
www.visualstudio.com
Visual Studio 가 무료가 될지 누가 알았겠나?

PostgreSQL: File Browser        
www.postgresql.org
좋은 DB도 무료로 쓸 수 있게 될지...

7-Zip    
www.7-zip.org
데이터 압축도 오픈소스를 선택하고

github.com
오래된 녀석도 여러 라이브러리를 이용해서 손볼 수 있다.

dev.windows.com

시스템 구축에 MAC을 쓰면 참... 깔끔하고 좋겠지만. 아시다시피 리눅스가 가장 오픈적 형태이고  그다음은 윈도즈 기반이다. 오픈이 되면  될수록 고객의 입맛에 맞게 커스터마이징을 할 수 있다. 아쉽게도 BSD나 System V 계열처럼 저널링 파일 시스템을 쓰는 친구들은 계량기 및 전기 공사를 다시 하고 UPS도 달아줘야 해서 최소 2천만 원의 단가가 올라간다. 안정적인 서버에 UPS는 필수겠지만 견적서에 융통성을 두지 않으면 경쟁력이 없다. 게다가 전기세까지 고려하는 시스템은 필요 없는 시간에 전원을 끌 수 있게 설계가 되어야 한다. UPS가 들어가면 벽면과의 공간은 2.5Cm만 뛰우면 된다. 생각보다 작게 띄워도 된다. 벽면과의 거리면 지켜주면 되고 바닥에 놓아도 관계없다. 타워 렉의 가장 하단에 놓는 것도 좋다. 정말 중요한 온도는 0~40를 넘지 말아야 한다. 강한 햇빛, 겨울철 전열기 복사열, 습한 곳에서의 설치는 문제가 된다.


Fin.


업계에서 공개적으로 인지도가 있거나, 여러 프로젝트들과 괜찮은 퍼포먼스로 브로커와 손쉽게 연락이 닿는 사람들에게는 별 어쭙잖은 생각들일지도 모르나. 분명, 도움이 될 사람이 있다는 가정 아래 글을 썼다.

버그의 종류

서두에 밝힙니다. 브런치에 글을 적고 있지만 책 내용에 들어갈 수도 일부만 참고될 수도, 판이하게 다를 수도 있습니다. '대한민국 프로그래머'의 공식 공개 초판은 6월 2일 업로드 됩니다. 그 외 글들은 책과는 무관하게 시간 날 때 마다 생각을 씁니다.

버그의 종류는 많습니다. Coverity 툴 처럼 몇 억씩 줘야 쓸 수 있는 툴의 경우 버그의 종류를 수백가지 지정하고 개발자가 디버깅 하도록 도와줍니다. 힘든 시간이었지만 디버깅 관련해서는 정말 많은 경험을 쌓을 수 있었던 추억입니다. 스타트업 있을 때도 도입하려고 시도했지만 규모가 작아서 안된다고 하더라구요. 디버깅 만큼 연차가 묻어나고 레벨 구분이 확실히 되는 작업도 드뭅니다. 우리 부모님들께서 우리들을 생각해서 하는 한마디 한마디 처럼요. 짧지만 평생을 갑니다.

자바만 해도 Syntax Error, NullPointerException, Array Index, Argument, NumberFormat, 런타임 때 나는 Resource leak, OOM(Out of Memory) 등 다양하게 있지만 제가 생각하는 오류는 크게 4가지 입니다.

컴파일 오류

실행 파일을 만들기 전에 나는 오류 입니다. 컴파일, 링크가 요즘엔 대부분 컴파일이나 빌드로 통합해서 부르니 컴파일 오류라고 했습니다. 컴파일러가 잡아 낼 수 있는 오류입니다. 대표적인데 구문 에러, 인자를 잘못 넣거나, 언어가 요구하는 문법을 틀린 경우 입니다. 링킹할 때는 대부분 라이브러리를 못 찾아서 납니다.

런타임 오류

실행 중에 나는 것입니다. 휴대폰으로 치면 휴대폰이 갑자기 꺼지거나(reset, null pointer exception이 대표적), 멈추거나(특정 파트에서 무한루프를 도는 거죠) 합니다. 다시 켰는데 안되는 경우는 OOM(아우럽메모리) 혹은 파일 시스템이 망가진 경우 입니다. 모두 작동중에 제대로 Exception 처리를 안해줘서 그런거죠. (특히나 저장 용량이 다 차서 부트 영역까지 잡아 먹는 건 파티션을 나눠서 해결해줘야 합니다. 어플리케이션에서 케어할 수 없는 문제라는 거죠)

Algorithm 오류

역시 실행 중에 납니다. 그러나 가장 잡기 어려운 버그 입니다. Algorithm 이 뭔지 말했으니 알고리즘 오류라고 하겠습니다. 메소드 오류, 펑션 오류, 객체의 행동 오류등 다양하게 불러도 됩니다. 사람이 잘못 짠 것 입니다. 컴파일, 링크가 잘 되는데 원하는 결과값이 안나오는 경우 입니다. 

철학의 오류

대학생 멘토링을 하면서 얻은 새로운 오류 입니다. 화려한 경력으로 치장된 개발자들이 잘못 가르쳐 주기 때문에 나는 오류 입니다. 명문대 출신의 졸업반 친구들이 비전공자이지만 자기 인생을 걸고 전직(직업을 바꾸는)을 합니다. 캐릭터 스탯을 다시 찍어야 하는 경우 입니다. 이 때 가장 중요한 것이 자신감을 가지는 일입니다. 자신감을 가지려면 열심히 하면 되는데 독이 되는 사람들이 많습니다. 특히나 전공했던 사람들입니다. 
For Loop 실행 순서도 잘 모르는 사람이 많았습니다. 기초 문법도 모릅니다. Ctrl+C, V 에 무조건 최신 기술지향을 단 한번만 성공하면 됩니다. 비교 대상이 되지 않습니다. 우린 분야가 다르고 난 내 분야에 최고라고 말합니다. 생각 자체의 오류를 철학의 오류라고 합니다. 불륜을 조장하는 애슐리매디슨의 고객은 삼천만명이 넘습니다. 분명 우수한 시스템일 것이고 위에서 말한 오류들을 무수히 잡았을 것입니다. 그러나 철학적 오류가 있는 것입니다.



선행개발과 상품화팀에만 오래 있어서 직업병이 생긴 것인지도 모르겠습니다. 선행개발 직업병으로 볼 때, 최근 학생들이 하는 대부분의 새로운 프로젝트라고 하는 것들은 이미 오픈소스로 나와 있습니다. 그것을 가져와서 실행만 시키는 스크립트 키들이면서 새로운 도전이라 말합니다. 평가받기를 거부 합니다. 
상품화 직업병으로 볼 때 제대로 동작하지 않는 것을 최종 결과물로 내려고 합니다. 단 한번이라도 신박한 기능이 시연되는 것이 목표입니다. 차라리 만들지 않은 것이 낫다고 생각합니다. 우리 가족이 산에서 위급 상황을 만났는데 휴대폰 오류로 목숨이 위태롭다고 생각해 봅시다. 차라리 아무것도 만들지 않는게 낫습니다.

완전히 새로운 것에 대한 도전 정신을 가지던지, 처음 계획한 결과물을 완벽한 형태로 내던지. 그게 다니면 두마리 토끼를 잡기 위해서 멋진 아이템에 도전하며 밤낮으로 디버깅할 지언정, 목표로의 열망을 잃지 않던지. 온 힘을 다해야 하는데 참 답답함을 많이 느꼈습니다. 아닌 친구들도 많습니다. 반짝이는 눈빛 하나로 꿈을 말하는 친구들도많이 있습니다. 대체로 이런 현상이 난다는 것이죠. 반성합니다. 제대로 가르쳐 주지 못한 기성 세대의 잘못입니다.

국내에서 묵묵히 제품의 완성도를 올리기 위해 디버깅을 하고 있는 개발자 분들. 감춰진 소스와 자신의 문제가 아니라고 하는 정치 속에서도 일하시는 분들. 또, 국내 최고의 실력을 가지고 세계와 경쟁하는 분들은 책 쓸 시간이 없습니다. 이에, 재차 계속 권유를 드리고 있습니다. 저 역시 대한민국 개발 문화를 바꾸려고 시작했으니 한번 뽑은 칼은 끝까지 가보려고 합니다. 문화를 만들어 보려고 합니다.

대학원생의 투고 지도 ④ (완결) — 논문의 수준이란 무엇인가: 사다리와 사분위, 첫 논문 전략

완결편이다. "논문 수준"이라는 말을 해부하고, 에듀테크 석사생의 첫 논문 전략으로 마친다. 학위논문과 학술지 논문은 다른 장르다 먼저 가장 흔한 혼동부터. 학위논문(thesis)은 "내가 연구를 수행할 줄 안다...