상냥한 IT 블로그

생각하는 시간이 길어서 행동을 주저한 경험이 있고 돌아보았을 때 오히려 빨리 실행하는 것이 더 좋았을 때도 있었다. 빠르게 실패하기 책을 읽으면서 인상깊었던 문장을 정리하고자 한다.

빠르게 실패하기 요약

만약 창의적인 일을 시도한다면 스스로에게 실패할 여유를 허락하는 것이 특히 중요하다. 우리는 모든 사람이 창의적이라는 점에 주목해야 한다. 우리 모두는 살면서 아이디어를 짜내고 문제 해결책을 찾으며 꿈꾸고 자신의 길을 개척해 나가고 있다. 그리고 당신 자신의 삶은, 당신이 만들어내는 궁극적인 창조물이다.

작가 앤 라모트는 『글쓰기 수업 Bird by Bird」에서 글을 쓸 때 부딪히는 도전에 대해 이렇게 말했다.
“하나의 작품을 완성하는 데 중요한 것은 정말 엉망진창인 초안을 써보도록 스스로에게 허락하는 것이에요. 정말 엉망인 초안을 쓰면 두 번째 안은 더 좋아지고 세 번째는 더 훌륭한 작품이 나올 확률이 높아지죠. 다 쓰고 나서야 자기가 무엇을 쓴 건지 깨닫는 작가들이 대부분이에요. 도대체 어떤 주제에 대해 쓰고 싶은 지, 어떻게 이야기를 펼쳐나갈지 몰라도 일단 자리를 잡고 앉아 단어들을 짜내는 게 중요해요. 그래야 스토리 전개 방향을 비로소 잡게 됩니다.”
바로 이런 태도가 빠르게 실패하기 Fail Fast의 핵심이다. 직접 해보지 않는 이상 일의 본질이 무엇인지, 일을 하면서 어떤 기분이 들지, 그 결과가 어떻게 될지는 모르는 일이다.

실수를 피하기 위해 공부하고 준비하며 질질 끄는 대신에 이들은 즉시 행동한다. 자신들의 노력이 완벽에는 한참 미치지 못하거나 경쟁력이 전혀 없어도 말이다. 성공은 대개 위태로운 상황과 어설픈 노력으로부터 시작된다. 그러니 성공을 거두고 싶다면 먼저, 그 일을 얼마나 망치게 될지 생각해 보라.

훌륭한 뮤지션이 되고 싶다면, 먼저 엉망인 음악을 수없이 연주해 봐야 한다.

언제나 탁월한 결정을 내리는 비즈니스맨이 되고 싶다면, 먼저 진부한 결정을 내리는 일정 시간을 보내야 한다.

소설을 한 권 쓰고 싶다면, 먼저 하찮은 이야기들을 써 봐야 한다.

중국어를 유창하게 하려면, 먼저 형편없는 중국어를 많이 해야 한다.

진정한 예술가가 되고 싶으면, 먼저 어설픈 예술을 창조해 봐야 한다.

에너지 효율이 좋고 미니멀한 디자인으로 최고의 상업 건축가가 되려면, 먼저 비효율적이고 거추장스러운 건축물을 디자인해 봐야 한다.

재능 있고 용감한 암벽 등반가가 되려면, 먼저 소심하고 서툰 암벽 등반가가 되어야 한다.

수학을 아주 잘해서 어려운 분석 문제를 척척 풀고 싶다면, 먼저 간단한 수학 문제와 씨름해야 한다.

훌륭한 테니스 선수가 되려면, 우선 수많은 경기에서 패배하는 경험을 쌓아야 한다. 

실패하면 실망할지 모른다. 그러나 시도하지 않는 것은 불행한 삶이다. (비버리 실즈, 성악가)

실수로 가득 찬 삶이 아무것도 시도하지 않는 삶보다 더 명예롭고 가치 있다. (조지 버나드 쇼)

실수를 하며 보낸 인생은 아무것도 하지 않고 보낸 인생보다 훨씬 존경받을 수 있을 뿐 아니라 유용한 삶이기도 합니다. (조지 버나드 쇼, 아일랜드 극작가 및 런던 경제학부 공동 설립자)

느낀점

너무 빠르게 행동해도 문제가 될 수 있지만, 너무 길게 고민해서 고민할 시간에 행동하는 게 더 나을 때도 있었다. 고민이 생기면 고민할 기간을 대략 생각하고 그 기간 내에 결정하고 사소한 거라면 빠르게 실행해보는 것이 중요할 것 같다. 뭔가 배울 때도 이론으로만 접하는 것보다 직접 실행해보면서 부족한 부분을 파악하고 수정해 가면서 실력이 늘었던 것 같다. 고민만 하다가 실행조차 못했던 경험도 있어서 빨리 실행해보는 것도 해봐야겠다.

1. 배경

수익성 사이드 개발 프로젝트에 여러 명이 참여할 때 지분율을 어떻게 설정해야 할지를 명확하게 떠오르지 않아, 고려해야 할 점을 정리해보았다. 사이드 개발 프로젝트에 참여하는 사람의 수, 사람마다 가지는 지분율에 따라서 의사결정 과정이 많이 달라질 수 있기 때문에 적절한 지분율을 설정하는 것이 중요하다고 할 수 있다. 

모바일 개발자, 개인사업자로서 내가 부족한 부분(기획, 디자인, 개발, 영업, 마케팅, 경영 등)을 채워줄 공동창업자가 필요하게 될 상황이 발생할 수 있고, 이때, 창업자 간 갈등을 가장 줄이는 동시에 가장 현명한 선택을 하기 위해서는 지분율에 대한 이해가 필요할 것 같다.

2. 지분율에 따라 행사할 수 있는 통제력 (자세한 내용은 상법 참조)

• 3% - 위법행위 감시 및 통제
• 25% - 단독 출석 시 보통결의사항 통과 가능
• 33.4% - 단독 출석 시 특별결의사항 통과 가능
• 50% + 1주 - 보통결의사항 통과 가능
• 66.7% - 특별결의사항 통과 가능
• 100% - 1인 회사

3. 지분율 설정 방법

3.1. 1:1:1:1로 1/N 으로 설정하는 방법

예를 들어, 개발자 2명, 디자이너, 기획자 넷이 사이드 프로젝트를 진행하고자 한다면, 각각 25%의 지분율을 갖는 방법이다.

단점으로는 만약에 서비스가 성공 궤도에 올라서 회사가 커지고 나서 주주총회에서 의사결정을 할 때, 지분율이 똑같다면 의사결정 상황에서 최소 2~3인 이상이 필요하므로 의사결정까지의 속도가 느릴 수 있고 주주 간 갈등이 발생할 소지가 크다. 단순하게 생각해 본다면 가장 공평한 방법이라고 생각되지만, 나중에 분쟁이 가장 많은 유형이다.

예를 들어, 갑, 을, 병, 정이 일한다고 했을 때, 갑, 을은 일을 열심히 하는데 병, 정은 회사에 발만 걸치고 업무에 관여하지 않는 상황이다. 이때, 갑, 을은 병, 정에 불만을 가질 수 있지만, 두 명 다 25%의 지분을 가지고 있기에 회사가 성장하면서 불공평한 보상을 받는 상황이 된다. 하지만 병, 정은 50%의 지분을 가지고 있으므로 불공평함을 말한다고 하더라도 배 째라는 식으로 행동한다면 조정이 불가능하다.

3.2. 대표자가 상당수의 지분을 가지고, 나머지가 남은 지분을 나눠 갖는 방법

VC(벤처캐피탈 투자사)가 가장 좋아하는 지분 형태이다. 엔젤투자, 시리즈 A, B, C 투자로 갈수록 지분이 희석되긴 하지만 대표가 지분의 대부분을 가지고 있다면, 대표만 설득하면 빠른 의사결정 및 투자를 집행할 수 있기 때문이다. 반대로 대표의 지분이 적다면 대표의 통제력이 약해져서 지분을 가진 사람에 한하여 의사결정 시 고려해야 할 이해관계가 많아진다.

3.3. 조건부 불완전 주식 부여 (Vesting)

https://www.mobiinside.co.kr/2021/01/25/stock-vesting/

아래의 내용은 위의 잘 정리된 글을 참고하였다. Vesting은 주로 실리콘밸리 스타트업에서 많이 행해지는 지분율 설정 방법이다.

Vesting 조건으로 주식을 부여받은 수여자는 특정 조건을 만족하지 않을 경우에는 해당 주식을 몰수당하거나 회사가 재매입할 수 있는 선택권을 가진 불완전한 소유권을 가지게 된다. Vesting으로 주식을 발행할 시 여러 가지 장점이 있다.

첫째, 처음에 약속했던 역할을 완수하지도 않은 상태로 주식만 받고 갑자기 회사를 떠나는 멤버가 생길 수 있다. 공동창업자들 간 처한 상황이나 갈등에 의해서 각자의 길로 가기를 원할 수 있다. 수익이 발생하지 않거나 투자유치가 이루어지지 않으면 당장 안정적인 급여를 주는 회사로 갈 수 있고, 업무 분배와 내용에 대한 불만 등 여러 가지 변수가 존재한다. 일말의 확률로 주식을 부여한지 얼마 안돼서 이러한 상황이 발생할 수 있으므로, 주식발행 후 일정 기간이 경과한 후에(창업자들이 주식의 대가로서 약속한 역할과 임무를 어느 정도 완수한 후에) 완전한 소유권을 가지게 되는 것이 추후에 발생할 갈등을 줄일 수 있는 방법이다.

둘째, 위에서 언급한 상황이 발생할 경우, 회사를 떠나는 멤버를 대체할 사람을 구해야 하는데 이 경우 다시 주식을 발행하여 부여하게 되면 기존 멤버들의 주식이 많이 희석되는 상황이 발생한다. 완전한 주식을 받고 한 창업멤버가 갑자기 회사를 떠난다면 나머지 멤버들은 업무가 증가하고 고생은 더하고 지분의 가치가 더 낮아지는 비합리적인 상황이 발생할 수 있다.

셋째, 투자자들 입장에서도, 창업자들이 베스팅 조건으로 주식을 부여받은 회사를 선호한다. 많은 VC들은 투자할 회사를 선정할 때, 창업자들의 능력과 회사에 대한 헌신도를 매우 중요하게 볼 수 밖에 없다. 당연히 창업자들이 성공에 대한 강한 동기부여가 되어 있는 회사에 투자하기를 원하지, 창업자들이 이미 완전한 주식을 소유하고 있어 언제든지 회사를 떠나거나 다른 직원들의 노력에 무임승차(free ride)하는 것을 허용하는 회사에 투자하는 것을 원하지 않을 것이다. 결국 장기적으로 VC나 외부의 다른 투자자들로부터 투자유치를 희망하는 스타트업이라면, 특히 더 베스팅 조건을 고려하는 것이 바람직할 것이다.

Vesting으로 주식을 배분하기로 결정한다면 계획을 세울 때, 고려해야 할 점은 다음과 같다.

첫째, 베스팅의 기간(length)이다. 예를 들어, 4년의 베스팅 일정을 선택한다면, 모든 주식의 완전한 소유권을 취득하려면 4년이 필요하다. 베스팅의 기간은 각 회사에 따라 다양하게 설정할 수 있지만, 일반적으로 3년에서 5년이 많은 편이며, 그중 4년을 가장 많이 선택한다.

둘째, 베스팅 기간의 기산일(commencement date)이다. 창업자들의 경우에는, 회사가 설립되기 전부터 일했던 기간을 고려하여, 베스팅 기간의 기산일을 주식의 부여일보다 앞서 설정할 수도 있다. 다시 말해, 주식은 2020년 12월 1일에 4년 베스팅 기간을 설정한 주식을 부여받으면서 그 기산일은 2020년 7월 1일로 설정할 수 있다. 이 경우에는, 베스팅 기간의 만료일은 2024년 7월 1일이 되어 실제로는 부여일로부터 3년 7개월 내에 완전한 주식의 소유권을 취득할 수 있다는 의미가 된다.

셋째, 베스팅의 빈도(frequency)이다. 즉, 얼마나 자주 베스팅이 이루어질 것인지를 정하는 것이다. 일반적으로 매달 또는 매분기마다 베스팅이 이루어지는 것으로 설정하고는 하는데, 이 부분이 중요한 이유는, 빈도를 정하지 않고 1년 중 아무때나 그리고 불규칙한 주기로 베스팅이 이루어진다면, 베스팅 주주들이 늘어남에 따라 업무상 혼란이 가중될 뿐만 아니라 매번 얼만큼의 주식이 부여되어야 하는지 계산도 복잡해지기 때문이다. 다시 말해, 4년 기간으로 설정하고 매달 베스팅을 하기로 명확하게 설정하였다면, 4년간 매달 정해진 날에 약속된 총 주식의 1/48 (약 2.08%)씩 부여받게 된다는 것을 의미한다.

넷째, 클리프(cliff) 기간의 유무이다. 클리프란, 무분별한 주주의 증가를 방지하기 위하여, 스톡옵션을 받을 수 있는 최소한의 근무 기간을 의미하며, 보통 1년으로 설정하는 경우가 많다. 즉, 베스팅 주식을 부여받은 후 1년은 근무를 해야 지난 1년치 베스팅 주식을 한꺼번에 행사할 권리가 생기는 것이다. 반대로, 1년 클리프 베스팅 조건인데, 직원이 360일만 근무하고 회사를 그만두는 경우에는, 베스팅 주식을 1주도 행사하지 못한다는 의미이다. 이는 초기에 직원들이 베스팅 주식만 받고 금방 회사를 떠나버리는 경우를 방지하고 장기적인 근속을 유도하기 위하여 고안된 제도로서, 회사 입장에서는 클리프 조건을 둘 것인지, 그리고 그 기간은 얼마로 할 것인지에 대한 신중한 고민이 필요하겠다.

4. 어떤 선택을 할까?

4.1. 조건부 불완전 주식 부여 (Vesting)

사이드 프로젝트에 참여하는 인원 수가 많고, 각자 맡은 범위가 독립적이며 업무량의 수준이 비슷하다면 이 방법을 쓰는 것이 좋을 것 같다. Vesting 기간, Vesting 기간의 기산일, Vesting의 빈도, 클리프 기간의 유무를 팀원과 합의하여 적절한 수준의 Vesting 조건을 설정한다. 변호사에게 자문을 받으면 더욱 좋겠지만, 비용이 부담되는 경우 서로 Vesting 조건에 대해 고민하고 합의하는 기간을 거쳐 납득할 만한 조건을 갖추는 것이 좋을 것 같다. 웬만하면 프로젝트 시작 초기에 합의를 하는 것이 좋을 것 같다.

4.2. 대표자가 상당수의 지분을 가지고, 나머지가 남은 지분을 나눠 갖는 방법

대표가 혼자서 대부분의 일을 해낼 수 있으면 혼자 하되, 다른 사람의 도움이 절실히 필요한 범위에 대해서 다른 사람에게 맡기는 방법이다. 대표가 기획, 디자인, 개발을 총괄하지만 마케팅, 영업에 약하다면 시니어 CMO(최고마케팅책임자)에게 지분을 부여하여 업무를 맡기는 경우다. 이렇게 하면 장점은 대표가 상당수의 지분을 가지고 있기 때문에 의사결정 속도가 빠르고, 투자를 받기에 용이하다.

책임져야 할 부분과 해야 할 업무는 많아지지만, 지분을 가진 이해관계자와의 갈등도 줄일 수 있고, 대표의 통제하에 진행되어 안정감이 높다.

1. 장단기금리차란?

미국 국채 10년물 금리 - 2년물 금리입니다.

만약 연준이 기준금리를 낮은 수준을 유지(단기금리 하락) 하고, 채권시장이 실물경제의 회복을 기대(국체 대신 주식을 매입 → 장기금리 상승)한다면 장단기 금리차가 확대됩니다. 따라서, 실물경제의 회복 국면에서 장단기 금리차가 확대되는 경향을 보입니다.

반면, 연준이 기준금리를 인상(단기금리 상승)하고, 채권시장이 실물경제의 침체를 기대(안전자산인 국채 매입 → 장기금리 하락)​한다면 장단기 금리차는 축소됩니다. 즉, 실물경제의 침체 국면에서 장단기 금리차가 축소되는 경향을 보입니다. 이것이 과해지면 장단기금리차 역전 현상이 발생합니다.

보통 10년물 금리가 2년물 금리보다 높은 것이 정상적인 상황입니다.

경제위기가 오기 전에 장단기금리차가 마이너스가 되는 경향이 있습니다.

장단기금리차가 마이너스를 찍으면 곧이어 경제성장률이 바닥으로 떨어지는 것을 쉽게 볼 수 있습니다.

2. 장단기금리차 지표 확인하기

https://fred.stlouisfed.org/series/T10Y2Y

2023년 1월 기준 -0.7 point로 2000년 전후로 IMF 시절과 비슷한 것을 볼 수 있습니다. 현재보다 더 떨어질지 올라갈지는 모르지만 장단기금리차 지표를 이해하면 경제를 이해하는 데 도움이 될 것입니다.

3. 경기순환시계 사이트

kosis.kr/visual/bcc/index/index.do;jsessionid=mR1DjF65YqFRDZrZZk1Kdg1ChkPX93QAxRdca1yloMEE2SHzVQy2gYV1M54F0XTv.STAT_WAS1_servlet_engine4?mb=N

1. 배경

데이터베이스에서 데이터를 가져와 앱 프론트에 표시할 때, 서버와 API통신하는 경우가 많은데, API 통신 코드를 모듈화하여 유지보수가 용이하게 할 필요성이 있었다. 다양한 기능을 가진 Interceptor를 옵션에 추가해 개발 시 디버깅이 편하게 해야 했다.

2. 요구사항

2.1. dio

https://pub.dev/packages/dio

인기있는 http 라이브러리다. 다양한 기능이 포함되어있다.

2.2. alice

https://pub.dev/packages/alice

api 통신을 디버깅하거나 receiveTimeout 등의 설정을 할 수 있다.

2.3. hive

https://pub.dev/packages/hive

로그인 시 jwt token을 hive에 저장하고, API 통신 시 헤더에 이를 추가하여 유저임을 인증할 수 있다.

2. 코드

import 'dart:async';
import 'package:alice/alice.dart';
import 'package:hive/hive.dart';
import 'package:papsm/app/data/environment/environment.dart';
import 'package:papsm/app/dio/constant_dio.dart';
import 'package:dio/dio.dart';
import 'package:dio_cache_interceptor/dio_cache_interceptor.dart';
import 'package:flutter/material.dart';

import 'package:papsm/app/dio/interceptor/logging_interceptor.dart';

class DioHelper {
  Dio? dio;
  Alice? alice;

  DioHelper() {
    alice = Alice(showNotification: false);
    final options = BaseOptions(
      receiveTimeout: ConstantDio.timeout,
      connectTimeout: ConstantDio.timeout,
    );

    options.baseUrl = EnvironmentConstant.config ?? 'test';
    dio = Dio(
      options,
    );

    dio!.interceptors.add(LoggingInterceptors());
    dio!.interceptors.add(alice!.getDioInterceptor());
    dio!.interceptors.add(DioCacheInterceptor(options: dioCacheOptions));
  }

  Future<Map<String, dynamic>> get(String url,
      {dynamic param, bool? refresh}) async {
    final userModelBox = await Hive.openBox('userModelBox');
    String? token = userModelBox.get('token');
    dio!.options.headers["authorization"] = 'Bearer $token';
    final response = await dio!.get(
      url,
      queryParameters: param,
      options: refresh == true
          ? dioCacheOptions.copyWith(policy: CachePolicy.refresh).toOptions()
          : null,
    );
    return response.data as Map<String, dynamic>;
  }

  Future<Map<String, dynamic>> post(String url, dynamic body) async {
    final userModelBox = await Hive.openBox('userModelBox');
    String? token = userModelBox.get('token');
    dio!.options.headers["authorization"] = 'Bearer $token';
    final response = await dio!.post(url, data: body);
    return response.data as Map<String, dynamic>;
  }

  Future<Map<String, dynamic>> patch(String url, dynamic body) async {
    final userModelBox = await Hive.openBox('userModelBox');
    String? token = userModelBox.get('token');
    dio!.options.headers["authorization"] = 'Bearer $token';
    final response = await dio!.patch(url, data: body);
    debugPrint('[Response] ${response.data.runtimeType} ${response.data}');
    return response.data as Map<String, dynamic>;
  }

  Future<Map<String, dynamic>> put(String url, dynamic body) async {
    final userModelBox = await Hive.openBox('userModelBox');
    String? token = userModelBox.get('token');
    dio!.options.headers["authorization"] = 'Bearer $token';
    final response = await dio!.put(url, data: body);
    debugPrint('[Response] ${response.data.runtimeType} ${response.data}');
    return response.data as Map<String, dynamic>;
  }

  Future<Map<String, dynamic>> delete(String url, dynamic body) async {
    final userModelBox = await Hive.openBox('userModelBox');
    String? token = userModelBox.get('token');
    dio!.options.headers["authorization"] = 'Bearer $token';
    final response = await dio!.delete(url, data: body);
    debugPrint('[Response] ${response.data.runtimeType} ${response.data}');
    return response.data as Map<String, dynamic>;
  }

  void errorCheck(Map<String, dynamic> result, String err) {
    if (result['code'] != 200) {
      throw err;
    }
  }
}

CacheOptions dioCacheOptions = CacheOptions(
  store: MemCacheStore(),
  hitCacheOnErrorExcept: [401, 403],
  maxStale: const Duration(hours: 6),
);

DioHelper 생성자에서 .env 파일에서 저장된 서버의 주소로 baseUrl을 설정하였다.

dio interceptor로 LoggingInterceptor를 추가하여 API 통신 시 보내는 데이터와 받는 데이터를 로깅하는 기능을 추가했다.

dio interceptor로 CacheInterceptor를 추가하여 동일한 API 통신 시 6시간 마다 MemCacheStore에 저장하여 재활용할 수 있도록 하였다. (새로 요청하려면 refresh option을 true로 두면 된다.)

hitCacheOnErrorExcept에서 401, 403 error가 발생했을 때는 다시 요청하도록 했다.

1. 배경

각 유저마다의 체력 등급을 평가하기 위해 체력요인점수를 합하여 높은 순부터 1등급 ~ 9등급을 부여해야 하는 기능을 구현해야했다.

2. 요구사항

2.1. 각 체력요인 점수는 종목 점수 중 제일 높은 것을 선택
2.2. 1 ~ 9등급 비율은 아래의 표를 참고하여 설정

2.3. 각 유저의 5가지 체력요인 점수를 합하여 비교
2.4. prisma 기본 쿼리로는 구현이 복잡해서 Raw Query를 사용해서 구현
2.5. 연도별 조회 기능도 필요하기에 year에 따라 연도별로 계산

3. 해결 & 코드

      select
        t3.*,
      -- 비율마다 1 ~ 9등급 부여
      CASE WHEN t3."totalPercentile" >= 0.96 THEN '1'
          WHEN t3."totalPercentile" >= 0.89 THEN '2'
          WHEN t3."totalPercentile" >= 0.77 THEN '3'
          WHEN t3."totalPercentile" >= 0.60 THEN '4'
          WHEN t3."totalPercentile" >= 0.40 THEN '5'
          WHEN t3."totalPercentile" >= 0.23 THEN '6'
          WHEN t3."totalPercentile" >= 0.11 THEN '7'
          WHEN t3."totalPercentile" >= 0.04 THEN '8'
          ELSE '9'
      END AS "totalGrade"
      from
        (select
          t2.*,
          -- PERCENT_RANK()를 사용하여 비율 구하기
          PERCENT_RANK() OVER (ORDER BY t2."totalScore") as "totalPercentile"
        from
          (select
            t1."userId",
            -- 비율 계산에 필요한 각 유저의 5가지 체력 요인 점수 합계
            cast (sum(t1."max_score") as integer) "totalScore"
          from
            (select
              u."userId" "userId",
              u."factor" "factor",
              max(u.score) "max_score"
            from
              "UserEventScore" u
            where
              -- year에 따라 연도별 조회
              extract(year from u."updateDate") = ${year}
            group by
              u."userId",
              u."factor") t1
        group by
          t1."userId") t2
        ) t3
      where
        t3."userId" = ${userId}

4. Next To Do

4.1. 파일 다운로드, 업로드 기능
4.2. 마이페이지 변경 기능들
4.3. 종목 평균 점수 계산 API 개발
4.4. 체력 진단 기능 API 개발

1. 배경

매번 하는 일인데, 배포 심사할 때만 하다보니 까먹는 경우가 잦아 정리하려고 한다

2. 의존성 추가하기

flutter_launcher_icons: "^0.11.0"

https://pub.dev/packages/flutter_launcher_icons

3. flutter_launcher_icons.yaml

루트 폴더에 앱 아이콘의 경로 및 기타 정보를 설정하는 yaml 파일을 생성한다.

flutter_icons:
  android: "launcher_icon"
  ios: true
  remove_alpha_ios: true
  image_path: "assets/images/app_icon.png"

4. 앱 아이콘 적용하기

터미널에 아래 명령어를 사용하면, 해상도별로 android, ios 앱 아이콘이 적용된다

flutter pub run flutter_launcher_icons -f flutter_launcher_icons.yaml

1. 배경

티스토리 스토리 섹션에서 댓글을 다는 도중 자동화하면 좋을 것 같아서 도전해보았다. 티스토리 댓글을 자동으로 달아주는 봇을 만들면 편할 것 같아서 selenium으로 Python 봇을 만들기로 했다.

2. 코드

python 크롤링할 때 많이 쓰이는 selenium을 사용했고, 크롬 웹 드라이버를 사용했다. 아이디 비밀번호 입력할 때는 pyperclip으로 클립보드에 복사하여 입력하는 방식을 사용했다. (코드 설명은 아래 주석 참고하자)

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.common.action_chains import ActionChains
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# 크롬 드라이버 자동 업데이트
from webdriver_manager.chrome import ChromeDriverManager

import pyperclip
import time
import datetime
import openpyxl

# 클립보드에 input을 복사한 뒤
# 해당 내용을 actionChain을 이용해 로그인 폼에 붙여넣기
def copy_input(xpath, input):
    # 해당 element가 있을 때까지 대기
    isActivated(xpath)
    while True:
        try:
            pyperclip.copy(input)
            driver.find_element(By.XPATH, xpath).click()
            ActionChains(driver).key_down(Keys.COMMAND).send_keys('v').key_up(Keys.COMMAND).perform()
            return
        except:
            time.sleep(0.2)
            continue

# 존재하면 클릭
def existClick(xpath):
    isActivated(xpath)
    driver.find_element(By.XPATH, xpath).click()

# 존재하면 가져옴
def existGetElement(xpath):
    isActivated(xpath)
    return driver.find_element(By.XPATH, xpath)
    
# 존재하면 종료
def isActivated(xpath):
    while True:
        try:
            target = driver.find_element(By.XPATH, xpath)
            if not target:
                time.sleep(0.2)
            else:
                break
        except Exception as e:
            print(e)
            time.sleep(0.2)
            continue

# 티스토리 로그인
def tistoryLogin(userid, pw):
    print('tistoryLogin', userid, pw)
    # 카카오 로그인 창 띄우기
    driver.get('https://www.tistory.com/auth/login')
    # 카카오 계정 로그인
    existClick('//*[@id="cMain"]/div/div/div/a[1]')
    # 아이디 입력
    copy_input('//*[@id="input-loginKey"]', userid)
    # 비밀번호 입력
    copy_input('//*[@id="input-password"]', pw)
    # 로그인 버튼 클릭
    existClick('//*[@id="mainContent"]/div/div/form/div[4]/button[1]')
    # 스토리 접속
    existClick('//*[@id="kakaoGnb"]/ul/li[2]/a')

# 댓글 달기
def reply():
    # 라이프
    existClick('//*[@id="mArticle"]/div[1]/ul/li[1]/a/span')
    time.sleep(3)
    driver.execute_script("window.scrollTo(0, 2000)")
    time.sleep(3)
    driver.execute_script("window.scrollTo(0, 2000)")
    time.sleep(3)
    # 첫 번째 글
    existClick('//*[@id="mArticle"]/div[3]/ul/li[2]')
    # 댓글 달기
    time.sleep(3)
    driver.execute_script("window.scrollTo(0, 2000)")
    time.sleep(3)
    driver.execute_script("window.scrollTo(0, 2000)")
    time.sleep(3)

    copy_input('//*[@id="comment"]', '글 솜씨가 좋으시네요! 잘 보고 갑니다~')
    existClick('//*[@id="entry60Comment"]/div/form/div/div[2]/button')
    
# 브라우저 꺼짐 방지
chrome_options = Options()
chrome_options.add_experimental_option("detach", True)

# 불필요한 에러 메시지 없애기
chrome_options.add_experimental_option("excludeSwitches", ["enable-logging"])

service = Service(executable_path=ChromeDriverManager().install())
driver = webdriver.Chrome(service=service, options=chrome_options)

driver.set_window_position(0, 0)
driver.set_window_size(1600, 1000)

# 티스토리 로그인 아이디, 비밀번호
id = 'id'
pw = 'pw'

tistoryLogin(id, pw)

reply()

XPath로 html element를 찾고나서 클릭하거나 텍스트를 입력해야 한다. element가 로딩되고 있는 시점에는 element를 찾지 못하는 오류가 발생하기 때문이다. 봇이 클릭이나 텍스트 입력 시, isActivated() 함수를 통해 해당 element가 존재하는지 0.2초 마다 검사하도록 했다. 해당 element를 발견하면 다음 동작을 실행시키도록 구현했다.

티스토리 로그인 및 게시글 이동까지는 성공했으나 댓글 달기 시, 여러 방해물이 존재했다.

3. 한계

티스토리에서 크롬 웹 드라이버를 이용한 댓글 자동으로 다는 Python 봇을 막으려고 여러가지 장치를 해놓아서 다른 방법을 찾아봐야 할 것 같다. 이유는 아래와 같다.

첫째로, 크롬 웹 드라이버로 게시글에 들어가서 댓글을 달고자 할 때 랜덤으로 생성된 매크로 방지문자 6자리를 입력해야 해서 자동화가 불가능하다.

둘째로, html element를 찾을 때 element의 id 정보를 포함한 XPath를 사용하는데, id가 entry60Comment, entry210Comment 이런식으로 게시글, 블로그마다 불규칙적이여서 기준을 잡기가 불가능하다.

4. 소감

티스토리 댓글 봇은 현재 어렵지만, 다른 방법이 있는지 고민해봐야겠다.

element의 id나 XPath가 규칙적이거나 자동입력방지문자가 없는 사이트에 대해서 데이터 크롤링, 자동 매크로를 사용할 때 요긴하게 쓰일 것 같다.

1. DAO의 개념

DAO란 Decentralized Autonomous Organization의 약자로 탈중앙화된 자율조직을 의미한다. 블록체인과 인공지능 기술이 접목된 블록체인 기반의 공동 투자조합이다.

기존의 기업은 CEO나 경영진이 회사의 방향에 대한 의사결정을 하지만, DAO는 구성원의 모두 참여하여 투자하고 투표하고 인공지능에 의한 의사결정을 한다. 이 과정에서 현재까지의 투자 현황, 분배 방법, 운영 과정에 대한 소스 코드가 모두에게 공개된다. DAO 기업의 프로세스는 모두에게 투명하고, 완벽하게 민주적이다. 모든 사람들은 어떠한 형태로 거래가 일어나는지, 이때 내가 가져가는 것을 얼마인지, 지분이 얼마인지를 모두가 확인할 수 있고, 공동으로 공정하게 의사결정하는 조직이다. 

DAO가 미래의 시스템이라고 하는 이유는 인간보다 인공지능이 더 정확하고 효율적인 판단을 내릴 수 있는 영역에서 의사 결정을 할 때, 인공지능이 모두가 납득할 수 있는 범위 내에서 행동을 하도록 설계되어 있기 때문이다. 비리, 비밀을 없앰으로 인해서 DAO 기업이 더 투명하게 경영될 수 있고 사회에 조금 더 큰 가치를 가지고 있는 형태로 운영되도록 하자는 것이 DAO의 철학이다.

2. DAO가 활용된 사례

https://originstamp.com/blog/10-examples-of-decentralized-autonomous-organizations/

3. Flutter, 블록체인, NFT를 활용한 Dapp 개발 (DAO) 계획

1월 : 블록체인 기반 NFT 활용 방안에 대한 자료 조사 및 아이디어 도출

2월 : 블록체인 개념 학습 (분산화 시스템, 이더리움, EIP, 이더리움 네트워크, Smart Contract, Private Key & Public Key, EOA & CA, Private Key 관리 기법, 지갑, Web3, 거래소, 이더리움 네트워크 모델, CRUD 개발)

3월 : Ganache, truffle, VSCode를 사용한 개발 환경 설정, Solidity 언어 학습, Web3 네트워크 연결, 이더리움 전송 트랜잭션 개발, Smart Contract 트랜잭션 개발, 이더리움 보유량 조회 기능 개발, 트랜잭션 이벤트, Smart Contract 이벤트 수신 개발, Flutter UI 개발, 기능별 단위 테스트 진행

4월 : Smart Contract 비즈니스 로직 개발, Flutter UI 개발, 단위 테스트 진행

5월 : MetaMask 테스트넷에 배포 및 통합테스트 진행, 코드 리팩터링

6월 : 프로젝트 페어(졸업작품 사전심사) 준비

7~9월 : 부가기능 개발(Smart Contract 비즈니스 로직 개발, Flutter UI 개발)

10월 : MetaMask 테스트넷에 배포 및 통합테스트 진행, 코드 리팩터링

11월 : 창의작품경진대회(졸업작품 본심사) 준비

1. Why, 전자책을 왜 만들어야 하는가?

전자책이란 문자나 화상과 같은 정보를 전자 매체에 기록하여 서적처럼 이용할 수 있는 디지털 도서를 총칭한다. 독자 입장에서 보면 종이책에 비해 가격이 저렴하고 필요한 부분만 별도구입이 가능하다는 점이 편리하고, 출판사 입장에서도 제작비와 유통비를 절약할 수 있고 업데이트가 쉽다는 장점이 있다.

해마다 전자책을 판매하는 사람과 구매하는 사람은 늘어나고 있고, 전자책 시장은 점점 커지고 있다. 전자책을 판매하여 소소한 용돈을 버는 사람들부터 많은 판매량을 기록하는 사람들도 있다. 각 분야의 사람들은 지식에 대한 갈증이 있고 이를 해소해주는 컨텐츠에는 기꺼이 돈을 지불한다.

퇴근 후 저녁 시간 하루 1~2시간 1주일 정도의 투자로 20~50페이지 가량의 전자책 하나씩 만들어보자. 내가 경험한 지식 중에서 다른  사람에게 도움이 될 만한 내용을 선별하여 만들어보자. 전자책을 만들어봐야하는 이유는 내가 자고 있는 동안에도 판매가 되고 이는 수익으로 돌아오기 때문이다. 이는 회사에서 하루 내내 근무하는 것보다 부담이 훨씬 덜한 시간이다. 회사에서 근무하는 경우는 내가 투자한 시간만큼만 시급을 받는 형태이지만(8시간 일하면 8시간에 대한 것만 받는다.) 전자책은 한 번 잘 만들어 놓기만 하면 그때부터 내가 시간을 투자하지 않더라도 수익이 발생한다.

2. How, 전자책을 어떻게 만드는가?

2.1. 내 인생 돌아보기, 주제 발굴을 위한

내 현재까지 살아온 인생을 돌아보자.

이 블로그 주인장인 나는 보통 사람들처럼 초중고 교육과정을 마친 후에 지방 거점 국립 대학교 컴퓨터공학과에 입학하여 대학생활을 했다. 입학 이전에 코딩을 한 경험이라고는 AutoHotkey나 Python으로 게임 매크로를 개발해 본 경험이 다였기 때문에, C, Java, Javascript에 대해서는 전혀 몰랐다. 그래서 전공 공부를 열심히 배워 익숙해지자고 마음을 가졌고 수업에 열심히 임했다. 새로운 지식에 대해 모든 게 어색한 시기였기에 인생의 전부가 대학 전공 공부였던 시기였다.

대학생활을 하고 나서 공군 개발병으로 복무를 했다. 약 2년간 여러 대규모 Spring 웹 프로그램을 유지보수, 전화 응대, 오류 수정, 추가 기능 개발에 대한 일을 하면서 웹 개발에 대해 전반적인 이해를 했다. 제대하고 나서는 웹프로그래밍, 데이터베이스 수업에서 Node.js 백엔드 개발, React 프론트엔드 개발 기술, SQL 쿼리 작성 기술, 테이블 설계를 배웠다. 창업 동아리와 직장인 사이드 프로젝트에서 Flutter를 활용한 앱 개발을 진행했고 Android, iOS 배포를 배웠다. 그러면서 Flutter 앱 개발 기술과 Node.js 서버 개발 기술, AWS 배포 기술을 익혔고 이것으로 앱 개발 외주 사이트에 앱을 개발해드리는 서비스를 오픈했다. 프리랜서 사이트를 통해 골프 회사, 개인 의뢰, 교사 분들, 등의 예비 사업가분들과 연락이 닿았고 개발을 하고 있다.

취미는 코딩, 주식 부동산 경제 공부, 사업 공부, 셀프 브랜딩, 헬스, 자전거 타기, 탁구, 맛집 탐방, 독서, 글쓰기, 인터넷 쇼핑, 영화보기 이다.

2.2. 주제 발굴하기

내 경험을 바탕으로 주제를 선정하는 방법도 있고, 전자책 판매 플랫폼에 들어가서 카테고리 별 판매되는 전자책 주제를 참고거나 변형해서 정할 수 있다.

1. 공군 개발병 쉽게 들어가는 방법, 군대 2년 동안 웹 개발 경험을 하는 방법

군대에서 코딩 관련 일을 하고 싶은 사람을 대상으로 개발병이 되는 방법을 자세히 설명한다. 군대에서 자기 전공과 관련없는 일을 2년 동안 하다가 나오는 경우, 이 시간이 매우 아까울 수 있다. 그리고 면접 팁과 공군 훈련소, 특기학교에서 생활방법, 도움이 되는 정보 커뮤니티를 설명한다. 개발병 2년 동안의 생활, 노하우, 보람있는 군생활을 위한 자투리 시간 활용법을 자세하게 설명한다. 그리고 느낀 점과 군생활동안 배운 점을 요약해서 설명한다.

2. 앱 개발하는 방법 (프론트 앱부터 백엔드 개발, 마켓 배포까지)

스스로 온전히 나만의 앱을 만들고 싶어하지만 어떻게 개발을 시작해야 할지 모르는 사람들을 대상으로 앱 개발 방법을 설명한다. 어떤 기술을 써야 하는지, 장점은 무엇인지, 단점은 무엇인지 4년 동안 고민한 내용을 바탕으로 주제별 기술 스택을 설명한다. 풀스택 개발을 위해 어떤 것을 공부를 해야 하는지도 포함한다. 그리고 정보를 얻는 방법, 질문하는 방법, 빨리 개발하는 법 등 프로젝트 개발 과정에서 4년 동안 고민해보고 시행착오 했던 경험을 자세히 설명한다.

3. 앱개발 영업 노하우 공유

약 1년간 의뢰받은 경험을 바탕으로, 앱 개발 외주를 시작하고자 하는 프리랜서들을 대상으로 도움이 될 정보를 정리해서 설명한다. 어느 정도 개발이 가능하면 앱 개발 외주를 시작할 수 있는지, 고객이 앱 개발을 의뢰할 때 주의 깊게 보는 포인트 5가지, 의뢰가 들어왔을 때 검토해야 하는 체크리스트 공유, 앱의 주제와 기능별 프론트엔드, 백엔드 선택 노하우, 앱 개발 과정 설명, 기획서가 없고 아이디어만 있는 고객 대처 방법, 초보자도 앱 디자인 수준 높게 만드는 법, 고객이 가장 불안해하는 요소들, 유지보수 계약, 고객들 유형별 대처 방법, 소개영업, 빠르게 기획하고 디자인하는 방법, 리뷰가 중요한 이유, 피드백의 중요한 이유, 회사 고객의 특징과 개인 고객의 특징, 고객 관리가 중요한 이유 등에 대한 내용을 다룬다.

4. 온라인 쇼핑 싸게 사는 법

온라인을 통해 쇼핑하는 사람들이 해마다 늘어나고 있고 규모도 그에 따라 상승하고 있다. 이제는 소비자들이 현명한 소비가 중요한 시대에 왔다. 같은 제품이라도 쇼핑 채널마다 가격이 제각각이고, 같은 기능을 가지는데 가격이 다른 경우도 있다. 물품에 따라 품질을 감수하면 훨씬 저렴한 가격에 구매하기도 한다. 최신 사례를 바탕으로 물품별로 저렴하게 사는 팁을 공유한다.

5. Flutter 블록체인 앱 개발

처음 블록체인 Dapp을 개발을 하는 사람을 대상으로 쉽게 개발할 수 있게 돕는다. 아직 블록체인에 대해 잘 알지는 않지만 이번 학기 (4-1) 졸업 프로젝트에서 블록체인 기술을 활용하여 Dapp을 개발해야 하므로 이 도메인 지식을 정리하고, 개발 과정을 꾸준히 정리해나가다 보면 전자책을 만들 수 있을 것 같다.

2.3. 글쓰기 연습하기

글쓰기가 어렵다면 글쓰기 연습부터 해야 한다. 먼저 Google 검색창에 자신이 관심있는 주제에 대해 검색하고 상위노출 된 글을 5~10개 정도 본다. 상위 노출된 글은 Google 검색 알고리즘에 선택되었다는 의미이므로 사람들이 그 글을 오래동안 보았거나 클릭 횟수가 많은 글일 것이고 퀄리티도 기본 이상 보장될 것이다. 글을 처음 쓰는 경우에는 머리에 잘 떠오르지 않기 때문에 그 글들을 보면서 글의 구성과 글을 어떻게 쓰는지 참고하는 것이 좋다. 개인적으로 글을 쓸 때,

1. 제목 정하기

2. 목차 정하기

3. 글을 쓰다가 막히면 다른 글들을 참고하되 내 경험을 녹여서 쓰기

4. 다시 보면서 어색한 문장, 구성 수정하기

이 순서로 진행한다. [역행자]의 저자인 자청님은 글을 쓸 때, SEDA라는 원칙으로 쓴다고 한다. SEDA는 짧게 쓰고 (Shortly), 쉽게 쓰고 (Easily), 문단을 나누고 (Divide), 다시 보는 (Again) 것을 말한다. 이 방법도 읽는 사람의 입장에서 가독성을 높이는 방법으로 매우 좋다고 생각한다.

하지만 무엇보다 중요한 것은 양치기인 것 같다. 많이 써보고 다시 읽어보고 잘 쓴 사람들과 비교해보고 또 다시 읽는 과정을 통해 점점 나아진다고 생각하고 나도 그렇게 하고 있다.

3. Where, 전자책을 어디에 판매할까?

전자책을 판매하는 플랫폼은 여러 개가 있다. 크몽, 탈잉, 오투잡, 인프런, 내 블로그 등이 있다. 전자책 플랫폼은 수수료가 있지만 방문자 수가 많기 때문에 판매를 높일 수 있다. 내 블로그가 있는 경우에는 수수료 없이 판매가 가능하지만, 판매량을 높이려면 게시글 노출 수, 방문자 수가 중요하다.

4. How, 전자책을 어떻게 판매할까?

1. 내가 만든 전자책의 비슷한 주제를 다루되, 판매량이 높은 것들을 5~10개정도 관찰, 분석하여 공통점을 도출하고 나의 컨텐츠에 맞게 새로 구성한다.

2. 내 컨텐츠로 사람들의 시간, 비용을 얼마나 아껴줄 수 있는지, 정보의 희소성을 고민해보고 가격을 결정한다. (예를 들어, 이 지식으로 절약되는 시간, 비용이 얼마인지 생각해본다)

3. 여러 채널을 통해 해당 상품을 홍보한다. (유튜브, 블로그, 인스타, 지인 등)

월평 3동 거주민의 로컬 단골 Real 맛집 현장 탐방기를 시작하겠습니다!

1. 위치

https://naver.me/GjRGjUVn

월평3동에 살면서 주로 외식을 할 때 월평1동(이마트 트레이더스 쪽) 이나 월평2동(무지개아파트 쪽) 쪽으로 가는데요! 한마음 정육식당은 월평1동에서 제일 자주 가는 집 중 하나랍니다. 집 앞 정육점이나 이마트 트레이더스에서 고기를 사먹을 때도 있지만, 아무래도 식당에서 선별한 고기가 더 맛이 좋기도 하고 사이드 메뉴가 맛있어서 밖에서 먹기도 한답니다.

2. 메뉴

메뉴판입니다! 메인 메뉴는 돼지고기와 소고기가 있고, 부위별로 추가할 수 있습니다! 잘먹는 성인 3명이서 주로 가는데요~ 소고기를 먹을 때는 소 한마리(600g)를 시켜야 양이 맞았고, 돼지고기를 먹을 때는 반마리(500g) + 공기밥 + 쫄면 시키면 양이 맞았던 것 같습니다! 쫄면이 달콤하니 맛있는데요~ 처음에 무료로 쫄면을 주지만 사이드로 추가해서 시키는 쫄면이 양도 많고 고기랑 궁합이 잘 맞아서 자주 시킨답니다~

3. 사진

양념이 달콤해서 맛있습니다! 

테이블마다 된장찌개 전용 가스레인지가 있어 따듯하게 먹을 수 있어서 더 맛있었습니다~ 그리고 종업원 분들이 돌아다니시면서 빈 그릇을 치워주시고 부족한 음식, 파절이, 된장찌개 등을 리필해주셔서 먹기 편했습니다! 

고기도 신선해 쫄깃하고, 사이드 메뉴도 다양하면서 맛있고, 서비스도 좋은 한마음 정육식당! 월평동에 들릴 일이 있으면 가보시는 것을 추천합니다~

1학년 교양 과목 리포트를 공유한다. 경영학적 관점에서 공학자에게 필요한 지식을 배우는 과목이였는데, 느낀 점이 많았던 과목이였다. 아래는 '숨은 돈을 찾아라'에 대한 독후감이다.

시스템프로그래밍 과목에서 악명높은 MallocLab(말록랩) explicit을 구현한 후기를 적고자 한다. 해당 과목 수강생 중에 구현한 사람이 1명 밖에 없다고해서 조교님한테 1:1로 코드설명까지 해야했던 과제여서 기억에 남는다.

과제 목적

C로 작성한 동적할당기를 구현하는 것이다. 즉, malloc, free, realloc 함수들을 활용해서 할당 작업 성능을 최대한으로 끌어올려야 한다. 정확하고, 신속하고, 효율적인 코드를 작성할수록 성능 점수는 상승한다.

Naive

Implicit

Explicit

Naive, Implicit은 기껏해봐야 66점이 나오는데, Explicit으로 구현했더니 94점으로 거의 1.5배의 성능 향상이 있는 것을 알 수 있다. 

explicit을 구현하면서 적용하는 알고리즘에 따라 성능의 차이가 심하다는 것을 몸소 느꼈다.

동적할당의 내부 동작 과정을 피부로 와닿은 배운 것이 많았던 과목이였다.

학기 중이라 바빠서 신경 못쓴 것도 있지만, 거의 한 달간 앱 심사를 여러 번 올리고 애플님한테 리젝당하고.. 돌아보면 많은 것을 배운 시간이었다.

리젝 당한 이유는 소셜 로그인(카카오 로그인, 애플 로그인) 때문이였는데, Google PlayStore (Android)에서 보는 심사 기준보다 깐깐하게 보니 기준에 맞춰 구현하는 것이 중요하다고 할 수 있다.

1. 카카오 로그인

우선 회원가입할 때 이메일을 사용하기 때문에 이메일은 필수로 가져올 수 있어야 했다. (카카오 디벨로퍼스 홈페이지에서 이메일 필수 동의 설정해야 하고, 필수 동의 설정 하려면 사업자 등록 번호 입력해야 됨 -> 이것 때문에 예전에 개인 사업자 등록함ㅋ)

카카오톡이 설치되었으면 별도로 입력하는 것 없이 이메일을 가져올 수 있지만,

카카오톡이 설치되지 않았을 때, 에러를 발생시키는데 catch문에서 웹으로 넘어가서 카카오 이메일, 비밀번호 입력 후 정보 가져올 수 있어야 함.

2. 애플 로그인

애플 로그인 시, 처음에만 이메일을 가져온다. 2번째 로그인 시 이메일에 null값을 가져오므로 처음에 당황했다. 

해결법은 로컬 데이터베이스에 해당 이메일을 저장해서 다음에 로그인 할 때 이 이메일 정보를 활용해야 한다.

2-1. 회원 탈퇴 기능

애플 로그인을 하는 경우 회원 탈퇴 기능이 있어야 함.

어느 블로그에 회원 탈퇴 로직을 구현하려면, 아래와 같은 과정이 필요하다고 해서, 백엔드 스프링 개발자님에게 해당 사항을 요청드렸다.

1. Apple 로그인 시 authorization_code를 포함하여 API Server에 전달
2. client_secret을 생성 할 수 있도록 한다. → Apple Developer Key Info 필요
3. Apple Server API를 접근 하기 위한 access_token 생성
4. 애플 로그인 회원 탈퇴 시 Apple Server로 사용자 토큰 해지 처리 로직 개발

회원 탈퇴 시, 토큰 해지 처리가 필요한지, 아니면 데이터베이스에서만 알아서 회원탈퇴 처리 하면 되는지 고민이였다.

그러다가 토큰 해지 처리 로직이 없어도 심사가 통과된다는 이야기를 듣고, 카카오 로그인, 애플 로그인, 회원탈퇴 기능을 넣은 상태에서 심사에 올렸다.

기말고사 끝나는 날에 심사 통과가 되어서 두 배로 기분이 좋았다ㅎㅎ

https://www.ascentkorea.com/what-is-crm/

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

https://business.adobe.com/blog/basics/cross-channel-marketing

Flutter 츠누봇 [Pull Request] :: [학식] 페이지 UI 퍼블리싱

https://github.com/cnu-bot/cnubot-client-app/pull/22

1. 요구사항

- 디자인 참고하여 UI 개발

- 공통 컴포넌트 설계

- TextStyle, Color 생성

- 1, 2, 3, 4학, 긱사, 생과대 식단 가져오기

- 원산지 파싱

2. 작업내용

영상으로 확인하기

https://www.youtube.com/shorts/EcfJ5q3RGHA

 

작업 상세내용

3. 코드리뷰

- conflic 해결방법 : git merge 제안

- 파일명, 함수명 오타 수정

4. Merge

Flutter 츠누봇 [Pull Request] :: [소식] 페이지 API 연동

https://github.com/cnu-bot/cnubot-client-app/pull/20

1. 요구사항

2. 작업내용

영상으로 확인하기

https://www.youtube.com/watch?v=1Xn7CVbj8jU 

작업 상세내용

3. 코드리뷰

- Shell script 사용

- Get.back()을 Get.toNamed()로 수정

- enum에 API요청을 위한 param 변수 추가

4. Merge

Flutter 츠누봇 [Pull Request] :: [소식] 페이지 UI 퍼블리싱

https://github.com/cnu-bot/cnubot-client-app/issues/11

1. 요구사항

- 아래 디자인을 바탕으로 UI 개발

- 데이터는 임시로 더미데이터를 생성하여 진행

2. 작업내용

영상으로 확인하기

https://www.youtube.com/shorts/y4_hiaOdu1o

 

작업 상세내용

3. 코드리뷰

- default로 정해져있는 코드 생략

- 유틸함수 분리

- Color 변수 이름 컨벤션 : kBlue213B85 -> kBlue21 로 수정

- Color 변수는 copyWith() 함수를 사용하여 재사용성 높임

- BottomNavigation 추가

4. Merge

Flutter 츠누봇 [Pull Request] :: flutter_lints rules 추가

https://github.com/cnu-bot/cnubot-client-app/pull/17

1. 요구사항

- 협업 시 코드의 일관성을 위해 lint rule 적용

2. 작업내용

root폴더의 analysis_options.yaml 파일에 해당 lint 규칙 추가

linter:
  rules:
    avoid_print: true		// release모드에서 출력 안되게 변경
    prefer_single_quotes: true		// single quote 통일
    require_trailing_comma: true
    always_use_package_imports: true	// 절대경로 사용
    prefer_final_locals: true		// final 사용 (컴파일러 성능 향상)
    camel_case_types: true		// camel_case_types

lint rule 적용하면서 생긴 Problems 수정

3. 코드리뷰

4. Merge

Flutter 츠누봇 [Pull Request] :: clean & 3-layered architecture 적용

https://github.com/cnu-bot/cnubot-client-app/pull/9

1. 요구사항

- Project resetting

-folder structure refactoring

- http => dio

- color palette

- font typography

2. 작업 내용

README.md 파일 업데이트

clean & 3-layered 아키텍쳐 적용

dioHelper - provider - repository - controller - GetView 순서로 API에서 가져온 데이터 표시

.env 파일 추가

env 파일은 API서버 IP, Service key 같은 민감한 정보를 저장합니다. (.gitignore에 .env추가 완료)

3. 코드리뷰

- 폴더 오타 수정

- ios platform 버전 12.0으로 수정 (Podfile)

- 파일명 단수로 통일

- 절대경로로 통일

- 필요없는 코드 제거

- dioHelper 추가

- http 의존성 제거 (dio로 대체)

- DI (의존성 주입) 

- CI 오류 수정

4. Merge

 Flutter 츠누봇 [Pull Request] :: 의존성 추가, 화면 비율 설정

https://github.com/cnu-bot/cnubot-client-app/pull/3

1. 요구사항

- 의존성 추가

- 화면 비율 설정

2. 작업 내용

의존성 추가

cupertino_icons: ^1.0.2
freezed_annotation: ^2.1.0
json_annotation: ^4.6.0
http: ^0.13.5
get: ^4.6.5
url_launcher: ^6.1.5
cached_network_image: ^3.2.1
shimmer: ^2.0.0
intl: ^0.17.0
device_info_plus: ^3.2.4
flutter_screenutil: ^5.5.3+2
flutter_local_notifications: ^9.7.0
flutter_native_timezone: ^2.0.0
carousel_slider: ^4.1.1
url_launcher: ^6.1.5
flutter_dotenv: ^5.0.2
hive: ^2.2.3
hive_flutter: ^1.1.0
flutter_launcher_icons: ^0.10.0

화면 비율 설정 (375, 812)

return ScreenUtilInit(
      designSize: const Size(375, 812),
      minTextAdapt: true,
      builder: (context, child) {
        return GetMaterialApp(
          debugShowCheckedModeBanner: false,
          title: 'cnubot',
          initialRoute: Routes.HOME,
          initialBinding: AppBinding(),
          getPages: AppPages.routes,
          theme: ThemeData(
            primarySwatch: Colors.blue,
          ),
        );
      },
    );

3. 코드리뷰

- 불필요한 용량을 차지하기 때문에 현재 필요없는 의존성(dependencies)들 제거하기

4. Merge

혁신 :: 혁신의 원천 7가지 (피터 드러커)

혁신이란?

혁신은 가치를 창출하는 것이다. 피터 드러커는 혁신을 “소비자들이 이제껏 느껴온 가치와 만족에 변화를 일으키는 활동”으로 정의하고 있다. 이러한 관점에서 보면 기존 자원이 가진 잠재력을 더 높여 더 많은 가치를 창출하는 것도 혁신이고, 없던 것에서 혹은 아주 형편없던 것에서 가치를 창출하는 것도 혁신이다. 이렇듯 넓은 의미에서 혁신은 가치 창출의 활동인 것이다.

혁신을 통한 가치 창출은 곧 이윤 창출로 이어지므로, 혁신은 기업 활동에서 필수 불가결한 요소이다.

혁신의 원천(sources of innovation) 7가지

- 비즈니스에 있어서 혁신은 천재의 반짝이는 영감으로부터 비롯되기도 하지만, 그 보다는 7가지의 혁신 기회에 대한 의식적이고 목적이 분명한 냉철한 분석으로 부터 비롯된다.

회사 또는 산업 내에 존재하는 4가지 혁신 기회

1. 예상 못한 사건(unexpected occurrences)

- 예상 밖의 사건은 혁신의 기회를 찾을 수 있는 가장 용이하고도 단순한 원천임

- 1930년대 초 IBM은 최초로 은행용의 현대식 계산기를 개발하였지만, 그 당시의 은행들은 새로운 장비를 구입하지 않았음

- IBM을 구한 것은 예상 밖의 사건이었는데, 은행과 달리 자금에 여유가 있었던 뉴욕 공공도서관을 필두로 한 도서관들이 그 기계를 구입하길 원했고 그에 힘입어 IBM은 100대 이상의 기계를 도서관에 판매할 수 있었음

- 15년 후 모든 사람들이 컴퓨터가 첨단 과학 작업을 위해 필요한 것으로 믿고 있었는데 기업들은 예상 외로 급료 대장을 처리할 수 있는 컴퓨터에 관심을 보였음

- 이에 IBM은 기존의 기계를 재설계하여 기업이 원하는 것을 구현하여 예상 밖의 성공을 거두었고 그 결과 5년 만에 컴퓨터 업계의 선두 주자가 되었음

2. 양립할 수 없는 부조화(incongruities)

- 기대와 결과 사이의 부조화 상황이 혁신의 가능성을 열어 놓을 수 있음

- 조선사들과 해운업체들은 20세기에 들어 50년 동안 노력한 결과 배의 속도를 높이고 연료소모를 줄이는 성공했지만, 해운업체들의 수익성은 더욱 악화되었음

- 그러나 문제는 고비용이 해상의 작업이 아니라 항구에서의 낮은 노동 생산성에 기인한다는, 즉 해운업에 대한 가정과 현실 사이의 부조화 상황에 있었다는 사실을 경영자들이 몰랐던 데 있었음

- 경영자들이 실제의 고비용 발생 원인이 낮은 노동 생산성이라는 점을 이해함으로써 혁신의 대상을 분명히 파악하였고, 항구에서의 생산성을 높일 수 있는 롤온(roll-on) 및 롤오프(roll-off) 선박, 컨테이너선이 개발되었음

- 이들 선박은 이미 30년 동안이나 철도 및 트럭 운송업체들이 사용하던 낡은 방식을 해운업체에 단순 적용한 것으로서 새로운 기술이 아닌 관점의 변경이었지만, 해운의 수익성을 높였고 해운업을 지난 20-30년 동안 주요 성장 산업 중 하나로 변모시켰음

3. 프로세스상의 필요(process needs)

- 오늘날 미디어라고 하는 것은 프로세스 니즈에 대응하여 1890년 경에 개발된 두 가지 혁신에 그 기원을 두고 있음

- 하나는 신문을 신속히 그리고 대량으로 만들 수 있게 한 Ottmar Mergenthaler의 라이노 타이프(자동 주조 식자기)이고, 다른 하나는 진정한 최초의 신문 발행자라고 할 수 있는 뉴욕 타임즈의 Adolph Ochs, 뉴욕 월드의 Joseph Pulitzer 및 William Randolph Hearst에 의해 발명된 사회적 혁신인 현대식 광고이었음

- 광고는 이윤을 마케팅에서 얻도록 함으로써 뉴스를 무료로 유통시킬 수 있도록 하였음

불필요한 과도한 결재 시스템, (수기시스템 제거)전산화 교체, 조직 내 불필요한 프로세스 제거&간소화

4. 산업 및 시장의 변화(industry & market changes)

- 산업 구조는 하루 밤 사이에도 변할 수 있는데 이러한 변화가 엄청난 혁신의 기회를 만들어 냄

- 대표적인 미국 기업의 한 예가 DL&J(Donaldson, Lufkin & Jenrette)라는 중개 회사의 성공에서 찾을 수 있음

- 이 회사는 세 명의 젊은이들에 의해 1960년에 설립되었는데, 이들 젊은이들은 기관 투자가들이 득세함에 따라 금융 구조가 바뀐다는 사실을 깨달았음

- 이들은 자본도 연줄도 없었지만, 그들의 회사는 증권 유통 수수료 분야로의 이동 과정에서 선두 주가가 되었고, 월스트리트에서 최고의 성과를 올린 기업 중 하나가 되었음

- 이미 기반을 다진 회사들은 자신들이 이미 확보하고 있는 것을 방어하는 데 집중하여 신규 진입자가 도전할 때 역공을 펼치지 않으려는 경향이 있음

- 또한 시장이나 산업 구조가 변할 때, 전통적인 산업의 선두 주자들은 급성장하는 시장 부문을 등한시함으로써 혁신자들이 오랫동안 내버려진 좋은 기회를 차지하게 됨

4차 산업혁명, IT, AR/VR, AI, 자율주행, 모바일

회사 밖의 사회적•지적 환경에 존재하는 3가지 혁신 기회

5. 인구통계학적 변화(demographic changes)

- 일본인들이 로봇 공학에서 앞선 것은 인구 통계학에 주의를 기울였기 때문임

- 1900년 경 즈음 선진국들의 모든 사람들은 출생률이 급저하하는 중에 교육 수요의 급증은 지속되고 젊은이들의 절반 이상이 고등학교 이후의 교육 과정을 밟고 있다는 사실을 알고 있었음

- 결과적으로 제조업에서 필요한 전통적인 블루 칼라 노동력이 감소했고 1990년 경에는 부족하기에 이르렀음. 모든 이들이 알고 있었지만 일본인들만이 그러한 인구 통계적 변화에 맞추어 행동함으로써 오늘날 로보트 공학에서 10년이나 앞서게 되었음

고령화, 저출산

6. 인식의 변화(changes in perception)

- "잔의 절반이 찾다"라는 것과 "잔의 절반이 비었다"라는 것은 동일 현상에 대한 같은 표현이지만 그 의미는 매우 다름

- 이러한 표현처럼 경영자의 인식 변화는 커다란 혁신의 기회를 제공하기도 함. 예를 들자면 지난 20년 동안 미국인들의 건강은 신생아 사망률, 노인들의 생존률, 암 발생률(폐암 이외의), 암 치료율 등으로 볼 때 전례 없는 속도로 개선되어 왔음

- 그렇지만 오히려 집단 우울증이 전국에 만연되었고, 전에 없이 건강에 대한 관심 또는 두려움이 확산됨으로써 갑자기 모든 것이 심각한 질병을 야기하는 것처럼 여겨졌던 것임(잔의 반이 비었다는 인식, 건강의 개선 지표 공개 -> 동시에 건강에 대한 관심과 두려움)

- 미국인들은 건강의 획기적 개선을 기뻐하기보다는 죽을 날이 얼마나 남았는지를 강조하는 것처럼 보였고,

- 이러한 관점이 새로운 건강 잡지 시장, 운동 기구, 건강 식품 등에서 많은 혁신의 기회를 창출해 내어 왔음

- 1983년에 가장 빠른 성장을 보인 미국의 기업은 실내 운동 기구를 제조하는 회사였음

7. 새로운 지식(new knowledge)

- 지식 기반의 혁신이야말로 기업가 정신의 수퍼 스타이지만, 모든 혁신들 중에서도 선행 시간(lead time)이 가장 김

- 새로운 지식의 출현에서 새로운 기술, 시장에서의 제품화로 이어지는 선행 기간이 역사 전반적으로 보면 50년 정도임. 또한 지식 기반 혁신은 한 가지 지식이 아니라 많은 다른 지식들을 필요로 함

- 지식 기반 혁신이 성공하기 위해서는 혁신을 가능토록 하는 데 필요한 여러 종류의 지식에 대한 주의 깊은 분석, 예정된 사용자의 니즈에 대한 사려 깊은 분석이 필수적이며, 이를 통해 지식 기반 혁신에 대한 관리가 가능해짐

혁신의 특징

이들 혁신 원천은 겹치기도 하며, 이들은 모든 혁신 기회의 절대 다수의 원인이 됨.

의도적이고 체계적인 혁신은 새로운 기회의 원천에 대한 분석에서 시작됨.

- 정황/환경(context)에 의존하는 기회의 원천들은 서로 다른 시점에서 서로 다른 중요성을 갖게 될 것이며, 다른 한편으로는 서로 관련성을 갖지 않을 수도 있음.

- 예컨데 인구통계학적 변화가 철강산업분야 혁신자들에게 별 관심을 끌지 못하고, 새로운 지식이 조세 관련법 변화에 따른 사회적 기구 혁신을 도모하는 사람들에게는 거의 관계가 없는 경우가 그것임

- 그러나 상황이 어떻든간에, 혁신자들은 모든 기회 원천(all opportunity sources)을 분석하여야 함.

혁신은 개념적인 측면과 인지적인 측면(conceptual & perceptual)을 모두 갖고 있기 때문에, 장래 혁신자들은 실제 산업으로 나가서 직접 보고, 질문하고 들어야 함…좌뇌와 우뇌의 동시 사용

- 성공적 혁신자들은 기회를 만족시키기 위하여 혁신이 무엇을 해야 하는가를 분석적으로 다루고, 그리고 밖으로 나가서 잠재적 사용자들의 기대, 가치 및 니즈를 연구조사함.

효과적인 혁신을 위하여, 혁신은 단순하고 집중되어야 함. 만일, 그렇지 못할 경우 사람들을 혼란시키게 됨.
- 혁신이 받을 수 있는 최고의 찬사는, “이것 참 알기 쉽고 명쾌하군! 왜 내가 그 생각을 못했지? 정말 간단해!”라는 말임.
- 새로운 사용자와 새로운 시장을 창출하는 혁신일지라도 특정하고 명쾌하며 주의깊게 설계된 적용을 위하여 제 3자로부터 감독/지시를 받아야 함

시스템의 혁신 사례 - 스테이크 덮밥 가게의 경영자의 실제 사례

문제

스테이크 덮밥 가게를 하는 경영자는, 스테이크를 굽는 직원들이 자주 스테이크를 태우는 현상을 목격했다. 경영자는 스테이크를 태우는 현상을 막아야 했다.

경영자는 이 문제의 원인을 일손의 부족이라고 단정지었다. 그래서 주방 직원 1명을 채용했다. 하지만 결과는 나아지지 않았다. 스테이크를 태우는 현상을 동일하게 발생했다.

경영자는 생각의 전환을 해서 문제의 원인을 직원이 아니라 조리 시스템에 있다고 생각하고, 조리도구(팬 등)를 새걸로 교체했지만 나아지지는 않았다. 

그럼 어떻게 이 문제를 해결했을까? 해당 가게의 스테이크는 두꺼워서 겉을 익혀도, 속도 어느정도 익혀야 하기에  조리 기술력이 필요했다.(속을 익히지 않으면 피가 아래로 새어나왔다.) 경영자는 태우지 않고 직원보다 2~3배의 양을 구울 수 있는 기술력이 되었지만 직원은 그렇지 못했다. 여기서 경영자는 

(1) 태우는 직원에게 책임을 묻는 방법

(2) 경영자가 직접 직원에게 스테이크를 잘 굽는 방법에 대한 기술력, 노하우를 직접 전수하는 방법

을 생각할 수 있겠지만, 경영자는 다음과 같이 어느 누가 오더라도 쉽게 조리할 수 있는 시스템을 설계하는 방법을 택했다.

해결

스테이크는 두꺼워야 식감이 좋았지만, 속도 어느정도 익혀야 하기에, 그 적정선을 맞추는 노하우와 기술력이 필요하기 때문에 직원들이 잘 태우는 문제가 있었다. 그래서 경영자는 다음과 같이 시스템을 변경했다.

(1) 식감을 잃지 않되, 직원들이 쉽게 스테이크를 조리할 수 있도록 스테이크의 두께를 적절히 줄였다. (레시피의 변경)

(2) 조리 마지막에 버터와 향신료를 추가하는 프로세스에 대해서 업무 부담이 컸다. 그래서 이 과정을 제거하고, 풍미를 살려줄 소스를 4개 정도 추가했다. (버터 비용이 비싸서 원가는 절감이 되었고, 조리 부담도 줄었다. 버터가 빠졌다고 해서 맛이 크게 달라지지 않았다.)

Tistory 스킨편집 :: 유명 스킨인 hELLO 스킨 편집하기 (사이드바 안보이는 문제 해결하기, 게시글 그리드 형태로 표시하기)

배경

https://pronist.dev/5

티스토리 유명 오픈소스 스킨인 hELLO 스킨을 사용하다가 보완해야할 점이 여러 개가 보여서, 스킨 편집 - html 편집을 통해 내 입맛에 맞게 수정하고자 했음.

스크린별로 보이는 화면을 아래 요구사항에 맞춰 사용자 경험을 더 좋게 만들기 위해 html, css를 편집하게 된 과정을 요약하여 공유하려고 한다.

요구사항

1. 웹 화면이 1400px 이하 일때, 사이드바를 가리고 1400px보다 커지면 사이드바를 표시함.

2. 한 화면에 더 많은 게시글을 표시하게 하기 위해 한 줄에 3개의 게시글이 표시되도록함.

3. 상단 네비게이션 우측에 Github, Youtube, Instagram, Kmong 등 외부  사이트 아이콘을 추가하고 링크를 걸어놓는다.

해결

1. 웹 화면이 1400px 이하 일때, 사이드바를 가리고 1400px보다 커지면 사이드바를 표시함.

개발자 도구 열기 단축키는 아래와 같습니다.

Mac : Option + Command + i
Windows : F12

개발자 도구를 열어, 사이드바가 닫혔을 때와, 사이드바가 열렸을 때를 비교해보니, 아래와 같았다. (스킨 편집에서 110번째 줄에 해당 요소가 있다.)

<aside id="__sidebar" class=""> // 사이드바가 닫혔을 때
<aside id="__sidebar" class="opened"> // 사이드바가 열렸을 때

html 상단의 script 태그에 아래의 코드를 추가하여, 스크린 사이즈가 변경될 때마다(window.onresize) 가로 사이즈를 검사해서 1400px보다 크면 사이드바를 표시하고(opened) 1400px 이하면 사이드바를 (remove) 안보이게 하였다.

<script>
  // html이 로드 되면 실행됨
  document.addEventListener("DOMContentLoaded", function(event) {
	// 사이드바 element를 변수에 저장함
	var element = document.querySelector('#__sidebar');
	
    // 스크린 사이즈가 변경되면 실행되는 함수
    function resize() {
      // 스크린 가로 사이즈가 1400px 보다 크면 사이드바를 표시함 (opened)
      if (window.innerWidth > 1400) {
          element.classList.add('opened');
      // 스크린 가로 사이즈가 1400px 이하이면 사이드바를 안보이게함
      } else {
          element.classList.remove('opened');
      }
    }
    // debounce : n초마다 검사해서 resize 함수를 실행할 경우 delay값을 설정함
    function debounce(func, delay = 0) {
      let timer = null;

      return function() {
          const context = this;
          const args = arguments;

          if (timer) {
              clearTimeout(timer);
          }

          timer = setTimeout(() => func.apply(context, arguments), delay);
      };
    }
    resize();
    // window.onresize = debounce(resize);
    
    // 스크린 사이즈가 변경되면 resize() 가 실행되도록 함수를 등록함
    window.onresize = resize;
  });
</script>

2. 한 화면에 더 많은 게시글을 표시하게 하기 위해 한 줄에 3개의 게시글이 표시되도록함.

스킨 편집 - html 편집의 826번째 줄의, <section> element의 data-mode 속성을 "grid"로 변경하여, 한 줄에 3개의 게시글이 표시되게 한다. (종류는 default, grid 등 여러 개가 있으니 자신의 블로그 컨셉에 맞는 방식을 사용하는 것이 좋을 것 같다) 

<s_list>
  <!-- <section class="list" data-mode="" data-image-mode=""> -->
  <section class="list" data-mode="grid" data-image-mode="">
  ...
</s_list>

grid안의 각 게시글에 대해서, 사진이나 글씨 높이, 폰트 등 설정은 html과 css를 수정해서 자신의 블로그에 맞게 수정할 수 있다.

3. 상단 네비게이션 우측에 Github, Youtube, Instagram, Kmong 등 외부  사이트 아이콘을 추가하고 링크를 걸어놓는다.

상단 우측에 공간이 비어서, Github, Youtube, Instagram, Kmong 외부 링크를 넣고자 하였다.

 <nav class="uk-navbar-container uk-navbar-transparent sticky" id="__nav" uk-navbar="">
  // 좌측 프로필 이미지
  <div class="left uk-navbar-left"><img class="profile lazyload" data-src="https://tistory1.daumcdn.net/tistory/3701876/attach/6ffb1d2275e243b9b79b6dba8762406c" data-sizes="auto" alt="상상하는 냥이" width="40" height="40" uk-toggle="target: #__sidebar; cls: opened"></div>
  // 타이틀 표시(처리의 개발 블로그)
  <div class="center uk-navbar-center">
    <h1 class="title">상냥한 IT 블로그</h1>
  </div>
  // 우측 아이콘, 링크 (Github, Instagram, Youtube, Kmong)
  <div class="right uk-navbar-right">
    <a href="https://github.com/CheolheeLee0"><i class="fab fa-github" style="font-size:28px; color:#000000; margin-right:16px;"></i></a>
    <a href="https://www.instagram.com/wks0968/"><i class="fab fa-instagram" style="font-size:28px; color:#C13584; margin-right:16px;"></i></a>
    <a href="https://www.youtube.com/@catveloper/shorts"><i class="fab fa-youtube" style="font-size:28px; color:#FF0000; margin-right:16px;"></i></a>
    <a href="https://kmong.com/gig/404740"><i class="fas fa-comment-dots" style="font-size:28px; color:#333333; margin-right:0px;"></i></a>
   </div>
</nav>

<a href=""> 태그로 링크를 걸었으며, <i> 태그의 class 속성에 아이콘 종류를 지정했다. style 속성에 아이콘 크기(font-size)와 색깔(hex)을 지정했다.

아이콘은 아래 링크에서 골라서 적용할 수 있다. (종류가 진짜 많다!)

https://www.w3schools.com/icons/fontawesome5_icons_brands.asp

느낀점

블로그 스킨을 html과 css를 수정해서 내 입맛에 맞게 수정한다는 점이 재미있었다. 예전에 공군에서 웹 개발 및 유지보수하면서 근무할 때 html, css, javascript를 공부했던 경험이 도움이 많이 되었던 것 같다. html, css, javascript를 공부해서 적용하면 내가 원하는 블로그를 커스텀화할 수 있는 부분이 좋은 것 같다.