소소한 일상 블로그

(대체 왜 이렇게 프로비저닝을 분기를 해놓은 건지.... 애플....)

일하면서 퍼블리셔 3개 회사를 겪어봤는데, 그 과정에서 알게 된 iOS 프로비저닝 정보를 정리한 표입니다.

매번 라이브 하다보면 까먹고 해서 생각난 김에 적어봅니다.

 - 대체로 퍼블리셔들은 inhouse 프로비저닝 (회사에 따라 Enterprise 프로비저닝이라고도 합니다) 은 기본으로 제공하고, 회사에 따라 다르지만, 기기 UUID 2대를 취합받아 Develpment 프로비저닝을 전달해 주는 듯합니다. ( Adhoc은 회사가 클수록 제한 기기가 부족하기 때문에 전달이 안 되는 것으로 추측합니다.)

 - 개발자 입장에서는 Adhoc 이 그나마 앱스토어와 비슷한 환경이여서 Adhoc을 전달해 주는 곳이 가장 좋긴 했습니다.

저는 iOS 프로그래머가 아니다보니 틀린 정보가 있을 수 있습니다. 지적해 주시면 감사히 배우겠습니다. 

새로 알게되거나 틀린 게 있으면 다시 업데이트하겠습니다.

첫 회사에 입사하는 신입 프로그래머의 마음가짐과 조심해야 하는 것들에 대해 한 번 적어보려고 합니다.

저도 신입 프로그래머 시절을 겪기도 했고, 몇몇 신규 입사자분들을 가이드해드리면서 느꼈던 것들을 적으면, 누군가에게는 도움이 될 수도 있고, 저 또한 마음가짐을 다시 다잡을 수 있을 거라 생각합니다.

참고로 저는 클라이언트 프로그래머입니다. 클라이언트 관점에서 작성되었습니다.

필수사항

- 이것만 지켜도 기본기는 되어있다!

1.  절대 본인이 모르는 코드는 넣지 마세요.
   • 라이브 프로젝트에서 이미 사용하는 코드를 가져오는 것은 좋습니다. 라이브에 서비스되며 검증된 코드니까요. 하지만 복붙 하더라도 코드를 정확히 파악하고, 필요한 것만 가져오세요.
   • 해당 코드가 뭔지 도통 모르겠으면 그냥 선임에게 물어보세요.
   • 작업자가 모르는 코드는 다 시한폭탄입니다.
   • 외부 오픈소스를 가져올 때도 확인하고 필요한 것만 가져오는 게 베스트겠지만, 여의치 않다면 충분히 검토하시고, 이 소스가 필요한 타당한 이유를 근거로 가져오시길 추천드립니다.
2. 작업하시면서 더 이상 사용하지 않는 코드가 생기면 바로바로 제거해 주세요.
   • 그때그때 정리 안 하면 혼란이 가중되고, 다음 작업자한테 떠넘기기 밖에 안됩니다.
   • 혹시 몰라서 내버려두었다는 소리는 잘 모르고 작업했다는 소리로 들립니다.
3. 항상 서버가 에러 날 수 있다는 상황을 염두하시고 코드를 짜주세요.
4. 작업자 간의 R&R이 있습니다. 아무 말 없이 다른 작업자의 작업공간을 침범하지 마세요.
   • 작업공간은 그 작업자의 책임하에 있습니다. 근데 작업자 본인이 모르는 작업이 생기는 건 위험하기도 하고, 실례라고 생각합니다.(부득이하게 작업하게 되면 작업 후에라도 알려주세요)
5. 함부로 타인의 코드를 바꾸지 마세요. (부득이하게 해야 한다면 나중에 공유해 주세요)
   • 변경해야 할 이유가 있다면 해당 작업자와 논의하시길 추천드립니다.
   • 작업자 간의 코드 스타일을 존중해 줍시다. 어차피 그 부분을 나중에 수정해야 될 사람은 그 담당자입니다. 본인 코드 스타일대로 바꿔버리면 혼란스럽습니다.
   • 특히 라이브라면 검증된 코드를 바꾸는 건 어떤 이슈가 터질지 모르기 때문에 더 위험합니다. (검증된 코드는 다시 테스트 안 하고 넘어갈 확률이 크거든요)
   • 비효율적으로 보여도 그렇게 해야 할 이유가 있을 수 있습니다.
6. 함수명 / 변수명은 역할을 알 수 있게 신경 써 주세요.
7. 적절한 자료구조를 사용해 주세요.다른 곳에서 썼으니 따라 한다는 1번과 같은 행동입니다.
8. 라이브 서비스는 서비스 안전이 최우선입니다.
   • 예를 들어, 코드 리펙토링 같은 건 큰 각오가 필요할 겁니다. 5번과 비슷한 맥락으로 함부로 하지 않으시길 추천드립니다.
9. QA를 맹신하시면 안 됩니다.
   • 귀찮더라도 테스트 꼼꼼히 해주세요. 예외상황은 작업자가 가장 잘 압니다.
   • QA는 기본적으로 기획 의도와 동작이 맞는가를 확인하는 최소한의 테스트입니다. 겉으로 쉽게 보이는 예외상황 외에는 찾기 힘듭니다.
10. 중복코드 최대한 줄여주세요.
    • 너무 복잡해서 실수하는 건 어쩔 수 없겠지만, 신경은 쓰시길 바랍니다. 다 낭비고, 잘못하면 꼬이니까요.
    • 자주 사용하는 함수는 static을 사용하세요. (static을 남용하지 말라곤 하지만, 자주 사용하는 함수는 오히려 static이 효율적일 수 있습니다.)
11. 공식이나 보정 값, 한 번만 쓰일 값 정도를 제외한 곳에서는 코드에 숫자를 그대로 쓰지 말고 enum이나 Define(const)로 관리해 주세요.
    • enum이나 const로 관리해 주는 것이 범용성 및 유지보수 측면에서 훨씬 좋습니다.
    • 수정 요청이 왔을 때 선언된 곳에서 추가/삭제/변경하면 끝이니까요.
    • 만약에 숫자를 코드에 그대로 입력한다면 - 반년 뒤에 "2"를 "3"으로 바꿔달라는 요청이 왔다면? "2"를 검색해서 바꾸시겠습니까? 몇 백개가 나올 텐데? 검색해서 운 좋게 찾는다 해도 그게 본인이 찾는 "2"가 맞을까요? 만약에 본인이 휴가 중이라면? 다른 작업자가 해야 된다면?

권장사항

 - 습관하하면 좋다 싶은 것들 또는 추천하고 싶은 것들

1. 형상관리 프로그램 (git, svn) 커밋하시기 전에 change Log에서 마지막으로 한 번 더 코드를 확인하는 습관을 가지시면 좋습니다.
2. 커밋 시 리버트 하기 쉽게 작업단위로 커밋하시면 나중에 문제 생겼을 때 원복하기 쉽습니다.
   • A, B 작업이 섞여서 커밋을 하게 되면, 후에 A가 문제가 생겨서 리버트 하면 B의 일부분도 리버트 되겠죠? 바로 에러가 나면 그나마 다행이지만, 에러조차 안 나서 발견 못하면 시한폭탄이 됩니다.
3. 일정시간 헤매고 있으면 그냥 선임에게 물어보세요. 일정이 우선입니다.
4. 플랫폼 작업과 같은 히스토리가 중요한 작업은 히스토리를 남기시길 추천드립니다.
   • 예를 들어 플랫폼 업데이트 내역 (버전과 사유), 에러 또는 장애 발생과 수정내역, 
   • 본인이 절대기억 능력자가 아니시라면 히스토리 관리 / 문서화가 협업, 유지보수에 있어 꽤 큰 도움이 될 수 있습니다.
   • (귀찮으시면 정리까진 아니더라도, 히스토리만이라도 카테고리별로 남겨두세요. 그것만으로도 도움이 될 수 있습니다.)
5. 일정 산정 시에는 작업 단위를 작게 끊어서 생각하시면 더 편합니다.
6. 일정 산정이 힘드시다면 본인이 작업을 하시면서 작업 전에 예상 일정을 적고, 작업 후 실제 걸린 시간들을 적으면서 연습해 보세요.
   • 일정 산정에 감이 잡히실 거고, 본인의 실력을 객관적으로 판단할 지표로도 쓸 수 있을 겁니다.
7. "나중에 수정하지 뭐...."하는 생각하지 말아주세요. 안합니다. 99퍼센트, 그 상태로 라이브 나가면 검증된 코드라 더 이상 손대기도 힘들어요.
8. 어떤 업무적인 행동이나, 의사 결정을 할 때, 그 이유를 명확히 하는 연습을 하세요.
   • 쉽게 예를 들면, 자료구조를 무엇을 사용할 것인가 왜 이게 적합한가, 상속 구조를 어떻게 가져갈 것인가, 작업 우선순위를 어떻게 할 것인가 등등.
   • 상황에 따라 귀찮고 어려울 수 있지만, 어렵다고 안 하는 거랑 하려고 노력하는 거랑은 다르니까요. 저도 여전히 노력하고 있습니다.
   • 일하다 보면 코드뿐 아니라 여러 상황에서 "왜 그렇게 했는가" 질문이 들어올 때가 많습니다. 혼내려고 묻는 게 아니라 상대방도 제 상황과 생각을 모르기 때문에 묻는 겁니다. 본인의 생각을 명확히 말할 수 있다면 좋은 인상은 물론, 상대방과 더 심도 깊은 논의를 할 수 있고, 혹시라도 틀리거나 부족하면 피드백을 받아 더 생각의 깊이를 늘릴 수도 있을 겁니다.
   • 본인이 충분히 생각해 보고 결정한 것을 피드백받는 것과 단순하게 작업해서 피드백 받는 것은 경험의 질이 다를 거라 생각됩니다.
9. 일을 이해하고 하세요.
   • 지시하달로 업무를 할 때, 그 일이 왜 필요한가 제대로 파악하고 하시길 바랍니다.
   • "왜 이 작업을 하세요" 했을 때 ~가 시켜서요 만큼 힘 빠지는 답변도 없습니다. 
   • 이유를 알고 하는 것과 그냥 누가 시켜서 하는 것은 결과가 질적으로 다릅니다.
   • 이해하기 위해 지시자에게 물어보는 게 참... 어렵죠... 그래도 하는 게 좋습니다... 여의치 않으면 본인이 생각해서 그 의도를 추측이라도 해야 좋겠죠. 
10. 타 부서가 볼 수 있는 메일은 최대한 간결하고, 명확하게, 초등학생도 이해 가능하게

너무 당연한 것들 아닌가? 하실 수도 있는데, 새로운 환경에 들어서게 되고, 낯선 사람들과 일하게 되면, 당연한 게 당연하지 않게 되더라고요. 직접 겪은 경험담이기도 하면서, 곁에서 여럿 보기도 했습니다.

저는 신규 입사자분이 들어오시면 작업하신 코드들을 전부 간단하게라도 확인을 해보고, 피드백을 드리는 편인데, 이 과정에서 생각보다 위의 필수사항에 있는 기초적인 실수들을 많이 보이시더라고요. (기억은 잘 안 나지만, 저도 아마 그랬겠죠) 이후에 같이 일해 보면서 느낀 건 그분들이 실력 문제라기보단 코드파악, 새로운 환경에 따른 긴장, 일정의 다급함 등 다른 요소로 인한 거라 생각이 들더라고요. 사회 초년생들이 당연한걸 왜 안 했지, 왜 몰랐지 하면서 자책을 많이 하기도 하잖아요. 당연한 걸 당연하다고 그냥 넘어가기보단, 한 번 숙지하고 마음가짐을 다잡는 게 조금이라도 도움이 되지 않을까 싶더라고요.

아무튼 사회 초년생분들에게 조금이나마 도움이 될 수 있기를 바라며,

이건 어디까지나 제가 겪으면서 생각한 것들이기에, 반박 시 여러분 생각이 맞습니다!