최초 작성일 : 2011/10/20 10:26 


원문 링크 : http://i-guacu.com/2717


트위터에서 우연히 임정욱(@estima7:라이코스 CEO)님과 김진중(@golbin:파랑새 개발자, Blogcocktail)님의
대화를 보게 되었다. 기획자가 본 어느 개발자의 이야기...

뭐 두 분 모두 안면이 있는 것도 아니고 내가 주제넘게 낄 위치도 아니고...^^
그냥 이 누추한 공간에 느낌을 한 자 적어본다.

사실 나는 약간 사이비 개발자다.
국문과를 졸업해서 1992년 초쯤 코볼 한 달, 어셈블리 한 달 정도를 학원에서 배워보고
군대 갔다 와서 98년 말쯤 역시 같은 학원에서 한 5개월 C/C++/MFC를 몽땅 마스터(?)했다.

이후로 인터넷 세상이 펼쳐지면서 HTML, javascript, asp, php, java 그리고 현재의
objective-c까지 독학으로 공부해오면서 개발자라는 명함을 내밀기에 아슬아슬한 선에서
생활을 해오고 있다. (그래도 이렇게 적어놓고 보니까 꽤 그럴싸하다...@___@

아마도 나와같은 비전공자 출신의 개발자들은 모두 비슷비슷하지 않을까 싶다.
따라서 여기 적은 내 의견도 비전공 출신 개발자들이 본 개발자의 모습일 듯싶다.

현재 프리랜서로 일을 하고 있지만 올 초까지 직장을 구하기 위해 무지 노심초사 했다.
2010년 4월 회사를 그만 두고 1년간 iOS 개발 공부한다고 쉬다가 다시 취업 하려니
그리 만만치 않았다. 역시 가장 신경쓰이는 것은 나이...ㅠ.ㅠ

이건 순전히 추측이지만 잡코리아에서 잘나가는 아이폰 앱 개발사에 원서 한 번
넣었는데 내가 넣기 전에 '나이 무관'이라고 적혀있던 구인 내용이 그 다음날로
바로 76년 이후 출생자로 바뀌더라는...ㅠ.ㅠ

그러다가 모 업체에서 연락이 왔다. 어차피 자바 웹 개발 경력이 가장 길기 때문에
대부분의 분야에 모두 지원을 했는데 그 업체는 웹 개발 업체였다.

일단 사무실에 들어섰는데...대략 70년대 공장 분위기였다.
청소도 안되어있는 사무실 하며 희뿌연 공기는 절반이 니코틴 인 것 같고...
집기나 파티션들은 분명 중고시장에서 싸게 샀거나 고물상에서 헐값에 업어온 것이
틀림없어 보이고...

면접이 시작되었는데 사장님은 작업복을 입으신 조금은 인상 좋아보이시는 분이었다.
근데...기술 면접을 한다고 들어온 팀장은...아마도 자다 일어났나보다.
술과 담배에 쩔어보이는 시커먼 얼굴에 자신의 실력을 맹신하는 개발자 특유의
고집이 얼굴에서 발끝까지 녹아내리고 있었다.

그리고 면접 시작
다른건 별로 기억 안난다. 사실 SI쪽 경험이 부족한(SM 경력이 좀 길고 SI는
단기성 몇 건밖에 없음) 것은 사실이라 그 부분에 대한 지적은 받아들일 수 밖에
없었다. 그러다가 갑자기 DB 테이블을 몇 개까지 다뤄봤냔다.

사실 미션 크리티컬한 업무 경험이 전무한지라 테이블 많아봐야 한 20-30개 정도
선이 내가 다뤄본 최대 갯수였다. 난 그것도 많아보인다...ㅠ.ㅠ

그랬더니 노골적인 비웃음이 내 콧잔등을 간질거린다. 그러더니 난데없이
1500-2000개를 말한다. 이런 회사에서 그만한 테이블을 관리한다는데
뻥이요 냄새가 좀 났지만 겸손하게 고개를 끄덕였다. 그리고 끝무렵에 지난 회사에서 얼마
받았냐길래 말해줬더니 '많이 받았네요.' 이러더라...-.-

암튼 면접 내내 든 생각은 이 회사는 '이 한 사람' 때문에 다닐 수 없는 회사구나 하는
생각이었다.

한 사람의 예를 가지고 전체를 평하기에는 너무 일반화가 심한 것 같고
다만 내가 개발자로 일하고 있으면서도 '무서운 개발자'를 많이 접하게 된다.
상이한 의견이 도출되었을 때 다양한 관점에서 다양한 시도를 통해 합리적인
해결안을 모색하기 보다는 자신에게 가장 업무량이 줄어드는 방향으로 자신의
지식과 고집을 이용해 해결을 보려는 개발자들이 적지 않았다.

지식은 생각보다 무서운 힘이다. 지식이 있는 자들은 남을 속일 수도 있다.
사실은 나역시 그렇게 남을 속여 본 적이 있다. 좀 오래 걸리고 힘든 방법이 있지만
고객의 마음에 안들더라도 내게 쉽고 짧게 끝나는 방법이 있다면 그 방법으로
유도를 하곤 했다.

하지만 분명한 것은 그 방법이 최선은 아니었다는 것이다.

그렇게 '무서운 개발자'는 동료 개발자조차 접근하기가 힘들어서 팀웤이 깨지기 일쑤다.
그리고 그렇게 팀웤이 깨지면 프로젝트가 산으로 가거나 그 '무서운 개발자' 손아귀에서
진행되게 된다.

개발자는, 프로그래머는 가장 합리적이면서 가장 보편적이고 가장 정직한 해결책을
준비해야 한다고 생각한다.

그런 한편으로는 그런 개발자들은 원문에도 나와있듯이 고객과의 대화를 애써 외면한다.
만나봐야 엉뚱한 소리나 하고 일거리나 늘리고 별로 중요하지도 않은 시시콜콜한 것
(예를 틀면 맞춤법 하나 틀린 것, 간격 하나 더 떨어진 것)가지고 시비를 건다고
생각하는 것이다.

하지만 그래서 더 만나야 한다.
이제 개발자들은 전달 받은 이야기에 짜증 버럭 할 것이 아니라 직접 고객의 이야기를
듣고 자신의 의견을 설득할 수 있는 능력이 필요하다.

많은 개발자들이 불완전한 기획서나 고객의 요구사항에 대해 '추측'으로 일관하면서
불평 불만을 늘어 놓는 것 처럼 보인다. 하지만 실상 고객과 직접 이야기를 하고
고객의 요구에 어느 부분이 어째서 쉽지 않은가를 설명을 하면 대부분의 고객들은
그 내용을 수용을 한다.(사실 지금도 이런 상황을 겪고 있다.)

그럼에도 '개발자'라는 자존심, '이 것 만큼은 내가 더 많이 안다'라는 오만이
고객을 무시하는 말투를 만들어내고 대화는 단절되고 추측은 난무하고 프로젝트는
산으로 가게 만들고 만다.

너무나 구태의연한 말이라 쓰기도 쑥스럽지만 벼는 익을수록 고개를 숙인다.
많이 안다면 그 아는 것을 쉽게 풀어 이야기 할 수도 있어야 할 것이다.
이제는 고객도 예전의 고객들이 아니다.

어차피 구성원 모두가 함께 힘을 합쳐야 성공할 수 있는 '프로젝트'라면
서로 한 발짝씩 물러나 상대방을 보고 또 자신을 볼 필요가 있을 것이다.

부디 자신의 프로그래밍 실력과 지식을 '전가의 보도'처럼 휘둘러오지는 않았는지
되돌아 볼 일일 것 같다.

간만에 긴 글을 썼더니 중구난방이다.
양해 부탁드림...^^;;;

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/08/31 13:48 


이번에는 프로젝트에 프로젝트 삽입하기에 이어 프레임워크와 라이브러리를

추가하는 부분에 대한 팁이다.

물론 추가하는 것 자체를 모르는 사람은 아마도 거의 없을 것이다.
일단 간단하게는 파인더의 경로상에서 프레임워크나 라이브러리를 찾아
부드럽게 해당 프레임워크나 라이브러리를 드래그앤 드롭하여
Xcode의 프로젝트 탐색창에 떨어뜨려주면 된다.
(참고로 프레임워크는 .framework확장자로 끝나는 디렉토리 형태이고
 .a 확장자를 갖 것은 정적 라이브러리, .dylib 확장자를 갖는 것은 동적 라이브러리이다)

그럼 이게 뭐가 어려워서 팁을 쓰고 난리 부르스냐...?

iOS의 프로그래밍 언어인 Objective-c는 조상격인  C/C++과도 호환이 가능한
언어이다. 이 것은 언어의 확장성 면에서 보면 상당히 좋은 특징이긴 하지만
자바와는 달리 라이브러리를 구했을 때 언어적 기반이 다르면 손을 좀 봐줘야 하는
문제가 있다.

이번에 겪은 가장 큰 문제는

1. 프레임워크를 삽입해서 컴파일했더니   x86_64, i386, armv7, armv6 등의
    아키텍쳐에 대한 심볼이 없다는 에러가 난다.
2. 헤더파일의 경로 설정의 문제
이 정도가 있다.
차근차근 살펴보자면
1. 특정 아키텍쳐에 대한 심볼이 없다는 에러가 발생하는 경우. 
사실 이 경우가 가장 혼란스럽고 해결하는데 시간이 많이 걸렸다.
프로젝트의 빌드 세팅에서 Architectures, BaseSDK, Valid Architectures를
아무리 설정을 해줘도 계속 에러를 뿜어내니 환장할 지경이었다.
※ 쉽게 말해 Architecture는 하드웨어인 CPU를 설정하는 것이고
   BaseSDK는 해당 CPU에 맞는 SDK를 설정하는 것이고
   Valid Architectures는 호환 가능한 CPU를 설정하는 것이다.
   BaseSDK를 먼저 선택하면 Architecture는 자동으로 설정되는데
   i386(32비트 CPU)와 x86_64(64비트)의 인텔계열 CPU는 Mac OS X를
   선택했을 때 설정되고 iOS를 선택하면 armv6, armv7이 선택된다.



특히 문제가 많이 발생하는 경우는 C++로 작성된 라이브러리나 프레임워크를
추가하는 경우인데. 계속해서 i386또는 x86_64 Architecture용 심볼이 없다는
에러가 발생했다.
이 때 가장 쉽게 해결하는 방법은 프로젝트 경로상에 내용 없이 비어있는 .cpp 파일을
하나 추가해서 컴파일 해주면 간단히 해결된다.
이유는...사실 잘 모르겠다. 이메일 관련 라이브러리를 검색하다가 찾게된
ChilKat라는 상용 라이브러리 제작사 홈페이지에서 이같은 내용을 발견했다...^^;;;
2. 헤더파일의 경로 문제는 사실 고수들에게는 문제라고 할 것 까지도 없다.
하지만 나는 영원한 초보니까...ㅠ.ㅠ
우선 모두 알고 있듯이 사용자가 만든 헤더파일은 프로젝트 내에 포함되어 있으므로
별다른 표시 없이 그냥
#import "header.h"
이렇게 사용을 하게 된다.
다음 프레임워크에 포함된 헤더파일은 프레임워크라는 별도의 디렉토리에
위치하므로(앞서 프레임워크는 .framwork확장자로 끝나는 이름의 디렉토리라고
말했다)
#import <Framework/Framework.h>
이렇게 프레임워크 이름의 경로명을 앞에 붙여주게 되며 ""이 아닌 <>로 감싸주게
된다.
문제는 라이브러리를 사용할 경우나 아니면 프로젝트 내에 프로젝트가 삽입되어
있는데 이 삽입된 프로젝트 내의 파일들이 모두 <>로 표현된 import문을 쓰고
있을 경우이다.
우선 라이브러리의 경우 하나의 단일 파일로 배포를 하게 되는데 이 안에는
실행 파일이 될 .c, .cpp, .m, .mm 등의 파일만이 포함되며 헤더 파일은 별도로
배포하게 된다. 따라서 .a, .dylib의 라이브러리 파일을 구할 경우에는 반드시
헤더파일(주로 include라는 디렉토리에 배포한다)을 같이 다운로드받아 프로젝트에
포함시켜야 한다.
다음 프로젝트 여러개가 중첩된 경우...
이 경우는 거꾸로 거슬로 올라가야 하는데...
만일 import문에 <>를 사용해서 헤더파일을 찾을 수 없다는 에러가 발생한다면
상위 프로젝트가 하위프로젝트의 어떤 타겟에 의존(사용)하고 있는지를 확인하여
혹시 정적 라이브러리가 참조되고 있다면 이 것을 프레임워크로 바꾸어주어야 한다.
하위 프로젝트의 타겟에 프레임워크가 없다면 새로 빌드를 해주어야 한다.
말로하니 엄청 복잡해보인다...ㅠ. ㅠ
어쨌든 대체로 이정도 하면 헤더 파일 문제도 해결된다.
어제도 오늘도... 그리고 내일도...
늘 시시한 팁만 정리하고 있는 나는 언제 고수의 반열에 오를까...-.-

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^