길게 주저리 주저리 글을 썼다가 다 지웠다.  결론 부터 간단히 말하겠다.

전공 vs 비전공

압도적으로 전공자가 유리하다. 이건 논란의 여지조차 존재하지 않는다. 대부분의 비 전공자들의 안타까움은 잘 이해하고 있다. 나도 20년간의 개발자 경력동안 어느정도 경력자 사이에서는 전공이 의미가 희미해 지는 순간이 온다는 것을 절대적으로 이해한다. 하지만 신입에서는 이야기가 다르다.

'당신이 그냥 전공자를 편애하는 개발 리더 아닌가?' 라고 말할 수도 있겠지만, 내 인생에서 첫 사수가 역사학과 출신 개발자 였다. 엄청나게 코딩을 잘하시는 훌륭한 개발자셨다. 그리고 오랫동안 같은 팀으로 회사를 옮겨도 같이 일하는 클라이언트 개발자는 처음에 뽑을때부터 비전공자 출신이였다. 나도 비전공자가 훌륭한 개발자가 될 수 있다는 것을 누구보다 잘 아는 개발 리더라는 이야기가 하고 싶은 거다.

그럼에도 불구하고 요즘 학원에서 천편일률적으로 배우고 나오는 비전공 개발자들의 이력서에는 특별함이 존재하지 않다. 즉 나는 현실을 말하는 것이다. 대부분의 사람들 심지어 비전공자 본인 조차도 전공자와의 서류 싸움에서는 힘들 것이라는 것을 이해한다. 비전공 개발자들은 서류 부분 트라이부터 엄청나게 큰 핸디캡을 가지고 전공자들과 싸워야 한다. 단지 학원에서 프로젝트 했다는 것으로는 개발 리더의 흥미를 끌기가 어렵다.

그래서 추천한다. 물론 엄청나게 어려울 것이다. 하지만 그러한 과정을 거치고 나서 당당히 그 내용을 기재했다면 개발 리더는 조금이라도 다르게 지원자를 바라보게 될 것이다. 학원을 졸업해서 취업 준비 기간중에 개인 프로젝트를 하라는 것이다. 아 물론 하는 사람들 엄청나게 많다는 것을 안다. 실제로도 이력서를 보면 개인 프로젝트 엄청나게들 많이 한다. 하지만 그 수 많은 사람중에 실제로 제품화 까지 도달하는 사람은 거의 없다. 개인 프로젝트 라지만 학원 강사의 지원을 받지 않으면 github 에 README 하나 작성하지 못하는 지원자들이 수두룩 하다.

즉 클라이언트라면 실제로 제품을 만들어서 스토어에 올리고, 서버 개발자라면 실제로 제품을 런칭해서 URL 까지 입혀서 출시해서 실제로 클릭해서 동작하게 만들라는 거다. 아 물론 이래도 관심을 가지지 않는 개발 리더가 존재할 수도 있다. 그래도 어쩌겠는가? 개발은 그만큼 전공자가 유리한 필드다. 그 천장을 무너뜨리려면 그정도 정성을 기울여야 이력서를 보고 한 번 이야기라도 할려고 서류를 통과 시킬 것이다.

요약하면 비전공자들은 이력서에 더욱더 노력을 기울이고 '색안경을 끼고' 바라보는 개발 리더가 흥미를 가지게 할려면 무엇을 해야 할지 고민하라는 것이다. 제품을 출시하는 것이 크나큰 강점이 될 것이라는 것이 내 의견이다.

ps. 실제로 나는 클라이언트 개발자가 다른 회사에 거의 50번의 면접에서 떨어지고 우리 회사에 지원 했을 때 그 친구가 만든 제품을 실제로 스토어에 올린것을 깔아보고 나서 면접을 거쳐 뽑게 되었다. 그 친구는 아주 훌륭한 개발자로 성장했다. 

예전에는 혼자서 개발하면서 성장할 수 있는 시기가 있었지만, 요즘은 팀단위로 개발을 진행하기 때문에 빠르게 성장할 수 있지만, 자신의 파트에 특화되는 경향이 있습니다. 물론 지금도 파트를 오가면서 개발을 할 수는 있지만 예전만큼 쉽지 않습니다. 저도 실제로 클라이언트 개발을 하다가 서버 사이드로 옮긴 경우 입니다. 


  예전 다니던 회사에서 공개 개발자 모집을 한 적이 있습니다. 들어온 원서의 비율을 체크 해보니 안드로이드, iOS, 백엔드 개발자의 비율이 8:1:1 이였습니다. 클라이언트와 서버 비율로 따져보면 9:1 입니다. 

  클라이언트 사이드에서 안드로이드 개발자가 iOS 보다 많은 이유를 몇 가지 짐작해 볼 수가 있습니다. 

  안드로이드 폰을 가진 사람이 월등하게 많습니다. 자신이 가진 폰에 맞는 앱을 개발하다보면 당연히 안드로이드 개발이 많을 수 밖에 없다고 생각할 수 있습니다. 

  안드로이드 개발 환경 구축이 훨신 쉽습니다. iOS 는 맥에서 개발을 해야 하지만 안드로이드는 일반 윈도우 환경에서도 개발이 가능합니다. 또한 iOS 는 스토어에 올리려면 개발자 인증서를 사야 하는데 이 비용도 초기 비용에 해당합니다. 또한 지금은 추세가 바꼈지만 예전에 iOS 는 object-c 로 개발을 해야 했는데 이는 java 보다 난이도가 높습니다. java 는 학교 수업시간에도 배우는 언어이기 때문입니다. 

  여러가지 이유로 안드로이드 개발이 iOS 보다 많은 이유를 짐작해 볼 수가 있습니다. 

  그러면 클라이언트와 서버 개발은 어째서 차이가 날까? 
  
  클라이언트 개발은 접근성이 편합니다. 그리고 결과물을 바로 볼 수가 있다는 장점이 있기 때문에 개발에 흥미를 가지고 시작하기가 좋습니다. 그리고 개발 -> 개발 완성까지의 가야 하는 길이 짧습니다. 

  서버 사이드는 개발을 시작하기 위해서 알아야 할 것들이 많습니다. 데이타베이스도 알아야 하고 디플로이도 제대로 할려면 리눅스 관련 명령도 배워야 합니다. 요즘은 클라우드가 대세이기 때문에 AWS (Amazon Web Service) 나 GCP (Google Cloud Platform)을 알아야 하는 시기가 됐습니다. 개발 언어도 알아야 하고 웹 서비스면 웹프레임워크도 알아야 합니다. 게다가 국내에서 가장 많이 쓰이는 자바 관련 개발 환경이라면 스프링 프레임워크를 많이 쓰는데 이 또한 학습곡선이 높고 많은 기간을 필요로 합니다. 만약에 결과를 눈으로 확인 하기 위해서는 프론트엔드도 최소한으로 알아야 하는데 이 또한 만만치 않은 노력을 필요로 합니다. 

  즉 클라이언트 개발은 접근성이 좋고 바로 바로 아웃풋이 확인 가능하니 개발의 재미를 줄 수가 있습니다. 서버 개발은 개발 접근성이 좋지 않고 바로 바로 아웃풋 확인 하기까지가 배워야 할 것들이 많습니다. 하지만 이러한 난이도가 시니어급에 이르렀을 때 연봉의 차이를 가져옵니다. 9:1 클라이언트대 서버 개발자의 비율입니다. 이게 펑균이라고 보기에는 사실상 무리가 있는 특이 케이스 일 수도 있지만 인력시장에서 알아보면 확실히 서버 개발자의 숫자가 적습니다. 

  그래서 내가 클라이언트와 서버 개발중에서 어떤걸 할까 고민을 한다면 각각의 특장점이 있습니다. 

  클라 개발에 전념해서 장인급이 되신다면 회사를다니면서 또는 프리랜서를 하시면서 '돈'만 바라보고 여러가지 일을 동시에 진행한다면 단기간에 큰 돈을 벌 수가 있다는 것입니다. 제 주변에는 프리랜서 시절에 연 1억을 넘게 벌어들인 아이폰 개발자와 연 2억을 넘게 돈을 버는 클라이언트 개발자들이 있습니다. 

  서버는 이후에 올라갈 수 있는 테크가 있습니다. 아키텍트 - 개발 총괄 - CTO 등으로 커 나아갈 수 있는 기회가 열려 있습니다. 물론 클라이언트 개발자 출신으로도 가능합니다. 그리고 클라이언트 개발자 분들의 역량을 무시하는 건 절대 아니지만 이후 실제로 서비스를 론칭해서 운영하는 경우에는 절대적으로 서버쪽의 지식이 필요합니다.

  물론 이런 것들이 생각처럼 잘 되기 위해서는 그에 따르는 노력들이 필요하지만 대체로 이렇습니다. 


프론트 개발이 가능하신 개발자 분들이 제 오픈소스 프로젝트에 참여해서 프론트 엔드를 꾸며 주었군요. 모바일도 적용이 되어 있습니다. 


데모: https://chat.crazia.org/

소스: https://github.com/crazia/NM-chatbot


딥러닝 관련 과거 포스트들: 

1. AI 학 개론 (초보 개발자를 위한 정리) 

2. seq2seq 를 이용한 챗봇 (Neural Network Chatbot)

3. seq2seq 를 이용한 챗봇 - 웹버젼

4. seq2seq 를 이용한 챗봇 - 자동 진화 버젼

5. seq2seq 를 이용한 챗봇 - 형태소 분석을 추가한 버젼



최근 열심히 공부해서 간단한 챗봇을 만들 수가 있었습니다. 형태가 간단할 뿐이지 그 안에 들어 있는 Deep Learning 은 구글의 최신 NMT example 을 참조해서 만들었습니다. 


github 에 올리는 거라 대충 영어로 올렸지만 좀 자세한 설명은 여기에 남길려고 합니다. 


NMT(Neural Machine Traslation) 과 chatbot 은 원리상 거의 같습니다. seq2seq 방식으로 RNN 세팅해서 교육시키는 것 까지 동일합니다. 따라서 잘 만들어진 NMT 는 training 자료만 교체해서 챗봇으로 활용 가능합니다. 


소스는 https://github.com/crazia/NM-chatbot 에서 받을 수 있습니다. 


파이썬(python) 버젼은 3.6 이고 tensorflow 버젼은 1.8 입니다. 그 외 다른 라이브러리는 필요 없습니다. 


기본적으로 NMT 소스는 많이 복잡하고 옵션도 다양합니다. 이 소스를 기반으로 했기 때문에 트레이닝(Training)은 NMT 의 옵션과 실행을 그대로 가져갑니다. 대신 입출력을 최소한으로 간소화 시켰기 때문에 추후에 다른 방면으로 이용할 때(서비스 등을 만들때)는 chat.py 만 연구해서 떼어 붙이면 됩니다. 


챗봇을 구동 시킬려면 우선 교육을 시켜야 합니다. 그러면 교육 시키는 방법부터 알아야 합니다. 그러면 교육시키기 위한 자료들 부터 규정합니다. 



1. Train set 


교육을 시키기 위해서 필요한 자료 입니다. 챗봇은 사용자가 '질문'을 던지면 '응답'을 하는 구조로 되어야 합니다. 따라서 train.req 와 train.rep 두 파일이 필요합니다. 각각의 파일은 질문이 들어 있는 (req) 파일과 응답이 들어있는 rep 파일이 쌍으로 필요합니다. train.req 의 132 번째 줄에 있는 질문에 대한 답은 train.rep 의 132 번째 줄에 존재해야 합니다. 

당연히 훌륭한 챗봇은 이 데이타가 확실하게 많아야 합니다. 



2. Test set


교육이 잘 됐는지 확인하기 위해서 필요한 자료입니다. train 에 있는 내용을 발췌해서 써도 되고 아니면 한번 train 에 있는 단어들을 이용해서 적당히 만들어서 써도 됩니다. 



3. Dev set


Test set 하고 다른 케이스의 Test 를 정리해도 되지만 같은 것을 써도 무방합니다. 



4. Vocabulary file


교육과 테스트 전 과정에서 쓰이는 단어집이 필요합니다. 따라서 train.req 와 train.rep 에서 쓰이는 모든 단어를 모아서 단어집으로 가지고 있는 것이 좋습니다. 기본적으로 NMT 는 통역이라 각각의 과정에서 쓰이는 단어집이 다릅니다. (영어-> 베트남 이라면 영어 단어집 하고 베트남 단어집이 따로 존재) 하지만 챗봇은 같은 언어 이기 때문에 굳이 다를 필요는 없을 것이라고 판단했습니다. 


이 단어집을 쉽게 만들어줄 수 있는 파일이 존재해서 그냥 가져다가 조금 바꿔 줬습니다. 


$PROJECT/bin/generate_vocab < train.file > vocab.req
cp vocab.req vocab.rep


이와 같이 하면 단어집을 쉽게 만들어 줄 수 있습니다. 



5. 이 모든 파일을 한 디렉토리에 모아 둡니다. 


mkdir -p /tmp/nmt_chat
cp train.req train.rep test.req test.rep vocab.req vocab.rep /tmp/nmt_chat



이제 교육 시키기 위한 모든 자료가 준비 됐으니 교육을 시키면 됩니다. 



   $PROJECT/python nmt.py \
    --attention=scaled_luong \
    --src=req --tgt=rep \
    --vocab_prefix=/tmp/nmt_chat/vocab  \
    --train_prefix=/tmp/nmt_chat/train \
    --dev_prefix=/tmp/nmt_chat/test  \
    --test_prefix=/tmp/nmt_chat/test \
        --out_dir=/tmp/chat_model \
    --num_train_steps=12000 \
    --steps_per_stats=100 \
    --num_layers=4 \
    --num_units=128 \
    --dropout=0.2 \
    --metrics=bleu


여기에서 신경 써야할 몇가지 사안들을 지적하겠습니다. 


attention 알고리즘을 선택해야 효율이 좋아지기 때문에 꼭 선택을 해줘야 합니다. 

src 와 tgt 는 내가 이용하는 파일의 확장자들입니다. 저는 req 와 rep 를 썼기 때문에 그걸 지정해 준것입니다. 

vocab_prefix 는 단어장으로 써야할 파일의 파일명입니다. (확장자는 req 와 rep)

train_prefix 는 교육시킬때 써야할 파일의 파일명입니다. 여기서는 train 이라고 씁니다. 

dev_prefix 와 test_prefix 는 테스트 할때 쓸 파일의 파일명입니다. 여기서는 test 라고 만든것을 써줍니다. 


정말 중요한 out_dir 입니다. 교육시킨 결과물이 저장되는 곳입니다. 그리고 이후에 실행할 때 교육된 정보값을 가져오기 위해서도 입력해야 합니다. 


num_train_steps 얼마만큼 교육을 시킬것인가 하는것입니다. RNN 은 제대로 효과를 볼려면 꽤 많은 횟수로 교육을 시켜야 합니다. 

steps_per_stats 몇번 마다 로그를 남길것인가 하는것입니다. 체크포인트(checkpoint: 교육 결과 저장이 10x steps_per_stats 마다 일어납니다)

num_layers 는 RNN 을 몇 계층으로 할 것인지 입력하는 것입니다. 간단한 건 2 계층, 시스템이 허용된다면 8 계층에서 가장 최적의 효과를 보였다고 벤치마크는 말합니다. 

num_units 는 네트워크 사이즈 입니다. 

dropout 은 Deep Learning 에서 교육중 건너뛰고(?) 얼마만큼 교육시킬건지 지정해 주는 수치 입니다. 교육자료가 많을 때 사용하면 좋습니다. 


너무나 당연하지만 gpu 버젼으로 교육시키면 효과가 훨씬 좋습니다. 저는 개발은 OSX 에서 하지만 교육은 제 PC 에서 합니다. nvdia 그래픽 카드를 소유하고 있어서..


이제 모든 교육이 끝났으니까 챗봇을 구동하면 됩니다. 


챗봇 구동시키기



python chat.py --out_dir=/tmp/chat_model


예전에 Emacs for OSX 관련 설치글에서 File Dired Mode 에서 한글이 깨지는 문제는

(require 'ucs-normalize)
(set-file-name-coding-system 'utf-8-hfs)

위 내용을 .emacs 에 써주면 된다고 했습니다. 그런데 shell-mode 에서 한글이 제대로 출력이 안되는 이슈가 존재합니다.

역시 .emacs 에

(setq default-process-coding-system '(utf-8-hfs . utf-8-hfs))

와 같은 내용을 써주면 해결됩니다.



각각의 request_log 에 application_log 가 딸려있다. 그리고 각각의 어플리케이션 로그는 형식에 맞춰서 로그를 남길 수가 있으며 위 사진을 보면 알 수 있듯이 각각의 아이콘 그림까지 다르다!! 



저는 습관처럼 gradle 을 command line 에서 사용합니다. 다만 최근 무지하게 느려진 느낌입니다. 자성의 움직임이 있었는지 최근 gradle 도 daemon 모드를 말하는 군요. 세팅은 무지하게 쉽습니다. 


touch ~/.gradle/gradle.properties && echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties

이렇게만 하면 비약적으로 빌드 속도가 올라간다는데 저는 사실 잘 모르겠습니다. -ㅅ-  Android Studio 도 빨라지는지는 테스트 해봐야 할 듯합니다. 


처음 스위프트 (Swift : 혹 수입푸드 라고 부르는 사람들도 있음 ㅋㅋ) 개념을 보았을 때, VM (Virtual Machine) 같은 개념으로 여겼습니다. '뭐 또 빠르게 개발은 될 지 모르겠으나 동작은 느린애가 되겠군' 라고 생각하며 안 보고 있다가. 최근에 보니 이게 컴파일러용 언어였더군요. 플레이그라운드(Playground) 개념은 잽싸게 컴파일 해서 그 결과를 보여줘서 interactive 하게 보일지 모르지만 실은 컴파일 언어였습니다. 


개념이 재미 있는데다가 컴파일된 바이너리가 기존의 Object-C 언어로 만들어진 것보다 속도가 2.8 배가 빠르다는 것을 보고 관심이 가더군요. 그래서 언어 개요를 가볍게 살펴봤습니다. 

iOS 기기를 가지고 있으면 iBooks 에서 공짜로 프로그래밍 언어에 대해서 설명한 책을 받아볼 수가 있습니다. 물론 그런것이 없는 분들을 위해서 사이트에서도 제공됩니다. 그리고 정말 훌륭하신 분들이 해석해서 사이트에 올려둔 곳도 존재하더군요. 


Swift 언어 가이드 


에서 참조하실 수 있습니다. 저는 프로그래밍 언어 자체에 노력을 많이 기울이는 편은 아닙니다. 애초에 Swift 가 필요한 이유는 iOS 나 Cocoa 용 앱을 빠르게 만들기 위함이 아니겠습니까? 그렇다면 실전에서 익히고 어렵거나 이해가 안가는 부분을 찾아서 공부하는 것이 조금 더 '실용적' 이라고 생각하기 때문입니다. (실은 예전에 프로그래밍 언어 그 자체만 공부하다가 지치거나 중간에 흥미가 떨어져서 응용해 보지도 못한 적이 여러번 있기 때문입니다. - 마치 영어를 공부해야 하는데 어떻게 하면 영어 공부를 잘하는 법을 공부하는 경우와 비슷하다고 하겠습니다) 


그래서 실전 튜토리얼을 찾아보다가 찾은 정말 훌륭한 동영상이 있더군요. 비록 한글이나 한국어로 된 것은 아니긴 하지만 기술 영어를 사용하고 있어서 쉽게 알아먹을 수가 있습니다. 영어도 공부하고 Swift 도 공부하고 1석 2조!! 


프로그래밍 경험 없는 사람이 쉽게 iOS 용 앱 (다 만들면 게임이 만들어 집니다) 만들기 


iOS 용 앱을 만들어 볼려고 했는데 엄두가 안 나신분 들에게 강력 추천합니다. 내용중에 보면 MVC 패턴과 XCode 툴에 관한 설명등 들어두면 좋은 내용들 다수가 들어 있습니다. 



어제 제자 한명이 집 근처로 찾아와서 차를 한 잔 했습니다. 최근에 이쪽 방면에서 알려진 크고 건실한 기업에 취직했다고 하더군요. 이번에 취직할 때 평소에 내가 말하던 것들을 잘 실천하고 있었던 터라, 그러한 부분들을 엮어서 스토리를 잘 만들었더니 입사할 수가 있었다고 합니다. 전공과를 졸업한 것도 아니고 흔히 말하던 학원 출신으로서 이 정도 위치까지 온 친구라 더 이상 잔소리는 필요 없을 것 같고, 저 또한 내 덕에 입사를 할 수 있었다는 소리를 들으니 뿌듯해 지더군요. 그래서 그 제자에게 평소 하라고 했던 (입사할 때 도움이 됐던) 잔소리를 조금 정리 해볼까 합니다.

  1. 블로그 쓰기 블로그를 쓰라고 하는 이유는 3가지 였습니다.
    • 첫째, 자신이 몰라서 찾게 된 방법은 나중에 다시 모를 경우가 많기 때문입니다. 그 때마다 계속해서 검색을 통해서 솔루션을 찾다보면 같은 일을 계속해서 반복하게 됩니다. 이건 제 자신이 느꼈던 것이라 확실하게 정리하라고 시켰습니다.

    • 둘째, 블로그에 정리하면서 확실하게 기억을 하라는 의도였습니다. 같은 기억이라도 정리를 하면서 조금 더 쉬운말로 바꾸는 노력을 들이다 보면 시간이 지나도 잊어지지 않으며, 또한 잊어버린다 하더라도 내가 그 내용을 블로그에 정리했었지 라는 기억이 남아 있어서 조금 더 쉽게 검색할 수가 있습니다.

    • 셋째, 대의적인 명분입니다. 내가 고생한 내용은 역시 다른 사람들도 고생하기 마련입니다. 이때 같은 내용을 영문사이트에서 찾는 것보다 한글로 정리된 블로그에서 찾는게 여러모로 도움이 되겠죠. 그래서 내가 고생했던 내용때문에 다른 개발자들이 고생하지 말라는 의도로 정리하라 했습니다.

  2. Node.js 로 프로젝트를 진행했습니다. 그 당시에 뜨고 있던 개발 언어로 Javascript 문법을 차용해서 쓰고 있던 일명 Server-side-Script 언어였습니다. Express 라는 웹프레임워크를 사용해서 엄청나게 빠른 속도로 개발이 가능했습니다. 게다가 이 언어를 KT 프로젝트에서 사용하자고 주장해서 통과시켰습니다. KT 쪽은 왜 Java 가 아닌지 사유를 설명하라고 해서 설명 문서를 세개를 만들고 PT를 두번이나 했던 기억이 나는군요. 어쨌거나 이렇게 한번 새로운 언어로 개발을 해본 효과에다가 Node.js 가 최근 뜨는 트렌드가 되서 중복적인 효과를 발휘해 새로 Node.js 를 기반으로 하는 플랫폼으로 개발을 할려는 업체에게 좋은 가산점을 줬다고 합니다.


  3. 프로젝트 관리를 GitLab 으로 관리하는 법을 배웠습니다. 당시 소스 레파지토리 관리를 SVN 으로 하는 것이 대세였는데 뜨고 있던 git 으로 대체하고 이를 기반으로 해서 프로젝트를 관리할 수 있는 github 를 모방해서 만든 GitLab 을 사용하자고 해서 이 시스템을 설치하고 교육시켰습니다. 처음 써본거라 어안이 벙벙들 했는데 지속적인 잔소리 덕분인지 일주일도 안 되서 능숙하게 되더군요. 게다가 GitLab 안에는 이슈트래킹 기능과 설명을 위한 Wiki 기능이 탑재되어 있어서 전체 프로젝트를 마일스톤별로 관리할 수도 있는 멋진 관리툴입니다. 굳이 GitLab 이 아니더라도 대부분의 프로젝트를 관리하는 시스템은 이러한 기능들이 탑재되어 있기 때문에 하나를 써본 경험으로 다른 것도 쉽게 익숙해질 수 있는 장점이 있습니다.


  4. CI (continuous integration) 솔루션의 사용 (이건 미 적용) 사용하라고 자주 이야기는 했지만 실제로 적용을 못하고 있던 부분이였습니다. CI 는 적용하자고 마음을 먹으면 TDD (test-driven development)를 자연스럽게 적용할 수가 있기 때문에 여러사람이 공동으로 작업할 때의 필수적 요소입니다. 소스의 master branch 를 깨먹지 않고 유지하려면 최선의 방법이기 때문에 추천합니다. 추천하는 시스템은 그 유명한 Jenkins 입니다.


어제 이런 저런 이야기를 나누다 보니 내가 그 제자에게 했었던 이야기가 떠 오릅니다.

'학벌'은 중요하다. 하지만 한 번, 이 업게예 발을 들여 놓으면 얼마만큼 새로운 기술에 잘 적응하느냐와 습관처럼 몸에 익힌 기술들이 학벌 보다 더 도움이 될 수밖에 없다. 'php 로 다 되는데 어째서 이러한 것들을 공부해야 하나요?' 같은 시대에 뒤 떨어진 소리를 하지말고 잘 이해가 안되더라도, 잔소리가 고깝게 들리더라도 계속해서 모르는 것을 물어보면서 자신의 것으로 만들어라.

이 말은 또 다른 후학들에게도 해당되는 말이라 할 수 있습니다. CS 에 종사하시는 모든 분들 화이팅!!

안드로이드 개발하다 보면 별 문제는 없어보일지 모르지만 안드로이드가 네트워크 인터페이스를 여러개 가지기 때문에 발생하는 문제가 있습니다. 갤럭시 s3 의 경우에는 LTE, 3GS, WI-FI 등 세개의 인터페이스가 있습니다. 그런데 이런 인터페이스들이 사용을 안하면 비활성화 되어 있으면 사용하기 편할텐데 사용 안하더라도 활성화가 되어 있는 데다가 잘못된 (구동하지 않는) IP 주소를 가지고 있어서 문제가 됩니다.

무슨 문제가 있겠어? 라고 하지만 순수 자바 (Pure Java) 로 네트워크 레이어를 구현할 때, 만들어진 라이브러리를 안드로이드로 포팅시 발생하는 문제입니다. 이를 해결하기 위한 방법입니다.

인터넷에 연결이 되어 있고 (LTE,3GS,WI-FI 상관하지 않고) 접속되어 있는 상태에서의 가지고 있는 IP 주소를 가져오는 방법입니다.

Socket socket = new Socket("www.google.com", 80);
String localAddr = socket.getLocalAddress().getHostAddress();
Log.d(TAG, "local address is : " + localAddr);

생각보다 자주 부딛히는 문제라서 정리합니다.





+ Recent posts