기무춍상 003 – 기무춍상은 실력이 있다고 착각을 할 뿐, 5년이고 10년이고 실력이 늘지 않습니다.

일본 it 취업에서 제일 뭣같은 것이… 일본인들 기준으로, 신입은 진짜 기본만 하고 와도 우와~ 소리 듣는다는 겁니다. 그걸 회사에서 열심히 키우고 같이 시키고 해나가면서 만들어갑니다. (블랙기업 제외합니다.) 이공계에 처음부터 it를, 프로그래밍을 할 줄 아는 애들은 다른 코스입니다만 그런 경우가 아니라면 대게 그런 케이스가 많습니다.

근데 한국에서 국비교육 받아서 일본 오거나 그런 경우에 대다수가 교육 비중이

일본어 < IT

일 정도로 IT를 더 많이 가르칩니다. 일본어는 JLPT 기준으로 N3만 되어도 되니 어쩌니 합니다. 그렇게 해서 연계된 기업들과 취업을 시키려 하는데, 그 기업들도 일본어 낮아도 된다 하는 쪽은 거의 100% it 관련 질문, 프로그래밍 질문 엄청 시킵니다. 한국 중소기업에서 시킬 정도는 다 시켜요.

그러다 보니 자기들은 실력으로 합격한 거라고 이야기 합니다. 일본어는 N3인데 말이죠.

그렇게 해서 일본으로 넘어옵니다. 당연히 배운지 얼마 안되었으니 말 하면 어느정도 알아 듣습니다. 당연히 그런 거 알아듣는지 아닌지 보는 회사를 면접봐서 가는 거였으니깐요.

그렇게 일본어 어정쩡하게 되고, 실력은 그만한 곳에서 좀 하다보니 나 it 일 할 수 있어~ 하고 있어~ ㅇㅇ. 내가 몇년차 사람들하고 잘 해~ 하지만….

그런쪽 일은 생각보다 누가 와서 해도 되는 일인 경우가 많거나, 아니면 그냥 돌아가기만 하면 된다거나 하는 그런 일들이었던 것입니다. 진짜 핵심은 다른데서 개발하거나, 스타트업들이 따로 만들거나, 컨설팅을 받거나 그러고 있었거든요.

자, 그럼 이렇게 된 기무춍상은 어떻게 되는 걸까요?

어정쩡한 일본어 실력 + 그냥 고만고만한 채 시간만 몇년 먹음 = 제자리걸음

잡다하게 많이 할 줄 아는 것이 생겨서 실력이 는 거 아니냐고 하는 건 말이죠… 그냥 지식량 많은 다른 누군가가 한두번 배우면 배울 수 있는 거에요.

이렇게 기무춍상이 생깁니다. 그리고 이런 업계인들 생각보다 많이 양산되다가 한국 돌아갔다고 들었습니다.

기무춍상 002 – 일본에서의 스타트가 살짝 어긋난 건 바꿀 수 있습니다. 근데 그들은 그러지 않습니다.

일본it로 취업 막 들어왔을 때, 자기가 간 회사가 블랙인지 아닌지에 대한 판단은 좀 늦어도 됩니다. 근데 중요한건 거기에서 잘 어울리면서 일을 할 수 있냐 아니냐부터 시작해야 합니다. 가뜩이나 it 하겠다고 하던 분들중에는 배울때는 재밌게 배웠다가도 실제로 회사에서 일로 하면서 아 아니구나 하고 돌아가는 분들도 많으니깐요. 게다가 해외에서 일한다? 더더욱 높은 벽부터 부딧히고 시작하는 겁니다.

그래서 생각 이상으로 제대로 알지 못하고 취업해서 블랙기업에서 시작했더라도 본인 하기에 따라서는 여러모로 길을 다시 모색해서 더 좋은 회사로 가기 위해 계속 뭔가를 하거나 할 수 있습니다. 제가 아는 분이 취업 컨설팅 이야기 하는데 들어보면 진짜 아무것도 안되어있는데 무작정 왔다가 제2신졸 전직하고 그러는 케이스도 많다고 하더군요. 그런데 전직을 위한 과정에서도 그들은 벽을 느낀다고 합니다.

일본 취업을 제대로 알아보지 않고 그냥 취업연계 같은 걸로 들어온 기무춍 레벨에서는 일본 내에서의 전직 시스템을 이해하는 것이 거의 불가능하더군요. 경력 1년 내외면 거의 제2신졸이라고 해서 졸업 후 1,2년 이내의 사람들을 신입처럼 다시 시작시켜주는 제도로 재취업을 노리는 쪽이 정답입니다. 기업들도 그렇게 하고 실제로 1,2년 정도의 그걸 경력으로 인정을 안해줘요. 근데 기무춍 같은 애들은 이미 블랙으로 들어와서 착취당할 예정이었기 때문에 비자도 짧습니다. (그냥 기본 1년짜리 받고 오는 듯 하더군요) 그럼 비자 갱신부터 하고 나서 알아봐야 할 일을 이런 저런 거 다 부정당하고 할 거 많이 부딧힌다고 해서 씩씩거리기 시작합니다. 미치는 거죠.

근데 이정도는 그냥 살짝 어긋난 거라고 봐야 합니다. 내 국가도 아닌 곳에서의 생활이니깐요. 허들 더 어려운 거 맞습니다. 실제로 제2신졸로 잘 되는 케이스도 적지 않고요. 어쩌다가 다른 걸로 잘 자리잡고 살기도 하고요. 케바케가 많은데.. 그들은 그런 걸 못합니다. 그러다가 돈 까먹고 한국 가는 거죠. 게다가 실력이 제대로 있는 것도 아니니 한국 가서도 힘들꺼고요. (실력이 없는 것은 이유를 알려드리겠습니다.)

만약 본인이 뭔가 좀 꼬인 거 같다. 그래도 객관적으로… 최대한 객관적으로 보면서 어떻게 앞으로 살아갈지 고민하고 해서 수정할 수 있는 방향을 찾아보면 뭔가 방법이 있기 마련입니다.

의외로, 공식 문서를 이해하는 게 더 빠른 해결책이 될 수 있습니다.

제가 이번에 좀 여러모로 삽질을 하게 된 일이 있는데…. 삽질하면서 검색을 안해본 게 아닙니다. 그런데, 블로그 정보나 유튜브로 영상 올려놓은 정보는 생각 이상으로 제각각인 경우가 많습니다. 오래되어서 참고가 될 수 없다거나, 자기만의 방식으로 설명하거나, 지금은 지원 안되는 서드파티를 사용한 특수한 코드거나, 강의용이거나…

다양한 이유로 이용하기 어려운 것이 정말 많다는 것을 느꼈다.

근데 이럴 때일수록, 공식 문서를 뒤져서 이런 기능이 있는지부터 찾아보거나, 이렇게 이용할 수 있는 무언가가 있는지를 우선 찾아봐야 한다. 그렇게 안되면 그때부터 머리 써서 만들어야 하는 것이 된다.

생각보다 많은 기능들이 개발에 필요할 거 같아서 만들어진 기능들이 많이 존재한다. 그걸 제대로 써본 적이 없거나 해서 그렇지.

설치, 운영에 대해서도 생각보다 자세하게 적혀있는 내용 또한 많이 존재한다. 특히 고급, 전문 기술의 프로그램들일수록 환경 의존적이거나, 환경에 따른 확장 가능성이라던가 하는 게 정말 많아서…

서드파티를 쓴 다고 해도 서드파티에서 제공하는 공식 문서가 기본 베이스이다. 그 외에 기능에 대해서 검색하거나 새로 만드는 건 그렇다 쳐도, 이미 어느정도까지 제공해주는지조차 모르는 상태에서는 제대로 된 판단을 하기 어렵다.

그래서 공식문서가 생각 이상으로 이해가 되거나 도움되는 경우가 정말 많다. 가끔 공식이 이상한 특수한 것들이 있긴 한데…. 그건 좀 예외다만, 그런 것들은 생각보다 오래 못가는 경우가 많으니 패스.

QEMU를 이용하면 임베디드 하드웨어 에뮬레이팅이 접근하기 쉽습니다.

저는 요즘 개발에서는 한 발 뒤로 빠져있는 입장이긴 한데, 그래도 여러모로 개발 관련 질문을 여럿 받습니다. 지금까지 해온 것도 있고 해서..

특히 임베디드를 좀 오랫동안 해왔고, 주변에 여전히 임베디드 하는 선배분들도 많고, 극소수지만 임베디드 하겠다고 하는 애들도 많이 보는데….

하드웨어 구매하기 좀 애매한 사정의 친구들이 보일 때가 있습니다. 그럴 때에는 그냥 전 QEMU를 이용하여 에뮬레이션 하는 방법을 알려주곤 합니다. QEMU 자체는 가상화되 지원하지만 CPU 아키텍쳐를 에뮬레이션 해주기도 하기 때문에 다양한 환경 기반으로도 작업을 해볼 수 있기 때문입니다.

뭐 하드웨어 가격 얼마나 한다고 하겠지만, 해보신 분들 아실 껍니다. 하드웨어 하나만 삽니까? 이것저것 뭐 한다고 더 지르고 그러면서 생각 이상으로 지출 많이 생기는 거 뻔한데….

기회가 되면 직접 돌려보는 것도 좋겠지만, 저는 아직 힘들면 우선 RTOS 같은 것들을 가르칠 땐 QEMU를 통한 환경으로 가르쳐 주는 것도 좋은 방법이라고 생각해서 관련 노하우를 전달해주곤 합니다. FreeRTOS 같은 녀석 이용할 때 QEMU 쓰는 게 얼마나 편한데요. 특정 타겟팅 환경 에뮬레이션 해서 이용하는 것도 편하고요.

…이참에 노하우로 정리해야 할 것들이 계속 늘어서 큰일입니다.

기무춍상 001 – 기무춍이 되기 위한 조건

왜 이거부터 시작할까 싶은데… 이거 시작글에서 적었다. 사람만 다를 뿐이지, 같은 조건으로 같은 루트를 타고 일본으로 들어와서 같은 절차를 밟고 그대로 한국으로 리턴하는 케이스다. 그렇다면 그사람들은 거의 대부분이 기무춍이 되기 위한 조건을 가진 상황이라는 거다.

유학에 대해서 많은 사람들이 도피성으로 유학을 하는 경우가 많다. 근데 취업을 도피성으로 하는 경우를 볼 거라고는 난 생각도 못했다. 한국에서 취업이 안되는 정확한 이유에도 본인이 포함 안되면서 당연하게 난 안될꺼야 하고는 일본취업으로 방향을 틀었다는 애들이 많다. 이게 좀 웃긴데… 한국에서도 일을 했고, 미국에서도 일을 했고, 일본에서도 일을 하면서도 느꼈지만 일은 어느 나라에서 해도 큰 차이 잘 안났고(업무 내용은 차이가 났지만 업무 환경과 태도를 말하는 거다.) 일본에서 못하는 거면, 한국에서도 못한다. 그러니 취업은 도피성으로 하는 것이 아닌데… 어이없는 상황이다. 근데 생각 이상으로 많다. 그리고 그런 사람들이 국비나 붓캠으로 일본취업 연계까지 가서 보니 블랙이었다 그런 소리 하더라.

저기에 실력도 어정쩡하게 있는 스타일은 일본 취업을 도전이라고 생각합니다. 일본에 개발 능력이 없다고 생각하니깐요. 실제로 없는 곳도 있습니다. 이건 나중에 잡소리쯤에서 따로 설명하거나 하죠. 한국에서는 제대로 된 곳 취업도 못하는 수준인데, 일본에선 대기업으로도 갈 수 있다는 그런 느낌? 으로 뭔가 옛날에 다큐도 있었죠. 그게 실력있는 대기업인지는 차차 나중에 보기로 하고… 뭐 그런 것들 때문에 한국에서 실력 출중하게 보고 당장 쓸만한 경력직 혹은 그에 준하는 수준으로 뽑으려고 하다보니 이쪽도 도피를 합니다.

그리고 마지막으로, 굉장히 어정쩡한 인간관계에서 발생합니다. 근데 이건 딱 집어서 뭐라 하기 어렵군요. 알고보니 그랬다 케이스가 많네요. 그리고 그들한테는 당연한건데 다른 부류한테는 당연한 게 아니고.. 말하면 싸움만 나니 이건 그냥 그렇다고만 알아두세요.

이게 왜 조건이냐고 물었을 때, 해답은 간단합니다. 일본 취업에서 제일 중요한 자기 분석이라는 게 전혀 안되는 사람들의 특징입니다. 그래서 정상적인 일본 취업 루트를 제대로 타지 않는 상황에서 쉬운 방법으로 일본에 들어와 블랙기업을 입사했습니다. 어떤 과정인지는 더 자세히 쓸 일이 있겠으니 넘기겠습니다. 그런 상황에서 회사 탈출을 위해서 여러모로 노력을 해야 하는데… 저런 것이 깔려있는 상태에서 전직(일본에서는 이직도 전직이라고 표현합니다.)을 하던 제 2 신졸(대학 졸업을 최근에 한 경력 1,2년 짜리를 신입으로 취급해주는 취업 시스템)을 하던 뭔가를 노력해서 해야 하는데 그 노력은 별로 하기 싫은 상태가 되었으니… 귀국하던 일본에서 더 어이없는 선택을 하던 합니다. 그런 것들이 한인사회 욕쳐먹게 하는 짓들의 원인이 되죠. 귀국은 상관없습니다. 한국에서 it 취업을 다시 하던 다른 분야 취업을 하던 어떻게던 살겠지만, 더 어이없는 선택을 통해서 기무춍이 되는 과정으로 들어오는 거죠.

꼭 기억하시기 바랍니다. 취업이라는 거 자체로도 현실적인 자기 삶이 결정되는 것인 만큼 중요하고 신중하게 해야 합니다. 거기에 해외 취업은 더더욱 신중하게 해야 하고, 밖으로 나오면 의지할 수 있는 사람 있어도 그사람만 믿으면 안됩니다. 진짜 ㅄ되기 십상입니다. 그리고 도망치지 마세요. 기무춍이 되고 나서는 이미 늦었습니다.

기무춍상 000 – 왜 이 시리즈는 만들어졌나…

지금 많이 잃어버려서 어찌 할 지 좀 고민인 Oh! 반면교사는 아주 쌩 패악질의 기준이었던 미국에서 겪은 한국인 오모씨 이야기를 거의 각색했다. 그러면서 하면 안되는 짓에 대한 반면교사를 쓰고 싶었다. 이전 글들을 잃어버려서 이거 어찌 할 지 여러모로 고민중이다.

근데, 이 기무춍상은 왜 시작하냐고 하면… 일본 IT 취업에서 보고 있는 개막장 스토리를 투영하고 싶었다. 솔직히 여기서 적응 잘 해서 나가는 사람들 많은데, 그분들 이야기가 아니다. 상당히 많은 사람들은 일본으로 넘어오는 이유가 일본이 취업 잘된다는 이유 + it는 취업 더 잘된다라는 걸로 해서 넘어와서는 온갖 병신같은 일을 당하거나 저지르거나 해서 2,3년 하다가 귀국하고는 한국에서 경력자로 인정받으려고 하는데, 현실은 진짜 미안하지만 개판인 케이스를 너무 많이 들었고, 나도 좀 봤고, 제대로 정착해서 사는 사람들 통해서도 들려오는 이야기가 너무 많았다.

그것도 엄청 정형적이다. 똑같은 패턴으로 들어와서 똑같은 패턴으로 망하고 귀국후에도 똑같은 패턴이라는 것이다. 진짜 신기할 정도로 똑같은 이야기들이 엄청나게 많이 나온다. 어디서 실패하는 법을 똑같이 배워오는 듯 하다고할 정도로… 가끔 보면 볼수록 스트레스 받는다. 술안주거리로 흘려들으면 좋겠는데, 기무춍 같은 것들이 있다 간 클라이언트를 만났을 때 내가 한국인인 것을 알게 된 순간 그들의 태도가 변한다는 걸 직접 경험하는 것이다. 스트레스를 받는 이유를 알겠는가?

나는 성공 케이스는 그렇게 이야기 할 필요 없다고 생각해서 솔직히 성공 이야기는 잘 안쓴다. 잡소리에도 안쓴다. 그런 거 보면 결국은 좋은 타이밍에 자기가 뭔가를 할 수 있을 정도로 안에서 열심히 살아왔던 사람들이 좋은 타이밍에 기회 잡고 잘 되는 케이스인데… 누구나 다 그럴 수 있냐고 하면 또 아니다. 그냥 위인전 읽고 나도 저렇게 될꺼야 한다고 해서 그게 되나?

근데, 실패 케이스는 정말 많은 데다가…. 제발 이런 인생 살지 말아야 된단 걸 보여줘야 한다고 본다. 그러면서도 나도 이딴 식으로 되고 싶지 않다. 제목인 기무 춍부터 한국인 멸시다. 일본 안에서도 제대로 인정받는 한국인들은, 제대로 자리잡고 생활하는 한국인들은 이렇게 불릴 일도 없다. 뭐 그렇다고 일본 회사들이 일본 사회들이 잘하냐고 물으면 그것도 아니라 거의 양쪽을 다 까는 스토리도 있을 것이다. 미국은 비자에 대한 허들이 좀 많이 높기 때문에 미국 같은 곳에서 병크 저지르는 것은 거의 그 개발자 자체를 까면서 하지 않아야 할 일을 서술하게 되겠지만.. 이 글에서는 그 개발자 자체만을 까진 않을 거 같다.

Javascript 스터디 – 002 여담: 옛날 Javascript를 보여주지…ㅡㅅㅡ

내가 하나하나 진행하면서 글 쓰려고 했는데… 옛날에 자바 스크립트 쓰는 거 진짜 더러웠다고 하는데 안믿는 애들이 있어서 옛날에 쓰는 방식을 보여줬다. 그리고 그 내용을 여기서도 보여주려고 한다.

옛날 자바스크립트는 자바스크립트와 호환되지 않는 브라우저가 스크립트 부분을 html의 일부로 그냥 화면에 표시해 버리는 것이 빈번하게 존재했다. 그래서 반드시 head 태그 안에 script를 별도로 작성하였다. 그럼에도 불구하고 내부에 js 코드를 넣으려면 어떻게 했냐고? html 주석과 섞어서 처리했다.

<script>
<!-- 
document.write("hello");
-->
</script>

이런 식으로 처리해버리면 js가 처리되는 코드에서는 실행되고, 안그러면 그대로 html의 주석 처리가 되어서 실행되지 않는 것이다. ㅡㅅㅡ 게다가 noscript라는 태그도 존재한다. 이런 걸 이용해서 처리하면 js에 대응하지 않는 브라우저로는 별도의 표시가 되도록 하는 형식이다. 위에 것에서 추가한다면… 이런 것이다.

 <script>
<!-- 
document.write("hello");
-->
</script>
<noscript>
This browser dosen't corrspond to js.
</noscript>

….아 진짜.. 이거 생각하니 열받네. 이거 언제부턴가 head에서도 쓸 수 있게 되어있다. 그래서 이거 쓰는 건 좀 조심해야 한다. 게다가 여전히 xhtml에서는 이용 안된다.

근데 요즘은 js 동작 안할때를 위해서라면서 html 알려줄 때 알려주는 걸로 아는데, 요즘 브라우저에서 아직도 안되는 게 있나…? 싶을 정도이다. 뭐 써서 안전하다면 그냥 쓰던가. ㅡㅅㅡ

그리고 js의 옛날 특징이라고 하면… language, text를 별도로 지정해서 이용하였던 것이라고 생각한다. 바로 이런 식으로 말이다.

vs code가 암말도 안한다. 아직도 적용되는 녀석이라는 거다.

내가 배우기 이전에는 이렇게 해서 js1.2 지원 브라우저에서만 이용되게 하려고 이렇게 했었다고 한다.

근데 내가 배울 땐 이렇게는 안배웠고…. type로 배웠지. 이렇게 배운 사람들 장난 아니게 많을 것이다. 옛날부터 엄청 오래 써오던 CMS 시스템들이 아직도 이런 js 코드가 많이 남아있을텐데…

이렇게 처음으로 배운 분들 많을 것이다.

여기에 이벤트 핸들러(onClick 같은것들)에 기술한 스크립트에 대해서도 종류 지정을 할 수 있었기 때문에, html의 헤더에다가 meta를 지정해서 이용하는 것도 있었지…

이런 것들이 아직도 쓰이긴 하지만…. 요즘은 그나마 나아졌다고 생각한다. 이것 조차 불필요하게 되어서, 이젠 그냥 규정치로써 js가 그냥 당연하게 이용되니깐. 타입스크립트 같은 경우에는 개발 환경 구성 단계에서 타입스크립트를 이용한다고 지정만되어있으면 그냥 그대로 사용되기도 하고….

그래서 이런 이야기 하면서 세월 좋아졌다고 하면 나이 든 티가 날 것이다. ㅡㅅㅡ

Filesystem in Userspace와 AppImage

Filesystem in Userspace(FUSE)는 커널이 아닌 사용자 공간에서 파일 시스템을 구현할 수 있게 해주는 소프트웨어입니다. FUSE는 Linux 커널 모듈과 사용자 공간 라이브러리로 구성되어 있으며, 이를 통해 사용자는 자신만의 파일 시스템을 쉽게 만들 수 있습니다.

FUSE의 주요 특징은 다음과 같습니다.

  1. 사용자 공간에서 실행: FUSE는 파일 시스템 코드를 사용자 공간에서 실행할 수 있도록 해줍니다. 이는 파일 시스템 개발을 더 쉽게 하고, 커널 크래시 없이 개발 중인 파일 시스템을 테스트할 수 있게 합니다.
  2. 다양한 언어 지원: FUSE는 C, C++, Python, Java 등을 포함한 다양한 프로그래밍 언어를 지원합니다. 이는 개발자가 익숙한 언어를 사용하여 파일 시스템을 구현할 수 있게 합니다.
  3. 유연성: FUSE를 사용하면 다양한 종류의 파일 시스템을 쉽게 구현할 수 있습니다. 예를 들어, 원격 서버의 파일 시스템을 로컬에 마운트하거나, 데이터베이스를 파일 시스템으로 사용하는 등의 작업이 가능합니다.
  4. 보안: FUSE는 사용자 공간에서 실행되므로, 커널 공간에서 실행되는 전통적인 파일 시스템에 비해 보안상의 이점을 가질 수 있습니다. 이는 버그나 악성 코드로부터 시스템을 보호하는 데 도움이 됩니다.

FUSE의 동작 방식은 다음과 같습니다.

  1. 커널 모듈: FUSE는 먼저 커널 모듈을 통해 파일 시스템 호출을 인터셉트합니다.
  2. 사용자 공간 라이브러리: 인터셉트된 호출은 사용자 공간으로 전달되며, FUSE 라이브러리가 이를 처리합니다.
  3. 파일 시스템 구현: 사용자는 FUSE 라이브러리를 사용하여 파일 시스템의 동작을 정의합니다. 이는 파일 읽기, 쓰기, 삭제 등의 작업을 포함합니다.

FUSE는 특히 개발자들이 새로운 파일 시스템을 빠르고 쉽게 개발할 수 있도록 도와주는 강력한 도구입니다. 이를 통해 다양한 파일 시스템 실험과 구현이 가능해지며, 이는 Linux의 파일 시스템 확장성과 유연성을 더욱 강화합니다.

이렇게 좀 사전적인 의미로 FUSE를 설명해 드렸습니다. 근데 왜 이걸 이렇게 설명하냐면…. AppImage라는 형태의 프로그램들을 설명하기 위해서 그렇습니다.

요즘 제가 몇몇 프로그램을 받아서 리눅스에서도 써보고 있는데, AppImage라는 녀석으로 받을 경우에 어떻게 실행하라고는 쉽게 나와있습니다. Property에서 보면 이걸 프로그램으로 인식해서 실행하라고 체크박스가 있는데, 그걸 체크하여 설정한 후에 그냥 더블클릭하면 실행할 수 있습니다만, 이걸 왜 이렇게 해야 하는지에 대한 설명이 모자라더군요. 그 기반이 되는 녀석이 바로 FUSE입니다. 그리고 이녀석이 AppImage와 어떻게 연관되어있는지도 설명을 좀 사전적으로 해보겠습니다.

FUSE(Filesystem in Userspace)와 AppImage는 서로 다른 목적을 가진 두 가지 기술이지만, FUSE가 AppImage의 작동에 중요한 역할을 합니다. 이 두 가지가 어떻게 연결되는지 설명드리겠습니다.

AppImage

AppImage는 Linux 시스템에서 소프트웨어를 배포하는 포맷입니다. 이를 통해 하나의 실행 파일로 소프트웨어를 배포하고 실행할 수 있습니다. AppImage는 소프트웨어 설치를 필요로 하지 않으며, 단일 파일로 제공되어 사용자가 클릭하여 실행할 수 있습니다. 이는 특히 소프트웨어 배포를 간단하게 하고, 다양한 Linux 배포판에서의 호환성을 보장합니다.

FUSE와 AppImage의 연결

AppImage는 FUSE를 사용하여 파일 시스템을 마운트하고, 이를 통해 소프트웨어를 실행할 수 있습니다. 구체적으로, AppImage는 내부적으로 압축된 파일 시스템을 포함하고 있으며, 이를 FUSE를 통해 임시 마운트하여 소프트웨어를 실행합니다. 다음은 그 과정에 대한 자세한 설명입니다:

  1. AppImage 실행: 사용자가 AppImage 파일을 실행하면, 이 파일은 자체적으로 포함된 파일 시스템 이미지(압축된 파일 시스템)를 마운트하려고 시도합니다.
  2. FUSE 사용: AppImage는 FUSE를 사용하여 파일 시스템 이미지를 임시로 마운트합니다. 이를 통해 AppImage 내부의 모든 파일과 디렉토리가 접근 가능해집니다.
  3. 소프트웨어 실행: 마운트된 파일 시스템에서 소프트웨어를 실행합니다. 이 과정에서 필요한 라이브러리와 리소스는 모두 마운트된 파일 시스템 내에 포함되어 있어, 시스템에 추가적인 설치나 설정 없이 소프트웨어를 실행할 수 있습니다.
  4. 마운트 해제: 사용자가 소프트웨어를 종료하면, FUSE를 통해 마운트된 파일 시스템은 자동으로 해제됩니다. 이는 시스템에 잔여 파일이나 설정이 남지 않도록 합니다.

간단 요약

  • FUSE: 사용자 공간에서 파일 시스템을 구현하고, 안전하게 파일 시스템을 마운트 및 해제하는 기능을 제공합니다.
  • AppImage: FUSE를 사용하여 내부에 포함된 파일 시스템 이미지를 임시로 마운트하고, 이를 통해 소프트웨어를 실행합니다.

이러한 연결 덕분에 AppImage는 설치 과정 없이도 복잡한 소프트웨어를 쉽게 배포하고 실행할 수 있는 편리한 방법을 제공합니다.

자, 좀 간결하게 이해가 되었을까요? 이렇게 해서 AppImage로 배포되는 프로그램들이 조금씩 늘고 있고, 여러모로 사용되고 있습니다.

Javascript 스터디 – 001 개발도구와 개발 환경, 그리고 hello world

진입장벽이 제일 낮은 곳 아닐까 하는 생각이 든다. 솔직히 그냥 메모장과 웹 브라우저만 있어도 가능하다. 대부분의 실행과 디버그는 웹 브라우저에서 다 진행할 수 있다.

뭐, 메모장은 그래도 좀 그러니깐 그냥 에디터를 이용하자고 하자. 웹은 각종 여러 언어들을 섞어서 개발하다 보니 IDE(통합 개발 환경)으로 나오는 경우가 별로 없다. 있어도 거의 대부분 플러그인 떡칠이다. 그럴꺼면 그냥 에디터 써도 될 정도다. 내 경우에는 주로 Visual Studio Code를 이용한 것을 보여줄 것이다. vim, emacs,인텔리, 에디트플러스 등등 그냥 편한 거 쓰면 된다. 뭐가 좋냐고 물으면 그냥 쓰기 편한 게 좋다고 할 것이다.

그리고 실행과 디버그 자체가 그냥 웹 브라우저를 이용하기만 하면 되기 때문에 그렇게 어려운 것이 없다. 직접 만든 코드를 웹 브라우저에서 돌려보기만 하면 되니깐.

그래서 바로 hello world를 만들어서 보여주려고 한다. code를 열어서 html 페이지를 아래와 같이 하나 만들었다.

그냥 진짜 hello world.

script라고 되어있는 곳에 옛날에는 자바스크립트라고 정의해주고 하는 내용을 넣고 해야 하는데… 요즘은 그냥 저렇게 해도 된다. js가 거의 표준 아닌가 싶을 정도로 널리 쓰이고 있으니깐… (타입 스크립트 이야기 하고 싶으면 나중에 다른 기회를 보자.)

그래서 저 html 파일을 실행하고, 브라우저의 개발자 모드를 보면 아래처럼 hello world가 표시될 것이다.

근데 지금 내가 hello world를 두 군데에 넣어서 뭐가 뭔지 몰겠다 싶으면, 코드 수정하고 저장해보자.

단순 무식한 구분 방법. ㅡㅅㅡ

이렇게 그냥 무식한 방법으로 구분이 되게 했으니 결과는… 무식하게 나온다.

무식하지만 효과는 좋게 나온다. 그래서 난 무식하게 알려주는 걸 좋아한다.

이제 하나하나 다시 시작해보자.

Javascript 스터디 – 000 회기, 그리고 다시 정리

줄여서 js라고 하던데.. 만난 건 엄청 오래전이다. 근데 내가 쓸 때의 js는 진짜 그냥 웹 페이지를 동적으로만 만들어주고 하는 데 이용하던 스크립트 중 하나였다. 거의 2006~2008년부터 만나기 시작해서 알게 된 녀석인데….

이 때 이용자들은 알 것이다. 사이트가 동적으로 움직일 수 있다는 것만으로도 자바가 엄청나게 각광받고, js가 그 자리 안에서 조금씩 발전하고 있는데 각종 알 수 없는 warning 띄우고 할 때에 보면 꼭 이녀석이 난리치고 있던 것도 있고… 뭔가 html 코드 안에서 난잡하게 돌아가고 그런 것들. 그리고 사이트 느리게 만드는 주범 중 하나였고… (그때 뭐 알고 했나.) 그러면서 브라우저끼리 호환도 잘 안되던 과거가 있질 않나… 거기에 더해서 웹 사이트에서 복잡한 기능을 넣고 하질 않았기 때문에 js 코드들도 간단했기 때문에 js 하는 것 = 그냥 왕초보 이런 느낌이었던 시절이다.

근데 지금 와서 웹 하는 데 보면 죄다 js가 기본으로 깔려간다. 웹 클라이언트에서 js 빼고 이야기 못할 정도다. 언어 자체의 성능도 발전하고 jit도 도입되면서 실행 속도도 엄청 빠른 편이다.

게다가 요즘 웹 개발이 주를 이루고 그에 따라 엄청 복잡해지면서 수요도 엄청 늘고, 나같은 임베디드 하던 인간들도 최소한의 설정 작업 만드는 것도 이젠 웹 베이스로 만들어 줘야 하는데 이런 곳에서도 어느정도 알아는 둬야 협업이 된다. 그래서 요즘 웹 관련된 내용을 하나하나 다시 볼려고 한다.