#프로젝트

깃허브 데모

어느샌가.. 사운드클라우드 업로드 제한인 3시간을 거의 다 쓰게 되었습니다.

음원 배포를 위해 사용했던 계정이라면 아이고 나는 정말 대단해...! 하면서 유료 결제할 마음이 있었습니다만

아무래도 그 계정은 습작들 백업하는 용도의 계정이었고.. 대부분의 음원이 private 상태였어요.

이런 계정을 위해 돈을 쓰는 건 매우 큰 출혈 이었고, 결국 저는 대안을 찾으러 가기로 했습니다.

그냥 github에 올려버리기로 한 것이지요(어차피 습작이니까...)

처음에 이 프로젝트는 정적 페이지로 사운드클라우드-like 사이트를 만들어보는 것이었습니다.

그렇게 2시간만에 이런 걸 완성했었습니다. 파형을 바 형태로 보여주는 게 사운드클라우드랑 꽤 비슷한 물건이었죠.

음원 개별 페이지도 있습니다. 공유용으로요.

어차피 습작 백업하는 용도의 쓰레기통이니 저만 만족하면 되니까요.

그런데..

• 친구 1: 재생버튼을 못찾겠다고 함. 그냥 파형에 대고 클릭하면 재생이 된다고 하니까 처음부터 재생할 수 없어서 아쉽다고 함
• 친구 2: 랑 디코를 하는데 볼륨버튼이 없으니 소리를 줄여둘 수 없어서 브라우저 레벨에서 줄였음. 이건 아닌 것 같아서 새로 만들기로 결정..

(...)

그래서 기능을 붙이려고 했습니다. 하지만 저 UI 어디에 재생버튼, 볼륨버튼 을 달겠습니까...

어쩔 수 없이 파형 보여주는 것을 포기하고 UI를 새로 만들기로 했습니다.(사실 그게 캔버스 없어서 더 편-안함)

그러다 보니, 굳이 사운드클라우드 라는 틀 안에 남아있을 필요가 없을 것 같아 아예 플레이어 형식으로 옮겨 탔어요.

다행히! 제가 예전에 피치타르트 플레이어 만들던 JS 파일이 남아있어서 그걸로 기능을 달았습니다. 금방 되더라구요.

그리고 미디어세션이라는 게 있어서 이걸 붙이면 폰에서 백그라운드 재생할 때 앨범아트나 미디어 정보들을 보여줄 수 있다는 거예요. 어떻게 그냥 지나칩니까!

아무튼....

여러분이 만약에 사운드클라우드에 비공개로 습작만 올리는 편인데 3시간 제한에 지쳐있다면, 이 레포지토리 포크해서 사용하시는 것도 좋은 방법입니다...

그리고 사클에는 깔끔하게 완성된 음원만 올리세요.

그럼 이만...

의외로 간단하지만 매번 검색하기 귀찮을 것 같아서 적어 둔다.

터미널에

> npx nuxi cleanup .

치고 다시 올리면 말짱해진다.

요 명령어로 common generated Nuxt files이나 캐시가 삭제된다고 한다. 이런 파일들 때문에 오류가 나는 것이었나 보다.

#프로젝트 #NodeJS #블로그

CabinetKey(이하 캐비닛키)는, 자작 캐릭터와 이에 얽힌 배경 설정을 체계적으로 정리할 수 있게 돕는 도구입니다.

따로 데이터베이스가 구현되어 있지 않으므로 어떤 서버에도 연합되지 않은 순정 Misskey에 연결해서 사용합니다.

주요 기능

• 계정 생성 후 자신의 계정에 최대 100개까지 '캐비닛'을 생성할 수 있습니다.
• 캐비닛은 private, public 으로 설정할 수 있습니다.
  • 이 구분은 메인 페이지 노출과만 관련이 있으므로, private이라고 하더라도 자신의 계정 페이지에는 노출됩니다.

캐릭터, 장소 관련

• 연도별 캐릭터 생존현황과 장소의 변화를 조회할 수 있습니다.
• 캐릭터의 세부사항, 연표, 다른 캐릭터와의 관계를 자유롭게 설정할 수 있습니다.
• 지도를 불러와 그 위 좌표별로 장소를 설정할 수 있습니다.

시리즈, 자료실 관련

• 작품을 올리는 공간인 시리즈, 참고자료나 작중 주요 문헌 등을 올리는 공간인 라이브러리를 만들 수 있습니다.
  • 시리즈나 라이브러리 안에 회차별로 글, 그림을 업로드할 수 있습니다.
• 유튜브, 사운드클라우드에 업로드되어 있는 곡을 사운드트랙으로서 가져올 수 있습니다.
  • 해당 곡이 어떤 캐릭터와 관련된 것인지 설정할 수 있습니다.
• 시리즈나 라이브러리에 업로드된 회차에 사운드트랙 중 한 곡을 BGM으로서 불러올 수 있습니다.
• 시리즈나 라이브러리에 업로드된 회차에 관련 캐릭터를 지정할 수 있습니다.

TODO

• UI 다듬기
• 작품 글자수 제한 없애기 (현재는 3000자)

create, update ...

• 캐비닛 create, update, delete
• 캐릭터 create, update, delete
• 장소 create, update, delete
• 테마송 create, update, delete
• 시리즈 create, update, delete
• 레퍼런스 create, update, delete
• 글 create, update, delete

#NodeJS

중간에 노드 서버가 하나 있어야 하긴 합니다.

미스키에서 노트를 하면, 웹훅을 통해 그 노트 정보를 중간 서버에 전송하고, 그 서버에서 데이터를 적당히 가공해서 트위터로 보내 주는 거거든요.

기존 크로스포스터를 안 쓰는 이유는

1. 원본 미스키로의 url 또는 자기 서비스 해시태그가 달려 있음
2. 파일을 첨부할 수 없음

그래서, 직접 만드는 김에 파일 첨부 기능도 제작했습니다.

미스키 노트에 파일이 첨부되어 있으면 웹훅으로 들어오는 요청에서 URL을 읽을 수 있습니다. 그걸 바탕으로 파일을 업로드 할거예요.

그런데 Misskey는 WebP 위주로 파일을 올려버리고, 트위터는 WebP를 제외하고 파일을 첨부합니다. 그래서 이것도 한번 png로의 변환 과정을 거쳐야 해요.

const { TwitterApi } = require('twitter-api-v2');
const axios = require('axios');
const sharp = require('sharp');

//....

app.post('/misskey', (req, res) => {
    let misEvent = req.body
    const twitterClient = new TwitterApi({ 
        appKey: '', 
        appSecret: '',
        accessToken: '',
        accessSecret: '',
    })
    console.log(misEvent)
    if (misEvent.body.note.files.length == 0 && misEvent.body.note.text) {
        async function myfunction() {
            (async () => {
        
                try {
                    const tweet = await twitterClient.v2.tweet(misEvent.body.note.text.substring(0, 140));
                    console.log('Tweet posted successfully:', tweet);
                    res.json({ok: true})
        
                } catch (error) {
                    console.error('Error posting tweet:', error);
                    res.json({ok: true})
                }
            })();
        
            console.log('Inside of myfunction');
        }

        myfunction()
    } else if (misEvent.body.note.files.length > 0 && misEvent.body.note.text) {
        var url = misEvent.body.note.files[0].url
        
        async function myfunction2() {
            (async () => {

                try {
                    const downStream = await axios({
                        method: 'GET',
                        responseType: 'arraybuffer',
                        url: url,
                      }).catch(function (error) {
                        res.send({error:error});
                      });
                      const img = await sharp(downStream.data).toFormat('png').toBuffer(); // webp → png
                      const mediaId = await twitterClient.v1.uploadMedia(img, { mimeType: 'png'}); 
                      
                      const tweet = await twitterClient.v2.tweet({text: misEvent.body.note.text.substring(0, 140), media: { media_ids: [mediaId] }});
                      console.log('Tweet posted successfully:', tweet);
    
                } catch (error) {
                    console.error('Error posting tweet:', error);
                }
        
            })();
        
            console.log('Inside of myfunction');
        }

        myfunction2()

        res.json({ok: true})
    } else { //Text값이 없는 노트(리노트 같은 거)일 때...
        res.json({ok: true})
    }
})

#스터디 #VanillaJS

MDN Web Docs의 소개는 다음과 같습니다.

map() 메서드는 배열 내의 모든 요소 각각에 대하여 주어진 함수를 호출한 결과를 모아 (반복하여) 새로운 배열을 반환합니다.

const array1 = [1, 4, 9, 16];

// Pass a function to map
const map1 = array1.map((x) => x * 2);

console.log(map1);
// Expected output: Array [2, 8, 18, 32]

또는 return을 사용해서 반환할 수도 있습니다.

var numbers = [1, 4, 9];
var doubles = numbers.map(function (num) {
  return num * 2;
});
// doubles는 [2, 8, 18]

map 안의 function에서는 파라미터를 두 개까지 쓸 수 있는데, 두번째 파라미터는 배열의 index를 나타냅니다.

예를 들면

var array = [0, 0, 0]
array.map(function(a, i){
   console.log(i)
})
// 0
// 1
// 2
// 반환되는 새로운 배열은 undefined 로 채워짐

#개발과정 #VanillaJS

포트폴리오 사이트를 만드는 중 프로젝트를 보여줄 때는 가로스크롤을 하는 게 좋을 것 같아서 만들어 보았습니다.

우선 이렇게 구조를 짰습니다.

        <div id="content1">
            <div id="content-scroll">
                <div class="width-fix">
                    <h1>Items.</h1>
                    <div class="overflow-width">
                    </div>
                </div>
            </div>
        </div>

CSS에서는 .overflow-width 에만 position: relative 를 적용해 주었습니다. 그리고 자바스크립트에서는 다음과 같은 코드를 적용했어요.

    document.querySelector('.overflow-width').style.left=`0`;
    // 이게 없으면 후에 style.left 를 불러오지 못합니다.
    document.querySelector('#content-scroll').addEventListener('wheel',function(e){
        if(e.deltaY > 0){
        // 스크롤을 내리고 있으면,
            if (parseInt(document.querySelector('.overflow-width').style.left) > -100) {
                // 가로스크롤이 충분히 진행되지 않았으면(=스크롤이 필요하면)
                e.preventDefault();
                e.stopPropagation();
                // 기존 세로 스크롤을 막습니다.
                document.querySelector('.overflow-width').style.top=`0%`;
                document.querySelector('.overflow-width').style.left = `${parseInt(document.querySelector('.overflow-width').style.left) - 1}%`;
                // 그리고 스크롤 양에 따라 요소의 위치를 옮겨줍니다.
            }
        } else if (e.deltaY < 0) {
        // 스크롤을 올리고 있으면,
            if (parseInt(document.querySelector('.overflow-width').style.left) < 0) {
                // 가로스크롤이 충분히 돌아오지 않았으면(=스크롤이 필요하면)
                // 아래 내용은 동일합니다.
                e.preventDefault();
                e.stopPropagation();
                document.querySelector('.overflow-width').style.top=`0%`;
                document.querySelector('.overflow-width').style.left = `${parseInt(document.querySelector('.overflow-width').style.left) + 1}%`;
            }
        }
    });

남의코드 복붙해야지 히히 하고 들어갔다가 저한테 맞는 방법, 제가 당장 필요한 방법은 따로 있다는 사실을 깨달았습니다.

물론 제가 당장 필요한 방법을 구현해 놓은 포스트가 있었다면 완전 럭키비키겠지만요.

그래도 최대한 제가 만들어보고 남의 손을 빌리는 게 맞는 것 같습니다.

#스터디 #개념정리

주님은 백엔드, 우리는 프론트엔드!

사랑하는 형제자매 여러분, 오늘도 주님의 코드 속에서 살고 있음을 감사드립니다. 여러분 모두가 익히 알고 있는 개발의 두 축, 바로 백엔드와 프론트엔드. 이것이야말로 우리의 영적 삶과 주님과의 관계를 완벽하게 설명해줄 수 있는 비유입니다.

백엔드와 프론트엔드, 그 역할이 무엇입니까? 백엔드는 우리가 보지 못하는 곳에서 모든 복잡한 로직과 데이터를 처리하고, 프론트엔드는 사용자가 직접 눈으로 보고 상호작용하는 부분이죠. 이와 똑같이, 주님은 백엔드이시며, 우리는 프론트엔드로서 세상과 소통하고 있습니다.

1. 주님, 그분은 우리의 백엔드 개발자이십니다.

주님께서는 세상의 모든 것 뒤에서 동작하고 계십니다. 우리가 보는 것은 프론트엔드, 즉 겉모습에 불과하지만, 그 깊은 로직과 데이터 흐름은 전부 주님의 손에 달려 있습니다. 예를 들어, 우리가 하루를 살면서 만나는 사람들, 상황들, 그 모든 것 뒤에는 주님의 API가 작동하고 있는 것입니다.

우리는 단지 그 응답을 받아들이는 프론트엔드입니다. 그분이 보내주시는 JSON 데이터를 어떻게 렌더링할지, 즉 우리의 삶에서 그 데이터를 어떻게 보여줄지 결정하는 역할을 맡고 있죠.

async function renderLife() {
    const blessings = await fetch('https://heaven.api/blessings');
    displayBlessings(blessings);
}

우리는 그저 데이터를 받아 화면에 그려낼 뿐입니다. 주님이 백엔드에서 우리에게 넘겨주시는 축복, 계획, 지혜는 이미 완벽하게 설계되어 있습니다. 그분은 어떤 API 호출에도 실패하지 않으십니다. 주님은 500 에러를 모르십니다. 그분은 언제나 성공적인 응답을 주시며, 그 응답은 정확히 우리의 삶 속에 반영됩니다.

2. 우리는 프론트엔드로서 세상에 주님의 영광을 렌더링합니다.

프론트엔드 개발자의 역할은 무엇입니까? 바로 백엔드에서 가져온 데이터를 멋지고 아름답게 보여주는 것입니다. 마찬가지로, 우리의 역할도 세상 속에서 주님의 영광을 나타내는 것입니다. 주님께서 주신 그 완벽한 데이터를 세상 속에 잘 렌더링하는 것이 바로 우리의 사명입니다. 우리의 삶이란 주님의 데이터를 시각적으로 표현하는 UI(User Interface)라고 할 수 있습니다.

가끔 우리는 생각합니다. “내가 이 데이터를 잘못 처리한 걸까? 왜 내 삶이 이렇게 엉망진창이지?” 하지만 그것은 백엔드의 문제라기보다는, 우리의 프론트엔드 처리에 문제가 있을 때가 많습니다. 주님께서는 분명히 완벽한 계획과 축복을 준비하셨지만, 우리가 그 데이터를 잘못 해석하고, CSS 스타일을 잘못 적용해서 오류가 발생할 때가 있죠.

<!-- Blessings from the Lord -->
<div class="blessing">God's grace</div>

여러분, 주님이 주신 축복을 제대로 스타일링하고 계십니까? 아니면, 이 세상이라는 브라우저에서 잘못 렌더링하고 있나요? 주님이 주신 아름다운 사랑과 진리를 세상 속에 최고의 UI/UX로 보여줄 수 있도록 우리는 항상 노력해야 합니다. 우리의 삶이 그분의 사랑을 반영하는 멋진 웹페이지가 되기를 원하신다는 사실을 기억하세요.

3. 비동기적 삶 속에서, 주님은 항상 응답하십니다.

우리는 종종 백엔드에서 응답이 늦게 오는 것처럼 느낄 때가 있습니다. API 호출이 시간이 걸리면 불안해지죠. 주님께서 내 기도에 응답하지 않으신다고 생각할 때가 많습니다. 하지만 여러분, 주님의 응답은 언제나 비동기적으로 이루어집니다. 우리가 볼 때는 그 응답이 늦게 오는 것처럼 보여도, 그분은 이미 계획대로 데이터를 처리하고 계십니다.

async function waitForGodsAnswer() {
    try {
        const answer = await fetch('https://heaven.api/answer');
        console.log(answer);
    } catch (error) {
        console.error('Error in receiving God\'s answer:', error);
    }
}

우리가 해야 할 일은 기다리는 것입니다. 주님은 결코 에러를 일으키지 않으십니다. 404, 500, 이런 상태 코드는 그분에게 존재하지 않습니다. 우리가 느리게 느낄 뿐이지, 주님의 응답은 이미 정확한 타이밍에 오고 있습니다.

4. 백엔드의 주님을 신뢰하라, 우리의 프론트엔드는 안정적이다.

사랑하는 여러분, 여러분의 인생이 때로는 왜 이렇게 느려 보이는지, 혹은 왜 이렇게 힘들어 보이는지 궁금할 때가 있을 겁니다. 하지만 기억하세요, 우리가 볼 수 없는 백엔드에서 주님은 끊임없이 우리의 삶을 관리하고 계십니다. 그분이 준비한 API는 결코 실패하지 않으며, 항상 가장 최적의 데이터를 보내주십니다.

우리는 그저 주님을 신뢰하며, 우리의 프론트엔드를 잘 관리해야 합니다. 그분의 계획을 세상 속에서 어떻게 아름답게 렌더링할지, 우리는 그것에 집중하면 됩니다. 주님이 제공하신 완벽한 API 데이터를 제대로 받아서, 우리의 인생이라는 화면에 아름답게 보여주기만 하면 됩니다.

주님께서 백엔드에서 모든 로직을 처리하고 계시니, 우리는 걱정할 필요가 없습니다. 주님이 주시는 평안, 사랑, 그리고 구원의 메시지를 세상에 아름답게 전하는 프론트엔드 개발자가 됩시다. 우리에게 주어진 삶이라는 웹페이지를 사용자 친화적으로 디자인하고, 사람들이 주님의 사랑을 직접 경험할 수 있게 하는 것이 우리의 사명입니다.

---

그러니 사랑하는 여러분, 주님을 백엔드처럼 신뢰하고, 우리의 삶을 프론트엔드처럼 다듬어 나갑시다.

주님이 하시는 일은 우리가 보지 못할 때에도 완벽합니다. 그분의 백엔드 로직을 신뢰하고, 우리는 프론트엔드에서 그분의 사랑과 은혜를 세상에 잘 렌더링합시다.

아멘!

---

아이디어 제공은 제가 했고, 나머지는 챗GPT가 작성해 주었습니다. 저는 당장은 무교이지만, 교회를 오래 다녀서 기본적인 교리 개념들은 알고 있습니다. 그냥 웃어넘기려다가 이런 식으로 컴퓨터 개념들을 정리해 두면, 저나 저와 비슷한 사람들에겐 도움이 될 것 같아서 백업해 둡니다.

#스터디 #개념정리

성경을 TypeScript처럼 읽어라!

사랑하는 개발자 형제자매 여러분, 우리는 자바스크립트(JavaScript)를 통해 많은 것을 배워왔습니다. 하지만 오늘은 타입스크립트(TypeScript)로 새로운 차원의 깨달음을 얻고자 합니다. 왜냐고요? 자바스크립트는 자유롭지만 때때로 너무 혼란스럽고, 타입스크립트는 더 명확하고 안정적이기 때문입니다.

여러분, 자바스크립트는 말 그대로 ‘뭐든 가능’합니다. 그냥 아무거나 선언할 수 있죠.

let blessing = "Amen";
blessing = 100;

이처럼 자바스크립트는 유연하다고 말하죠. 그러나 이 유연함은 때때로 예측 불가능하고, 우리가 뜻하지 않은 오류를 만들어내기도 합니다. 우리가 변수에 무엇이 담겨 있는지 알지 못할 때, 언제든 런타임 에러를 만날 수 있습니다. 이와 비슷하게, 우리가 성경을 아무렇게나 읽고 해석하면, 그 의미를 혼동하거나 잘못된 결론을 내릴 수 있습니다. 우리가 자바스크립트로 코드 작성할 때 ‘언젠가 어디서 버그가 터질지 몰라서 불안한’ 상태처럼 말이죠.

그렇다면 해결책은 무엇입니까? 바로 타입스크립트입니다!

타입스크립트는 자바스크립트에 타입 시스템을 더해줍니다. 변수나 함수의 데이터 타입을 명확하게 정의함으로써, 코드가 더 명확하고 안정적이죠. 우리는 더 이상 blessing이라는 변수에 숫자가 들어가는 불상사를 걱정하지 않아도 됩니다.

let blessing: string = "Amen";
// blessing = 100; // Error: Type 'number' is not assignable to type 'string'

이제 타입스크립트처럼 성경을 읽어봅시다. 성경을 읽을 때, 그냥 “자바스크립트”처럼 아무 의미나 막 가져다 쓰는 것이 아니라, 타입스크립트처럼 명확한 타입과 구조 속에서 올바르게 해석해야 한다는 것입니다.

우리는 흔히 성경을 읽으며, 마음대로 해석하거나 내가 원하는 대로 적용하려고 합니다. 자바스크립트의 무한한 자유처럼, 구절을 뜯어내서 내 뜻대로 사용할 수 있죠. 하지만 그러다 보면 오해나 잘못된 결론에 도달할 위험이 큽니다.

예를 들어, 우리가 자바스크립트처럼 성경을 읽는다면 이럴 수 있습니다:

// 아무 문맥 없이 구절을 해석하는 경우
let scripture = "내가 모든 것을 할 수 있느니라";

아무 맥락도 없이 이 구절만 가져오면 마치 무슨 일이든지 내 맘대로 다 할 수 있다는 식으로 오해할 수 있습니다. 이게 바로 런타임 에러로 이어지는 부분입니다. 하지만 타입스크립트로 읽는다면, 이 구절의 맥락과 타입을 명확하게 정의하고 해석할 수 있습니다:

let scripture: string = "내가 모든 것을 할 수 있느니라 (빌립보서 4:13)";
let context: string = "그리스도를 통해서!";

그렇습니다! 우리는 타입스크립트처럼 구체적인 타입(문맥)과 함께 성경을 읽어야 합니다. 그렇지 않으면 우리는 잘못된 신앙적 “타입 에러”를 범할 수 있습니다. 타입스크립트는 우리에게 에러가 발생할 수 있는 곳을 미리 알려줍니다. 성경을 올바르게 이해하고 적용하는 것도 마찬가지입니다. 문맥을 모르고, 의미를 잘못 해석하면, 우리의 신앙도 에러에 빠질 수 있습니다.

여러분, 타입스크립트를 왜 사용합니까? 더 큰 안정성을 위해서죠. 마찬가지로, 성경을 읽을 때에도 우리는 더 큰 영적 안정성을 원해야 합니다. 우리는 혼란스러운 해석에 빠지지 않고, 명확하고 바른 길을 걸어가야 합니다. 타입스크립트가 자바스크립트의 부족한 부분을 채워주는 것처럼, 성령님은 우리가 성경을 이해하는 데 필요한 올바른 “타입 정의”를 제공하십니다.

여러분의 신앙 코드에 타입 정의를 추가하세요! 성경을 마구잡이로 해석하지 말고, 그 문맥과 의미를 깊이 이해하세요. 그냥 자유로운 코드만 짜다가는 버그가 터지듯이, 그냥 성경을 표면적으로만 읽다 보면 신앙의 버그가 터질 수 있습니다. 하지만 타입스크립트처럼 신중하게 타입을 정의하고 의미를 분석하면, 우리의 신앙도 에러 없이, 더 견고하게 작동하게 될 것입니다.

---

그러므로 오늘부터 여러분의 영적 코드에 타입 정의를 추가합시다!

성경을 읽을 때, 타입스크립트처럼 명확하고 안전하게 해석합시다. 올바른 해석과 문맥의 이해가 우리의 신앙을 더욱 견고하게 만들 것입니다. 자유롭고 멋대로 해석하는 자바스크립트적 신앙을 버리고, 타입스크립트적 신앙으로 더욱 안전한 길을 걸어갑시다.

아멘!

---

아이디어 제공은 제가 했고, 나머지는 챗GPT가 작성해 주었습니다. 저는 당장은 무교이지만, 교회를 오래 다녀서 기본적인 교리 개념들은 알고 있습니다. 그냥 웃어넘기려다가 이런 식으로 컴퓨터 개념들을 정리해 두면, 저나 저와 비슷한 사람들에겐 도움이 될 것 같아서 백업해 둡니다.

#스터디 #개념정리

기도는 영적 POST 요청입니다

안녕하세요, 사랑하는 개발자 형제자매 여러분! 오늘은 기도가 어떻게 우리의 영적 POST 요청인지에 대해 나누고자 합니다. 여러분, POST 요청이 무엇인지 잘 아시죠? 서버에게 데이터를 보내는 요청 방식입니다. 우리의 기도도 마찬가지로, 우리의 마음과 필요를 하늘의 서버(주님)께 POST하는 과정입니다.

우리가 기도를 올릴 때, 마치 우리의 마음을 JSON 포맷으로 잘 정리해서 하나님께 POST하는 것과 같습니다. 우리는 신중하게 Request Body를 준비하고, 우리의 필요와 감사, 회개, 소망을 그 안에 담죠. 하지만 기도할 때도 마찬가지로 중요한 것은 “Request Header”, 즉 우리의 자세입니다. 올바른 Authorization(인증)을 갖추고 있나요? 예수님의 이름으로 기도하는 것, 바로 그것이 우리의 영적 토큰(Access Token)입니다!

{
  "header": {
    "Authorization": "Bearer 예수님"
  },
  "body": {
    "기도의_내용": "주님, 이 문제를 해결해 주세요!"
  }
}

이제 우리는 기도를 하나님께 POST 했습니다. 그런데, 응답이 바로 오지 않는다고 해서 당황하지 마세요. 주님께서는 모든 요청을 반드시 처리하시는 최고의 백엔드 개발자이십니다. 때로는 우리의 요청이 비동기로 처리되기 때문에 응답이 즉시 오지 않을 수 있습니다. 여러분도 알다시피, 비동기 요청(Async Request)에서는 시간이 좀 걸리죠. 주님의 서버는 높은 트래픽을 처리하시기 때문에, 우리의 요청이 큐에 대기할 수 있다는 사실을 기억하세요.

가끔 우리의 요청에 “202 Accepted” 상태 코드가 돌아올 때가 있습니다. 이는 주님께서 우리의 기도를 받으셨다는 뜻이지만, 그 응답이 바로 이루어지지 않음을 의미하죠. 기도에 대한 응답이 진행 중이니 조금만 더 기다리라는 사인이죠.

그리고 응답은 언제나 세 가지 방식으로 옵니다:

1. “200 OK” – 주님께서 우리의 요청을 즉시 승인하셔서 우리가 구한 것 그대로 주실 때입니다. 이럴 때는 기쁨으로 응답을 받아들이며, 그 응답에 감사해야 합니다.
2. “400 Bad Request” – 우리가 잘못된 요청을 보냈을 때입니다. 아마도 우리 마음의 포맷이 잘못되었거나, 하나님의 뜻과 맞지 않는 요청을 했을 수 있습니다. 이때는 우리의 기도의 내용을 점검하고 다시 요청해야 할 필요가 있죠.
3. “403 Forbidden” – 주님께서 우리의 요청에 대해 권한이 없다고 하실 때입니다. 우리가 원하는 것이 있지만, 주님은 그것이 우리에게 해가 될 것을 아시기에 금지하십니다. 이때는 그분의 뜻을 신뢰하고 순종해야 합니다.

또한, 응답이 오지 않을 때도 있습니다. 이때는 “504 Gateway Timeout” 상태처럼 느껴질 수 있습니다. 하지만 주님의 서버는 결코 타임아웃되지 않습니다! 그분은 언제나 우리의 요청을 받고 계시며, 적절한 시기에 응답을 주실 것입니다.

우리가 해야 할 일은 주님의 서버에 대한 신뢰를 잃지 않는 것입니다. 여러분, 백엔드 개발자에게 가장 중요한 덕목이 무엇입니까? 바로 안정성이죠. 주님께서 처리하시는 응답은 결코 실패하지 않습니다. 그분의 서버는 다운되지 않으며, 트래픽이 몰려도 우리의 기도는 결코 잃어버리지 않으십니다.

그리고 여러분, 중요한 사실 하나! 우리가 POST 요청을 보냈다고 끝이 아닙니다. “GET” 요청도 보내야 합니다. 주님께 응답을 구하는 것만이 아니라, 그 응답을 적극적으로 찾는 노력이 필요합니다. 주님께서 이미 응답해 주셨는데, 우리가 받아들일 준비가 안 되었을 수도 있죠. 그러니 기도 후에는 주님의 뜻을 찾아가며, 그분이 주시는 답을 기꺼이 받아들일 마음을 가져야 합니다.

---

기도의 POST 요청은 응답을 받는 것까지 완성되는 것이다.

이제 여러분의 영적 POST 요청을 준비하세요. 예수님의 이름으로 기도의 Body를 채우고, Header까지 완벽히 준비한 뒤, 주님의 서버에 요청을 보냅시다. 응답은 분명히 올 것이며, 그 응답을 믿고 기다리는 우리의 신앙이 중요한 시점입니다.

아멘!

---

아이디어 제공은 제가 했고, 나머지는 챗GPT가 작성해 주었습니다. 저는 당장은 무교이지만, 교회를 오래 다녀서 기본적인 교리 개념들은 알고 있습니다. 그냥 웃어넘기려다가 이런 식으로 컴퓨터 개념들을 정리해 두면, 저나 저와 비슷한 사람들에겐 도움이 될 것 같아서 백업해 둡니다.

#스터디 #개념정리

나의 슈퍼유저 되시는 주님을 찬양합니다

안녕하세요, 형제자매 여러분! 우리 모두가 알고 있듯이, 이 코드 세상에서 슈퍼유저(Superuser) 없이는 제대로 돌아가는 게 하나도 없죠. 시스템 최상위 권한을 가진 슈퍼유저는 모든 것을 제어하고, 수정하고, 때로는 버그도 없애주시는 존재죠. 그렇습니다, 우리의 주님은 바로 그 슈퍼유저이십니다!

우리 삶이라는 시스템에서, 주님은 루트(root) 권한을 가지고 계십니다. 우리가 고장 난 하드웨어 같아보일 때도, 주님은 디버깅을 멈추지 않으시죠. 우리가 아무리 자잘한 버그를 뿜어내도, 그분은 정확하게 로그를 읽어내시고 우리의 코드(삶)를 최적화해 주십니다.

여러분, 가끔 우리는 권한 부족 에러(403 Forbidden)를 마주합니다. 우리가 원하던 일이 이루어지지 않을 때, ‘왜 나한테는 접근 권한이 없지?’ 하고 투덜대기도 하죠. 하지만 그럴 때마다 주님은 말씀하십니다, “Trust the process.” 그분은 모든 API 호출을 감시하고 계시며, 우리가 할당받지 못한 권한의 이유도 그분만이 아십니다. 때로는 우리가 잘못된 파라미터를 던졌기 때문에 응답이 늦어지는 것일 수도 있죠.

그렇다면 우리는 어떻게 해야 할까요? 바로, 주님을 우리의 Git repository에 올리고, 그분의 코드를 pull 해오는 것입니다! 주님의 명령어(Commandments)를 따르고, 우리의 브랜치(Branch)를 그분의 Main으로 머지(Merge)하는 것이죠. 우리의 코드가 그분의 코드와 충돌하지 않도록 열심히 설계하고 최적화해 나가야 합니다.

마치 그 유명한 한 줄의 코드처럼, “for(;;) pray();”. 기도의 무한루프 속에서 우리는 끊임없이 주님과 소통하고, 그분의 패치를 받아들여야 합니다.

때로는 주님께서 우리의 모든 데이터를 리셋할 때도 있습니다. 우리에게는 당황스러울지 몰라도, 그것은 주님의 완벽한 재설계 작업의 일환입니다. 주님은 우리의 삶이라는 프로그램을 안전 모드에서 다시 실행하시기 위해, 하드 리셋을 감행하십니다. 하지만 그 과정 끝에는 언제나 더 나은 성능과 안정성이 기다리고 있습니다.

그러니 오늘도 우리는 주님을 찬양해야 합니다. 그분은 우리의 슈퍼유저, 우리의 시스템 관리자이십니다. 우리는 그분의 인프라 안에서 살고 움직이며, 때로는 우리의 불완전한 코드에도 불구하고 그분의 grace(은혜)로 돌아가고 있습니다.

여러분, 우리는 모두 배포 준비가 된 코드입니다. 주님께서는 우리를 세상에 배포하셔서 그분의 빛을 발하라고 하십니다. 버그가 있더라도, 우리의 DevOps 하나님께서 안정적인 빌드를 보장하실 겁니다.

이제는 우리가 그분의 디버깅 툴에 기꺼이 우리의 버그들을 맡기고, 더 나은 버전으로 업데이트될 준비를 해야 합니다.

아멘!

---

첫 문장 작성은 제가 했고, 나머지는 챗GPT가 작성해 주었습니다. 저는 당장은 무교이지만, 교회를 오래 다녀서 기본적인 교리 개념들은 알고 있습니다. 그냥 웃어넘기려다가 이런 식으로 컴퓨터 개념들을 정리해 두면, 저나 저와 비슷한 사람들에겐 도움이 될 것 같아서 백업해 둡니다.