최고의 투자자 워렌버핏이 배당금으로 2년마다 원금 회수하는 주식 = 코카콜라

위의 내용을 요약하면, 지금으로부터 30년전에 투자를 했다고 하고, 현재 기준으로 배당률이 50%가 넘는다고 합니다 ㅎㄷㄷ

우리나라에도 코카콜라 못지 않게 꾸준히 우성장하면서, 한국 기업치고 배당금을 잘 주는 기업이 있죠! 외쳐 삼성전자

한국에서는 대부분 연배당이지만, 삼전은 분기배당으로 주고 있고, 배당금액도 올라가고 있고, 무엇보다 주가도 잘 오르기 때문에, 장기적으로 보면 괜찮은 접근이라고 생각이 됩니다

특히나, 삼전은 최근에 계속 조정을 받고 있어서 7만전자의 선이 깨지고 6만원대 후반까지 떨어져있어서 매력적인 구간이라고 보여집니다.

일단 오늘의 주제인 배당률에 대해 비교해보겠습니다.

같은 조건에서 2개 기업의 배당률과 수익률을 계산했습니다

(1월 시가 기준, 현재가는 22년 4월 5일 기준)

코카콜라

91년01월 가격 : 4.87달러

11년01월 가격 : 32.94달러

현재가격 : 62.88달러

연배당금 : 1.68달러

현재 배당률 : 2.6% (= 1.68 / 62.88 * 100)

30년전에 샀을때 배당률 : 34% (= 1.68 / 4.87 * 100)

10년전에 샀을때 배당률 : 5.1% (= 1.68 / 32.94 * 100)

삼성전자

91년01월 가격 : 312원

11년01월 가격 : 19100원

현재가격 : 69200원

연 배당금 : 1444원

현재 배당률 : 2.08% (= 1444 / 69200 * 100)

30년전에 샀을때 배당률 : 462% (= 1444 / 312 * 100)

10년전에 샀을때 배당률 : 7.5% (= 1444 / 19100 * 100)

허허...

30년전에 코카콜라 주식을 산 워렌 버핏은 매년 34%의 이자를 받습니다

(버핏 할아버지는 88년도부터 샀기 때문에 더 싸고, 배당률이 높아서 52%정도 된다하네요)

30년전에 삼성전자 주식을 산 누군가는 매년 원금의 4배이상을 받고 있네요//

결론

다시 보자 삼성전자!

• 계속해서 오르는 주가(성장성)
• 점점 높아지는 배당금(+앞으로는 좀 더 주주 친화적이게 변신하지 않을까..)

하지만, 여기서 조심해야 할 포인트가 2가지 있는데요!

1. 배당

• 꾸준히 우성장하면서, 배당을 수십년간 끊기지 않고 늘려온 코카콜라와 달리,
  삼성전자는 배당금을 언제부터 줬는지 확인하지 못했지만, 코카콜라보다는 배당 역사가 많이 짧을겁니다.

2. 성장성

• 사실 삼전의 이자율이 저렇게 사기급으로 나온 이유는 반도체, 휴대전화 사업을 성공적으로 이끌면서 엄청난 성장을 했기 때문에, 주가가 코카콜라에 비해 급격하게 많이 올라서, 더 많이 주는것처럼 보여집니다.

진짜 결론!!

앞으로도 삼전이 세계 탑티어의 반도체, 전자제품, 휴대폰 시장을 장악해서 살아남는다면, 엄청난 성장주이면서 동시에 엄청난 배당주가 될 수 있어 보입니다.

하지만! 배당주는 더디더라도 꾸준히 배당률을 올려가면서, 끊기지 않고 돌려줘야 한다고 생각합니다. 

코카콜라가 소비재로써 그래서 더 적합한 주식이라 생각되긴 하네요.

하지만 저는 코카콜라보단 삼전에 투자하겠...

삼슬라에 대해 궁금하신 분은 전에 작성한 아래 글에서 확인!

투자 정보

매도 종목 : TSL3
매도 가격 : \7001 (매수가:\5167, 수량:2771개)

총 투자금 : 1430만원

수익률 : 35.36% (수익:약 500만 원)
매도 이유 :

• 메인 계좌에 테슬라를 이미 400 후반대에 들고 있는 대투자자로서, 테슬라에 대한 확신이 있었음
• 과도한 폭락 시마다 계속해서 추매함 (테슬라 $900에서 사고 800 아래로 떨어질 때마다 계속 줍줍)
• 테슬라의 가격이 목표가인 $1000이 장 중에 도달 하자마 수익 실현

투자 후기

1. 리스크가 "진짜" 높다
2. 수수료도 "진짜" 높다
3. 낮은 거래량
4. 영국에 상장
5. 기타 제약 사항

설명

1. 리스크가 "진짜" 높다 (장점 + 단점)
   -> 투자하고 있을 때 하나의 종목을 3배로 추종하다 보니 오르락/내리락이 더 다이나믹..
2. 수수료도 "진짜" 높다 (단점)
   -> 0.0163%/1일 (5.94%/1년) 이보다 높은 수수료는 본 적이 없음
   -> 가만히 있어도 투자금이 매일 0.0163%씩 녹는 경험
3. 낮은 거래량 (단점)
   -> 평균 거래량 40000건이 안 되는 지극히 적은 거래량
   -> 내가 팔고 싶어도, 팔리지 않을 수 있는 리스크 존재
   -> 오죽하면 매도 할 때 1500만 원어치를 한 번에 걸었더니, 나 혼자서  당일 최고 막대기 세움 (아래 스샷)
4. 영국에 상장 (단점)
   -> 우리나라에서는 삼성증권 말고, 다른 증권사는 매매 자체가 불가능 (영국 시장)
5. 제약사항 (단점)
   -> 당일 매수 후 5일 이후 매도 가능 (3~5일 정도인 듯)
   -> 최소 매도 물량 있음 (최소 10개 이상 있어야 매도 가능)

결론

엄청난 단점이 무려 4개나 있지만!! (높은 수수료, 낮은 거래량, 영국 시장의 불편한 접근성, 기타 많은 제약 사항)

그걸 커버할 만큼의 수익률이기 때문에 투자했지만! 장이 좋지 않으면 진짜 위험할 듯

이미, 테슬라 주주로써 확실한 믿음이 있기 때문에 평단가를 높이지 않고도 더 많은 수익 창출 가능!!

앞으로도 테슬라 800선이 위태하면, 투자를 고려할 마음이 있다!

FNGU, BULZ에 투자해서 손절하고 여기에 물 타서 투자한 게 신의 한 수였다! 
-700중에 500을 해결해주신 귀인.. 오늘도 테멘

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

후..

1월달에 조정을 받은 후에 3일에 나눠서 분할 매수를 했는데
매수 타이밍이 너무 빨랐던 탓일까...

매수하자마자 첫주에는 +10% 찍어서.. 역시 난가?! 했는데..

FOMC와 금리 이슈를 들면서 시장이 과도하게 조정을 받았다...
둘째주 -20%
셋째주 -30%
1월 마지막날에는 결국 -12%대..

글을 쓰고 있는 시점에는 -8%에서 왔다갔다 하고 있는데..
아직 조정이 다 끝난것 같지는 않아서 두려워~ 겁시나~

언제까지 조정장이 계속 될지 모르겠으나  

그때까지 같이 존버해보자구욧!

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. 공모주 청약

말 많던 LG에너지솔루션 청약이 오늘(1월18일)부로 시작됐습니다

저도 30만원 기준 10주, 증거금(50%) 150만원을 넣고 신청했습니다

왜 청약을 해야하는 지는..

2. KB 증권

KB가 물량이 가장 많기도 하고 해서 1~2주 정도 예상하고 KB로 신청했습니다

눈치보고 끝에 신청한다 해도 비슷할거 같고, 사실 다른 증권사는 제가 없기 때문에..ㅎㅎ

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/