실전코드로 배우는 플러터 기본과 활용

Do it! 플러터 앱프로그래밍

어제는 Flutter의 등장배경과 Flutter에서 사용하는 언어인 Dart의 특징에 대해 간략히 배웠습니다. 

오늘은 플러터의 내부 구조(간단한 샘플코딩)와 위젯의 생명주기에 대해 공부하고자 합니다. 위젯의 생명주기는 안드로이드 액티비티의 생명주기와 비슷하다고 생각하시면 됩니다.

폴더 및 주요 파일 안내

Flutter 프로젝트 구조. 시작 파일은 lib>main.dart

폴더 내용 비고
android 안드로이드 프로젝트 관련 파일 안드로이드 스튜디오로 실행 가능
ios iOS 프로젝트 관련 파일 엑스코드로 실행 가능(맥 전용)
lib 플러터 앱 개발을 위한 다트 파일 플러터 SDK 설치 필요
test 플러터 앱 개발 중 테스트 파일 테스트 편의성 제공
파일 내용 비고
pubspec.yaml 패키지, 이미지, 폰트 등 asset 설정 직접 관리
README.md 프로젝트 소개
.gitignore git에 커밋, 푸시 등 소스 코드를 업로드할 때 필요 없는 파일 기록
서버 주요 정보, 운영/테스트 구분에 따른 배포시 배제해야 할 파일들 명시
.metadata 플러터 SDK 정보 자동 관리
.packages 플러터 SDK에 사용할 기본 패키지 경로
first_flutter_app.iml 파일이 자동으로 생성될때 만들어지는 폴더 위치
pubspec.lock pubspec.yaml 파일에 적용된 패키지 위치

* 플러터는 위젯 기반으로 개발하며, 위젯은 클래스로 정의하여 상속 개념이 존재합니다. 텍스트박스, 이미지, 버튼 모두가 위젯 클래스로 변경이 필요하면, 상속받아 필요한 속성만 수정하면 됩니다. 위젯은 크게 2가지 나눕니다. 상태 고정(statless, 화면에 보이기 위해 로딩한 순간 상태감시를 하지 않아 변화가 없는 위젯)과 상태변경(statefull, 동적 위젯으로 상태를 감시하다 알맞게 화면 변경) 입니다. 따라서 화면 변경이 필요한 경우, statefull 위젯에 코딩해야 합니다. 

교제에 나와 있는대로, 버튼 클릭시 글씨와 버튼색이 변하는 것을 statless위젯(클래스)에 개발하면 아무런 변화가 없지만, statefull위젯에 개발하면 화면이 변하는 것을 확인할 수 있습니다.

추가로 책의 예제를 따라 코딩해보면, 플러터 버전에 따라 폐기된 위젯들이 있어 아래와 같이 소스를 수정해서 코딩해야 합니다. 

// 교제 소스 //
child: RaisedButton (
            child: Text('$test'),
            color: _color,
            onPressed: () {
              if (test == 'hello') {
                setState(() {
                  test = 'Flutter';
                  _color = Colors.amber;
                });
              } else {
                setState(() {
                  test = 'hello';
                  _color = Colors.blue;
                });
              }
            },
          ),
// 수정 RaisedButton -> ElevatedButton
// 수정 style: ElevatedButton.styleFrom 이용
child: ElevatedButton (
            child: Text('$test'),
            style: ElevatedButton.styleFrom(
              primary: _color,
            ),
            onPressed: () {
              if (test == 'hello') {
                setState(() {
                  test = 'Flutter';
                  _color = Colors.amber;
                });
              } else {
                setState(() {
                  test = 'hello';
                  _color = Colors.blue;
                });
              }
            },
          ),

* visualDensity 속성은 앱이 모바일, 웹, 데스크톱, 맥 등 어떤 플랫폼에서도 자연스럽게 보이도록 지원

위젯의 생명 주기 이해

class MyHomePage extends StatefulWidget {
	@override
    _MyHomePageState createState() => new _MyHomePageState();
}

State와 StatefulWidget 클래스를 나눈 이유는 성능 때문입니다. State 클래스가 무겁다 보니, StatefulWidget에서 감시하고 있다가 상태 변경 신호가 오면, State클래스로 화면을 갱신하도록 합니다. 만약 StatefulWidget에서 바로 갱신하면, 화면이 종료되더라도 할당받은 메모리를 바로 반환하지 않기 때문에 두개는 분리한 것입니다. 

호출순서 생명주기 내용
1 createState() 처음 스테이트풀을 시작할 때 호출
2 mounted == true createState() 함수가 호출되면 mounted 는 true
3 initState() State에서 제일 먼저 실행되는 함수. State 생성 후 한번만 호출
4 didChangeDependecies() initState() 호출후에 호출되는 함수
5 build() 위젯을 렌더링하는 함수. 위젯을 반환(=화면에 표시)
6 didUpdateWidget() 위젯을 변경해야 할 때 호출하는 함수
7 setState() 데이터가 변경되었음을 알리는 함수. 변경된 데이터를 UI에 적용하기 위해 필요
8 deactivate() State가 제거될 때 호출
9 dispose() State가 완전히 제거되었을 때 호출
10 mounted == false 모든 프로세스가 종료된 후 mounted가 falsed가 됨

 

요약(프로젝트 구조, 위젯 생애주기...)
• 프로젝트 주요폴더, 파일에 대해 확인
• createState(), initState(), build(), setState(), dispose() 등 생애주기 과정에 log, 데이터 처리 등 수행

 

Posted by 목표를 가지고 달린다
,

실전코드로 배우는 플러터 기본과 활용

Do it! 플러터 앱프로그래밍

오픈API활용, 파이어베이스, 구글맵까지 배울 수 있는 크로스 플랫폼. Flutter에 입문하기 위해 위 플러터 앱프로그래밍 책을 가지고 3주 이내로 공부하려고 합니다. 배우고 정리해서 최종적으로 간단하고 필요한 앱들이 3개 정도 만들 수 있는 수준까지 올라가는 것이 목표입니다. 코틀린이 발전하기 전, 안드로이드 스튜디오에서 Java로 만들때는 디자인이 너무 어려워서 포기도 했었는데, Flutter는 디자인 기반이라 개발자도 쉽게 괜찮은 수준으로 외관을 만들 수 있다고 해서 도전해 보려고 합니다. 

플러터 등장 배경

모바일OS는 안드로이드와 iOS가 대부분 점유하고 있습니다. 애플은 오브젝트-C에서 스위프트(Swift) 언어를를 추가 지원하고 있으며, 안드로이드는 자바에서 Kotlin을 밀고 있습니다.(오라클에서 Java 이용에 대한 라이선스 비용 이슈. 아직 Java기반의 앱들이 많아 Kotlin으로 모두 대체되는데는 시간이 상당 필요) 이런 각 모바일 운영체제에 맞는 언어로 개발한 앱을 네이티브 앱(native app)이라고 합니다.

최근 전세계 iOS와 안드로이드의 시장점유율. 출처 : statista

하지만, 두 운영체제의 언어로 개발하면 2source 1서비스라서 관리가 어려워, 웹앱이나 하이브리드앱이 등장하였습니다. 최근 Progressive 웹앱에서는 알림도 받을 수 있다고합니다. 하지만 이런 하이브리드 앱은 속도 측면에서 느리다는 단점이 있습니다. 

그래서 나왔던게 페이스북의 리액트, 구글의 플러터입니다.

구분 리액트 네이티브 플러터
개발주체 페이스북 구글
언어 자바스크립트 다트
성능 빠르지만, 네이티브 앱보단 느림 네이티브 앱에 근접한 속도
학습 곡선 높음(네이티브 앱 개발자 수준) 낮음(네이티브 앱 개발자 수준)
대표 앱 페이스북, 인스타그램, 핀터레스트, 토스 알리바바, 구글애드센스, 네이버 지식in
장점  웹 개발자의 접근성(코딩을 잘해야 함)
 많은 패키지 이용 가능
 다양한 위젯(디자인 구성이 편함)
 강력한  애니메이션 등
단점 • 기본 위젯이 부족해 커스텀해 사용
 안드로이드/iOS 네이티브 위젯을 이용하기에 OS 판올림에 따른 업데이트 필요
 블루투스 등 네이티브 커스텀해 통신하는 부분 개발이 어려움
 플로터 SDK로 앱 크기가 큼(네이티브 대비)
 업데이트 주기가 빠름(책, 인터넷의 예제에 deprecated(폐기) 된 항목들이 종종 있음)

개발해보면 아시겠지만, hot reload 기능으로 소스 수정하면 별도 빌드과정없이 바로 결과 화면(가상디바이스화면, 웹화면)에 바로 표시해 주어 개발 효율이 높고, 앱을 만들더라도 웹화면에서 개발 결과를 확인해도 됩니다.

개발 환경 구축

안드로이드 스튜디오를 설치한 후, 플러터 SDK를 설치합니다. (https://docs.flutter.dev/get-started/install

정상적으로 설치가 되었다면, CMD창에서 flutter 폴더로 가셔서 flutter doctor 명령어로 개발 환경을 점검할 수있습니다.

flutter 개발환경 점검을 위해 flutter doctor 실행 결과 화면

그리고 안드로이드 스튜디오로 "Create New Flutter Project"를 생성하면서, "Flutter" 플로그인도 설치합니다.

Dart 핵심 요약 
  • 다트 언어의 6가지 특징
  • 비동기 처리 방식
  • JSON 데이터 처리 방식
  • 스트림 통신(순서 보장)

다트언어의 6가지 특징

  1. main()함수로 시작
  2. 변수는 어디에서나 선언 및 사용 가능
  3. 자료형이 엄격하여 선언한 타입외 다른 유형의 값 입력 불가. 선언하고 나중에 타입을 정하려면 var를 이용하고, 동일 변수에 여러 자료형을 허용하려면 dynamic 타입으로 이용 가능
  4. 제네릭 타입 이용 개발 가능 List<int>, List<dynamic> 등
  5. public, protected 같은 키워드 없음. 다만, 외부로 노출하고 싶지 안핟면, 변수나 함수 앞에 언드스코어( _ )를 이용해 표시. _hiddenValue, _hideValue
  6. 삼항 연산자를 자주 사용 (예 : var visibility = isPublic ? 'public' : 'private';)

비동기 처리 방식

다트는 async와 await 키워드를 이용해서 비동기 처리를 구현합니다.

  1. 함수 이름 뒤, 본문이 시작하는 중괄호 { 앞에 async 키워드를 붙여 비동기를 선언
  2. 비동기 함수 안에 언제 끝날지 모르는 작업 앞에 await 키워드를 붙임
  3. 2번 작업을 마친 결과를 받기 위해 비동기 함수 이름 앞에 Future(값이 여러개면 Stream) 클래스를 지정
void main() {
    checkVersion();
    print('end process');
}

Future checkVersion() async {
    var version = await lookUpVersion();
    print(version);
}

int lookUpVersion() {
    return 12;
}

#실행결과#
end process
12

비동기 함수가 반환하는 값을 처리하면, then() 함수를 이용

void main() async {
	await getVersionName().then( (value) => {
    	print(value)
    });
    print('end process');
}

다트는 단일 스레드로 동작하는 프로그래밍 언어

void printTwo() async {
	Future.delayed(Duration(seconds: 1), () {
    	print('Future');
    });
    print('Two');
}

JSON 데이터 주고 받기

Convert라는 라이브러리를 활용하여 쉽게 이용 가능하며, jsonDecode 반대는 jsonEncode() 함수입니다. 

import 'dart:convert';

void main () {
    var jsonString = '''
    [
    	{"lotto" : 5},
        {"lotto" : 15},
     ]
     ''';
     
	var lottos = jsonDecode(jsonString);
    print (lottos is List); // true 출력
    var lottoOne = lottos[0];
    print(lottoOne is Map);  // true 출력
    print(lottoOne['lotto'] == 5); //true
}

스트림 통신하기 

데이터를 주고 받을 때 순서 보장이 필요하다면, 스트림(stream)을 이용합니다. return은 한번 반환하면 함수가 종료되지만, yield 키워드는 반환 후에도 계속 함수를 유지합니다.(계속 반환) 그리고 async* 명령어는 yield를 이용해서 지속적으로 데이터를 전달하겠다는 의미입니다. 

import 'dart:async';

Future<int> sumStream(Stream<int> stream) async {
    var sum = 0;
    await for (var value in stream) {
    	print ('sumSteam : $value');
        sum += value;
    }
    return sum;
}

Stream<int> countStream(int to) async* {
    for (int i = 1; i <= to ; i++) {
    	print('countStream : $i');
        yield i;
    }
}

main() async {
    var stream = countStream(10);
    var sum = await sumStream(stream);
    print(sum);
}

다음처럼 then() 함수를 이용할 수있습니다. 다만, 스트림은 소모하면 사라지므로, first, last, length 등 한번만 실행해야 할 경우 이용합니다. 동일 스트림에 first, last를 같이 사용한다면 오류가 발생할 수 있습니다. 

main() {
    var stream = Stream.fromIterable([1,2,3,4,5]);
    
    //첫번째 값 출력
    stream.first.then((value)=> print('first: $value'));
    //마지막 값 출력
    stream.last.then((value)=> print('last: $value'));
    //스트림 비었는지 출력
    stream.isEmpty.then((value)=> print('isEmpty: $value'));
    //스트림 길이 출력
    stream.length.then((value)=> print('length: $value'));
요약(플러터 시작, 다트를 알면..)
• Flutter는 iOS, 안드로이드용 앱을 한번에 개발할 수 있는 개발 플랫폼
• Dart의 특징
 - proteced처럼 하려면 변수와 함수명 앞에 언드스코어( _ ) 추가
 - async-await-Future를 이용한 비동기 지원
 - 통신 과정에서 순서보장이 필요하면, async*-yield를 이용한 stream(스트림)  

 

Posted by 목표를 가지고 달린다
,

Django MVC 프로젝트가 Micro-frontend React 프로젝트로 탈바꿈하는 과정

Django MVC 프로젝트를 MSA 로 가는 과정

 

거대 프로젝트 구성도

* 인프라 패키지 : 동일한 빌드 툴링을 공유
* 라이브러리 패키지 : 공통 소스코드를 관리
* 서비스 패키지 : 페이지에서 독립적으로 작동

위의 방식을 통해, 소스와 빌드 설정을 완벽히 격리시키고, 서비스별 의존성 문제를 해결하여 빌드업 시간, 소스 동기화 시간을 해결할 수 있습니다. 

Monolithic에서 MSA전환 사례?

MSA(MicroService Architecture)는 Netflix에서 도입되어 IT에서 많이 화자가 되고 있습니다. 다양한 서비스들이 서로 의존성에 대한 걱정없이 배포하고 운영되는 것에 많은 흥미를 가졌습니다.

하지만, 이미 대규모의 웹, 앱을 안정적으로 운영하는 기업 입장에서 100에 +1, +2를 더하는 것은 쉬우나, 이것을 다시 1+1+1+1...(100번) 하여 재구축하는 것은 전면 재구축이라, 단순 MSA로 전환에 따른 이점이 크지 않아 도입하는게 좋은 선택이 아닐 수 있습니다. 또한, MSA에 대한 충분한 이해없이, 서비스간 의존성을 최소화하면서, 빌드, 분산 배포 계획까지 마련한 사례가 없어 참고자료가 마땅치 않습니다. 

MSA의 대표 사례인 Netflix경우, 서비스가 다양하지 않고, 일부 오류(제안, 검색 화면 등)가 나더라도 크리티컬하지 않지만, 금융거래 또는 개인정보 처리 및 전자서명하는 거래의 경우에는 거래의 무결성을 보장해야 하기에 오히려 부적합할 수도 있습니다. 

토스는 다른 전략을 갖고 개발되는 제품(서비스)들이 다르게 개발될 수 있는 문화가 이미 정착되어 있고, 그런 환경이기에 MSA가 적합해 보입니다. 그래서 제품 전략적으로 독립된 제품들이 기술적으로도 독립할 수 있는 것입니다. 따라, 각자 다른 엔지니어와의 커뮤니케이션을 최소화하여 개발에 집중할 수 있지만, 다른 측면으로는 추후 업무 이관 등 관리적면에서는 또다른 문제가 있을 수 있습니다. 기존 Monolithic 방식의 장점이 이런 관리 운영적인 측면에서 체계적이었기 때문입니다. 

빌드 시간 최소화

전체 소스빌드가 아닌 incremental build를 이용하여 변경된 소스만 빌드하고, 기존 소스는 빌드하지 않고, 그대로 이용하면 됩니다. Eclipse 기반에서는 build는 auto를 설정하면, 기본적으로 지금 수정된 파일만 incremental build를 수행하고, "clean"을 명령해야 전체 소스를 build합니다. 또한, 상용/무료 형상관리 프로그램 역시 두가지 버전(clean, incremental)을 모두 지원하고 있습니다. 

우리가 사용하는 서버의 Java 버전이 변경되는 경우는 매우 드믑니다. 없다고 생각하셔도 좋습니다.

  • 전체 소스코드를 rebuild해야 하며, 그과정에서 일부 소스 수정이 필요할 수도 있습니다. 따라 전체 메뉴에 대한 기능 테스트를 수행
  • 이용하고 있는 암호화 솔루션, 프린트 솔루션 등 자바 버전이 충돌되어 오작동하는 솔루션이 있는지 미리 체크
  • Java 버전 변경의 장점이 매우 적어 버전업을 하지 않지만, 너무 오래된 버전(1.3 등)의 경우에는 신기술 도입을 위해 전면 재개발을 할 때, 신규 서버에 Java 버전을 최신의 안정화 버전으로 Up

Java 버전이 변경되는 경우가 아니라면, 굳이 전체 소스를 build, 배포할 필요가 없으며, 배포할 필요가 없는 소스를 굳이 build할 필요 역시 없습니다. 

제로빌드 정책에 따른 소요시간. 불필요한 빌드 과정 단축

요약
• 수평적인 애자일 조직(각자 다른 서비스앱을 개발하는 것이 아니라, 여러팀이 각자 서비스를 단일 앱에 올리는 경우)에 MSA는 좋은 선택
• 변경한 소스만 build : Zero-Build
Posted by 목표를 가지고 달린다
,

DB 이중화, DR센터를 구축해야 하나요?

  • 금융회사라면 전자금융감독규정을 확인해보세요.
  • 인터넷 쇼핑몰이라면 4시간 장애로 인한 판매 중단시 발생하는 손실 금액을 확인해보세요.
  • 대기업이라면 회사 홈페이지 마비에 따른 업무 중단 또는 회사 이미지를 생각해보세요.

재해복구센터(DR) 구성도

시스템 HA구성을 얘기할 때, 3tier 구조(WEB Server - Application Server - DBMS 의 구성) 부터 시작합니다. 추가로 L3 또는 L4 같은 네트워크 장비와 WEB 방화벽 등 정보보호 시스템을 붙여 나갑니다. HA 구성은 이중화를 통해 로드 밸런싱외에도 장애 발생시 Fail-Over 기능을 수행합니다. 서버 장비가 2대 이상 구성함에 따라 많은 비용이 발생합니다. 물론 처음부터 100의 능력을 가진 서버가 아닌 50~70의 서버를 2대 이상 구성하는 것이 비용 측면에서는 좋을 선택일 수 있습니다. 

비용   VS  시스템 구성 복잡도, 장애 포인트 증가

DBMS(DataBase Management System)은 보통 유료버전의 경우 RAC, TAC 처럼 단일 Datafile을 이용하는 여러 instance를 이용하는 방법외에도 Master-Slave 방식의 방법도 제공하고 있습니다. 대부분의 웹서비스는 조회와 데이터처리(등록/정정/삭제) 거래량을 비교하면, 조회가 10배 이상이라 생각됩니다. 주식거래를 하다보면, 우리 자산을 하루에도 10번 이상 체크하지만 거래는 자주 하지 않는 것과 같습니다. 

그래서 데이터를 처리하는 Master가 있고, Master의 변동분을 읽어 동기화하는 N개의 Slave가 있습니다.그래서 이렇게 설계해야 데이터 동기화가 꼬이지 않고 Simple해지기 때문입니다. 동기화하는 전문 솔루션을 이용하거나 OS레벨에서 동기화 지원하는 Disk 제품도 있습니다. 이런 구성은 최소 비용으로 데이터의 성능을 올려 HA를 올리는 방법이고, 여기에 Active-Stanby 구성을 추가합니다. 그러면 Active 서버 장애 발생시 모니터링 서버가 인지하여, 자동(수동)으로 동기화된  Stanby서버로 거래가 들어오면서 서비스를 유지할 수 있습니다. 

재해복구센터(DR) 구성도

여기까지가 주센터에서 할 수있는 HA입니다. 

만약 주센터에서 해결할 수 없다고 판단된다면, DR 전환을 수행해야 합니다. 사실상 금융권은 전자금융감독규정에 따라 주기적으로 DR 전환훈련(재해복구 전환훈련) 을 수행하고 있습니다. 그래서 데이터 동기화도 실시간으로 진행되고 있습니다. 물론 이런 경우 추가로 고려해야 할 사항이 있습니다.

  • RTO(Recovery Time Objective, 목표 복구 시간) : 업무 중단 시점으로부터 복구되어 가동될 때까지의 소요시간, 장애 발생 후 4시간 이내 복구 가능
  • RPO(Recovery Point Objective, 목표 복구 시점) : 비상사태 또는 업무 중단 시점으로부터 데이터를 복구할 수 있는 기준점, 장애 발생 전인 지난 주 목요일에 백업시켜 둔 복원 시점으로 복구 가능 등

금융권외에 다른 권역에서는 백업을 주단위 또는 월단위로 할 수 있기에 복구 시점을 정확히 인지하고, 복구 이후 이후 변경에 대해 대책을 세워야 합니다. 또한, DR 전환이 성공할지라도 DR-주센터가 전환된게 아니기에 다시 안전하게 주센터로 전화해야 한다는 걸 고려해야 합니다. 따라, DR전환은 정말 주센터가 상당 기간 동안 정상화될 수 없다고 판단이 되면 시행해야 합니다. 

센터 장애시나리오 1, Master서버 다운
센터 장애시나리오 2, Fail-over 불가
DR 전환 시나리오

DB를 빨리 복구하는 방법

동기화하는 DR센터가 없는 상태에서 DB datafile이 깨진 경우를 대비하여, 거래량이 적어 Datafile의 변경이 적은 매일 새벽마다 Datafile을 복제하는 방법이 있습니다. 오늘이 6월 27일이면, 복제DB는 6월 27일 02시 기준의 자료입니다. 오늘이 6월 28일이면, 복제DB는 6월 28일 02시 기준의 자료가 됩니다. 복제DB는 관리 목적이 당일 02시 기준의 상태로 복구하는 것입니다. 따라 Full Copy할 테이블과 append하여 전일 변경분만 Copy할 테이블을 정리하여 복제하면 됩니다. DBMS에 따라 Datafile을 복제해도 가능합니다. 

물론, 데이터 복구 이후, 복구시점 이후 거래나 변동에 대해 조치를 취해야 합니다. Log파일이나, 다른 매체에 기록된 정보를 활용해서 재거래(Re-transaction)를 할 수 있는 프로그램(솔루션)을 개발해야 합니다. 재거래는 속도가 생명이지만(복구시간), 거래순서가 중요할 경우 적절히 거래를 Divide하여 병렬처리하면 됩니다. 

주기적인 당일 백업

요약
• 장애 발생에 대한 피해 정도, 법적 의무를 확인하여 비용내에 적절하게 HA 구성
• RTO가 길다면, 월1회에 직접 Datafile을 복제하여 별도 장소에 보관(복구 훈련 필요)
• DR전환은 성공하더라도 주센터로 전환까지 해야 하므로, 주센터 내에서 최대한 복구 대책 마련

https://www.youtube.com/watch?v=t96l6ry_qmw 

 

Posted by 목표를 가지고 달린다
,

성장하는 스타트업은 완벽 보다는 필요한 것부터 차근차근

통계전문가, 빅데이터 전문가의 역할은 무엇일까요? 비즈니스 전문가, IT기획자 또는 개발자가 데이터 항목간의 연관성, 의사결정을 위한 통계, 판매 실적 추이, 특이점 등을 찾아낼 수 있도록 DW 환경을 구축하는 것입니다. 그렇게 하기 위해서 실거래 DB부터, 디멘젼 테이블, ODS, 메타관리, 데이터품질관리 마지막으로 효율적인 협업 시스템을 구축해야 합니다. 

스타트업으로 시작한 토스는 Simplicity21에서 나온 "오직 한사람, 사장님을 위해" 같은 다양한 통계를 활용한 서비스를 기획할 수 있는 큰 규모 DW를 구축할 수 있었습니다. 그들은 6개의 원칙을 갖고 성장할 수 있었습니다. 

DW업무를 처음 접하시는 분들은 토스의 과정을 보시면서, 막연한 DW에 대해 감을 잡으시기 바랍니다. 

DB Review

IT직원이 30명이 넘는 규모의 회사에서도 별도의 DBA를 두지 않고, 개발자가 임의로 테이블을 추가, 수정하면서 데이터의 중복, 비효율적인 Index생성/누락 이 빈번한 회사가 많습니다. 토스는 DBA가 컴플라이언스(개인정보, 암호화, 권한 관리 등)와 데이터 모델, 성능과 안정, 운영 효율성 관점에서 리뷰를 진행하고, 안전하고 효율적인 방법으로 DB 변경 작업을 수행합니다. 운영DB의 품질(중복 최소화, 적절한 Index, 용어 통일, Null값 관리, FK, comment 설 등)이 낮으면, DW의 품질 또한 높을 수 없습니다. 또한 용어 통일이 되지 않으면 커뮤니케이션 오류, 데이터 중복관리 등 불필요한 업무가 계속 발생합니다. 

디멘젼 테이블

차원에 대한 테이블(일별, 월별, 코드별 등 집계 기준)은 자동화를 위한 선제 조건입니다. 주요 행위나 서비스에 대한 정의(d_act_type, d_svc), 각종 수수료 및 매출 계약정보 등을 분류 기준을 만들어 집계시 하드코딩하지 않고 디멘젼 테이블로 관리해야 일관성을 유지할 수 있습니다. 코드명별로 Min, Max값에 따라 코드값으로 값을 적절히 분류하면, ODS 테이블에 적재시 동일한 기준으로 Summary 테이블 생성 가능합니다.

영문코드명 한글코드명 코드 코드값 Min값 Max값
CUST_TP_CD 고객유형코드 CU_GOLD "골드"등급 고객 50,001 10,000,000
CUST_TP_CD 고객유형코드 CU_BRONZ "브론즈" 등급 고객 0 50,000
USAGE_OF_
FREQUENCY
이용빈도 UOF_1000 1,000번 이용 0 1,000

토스는 구글스프레드시트로 Python으로 MySQL 같은 RDB 데이터를 동기화하는 프로그램을 만들어 사용.

* 중견기업 이상, 금융권에서는 DW를 구축하면서 ETL(Extract Transform Load) 프로그램을 통해 설정된 Mapping rule대로 적재하며, 네티짜의 경우 SQL문으로 메모리에서 DB to DB 데이터를 적재(매우 효율적임)

ODS 설계 및 운영

ODS(Operational Data Store)란 집계효율을 위 중간 가동단계의 데이터들의 저장소입니다. 운영시스템의 복잡한 형태를 단순화하거나 표준에 맞지 않는 부분을 전처리 과정(Null값 통일)을 통해 맞추기도 합니다. 또한, 필요에 따라 Summary 테이블로 구성할 수도 있습니다. 

* AARRR : 데이터를 보는 하나의 방법론으로 이용자의 유입에서 매출로 연결되기까지 단계별로 분석하는 방법

이런 공통된 지표들을 윗 단계(Dimension 테이블)에서 정의하여 관리합니다. 그래야 모든 팀에서 공통으로 활용할 수 있습니다. 

행위(공통된 지표)에 대해 정의하였기에 단순한 SQL으로도 다양한 행동들에 대한 상관관계를 쉽게 파악할 수 있습니다. 

이런 모든 일련의 과정을 Sql 스크립트를 작성해서 돌릴 수도 있지만, 토스는 AirFlow를 사용하고 있습니다. 이미 정보계를 구축한 회사에서는 이미 자체적으로 개별 스크립트를 모듈로 작성해서 Diagram을 만들어 운영 중일 것입니다. 

효율적인 협업을 위한 도구

Jenkins를 이용하면 사용방법이 쉬워 비개발자들도 쉽게 배치를 등록할 수 있었으나, 관리가 어려워 체계적인 관리를 할 수 있는 체계를 마련할 필요가 있습니다. 간단하거나 지엽적인 것은 비개발자들에게 허용할 수 있지만, 영향도가 높은 경우에는 IT부와 협의를 통한 관리가 필요합니다. 

통계 프로그램(SQL) 역시 형상관리가 필요하며, 문제 발생시 담당자를 확인할 수 있게 명시하고, 작업이력도 관리할 수 있어야 합니다. 또한 작업 상세 설명을 검색할 수 있어야 중복 작업을 없앨 수 있습니다.

메타정보 관리

테이블명, 컬럼마다 comment를 등록해야 합니다. (우선 용어 정리를 먼저 해야겠군요.) 항목에 대한 의존성을 체크할 수 있는 기능이 있으면 좋겠지만, 필드에서는 의존성 검색하는 경우가 매우 드문 것 대비, DB 항목별 의존성(이용 메뉴)를 찾고 관리하는 비용이 매우 높아 주요 필드 위주만 관리하는 것도 방법입니다. 

과거에는 ERD를 그리고 PK와 FK를 연결하는 매우 고가의 솔루션들을 많이 도입했었지만, 실제 변경이 적어 관리에 소홀하다보니, 최신화가 되지 않는 현장들이 많습니다. 또한, FK를 설계할지라도 운영상 오류 방지를 위해 FK를 설정하지 않아, ERD의 그림과 DB의 스키마의 설정이 달랐습니다. 따라, ERD를 통하지 않아 직접 DB를 정의하다보니 차츰 ERD를 관리하지 않아 요즘에는 거의 유명무실해졌습니다. 

오히려 엑셀에 표로 테이블 구조를 관리하는 것이 적합할 수 있습니다.

데이터 품질

DW환경이 어느정도 안정화되면, DQ(데이터 품질, Data Quality)를 고려해야 합니다. 데이터 완결성, 유일성, 유효성 등은 메타 데이터를 가지고 검증할 수 있으며, 시의적절성, 정확성, 일관성 등은 검증 로직을 활용하여 체크해야 합니다. 그외 데이터 분포, 이상거래 탐지 등이 있습니다. 

실시간 검증이 필요한 영역이 있고, ETL, DW 처럼 일, 주, 월 배치로 작업을 해야 하는 것도 있습니다. 최근에는 LOG, 변동분 기록을 새벽에 전날 기록을 옮기지 않고(일배치), 실시간으로 DW에 기록할 수 있도록 구성하는 회사도 있습니다. 이것은 이동시간(거래량에 따라 1~2시간 소요)를 최소화하고, 실시간으로 검증 로직을 활용하기 위해서입니다.

요약
• Risk의 크기를 고려하여 통제는 꼭 필요한 곳에만 적용, 기본적으로는 빠른 탐지와 대응 중심.
• 전사차원의 효율성을 고려하여 자동화, 체계화 진행 시기 결정
• 관리시스템 개발시 처음부터 완벽한 시스템을 만들려고 하지 않는다.
Posted by 목표를 가지고 달린다
,

미국 고배당주 페트로브라스 우선주(ADR)

브라질 국영 투자 페트로브라스(Petrobras)

브라질에 국영 투자 페트로브라스(Petrobras)는 석유 및 천연 가스 생산, 수송, 판매 등 에너지 산업 분야에서 세계적인 선두주자 중 하나입니다. 특히 브라질을 대표하는 회사로 1973년 국영화되었습니다. 국내외에서 폭넓은 사업 영역과 강력한 경쟁력을 보유하고 있습니다. 그러나 최근 들어 전 세계적으로 에너지 산업의 구조 변화와 함께, 페트로브라스도 새로운 시장 환경에 대처하기 위한 전략적인 변화를 시도하고 있습니다.
 페트로브라스는 1953년에 국영 석유 회사인 "Petrobrás"가 창립되어 브라질의 석유 개발에 착수했습니다. 이후로 페트로브라스는 국내 외에서 다양한 비즈니스를 확장하면서 1979년에는 자국 정유공장에서 최초로 유도산물을 생산했으며, 2006년에는 브라질의 가스산업 부문에 진출하였습니다.
사업부문은 크게 3개로 분류됩니다. 먼저, Exploration and Production (탐사 및 생산, 이하 E&P)는 원유, 천연가솔린(NGL) 및 천연가스의 탐사, 개발 및 생산 등 이른바 업스트림(up-stream) 단계를 담당하고 있습니다. 최근 12개월 기준 매출 비중은 39%인데, 전사 EBITDA의 86%를 창출한 캐시카우 사업부입니다. 이어서, Refining, Transportation and Marketing (이하 Refining) 사업부에서는 미드/다운 스트림 (Mid/down-stream) 단계에 해당하는 원유 및 석유제품들의 정제, 수송 및 판매를 수행하며, 전사 매출과 EBITDA의 각각 52%, 11%를 창출합니다. 마지막으로 Gas and Power(이하 G&P)는 천연가스의 유통 및 무역과 석유/가스 외 에너지 자원 관련 사업을 영위하는 부문입니다.
 동사는 브라질을 중심으로 석유/가스 제품을 생산 및 판매합니다. 3Q20 기준 동사의 석유/가스 생산량은 29.5만 BOE(석유환산배럴) 중 98%가 브라질 유전에서 비롯됩니다. 특히 브라질 유전 특성 상 동사는 심해 그 중에서도 암염하층(presalt)에서 석유/NGL을 생산하는 데 특화되어 있습니다. 실제, 동사 전체 일간 생산량 중 56%를 브라질 암염하층에서의 석유/NGL 생산이 담당하고 있는 것으로 나타납니다. 3Q20 전체 동사 석유/가스 제품 판매량 중 브라질이 68%를 차지하고 있습니다. 해외 판매는 원유와 기타 석유제품의 경우 각각 중국과 싱가폴 수출을 중심으로 미국, 스페인, 칠레, 포르투갈 등으로 수출국을 다변화하는 중입니다. 전 세계 복합 석유/가스(Integrated Oil & GAS) 기업들과 비교해도 동사는 중상위권 이상의 생산량과 매장량을 보유하고 있습니다. 동사 일간 석유/가스 생산량은 세계 6위이며, 특히 일간 석유 생산량에서는 최근 PetroChina를 제치고 2위로 올라섰습니다. 또, 매장량으로 보더라도 동사는 각각 4위, 9위를 기록 중입니다(2019년 기준).

정부가 주요지분 36.6% 보유

28.7%를 보유하고, 정부 소유의 개발은행 등을 통해 7.9%를 추가하면 총 36.6%의 지분을 직/간접적으로 보유하고 있는 반국영 반국민 기업입니다. 따라 정부의 경영 간섭이 심해 필요에 따라 CEO를 교체하기도 합니다. 만약 국제 원유 가격이 치솟더라도 국내 연료비를 손해 보면서라도 어느정도 유지하여 자국민을 위한 보조금으로 사용하기 도합니다. 집권 정부에 따라 이런 주주 가치에 반하는 행동 때문에 저평가 받기도 합니다.

매우 주주친화적인 주주보수 정책(배당 정책)

사실 국영화하였지만, 배당 정책이 매우 주주친화적입니다.  홈페이지에 게시된 배당금 정책 SHAREHOLDER REMUNERATION POLICY (DIVIDEND POLICY) 를 살펴보면,

브렌트유 평균 가격이 40달러/배럴 이상인 회계연도에 대해 최소 40억 달러의 연간 보상을 책정한다. 

2018년부터 23년 6월까지 40달러 이하로 내려간 적은 딱 3달(2020년 3, 4, 5월) 있습니다. 23년 6월 가격이 $75이니, 안정권이라 정말 코로나19가 다시 터지지 않는 이상 올해도 40억 달러 배당이 기대됩니다. 게다가 조건에 부채수준에 관계없이 배분하게 되어 있어서 배당이 확실합니다. 그래서 재무제표를 보시면, 이익이 계속 나지만 부채가 줄어들지 않습니다. 

총 부채가 미화 650억 달러 이하라면, 회사는 차액(영업 활동으로 창출한 순 현금 - 회사의 자산, 플랜트, 장비 및 무형자산에 대한 투)의 60%를 주주에게 분배해야 합니다. 

첨부자료는 회사 홈페이지에 게시된 배당정책입니다.

Dividend Policy.pdf
0.25MB

2015, 2016년에 브라질에서는 무슨 일이 있었기에 배당금이 없었나?

주가 추이 및 배당비율 통계.

2013년 중반에서 2017년까지 계속된 브라질의 경제 위기였습니다. 지우마 호세프 대통령의 탄핵으로 이어진 정치적 위기와 같이 일어났습니다. 2015년 GDP는 급여 수준의 하락, 신용의 제약, 기준금리의 상승으로 인해 3.9%까지 떨어졌습니다. 2016년 모든 부문에서 침체되면서 GDP는 3.6%까지 떨어졌습니다. GDP가 2년 연속 하락한 것은 1931년 이후 처음이었습니다.
룰라 2기 행정부(2010.12.31.까지, 그리고 3기, 2023.01.01~ ) 실절 높은 금리와 10%대의 인플레이션을 기록하고 있던 브라질의 룰라 이후 지우마 호세프 대통령의 강력한 시장개입, 무리한 금리인한, 공공지출을 줄이기 위한 보조금 삭감 등 일련의 조치가 곧 재정적인 위기를 초래하게 되었습니다. 
(2011년 신경제 매트릭스(포르투갈어|Nova matriz econômica)의 실패) 
2015년 실업률은 평균 8.5%였고, 15년 한해에만 150만개의 일자리가 상실했으며, 이는 공공 기관과 노동자당, 그리고 대중의 불만이 켜져 결국 탄핵과 동시에 미첼 테메르의 집권 이후, 다양한 프로젝트들이 경제를 회복시키기 위해 제안되었습니다. 
2017년 초, 경제 회복을 암시하는 신호가 존재하지만 대다수는 회복 과정이 길고 느릴 것이라 예상하고 있습니다. 

브라질 경제 위기시절 GDP 성장률(하락세)

코로나 19 이후 부채축소에 따른 배당 확대

페트로브라스 부채 흐름과 최근 현황(개선 중)

코로나19 극복과 더블어 부채 축소와 배당정책의 변화로 재평가가 기대됩니다. 총부채가 600억달러 미만일 때, FCF의 60%를 배당금으로 지급할 수 있다는 주주배당규정 항목을 추가하였으며, 경영진은 21~25년 동안 총 300~350억 달러를 배당금으로 지급할 계획이라고 밝혔습니다. 특히, 총부채가 600억달러 이상이라도 최근 12개월 간 순부채가 축소됐다면 순부채 축소 규모 내에서 배당금을 지급할 수 있는 규정도 이사회 승인을 획득했습니다. 

브라질 경제 위기

2023년 1월 룰라 3기 정부는 코로나19 팬데믹, 우크라이나 사태 등으로 침체된 글로벌 경제 상황 속에서 고물가, 고금리, 고환율로 어려워진 브라질 경제 성장을 위한 해법을 찾아야 하는 중요한 임무를 띠고 출발했습니다. 경제 전문가들은 중앙은행이 현재 기준금리(SELIC) 13.75%를 최소한 올해 하반기까지 유지할 것으로 전망합니다. 이에 따라 브라질 경제는 2023년 한 해 동안 높은 금리에서 벗어나지 못할 것으로 예상됩니다. 높은 금리는 정부가 안고 있는 수십억 달러 상당의 부채 이자 부담을 증가시키는 것 외에도 기업들의 신용 대출을 더 어렵게 만들고 소비와 생산 설비 투자를 감소시키게 될 것입니다. 
최근 브라질 채권 연 12% 상품들이 있습니다. 국내 판매되는 채권 금리가 4~6%인데, 왜 브라질 채권에 투자를 꺼려하는 걸까요? 왜 증권, 은행분들이 투자권유를 하지 않는 걸까요? 2011년 과거 브라질 경제 위기에서 투자금 대비 높은 수익이 났습니다. 국내 2~3% 금리가 아니라 10%대였기 때문에 안정적인 수익이 날 것이라 생각했습니다. 게다가 브라질과 우리나라간 조세협력을 맺어 브라질 국채는 비과세였습니다. 

10%대의 높은 브라질 채권 금리

하지만, 문제는 환율이었습니다. 600원하던 헤일화가 지금은 273원입니다. 결국 600만원으로 1만 헤일화를 구매해서 1.5만 헤일화가 되었는데, 이걸 환전하니 400만원이 된 것입니다. 그래서 외국 투자는 환율 리스크도 고려를 해야 합니다. 

브라질 헤일화의 가치가 어떻게 될지 알 수 없음.

요약
• 요즘 친환경 정책과 전기차 보급 확대 전망 등 중장기적으로 유가 흐름에 부정적이지만, 친환경 인프라 구축에 필
요한 기간 상당히 소요되는 바, 단기에 유가가 급락하기는 어려워 보임
• 작년 기준으로 배당금 $6 은 지금 주가 $13 대비 아직 매우 높은 수준이지만 다른 유가 종목처럼 작년이 유독 많이 배당을 받는 것이 코로나19에 못받은 것에 대핸 보복적 배당정책이라면, 향후에도 지속적으로 배당이 될지? 아니면 올 상반기 주가 상승분을 반납하고 주가 하락을 기다려야 할지는 관망 필요
• 아직, 브라질 경제가 안정적이지 않기에 환율 리스크로 과도한 투자는 신중한 접근 필요

 

Posted by 목표를 가지고 달린다
,

BP 프루드 베이 로열티(BPT) 고배당 종목, 배당이익만 67%라는데,

회사 개요

BP 프루드 베이 로열티 신탁(이하 '신탁')은 1989년 2월 28일에 체결된 신탁 계약(이하 '신탁 계약')에 따라 The Standard Oil Company(이하 '스탠다드 오일'), BP Exploration (Alaska) Inc.(이하 'BP 알래스카')(현재 힐코프 노스 슬로프, LLC(HNS)로 알려짐), 수탁자인 뉴욕 멜론 은행, 공동 수탁자인 델라웨어 BNY 멜론 신탁(뉴욕 은행의 후계자) 간에 체결된 델라웨어 사업 신탁으로 만들어졌습니다.
2010년 12월 15일, 뉴욕 멜론 은행은 수탁자에서 사임하고 전국 은행 협회인 뉴욕 멜론 신탁 회사(뉴욕 멜론 은행)가 후임 수탁자(이하 '수탁자')로 교체되었습니다. 1989년 2월 28일, 스탠다드 오일은 신탁에 우선적 로열티 이익(이하 로열티 이익)을 양도했습니다. 이 신탁은 로열티 지분을 소유하고 관리하기 위한 목적으로만 설립되었습니다. 따라, 매출액의 대부분(약99%)을 배당금으로 돌려줍니다.
로열티 이익은 (a) 알래스카 노스 슬로프에 위치한 프루드호 베이 유전(1989년 2월 28일 기준)에서 분기당 석유 및 콘덴세이트의 실제 일일 평균 순생산량 중 최초 90,000배럴 또는 (b) HNS의 작업 지분(1989년 작업 지분)에서 분기당 실제 일일 평균 순생산량 중 적은 금액에 대해 16.4246%의 배럴당 로열티(이하 배럴당 로열티)를 받을 권리를 나타냅니다. 신탁 단위 보유자는 생산이 중단 또는 중단되거나 어느 분기에서든 하루 평균 90,000배럴 미만으로 떨어질 위험에 노출됩니다. BP는 로열티 이자와 관련하여 BP 알래스카의 지불 의무 이행을 보증했으며, 이러한 보증은 HNS의 지불 의무 이행과 관련하여 여전히 유효합니다. 2000년 1월 1일부로 BP 알래스카와 다른 모든 프루드호 베이 작업지분 소유자들은 프루드호 베이 광구에 대한 지분을 프루드호 베이 단위 조정 계약에 따라 교차 할당하였다. BP 알래스카는 신탁과 관련된 모든 권리, 의무 및 부채를 보유합니다. 이 신탁의 수탁자는 뉴욕 멜론 은행 신탁 회사(Bank of New York Mellon Trust Company, N.A.)와 델라웨어 은행 법인인 델라웨어 BNY 멜론 신탁(BNY Mellon Trust of Delaware)입니다. 델라웨어 법정 신탁법의 특정 요건을 충족하기 위해 델라웨어의 BNY 멜론 신탁이 공동 수탁자 역할을 합니다. 신탁 계약에서 수탁자에게 부여된 권리와 권한은 뱅크 오브 뉴욕 멜론 신탁 회사, N.A.만이 행사할 수 있습니다. 어떤 날에 적용되는 배럴당 로열티는 해당 날의 서부 텍사스산 중질유(WTI 가격) 가격에서 예정된 청구 비용(인플레이션에 맞게 조정)과 생산세(당시의 법정 세율 기준)를 차감한 금액과 같습니다. 손익분기점 가격은 우선 로열티 전달 약관에 따라 분기 마감 후 계산됩니다. 손익분기점 WTI 가격은 주로 지난 2월, 5월, 8월 또는 11월에 발표된 가장 최근의 소비자물가지수 및 생산세를 기반으로 하는 비용 조정 계수의 변화로 인해 시간이 지남에 따라 변경되며, 청구 가능한 비용은 해당 연도 동안 일정하게 유지되기 때문입니다. 또한 WTI 가격이 변동함에 따라 생산세 및 규정된 공제액도 변동하여 손익분기점 WTI 가격이 증가하거나 감소할 수 있습니다. 실제 손익분기 가격은 HNS에서 계산하여 제공합니다.

* 배럴당 평균 로얄티(일9만 배럴 생산) =
평균 WTI 가격
- ( 평균 조정 청구 가능 비용 + 평균 생산세)

이 신탁은 (i) 발행된 신탁 단위의 60% 이상의 신탁 단위 보유자의 투표에 따라 또는 (ii) 2년 연속 로열티 이자로 인한 순 수익이 연간 $1,000,000 미만인 경우(해당 기간 동안 순 수익이 특정 사건으로 인해 실질적이고 불리한 영향을 받지 않는 한) 해지됩니다.

알래스카 석유 및 가스 생산세

2013년 4월 14일, 알래스카 주의회는 알래스카 석유 생산 및 석유 산업에 대한 투자를 장려하기 위해 알래스카 석유 및 가스 생산세 법령인 AS 43.55.10 이하(이하 생산세 법령)를 개정하는 유류세 개혁 법안을 통과시켰습니다. 2013년 5월 21일, 알래스카 주지사는 이 법안을 2013년 알래스카 임시회 법률(이하 '법')의 제10장으로 법제화했습니다. 이 법은 2006년과 2007년에 생산세 법령의 일부 개정으로 시행된 월별 누진세율을 폐지하고, 기본 세율을 25%에서 35%로 인상했으며, 석유 생산에 대한 배럴당 단계별 세금 공제를 추가하는 등 주요 변경 사항을 담고 있습니다. 이 세금 공제는 과세 대상 석유 배럴당 생산 시점의 총 가치를 기준으로 하며, 생산세 법령에 따른 최소 세금(해당 연도 미국 서해안에서 판매되는 알래스카 북사면 원유의 배럴당 평균 가격을 기준으로 해당 연도 생산자 과세 대상 생산물의 생산 시점 총 가치의 0~4% 범위의 비율) 이하로 생산자 세금 부채를 감소시킬 수 없습니다. 이러한 변경 사항은 2014년 1월 1일에 발효되었습니다.

최근 개발

2023년 3월 31일에 마감된 분기의 일일 평균 WTI 종가가 손익분기점 가격보다 낮았기 때문에 해당 분기의 지급금 계산에 마이너스 값이 발생했습니다. 2022년 12월 31일에 종료된 분기에 신탁에 13,279달러의 초과 지급이 있었습니다. 그러나 신탁 계약에 명시된 바와 같이 모든 분기의 로열티 이자와 관련된 지불액은 0보다 작을 수 없습니다. 수탁자는 2023년 3월 31일까지 이 신탁에서 발생한 모든 비용(총 587,115달러)을 현금 준비금에서 지불했습니다. 수탁자는 현금 준비금의 적정성을 계속 평가하고 있으며 향후 현금 준비금을 늘릴 수 있습니다. 항목 1의 재무제표(감사 받지 않음)에 대한 주석 2를 참조하세요. 2023년 3월 31일로 끝나는 3개월 동안, 배럴당 로열티는 다음 정보를 바탕으로 계산되었습니다. 이 신탁은 WTI 가격 하락, 평균 조정 청구 비용의 증가 및 생산세 납부의 결과로 2023년 1분기에 귀속되는 로열티 지급을 받지 못했습니다. 신탁은 2년 연속 로열티 이자로 인한 순 수익이 연간 100만 달러 미만인 경우 종료됩니다(2년 동안의 순 수익이 불가항력적인 사건으로 인해 실질적이고 불리한 영향을 받지 않은 경우 제외).

평균 WTI 가격 $76.17
평균 조정 청구 가능 비용 $80.50
평균 생산세 $ 2.67
배럴당 평균 로얄티 $(7.00)
평균 순 생산량(mb/d) 70.3

공식) 평균 WTI 가격 - ( 평균 조정 청구 가능 비용 + 평균 생산세) = 배럴당 평균 로얄티(일9만 배럴 생산)
* 76.17 - ( 80.50 + 2.67 ) = (7.00) , -7.00$는 음수이므로 0$, 로열티 없음

'22년 최고 배당률 67.3% (주당 $3.77 지급)

22년에 4번(1월, 4월, 7월, 11월)에 걸쳐 많은 배당이 있었으나, 실제 현재 주가대비 67.3%이며(토스앱에서는 배당률을 "배당금액 / 현재 주식가격" 으로 계산하기 때문에 가격이 많이 떨어진 지금에서는 매우 높게 표시되고 있습니다. 주의 하세요.)
20, 21년은 WTI가 매우 낮은 저유가 시대여서 배당금이 1달러 미만으로 매우 저조하고, 특히 21년 3분기에는 기존 현금 보유액 127만달러를 600만 달러로 늘리기로 결정하면서 3분기 귀속되는 로열티 지불금에서 전액 조달하여, 배당 수익이 거의 없었습니다. 아래의 표를 보시면 WTI와 배당률은 비슷합니다. 따라, 지금 원유(WTI)의 가격이 $75 정도에서 벗어나 $90까지 오른다면 상당한 배당 수익 및 차익실현도 노려볼 수 있으나, 원유 가격이 유지되거나 떨어진다면, 오히려 20, 21년 처럼 $1.5~$3 까지 내려가는 걸 기다려야 하지 않나 싶습니다. 

요약 
• 원유(특히, WTI)의 가격에 영향을 많이 받고 있어 원유 상승을 기대한다면 투자 고려
• 20, 21년 주식 가격이 매우 떨어진 상태에서 발생한 배당이 매우 고배당으로 착시 현상이므로 투자 주의
• 유사 종목으로 페트로브라스 우선주(ADR)도 함께 비교 분석

2023.06.23 - [분류 전체보기] - (유가관련주) 페트로브라스 우선주(ADR) 의 전망 분석

 

(유가관련주) 페트로브라스 우선주(ADR) 의 전망 분석

미국 고배당주 페트로브라스 우선주(ADR) 브라질에 국영 투자 페트로브라스(Petrobras)는 석유 및 천연 가스 생산, 수송, 판매 등 에너지 산업 분야에서 세계적인 선두주자 중 하나입니다. 특히 브라

u-comensee.tistory.com

 

Posted by 목표를 가지고 달린다
,

한명의 친구처럼 말을 하는 앱

알림, 안내문구 등을 사람처럼 따뜻하고 부드럽게, 그리고 나의 불편함을 공감하듯이 말해준다면 많은 사람들이 좋아할 것입니다. Humanized Writing이 바로 6개월만에 토스가 이뤄낸 것입니다. 토스앱에는 은행, 증권, 혜택, 통신 등 아래의 메뉴와 같이 다양한 서비스를 제공하고 있습니다. 많은 개발자, 디자이너들이 각자 문구 등을 작성할 때 가이드라인을 참고하지만, 가이드라인이 많으면 많을 수록 놓치는 부분이 많아집니다.

'이체 완료했습니다.', '이체 완료했어요', '이체 완료' 등 동일한 표현을 각자 다르게 하는 경우가 종종 발생합니다. 사실 본인이 UX담당도 아닌데 수십페이지의 가이드를 모두 외우기도 힘들거니와 모두 체크하기는 너무 비효율적입니다. 그래서 아무리 완벽한 가이드문서를 만들어도 결국 보는 사람이 보지 않는다면 의미가 없습니다.  

그래서 토스는 가이드문서를 시스템화 했습니다.

개발툴에서 제공하는 코드 문법을 체크해서 표시해주는 기능을 활용하여, 컴퓨터가 문구를 읽고 용어를 변경하거나 동일한 어투로 바꿀 수 있게 가이드해주는 것을 개발했다고 합니다. 이 보이스톤 메이커를 만들기 위해 8,000개가 넘는 규칙을 만들어 데이터베이스화했다고 합니다. 이제는 사람이 아니라 컴퓨터가 수정해야 할 문구를 잡아주니 사람들은 더 고부가가치적인 업무에 집중할 수 있을 것 같습니다.

또한, 어투를 더 사람답게 만들었습니다.

'해피모먼트'를 발견하여, '대출 갚느라 고생했어요', '생일 축하해요' 등 축하와 격려를 수시로 하고, 어떤 변경사항(개선)에 대해서도 '그 동안 진짜 불편했을 것 같아요' 라고 공감해주기도 합니다. 사실 이런 공감하는 말투는 자칫 잘못을 인정하는 것이라고 생각하는 사람들도 있어서 대부분의 앱에서는 사용하지 않는 표현들입니다. 더 사람답게 다가가기 위해 이런 공감적인 표현을 하는 것은 정말 대단하다고 생각됩니다. 

 

 

Posted by 목표를 가지고 달린다
,