카테고리 보관물: Tip

Objective-C는 Swift의 친구가 될 수 있을까?

이제는 Swift도 꽤나 익숙하게 들리는 언어가 되었습니다. 저에게만 그런가요?
아마도 Swift를 배우고 있거나 실제로 사용하는 분들도 꽤 계실거로 생각됩니다. 저도 아직까지는 Objective-C가 훨씬 편하고 익숙하지만, 그래도 Swift를 아예 무시할 수는 없겠죠. 언제 애플이 Objective-C를 팽할지 모르니까요… 또르르..
Apple_Swift_Logo

Swift 로고
[출처 : Wikipedia – http://en.wikipedia.org/wiki/File:Apple_Swift_Logo.png ]

 

지난번 글에서는 너무 Swift를 부정적으로만 표현한 것 아닌가 싶기도 하고, 지금은 좀 더 Swift의 많은 면을 볼 수 있어서 지난번과는 조금은 다른 관점(?)으로 글을 쓸 것 같아요. 더 좋은 쪽으로!?

요즘에는 왠만하면 프로젝트 내에서 신규 클래스는 Swift로 작성하려고 노력중입니다. 이렇게 Objective-C랑 짬뽕혼합하여 사용하다보니, 그리 나쁘지만은 않더라구요. Objective-C의 장점과 Swift의 장점을 모두 취할 수 있으니까요.유후

Swift와 Objective-C를 한 프로젝트에서 함께 활용할 수 있는 방법은 애플에서 도큐먼트에 친절히 적어두었어요. 참고하세요.

하.지.만. 언제나 그렇듯 위험은 곳곳에 숨어있습니다. 두 언어의 차이점에서 비롯된 이점도 있지만 문제점도 분명히 드러납니다. 좋은점이 있으면 좋지 못한 점도 있기 마련. 좋은 점과 좋지 못한 점, 둘 중 뭐를 먼저 알고 싶으세요? 아마도 좋지 못한 점이 먼저 나오는게 좋을 것 같아요 ㅎㅎ 사실 좋지 않은 점이라기 보다는 그냥 제가 삽질한 것들이라… 후우… 그냥… 뭐랄까.. 넋두리… 네… 그렇습니다. 여러분들은 겪지 않으시길 바라면서! 하핳

제가 겪었던 빅삽질 들을 소개합니다!

b0036170_2231044

오예, 역시 프로그래밍은 삽질이 제맛이지

두 언어에는 서로 가지지 못한 것들이 존재합니다. 같은 듯 다른 듯 비슷한 기능들도 많은데요, 그 중 하나 카테고리(category)익스텐션(extension)이 되겠습니다.
Objective-C에서 저는 카테고리를 굉장히 즐겨쓰는 편입니다. 확장의 용이성과 간편함 때문인데요, 그에 대적할 기능이 스위프트에서는 익스텐션이라 말할 수 있겠습니다. 이에 관련된 에피소드를 소개합니다.
기존 프로젝트에서 저는 NSDictionary의 카테고리로 customMethod라는 메소드를 생성해 줬어요. 그런데 스위프트에서 코딩을 해주다가 저도모르게 NSDictionary의 익스텐션으로 customMethod라는 녀석을 만들어줬지 뭐예요? 서로 다른 이름의 기능이지만, 실제사용은 거의 똑같은 두 녀석. 결과는 어떻게 되었을까요?

13784314429c0c5517edf2134

결과는 카테고리의 승리였어요.

스크린샷 2015-03-11 오후 6.14.52

같은 이름으로 메소드를 호출해 주었을 때, 카테고리의 메소드가 호출이 되더라구요.  왜 그런가 곰곰이 찾아보고 고민해 봤는데, 아무래도 기능의 특성상 그런 것은 아닐까 조심스레 추측해 봅니다. 카테고리는 기존 클래스에 정의되어있는 메소드를 오버라이드 할 수 있습니다. 하지만 스위프트의 익스텐션은 그것이 불가능 하지요. 그렇기 때문에 런타임에서 유연하게 동작하는 특성과 오버라이딩이 가능한 특성 때문에 카테고리 메소드가 우위로 호출되는 것 같습니다. 그것도 모르고 저는 왜 자꾸 다른 결과물이 나오는지 갑갑해서 잠시 이성을 잃었답니다. 여튼, 이런 다르면서도 비슷한 기능들을 사용할 때, 주의해야겠어요.

또 한가지는 튜플(tuple)이었는데요, Objective-C에서는 튜플이라는 자료형이 존재하지 않지요. 다른 언어에도 있지만 Objective-C에서는 사용할 수 없던 녀석인데, Swift에서는 더 쉽게 사용할 수 있어서 몇몇 메소드에 적용을 해 봤어요. 그런데 그 메소드를 Objective-C 코드에서 사용해야 할 일이 생긴거예요. 하.지.만. Objective-C에서는 튜플 자료형을 사용하는 메소드에 접근할 수 없어요. 정확히 말하자면 튜플을 사용할 수 없어요(위의 애플 도큐먼트에서 확인 가능합니다). 그래서 Objective-C 메소드로 전달해줄 추가메소드를 작성해 주어야 했지요.

예를들어 위와같은 Swift 클래스에 두 클래스 함수가 구현되어 있을 때, Objective-C에서 commonMethod는 자유롭게 호출할 수 있지만, tupleMethod는 찾을수 없다며 에러를 뱉어냅니다.

스크린샷 2015-03-11 오후 6.29.58

하지만 주의할 점들만 빼면 좋은점들이 훨씬 많지요! 좀 더 유연하게 자신만의 스타일로 코딩을 할 수 있는 스위프트 덕분에 Objective-C에서 복잡하게 구현해야 했던 것들을 좀 더 쉽게 만들어 낼 수 있습니다. 예를들어 연산자 재정의나 제네릭 기능 같은 경우 Objective-C에서 어렵게 구현해야 했던 것들을 좀 더 간편한 방법으로 구현할 수 있는 길이 열리는데요, 이를 Objective-C에서 직접 접근하지 못하는 경우가 있다 하더라도, Swift에서 먼저 처리를 하고 특정 메소드를 통해 리턴해주는 방식으로 구현한다면 두 언어의 장점을 모두 흡수 할 수 있는 아주 멋진 프로젝트가 될 것입니다.

지난 번과 너무나 대조된 글이라서 좀 이상하지요? 예.. Swift는 계속 발전하고 있고, 우리가 만들어 가는 꼼수도 점점 늘어나고 있기 때문일 거예요 ㅎㅎ

결론
Objective-C는 Swift의 친구이자 멋진 동료가 될 수 있습니다! 100% Objective-C, 100% Swift 코드가 아닌 적절히 융합된, 서로의 장점을 가져다 쓸 수 있는 지금과 같은 체제를 계속 유지해 나갈 수 있으면 좋겠습니다. 애플이 Objective-C를 놓지 않고, Swift는 점점 발전시켜 주었으면 하는 바람입니다 🙂
 

왜 개발가이드라인을 읽어봐야 할까요

오늘은 우리가 놓쳐온 사소한 것들에 대해 이야기 해보려합니다.

우리 개발자들은 급변하는 개발환경 속에서 살아가고 있습니다. 하루가 멀다하고 변화되는 지옥같은 개발환경에서 변화를 따라잡기란 참으로 힘겹기 그지없습니다. 항상 그렇듯 우리는 가장 중요하지만 가장 사소한 것들을 놓치며 살아갑니다. 내 가족의 소중함, 내 옆자리의 동료, 매일같이 맛있는 밥을 해주는 식당 아주머니의 손길…  우리가 개발을 하면서 수도 없이 들여다보는 개발문서, 그러나 너무나 사소해 보여서 그냥 지나쳐 버리는 개발문서의 핵심들…! 무엇이 있을까요?

헬게이트를 열어봅시다

제가 한 번 들여다 보겠습니다.

# 처음 만나는 프레임워크

‘안녕, 코코아 프레임워크! 반가워. 앞으로 잘해보자’

설렘 반 두려움 반으로 마주한 새로운 프레임워크. 그 친구에 대해 알아보기 위해서 가장 먼저 할 일은 아마도 개발도큐먼트를 읽어보는 일이겠지요? 마치 RC카를 조작하기 전에 설명서를 먼저 보는 것 처럼 말이죠. 그런데 우리는 RC카를 빨리 몰아보고 싶은 나머지 설명서의 앞, 뒤 다 잘라먹고 ‘차량 조종법’만 읽고 조종을 시작합니다. 그 상태로 막상 조작을 하다보니 좀 더 안전하게 운전하려면 어떻게 해야하는지, 연료는 무엇을 넣어줘야 좋은지, 부품은 무엇무엇으로 이루어져 있는지… 도무지 알지 못합니다. 하지만 일단 굴러가니까 좋아합니다. 이건 마치 도로교통법과 차량 기본 정비법은 까마득히 모르고 운전만 할 줄 아는 난폭운전자와 다를바가 없습니다. 개발세계에서 우리는 이런 난폭운전자가 될 수는 없습니다.

너무나 교과서 같은 이야기지만 개발문서는 그 어느 한 글자라도 생각없이 쓰여지지 않았다는 것을 한 번 생각해 보아야 합니다. 여러분께서 라이브러리를 개발하여 개발문서를 작성한다고 생각해 봅시다. 그 얼마나 귀찮고 힘든 일인지… 상상해 보셨나요? 그런데 그 개발문서에 시간들이고 공들여서 쓰잘데기 없는 이야기들을 쓴다구요? 당치 않습니다 ㅎㅎ 시간이 없다면 개발문서에 강조되어있는 헤드라인이라도 쭈욱 훑어보는 습관을 들이는 것은 어떨까요?

 

# 아… 이런 삽질이…!

위에 RC카를 예로 들었을 때, ‘조작법만 먼저 본다’고 예시를 들었던 것은 API Reference를 이야기 했던 것입니다. 도큐먼트에는 많은 목차들이 있지만 그 분량의 98% 이상은 API Reference겠죠? 하지만 제가 강조하고 싶은 것은 나머지 2%의 내용들입니다. 그 나머지 2%를 잘 숙지하지 않아서 생기는 일들은 너무나도 많아 다 이야기하기 어렵지만 몇 가지 사례를 제시해 보고자 합니다.

난 아직 2% 부족해

난 아직 2% 부족해

  • 어…? 뷰가 동작하지 않아!

개발자 모모씨는 아이폰 앱을 만들기 위해서 한창 코딩중입니다.

‘눈누난나~ 역시 난 천재야! 냐하하. 실행해볼까? 어..! 이게 왜 동작이 이상하지? 왜 먹통이 된거야!!’

애플의 코코아 프레임워크를 위한 코딩 가이드라인을 살펴보면 ‘메소드 이름 짓기‘라는 챕터가 있습니다. 그 곳을 살펴보면 Private Methods 라는 섹션이 있는데, 한 번 훑어보면

  • Names of most private methods in the Cocoa frameworks have an underscore prefix (for example, _fooData ) to mark them as private. From this fact follow two recommendations.
  • Don’t use the underscore character as a prefix for your private methods. Apple reserves this convention.

왜 제대로 된 동작을 하지 않았는지 감이 오시나요? 애플은 코코아 프레임워크에 숨겨진 Private Method 앞에 항상 언더바( _ )를 붙인다고 하는군요. 그런데 모모씨는 한 번도 이런 문서를 쳐다도 본 적이 없죠. 결국 모모씨는 3일 간의 삽질을 뒤로하고 자포자기하는 심정으로 주변 iOS 개발 고수님께 코드를 보여줍니다. 결론은요? 3분도 채 되지 않아 고쳤죠 🙂 저 메소드가 기존 프레임워크의 Private Method를 오버라이드 해 버린 것이었습니다.

p.s. 예를 들기 위하여 작성한 코드일 뿐, 실제 위의 코드로 오동작하지는 않습니다.

 

  • 아니… 왜 리젝된거지?

모모씨는 뼈저린 아픔을 뒤로하고 계속 앱 개발을 진행합니다. 물론, 가이드 문서를 다시 읽어봤을 턱이 없죠 ^^ 그래도 문제가 하나 해결되었으니 가뿐한 기분으로 계속 개발을 진행해 나갑니다. 모모씨가 개발하고 있는 앱은 추억의 똥피하기 게임. 하하 드디어 완성했습니다! 앱스토어에 올려야죠? 당당히 애플에 리뷰신청을 합니다. 드디어 리뷰 결과가 나왔군요!

추억의 똥피하기 게임

추억의 똥피하기 게임

당신의 앱은 부적절 컨텐츠로 반려되었습니다. 앱스토어 리뷰 가이드라인 16을 참고하세요.

아니 이게 무슨말이지? 모모씨는 너무나 황당합니다. 대체 뭐길래 이게 안된다는거야! 버그도 없고 동작도 잘 한단말야!

앱스토어 리뷰 가이드라인을 살펴보러 가봤습니다.

16. Objectionable content

16.1 Apps that present excessively objectionable or crude content will be rejected

16.2 Apps that are primarily designed to upset or disgust users will be rejected

하… 이번에도 가이드라인을 제대로 숙지하지 못해 빅삽질을 하게 되었군요. 애플은 일부 사용자들이라도 불쾌감을 느낄 수 있는 앱은 허용하지 않는다는군요. 프로젝트를 아예 폐기해야 할지도 모르는 상황입니다..! 결국 모모씨는 똥피하기의 컨셉을 버리고 빗방울 피하기 게임으로 컨셉 자체를 변경하게 됩니다.

아아... 가슴이 아파..

아아… 가슴이 아파..

  • 실제 예시를 몇가지 더 소개합니다
  1. Private Method 및 Private Variable을 자신도 모르는 사이에 재정의 해버려서 원인을 알아내는데 수 일이 걸린 경우
  2. 앱 내에 사진 업로드를 포함한 성 상담 익명 게시판을 만들었지만 가이드라인에 위배된다며 반려되어 서비스 기획부터 다시 해야 했던 경우
  3. IAP(In-App Purchase) 아이템의 성격이 애플의 가이드라인에 맞지 않아 과금 정책을 변경해야 했던 경우
  4. 앱스토어에 게재되는 스크린샷에 안드로이드 이미지가 일부 포함되어 있어서 반려된 경우
  5. 프레임워크에 맞게 재정의된 자료형을 사용하지 않아 아키텍쳐에 따라 상이한 결과 및 메모리 접근 오류가 발생하여 일일히 수정해 주어야 했던 경우(64bit 프로세서 전환 때 멘붕 겪으신 분들이 종종 있죠)
  6. 가이드라인에 제시된 프레임워크 구조를 모두 파악하지 못한 채 프로젝트를 진행하여 후임자가 구조를 모두 변경하여야 하는 경우
  7. 더 좋은 퍼포먼스를 지원할 수 있는 번들 리소스를 알지 못해 이미지 및 사운드 리소스를 모두 교체해야 하는 경우

 

등등등…

# 마치며

간단한 예시를 통해 개발문서의 가이드라인을 숙지하지 않아 발생하는 불상사를 알아봤습니다. 물론 위의 예는 아주 극히 일부분이고, 어쩌면 애플 프레임워크 위에만 해당하는 문제일 수 있습니다. 하지만, 실제 현업에서 지켜본 결과 저런 일들은 비일비재하게 일어나고 있으며 그 원인은 가장 기본을 놓쳤기 때문입니다. 개발에 걸리는 몇 십, 몇 백 시간을 저 가이드라인 하나를 놓쳐서 몽땅 말아먹는 경우도 생길 수 있다는 이야기입니다.

무시하기 쉬운 프레임워크(or 라이브러리) 제공자들의 한 마디 한 마디를 놓치지 말자구요~

다른 의견 또는 실제 사례가 있으면 덧글로 남겨주세요 🙂 기다릴게요~!

멘붕없이 RVM과 루비 설치하기

안녕하세요. 이음소시어스 개발팀에서 서버사이드 코딩을 하고 있는 김민규(이터)입니다. 저희 개발팀 블로그의 첫 글에 많은 관심을 가져주셨는데요, 두 번째 글은 딱히 특별한 기술은 아니지만 RVM과 루비 설치법에 대해 한글로 된 문서가 별로 없고, 설치하며 겪은 경험을 공유하면 좋을 것 같아 이 포스트를 작성하게 되었습니다.

RVM이란?

루비 좀 안다고 하는 사람들에게 루비를 어떻게 설치하냐고 물어보면 RVM으로 설치하라는 이야기를 많이 들을 수 있습니다. RVM은 Ruby Version Manager의 약자로, 여러 버전의 루비를 쉽게 관리할 수 있게 해주는 스크립트입니다. 

한 시스템에 여러 버전의 루비를 설치하기는 쉽지 않습니다. 일반적인 리눅스의 패키지 시스템으로 동시에 여러 버전의 루비를 깔면 환경변수 꼬이고 gem 꼬이고 난리도 아니죠. 그렇기 때문에 시스템에 이미 작업하고 있는 프로젝트가 있을 때 새로 릴리즈된 루비 버전을 사용해보기는 쉽지 않습니다. 이미 구버전 루비에서 작업한 기존 프로젝트가 어떻게 될지 모르기 때문이죠. 하지만 rvm을 사용하면 여러 버전의 루비, 심지어 gem도 따로 관리해주기 때문에 새 버전을 써보고 다시 전환하기가 쉽습니다. 여기에 더해 gemset 기능을 사용하면 프로젝트별로 별도의 루비 버전을 사용하는 일도 가능합니다.

rvm의 설치 자체는 홈페이지에 있는 스크립트를 그대로 실행하면 되는 아주 간단한 작업입니다. 다만 몇 가지 주의해야 할 사항들이 있는데 이런 것들을 모른 채 설치하면 메뉴얼대로 작동하지 않고, “분명 시키는 대로 했는데 왜 안돼!” 하고 rvm은 물론 루비는 매우 설정이 거지같은 언어라는 안타까운 편견에 빠지게 됩니다.저도 처음엔 고생 꽤나 했구요…

서버 세팅하다 꼬이거나 CSS를 짜다 보면 이런 기분이 듭니다.

이 포스트는 ubuntu 12.04 64bit 기준으로 작성되었습니다.

RVM 설치하기…전에 하면 안되는 일들!

인스톨 방법을 쓰기 전에, 먼저 잘못된 설치법부터 설명하겠습니다.

이 포스트에서 제일 중요한 내용입니다.
절대, 네버, 무슨 일이 있어도 이렇게 깔지 마세요!

apt-get으로 까는 사람들이 많을 수 밖에 없는 이유

우분투가 rvm이 없으면 이렇게 깔라고 친절하게 인도해줘서 속는 사람들이 너무 많습니다. ㅠㅠ

우분투의 apt는 대부분의 패키지들을 apt-get install 명령어 하나로 한방에 깔 수 있게 해주는 멋진 도구입니다. 그런데 이 rvm을 apt-get으로 깔면 무슨 일이 생기냐구요?

설치 테스트와 트롤링을 위해 준비된 VM들

숙련된 VM의 시범을 한번 보겠습니다.

이 포스트를 작성하는 현재 RVM의 최신 버전은 1.24.7입니다…

낡아도 이렇게 낡을 수가 없습니다…

‘구버전이라도 기능만 잘 돌아가면 되겠지?’ 하고 루비를 깔아보겠습니다.

원래 ruby-1.9.3-pxxx등으로 patch level이 쓰여져야 하는데 1.9.3-에서 끝나네요

잘못된 경로로 찾아가서 루비를 제대로 깔 수도 없습니다.
2.0같은건 아예 리스트에 존재하지도 않아요… ㅠㅠ

‘구버전이니까 업데이트를 하면 되겠지? 업데이트를 해보자!’

 

그냥 포기하고 멀쩡한 버전을 깔아봅니다.

클릭하시면 스택오버플로우 링크로 이동합니다

심지어 멀쩡한 버전을 깔려는데도 얘가 방해를 하고 있어서 치워줘야 합니다.
혹시 apt-get으로 rvm을 까셨다면 싹싹 지워줍니다.

1. 패키지를 apt-get –purge로 날려주고, /usr/share, /etc/ 에 있는 스크립트들을 지워줍니다.

싹싹 지워서, 시스템에 후환(?)이 없도록 합시다.

2. 삭제 후에는 shell을 재실행해 이미 로드된 환경변수들이 다시 사라지도록 해줍니다.

하루빨리 우분투에서 이 거지같은 패키지가 사라졌으면 하는 바람입니다.

RVM 진짜로 설치하기

RVM의 설치에는 두 가지가 있습니다. 잘 읽고 원하는 방법을 골라 설치하세요.

Single User Install

  • 설치한 유저에게만 RVM이 깔립니다.
  • 설치한 RVM은 당연히 ‘그 유저’만 쓸 수 있고, 다른 유저가 사용할 수 없습니다.
  • RVM은 설치한 유저의 홈 디렉토리의 .rvm폴더 ($HOME/.rvm)에 설치되고,
    RVM으로 설치하는 ruby와 모든 gem들도 $HOME/.rvm에 저장됩니다.
  • 여러 유저가 각각 Single User Install을 하면 모든 ruby와 gem들은 별도로 저장됩니다.
    시스템 공용으로 사용하는 것은 rvm install에서 루비를 설치하기 위해 설치한 라이브러리뿐입니다.
  • root계정으로 Single User Install을 할 수 없습니다.
    root permission을 가진 상태면 자동으로 multi user 인스톨을 하므로,
    root계정에만 rvm을 깔아서 쓰는 것은 불가능하진…않은데 이 포스트에서는 다루지 않습니다.
    root 계정에만 rvm Single user Install로 설치하기

Multi User Install

  • /usr/local/rvm/ 에 모든 rvm, ruby, gem이 설치됩니다.
  • 한 유저가 설치한 루비, 또는 gem은 시스템 전체에 공유됩니다.
  • 시스템의 모든 유저가 rvm, rvm으로 설치한 루비와 gem을 사용 가능합니다.
  • rvm그룹의 유저만 새 루비 또는 gem을 설치할 수 있습니다.

자 고르셨나요? 그럼 따라해 봅시다.

Single User Install 방법

1. root가 아닌 일반 유저로 아래 명령을 실행합니다. (\ 오타 아닙니다!!)

2. 쉘을 껐다 켜거나 rvm스크립트를 현재 쉘에 로드해줍니다.

끝! 쉽죠?

Multi User Install 방법

1. root가 아닌 일반 유저로 아래 명령을 실행합니다. (\ 오타 아닙니다!!)

bash 앞에 sudo만 붙여주면 됩니다. 와!

실제로 root로 설치해 봤을때 특별히 이상한 점은 찾지 못했는데,
rvm 문서를 보면 root와 일반 유저의 환경변수 차이 때문에
root로 직접 깔지 말고 일반 유저에서 sudo를 써서 사용하라고 합니다.
시키는 대로 하는게 편하겠죠?

2. 그 다음 RVM을 사용할 유저들을 rvm 그룹에 추가합니다.

그룹에 추가를 안해주면 /usr/local/rvm에 write권한이 없어서 루비 설치가 불가능합니다

일반 유저는 /usr/local/rvm에 write권한이 없기 때문에 rvm 그룹에 추가해서 권한을 부여해야 합니다.
이게 없으면 rvm install등을 할 때 권한이 없다고 죽어버려요.

3. 쉘을 껐다 켜거나
(쉘을 껐다 켤 수 없는 상황이면) 그룹 권한을 재로드하고, rvm스크립트를 현재 쉘에 로드해줍니다.

이번에는 그룹 권한도 다시 로드 해야해서 좀 귀찮습니다.
그래서 쉘을 그냥 껐다 켜는게 편해요.

축하합니다! RVM 설치가 끝났습니다!

RVM으로 Ruby 설치하기

sudo같은거 붙일 필요도 없고 붙여서도 안됩니다.
이 과정에서 permission denied가 뜨면 대부분 그룹 문제이기 때문에
id를 쳐서 유저가 rvm 그룹인지 확인해보세요.

이미지가 너무 길어서 잘 안보이는데 끝에 보면 1001(rvm) 이렇게 써있습니다 ㅠㅠ
그룹에 추가했는데도 없으면 쉘을 재실행하거나 위에서 알려준 커맨드로 그룹 권한을 재로드해보세요.

설치 도중 sudo권한이 필요하면 알아서 물어봅니다.

설치 중 시스템 업데이트가 필요해 sudo권한이 필요한 경우가 있는데, 이 경우엔 알아서 물어봅니다.
rvm커맨드에 따로 먼저 sudo를 붙여야 하는 경우는 전혀 없으니,
혹시 permission denied가 뜨면 그룹을 먼저 확인해주세요.

네, 이제 루비 코딩을 시작하시면 됩니다!

TroubleShooting

Q: 루비 스크립트에서 sudo권한이 필요한데, sudo를 쓰면 rvm을 찾을 수 없다고 나오네요. 어쩌죠?

Single User Install에서 볼 수 있는 현상인데, rvm은 우리의 로그인 쉘에 로드되는 스크립트이기 때문에 root에는 깔려있지 않고 깔려 있다 하더라도 그 스크립트를 로드하지 않습니다 ㅠㅠ

sudo 대신 rvmsudo를 사용하면 현재 쉘의 루비를 가지고 sudo권한으로 실행할 수 있습니다.

Q: sudo -s,  su [username]등으로 유저를 바꾸고 그 유저의 rvm을 쓸 수 없나요?

sudo -s, su [username]은 로그인 쉘이 아니라 스크립트를 로드하지 않습니다.
su – [username] 으로 하면 그 유저의 로그인 쉘을 띄우기 때문에 그 유저의 rvm을 쓸 수 있습니다.

Q: 이미 시스템 루비가 있는데 지워야 하나요?

rvm 경로가 $PATH의 가장 앞에 붙기 때문에 시스템 루비는 남아있어도 상관없습니다.

 

이상, 한국에 루비 사용자가 한 명이라도 늘기를 바라는 이터였습니다.