아오 이제 어쩌지… http://cafe.naver.com/devrookie/8002 http://cafe.naver.com/devrookie/8008 http://cafe.naver.com/devrookie/8011 http://cafe.naver.com/devrookie/8013 http://cafe.naver.com/devrookie/8014

DEVROOKIE2014

ATTENTION

오늘 이야기는 특정 회사 보다는 여러분의 팀원이 얘기한다 생각하고 들어주시면 좋겠습니다

문제될만한 내용이 있다면 제 불찰이니

questionname@naver.com 그냥 가볍게 봐주세요

“DevRookie Special ”

지금까지 저는 개발자로서 무엇을 해야 할지에 대한 고민들을

발표했습니다

그리고 2014년 6월부로 딱 1년이 되었습니다

한번 1년 전으로 돌아가보겠습니다

저는 늦깎이 프로그래머였고 어영부영한 시간이 있어서 의기소침해 있었고 좋은 팀원이 되야 한다는 생각이 있었습니다

그래서 일을 잘하기 위해서 노력했죠 프로그래머로서 익숙해지기 위해 택한 라이브 팀이기도 했고

좋은 프로그래머가 되고 싶었습니다

한번 들은 것은 두번 묻지 않고 팀 안의 이슈들은 상관없어도 기웃기웃하고

트러블을 만들지 않고 언제나 바로 일 할 수 있게 소스를 파악하고

팀 히스토리를 최대한 파악하고 유저 커뮤니티를 항상 훑어서 동향도 알아보고

모르는게 없도록 기술 공부도 하고

들은 것들은 그 자리에서 바로 적어놓는다 두명 이상 무얼 할 때면 참석한다

작업자들과 원만한 관계를 유지한다 일이 없어도 켜놓고 소스에 대한 문서완성을 목표로 한다

경력자들 살살 꼬드긴다 탭에 아예 저장해 놓고 뉴스처럼 본다 퇴근 후 시간은 학습 시간으로 쓴다

익숙해지기 위한 과정이었습니다

그래서 매사 진지하다는 얘기를… OTL

그런데… 익숙해지면 되는 것일까?

저는 라이브 팀에 속해 있기 때문에 패치를 위해 빌드를 하고, 패킹을 하고 작업들을 합니다

나라마다 각각 다른 적용 프로그램들과 옵션들로 작업자들은 각기 국가의 옵션들을 외워야 하죠

몇 번 작업 후, 저도 익숙해졌습니다 매뉴얼은 열어보지 않고, 하품하면서도 할 수 있게 됐죠

그리고 생각했죠

왜 이렇게 해야 하나? 쉽게 하면 안 되나?

여러분이라면 어떻게 하시겠습니까?

옵션을 저장했습니다

나중엔 배치 만들고 젠킨스 했지만 처음엔 이랬습니다

저희 게임이 서비스한지가 8년이 넘었는데 그동안 이걸 한 사람이 왜 없었을까

모자란 사람들만 있었나?

아닙니다

익숙함

모자란게 아니라 다들 익숙해졌기 때문입니다 업무에, 일에, 그리고 불편함마저도

인간은 한번 익숙해지면 변하지 않으려는 속성이 있기 때문입니다

꼭 거창한 무엇을 해야만 하는 것은 아닙니다 단지 작은 행동으로도 변화를 가져올 수 있지 않을까?

어떻게 익숙해지고 어떻게 낯설어질지

그것이 오늘 테마입니다

“DevRookie Special ”

유저들이 맨날 하는 말 그래픽 바꾸고, 버그 없는 새 엔진으로 만들어주면 안되겠니?

그래서 시작한 것이

NAE

새로운 A**** 엔진이란 심플한 뜻 줄여서 노답

Neo A**** Engine

게임이 나름의 재미가 있지만, 오래된 게임

좀 더 좋은 그래픽을 좀 더 빠르게 제공한다면 좋겠다 오래 되서 침체된 개발팀 분위기도 좀 바꾸고 싶다

빌어먹을 유니티 덤비라 그래!

3가지 원칙을 세웠다

1. 혼자 하자 – 나에겐 학습시간도 필요하다 2. 타인에게 업무를 증가시키는 일은 최소화해야 한다

3. 확실히 다른 모습으로 완성해 팀 문화를 활성화 시켜야겠다

그리고 곧 벽에 부딪쳤습니다

1. 어떻게 하면 근사하게 되는지 잘 모르겠다 2. 어떤 파장을 불러올지 짐작이 안 간다

3. 메인 업무가 아니다 보니 자꾸 방해 받는다

그래도 꿋꿋이 함 첫번째 책은 특히 추천…

외부 라이브러리들은 CODEPROJECT에 찾아보면 있더라 사용중인 버전을 확인하고 혹시 신규버전이 있는지 확인

물론 그 중엔 제작자가

“너무 오래 되서 나도 기억이 안나, 요즘 좋은거 많더라 바꾸지?” 라는 것도 있더라 -_-;

심지어 이 답변도 몇 년 전꺼…

점점 외롭다고 느낄 때 툴 담당 프로그래머 자리 차지

그나마 같이 지내던 사람이 나가서

더 외로워졌지만 권한이 생겼다

기획팀과 그래픽 팀이 맨날 하는 말 엔진이 구려 툴이 구려

여길 나가야겠어

잘해보려는 의지가 있는 사람들은 있는데 거듭된 좌절을 겪은 느낌

이 분위기부터 바꿔야 유저를 위한 뭐가 되겠다

그러면 엔진 수정에 따른 이슈들도 독단이 아닌 협조가 되겠지 그래 너희가 만지는 프로그램 먼저 고치겠어!

일단 대충이나마 툴 구조부터 파악

엔진 7개, 툴 17개의 DLL

Kernel에 집중되지만 기존 프로그래머가 어떤 의도로 만들었는지 알겠다! 고 생각했다…

Kernel

Main

Automatic

View View View View View

Engine

하나하나 다시 자세히 보니 처음부터 이러진 않았겠지만

아름다운 실뜨기 구조더라

Kernel

Main

Automatic

View View View View View

Engine

View

Data

경고가 876개 거기다 별도의 라이브러리들을 합하면 1000개가 넘음…

이건 뭔가 비정상인데??

툴에 대한 히스토리 파악을 하려니까 툴을 아는 사람들은 퇴사했고

Svn 기록은 날려먹어서 1년치도 없었음

난관

1. 내 MFC 실력도 프로 레벨이 아님 2. 소스도 정상이 아냐

3. 외롭다외로워

이럴 땐 리팩토링

고치면서 익숙해져야겠다 단순하고 귀찮은 작업부터 시작

신입 입장에서 중요 소스를 건드리려고 하면 걱정이 앞선다

괜히 건드렸다가 되돌리지도 못 하면 어쩌지…

쫄지 말고 해보자!

“DevRookie Special ”

리팩토링 작업은 동일한 종류의 작업들이 있음 후위 연산을 전위로 바꾼다거나…

(어셈블리로 보면 int같은 기본형은 알아서 잘 해주지만, stl 같은건 안됨) 함수 꼭대기에 모아놓은 지역변수를 생성 위치로 옮겨주거나…

하여간 자주 변경되는 것들을 추려서 주석표를 하나 저장 일일이 적기 어려우므로 동일한 키워드를 설정해놓으면…

Ex : //사용하지 않는다 qsmname

이후에 알아보거나 찾을 때 편함

문제가 생기면 알아볼 수 있고 놓친게 있는지 알 수 있음 통계도 낼 수 있을 것 같은데 귀찮아서…

하지만 지금 생각해보니

통계를 내서 팀원들끼리 코딩스타일에 대한 토론을 하는 것도 좋을 것 같긴 하다

이 생각을 못 했구나…OTL

이게 괜찮았습니다

오른쪽은 읽기도 쉬움

SVN 히스토리가 없으니 주석과 코딩 스타일, 줏어 들은 이야기들로 친구를 만들어야겠다

1. 툴 처음 만든 사람 2. 코딩 스타일 혼자 틀린 누군가…

3. 퇴사한 전임사수

하다가 짜증나면 저 사람들 하고 혼자 대화함 외로움… (실제 도움이 됩니다 코딩호러의 오리인형과 똑같은 거에요)

문제를 한 줄로 보여드립니다 저거 4중 for문

line<>인줄 알았네 -_-; for문 반복에서 함수호출(어셈으로 보면 매번 호출)

게다가 사실 밑에 for문이 몇 개 더 있음…

그외에도 m_input, m_pinput, input 각기 다른 멤버변수 명명법

NsJob, nsjob, nsJob 대소문자 구별도 있더라 전역변수를 저렇게 해놨음

리팩토링

코딩스타일 통일 소스코드 개선 클래스 분할

프로젝트간 의존관계 정리 솔루션설정 변경

불필요한 리소스 제거 빌드 워링 제거 메모리릭 제거

엔진 빼고는 거의 다 수정(엔진은 이슈가 좀 있어서…)

단점은 svn 로그 보기가 귀찮게 됨 여기저기 많이 바꿨더니

Winmerge로 봐도 보기가 어려워짐

그래도 바로 읽기엔 훨씬 편해짐

그런데 사실 이런 일은 프로그램 팀에서만 이슈가 되지 (사실 아무 일 없었지만…) 현실적으로 툴의 사용자인

그래픽과 기획쪽에서는 알 수가 없다

그리고 사실 나도 안 써서 실무적인 불편함을 잘 모른다

그래서 몇몇 기획자에게 이야기 불편한거 있어요?

그리고 지옥이 시작되었다

기획자 몇몇에게 물으니 한숨 쉬거나, 조심스레 얘기한다 이런거 하나 있으면 좋겠는데…

그리고 꼭 안될꺼야 같은 말을 한다

급하게 안 해도 된다 하는건 이해하겠는데 기간을 너무 길게 잡는다

특별히 어려운 기능 추가하는게 아님에도 불구하고

물론

니가 할 수 있겠어?

라는 뉘앙스로 대충 대답한 사람꺼는

나중에도 잘 안 처리해줌 예민한 프로그래머임

어쨌든 점심시간에 받아서 그날 오후에 고쳐줌

기획자 일주일 불렀는데 벌써 했냐고 깜짝 놀람 흐뭇

그러면 어떻게 되는지 아십니까?

귀찮아집니다

안녕하세요 단축키좀만들어주세요창에서바로명령할수있으면좋겠어요툴에오타가있더라고요이거안돼요저거안돼요확대좀할수없나요확인창같은거안나오고그냥되게해주세요엑셀메모기능도좀있으면좋겠는데아그냥엑셀에있는것좀되게해줘요사실이런버그가있는데아저기저툴에있는기능은안되나요그거쉬운거잖아요월급받으면일하셔야죠돼요안돼요커피사줘요기타등등해줘요하여간뭐좀해주면안됩니까

그럼수고하세용~☆

갑자기 기획자들이 툴버그 찾기에 달려들었다 괜찮은 제안도 있었지만

별 말도 안 되는 얘기도 많았음

이래이래서 그럼 문제 생길텐데? 아!

이 사람들이?

작업자들의 불편함은 하드코딩이라도 좋으니 빨리 만들어주자

찜찜한 곳은 주석 나중에 고칠 수 있도록

그날 들어온건 최대한 그날 처리

좀 늦어도 다음날 아침에는 다됐어요~라고 보냈다

그러면 어떻게 되는줄 아십니까?

귀찮아집니다

기술적 채무는 채무 똥 위에 똥을 싸는 기분

어떤 새끼가 이렇게 만들어 놨어? 하고 보다 보니 내가 만들어놨네…

그래도 라이브는 개발 속도가 우선

설계상 어쩔 수 없을 때는 가능한 특정 지역에서만 처리하게

사실 누구나 할 수 있다!

생각보다 간단한 기능들 추가가 주 요구사항 한 10분이면 끝나는 것도 있고 하루종일 걸리는 것도 있지만

어쨌든 일일일개선을 목표로 추가 공부도 됨

결론적으로 요구 중 괜찮은건 해줌 안돼!라고 하지 않는 것을 목표로 설명은 최대한

나머지는 내 마음대로

단축키 제공 툴 속도 개선 툴 안정성 개선

데이터 오류시 툴에서 검사 ui 편의 개선

각종 로그 파일 제공 버그수정

개발하고 아직 적용 안 한 것도 있고, 완벽하진 않지만

조금은 나아졌다 생각함

발표자를 갈아넣고 있는 중 조금만 기다리세요!

“DevRookie Special ”

그러나 이것만으론 그냥 한가하고 만만한 프로그래머 낡았다는 이미지는 변하지 않는다

뭔가 획기적으로 다른 느낌을 줘야 할텐데…

MFC FEATURE PACK으로 버전업 XP보다 7처럼 보이면 좀 세련되 보이니…

혹시나 MFC를 사용중이라 똑같은 생각을 하시는 분이 있다면

버전업시 어떻게 되는지 알려드립니다

귀찮아집니다

마이크로소프트가 외부라이브러리를 사다 붙인거라서… 버그가 있다

예제코드 그대로 따라 해도 제대로 작동이 안 된다

FEATURE PACK은 C#에 밀려서 사용수가 적긴 하지만 그래도 MFC는 MFC

전 세계의 프로그래머들이 이미 질문해놔서 구글과 MSDN을 찾으면 해결은 있다

짜증은 난다

RIBBON 스타일 인터페이스로 변경 몇몇 편의기능 추가

어쨌든 매달 4주차 목요일 하는 업데이트가 끝나면

금요일은 버그 고쳐야 하니까 뛰고 다음주 월요일에 전체적으로 테스트 좀 돌려보려 계획

!??

팀장님이 나갈꺼면 나가고 아니면 신규 모바일에 참여하라고 함

2~3개의 프로젝트가 있다며 설명해주는데… 다 마음에 안 든다

모바일을 하는건 괜찮은데

기획이 잘 되고 안 되고를 떠나서 아예 없다는 느낌을 받았다

일단 할 생각을 하고 마음을 다스렸으나…

나중에 알아 봤더니 짬순으로 최고 잉여인력인 것을 깨닫게 됨

제가 막내임

덧붙여서 그 주 회의 때 모두에게

다들 안심하지 말고 나갈 준비 하라고 함

이대로 있어도 괜찮은가

일전에 농담식이었지만 아이디어 있음 위에 직접 들고 가도 됨 ㅋ

이야기가 떠오름

Project D * 자체심의를 존중해 궁금해하지 마세요 -_-;

모바일을 해야 한다면 좋다 좋은 아이디어를 내서 허가를 받으면 되지 않을까? 시장성과 정치적인 것들을 만족시키게 해보자

이번에야말로 결판 나기 전에

빠르게 움직이는 거다

회사의 아이덴티티와 시장이 바라는 것들을 충족 최대 1년 내외의 제작

충분한 수입을 뽑는 지속 가능 모델 누굴 끌어들여야 하고 누구랑 척을 지게 될지 고려

프로젝트를 성공 시키기 위해서 필요한, 혹은 같이 일하고 싶은 사람은 누구인가?

우리 회사는 스토리가 강하다는 이미지 IP 게임들이 비교적 성공

회사를 이끌어나갈 새로운 IP가 필요하다고 어필하면

좀 좋게 봐주지 않을까? 기존 IP와의 콜라보도 가능하게…

사실 꼭 제안 통과를 위한 수단이 아니라

진짜 그런게 필요하다고 생각함

던전 운영식의 게임이라면… 스토리도 살리고 과금도 먹이고 이후에 확장도 가능하겠다…

IP 활용도 ok 어떻게 개발하면 될지도 대충 구상이 됨

레퍼런스로 삼을만한 게임들 선정

망함

면담 다음날 바로 팀 분배…

또 급조한 기획이라 허점이 많은 상태

그래도 밀어붙여볼까?!?!?!

파트장님을 설득하고 해외기획 팀에서 인력을 끌어오면…

아 뭘 그렇게까지 처음 입사 소개해준 사람도 나갔는데 뭔…

결국 처음에 꿈꾸던 팀원이 되지 못 한 것

다들 나갈 고민하고, 공부하는걸 보면 좀 서글프더라

“DevRookie Special ”

작업을 하면서 느낀걸 정리해보자면

잘된점 1. 혼자 했다 – 자유롭게 할 수 있었다

2. 역시 만드는게 노는 것보다 재밌더라 3. 팀 문화는 조금만 노력해도 바뀐다

못한점

1. 혼자 했다 – 늦었다 2. 스트레스만 받는 날도 많았다

3. 상대가 그냥 고대로 살려 하면 안 바뀐다 나도 귀찮다

따라 하지 마세요 결론적으로 잘못했습니다

개발은 혼자 하는게 아니에요

도움이 됐던건 팀원들의 그래프를 그려봤던 일 팀장님의 실력을 100으로 잡았을 때

팀원들의 수치, 내게 기대하는 수치, 현재 내 수치 그리고 내가 지금까지 만나본 프로그래머들의 수치

내가 맘 편하게 놀 때가 아니구나!

좋다 이직준비를 하자 문제는 아직 자신감을 회복 못 했다

학습은

근자감->좌절->근자감->좌절 같은 구조일때 잘되는데…

나가면 새로운 모험 길에 올라서게 되고 또 적응하고…

계획했던 것도 이제 초입이라… 실력이 영 안 늘었는데…

아직 준비가 안 된거 같은데… 무서운데…

정신 상태가 이 모양이면 어떤 생각이 드는지 아십니까?

귀찮아집니다

프랑스의 철학자 들뢰즈 선생에 따르면 인간은 늘 과거로부터 도망쳐야 합니다

과거와의 차이와 반복이

인간을 더 인간답게 한층 발전하게 하는거죠

그러니 준비해 보겠습니다

빨리는 안될 듯

결론으로

오늘은 개발 경험을 좀 자세하게 나누고 자신의 구역에서 어떻게 살아가는지 이야기를 나누고 싶었습니다

그리고 지금 출발 30분전에 급조하고 있는데…

광고 쓸 시간에 이거나 만들지 그랬냐고 하시겠지… 아니 짤방 붙일 시간에 더 잘 쓰지 그랬냐고…

흑

제 발표가 너무 가볍다는 지적이 있어서 지난 과거 정리도 할겸

전 이런 경험 발표가 더 유익한 이야기가 나올 수 있다고 생각하지만

저도 익숙해진건지 모르니까 그리고 요새 잘 못 하기도 했고 -_-;

익숙한 발표도 이걸 마지막으로 다음부턴 다 잠 재워드리겠습니다

약은 그만할래요

어쨌든 우리는 익숙해지기 위해 노력합니다

그래서 익숙해지고

다시 낯설어져야 한다

자신의 익숙함을 돌아보고 다시 낯설어질 수 있다면

그리고 그걸 서로서로

공유해 보는 시간이 되었으면 합니다

모두모두 즐거운 프로그래머가 될 수 있도록!

Q&A

발표 후 피드백

익숙해지는 것은 당연한 것, 더 잘할 수 있도록 고민하라 잘 하려고 고민한 것은 좋은 일이다 그러나 뭔가 바꾸려 했다면 나쁜 일

신입사원에게 바뀌는 팀이라면 거기야말로 탈출하라 아무런 개발 철학이 없다는 것이다

항상 고민하고 또 준비하는 것이 필요하다

후일담

발표 하고 2일 후에 얼른 열심히 하라고 구조조정이 발생

그래서 에라 모르겠다 하고 명단으로 뛰어들었습니다

인생은 스팩타클

다음에 더 좋은 직장에서 만나요…