망했을때 어떻게 할것인가를 고민하는것이 중요한 이유(정리)

MariaDB 쿼리

: 범위 별로 개수 구하기

2가지 방법 (sum & case 사용 방법과 count & case 사용방법)

-- 쿼리1 - sum / case  사용
select
    sum(case when usage < 1 then 1 end) '1',
    sum(case when 1 <= usage and usage < 10 then 1 end) '10',
    sum(case when 10 <= usage and usage < 100  then 1 end) '100',
    sum(case when usage > 100 then 1  end) '100+'
from
    TABLE

-- 쿼리2 - count / case 사용
select
    COUNT(case when age < 10 then 1 end) as '아이',
    COUNT(case when 10 < age and age < 20 then 1 end) as '10대',
    COUNT(case when 20 < age and age < 30 then 1 end) as '20대'
from
    TABLE

1줄 요약

카운트만 필요 할 때는 COUNT(*)가 가장 빠르다

COUNT(*) >  COUNT(컬럼) > COUNT(DISTINCT(컬럼))

 출처 : https://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=77484 

본문

누구나 다 알고 있는 지식이긴 하지만 모두들 적게나마 공유를 하고자 글을 남기도록 하겠습니다.

중복 내용이면 죄송합니다. 그럼 시작하겠습니다.

일반 SQL 질의의 SELECT 절에의 *는 모든 컬럼을 가지고 오기 때문에

필요한 컬럼만 가지고 오는 SELECT 절에 비해 속도가 느리고 불필요한 자원을

낭비한다는 사실은 모두가 알고 있을 것입니다.

그렇기 때문에 이러한 것을 똑같이 생각함으로 인해 집계함수의 COUNT에 대한 COUNT(*) 와

COUNT(컬럼)에 대한 잘못된 인식과 SQL 질의를 실행하여 DB의속도를 느리게 할 수 있는 원인이 될 수 있습니다.

일반 SQL질의와 다르게 COUNT 집계함수에서의 *의 역할은 다른 역할을 수행하고 있습니다.

* MySQL COUNT 함수의 역할을 보면

COUNT(*) : 단순 행을 세는 역할을 합니다. (MySQL 내부적으로 데이터를 읽지않고 행의 갯수만 흝고 지나간다는 뜻을 말합니다.)

COUNT(컬럼) : 행의 값을 세는 역할을 합니다.(데이터를 읽는다는 뜻이 되겠지요)

자 그럼, 컬럼이 VARCHAR(50) 형태의 데이터가 100만건이 있다는 가정하에 실행계획 및 질의를 실행에 보도록 하겠습니다.

* 실행계획

1) COUNT(*) : 우선 단순 행을 세는 COUNT(*)의 실행계획을 보도록 하겠습니다.

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE Select tables optimized away

Select tables optimized away : 인덱스, 또는 MyISAM용 COUNT(*)을 사용하되 GROUP BY 구문은 사용하지 않은 채로 처리된 집단 함수(MIN(), MAX())만을 가지고 있음.

2) COUNT(컬럼) : 데이터를 읽고 지나가는 COUNT(컬럼)의 실행계획을 보도록 하겠습니다.

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE performance1 ALL 1000000

실행계획을 보면 알듯이 type을 보면 알 수 있듯이 ALL로 전체를 스캔하는 것을 알 수 있수 있을 것입니다.

3) COUNT(DISTINCT(컬럼)): DISTINCT에 데이터를 읽고 지나가는 COUNT(DISTINCT(컬럼))의 실행계획을 보도록 하겠습니다.

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE performance1 ALL 1000000

COUNT(DISTINCT(컬럼))도 type을 보면 알 수 있듯이 ALL로 전체를 스캔하는 것을 알 수 있을 것입니다.


실행계획을 봤으니 SQL질의를 실행하여 실행시간을 비교해 보도록 하겠습니다.

* 실행결과를 종합해 보면

1) COUNT(*) : 0:00:00.029
2) COUNT(컬럼) : 0:00:00.201
3) COUNT(DISTINCT(컬럼)) : 0:00:02.413

COUNT(DISTINCT(컬럼))  < COUNT(컬럼) < COUNT(*) 순입니다.

그렇습니다. 불필요한 데이터를 셀 필요없이 행의 갯수만 얻고 싶다면 당연히 * 쓰는게 훨씬 속도

가 빠르다는 사실을 알 수 있을 것을 것입니다.

그러면 '혹시 컬럼에 인덱스를 걸어주면 데이터를 세더라도 count(*)보다 빠르지 않을까?' 라는 생각이 문득 들어서

컬럼 하나에 인덱스를 걸고 인덱스를 타게 해서 질의를 실행하여 비교해 보도록 하였습니다.

* 실행계획

1) COUNT(*)

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE Select tables optimized away

2) COUNT(컬럼)

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE performance2 index index 153 1000000 Using index

3) COUNT(DISTINCT(컬럼))

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE performance2 index index 153 1000000 Using index


* 실행결과를 다시 종합해보면

1) COUNT(*) : 0:00:00.054
2) COUNT(컬럼) : 0:00:00.592
3) COUNT(DISTINCT(컬럼)) : 0:00:02.955

그렇습니다. 실행결과를 보면 인덱스 거는거에 상관없이 COUNT(*)이 가장 빠르게 질의를 수행한다는 것을 알 수 있

을 것입니다. 누구나 다 아는 사실이지만, 참고가 될 수 있도록 글을 기재합니다.

[ 실행환경 ]

MySQL Version : 5.1.41-community

테이블 형태 : MyISAM

컬럼 형태 : varchar(50)

문의 내용이 있으시면 쪽지로 주시면 감사하겠습니다.

끝까지 읽어주셔서 감사합니다.

상황

로컬(IDE) 환경에서 잘 실행되던 로직인데,
Jar파일로 실행할때 에러 발생 (FileNotFoundException)

Log

 java.io.FileNotFoundException: src/main/resources/keystore/server.truststore (그런 파일이나 디렉터리가 없습니다)

원인

에러가 생기는 부분은 아래와 같다.

 File trustStoreFile = new File(trustStoreFilePath);

• jar로 실행시에는, IDE에서의 file 시스템과 경로가 다름
• 로컬 IDE 환경에서 File을 사용하려 하면 file:// 로 시작되는 url (실제 파일 시스템으로 접근)
  Jar 실행 환경에서 File을 사용하려 하면 jar://로 시작되는 url

해결 방법

inputStream을 이용

// 수정전
File file = new ClassPathResource(filePath).getFile();


// 수정후
InputStream instream = new ClassPathResource(filePath).getInputStream();

// InputStream 을 이용해 File 생성 후 사용하는 방법
File somethingFile = File.createTempFile("test", ".txt");
try {
    FileUtils.copyInputStreamToFile(inputStream, somethingFile);
} finally {
    IOUtils.closeQuietly(inputStream);
}

주의!

• File Path 변경
  기본 classpath: src/main/resource
  filePath=src/main/resource/keystore/test.jks
  => (아래로 수정)
  filePath=keystore/test.jks
  
  
• ClassPathResource(filePath).getFile();에서 에러 발생
  java.io.FileNotFoundException: class path resource [파일] cannot be resolved to absolute file path because it does not reside in the file system: jar:file:/....

자세히 알고 싶다면 아래에서 확인

참고 - https://sonegy.wordpress.com/2015/07/23/spring-boot-executable-jar%EC%97%90%EC%84%9C-file-resource-%EC%B2%98%EB%A6%AC/

하이라이트

인생은 곱셈 => 내가 0이면 뭘 만나도 0이다

내가 0이 되지 않기 위해 항상 도전

내가 걸어온 길을 인생철학에 빗대어 설명할 줄 아는 사람이 대체 불가능한 사람이다

인터뷰 내용 정리

• 프로필 : 페이스북 SF엔지니어 5년반, 뱅크 샐러드에서 근무 중, 스탠퍼드 MBA 공부중
• 학생 시절 살찐 곰이 나의 이미지
  => 그 편견을 깨고 나온 경험이, 사람들의 편견에 나를 익숙하게 하지 말고, 나를 변하게 할 수 있는 사람이 되자
• 카이스트를 나오면 좋은 대기업을 정해진대로 가는 걸 깨고 나와보자 해서 3개월 나오고 자퇴 결심
• 바로 버클리 대학에 입학 => EECS(전기공학 + 컴퓨터공학) 전공이라 공부량이 어마어마해서 힘듦 
  => 시험중에 1시간 후에 깨워서 시험을 마칠 정도로 열심히 살던 시기
• 인생 모토 : 단기적으로는 비관론자, 장기적으로는 낙관론자
  => 열심히 준비를 하되, 결과에 대해서는 긍정적으로!
• 입사한 페이스북은 자유롭고 좋지만, 그만큼 책임감이 따른다 
  => 계약조건을 하루 만에도 잘릴 수 있을 정도로, 자유는 무제한이지만, 그만큼 책임감이 무겁다
  이것은 마치 큰 힘에는 큰 책임감이 따른단다 피터..?
• 잠자는 시간 말고는 나의 서비스에 대해 24시간 대응을 해야 함
  => 회사에서 더 잘 대우해줘야 하는 게 아닐까 싶을정도
  마치 작년의 나를 보는 것 같네..
• 페북에서 가장 자랑스러운 기억은 큰 보상이 보장된 프로젝트가 아닌 '내가 하고 싶은 프로젝트'
  = 페북에 올린 비디오를 외부 사이트에 임베딩 시키는 기능
  => 몇 건의 메일을 받고, 반대하는 위의 사람들을 설득했고, 성공적으로 만들고, 페북의 이용시간의 몇 프로가 해당 채널로 나옴
  => 성과를 인정받아, 페이스북 개발자의 블로그에 남는 영광을 누림 (이게 2년 차 재직 시절)
• 2번의 승진을 하면 레벨 5가 되는데, 보상도 크고, 종신적으로 있을 수 있지만, 그건 너무 답답할 것으로 생각
  => 페북은 물론 크지만 그곳에 우물 안 개구리가 되고 싶지 않다고 생각
• 뱅크 샐러드를 고른 이유 : 업계 1위가 아닌 회사, 페북의 인재풀이 너무 좋았기 때문에, 회사의 후광을 뒤에 두고, 내가 아니어도 누군가가 했을 것 같다
  => 내 성장을 극대화하려면 그렇지 않은 곳으로 가는 것이 더 좋을 것 같다
• 뱅크 샐러드의 가장 큰 장점
  => CEO의 가까운 데서 일하면서, 어떤 생각과 문제로 시달리는지 간접경험을 할 수 있다
  => 같이 일하는 사람들이 굉장히 뛰어나다 (실리콘밸리 이에 비해 떨어지지 않는 인재들도 많다)
• 뱅샐을 다니면서 MBA를 준비
  => 하나의 스타트업에는 영향을 줬지만, 더 큰 임팩트를 주고 싶다
  => 다른 한국 기업들의 글로벌 역량에도 도움이 되는 일을 하고 싶다
  => 스탠퍼드/하버드 동시에 붙었지만, 둘 다 좋은 곳이지만, 결국 스탠퍼드를 선택
• 아직 어떤 문제를 풀기 위해 이 세상에 왔는가 
  => 아직 답조차 없고, 어떤 문제를 풀지 전진할지 정하지 못함
• 인생은 곱셈과 같다. 내가 0이면 어떤 기회가 와도 0일뿐이다.
  => 내 인생에 좋은 기회가 많이 오더라도, 내가 준비되지 않으면 0일뿐이다
  => 항상 도전하는 자세
  => 그로 인해 좋은 기회가 많이 생긴다
  => 결과가 실패하던 성공을 하던 그 과정에서 얻는 것이 본인 만의 스토리
  => 스토리가 있는 삶이 멋진 삶이다!
  => 나의 인생에 빗대어 내가 걸어온 길을 설명하는 게 찐 멋짐이다!!

느낀 점

와.. 진짜 조곤조곤하게 말하는데, 멋있는 말이 굉장히 많이 나왔다.

MBA를 나오고 나서 행보도 기대되고, 지금 뱅샐도 많이 좋아졌지만

또 그 틀을 깨고 다른 도전을 하러 갈 인우형을 응원하겠습니다!

이 인터뷰 거의 명언제조기..

인터뷰 원본 영상 보기

일론 머스크가 만든 인공지능 회사 OpenAI에 입사한 유니스트 대학생으로 화제가 됐던 김태훈 님의 인터뷰

인터뷰 내용 + 나의 생각 정리

• 틈만 나면 새로운 걸 만들어야겠다 생각함
• 내가 우물 안의 개구리라는걸 느끼는 순간이 본인이 가장 성장한 순간
  : 나보다 훨씬 똑똑하고 대단한 사람은 이미 충분히 많은데, 그걸 느끼는 순간 우물에서 벗어날 수 있다
• GOOGLE / OPENAI 에서의 제의
  -> 텐서 플로우가 궁금해서 모두의 연구소라는 스터디 모임에 참여
  -> 다들 논문을 구현해와서, 본인도 다음 모임에 논문을 구현해서 페이스북/레딧에도 업로드
  -> 구글의 제프딘이 직접 같이 일하면 좋을 것 같다고 제의
  -> 하지만, 병특 진행중이라, 군대 문제 때문에 결렬
  -> 대신 병특이 끝나는 2년 후를 기약하며, 매주 새로운 논문을 구현해서 업로드
  -> 1년을 남기고 OPENAI의 제안을 받아 면접을 보고 후에 입사
• 인터넷:
  주변사람/오프라인에서 만날 수 없던 사람들이 어떤 경험을 하는지 보면서
  전 세계에는 굉장히 뛰어난 사람이 많다는 걸 깨달음
• 주변에 있는 사람보다 잘하는 게 중요한게 아니라
  전 세계에 있는 인재들과 겨룰 만큼 뛰어난 게 중요하다
• 인간을 대체할수 있는 AI를 강 인공지능이라고 한다
• OPENAI에는 본인이 강인공지능을 만들 수 있다고 말할 정도로 뛰어난 사람들이 많다
• 2년간 많은 프로젝트에 참여 - 강화 학습, 로봇 연구, 딥러닝 모델 최적화 등등
• 한국과 가장 다른건 팀 간의 커뮤니케이션이 가장 활발하다
• 팀별로 밥을 먹지 않고, 온 순서대로 앉아서 밥을 먹으면서, 뭘 하고 있고, 누구와 함께하면, 어떻게 하면 생산성을 극대화할 수 있을지 적극적으로 도움을 요청하는 모습이 좋았다
• 피자타임
  오후 5시쯤 피자 한판 올려두면, 피자 한조각씩 들고, (부담 없이 얘기하는 자리)
  얘기를 하다 보면 프로젝트에 대한 인사이트나 방향을 제시해주는 네트워킹 자리가 자연스럽게 생기는 문화가 더 좋은 환경을 만들었을 것 같다고 생각함
• 새로운걸, 사람들이 좋아하는 걸 만드는 걸 만드는걸 좋아했는데,
  막상 해보니 기대와 다르고, 본인이 하고 싶은 일이 맞는지에 대한 고민
• 갭이어를 가지면서 그동안 하지 못했던 일들을 하고 싶어 OPENAI에서 퇴사를 결심
• 목표를 달성해야지만 진짜 좋아하는지 아닌지를 깨달을 수 있다
• 자신의 안전지대(comfort zone)를 넘어서자!
  사람은 결심만으로 바뀌지 않는다
  변화기 위해선
  쓰는 시간을 바꾸거나,
  장소를 바꾸거나,
  만나는 사람을 바꿔야 한다
  새로운 도전을 하는 게 개인의 성장에 도움이 된다
• 내가 좋아하는 것 + 내가 잘하는 것 + 세상이 원하는 것의 교집합을 찾아야 성공할 수 있다

원본 영상

시중에 주식 자동 매매 시스템을 만드는 교재부터 인터넷 강의까지, 요즘에 더 많이 생긴 것 같네요.
올해 초에 Class101에 올라온 주식을 자동으로 매매해주는 "AI 자동 투자 봇" 클래스를 들으면서 구현하면서 느낀 점을 정리해보려 합니다.

결론적으로 말하면, 끝까지 만들지 못했고, 커리큘럼을 2/3정도 들은 시점에서 저의 인사이트가 바뀌었고,
그로 인해 그만 두게되었습니다.

1. "주식 자동 매매 봇" 프로젝트를 시작한 이유(목적)

개발을 업으로 하고 있는 사람으로서, 파이썬에 대한 관심도 있고, 주식도 좋아하는 입장에서 아주 구미가 댕기는 주제였습니다. 그리고 아래 3가지 이유로 해당 프로젝트를 시작하게 됐습니다.

• 개발자로서 파이썬을 이용한 토이 프로젝트
• 주식 매매 골든룰 (알고리즘) 발견
• 매매 봇을 운영하면서 얻는 부수입

2. 구성

투자 봇은 크게 3가지 기능으로 구성됩니다

Crawler

: 매일 특정 시간 스케쥴러를 돌려 분/일별 주식 data를 가져와 db화 하는 작업
- Crawler : Open API에서 주식 데이터를 긁어오는 기능
- 스케쥴러 : 매일 특정 시간대에 특정 기능 crawler 실행
- DB화 : crawler로 긁어온 data를 DB에 자동으로 분류해서 저장

Simulator

: DB에 저장된 data로 매매 알고리즘을 시뮬레이션해서 수익률 + 알고리즘 검증
- 파이썬을 이용한 매매 알고리즘 구현
- 주식/차트에 대한 공부 필요

자동 매매 봇

: 알고리즘에 맞는 상황일 때, 주식을 실제로 자동 매매해주는 기능

3. 주식 매매 알고리즘을 고민하며 얻은 깨달음

이렇게 위처럼 인프라를 구성한 후에, 나만의 매매 알고리즘을 고민하고 구현했습니다.
그리고 구축해놓은 DB로 백테스팅을 하면서 수익률을 체크하고, 해당 알고리즘으로 가상/실제 매매를 실행해보면서 실제로 효과가 있는 알고리즘을 모아가면 됩니다.

기대 수익률 저하
그렇게 내린 결론은 "항상 이익을 낼 수 있는 골든룰이란 건 없다"였습니다. 워낙에 현실에서는 변수가 많고 복잡하기 때문에, 주가를 예측하기란 쉽지 않습니다. 오히려 최대한 단순한 규칙으로 조금씩 수익을 내는 방법이 더 안정적으로 벌 수 있겠다는 생각도 들었고요.

생각보다 공수가 많이 들어감
하지만 그렇게 되면 지금 손으로 직접 하는 투자보다 수익률은 떨어지는데, 알고리즘은 알고리즘 대로 계속해서 수정해주고, 테스트해줘야 하는 상황이 될 것이라고 판단했습니다. 근데 이 알고리즘이라는 게 구현하면 할수록 복잡해지고, 예외도 많아서, 손이 매일같이 갈 수밖에 없었습니다. 그렇다고 손 투자에 비해 수익률이 좋은지도 모르겠고요.

실제 월가에서도 이미 시스템을 이용한 매매를 하고 있지만, 그 전문가들이 모여서도 계속해서 수익을 내는 게 쉽지 않으니, 예상은 했지만! 제가 할 수 있는 선에서의 프로그램은 생각보다 비효율적이라는 결론을 내리게 됐습니다.

요약

• 골든룰 x : 알고리즘 수정을 생각보다 자주 해줘야 함 (공수가 많이 들어감)
• 기대 수익률이 손 투자보다 높지 않음

4. 결론

저의 취미 수준의 프로젝트를 기준에서..
빅데이터를 이용해 실제로 의미 있는 결과를 내기가 불가능해 보였고, 그래서 해당 프로젝트는 여기에서 접기로 했습니다.
오히려 수익률이 좋은 손 투자를 편하게 도와줄 수 있는 정보를 크롤링해서 보여주는 챗봇 프로젝트를 기획해서 만들어 보기로 했습니다!
만... 잠시 권태기가 와서 개발 중간에 멈춰 있는 상황이네요 ㅎㅎ
내년에는 부디 마무리할 수 있기를 바라면서..

끄읕!

그렇다면, 가장 안전한 시장의 평균 수익률과 그 3배를 추종한다면 

오히려 더 높은 수익률이 아닐까?!

가장 안전하게! 시장 평균 수익률을 내는 방법

시장 평균 수익률 * 3배 하는 방법

매운 투자가 끌린다면..