클로즈드 베타 테스트 기준 (2015-09-29)

공격
현재 방패가 상당히 강하다. 평균 실력 팀 또는 공방에서는 방패가 필승.

수비

방패를 잡아내는게 승리의 관건이다. 방패는 정면에서는 무적임을 명심해야 한다. 따라서 적이 들어올 입구를 한정시킨 뒤 교차 사격할 수 있도록 해야 한다. 즉, 수비 과정은 다음과 같다:

1. 방패가 들어올 입구를 한정시킨다. 다시 말해, 내가 짱박을 곳 옆이나 뒤에서 적이 들어오지 못하게 한다.

2. 방패가 입구로 밀고 들어올 때 최소 2 군데 이상(양쪽이 제일 좋다)에서 공격을 받도록 아군이 위치를 잡는다. 이걸 실패하면 그냥 방패 킬수만 올려주게 된다.


바리케이드 및 포지셔닝 기본:

바리케이드는 보호할 대상이 있는 곳에서 멀리서부터 쳐야 한다. 안에서부터 치면 갇히게 되므로 밖으로 못 나가게 된다. 가장 안쪽은 가장 마지막에 친다.

바리케이는 스스로를 방에 가두는 식으로 사용되면 안된다. 퇴로가 없으면 수류탄(특히 Fuse), 방패가 들어왔을 때 죽음뿐이다. 바리케이는 적이 들어올 것으로 생각되는 방향에 치는 것이다. 그리고 그 이유는 아래와 같다:

바리케이 아래 바닥에 보이는 전투화, 브리칭을 설치하는 소리, 바리케이를 손으로 때릴 때 눈치를 챌 수 있으며 이 순간 화력을 집중하여 킬을 낼 수 있다. 또한 직접 바리케이를 보고 있지 않더라도 소리로 적이 접근하는 방향을 짐작하게 만들 수 있다.

드론을 맞출 수 있다면 쏘되, 쫒아가지는 않아야 한다. 그 시간에 바리케이를 치는게 더 이득이다. 어차피 공격이 시작되어도 드론을 또 보낼 수 있기 때문이다.

수비할 방의 주변 방에 한 두명 씩 들어가 있는 것이 가장 좋다. 그리고 벽에 구멍을 내 지켜보면서 적들이 옆 방에 들어와면 쏴죽인다.

수비할 방에는 사람이 없어도 된다. 옆 방에서 구멍으로 수비 가능.

수비할 방 말고 그 옆 방들을 지킨다는 느낌으로 자리를 잡는게 좋다. 옆 방이 털리면 결국 방패가 수비할 방에 밀고 들어오기 때문에 퇴로가 없어서 진다.


직업:

Mute는 강화 벽을 Thermite가 깨고 들어오지 못하게 만드는 역할을 한다. Bandit도 같은 역할을 한다. 재머는 그 외 드론을 막거나 일반 바리케이트의 브리칭을 막을 수도 있다.

드론은 Mute의 재머를 점프로 뛰어넘을 수 있다.


수비 중 Light Armor(현재는 jager, bandit)는 이동 속도가 빠르므로 로밍을 다니는 것이 좋다. 다른 층에 숨어있다가 교전이 시작되었다고 판단되면 뒷치기로 뛰어나와 킬을 쓸어담을 수 있다. 만약 이때의 기습으로 한번에 적을 못잡아냈다면 킬 욕심을 버리고 생존하여 바로 다시 도망가야 한다. 그러면 공격측은 앞 뒤를 동시에 봐야 하므로(뒤쪽에서 수비가 오는 것을 알았지만 못 죽였으므로) 심리적으로 굉장히 불안해진다. 다시 교전이 시작되면 뒷치기를 가면 된다.

바리케이드가 쳐진 창문으로 공격이 들어오는 경우, 같은 방에 있는 수비측이 유리하다. 바리케이드를 때리는 순간 난사로 잡아낼 수 있다. 창문에 바싹 붙어 있으면 브리칭을 붙이는 소리도 들리므로 이때 난사로 공격하면 아주 좋다.

다른 모든 FPS를 해본 사람은 알겠지만 캠핑하는 쪽이 언제나 유리하다. 수비하는 사람은 자꾸 팀데스매치 하듯이 돌아다니지 말고 캠핑한다는 느낌으로 적이 들어올 입구 좌우 구석에 짱박고 있어야 한다. 공격은 방패가 제일 처음에 들어오므로 정면에서 샷발로 싸우려고 하면 방패에 막히고 바로 권총맞아 죽는다.

몸을 노출시키고 있으면 안된다. Q나 E (Lean - 몸 기울이기)을 써서 아주 최소한 사격에 필요한 정도만 몸을 내민다.

적의 위치를 잘 모를 때는 움직이지 않는다. WASD 키에서도 손을 떼고, 마우스에서도 손을 떼야 한다. 적이 들어왔을 때 움직이고 있는 상대는 굉장히 눈에 잘 띈다. 특히 포복 상태에서 아주 중요하다. 포복 상태에서는 몸 전체가 꿈틀거리기 때문에 움직이면 누워있는 표적이 된다.

수비할 때 공격이 들어올만한 입구가 막혀있다면 보고있어도 된다. 하지만 뚫려있다면 완전 은폐하여 있는 것도 좋다. 적이 방에 들어와서 아무도 없다고 생각하여 지나가게 만드는 것이다. 이때 소리를 듣고 뒤에서 몰래 나와서 공격한다. 아니면 자기를 발견 못하고 다른 수비 플레이어와 교전할 때를 노리게 만들어야 한다.

당연하지만 단단한 장애물 뒤가 가장 안전하다. 그러나 구멍을 내고 보는 경우 물렁한 벽이라도 좋다.

공격측이 가장 인식하기 어려운 상대는 벽에 구멍을 뚫고 감시하거나 공격하는 수비측 플레이어다. 반드시 써먹자. 이게 수비 최고의 방법이다.


방패는 느리다. 만약 방패와 조우했을 때 방패가 날 발견했다면 다음과 같이 행동한다:

만약 퇴로가 있다면 1초도 지체하지 않고 즉시 뛰쳐나간다. 방패는 이동 속도가 엄청나게 느리므로 쫒아오지 못한다. 이제 우회하여 뒷치기를 가면 된다. 우회할 수 없더라도, 다른 방으로 이동했다면 방패는 내 위치를 모르기 때문에 방으로 진입할 때 좌우를 보는 과정에서 반드시 측면이 노출되는 순간이 온다. 그 때를 노리고 쏴야 한다.

퇴로가 없을 경우, 내가 장애물 뒤에 숨어있는 상태이거나 빠르게 숨을 수 있다면 그렇게 한다. 절대 머리를 내밀지 않는다. 방패는 이 순간 나만을 바라보고 있기 때문에 괜히 머리를 내밀면 권총에 희생될 뿐이다. 아군에게 도움을 요청한다. 차라리 방패가 내 쪽으로 접근해서 싸우게 만들어야 한다. 거의 칼이 닿을 정도로 접근하게 만들면 뛰쳐나와서 측면의 머리와 옆구리를 쏴야 한다.

던질 수 있는 것은 다 던진다. C4, 수류탄, 가스 수류탄 등.



아군끼리 교전이 벌어졌다고 생각되면 바로 지원을 가야 한다. 안그러면 보통 방패에 멀리 있던 아군이 당하고 그 다음 내가 방패를 혼자 상대해야 하는데, 측면과 후면에서 같이 잡아줄 사람이 없게 된다.



---


글 써둔지 꽤 오래됐는데 버리기 아까워서 발행


반응형

'게임' 카테고리의 다른 글

몬스터헌터 월드 아이스본 PC판 세이브 파일 문제  (0) 2020.01.11

KB국민은행 등 일부 은행의 경우 웹에서 인터넷 뱅킹을 사용하기 위해서는 이런저런 플러그인을 반드시 설치하도록 되어 있다. 그 중 두 개가 veraport, delfino 이다.





위 두 개의 프로그램은 WIZVERA 사에서 만든 프로그램이다. (사이트 링크: http://www.wizvera.com)

WIZVERA 사이트에 따르면 veraport의 경우 "통합 설치 관리", delfino의 경우 "인터넷뱅킹 공인인증 전자서명 모듈"이 라고 한다. 이 프로그램들을 설치하지 않으면 인터넷 뱅킹을 이용할 수 없기 때문에 어쩔 수 없이 설치를 해야만 한다.


그런데 문제는 이 프로그램들이 인터넷 뱅킹을 마치더라도 종료되지 않는다는 것이다. 아래를 보자:



작업 관리자나 Proces Explorer 등으로 보면 위와 같이 프로세스가 떠 있는 것을 볼 수 있다. 그래서 이 프로그램의 서비스를 사용할 필요가 없는 상황에도 컴퓨터의 자원을 갉아먹는다.


그렇다면 이 프로세스들을 강제로 종료한다면 어떻게 될까? 프로세스를 강제로 종료하더라도 몇 초 뒤에 다시 프로세스들이 실행된다. 사람에 따라선 상당히 기분이 나쁠 수 있다. 보통 악성 프로그램들이 이런 행동을 하기 때문이다.


veraport와 delfino를 VirusTotal(www.virustotal.com)에서 검사해본 결과 악성 프로그램은 아닌 것으로 보인다. 하지만 저 거슬리는 프로세스들을 어떻게 하면 종료할 수 있을까?




먼저 결론부터 말하자면 종료는 할 수 있지만 수동으로 다시 실행해주기 전까진 인터넷 뱅킹 이용을 못하게 된다. 참으로 거지같은 상황이 아닐 수 없다. 가만히 내버려 두자니 시스템의 자원이 아까울 뿐더러 저 프로세스들이 백그라운드에서 무슨 정보를 수집하여 서버로 전송하거나 어떤 프로그램들을 다운로드 받아 컴퓨터에 설치하고 있는지 알 수가 없다. 그렇다고 종료하자니 인터넷 뱅킹 이용할 때마다 귀찮게 일일히 실행을 시켜줘야 한다.


일단은 왜 저 프로세스들이 종료되지 않는지 그 이유를 알아보고 그 다음으로 종료하는 법을 알아보자.




먼저 시작-실행-services.msc 입력 후 확인을 누른다. 시작-실행 대신 윈도우 키를 누른 상태에서 R 키를 눌러도 된다.



그러면 아래와 같이 서비스 관리자가 뜬다:



여기서 WIZVERA Process Manager Service 라는 것을 찾는다. 이 서비스가 wizvera.exe 와 delfino.exe 를 계속 실행시키고 있었던 것이다. 현재 시작됨 상태에 자동 시작 유형인 것을 볼 수 있다. 즉 이 서비스가 동작중이며, 서비스를 중지하고 컴퓨터를 재시작하더라도 자동으로 서비스가 다시 동작될 것이라는 것을 알 수 있다.


서비스 이름 위에서 마우스 오른쪽 버튼을 클릭하고 "속성"을 누르자:



그럼 아래와 같이 속성이 표시된다:





시작 유형은 "자동(지연된 시작)"으로 바꾸자. 이렇게 하면 부팅 속도가 조금이라도 빨라진다. 그리고 가장 중요한 것으로, 바로 아래에 보이는 "중지" 버튼을 눌러서 서비스를 중단시킨 뒤 확인 버튼을 누르고 나오도록 하자 - 참고로 다시 실행하려면 "시작" 버튼을 누르면 된다. 꼭 기억해야 한다.




그러면 이렇게 상태가 없어진다 - 즉 실행이 중단되었다. 이제 veraport.exe, delfino.exe 프로세스를 강제 종료하면 상황 끝.




다만 위에서도 말했듯이, 이렇게 하는 경우 인터넷 뱅킹을 다시 하려면 WIZVERA Process Manager Service 속성으로 들어가서 "실행" 버튼을 눌러줘야 한다. 그렇지 않으면 프로세스와 통신을 못하는지 공인인증서 화면이 뜨지 않는다. 상당히 거슬리는 부분이다. 


이제 ActiveX, NPAPI 모두 지원이 중단되고 있으므로 각 은행에서도 조속히 웹 표준을 지키는 인터넷 뱅킹 시스템을 만들었으면 좋겠다.

반응형

책 세 권을 샀다.


패턴을 활용한 리팩터링, 클린 코드, More Effective C++이다. 



일단 C++을 다루는 프로그래머라면 Effective C++ 3판, More Effective C++, 마틴 파울러의 리팩토링 책은 거의 필수로 가지고 있어야 한다고 생각했기 때문에 이걸 사려고 했는데 Effective C++이랑 리팩토링은 현재 품절 상태였다.


품절이 되니까 조금 겁이 나는게, 이러다 절판되서 영영 구할 수 없으면 어쩌나 하는 생각이 들었다. 제발 나와줘 ㅠㅠ



게임 프로그래밍을 하면서 많이 듣는 말이 있는데, 라이브 게임은 소스 코드가 더러울 수 밖에 없다는 말이다. 하지만 난 그 말에 동의하지 않는다. 더러울 수 밖에 없다는 말에는 자포자기와 자기 합리화가 엿보이기 때문이다.


라이브 게임의 코드는 24시간 언제나 변한다. 마감도 항상 빠듯하고, 버그가 발생하면 타격도 크다. 따라서 코드를 수정하는 데 보수적이 되는 경향이 있는 것 같다.



처음엔 클래스가 작았는데, 사소한 기능을 추가하거나 변경하다 보니 새로운 클래스를 만들지 않고 조건문 등을 추가해서 기존의 클래스 내에 기능을 추가하는 경우가 많다. 메소드 하나 짜리 일을 클래스로 빼려면 심리적으로 부담이 되기 마련이다.


하지만 이게 누적이 되다 보니, 클래스가 신적인 존재 - Super Class 또는 God Class - 가 되는 경우가 많다. 물론 코드는 잘 동작한다. 단지 이해하기 힘들고 변경하기 힘들게 될 뿐.



나는 코드가 더러우면 결국엔 프로젝트가 망한다는 믿음을 가지고 있다. 지금 작업 중인 코드를 계속 리팩터링해나가고 있다. 수 년간 쌓여온 코드는 단지 한 가지 기능을 추가하거나 수정할 때 수십개의 파일 또는 클래스를 수정해야 할 정도이다. 


가혹한 환경과 조건에서 프로그래밍을 했던 선임들의 마음은 충분히 이해하지만, 그렇다고 해서 지금 그들의 코드를 그대로 놔두는 것 또한 같은 프로그래머로서의 도리가 아닌 것 같다.



클린 코드(Clean Code) 책 뒤편을 보면 이런 말이 있다.


나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못하면 개발 조직이 기어간다.


반응형

참고: 2011/07/10 - [일기] - 기계식 키보드 첫 사용기 - 스카이디지탈 nKeyboard 메카닉 브라운


약 1년간 스카이디지탈 nKeyboard 메카닉 브라운(갈축)을 사용하다가, 이번에 레오폴드 FC300R 갈축을 또 마련하게 되었다.


링크: http://www.leopold.co.kr/?doc=cart/item.php&it_id=1301970288

9만 9천원에 구입했다. 사는 김에 키캡 리무버도 샀다 ^^ 지금 스카이디지탈 키보드가 너무 드러워서....



스카이디지탈 엔키보드 메카닉 브라운은 얼마 전에 회사에서 사용하기 위해 이동을 했는데, 집에서 멤브레인을 쓰기 시작하니 너무 허전하여 또다시 갈축으로 마련하게 되었다. 기왕 사는 김에 이번엔 유명한 모델을 사보자는 생각에 레오폴드의 FC300R을 구입하였다.



일단 느낌만 비교해 보자면, 스카이디지탈에 비해 좀더 쫀득거리는 - 기계식 키보드를 아시는 분들을 위해 설명하자면 더 흑축스러운 - 느낌이다. 그러니까 사각거림은 더 적고, 반발력이 좀 더 강하다. 그리고 키캡 높이가 더 낮은 느낌이다. 상대적으로 좀 더 구름타법스럽게 사용할 수 있다고 할까...? 내가 멤브레인을 오래 썼고 손가락 힘이 강해서 키를 누를 때 바닥 끝까지 팍팍 치는 스타일인데, 스카이디지탈은 바닥을 딱 딱 하고 치는 반면 레오폴드는 같은 압력을 주었을 때 바닥을 치는 딱 소리가 상대적으로 작았다. 좀 더 소음 면에서 준수하다고 생각된다. 또 F, J 키에 위치한 돌기가 좀 더 강한 느낌이다 - 사실 스카이디지탈쪽이 너무 돌기가 작았던 것 같다.



다른 차이로는 키 구성인데, 스카이디지탈 엔키보드 메카닉 브라운은 106키이고 레오폴드 FC300R 갈축은 104키이다. 그러니까 한/영키랑 한자키가 없다. 대신 오른쪽에 위치한 Alt 키가 한/영키, 그리고 오른쪽 Ctrl키가 한자키 기능을 하게 된다. 약간 어색했던 점은 한/영키를 누를 때 기존에 비해 위치가 좀 더 오른쪽이라서 스페이스랑 자꾸 헷갈렸다는 점이다. 아직 한자키는 쓸 일이 없어서 모르겠고...


또 다른 차이는 엔터키와 백슬래시(/의 반대 방향 기호, 또는 대한민국의 원화 기호인 \), 그리고 백스페이스 키가 다르다는 것이다. 엔터키는 좌우를 뒤집은 ㄴ자 대신에 작은 일자(ㅡ) 모양이고, 원래 엔터키의 상단 부분에는 백슬래시키가 위치한다. 그래서 엔터를 때리는 대신 백슬래시를 입력하는 불상사가 생기기도 한다... 



결론!


기계식 키보드에 첫 입문이고 한국식 106키 멤브레인 키보드가 매우 익숙하다면 스카이디지탈 nKeyboard 메카닉을 추천한다. 기계식 키보드 중 가장 저렴한 축에 속하고 익숙한 106키 방식이다.


엔터키 일자형이고 한영키 한자키 없는 104키 방식도 상관없으며, 멤브레인에 비해 키캡이 높은 기계식이 싫다면 레오폴드 FC300R도 괜찮은 선택이다.



키보드는 음식과 같아서 개인마다 취향 차이가 극명하다. 나는 회사에서 프로그래밍을 하는데 멤브레인 쓰면 손가락이 아프다 ㅠㅠ 스카이디지탈 엔키보드 메카닉 브라운은 키압이 상당히 낮은 편이라 이런 경우 유용할 듯. 


회사에 필코 마제스터치2 옐로우 청축을 쓰는 사람이 있어서 써봤는데 청축을 찰칵거리는 경쾌함이 느껴지긴 했지만 약 20여년간 멤브레인으로 코딩과 게임을 즐겼던 나에게는 상당히 익숙하지 않았다.


흑축은 전 회사에서 쓰는 사람이 많아서 써봤는데 멤브레인보다 키압이 강해서 별로 맞지 않았다.


리얼포스도 시타해봤는데 도각도각 느낌나는 멤브레인 느낌... 가격에 비해 많은 메리트가 느껴지지는 않았다.



반응형

SW마에스트로 하면서 진행했던 5인 프로젝트.

프로그래머 4명(대학교 학부생)에 기획 1명으로 진행했다.

2D 비행 슈팅 게임을 만들자! 라는 나의 염원이 이루어진 첫 작품.

C++, DirectX, FMOD, Lua를 사용했다. 기간은 총 한 달. 회의하고 방황한 시간 빼고 본격적으로 코딩한 기간만 따지면 약 2주 정도 된다.

애초에 직접 리소스를 만들 생각이 없었기 때문에 이곳 저곳에서 줏어다 썼다. 특히 Strikers 1945 리소스가 많다. BGM은 배틀필드3.





프로젝트 페이지:
http://dev.naver.com/projects/caffeinea 


반응형




한국에 인터넷 인프라가 막 보급되던 2000년도 초에는 회원 가입 시 자신의 아이디와 비밀번호가 이메일로 전달되는 경우가 많았다. 아마도 아이디랑 비밀번호를 까먹을까봐 전달한게 아닐까 싶기는 하지만 정확한 이유는 모르겠다. 그런데 요즘에도 이런 사이트가 있는 것을 확인했다. 바로 미스터피자이다.

이게 문제가 되는 이유는 여러 가지가 있다.


첫번째로 이메일이 전달되는 과정에서 비밀번호가 들어가있는 패킷이 제 3자에게 노출될 우려가 있기 때문이다. 회사 서버가 이메일 서버로 보낼 때와 내가 이메일을 열어볼 때의 두 시점에서 노출될 수가 있다. 쉽게 말하면 패킷이라는 것은 포장이 되어있지 않은 택배 화물 또는 봉투 없는 편지와 비슷하다. 중요한 내용은 아예 암호화해서 써놓아야 한다.

두번째는 조금 더 큰 문제라고 생각하는데, 바로 비밀번호를 암호화하지 않고 있거나 해독이 가능하다는 암시적인 증거가 되기 때문이다. 내 비밀번호를 저쪽에서 보내줄 수 있다는 것은 데이터베이스 서버에 내 비밀번호를 읽을 수 있는 형태로 저장해놓았다는 뜻이기 때문이다. 만약 미스터피자의 고객 데이터베이스 서버가 해킹을 당할 경우 나의 비밀번호가 해커에게 전달이 될 것이고, 거기다가 동일한 아이디와 비밀번호를 사용하는 모든 사이트가 털릴 것이다. 최소한 아이디는 아니더라도 비밀번호를 사이트마다 다르게 하는 것이 이래서 중요한 것이다. 영세한 회사는 보안이 취약하기 쉬우므로 이런 곳이 털리면 아무리 보안이 철저한 사이트라도 비밀번호를 알고 있으므로 그냥 뚫고 들어갈 수 있다.

만에 하나 이메일에 중요한 정보, 예를 들면 금융 관련 정보를 저장해두고 있는 사람이라면 무시무시한 피해를 입을 것이다.


여기서는 미스터피자가 대상이었지만 아직도 이런 회사들이 많은 것으로 추측된다. 가장 중요한 것은 해킹에 100% 안전한 곳은 어디에도 없다는 것이다. 반드시 비밀번호를 사이트마다 다르게 해주자.


 
반응형

C++에서 C#처럼 enum을 쓰는 방법이 있다!

namespace 관련해서 자료를 조사하다가 나온건데...
(참고: C++ namespace(네임스페이스) 코딩 스타일)
 
 

Unreal쪽 자료를 찾아보다가 여길 보니 enum을 C#스타일로 쓰기 위해 namespace를 사용한다는 내용이 나온다. 나도 예전에 생각해봤던건데 진짜로 쓰는 데가 있었구나!

http://udn.epicgames.com/Three/CodingStandard.html


기존의 C++ enum은 다음과 같은 문제가 있었다.
enum Color
{
    Red,
    Green,
    Blue,
... } void Foo(Color color) { switch(color) { case Red: ... break; case Green: ... break; case Blue: ... break; } }

enum이 전역 공간을 돌아다닐 수 있기 때문에 이름 충돌이 일어날 가능성도 높고 - 예를 들면 어디선가 const string Red = "Red"; 같은거 선언하면 모호해진다 - enum보다는 마치 #define된 상수처럼 보이며, 같은 enum소속인지도 알아보기 힘들고, 같은 enum내에 다른 멤버들이 어떤 것이 있는지 알아보기 힘들며, 어디서 사용되는지 유추할 길이 없는 등의 단점이 있다.

약간의 꼼수로는 Color_Red, Color_Green과 같은 이름을 사용하는 방법이 있긴 하다. 나도 지금까지 이렇게 해왔지만 이제 바꿀 예정!


Scoped enum을 사용하는 방법은 다음과 같다.
 
namespace Color
{
    enum Type
    {
        Red,
        Green,
        Blue,
... } } void Foo(Color::Type color) { switch(color) { case Color::Red: ... break; case Color::Green: ... break; case Color::Blue: ... break; } }
이제 각 enum형 상수들이 소속을 가지게 되었다! Visual Studio같은 IDE를 사용한다면 F12등을 누른다거나 Ctrl+Space를 눌러서 Color의 다른 멤버 목록까지 볼 수 있다.

 
다른 방법 - 밑줄 쓰기

다만 변수를 만들 때 ::Type 이라는 것을 붙여 줘야 하는데 - Color::Type 처럼 - 이것도 싫다면 Color_Red, Color_Green 등올 하는 것이 나을 것으로 보인다.

또 밑줄을 사용할 경우, 단독으로 숫자를 사용할 수 있는 장점이 있다. 예를 들면 Keys_1, Keys_2 처럼 사용하는 것도 가능한데, 만약 namespace를 사용한다면 Keys::1, Keys::2 와 같은 방법은 1과 2처럼 숫자로 시작하는 식별자는 컴파일되지 않는다는 면에서 상대적으로 장점으로 볼 수 있다. 뭐 나같은 경우 Keys::D1, Keys::D2로 쓰고 있기는 하다.


 
반응형

중첩된 namespace는 어떻게 써야 하나?

오늘 코딩을 하다가 namespace를 중첩해서 만들어야 할 일이 생겼다. 내가 C#에 영향을 많이 받은지라, 각 namespace의 계층 구조를 만들어서 써보자는 생각을 했다.

그런데 문제가 생겼다. 이거 들여쓰기를 어떻게 해야 할 지 고민된다.

몇 가지 방법을 생각해냈다.

1번

namespace Foo { namespace Bar {
    class ImYourFather
    {
        ...
    }
} }
2번

namespace Foo
{
    namespace Bar
    {
        class INeedACupOfCoffee
        {
            ...
        }
    }
}

3번

namespace Foo
{
namespace Bar
{
class WatchWhereYouShooting
{
    ...
}
}
}



일단 namespace를 제시하는 방법과, namespace와 class의 들여쓰기 방법이 차이가 난다. 따라서 내가 여기에 제시한 것 말고도 여러 변형이 나올 수 있다만, 일단 저 세 개를 후보로 정했다.

1번은 namespace를 옆으로 나열한 것이다. packed 방식이라고 하더라. 들여쓰기는 한 번만 된다.
2번은 namespace마다 들여쓰기를 한 것이다.
3번은 namespace와 class 모두 들여쓰기를 하지 않은 것이다.

예상되는 장점과 단점을 생각해 보자면...

1번
장점
namespace의 계층 구조를 쉽게 파악할 수 있다. 들여쓰기는 한 번만 된다. Visual Studio의 자동 들여쓰기에 의존해도 되므로 편하다. C++은 C#과 달리 namespace를 namespace Foo::Bar {...} 로 선언할 수 없는 것을 가장 유사하게 극복하는 방법이다.

단점
내가 따르는 일반적인 C++ Coding Style을 위반한다. 보통 중괄호는 별개의 라인에 작성해야 한다.




2번
장점
Visual Studio가 알아서 들여쓰기를 해주므로 편하다.

단점
namespace 계층 구조가 깊어질 수록 들여쓰기가 많아진다.




3번
장점
namespace 때문에 들여쓰기가 중첩되는 현상이 없다. 즉, 수평 공간을 낭비하지 않는다.

단점
Visual Studio의 자동 들여쓰기 기능이 있기 때문에 수동으로 왼쪽에 정렬해줘야 하는 불편함이 따른다. 별 것 아니지만 귀찮다.
왠지 namespace만 들여쓰기를 하지 않는게 거슬린다.
계층 구조를 파악하기가 조금 힘들수도 있다.




아... 정말 고민된다!

다른 프로젝트들은 어떻게 하고 있을까?

내가 좋아하는 C#

C#쪽은 대체로 2번 규칙을 따르는 것으로 보인다. 근데 C#은 namespace 지정을 namespace Foo.Bar {...} 이렇게 할 수 있어서 나름 들여쓰기가 절약이 된다.


Google

Google의 경우 3번 규칙과 비슷하다. 다만 중괄호가 같은 라인에 있다.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces


Ogre3D

게임 쪽은 어떨까... Ogre3D를 봅시다.
Ogre3D의 경우 2번 규칙과 비슷하다. 중괄호가 namespace와 같은 라인에 있는 경우가 일반적으로 보인다. 별개의 라인에 중괄호가 위치하는 경우도 있기는 하지만 같은 라인에 위치하는 것이 보다 일반적으로 보인다. 좀 더 살펴본 결과 3번 스타일도 사용하는 것으로 확인되었다. 오픈 스스기 때문에 여러 사람이 작업해서 그런건지 스타일도 여러개다.

Ogre3D의 namespace는 계층이 최대 2단계까지만 중첩되기 때문에 어차피 들여쓰기 문제는 없는 것으로 보인다.


WebKit, Mozilla

외국쪽 사정도 비슷한듯... 들여쓰기에 대한 논쟁이 좀 있다.
http://bugreports.qt.nokia.com/browse/QTCREATORBUG-567

살펴보니 WebKit도 3번 규칙을 따른다. http://www.webkit.org/coding/coding-style.html
Mozilla도 3번 규칙을 따른다. https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide


 VS2010에서 namespace indention 안하는 방법
http://stackoverflow.com/questions/3727862/is-there-any-way-to-make-visual-studio-stop-indenting-namespaces


Unreal Engine

사족: C++에서 C#처럼 enum 쓰기
Unreal쪽 자료를 찾아보다가 여길 보니 enum을 C#스타일로 쓰기 위해 namespace를 사용한다는 내용이 나온다. 나도 예전에 생각해봤던건데 진짜로 쓰는 데가 있었구나!

http://udn.epicgames.com/Three/CodingStandard.html


결론

이것 때문에 몇 시간을 다른 사람들은 어떻게 하고 있는지 찾는데 보냈다. 코딩은 언제 하나 ㅠㅠ

대개 3번 유형을 선택하고 있는 것으로 보이고 간혹 2번, 그리고 드물게 1번 스타일을 사용하는 것으로 보인다.

일단은 1번 스타일로 하려고 한다. 중첩된 namespace를 사용하기에는 가장 편리하고 적합한 것으로 보인다. 그리고 namespace 선언으로 발생하는 탭 하나 정도는 괜찮다. 어차피 C#도 보니까 그러더만... 너무 들여쓰기 많아져서 스트레스 받기도 싫고, 들여쓰기 집어넣느라 스트레스 받기 싫다.




반응형

지금 사용중인 놈:
http://skyok.co.kr/product.php?code=741


여태까지는 멤브레인과 노트북 키보드밖에 써본 적이 없다. 개인적으로 키보드의 키압(키보드 압력)이 낮은 것을 좋아한다. 키압 높으면 손가락 관절 아프다 ㅠ

처음 써보는 기계식 키보드인데, 정확히 말해서 다른 사람의 기계식 키보드는 몇 번 만져본 적이 있었다. 기계식 키보드의 존재만 알 때 만져본 녀석이 하나 있고 - 지금 생각해보면 갈축 - 흑축과 리얼포스를 만져본 적이 있다.

당시 하도 키보드랑 마우스를 많이 만져서 손가락 관절이 정말로 아팠기 때문에 흑축은 개인적으로 너무 손가락이 아팠고, 리얼포스는 그냥 업그레이드 된 멤브레인 느낌이었는데 가격이 너무 세서 놀랐다.


아무튼 돈이 좀 생기게 될 일이 있어서 이 김에 기계식 키보드 한번 써보자! 하는 생각에 조사를 좀 해봤는데... 여러 사람이 있는 공간에서 써야 될 키보드라 그나마 조용하다고 하는 갈축을 샀다. 넌클릭이라고 하더라. 
이 모델이 기계식 키보드 치고는 꽤 싸게 나온 것으로 보인다.


기계식 키보드, 그 중에서도 갈축이라는 녀석을 처음 써본 결과, 멤브레인에 비해서 아주 미칠듯이 좋은건 아니다. 좋다기 보다는 각자의 개성이 있다는 느낌이다. 다만 기계식 키보드는 제작의 특성상 가격이 비쌀 수 밖에 없을 뿐이고. 따라서 멤브레인이 더 좋다는 사람이 있다면 오히려 돈도 아끼고 좋다는 생각이다.

갈축이라는게 조용해서 사무실에서도 쓸 수 있다고 광고에 써있기는 했지만, 분명히 말해서 조용한 사무실 기준으로 멤브레인보다 두 배 정도의 체감적인 소음은 난다. 내가 한글 기준으로 타수가 
평균 500~600타/분 정도 나오는데, 아마 이 정도로 친다면 바로 옆에 앉아 있는 사람들이 내 키보드 소리가 거슬리지 않을 수 없을 것 같다. 솔직히 말해서, 치면서도 눈치때문에 스트레스 받았다(내가 좀 눈치를 많이 보는 스타일이긴 하다). 요즘은 그냥 누군가 태클 걸어줄 때까지 주변 신경쓰지 않고 치려고 한다. 

키압이 낮아서 좋고, 사각거리는 느낌이 좋다. 다만 키를 체감상 30%~40% 정도만 눌러도 인식이 되고, 말했다시피 키압이 낮기 때문에 지금 오타율이 좀 올라간 상황이다. 평소엔 키보드 치는 습관 상 건드리는 키들이 - 나도 이런 습관이 있는 줄 몰랐다 - 무시되었었는데 이제는 100% 입력이 들어간다. 

NUM, CAPS, SCROLL의 LED는 확실히 밝다. 뭐 쳐다보지 않으면 눈부시지는 않다. 밤에 불꺼놓고 쓴다거나 한다면 거슬릴 수는 있을 것 같다. 반대로 뭐가 눌려 있는지 확실히 알 수 있는 장점도 있다. NumLock, CapsLock 자주 쓰는 사람이라면 유용할 듯.

전체적으로는 만족하는 편. 고속으로 칠 때 눈치만 안보면 되는데 orz




옆옆 사람이 이틀 정도 청축 키보드를 썼었는데 꽤나 많은 피드백(?)을 받고는 집으로 철수시켰다 --; 사무실 끝에 있는 사람도 들릴 정도라니... 확실히 그 키보드 소리는 듣자마자 기계식 키보드의 진한 향기가 났다. 커피로 치면 에스프레소같은 느낌? 갈축은 진한 아메리카노 같은 느낌이다. 흑축은 라떼 정도 되려나...(?!) 나도 한번 쳐봤다. 짤깍거리는 클릭음이라는게 이런거구나 하고 느꼈다. 집에서 쓰면 적절할 듯.



반응형

사건의 발단 - 키보드 불량?

몇 달 MSI GE620 i7 N-Gene이라는 노트북을 샀는데, 키보드가 좀 말썽이었다. 솔직히 말해서, 140만원(2011년 03월 기준)이나 되는 노트북의 키보드가 이래도 되나 하는 생각이 들었다.

겉보기에는 좋아 보이고 멀쩡하긴 한데, 키 감촉이 영 좋지 않다. 가장 큰 문제는 키가 눌렸다는 느낌이 들었는데도 안 눌린 것으로 처리되는 경우가 있다는 것이다. 이 현상은 몇 번의 실험 결과 키를 가운데 누르지 않고 키의 가장자리쪽을 눌렀을 때 발생한다는 사실을 알아냈다.

특히 한/영 키가 문제였는데, 보통 엄지 손가락으로 누르게 되는데 이 키가 오른쪽 엄지 손가락보다 좀 오른쪽에 위치하기 때문에 아무래도 가장자리를 누르게 될 일이 많다. 난 분명 눌렸다고 생각했는데 한글과 영어가 전환이 되지 않아 스트레스를 많이 받았다. 하지만 A/S 센터를 가기에는 시간이 없었고, 연속으로 써야 되서 거의 3달 반 정도를 참고 썼다.


나중에는 그냥 내 키 누르는 습관이 바뀌었다. 그래도 한/영 키 누를 때마다 잘 바뀌었는지 불안한 느낌이 드는 것은 어쩔 수 없었다. 문서를 옮겨 적거나 할 때 모니터 안보고 치다 보면 한글과 영어가 반대로 써있는 경우도 많았다. 그럴때면...

MSI GT680 Phoenix 모델도 최근에 장만했는데 이녀석은 키 촉감도 더 낫고 한영 전환도 더 잘되는 느낌. 근데 겉보기에는 두 노트북 모두 같은 키보드다. 희안하네.


센터 방문

결국 오늘 큰 마음(?)을 먹고 용산의 MSI A/S 센터로 갔다.


사소한 실망

센터 위치는 꽤 좋은 편으로 보인다. 내부도 나쁘지 않았다. 까페 비슷한 분위기의 대기실도 있었다. 다만 세심한 배려는 약간 부족한 느낌; 예를 들면 커피 머신과 2개의 과일 주스 - 각각 포도, 오렌지 - 디스펜서가 있었는데, 커피는 나오지 않았고(뭔가 에러 메시지가 보였다) 음료수의 맛은 가히 최악이었다. 그리고 대기실의 노트북은 성능이 아주 안좋았고 작았으며(귀엽긴 했다) 무선랜도 엄청나게 느렸다. 나름 고객에게 노트북 어필할 수 있는 기회인데... 아무래도 A/S 센터다 보니까 이런 홍보적인 면에서는 본사에서 잘 관리하지 않는 것으로 보인다.

키보드가 잘 안 눌리는 안되는 현상을 앞에서 보여주고, 교체를 한번 했다. 약 15분이 소요되었다. 



커다란 실망

대기실에서 기다리고 있었는데, 중간에 기사님이 와서 내 노트북 운영체제의 비밀번호를 적어달라고 했다. 비밀번호는 남에게 알려주지 않는 것이 기본 아닌가... 그래서 결국 직접 수리실 같은 곳에 들어가서 내가 쳤다.

교체 후에 테스트해본 결과 좀 개선된 느낌이 들긴 했지만 - 솔직히 말해서 내가 키 누르는 습관이 바뀌어서 그렇다고 생각한다 - 역시 가장자리를 눌렀을 때 해당 문제가 계속 재현되었다. 이것은 기사님도 확인하였다. 그리고 한 번 더 교체를 요청했다. 기사님은 교체해봤자 증상은 동일할꺼라고 했다. 쩝.

두 번째 교체 후에도 증상은 개선되지 않았다. 물어본 결과 GT680이나 GE620이나 들어가는 키보드는 동일하다고 한다. 내 생각인데 두 노트북의 키보드는 같은게 맞는 것 같다. 다만 키보드 아래쪽의 공간이랄까, 구성이 좀 달라서 누르는 느낌이 다른게 아닌가 생각한다.

아무튼 이런 문제가 있으니 본사에 연락을 하든지 해서 리포트를 하고 피드백을 달라고 했는데... 뭐랄까 너무 안된다 어렵다 그래봤자 소용없을 것이다 이런 어조로 말씀하셔서 상당히 기분이 안좋았다. 물론 키보드 모듈을 잘 못 만든게 기사님 탓은 아니지만, 같은 MSI 소속 직원인 만큼 고객의 피드백 수집에는 신경을 쓸 것이라고 했는데 소속감은 없는 것 같은 느낌이다. 그냥 MSI가 싸놓은 똥 치우러 온 용병의 느낌.



그 외 의견:

개인적으로 두 노트북 다 LCD 패널이 글레어 타입이라서 마음에 안든다. 보통 사무실에 형광등이 많이 있는데 이거때문에 작업할 때 아주 짜증난다. 용산 간 김에 퓨어메이트 가서 안티 글레어(AG) 필름 발랐는데 모래알 생겨서 또 짜증이... 퓨어메이트 소개에는 자기네 회사껀 모래알 안 생기는 것처럼 써있어서 믿었건만 ㅠㅠ

그래도 형광등 보면서 멀미 안해서 좀 낫다.



반응형

+ Recent posts