예전에 개인용으로 Google Play 개발자 계정을 등록 해두었었는데. 언제부터인가 자꾸 귀찮은 메일이 오기 시작했다.

개발자 계정이 사용되고 있지 않기 때문에 해지될 위험이 있습니다
Play Console 개발자님, 안녕하세요.

30일 이내에 Play Console 개발자 계정의 문제를 해결해야 합니다.

이 문제에 관한 자세한 정보는 Play Console의 정책 상태 페이지에서 확인할 수 있습니다. Play Console에서 보기

개발자 계정이 사용되고 있지 않습니다. 
Play Console 개발자 계정은 앱을 적극적으로 게시하고 유지 및 관리하는 개발자를 위한 계정입니다.
사용되지 않는 개발자 계정은 앱 사용자의 안전을 위해 해지됩니다. 자세히 알아보기

[해결 방법]

향후 앱을 게시하거나 유지 관리할 계획이라면 다음 작업을 완료하여 계정이 해지되지 않도록 하세요.

- 아직 계정 세부정보 페이지에서 이메일 주소와 전화번호를 인증하지 않았다면 지금 인증하세요.
- 앱을 만들고 게시하거나 Google Play에 있는 기존 앱의 업데이트를 게시하세요. 자세히 알아보기

무료 계정도 아니고 비용을 지불하고 등록한 계정인데, 장기간 사용을 하지 않는다고 해서 강제로 해지한다니 너무한다는 생각이 들었다.

하지만 구글의 위세에 눌려 나는 일단 뭐라도 하나 만들어서 앱을 등록해야겠다고 결정하였다.

간단한 퍼즐게임같은게 좋을 것 같아서 생각해보다가 테트리스와 컬럼스를 조합한 게임을 하나 대충 만들어 보았다.

컬럼스(Columns) : 국내에서는 헥사(HEXA)라는 명칭으로 더 유명했지만, 매치3의 진정한 원조

저작권 관련해서 조심해야 해야겠지만, 게임방식은 컬럼스를 기반으로 하여 같은 블록을 3개 이상 가로 세로 대각선으로 배열이 되면 사라지는 방식은 동일하지만, 기존의 블록순서를 변경하는 방식이 아니라 테트리스처럼 회전을 통해 변경해야 하는 방식이다.

게임명은 오마쥬한 '컬럼스' 에 회전한다는 의미로 '스핀'을 조합하여 '컬럼스핀(ColumnSpin)'으로 지어보았다.

• 낙하중인 블록은 좌우 이동 및 오른쪽 왼쪽으로 회전을 통해서 변경
• 가로,세로,대각선 3개이상 같은 블록이 매칭 되면 블록이 사라짐
• 쌓여있는 블록은 매칭이 되어 사라진 블록의 공간만큼만 아래로 이동됨
• 조작실수 또는 의도적으로 만든 공간은 아래로 떨어지지 않고 블럭이 공중에 유지되어있음

---

Google Play 스토어 링크: https://play.google.com/store/apps/details?id=com.yeoyu.app.game.columnspin

---

아무튼 심플하게 만들어서 Play 스토어에 배포를 하게 되였다. 배포한지는 좀 되었는데, 포스팅 하나 한다는 것이 은근히 귀찮아서 미루다가 이제야 올려본다.

막상 게임을 플레이 해보면 스마트폰의 터치를 통한 조작감이 클래식한 낙하형 게임에는 어울리지 않는것 같은 느낌이 들었다. 언젠가는 터치에 어울리는 퍼즐게임을 만들어 봐야 겠다.

초등(국민)학교 3학년 때 컴퓨터 학원을 다니기 시작했다.

당시 컴퓨터에 입문하는 사람들은 누구나 그렇듯이 시작은 GW-BASIC 였고, 보통 1년이 지나면 다음 단계로 FORTRAN 이나 COBOL로 넘어가는 과정이 있었다.

COBOL 과정을 시작하고 두어달 지나지 않아 컴퓨터학원의 원장 선생님이 바뀌게 되었다.

이전의 원장선생님보다 훨씬 젊은 분이었는데, 이제는 C언어를 배워야 한다면서 학원의 커리큘럼을 바꾸셨다.

그래서 우리들은 COBOL대신에 C언어를 배우기 시작했다. 지금 생각해보면 다행인 일이었던 것 같다.

당시 C언어 컴파일러는 원장실에만 설치가 되어있었다. 실습실에는 5.25인치 플로피 드라이브만 있는 XT컴퓨터와 주황, 초록 등의 단색모니터였고, 원장실의 공용 컴파일러 PC는 컬러 모니터에 하드디스크도 달려 있었다.

실습환경은 놀랍게도 MS-DOS용 EDLIN (UNIX의 ed와 유사품) 이라는 에디터를 사용했는데, 줄 단위로만 편집 수정이 가능하며 수정 삭제 등에 명령어를 써야 하는 매우 불편한 에디터였다.

사실상 GW-BASIC도 행번호를 활용한 줄단위 편집 방식이었기에 어느정도 적응해 나가게 되었다.

C언어 실습 방식은 실습실에서 EDLIN으로 C언어 코드를 작성하고는, 눈과 머리로 컴파일을 수차례 해보면서 이정도면 오류가 없겠지라는 마음으로 저장을 한 뒤 디스켓을 들고 원장실로 향한다.

그리고 컴파일을 해보면 오류가 발생한다. 다시 실습실로 돌아와서 반복한다.

GW-BASIC 배울때 코드를 작성 후 바로 실행하던 때와는 달리 너무 불편한 환경이었다.

나중에 시간이 지나 터보C 를 집에 설치해서 돌려보며 느낀 감정은 '저 때 터보C 같은 IDE 환경에서 공부했으면 좀 더 쉬웠을텐데, 나는 도대체 뭘 한건가...' 였다.

하나의 큰 소득은 EDLIN 의 편집명령은 PC통신의 문서편집기와 거의 동일했고, 또한 vi 에디터를 배울 때도 유사한 명령체계가 도움이 된 부분이 있었다. 긍정적으로 보면 뭐든지 배우면 도움이 되긴한다.

암튼 학원에서 기본기는 익혔으니 중학교 때부터는 취미삼아 서점에서 책을 사거나, 컴퓨터 잡지나 PC통신의 글을 통해 방과후나 방학때 틈틈히 독학을 하였다.

이것 저것 한번씩 해보는 것이었다. PASCAL, PowerBASIC, 한글프로그래밍 언어라는 씨앗도 있었고... 그 중 왠지 모르게 마음에 든게 있었는데 PowerBASIC 이었다. Basic 언어의 문법 기반에 포인터같은 C언어의 특징을 녹여내고, exe로 완벽히 컴파일이 되었다.

그 때의 나는 무언가 만들어보는 과정이 재미있었다. 그냥 재미가 있었다 .

프로그래밍이 가장 재미있었던 때가 언제인가를 묻는다면 나는 항상 중고등학교 시절이라고 이야기 한다.

그 생각은 지금도 변함이 없다. 당시의 나에게 프로그래밍이란 학교공부나 시험준비가 아닌 즐거운 놀이였기 때문이다.

한달 전 쯤에 본가에 들렀을 때 였다. 지금은 아버지가 쓰고 계시는 내 책상 구석에서 연습장 몇 권을 들춰보다가 옛 추억에 잠기게 되었다.

나는 늘 무엇인가를 보거나 체험하고나면 그것을 한번 내 손으로 직접 만들어 보고 싶다는 생각이 들곤 한다.

어렸을 때도 마찬가지 였는데, 게임을 플레이 하는 것도 좋아 했지만 끝까지 클리어하는 것만이 목적이라기 보다는 어느정도 즐기고 나면, '이걸 어떻게 만들었을까?' 생각하면서 나도 비슷한 것을 만들어 보려고 시도하곤 했다.

당시 어린 마음으로는 생각하기에 어느정도 프로그래밍에는 자신이 붙었지만.. 아무래도 게임을 만드는게 가장 큰 걸림돌은 그래픽이었다.

PC통신의 유명한 분들처럼 나도 그림 잘그리고 도트 잘찍는 달인과 함께 팀을 이루어 게임을 개발해보는 것이 꿈이었다.

그러나 나에게 그런 기회는 찾아오지 않았고, 나 스스로 해결하고자 그림을 연습하기 시작했다. 물론 실력이 잘 늘지 않었다. 게다가 손으로 그림을 그리는 것과 게임제작을 위한 도트노가다는 또 다른 영역이었다.

그러다가 생각의 전환이 온 시점이 있었는데, 바로 텍스트로만 이루어진 MUD게임이었다. 당시 여러 MUD게임이 유행이었는데, 그 중에서 나는 '단군의 땅'이라는 MUD게임에 빠져들기 시작했다.

동,서,남,북을 타이핑하면서, 화면에 뿌려지는 텍스트 묘사가 마치 머리속에 이미지로 렌더링 되는 듯한 놀라운 현상을 경험하면서 정말 재미있게 즐기고 있었다.

그런데 어느날 큰 문제가 발생했는데, 그것은 바로 전화비가 20만원이 넘게 나온것이었다. 나는 부모님께 크게 야단을 맞게 되었다.

전화 모뎀을 통해 플레이하는 방식이라 플레이한 시간만큼 전화요금에 추가 되는 과금 시스템이었고, 지금도 20만원이 작은돈이 아닌데 1990년대 물가로 계산해보면 당연히 혼날만한 일이었다.

아무튼 이 사건을 계기로 MUD게임을 더이상 못하게 되었다. 나는 금단현상을 느끼게 되었고, 싱글플레이가 가능한 OUD/SUD 게임을 PC통신에서 다운로드 해서 플레이하며 위안을 삼으려고 했었다. 멋진 작품들이 여럿 있었지만, '단군의 땅'과 비슷한 감성을 주는 게임은 못 찾았다.

OUD란?

당시 나우누리 'OUD 속의 세상' 이라는 소모임을 개설하신 분의 이야기에 따르면 OUD는 One User Dungeon 의 약자로 MUD(Multi User Dungeon)와 대비되는 용어인데, 나중에 생각해보니 SUD(Single User Dungeon)가 올바른 표현인데 이미 OUD로 명명 해버린 점에 대해 안타까움을 표현하셨었다.

그래서 나는 직접 만들기로 결심을 하였다. 핵심은 그래픽이 필요 없었다. 그렇다면 내가 혼자 만들 수 있는 것이었다.

지금 생각하면 우습지만 '천상천하' 라는 제목의 OUD게임이었다. 깊은 고심 없이 갑자기 '천상천하 유아독존'이라는 문구가 떠올라서 붙인 이름이었다.

처음에는 '단군의 땅'과 유사하게 주막, 포도청 등의 한국적 정서를 반영한 맵(존) 구성이나 '단군의 땅'과 유사한 명령어 체계로 시작을 하였는데 점점 만들다보니 무협요소가 애매하게 섞이면서 이도저도 아닌 설정이 되었다.

본인도 원본 소스와 파일들을 유실 했었는데 머드클럽 자료실의 어느 멋진분께서 자신이 소장중이던 자료를 공유해주셔셔 이 실행파일을 구할 수 있었다.

기억 속의 제작 과정을 떠올려 보면, 일단 머리 속에 생각나는 대로 무작정 코딩을 시작했다. 그러다가는 모눈종이에 연필로 맵을 그리고, 몹의 위치를 지정하고, 장비를 장착할 위치별로 숫자로 부여하였다. 맵에디터, 아이템에디터 이런거 없이 종이에 작성한 내용을 기반으로 수작업으로 데이터파일을 직접 만들었다.

지금의 나와 사뭇 다른 점은 지금은 뭔가 하나 만들려면 구글링을 엄청나게 하면서 과연 이게 올바른 방식인지, Best Practice는 과연 무엇인지, 세상에 나보다 뛰어난 사람이 정말으니 더 찾아봐야겠 하면서, 검색만 하다가 정작 코딩은 진도가 안나가는 경우가 많은데, 어린시절의 나는 거침이 없었다.

그냥 생각나는대로 타이핑해나가는 것이었다. 올바른 구현 방식인지는 고민하지 않는다. 일단 실행해서 돌아가면 된다. 학교에 가서도 수업시간에 나의 머리 속에서는 개발 진행 과정이 계속 머리 속을 맴돌고 있었고 집에 돌아와서는 다시 코딩을 시작했다. 돌이켜보면 그 때의 나는 매우 즐거운 시간을 보냈던 것 같다.

나우누리 'OUD속의 세상' 에서 활동하며 몇차례 업데이트도 진행했었고, 베타테스터 분 중에서 한분이 맵(존) 제작에 참여하고 싶다고 하셔서, 부랴부랴 조악한 인터페이스의 맵에디터를 만들어서 협업도 진행하고 즐거웠었다.

시간히 흐를수록 아무래도 너무 무작정 만들어서 그런지 한글입력 버그라던지 화면스크롤이 버벅인다거나 전반적인 시스템이 엉망이라고 느껴졌다. 라이브러리 선정에 대한 문제와 구조적 설계에 대해 어떠한 깨달음을 얻게 되면서 전체적으로 싹 뒤엎고 싶어졌다.

그리고는 새롭게 '영웅천하' 라는 이름으로 다시 개발을 시작했다. 과거 '천상천하' 의 구조적 버그 등을 해결하고, 맵, 몹,아이템 에디터 등도 만들었는데.. 정작 맵이나 아이템을 만들기 귀찮아 지고 아이디어가 고갈되며 점점 개발의욕이 저하되어 중단하게 되었다. 온라인에 공개되지 않은 채 하드디스크 속에만 남아 있다가 현재는 유실되어 버렸다.

사실상 껍데기만 만들고 알맹이가 없는 셈인데 아마도 지금 생각해보면 창의적인 컨텐츠 생산에 대한 어려움을 느낀게 아닌가 한다. 그렇다. 가장 중요한 것은 프로그래밍도 그래픽도 아닌 바로 컨텐츠 였던 것이다.

아무튼, 그 때의 나는 꿈과 열정이 있었고, 충분한 시간이 있었다. 지금도 가끔씩 옛 생각을 하다보면 나우누리 'OUD속의 세상' 에서 활동하던 시절이 그립다.

언젠가 여유 시간이 생긴다면 웹이나 모바일버전으로 한번 리메이크 해보고 싶어진다. (아무도 관심있는 사람이 없겠지만...)

여기저기에서 OpenAI의 ChatGPT에 대한 이야기들이 많이 들려오고 있다. 아직 한국어 인식은 좀 떨어지는 것 같지만서도... 질문을 하면 해결책을 제시해 주거나 기사를 요약한다거나 하는 등 AI의 엄청난 발전에 정말 놀라게 되었다.

AI스피커에서 느꼈던 허술한 대화와는 전혀 다른 감정이다.

ChatGPT의 프롬프트를 이것 저것 입력해 보며 신기해 하다가 갑자기 어린시절의 기억이 떠올랐다. 내가 처음으로 컴퓨터라는 것을 알게 되었을 때 이러한 인공지능을 기대했던게 아닐까?

지금으로부터 약 30여년 전, 아마도 9살~10살 무렵이었을 것이다. 정확한 날짜는 기억 나지 않는다.

부모님께 게임기를 가지고 싶다고 떼를 썼더니, 부모님께서는 당시 전자회사에 다니시던 이모부에게 쓸만한 제품을 문의하셨고 내가 원했던 게임기는 아니었지만 금성 MSX 컴퓨터(8비트)를 사주셨다.

지금 인터넷을 검색해 사진 찾아보니 모델명은 GFC-1080 또는 GFC-1080A 로 추정 된다.

아이를 키우는 부모의 입장이 되어보니 사달라는 물건을 사준다는 것은 여러모로 어려운 일이다. 부모님 정말 감사합니다.

출처: https://www.msx.org/wiki/Goldstar_GFC-1080

출처: https://www.msx.org/wiki/Goldstar_GFC-1080

스샷의 PASOCALC 가 기억에 없는 것을 보면 아마도 저가형이었던 GFC-1080A 인 것 같다.

슬롯에 팩을 장착하지 않고 전원을 켜면 파란색 화면이 표시되었고, BASIC 이 실행 되었다.

또는 팩을 장착하고 전원을 켜면 게임이 실행되었다. (재믹스 게임팩과 호환이 되었기에 사실상 게임기로 주로 사용하기는 했었다.)

나는 제품과 함께 딸려온 매뉴얼 중에 MSX-BASIC 교재를 호기심에 천천히 넘겨 보았다.

? 4+2-1 
5
OK

이런 비슷한 형태로 물음표 ? 뒤에 수식을 입력하면 계산 결과가 나온다는 사실을 알게 되었다. 어린 마음에 나는 컴퓨터 물어보고 싶은게 생기면 ?를 입력하고 물어보면 되는 것이라고 생각하게 되었다.

그리고 몇단계 명령을 입력해주면 한글 모아쓰기 모드 같은 것으로 한글을 입력할 수도 있었다.

아무튼, 이것을 알게 된 뒤, 학교 숙제를 하다가 풀기 어려운 문제가 있었고, 나는 얼른 컴퓨터에게 물어보고 싶어졌다.

TV에서 만화를 보면 컴퓨터는 모든 것을 다 알고 있는 것 같았다.

나는 기대감에 사로잡혀 컴퓨터의 전원을 넣었다. 그리고는 물음표와 함께 문제를 한글로 입력하기 시작하였다. 문제가 기억나지 않지만 예를 들면 다음과 같았다.

? 과수원에서 철수는 사과를 20개 바구니에 담고 영희는 배를 30개 담았는데 어쩌구 저쩌구..... 그래서 남은 것은 몇 개 일까요?

그리고 당당하게 엔터를 입력했다. 하지만 결과는 이상했다.

영어를 잘 모르는 나로써는 이해 할 수 없는 아리송한 영어가 표시되었다.

어머니께서 항상 말씀하시길, 잘 모르는 것이 있으면 먼저 책이나 사전을 찾아서 스스로 해결해 보라고 하셨다.

그리하여 어머니와 함께 아버지 책장에 꽃혀 있던 영어사전을 펼쳐서 해석을 해보니 '구문이 잘못되었다' 같은 느낌이었고, 나는 이를 두고 '문제가 잘못 되었다' 로 해석하고는 '내가 문제를 못푸는게 아니라 문제 자체가 잘못된 것이다' 라고 정신 승리를 하게 되었다.

그러나 그 이후로도 여러가지를 입력해보았는데, 늘 내가 원하는 대답은 나오지 않았고 이상한 영어만 계속 나왔다. 아무래도 컴퓨터가 모든 것을 알고 있는 건 아닌 것 같았다.

시간이 흘러, 컴퓨터학원을 다니면서 GW-BASIC을 배우고는 알게된 사실이었지만 저 물음표 ? 는 PRINT 라는 명령어의 축약형이었고, 그 결과는 바로 Syntax Error 였다. 전혀 문법에 맞지 않는 형태로 작성을 했기 때문이었다.

바로 그것이었다. 컴퓨터는 명확하게 요구하거나, 그에 따른 수행하는 절차를 정확한 문법으로 프로그래밍 해주지 않으면 원하는 결과를 얻을 수 없었다. 그리고 세월히 흘러 지금까지도 그 생각은 크게 달라지지 않았었다. 결국 개발자가 구현한 대로 동작한다는 믿음이었다.

그런데 바로 ChatGPT로 인하여 컴퓨터에게 질문을 하면 제대로된 대답을 들을 수 있는 세상이 열린게 아닌가?

그 옛날 어린 꼬마가 컴퓨터를 만나고 상상했던 모습이 드디어 이제 눈 앞에서 실현되고 있는 시대가 온 것이다.

이 책은 읽기 시작하면 너무 재미있어서 단숨에 끝까지 읽게 되는 책이다.

• 이미지 출처: 교보문고

고대 컴퓨터의 역사와 유닉스의 탄생에 대한 에피소드들을 비롯해, 벨 연구소에서 벌어지는 수많은 고수들의 모습을 보고 있으면 흥미 진진하다.

벨 연구소에서 벌어지는 일들을 머리속에 상상하며 읽다 보면 나도 그 곳에서 함께 해보고 싶다는 생각이 든다.

이 책에는 유명한 많은 사람들이 나오지만 역시 강렬한 인상을 주는 사람은 '켄 톰프슨'이었다. 그의 천재성은 정말 놀랍다.

그는 OS나 프로그래밍언어 같은 것들은 그냥 내가 하나 만들어 볼까 하면 뚝딱뚝딱 만들 수 있는 사람이다.

아무튼 유닉스의 철학, 파일시스템, 쉘, 파이프, 정규표현식, 에디터 등이 발전해온 과정이라던지, 벨 연구소의 자유로운 분위기를 느끼고 싶은 분이라면 한번 읽어보기를 권한다.

나는 이 출판사와 정말 아무 관계 없는 사람이지만, 너무 재미있게 읽었기에 모두에게 추천하고 싶다.

인터넷에서는 PHP를 조롱하거나 무시하는 경우가 많다.

그러나 모두가 알다시피 전세계적으로 무수히 많은 사이트가 PHP로 구축되어 있다. 과거의 날코딩이나 HTML과 로직이 뒤죽박죽되는 개발방식을 버리고, 모던 PHP 개념을 따르게 되면 완성도 높은 웹서비스를 구현할 수 있다. 특히 PHP 8.0 부터는 정말 좋아졌다.

내가 PHP를 처음 시작한 때를 떠올려보면... 2000년대 초반. 초고속 인터넷 붐과 개인 홈페이지 개발이 유행을 하던 시절이었다.

홈페이지에 방명록이나 게시판 등을 달기위해서는 링크만 하면 되는 '슈퍼보드'같은 무료게시판이 존재했었고,

이보다 한 단계 수준을 높이려면 CGI를 지원하는 호스팅서비스에 CGI방식으로 구현된 오픈소스들을 가져다가 설치하곤 했다.

그러다가는 문득 내가 직접 만들어야겠다는 생각이 들었고, 서점에 가서 책을 한권 구입 하였다.

그 책의 제목은 클릭하세요 CGI와 PHP (윤석범 저; 대림; 1999) 이었다.

• 이미지 출처: 알라딘

이 책의 분량을 보면 Perl CGI가 거의 70% 였었고 30% 정도가 PHP에 대한 내용이었다. 사실 이때는 PHP가 뭔지 잘 몰랐었고 CGI라는 단어만 보고 구입한 책이었다. 그런데 몇일 간 책을 보면서 공부를 하다보니 Perl 보다 PHP가 어딘가 모르게 훨씬 좋아 보이는 것이었다.

실제 실행을 해봐도 CGI는 뭔가 조금만 잘못해도 무작정 500 에러를 띄우는데 비해서, PHP는 훨씬 유연하게 동작 되었다.

재미난 점은 입문자에게는 장점인 이 유연함이 나중에는 단점이 되어버린다.

그렇게 책을 통해 PHP의 기본기를 익히고나서는 PHPSCHOOL에서 정보를 얻으며 방명록, 게시판, 카운터, 투표, 회원관리 등 이런 것들을 하나씩 만들었고, 'Kerz Board'라는 식의 이름을 붙여가며 나만의 솔루션을 만드는 즐거운 시간들을 보냈었다. 그 후로 JSP, ASP도 맛을 조금씩 보긴했지만, 여러가지 사정으로 웹개발에 흥미를 잃게 되었다.

세월이 흘러.. 나는 공공도서관에서 일을 하게 되었다. 그리고 어느날 새로 들어온 책 중에서 라라벨(Laravel) 과 관련된 책을 우연히 보게 되었다.

그 책은 라라벨로 배우는 실전 PHP 웹 프로그래밍 (김주원 저; 제이펍; 2016) 이라는 책이었는데, 대충 훑어 본 것 만으로도 내가 알고 있던 PHP와는 다른 모습이었고, 라라벨 프레임워크가 굉장히 멋지다는 생각이 들었다.

일단 한권 소장해야겠다는 마음이 들어서 부랴부랴 구매를 하였지만, 공공도서관에서의 나의 업무는 IT 인프라 운영관리가 주력이라 개발과는 거리가 멀었고, 한동안 먹고 살기 바빠서 취미삼아라도 볼 일이 없었다. 거실의 책장에 꽃혀 먼지만 쌓여가고 있었다.

그러던 어느날, 오랜만에 1인 개발로 웹서비스를 구축해야 할 일이 생겼다. 어떤 프레임워크를 선택할까 하던 도중 가장 먼저 생각난 것이 라라벨이었다. 스프링은 괜히 장황한 느낌이고, 간편하고 혼자 빠르게 개발하기에는 라라벨이 좋아 보였다. 그리곤 책장에 꽂혀있던 그 책을 다시 꺼내 들었다.

그렇게 마주하게 된 라라벨은 커다란 만족감을 주었다. 서비스에 필요할 만한 요소들은 프레임워크안에 대부분 내장되어있고 간단히 적용가능한 패키지들이 많았다. 인증, 스케쥴러, 큐, 워커 등도 내장 되어있는 진정한 의미의 풀 스택 프레임워크 였다.

혼자서 프론트엔드/백엔드를 나눠서 만들게 되면 회의감이 들 때가 있다. 2인 이상이 할 때는 REST API의 강점이 있지만, 혼자 개발 하는 경우에는 한 단계가 레이어가 더 추가 되는 느낌이다. 그런데 라라벨과 Inertia를 결합하면 REST API없이 Vue나 React 화면을 라라벨의 데이터와 쉽게 연동하여 동적으로 갱신 할 수 있다.

물론 인원을 충원할 계획이라면 귀찮아도 분리해서 개발하는게 좋을 수 있다. 하지만 빠른 결과물이 목적이라면 Inertia를 추천하고 싶다.

아무튼, 모두의 우려와는 달리 PHP는 건재하며, 라라벨은 완성도 높은 프레임워크라는 것이다.

The illiterate of the 21st century will not be those who cannot read and write, 
but those who cannot learn, unlearn, and relearn.

21세기의 문맹은 읽고 쓰지 못하는 사람이 아니라, 
배우고, 배운 것을 일부러 잊고(unlearn), 다시 배우는(relearn) 능력이 없는 사람일 것이다.

- 앨빈 토플러 (Alvin Toffler) -

---

40대에 접어 들어 다시 공부를 집중하기 시작하였다.

그러다보니 요즘 느끼는 것이 참 많다.

• 새로 공부해야 할 것들이 세상에 정말 많음
• 안다고 생각했던 것이 제대로 알고 있는게 아니거나, 시간이 지나서 더 이상 올바른 지식이 아님
  • 수금지화목토천해명
  • 공룡조류설
• 기억의 오류

과거에는 이미 알고있있는 부분이라고 생각하면 적당히 넘기면서, 잘 모르는 부분이나 특정 부분만 찾아서 공부했던 것 같다. 그런데 이제는 공부하는 방식을 바꾸기로 했다.

'나는 아무것도 모른다', '내가 알고 있는 지식이 잘못되었을 수도 있다.' 는 생각으로 기초부터 다시 배우기로 마음 먹었다.

안그래도 나이 탓인지 예전보다 집중력도 떨어지는데, 기초부터 차근차근 하다보니 학습의 속도가 느린 부분은 있다.

하지만 분명히 좋은 효과가 있다는 느낌이 온다.