반응형

Firebase의 data connect 를 백엔드로 정했습니다. 하지만 Postgres Sql인줄 알았는데,,, Graph ql 이더라구요. 

생소한 개념이라 공부를 시작했습니다. 

 

 

 

GraphQL 개요

 

GraphQL은 페이스북에서 2012년에 개발되었으며, 2015년에 오픈소스로 공개된 데이터 쿼리 언어 및 런타임 환경입니다. 주로 클라이언트와 서버 간의 데이터 요청 방식을 최적화하는 데 사용됩니다. REST API의 대안으로 인기를 얻었으며, 특정 데이터만 요청할 수 있는 유연성, 데이터 과다/부족 문제 해결, 효율적인 데이터 처리 등이 특징입니다.

 

GraphQL의 주요 특징

1. 클라이언트가 필요한 데이터만 요청 가능

REST API는 여러 엔드포인트를 호출해야 하는 반면, GraphQL은 단일 엔드포인트를 통해 필요한 데이터를 쿼리합니다.

예: GET /user 호출로 사용자 정보만 가져오는 대신, GraphQL에서는 한 번의 요청으로 사용자 정보와 관련 데이터를 모두 요청할 수 있습니다.

2. 타입 시스템(Type System)

GraphQL은 명확한 **스키마(Schema)**를 사용하여 데이터 구조를 정의합니다.

이를 통해 클라이언트와 서버 간의 계약(Contract)을 명확히 하고, 사전에 데이터 타입과 형식을 검증합니다.

3. 계층형 데이터 요청

GraphQL은 데이터 관계를 표현하기 쉽게 설계되어, 중첩된 데이터를 계층적으로 요청할 수 있습니다.

예: 사용자 정보와 사용자와 연결된 게시물 리스트를 한 번에 요청 가능.

4. 단일 엔드포인트

REST와 달리, GraphQL API는 단일 엔드포인트(예: /graphql)를 통해 모든 요청을 처리합니다.

요청의 종류(Query, Mutation, Subscription)에 따라 필요한 데이터를 제공.

5. 버전 관리 불필요

REST API는 버전 관리가 필요하지만(GraphQL은 v1, v2 등 필요 없음), GraphQL은 스키마 변경으로 새로운 필드를 추가하거나 수정할 수 있어 API의 변경에 유연합니다.

 

GraphQL의 구성 요소

1. 스키마(Schema)

GraphQL 서버에서 사용되는 데이터 구조와 쿼리를 정의한 청사진(정의서).

주로 **SDL(Schema Definition Language)**로 작성.

예:

 

type User {

  id: ID!

  name: String!

  age: Int

}

 

type Query {

  user(id: ID!): User

  allUsers: [User]

}

 

 

2. 쿼리(Query)

데이터를 읽어오기 위한 요청.

예:

 

 

query GetUser {
  user(id: "1") {
    name
    age
  }
}

 

 

 

위 요청으로 id가 “1”인 사용자의 nameage만 가져올 수 있습니다.

 

3. 변경(Mutation)

데이터를 생성, 수정 또는 삭제하기 위한 요청.

예:

 

 

mutation AddUser {
  addUser(name: "John", age: 30) {
    id
    name
    age
  }
}

 

 

 

4. 구독(Subscription)

데이터 변경 사항을 실시간으로 구독.

주로 WebSocket을 사용하여 실시간 데이터 처리를 구현.

예:

 

subscription {
  userAdded {
    id
    name
  }
}

 

GraphQL과 REST의 차이점

 

특징 GraphQL REST

  1. 데이터 요청 방식 클라이언트가 필요한 데이터 요청 서버가 고정된 데이터 제공
  2. 엔드포인트 개수 단일 엔드포인트(/graphql) 여러 엔드포인트(/users, /posts)
  3. 데이터 과다/부족 문제 없음(필요한 데이터만 요청 가능) 있음
  4. 버전 관리 불필요(스키마로 관리) 필요
  5. 관계형 데이터 처리 계층형 데이터 요청 가능 여러 요청으로 처리 필요

 

GraphQL의 장점

1. 유연성

필요한 데이터만 요청 가능하여, 네트워크 대역폭을 줄이고 성능을 최적화할 수 있음.

2. 단일 엔드포인트

여러 API를 호출할 필요 없이, 하나의 엔드포인트에서 모든 요청을 처리.

3. 스키마 기반 개발

명확한 스키마로 클라이언트와 서버 간 데이터 교환을 예측 가능하게 함.

4. 버전 관리 불필요

필드를 추가하거나 삭제하여 변경 사항을 쉽게 반영 가능.

5. 강력한 커뮤니티

GraphQL은 페이스북을 비롯한 많은 기업에서 채택하며, 점점 더 많은 오픈소스 라이브러리와 도구가 개발되고 있음.

 

GraphQL의 단점

1. 복잡성 증가

REST API에 비해 초기 구현과 설정이 복잡할 수 있음.

스키마 설계와 유지보수 필요.

2. 캐싱 어려움

REST API는 HTTP 캐싱을 쉽게 사용할 수 있지만, GraphQL은 특정 쿼리에 대해 캐싱이 어렵거나 추가 도구(Apollo 등)가 필요.

3. 오버헤드

쿼리를 처리하는 런타임 환경(GraphQL 서버)이 추가되면서 약간의 성능 손실이 발생할 수 있음.

 

GraphQL의 주요 도구 및 라이브러리

1. 서버 구현

Apollo Server: Node.js 기반의 GraphQL 서버.

Express-GraphQL: Express.js와 통합된 GraphQL 서버 라이브러리.

Hasura: GraphQL API를 자동 생성해주는 서비스.

Nexus: 코드 기반 스키마 정의를 지원.

2. 클라이언트 라이브러리

Apollo Client: 강력한 GraphQL 클라이언트.

Relay: Facebook에서 만든 GraphQL 클라이언트.

urql: React와 호환 가능한 GraphQL 클라이언트.

3. 도구

GraphiQL: 브라우저 기반 GraphQL IDE.

Postman: GraphQL 지원을 포함한 API 테스트 도구.

Altair: GraphQL 쿼리를 테스트할 수 있는 도구.

 

GraphQL 사용 사례

1. 페이스북

GraphQL은 페이스북의 뉴스 피드에서 유저 정보와 관련 데이터를 효율적으로 가져오기 위해 개발됨.

2. GitHub API

GitHub은 REST API와 함께 GraphQL API를 제공하여 사용자 지정 쿼리를 지원.

3. Shopify

GraphQL을 통해 전자상거래 플랫폼의 유연한 데이터 요청과 복잡한 데이터 구조 처리.

4. 트위터, 넷플릭스, Airbnb 등

대규모 데이터를 다루는 서비스에서 GraphQL 사용 증가.

 

GraphQL을 배울 때 참고 자료

공식 문서: https://graphql.org/

Apollo Docs: https://www.apollographql.com/docs/

GraphQL Korea: https://graphql-kr.github.io/

YouTube 강의: 다양한 GraphQL 강좌 및 튜토리얼.

GitHub: GraphQL 관련 프로젝트 및 샘플 코드.

 

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

 

반응형
반응형

 

Bloc 상태관리

 

 

Bloc는 flutter의 상태관리 패키지 중 하나입니다.. 좋아요는 6400개 

 

https://pub.dev/packages/flutter_bloc

 

flutter_bloc | Flutter package

Flutter Widgets that make it easy to implement the BLoC (Business Logic Component) design pattern. Built to be used with the bloc state management package.

pub.dev

 

 

국내에서는 Getx가 많이 쓰이고 있지만, 해외에서는 Bloc가 더 많이 쓰이는 듯 합니다.. Flutter 해외 유투버 영상을 많이 찾아보고 있는데.. Bloc 찬양을...ㅎㅎ 그래서 현재 제 프로젝트는 Getx이지만 하반기에 Bloc로 리팩토링을 해보려고 합니다. 

 

 

Bloc의 장점?

 

Bloc의 장점은 로직, 화면, 이벤트를 각 클래스로 나눠서 관리합니다.  

Bloc , Event, State  각 클래스 안에 세부적인 상태를 나누게 됩니다. 예를들어 Todo에서 Event에는 할일 추가, 할일 업데이트, 할일 삭제등이 있을 것이고, State에는 앱이 처음 실행되었을 때 db에 있는 데이터를 받아오는 상태, 삭제 후 리스트가 삭제 되는 상태 등이 있습니다. 

 

간단한 앱을 만들 때는 Bloc는 많은 코드로 불편함을 느낄 수 있지만, 앱이 성장함에 따라 여러 기능들이 복잡하게 이루어 질 때 Bloc는 아주 작은 단위의 기능들로 구성이 되어 있으니 유지 보수에 편하게 됩니다. 

 

 

Bloc의 단점?

 

아무래도 세세한 작은 기능을 따로 클래스로 관리를 하다보니 코드의 양이 다른 상태관리 패키지보다 2~3배는 더 많게 느껴집니다. 

Flutter를 배우는 사람들은 소규모 스타트업이나, 1인 개발자가 많은데 Bloc는 관리해야 하는 코드의 양이 많다는건 정말 부담되는 일입니다. 

 

그럼에도 Bloc를 배우고자 하는 이유는?

 

저는 1인 개발자이지만 Bloc의 정형화 된 사용 방법에 큰 매력을 느꼈습니다. 지금 제가 짜놓은 Getx 코드는 다른 개발자분이 보시면.. 기겁을 할 수 있습니다. 정말 이리저리 어지러운 코드입니다. 하나의 컨트롤러에 여러개의 페이지에 할당 하고 있어서 이 코드를 만든 제가 아니고서야 유지보스는 정말 힘든일일 것입니다. 

 

제가 하고자 하는 서비스의 기능들이 앞으로 계속 추가가 된다면 유지보수가 새로운 기능을 만드는 것보다 더 중요하게 생각됩니다. 서비스의 안정성이 유저 확보에 가장 중요한 부분이니까요. 

Bloc의 단점인 코드의 양은 GPT가 충분히 해결 해줄 것이라 생각됩니다..!!

 

 

 

반응형
반응형

 

 

Flutter 로 Supabase 를 이용해서 회원가입 로직을 구현 해보았습니다. 

 

 

문제 해결 목표 

원래 목표는 소셜 로그인 구글과 애플을 안드로이드, IOS 에 실행시키는 것이 목표였습니다. 

하지만 결국 email - password로 왔네요. 2월에는 email- password로 하고 이후에 다시 소셜 로그인을 추가를 할 예정입니다. 

 

 

 

문제 해결 과정에서 배웠던 개념들 

 

 

1. 안드로이드 - Mainifest , IOS - Inpo.Plist

 

안드로이드와 IOS 의 권한 부분에 대해서 배웠습니다. 

Flutter는 하나의 코드로 여러 플랫폼 구동이 가능한 프레임 워크이지만  결국 Flutter는 네이티브가 아닙니다. 

여기서 네이티브는 안드로이드, IOS  같은 OS 개념입니다. 

 

결국 각 OS에 맞게 권한 설정을 해줘야 합니다. 이러한 부분은 위에 있는 안드로이드 -Mainifest, IOS - Inpo.Plist 파일에서 설정 가능합니다. 

 

2. Deeplink 

위에 있는 각 OS 권한 설정에 연장선에 있는 기능입니다. Deeplink는  A앱에서 링크를 통해 B앱의 특정 페이지로 갈 수 있는 기능을 의미합니다. 네이버 블로그앱(A앱)에서 맛집을 검색하고 그 맛집을 가기 위해 주소를 클릭하면 네이버 지도앱(B앱)으로 넘어가는 경우가 바로 Deeplink 기능입니다. 

 

Supabase에서는 Email 로그인시 Email confirm 링크, 소셜로그인에서는 로그인 성공 후 돌아오는 페이지 설정 등등에 쓰이고 있습니다. 

 

Deeplink의 구성은 scheme / host/path 로 이루어져 있습니다. 

scheme는 해당 앱의 특성을 잘 나타내게 만들면 됩니다. 저는 mymoneytrackerapp으로 설정했습니다. 

 

각 OS에 권한을 부여할 때 는 scheme만 입력해도 그 scheme에 따라서 host/path 페이지도 인식하게 됩니다. 

 

 

안드로이드 구성 

  <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <!-- Accepts URIs that begin with YOUR_SCHEME://YOUR_HOST -->
        <data
          android:scheme="mymoneytrackerapp"
        
           />
      </intent-filter>

 

IOS

	<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleTypeRole</key>
    <string>Editor</string>
    <key>CFBundleURLSchemes</key>
    <array>

      <string>mymoneytrackerapp</string>
    </array>
  </dict>

 

 

supabae 

각 OS 별로 scheme를 인식해서 유저가 회원가입 신청 후 confirm 이메일 링크를 클릭하면 다시 해당 앱으로 돌아와 로그인 진행이 완료됩니다. 

 

mymoneytrackerapp:://redirect/main?firstLogin=true

를 deeplink로 만들었습니다. 

 

권한 설정을 할 때는 scheme만 입력해도 됩니다. 

 

scheme : mymoneytracerapp:// 

host :  redirect

pat:  main

query : firstLogin=true

 

 

3. 안드로이드 SHA-1 보안코드 기기와 구글플레이가 다르다. 

 

supabase 로그인을 진행하면서 IOS에서는 작동하는데 안드로이드에서는 로그인이 안되는 문제를 겪었습니다. 

그 이유는 다음과 같습니다. 

 

구글 클라우드 API를 통해서 안드로이드 Oauth 만들 때 SHA 1 보안 코드가 필요합니다. 

안드로이드는 앱 자체적으로 SHA 1  보안 코드를 가지고 있고,  앱이 구글 플레이에 정식 등록이 되고 나면 생기는 SHA 1 보안코드가 있습니다. 

 

즉 개발 할 때는 앱 자체적인 SHA 1 로 로그인 기능을 테스트 하고, 구글 플레이 출시 이후에는 구글 플레이 콘솔 페이지에 있는 SHA 1 보안코드로 다시 등록해야 유저가 로그인 구현이 가능해집니다. 

 

 

4. 회원 정보 관리 정책 정하기 

 

기존 기획과는 다르게 각 플랫폼 별 백업 시스템을 구현하는게 아니라 supabase 를 이용해서 각 플랫폼에게 동일한 백업 서비스를 구현하는게 좋다고 판단했습니다. 그래서 본의아니게 고객님 정보를 제가 관리를 해야 합니다.

 

회원 가입 할 때 어떠한 정보를 받을지, 계정삭제는 어떻게 진행 할지 등등 이런 고민을 자연스럽게 하게 되네요. 

아무래도 유저가 사용하는 매출과 지출의 데이터는 꽤 민감하기 때문에 여러 컴플레인에 대해 대비를 해야 할 것 같습니다. 

 

결론

 

회원가입은 빡세다

 

반응형
반응형

 

 

이 글은 절대 전문적인 글이 아닙니다. 

그저 제가 공부하면서 이해한 내용을 적은 글입니다. 

틀린 부분이 있다면 언제든 지적해주세요. 


 

DB를 만들어야 한다면 먼저 고민해야 할 것이 있습니다. 

 

1. 어디에다 저장 할 것인가? 

 

구현하고 싶은 앱에 따라서 사용자의 데이터를 기기 내부에 저장 해야 할지, 외부 서버에 저장을 해야 할지 고민해야 합니다. 

우리가 흔히 사용하고 있는 네카쿠라배 와 같은 앱들은 사용자의 데이터를 외부 서버에 저장을 합니다.

기업 정책에 따라  자체적으로 서버를 운영하는 네이버도 있고, 다른 회사의 서버를 빌려서 운영하는 카카오 같은 기업도 있습니다. 

 

보통의 IT회사들은 자체적으로 서버를 운영하기 보다는 AWS와 같은 클라우드 업체의 서버를 빌려서 운영하고 있습니다. 

 

하지만 무조건 외부 서버를 이용하는게 답은 아니라고 생각합니다. 

간단한 계산기, Todo어플은  기기 내부에 저장해도 사용자는 이해 할테니까요. 

 

 

 

2. 어떤 DB를 사용 할 것인가?

 

AWS클라우드 업체를 이용하더라도 단순히 컴퓨터 저장 공간을 빌리는 것이기 때문에 해당 서버를 운영하는 
DB를 선택을 해야 합니다. 

 

서버= 저장 공간

DB= 저장하는 방법

 

이라고 생각하시면 됩니다. 

 

쉽게 생각하시면 집안에 있는 

 

냉장고= 서버

냉장고를 정리하는 나만의 방법= DB 

 

DB 데이터를 정리하는 방법은 여러 종류가 있지만 큰 흐름에서는 딱 두가지로 나눕니다. 

 

관계형인가 No관계형인가 입니다. 

 중요한 핵심은 SQL을 사용하느냐 사용하지 않느냐의 차이입니다. 

 

SQL은 컬럼과 로우를 통해서 쌓은 데이터를 쿼리문을 이용해서 운영하는 방식입니다. 굉장히 정형화되어 있습니다. 우리가 흔히 사용하는 엑셀을 SQL이라고 생각하시면 됩니다. 엑셀을 열면 컬럼과 로우에 값을 입력해서 여러 수식을 사용해서 데이터를 관리합니다. 엑셀은 이쁘게 만들기가 어렵습니다.  이미 컬럼과 로우가 정해져 있어서 그 틀 안에서만 사용이 가능합니다. 

 

NoSQL은 기존의 SQL의 단점을 보완하기 위해 만든 DB입니다. 대표적으로 파이어베이스가 NoSQL입니다. 이것은 엑셀과 다른 파워 포인트로 생각하시면 좀 쉽습니다. 파워 포인트는 각각의 페이지에 알맞는 내용을 담습니다. 목차 페이지에는 목차 관련 내용이 들어가고 본문 페이지에는 본문 관련 내용이 들어갑니다. 이러한 방식을 다큐먼트 방식이라고 합니다. 

파워 포인트는 만드는 사람마다 각자만의 특성이 묻어나옵니다. 이쁘게 만드는 사람도 있고, 페이지를 최소화 하는 사람도 있고,3D입체형으로 만드는 사람도 있습니다.  이렇게 엑셀과는 다르게 표현 할 수 있는 방식이 넓은게 특징입니다. 

 

SQL = 엑셀 

NoSQL= 파워포인트 

 

 

 

 

3.그래서 뭐가 좋은데?(개인적인 의견 :수파베이스)

 

저는 수학을 못하는 찐 문과입니다. 하지만 숫자는 좋아합니다. 숫자는 곧 데이터입니다. 아래는 DB 랭킹을 보여주는 사이트 입니다. 

https://db-engines.com/en/ranking

 

DB-Engines Ranking

Popularity ranking of database management systems.

db-engines.com

 

상위 랭킹들이 관계형 DB 입니다. 그만큼 많은 사람들이 사용하고 있고  정보도 많고, 관련 서비스의 수요가 높다는 의미이기도 합니다.  

비지니스적인 관점에서 봤을 때 제가 관계형DB를 사용해야 후에 관련 서비스를 쉽게 받을 수 있다는 생각이 들었습니다. 

 

대부분의 Flutter  입문 책은 외부 서버 데이터 연동시에 파이어 베이스를 사용합니다. 그래서 대부분이 비전공자분들이 그 책을 읽고 Flutter-파이어베이스를 교과서처럼 생각하시는 것 같습니다. 

 

저도 처음에는 파이어베이스를 공부를 했으나 DB를 공부하다 보니 결국 관계형 DB를 고집하고 있습니다. 

그래서 찾아낸 수파베이스입니다. 아직 베타서비스이긴 하지만 PostgresSQL을 지원하고 있습니다. 관계형DB를 배우신 개발자라면 쉽게 익힐 수 있는 서비스입니다. 

 

4.NoSQL DB는 안좋은건가?

 

절대 아닙니다. NoSQL  기존 SQL  단점을 보완하기 위해 나온 것입니다. 몇 해 전 부터 IT업계의 AI 기술들이 속속 개발되고 있습니다. 관련 빅데이터를 처리 할 때는 NoSQL이 새로운 답안이 될 수도 있습니다. 하지만 저는 NoSQL을 사용해서 그럴 깜냥이 못됩니다. NoSQL은 SQL  보다 역사가 짧고, 기술 난이도가 높습니다.  예를 들어 서비스 하고 있는 앱에서 이벤트를 진행 합니다. 특정 조건의 유저를 찾아야 할 때 SQL 은 쿼리문으로 간단히 찾아 낼 수 있습니다.  하지만 NoSQL 은 특정 조건이 무엇이냐에 따라서 간단히 찾아 낼지 확인하기가 어렵습니다. 

 

제가 파이어베이스를 포기한 이유도 로그인 인증 , 연동 등등 구현하는 것은 쉽지만, 운영적인 측면에서는 꽤 도전적인 선택이라고 생각했기 때문입니다. 

 

5. 정리

 

비전공자분이 DB를 선택해야 한다면 저는 관계형DB를 배우시라고 추천드립니다. 백엔드 개발자분 중에서 SQL은 기본으로 하시고 NoSQL을 잘하시는 분은 계십니다만 SQL은 모르고 NoSQL만 잘하는 분은 잘 없습니다. SQL을 하셔야 주변에 쉽게 도움을 받으실 수 있습니다. 

 

 

 

반응형
반응형

 

코딩을 하면서 나는 그동안 세상을 단순하게 산 것 같았다. 

 

로그인, 회원가입 관련 서비스들이 모두 다 똑같은 것이라는 생각을 한 것이 그것이다. 

 

스타트업에서 근무 했을 때도, 회원가입- 로그인 로직은 어려웠다. 

 

이번에 supabase를 공부할 때 드디어 회원가입- 로그인에 관한 내용을 조금이나마 이해 할 수 있었다. 

 

그 중에 Oatuh2 에 대해 적어보려고 한다. 

 

 

Oauth2란?

 

 

기존에 이메일 로그인 방식, 그리고 여러 서비스의 API를 연동해서 유저의 정보를 공유하는 방식은 꽤 위험했다. 

 

A라는 작은 스타트업이 페북과 같은 대형 서비스 API를 가져오는 과정에서 페북에 있는 유저들의 중요한 개인정보도 가져왔다. 

 

해커들은 A 스타트업을 공격하면 쉽게 해당 유저의 중요한 개인 정보를 가져 올 수 있었다. 

 

이러한 위험한 상황을 막고자 나온 것이 Oauth 개념이다. 1버전은 모바일에 관해서 큰 오류가 있었고 2012년 Oauth2가 나오면서 

 

널리 사용하게 되었다.

 

즉 Oauth2 는  우리가 흔히 사용하고 있는 소셜 로그인의 근간이 되는 기술이다. 

 

Oauth2를 쉽게 정의 하면 "웹사이트의 정보에 접근 권한을 부여하는 것" 이다. 

 

기존에는 유저의 정보를 직접 내주었다면 지금은  유저의 가벼운 몇몇 정보를 조회까지만 가능 한 것이다. 소셜로그인을 제공하는 서비스들은 일단 대형서비스이다. Google, Apple, Githup,Meta 등등 보안과 관련해서는 일반 회사와 수준이 다를 것이다. 그렇기에 대형 서비스들에 가입 되어 있는 유저들의 가벼운 정보를 쉽게 접근 할 수 있다. 유저의 Email, 생일, 남녀유무, 등등이 그것이다. 

 

작은 스타트업이나, 개인적인 서비스를 진행하고 있는 개발자들에게는 해당 유저를 특정 지을 수 있는 정보만 있어도 충분하다. 

 

 

Oauth2 의 구성

 

Oauth2의 구성은 다음과 같다. 

 

구글로 예를 들자면 

Resource Owner - 유저

Client - 나의 서비스

 

Authorization Server - 구글 인증서버

Resource Server - 구글 API 서버

 

Oauth2의 진행 방식 

 

 

1. Client인 내 서비스가 유저에게 로그인 요청을 한다. 

2. Resource Owner인 유저는 로그인을 진행한다. (소셜 로그인)

3. Client인 내 서비스는 해당 정보를 가지고 Authization Server 인 구글 인증서버에   인증을 요청한다. 

4. Authization Sever는 Client인 내 서비스에게 해당 유저의 토큰을 발행한다. 

5. Client인 내 서비스는 해당 유저의 토큰을 들고 Resource Server 인 구글 API 서버에게 해당 유저의 정보를 요청한다. 

6. Resource Server인 구글 API 서버는 해당 토큰을 확인하고 해당 유저의 정보를 제공한다. 

 

 

 

Oauth2 구글 로그인을 통해서 해당 유저의 닉네임과 프로필 사진을 받아올 수 있다. 

 

 

 

 손으로 끄적일 때가 머릿속에 오래 남는 나

 

 

 

 

 

 

출처 

https://hudi.blog/oauth-2.0/

 

OAuth 2.0 개념과 동작원리

2022년 07월 13일에 작성한 글을 보충하여 새로 포스팅한 글이다. OAuth 등장 배경 우리의 서비스가 사용자를 대신하여 구글의 캘린더에 일정을 추가하거나, 페이스북, 트위터에 글을 남기는 기능을

hudi.blog

https://velog.io/@seeh_h/OAuth-%EC%9B%90%EB%A6%AC-%EB%9C%AF%EC%96%B4%EB%B3%B4%EA%B8%B0

 

OAuth 원리 뜯어보기

서비스 개발을 하다 보면 소셜 로그인 기능을 한 번쯤 구현해 보게 되는데요. 요즘에는 대부분 서비스가 제공하는 것 같습니다. 소셜 로그인의 근간이 되는 기술인 OAuth 기술 스펙에 대해 살펴보

velog.io

 

반응형
반응형

 

GPT는 무엇인가?

 

 

Open AI라는 스타트업에서 개발한 채팅형 인공지능 프로그램이다. 

내 질문에 답을 주는 참 똑똑한 친구이다. 

 

 

 

 

왜 사람들은 GPT에 열광할까?

질문에 답을 주는 프로그램.. 이게 정말 중요한 핵심이다. 

 

우리는 그동안 모르는 정보를 인터넷에서 검색을 통해 얻었다. 

 

이러한 행동을 "구글링" 이라고도 한다. 

 

검색 포털 사이트에서 원하는 키워드를 검색하면 관련된 정보가 나오는 방식이다. 

 

문제는 수 많은 정보들이 인터넷에 있다 보니 내가 원하는 정보를 얻기까지 이곳저곳을 돌아다녀야 한다는 것이다. 

 

결국 시간이 든다. 시간은 비용이다. 

 

GPT는 내 질문에 답을 빠르게 준다. 그 답은 GPT가 수 많은 데이터를 학습하고 사람들에게 선호도가 높은 답을 골라서 준다. 

 

이러면 내가 원하는 정보일 확률이 더 높아진다. 

 

 심플하고 나름 높은 정확도를 지닌 검색 포털이 생긴 것이다. 

 

그 결과 베타버전으로 출시한 지 3개월 만에 사용자가 1억 명을 모았다. 이 기록은... 앞으로 깨질 수 있을까..? 싶을 정도로 대단하다. 

 

 

 블로그 수익?

 

먼저 블로그 수익이 일어나는 과정을 알아봐야 한다. 

 

1. 블로거(블로그를 운영하는 주인) 가 일상생활이나, 자기가 잘 아는 분야에 대한 정보를 수집한다. 그 정보를 정리해서 자신의 블로그에 글을 공유한다. 

 

2. 그 정보가 도움이 되었다고 느끼는 사람들이 해당 블로그에 구독을 한다. 주기적으로 그 블로그에 방문하게 된다. 

 

3. 블로거는 자신의 블로그에 많은 사람들이 유입이 되는 것을 확인한다. 그러면 자신의 블로그에 관련된 "상품"이나 "서비스"를 판매한다.  또는 기업, 기관에서 협찬을 받기도 한다. 

 

 

4. 블로그내 페이지에 배너 광고를 올려서 수익을 얻는다. 

 

 

블로그 수익의 핵심은?

 

수많은 블로그가 있지만 많은 사람들에게 영향을 미치는 블로그들이 있다. 흔히 파워 블로그라고도 한다. 

그러한 파워 블로그들은 확실히 남들과 다른 핵심 콘텐츠들이 있다. 정보의 정확성도 아주 뛰어나기도 한다. 

 

즉 다른 사람들과의 차별점이 "반드시,무조건" 있다는 것이다. 

 

남들과 같은 그저 그런 블로그라면 많은 사람들이 그 블로그를 방문할까..?

 

 

그렇지 않을 것이다..

 

 

GPT를 이용한 블로그 수익은 가능한가?

 

 

GPT가 단시간내에 엄청난 사용자를 만들어 냈다. 그리고 유튜브에 GPT로 블로그 수익 관련 내용들이 넘쳐나기 시작했다. 

 

방법은 간단하다. 

 

1. 여러 분야의 정보를 GPT에게 물어본다. 

 

2. GPT가 알려준 정보를 토대로 블로그 글을 작성한다. 

 

 

끝이다... 

 

나도 할 수 있으면.. 너도 남도 다 할 수 있다. 

 

지금이야 무지막지한 생산성으로 수익을 얻을 수 있다고 생각한다. 

 

하지만 곧 위와 같은 작업을 하는 사람들이 많아지면 많아질수록 블로그들의 정보 수준과 콘텐츠들은 동일해질 것이다. 

 

더 깊게 생각해보면 사람들은 정보를 블로그에서 찾는 게 아니라 GPT에서 찾을 것이다. 

 

사람들이 블로그를 방문하지 않는다면 블로그를 통한 수익은 얻을 수 없다. 

 

 

이게 내 결론이다. 

 

끝.

 

 

 

 

반응형
반응형

 

챗 Gpt가 대박났다. 

 

3개월만에 이용자 1000만 돌파를 기록했다. 

이 기록은 얼마나 많은 사람들이 이 서비스에 만족하고 있는지를 잘 나타내준다. 

 

챗 GPT를 이용하기 위해서는 홈페이지에 접속해야 한다. 구글링이 익숙한 나로써는 불편한 감이 있었다. 

 

그러던 중.. 크롬 확장프로그램 하나를 발견했다... !!!

 

 

이름 부터 예사롭지 않다. 

 

구글을 위한 Chat GPT

 

바로 추가했다..!

 

 

옵션을 설정 할 수 있다. 

 

언어도 한국어 지원이 된다. 바로 눌렀다. 

 

그리고 구글 검색을 해봤다. 

 

 

 

오른쪽에 챗 GPT 검색 내용이 나오고 있다...!!! 

문제는 기본언어를 한글로 해놨더니 ... 좀 느리다.. 

다시 영어로 바꾸어 주었다 ^^/

 

 

구글링이 좀 더 편해질 것 같다!

반응형
반응형

 

어플을 만들 때 설계를 한다. 

 

코딩을 이제 막 시작한 나로써 참 어렵다. 

 

이러 이러한 기능을 넣고 싶다고 해도 

 

그 기능을 만들기 위해서 어떠한 함수가 필요하고 변수가 필요한지 잘 모르기 때문이다. 

 

그렇기 때문에 내가 설계하고 있는 어플들은 조금씩 부족함이 있다. 

 

 

오늘 승민님과의 스터디에서 원가계산기 설계부분에서 

 

재료를 언제 파이어 베이스에 놓을 것인지 이야기를 했다. 

 

난 단순하게 파이어 베이스를 사용하면 다 될 줄 알았지만 그게 아니었다. 

 

데이터의 저장 시점이 텍스트 필드의 입력 하는 순간인지, 저장 버튼을 누르는 순간인지 

 

이런 사소한 부분도 설계에 포함시켜야 한다. 

 

이런 이야기도 Hive 데이터 베이스를 좀 만져봐서 이해가 가기 시작했다. 

 

코딩 하면 할 수록 겸손해지는 것 같다. 

 

 

그리고 챗 GPT 이야기도 했다. 최근 챗 GPT 가 개발업계에서 핫하다. 

 

챗 GPT는 Open AI 라는 회사에서 개발한 채팅형 인공지능 검색 프로그램이다. 

 

채팅창에 질문을 하면 그 질문의 맥락을 이해하고 답을 준다. 

 

미국의 초등고 학생들은 숙제를 챗 GPT로 하고 있다고 한다........... 

 

해당 기술은 마이크로 소프트 MS의 투자로 엄청난 성장을 이뤘고, 그 프로그램 사용 독점권이 MS에게 있다. 

 

검색의 방법이 기존 웹 기반에서 챗 기반으로 바뀌고 있는 현장에 있는 듯 하다. 

 

관련 기사이다. 

 

챗 GPT 검색엔진 나온다...20년 구글 아성 흔들리나 - 아시아경제 (asiae.co.kr)

 

챗 GPT 검색엔진 나온다...20년 구글 아성 흔들리나

마이크로소프트(MS)가 검색엔진 빙에 '챗 GTP'를 적용한다고 밝히자 검색시장이 달아오르고 있다. 일각에선 사람처럼 똑똑한 AI로 구글의 독점을 무너뜨릴 것이라고 전망한다. 20여년간 세계 1위

www.asiae.co.kr

 

 

 

코딩을 시작하니 디지털 세상의 흐름이 조금씩 느껴진다. 

 

왜 난 이제야 코딩을 시작했을까 아쉬움이 남는다. 

반응형
반응형

[객체지향] Object-Oriented Programming 핵심 개념의 이해 — Peter의 우아한 프로그래밍 (tistory.com)

 

[객체지향] Object-Oriented Programming 핵심 개념의 이해

배경 데이터 흐름(Flow)에 기반한 절차지향적 프로그래밍 방법은 복잡한 로직을 갖는 큰 규모의 소프트웨어 개발에는 적합하지 않습니다. 하드웨어 성능이 폭발적으로 성장하면서 요구되어지는

gracefulprograming.tistory.com

(219) [10분 테코톡] 🍟 웨지의 OOP - YouTube

 

 

많은 글과 영상을 보고 객체지향을 공부했습니다만 머릿속에 남는건 위 두가지 입니다. 

 


 

Dart는 객체지향언어

Dart는 객체지향언어이다. 그래서 C언어, JAVA 언어를 배웠던 개발자라면 Dart는 쉽게 배운다. 

하지만 나는 Flutter, Dart가 나의 첫 개발언어이다. 기존에 부가세 계산기를 만들 때에는 클래스도 없이 

변수들로만 선언해서 코드를 짰다. 어찌어찌 돌아가고는 있지만 이것보다  복잡한 어플을 만들 때에는 객체지향 개념이 필요하다. 

 

자기 계발서를 읽다 보면 큰 문제보다 작은 문제부터 해결하라는 조언이 많다. 

 

 

객체지향은 주어진 문제를 작은 문제들로 쪼개고 작은 문제들을 하나씩 해결해가면서 큰 문제들을 해결하는 바텀업 방식이다. 

 

 

 

객체지향에서 중요한 개념들이 있다. 

1. 추상화 - 객체와 실제 물건의 기준

2. 캡슐화  - 클래스의 책임분담

3. 상속  - 다형성

 

 

객체지향의 중요한 세 가지 개념

 

1. 추상화 

피카소의 위 작품은 황소를 자세하게 관찰하고 황소 고유의 특성만을 남기는 프로세스이다. 

이게 바로 추상화의 핵심이다. 마지막 8번째 사진을 보면 황소 고유의 특징만 남겨 놓았다. 

이 사진으로 모든 설명이 된다. 

 8번 황소는 class, 1번 황소는 객체

이렇게 외우면 쉬운 것 같다. 

 

위 배민영상에서 나온 치킨집 배달로  설명을 하자면 우리는 치킨을 먹고 싶으면 치킨가게라고 생각을 먼저 하게 된다. 이때 떠오른 첫 번째 "치킨가게"라는 추상된 개념이 바로 class이다.  그러면 어느 치킨가게를 먹어야 할지 고민을 하게 된다. BHC? 굽네? 배민랭킹맛집?  특정된 가게들이 바로 객체가 된다. 

 

추상화의 가장 큰 장점으로는 확장성이다.  위에 언급한 굽네치킨을 class로 만들게 되면 굽네는  튀긴 치킨을 팔지 않는다. 즉 튀긴 치킨에 관한 주문을 받을 수 없다. 

튀긴 치킨의 주문을 받기 위해서는 새로운 class가 필요하게 된다. 

 

하지만 추상적인 개념 "치킨가게"는 다르다.  

구운 치킨, 튀긴 치킨, 삶은 치킨, 차가운 치킨 등등 온갖 종류의 치킨을 아우를 수 있다.

 

 

2. 캡슐화 : 클래스의 책임분담

 

보통은 캡슐화라고 나오지만, 개인적으로 책임분담이라는 용어가 더 어울리는 듯하다. 

위 치킨가게라는 추상된 개념으로 클래스를 만들었다. 

 

보통의 치킨가게에서는 아래와 같은 일이 매일 일어난다. 

 

1. 재료를 손질한다.

2. 주문을 받는다. 

3. 닭을 튀긴다. 

4. 배달을 간다. 

 

 

그리고 만약 사장 혼자서 운영하는 1인 매장이라면 하루에 팔 수 있는 매출의 양이 최대 100만 원이었다.

 

1인 사장은 더 많은 매출을 올리고 싶다. 그래서 직원 3명을 고용하고, 배달업체를 사용하기로 했다. 

 

직원 1은  재료를 손질한다.

직원 2는 주문만 받는다. 

직원 3은 닭만 튀긴다. 

배달대행업체가 배달을 한다. 

사장은 "치킨가게"가 잘 운영되는지 감시한다. 

 

이렇게 했더니 하루 매출이 600만 원을 팔았다. 

 

여기서 직원 1, 2,3, 배달대행업체는 "치킨가게" 클래스의 캡슐화된 상태이다.

 

 

이 치킨가게에서 치킨을 주문한 외부 클래스인 고객은 "아 여기는 직원이 4명이고, 배달업체를 사용하는구나" 생각하고 주문하지 않는다. 

파는 메뉴와 가격만 알 수 있다. 

 

치킨집 사장도 외부 클래스인 고객에 관해서는 주문한 내역과, 주소밖에 알지 못한다.  치킨이 정해진 주소에 도착했지만 고객이 부재중이다.

사장은 고객이 부재중인  이유를  알 수 없다. 이러한 개념을 은닉개념이라고 한다. 

 

 

캡슐화: 책임분담 의 목적은 

내부 클래스의 응집도를 올려서 효율을 높이고(매출이 100만 원에서 ->600만 원),

외부적으로는 원활한 프로세스 진행을 위해  다른 클래스와의 결합도를 낮추는 작업이다. (고객이 집에 부재중이다.  왜 고객이 집에 없는지 알 수 없다. 하지만 치킨은 도착한다.  )

 

코드를 칠 때 public, _private 개념이 여기서 나온다. 

 

 

 

 

 

 

 

 

3. 상속 -다형성

 

객체지향의 가장 핵심적인 부분이다. 

 

상속에서 가장 중요한 건 

여기서 B는 class, A는 객체이다.

 A는 B이다. 

 

   A                   B

"굽네치킨은 치킨가게이다" 

"청양고추마요치킨은 치킨이다"

"팔과 다리는 구부러지는 기관이다"

"바퀴는 동그라미이다"

"붕어빵은 빵이다"

"짜장면은 중식이다"

"고추장 양념은 소스이다"

 

 

 

흔히 상속에 대해 실수하는 부분이 아래와 같다. 

아래와 같은 개념으로 상속을 하게 되면 후에 큰 혼란을 줄 수 있다. 

 

B는 A를 가지고 있다 

      A                    B

"고추바사삭은 치킨가게이다"  

"청양고추마요치킨은 치킨가게이다"  

"팔과 다리는 사람이다"  

"바퀴는 자동차이다" 

"붕어빵은 붕어빵틀이다" 

"짜장면은 중국집이다" 

"고추장 양념은 제육볶음이다" 

 

 

 

 

 

위에 개념이 먼저 잡혀야 다음 다형성 개념을 사용할 수 있다. 

 

BHC는 치킨가게이다

굽네는 치킨가게이다

고봉삼계탕은 치킨가게이다

 

라는 A는 B이다의 개념을 이용해 아래 클래스를 만들었다. 

각 상속받은 BHC, 굽네 , 고봉삼계탕에 cook();이라는 공통된 함수를 만들었다. 

하지만 쿡 만으로는 상속받은 클래스들의 특징을 살릴 수 없다. 이때 등장하는 게 

재정의 (오버라이딩)이다.  공통된 cook(); 함수를 오버라이딩을 통해 

각 클래스만의 고유한 튀기기, 굽다, 삶다 함수를 사용할 수 있다. 

 

 

 

 

                          치킨가게 클래스

 BHC (상속 1)        굽네  (상속 2)       고봉삼계탕(상속 3)

cook();                  cook();                  cook();      

 

 재정의 (오버라이딩) 해서 쿡 밑에 각 음식점만의 고유한 스킬을 사용 가능하다. 

 

튀긴다.                     굽다.                    삶다.

 

 

 

 


배운 점을 토대로 원가계산기 클래스 구성 

 

재료 가격의 합은 레시피가격이다.

                                     

 

                                                      class 레시피 가격(이름, 가격)

                                              투입된 레시피양 * 재료들의 가격();

 

                                                    class 재료 가격의 합(이름 가격)

                            

                                                           재료들의 가격();

 

아래는 인스턴스화시킴

        재료 1 (이름, 중량, 가격)   |   재료2 (이름, 중량, 가격)    |   재료3 (이름,중량,가격)

                      가격/중량();                    가격/중량();                          가격/중량();

     

 

 

 

 

 


결론 

객체지향을 공부하기 위해 본 블로그 글과, 동영상이 많다. 

도서관에 있는 C, 자바 책을 보기도 했다. 

 

바나나 클래스가 있고  내 손에 있는 바나나는 객체이고, 붕어빵과 붕어빵틀은 뭔 관계며 

로봇 1과 로봇 2는 왜 나오는지.... 

뭐랄까... 내겐 더 혼란만 왔다. 

 

 곰곰이 생각해 보았다. 객체지향은 내게 뭘까...

그래서 내린 결론은 

 

객체지향은 코딩을 하기 위한 하나의 도구일 뿐이다. 

코딩을 하는 이유는 문제해결을 위해서이다. 

 

내가 어떤 문제를 해결하는지가 먼저 생겨야 한다. 그 이후에 

무엇이 클래스가 되고 무엇이 객체인지를 결정해야 한다. 

 

도구에 집착하지 말자. 문제에 집중하자. 

 

객체지향 끝.

(내가 객체지향을 100% 이해 못 했다 하더라도....)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

반응형

+ Recent posts