챗지피티 GPTs와 구글 Gems 차이 | 공유와 비용의 차이

-

AI를 사용하면 중복된 프롬프트를 꾸준히 만들게 된다.

챗지피티-GPTs 혹은 제미나이-Gems를 사용하면 중복된 프롬프트를 하나의 AI 서비스처럼 만들어 사용할 수 있다.

본인의 경우 GPTs 를 먼저 사용해 보고 익숙한 경우 Gems 까지 만들어 같이 사용하고 있지만, 이 둘의 차이가 있다.

사용자의 이용 범위이다.

결론적으로 챗지피티의 GPTs의 경우 모든 사용자가 사용할 수 있지만, GPTs를 만들고자 한다면 PLUS 사용자로 유료 결제가 필요하다.

하지만, 구글 제미나이 Gems의 경우 무료 사용자가 사용할 수 있는 장점이 있다.

1. GPTs와 Gems

.

2. 나만의 개인화 AI 비서를 만들고 공유하자.

.

3. 차이점 / 비용의 문제

.

4. 만들면 편하다

.


댓글

댓글 쓰기

챗지피티 코덱스와 깃허브 연동 방법 | VSCode 사용하기

-
이미지
챗지피티의 코덱스( Codex )와 깃허브( Github )를 연결하려고 했지만, 연결이 되지 않아 VSCode에서 직접 연결을 하였다. VSCode에 깃허브를 직접 연결하니 오히려 더 좋은 느낌이다. 코덱스에 프롬프트를 실행하면 자동으로 파일을 만들고 나는 그저 깃허브에 저장소를 만들고 푸시( Push )만 하면 된다. 오히려, 챗지피티 코덱스 페이지에서 연결이 제대로 되지 않은 것이 다행(??)이란 느낌이다. 새로운 것을 시도해 보고, 좀 더 편한 방법을 찾았기 때문이다. 왜 연결이 되지 않는 거냐 ?? 좀 편하게 작업하려고 코덱스( Codex )에 깃허브( Github )를 연결하고자 했다. 인증까지 하고, 윈도우 자동 인증까지 삭제하고 다시 했음에도 연결이 되지 않았다. 아~ 뭐지 ? 찾아보니 버그라고 하는데 ~ 몇 일 동안 계속 이어지는 것 보면 이건 뭔가 문제가 있다고 볼 수 밖에 없다. ( 그 원인과 해결책을 찾을 수가 없다. ) 아아 ~ 코덱스 ~ 인증까지 했는데 깃허브 연결이 왜 안되냐 ~ 다행스럽게도 VSCode에서 연결이 된다는 것을 찾게 되었다. 잘 모르겠는 화면에서 익숙한 아이콘과 제목이 눈에 보였다. 바로 ` IDE에서 시도해 보기 ` 버튼이었다. VSCode에서 할 수 있다는 얘기는 들었지만, 이렇게 보여주니 시도해 보는게 당연하겠지. 일단 자세한 내용을 찾아보니 이미 많은 분들이 VSCode에서 챗지피티의 코덱스를 연결해 사용하고 있었다. VSCode가 깃허브에도 연결되니, 생각해 보면 굳이 코덱스를 웹에서 할 필요는 없겠다는 생각이 들었다. 바로 시도를 해 본다. 새로운 방법을 찾다. 이런 새로운 방법을 찾게 되면 왠지 모를 도파민이 생기는 느낌이다. 어쨌든 VSCode를 실행하고 코덱스를 설치하게 되었다. 평소 웹에서 작업하다보니 VSCode에 설치된 코덱스가 익숙하진 않다. 뭐, 걱정할 필요는 없다. 화면을 캡쳐하고 챗지피티 또는 제미나이에 캡쳐화면 자체를 업로드하고 물어보면 된다. 화면 우측 하단에 프롬프트 입력창이 있다. ...
댓글 쓰기

이 블로그의 인기 게시물

ChatGPT Codex GitHub 연결 해제 방법 (앱 삭제까지 정리)

-
이미지
ChatGPT의 Codex를 사용하기 위해 Github를 연결했지만, 가끔씩 정리가 필요하다. Codex와 Github의 연결이 필요없는 경우들이 발생할 수 있기에 이 때는 Github에서 직접 연결해제 또는 삭제를 하는 것이 가장 확실하다. 깃허브( GitHub )에 연동된 코덱스( Codex) 연결을 해제하기 위해 깃허브 설정의 Settings > Application > ChatGPT Codex Connector 항목에서 Uninstall 을 수행하면 된다. 잘 사용하던 코덱스를 굳이 해제하는 이유는 개발자마다 다를 것이지만, 다른 깃허브의 연결이 필요할 수도 있고, 다른 PC에서 잠깐 연결한 깃허브의 코드를 노출하지 않기 위함도 있을 것이다. 깃허브 코덱스 연결 해제하기 방법 1.Codex 무엇? 챗지피티-코덱스( ChatGPT-Codex )는 사람이 어떤 작업을 문자열 프롬프트로 만들어 요청을 하면, 코드의 생성부터 수정, 분석까지 개발과 유지보수에 대한 지원을 도와주는 AI 개발 도구이다. 깃허브 연동을 통해 실제 프로젝트 코드에 직접 접근하여 자동화 코딩 개발 환경을 만들 수 있다. 하지만, 코덱스의 훌륭한 강점이 오히려 반대로 작용하는 부분들도 생기고, 개발 환경에서 코덱스로 생기는 branch에 상황에 따라 과도하게 생길 수 있다. 물론, 이것은 깃허브 홈페이지에서 삭제할 수 있지만, 코덱스의 연결점을 끊고, 다시 시작할 수도 있다. 2. Github에서 ChatGPT-Codex 연결을 해제하기 하나씩 진행해 보자. 모든 과정은 따라하기 형식으로 작성하였다. 성격 급한 분들을 위한 코덱스, 깃허브 연결 해제 방법 또한 순서대로 작성해 본다. 순서는 다음과 같다. ChatGPT-Codex에서 GitHub 연결 확인하기. GitHub 홈페이지 접속하기. 프로필 아이콘 > Settings 메뉴 접속하기. 좌측메뉴 > Applilcations 메뉴 선택하기. ChatGPT Codex Connector 항목의 Configure 선택...
자세한 내용 보기

C언어 return 종류와 차이 | return, return 0, return -1, return n

-
이미지
C언어에서 return은 함수의 실행을 끝내고, 필요 시 동작 또는 결과 값을 호출한 곳으로 함께 전달한다. 리턴의 종류는 크게 4가지로 return, return 0 , return -1 , return n 이다. 결과값이 없거나 0인 경우 종료, 0이 아닌 경우 에러 또는 특정 상태를 의미한다. C언어 return 종류와 차이 return 역할 모든 프로그램 언어들은 수행한 처리 결과를 전달할 수 있다. 수행한 처리 결과를 전달하는 때 사용하는 것이 return 이다. return 구문을 활용하면 처리되는 곳의 상태와 값을 알 수 있다. C언어 사용되는 return 구문의 종류는 반환값이 없는 경우와 있는 경우, 반환값이 0 인 경우와 0이 아닌 경우로 나눠진다. 프로그램 실행의 최소 단위 함수의 역할 C언어의 함수에 대해 잠깐 언급해 본다. OOP와 같은 프로그램 언어들이 소개되면서 함수란 용어 보다는 메서드란 용어를 주로 사용하는데 뭐, 같은 말이다. 프로그램이 실행되는 최소단위로 보면 된다. 그런데, 함수를 공부하고 있다면 return 구문을 자주 보게 된다. 보통 처리 결과를 호출한 곳으로 되돌리는 역할을 하는 것이 return 구문인다. 여기서 의미하는 함수는 프로그램의 시작점인 main() 함수도 포함된다. 그렇다면 main() 은 return 구문을 어디로 되돌릴까 ? 윈도우 또는 리눅스와 같은 main함수를 실행한 OS 이다. 함수는 이 정도로 간단히 언급해 본다. 리턴의 종류 return 의 역할은 프로그램의 흐름을 넘기고, 실행한 결과에 대한 값을 전달한다고 언급했다. 보통의 처리결과는 4가지가 있다. `종료(중단), 성공, 에러(실패), 사용자 지정`이다. 그럼에도 공통점은 처리를 중단한다는 점에 있다. 리턴 결과에 대한 코드와 내용은 프로그램을 제작한 곳마다 사람마다 다르다. 먼저 위에서 언급한 것에 대한 의미를 보자. 프로그램에서 언급하는 것은 좀 더 상세하게 나열 할 수 있다. 주목할 점은 여기에서 언급하는 함수는 프로그램 시작인 ...
자세한 내용 보기

UWP 지원 종료 확정? 2025년 이후 WinUI3 전환해야 하는 이유

-
이미지
UWP 를 접한 계기는 마이크로소프트 스토어 때문이었다. 앱을 개발하고 소소한 수익이라도 만져볼 생각이었지만 2024년 11월 UWP에 대한 지원 중단에 대한 포스팅을 발견했고, WinUI 를 접하게 되었다. 둘 다 마이크로소프트 윈도우의 UI 프레임워크지만 UWP 지원을 중단하는 큰 이유는 개발자들의 참여도가 상대적으로 적은 것이 원인이었다. UWP의 지원이 중단되면서 대체재는 무엇일까? 했지만, 마이크로소프트는 WinUI를 권장하고 있다. WinUI는 윈도우 계열의 UI 프레임워크로 간단한 앱은 기존의 WPF , UWP와 흡사하기 때문에 이미 WPF나 UWP에 익숙해져 있다면 WinUI로 빠르게 옮기는 것도 방법일 듯 싶다. 마이크로소프트 UWP 지원 중단과 WinUI 3 권장 UI 프레임워크 UWP 앱, 지금 당장 이전해야 할까? 결론부터 말하면, 모든 UWP 앱을 지금 즉시 WinUI 3로 옮길 필요는 없다. 하지만 “어떤 앱이냐”에 따라 판단은 완전히 달라진다. 아래 중 하나라도 해당된다면, UWP 유지보수는 장기적으로 리스크가 된다. 신규 기능 추가 계획이 있는 앱 Windows 최신 UI/기능을 활용해야 하는 앱 1년 이상 운영 예정인 서비스형 앱 기업/업무용으로 장기 지원이 필요한 앱 반대로, 단순 내부 도구이거나 기능 추가 계획이 없는 경우라면, 단기적으로는 UWP 유지도 가능하다. 중요한 건, ‘지금 이전하느냐’보다 ‘이전을 전제로 설계하고 있느냐’다. UWP 극복하지 못한 비운의 UI 프레임워크 UWP를 처음 접했을 때는 마이크로소프트 스토어 때문이었다. 소소한 윈도우 앱으로 소소한 수익을 기대한 것이지만, 상당히 불편했다. `윈폼보다 못한 기능` 이 한가지만 해도 이미 모든 것을 말해준다. 심지어 WPF보다도 못했다. ( 다행인건 개발환경은 비슷했다는 점에 있다.) 윈도우 계열의 모든 기기에서 사용할 수 있는 `원소스-멀티코드`가 목적이었지만, 욕심이 과했던 것인지 내부의 문제였던 것인지, 문제를 제기해도 UWP에 대한 지원은 미미했다. ...
자세한 내용 보기