빌딩과 개집

시중에는 넘쳐나는 수많은 소프트웨어 개발 방법론이 있습니다. 지금까지 알려진 방법론만 100가지가 넘습니다. 인터넷에서 이에 대한 설명만 보고 Template만 복사해 와서 회사에 적용하기에는 무리가 있습니다. Template과 Sample만 보면 방법론을 적용하여 선진 개발 방식을 따라 할 수 있을 것 같지만, 이는 착각입니다. 

방법론 자체가 잘못되지 않았음에도 잘못된 방식으로 오해를 하여 적용을 하거나 특정 부분에 집착하여 전체를 놓치는 경우가 많습니다.

집을 짓는데 빌딩을 만드는 방법을 적용하면 안되고, 그렇다고 개집을 만들 때처럼 대충 지어서도 안 됩니다. 개집을 만들 때는 대충 만들어도 되고, 안되면 다시 만들면 됩니다. 빌딩을 만들 때는 한치의 오차도 없이 정확하고 복잡한 방법을 사용해야 합니다. 

빌딩을 만드는데 대충 만들고 마음에 안들면 다시 만들고, 요구사항을 중간에 마구 바꾸면 안된다는 누구나 알 수 있습니다. 

그 반대로 개집을 만드는데, 정교한 설계와 많은 시간과 비용을 들일 필요는 없겠지요.

하지만 소프트웨어를 개발하는 현실 세계에서는 이와 같은 일들이 흔히 벌어집니다. 

빌딩과 같은 시스템을 만들면서 형식적으로만 방법론을 따르지만, 아키텍쳐는 심각하게 고려하지 않고, 요구사항이 철저히 분석, 검토되지도 않고 나중에 요구사항을 마구 바꿀 수 있다고 생각합니다.

모든 개발 방법은 프로젝트의 특성에 따라서 적절히 정해져야 합니다. 많은 경우 작거나 중간 규모의 프로젝트를 진행하면서 거대 프로젝트에 적합한 방법론을 기계적으로 적용하려고 합니다. 또는 정반대로 완전 주먹구구식으로 진행하는 경우도 많습니다. 

작거나 중간 규모의 프로젝트에 개발 방법론을 적용하려면 뭔가 생략하고 간소화를 해서 적용해야 할 것입니다. 그런데 무엇을 생략할지는 그 원리를 모르면 알기가 어렵습니다. 따라서 인터넷이나 소프트웨어 공학책을 통해 쉽게 익힌 방법론을 회사에 적용하는 것은 무리가 있습니다. 각 회사에 맞는 개발 방법론을 적용하려면 전문가의 도움을 받는 것도 좋은 방법일 것입니다.

개발자 채용 시 코딩테스트를 하시나요?

연기자나 가수를 뽑을 때 오디션을 보듯이 개발자를 채용할 때는 코딩테스트가 꼭 필요합니다.

하지만 코딩테스트를 하지 않고 채용하는 경우가 매우 흔합니다.

이력서를 통해서 그 개발자가 과거에 참여했던 프로젝트가 무엇인지 보고 인터뷰에서 이거 저거 물어보는 것만 가지고는 개발자의 실력을 평가하기는 아주 부족합니다.

코딩 테스트는 다음과 같이 3가지 타입으로 진행할 수 있습니다.

첫째, 인터뷰를 하기 전에 E-mail을 통해서 코딩테스트 과제를 전달할 수 있습니다. 

이때는 시간이 반나절이나 하루 정도 걸리는 과제를 줄 수 있고 꽤 많은 내용을 점검할 수 있습니다.

단순히 로직 뿐만 아니라 코딩 습관, 최적화 시도, 소스트리, 빌드 스크립트 등 다양한 실력을 엿볼 수 있습니다.

1차에 끝나는 경우도 있고, 시험대상자가 너무 많으면 1,2차에 걸쳐서 1차에서는 기본적인 과제로 기본 이하의 개발자를 거르고 2차 과제에서 진짜 문제를 낼 수도 있습니다.

이 테스트의 단점은 다른 사람이 도와줄 수 있는 것입니다. 대부분의 경우 본인 스스로의 힘으로 과제를 해결하지만 실력이 좋은 사람이 도와 줄 경우 이를 확인하기 어려우므로 인터뷰 시 몇몇 내용을 확인하는 것이 좋습니다.

예) Caching 알고리즘 구현

둘째, 인터뷰를 하는 날 인터뷰를 하기 전에 코딩테스트를 하는 것입니다. 인터뷰 전에 약 한 시간 정도면 풀 수 있는 과제를 주고 코딩을 하게 하는 것입니다. 노트북을 준비해 오게 해서 인터뷰 전에 코딩을 시키고, 인터뷰 시 발표를 하게 하는 방법입니다. 실력을 적나라하게 볼 수 있는 좋은 방법 중에 하나입니다.

예) Quick sort 알고리즘 구현

셋째, 인터뷰 시 칠판에 간단한 코딩 과제를 풀게 하는 겁니다. 약 10분이면 풀 수 있는 간단한 문제여야 하고, 이 때는 개발자가 최소한 논리적인 사고를 하는지 점검할 수 있습니다. 사실 코딩 인터뷰를 시도해보면 이 10분에서도 각 개발자들이 엄청나게 많은 차이를 보입니다. 일반 인터뷰 질문으로는 확인할 수 없는 수많은 것들을 여기서 파악할 수 있습니다.

예) itoa함수 구현, strtok 함수 구현 

위 3가지 방법은 모두 효과가 있기 때문에 회사의 상황이나 규모 등에 따라서 적절히 선택을 하면 되겠습니다. 

코딩테스트는 추가 비용 거의 없이 개발자의 실력을 구분할 수 있는 좋은 방법입니다. 아주 뛰어난 개발자를 판단하기는 어려울 수 있어도 형편 없는 개발자는 잘 걸러 낼 수 있습니다.

과거의 경험에 대해서 얘기를 들어보면 경력만 보고 채용을 했다가 아주 쉬운 코딩도 믿고 맡기기 어려운 경우가 많더군요. 코딩테스트는 이러한 것을 막아줄 좋은 수단입니다.

하루 8시간 일하시나요?

하루에 8시간 일하시나요?

그렇다고 프로젝트 일정을 예측할 때 하루 8시간 일을 하는 것으로 계산하십니까?

그러면 프로젝트 일정을 지키기 어려울 것입니다.

보통 아무리 집중해서 일을 한다고 해도 하루에 80% 일하기 어렵습니다.

나머지 20%의 시간은 회의를 하고, 커피도 마시고, Email도 봐야 합니다.

또 2개의 프로젝트에 4시간씩 할당이 되어 있어도, 업무 전환 비용(Context switching cost)를 무시할 수 없습니다.

물론 프로젝트 일정은 프로젝트 관리자 혼자서 마음대로 정할 수가 없습니다.

실제 업무를 담당할 담당자들의 도움을 받아서 일정을 산정하게 됩니다.

이때 담당자들이 산정한 일정을 그대로 받아들이나요? 아니면 스스로의 버퍼를 따로 두시나요?

저는 하루의 업무시간을 보통 8시간*80%로 잡고 일정을 산정합니다. 

그 이유는 다음과 같습니다.

• 개발자의 기술력은 믿지만, 일정 예측 능력은 믿을 수 없습니다.
• 프로젝트를 진행하다 보면 항상 예상치 못한 일이 발생합니다.
• 프로젝트가 막바지로 가면, 특히 통합과정에서의 혼란을 개발자들은 쉽게 생각하는 경향이 있습니다.
• 과거의 경험으로 보면 예상된 일정보다 빨리 끝난 프로젝트는 거의 없었습니다.

낙관적인 일정도 나쁘지만, 일정을 너무 비관적으로 잡으면 프로젝트팀이 자칫 게을러 질 수도 있습니다. 80%의 시간만을 일하는 것으로 일정을 잡아도 프로젝트가 진행되면 부정확인 일정 예측으로 인해서 초과근무는 자주 일어납니다. 그래도 합리적인 일정으로 산정되었기에 프로젝트 일정을 지킬 가능성이 훨씬 높습니다.

이러한 일정산정을 너무 넉넉한 일정으로 비난하는 경영자나 관리자가 있을 수 있습니다.

하지만 무리하게 촉박하거나 낙관적인 일정으로 일정을 지키지 못하거나 개발자를 너무 혹사하는 것보다는 합리적인 일정이 더 낫습니다.

프로젝트팀에서는 믿을 수 있는 일정을 제시하고 지키는 것이 계획적인 비즈니스를 할 수 있게 하는 원동력입니다.

이렇게 프로젝트팀이 제시한 일정이 신뢰를 받기 위해서는 합리적인 근거 제시와 투명한 프로젝트 진행이 꼭 필요합니다. 

(아래 그림은 프로젝트 초기에 일정 산정이 얼마나 어려운지를 보여주는 그래프입니다. 

프로젝트 초기의 일정은 -50% ~ +200%까지의 오차를 보인다는 의미입니다.

그리고 정확한 일정은 끝나봐야 안다는 거죠.)

소프트웨어 회사가 기본적으로 갖춰야 할 것

소프트웨어 회사가 처음에 작은 규모에서 시작할 때는 제품도 빨리 만들어 내고, 품질도 좋으며 생산성이 높습니다. 눈빛만 봐도 서로 무슨 생각을 하고 있는지 알고 생산성이 대단히 높습니다.

이런 과정을 거쳐서 회사가 점점 커져나갈 때 그 규모에 알맞은 준비를 하지 않으면 심각한 문제를 겪게 됩니다. 그럼 소프트웨어 회사가 기본적으로 갖춰야 할 것은 무엇일까요?

바로 조직, 프로세스, 기반시스템 그리고 사람과 개발문화입니다.

회사가 작을 때는 달랑 사람만 가지고 시작을 하곤 합니다.

이 때는 사람이 모든 Risk를 다 감당해야 하지만 작은 조직에서는 큰 문제가 되지 않습니다.

커뮤니케이션이 원활하고 모든 이슈들이 핸들링하기에 충분히 작기 때문입니다.

하지만 회사가 커지기 시작하면 상황은 달라집니다.

커뮤니케이션이 어려워지고, 이슈는 점점 늘어나며 조직이 점점 생산성이 떨어지게 됩니다. 

그래서 회사는 조직, 프로세스, 기반시스템을 적절하게 갖춰나가야 하며 개발문화를 정착시키기 위한 노력을 해야 합니다. 그래서 개별 사람에 대한 의존도를 낮춰야 회사는 Risk가 줄어 들며 각 개발자나 직원들은 좀더 전문적이고 자신의 일에 집중하여 Performance를 더 낼 수 있게 됩니다. 

수십, 수백명의 개발자를 보유한 조직에서 특정 개발자에 의존도가 너무 높다면 큰 문제가 아닐 수 없습니다.

사실 이러한 것들은 아주 소수일 때부터 준비가 되는 것이 더 바람직합니다. 그리고 회사의 규모에 알맞게 적절한 시점에 변모를 해야 합니다.

모자라는 것도 문제지만 과도한 것도 문제가 됩니다. 무리하게 복잡한 프로세스를 강요한다던지, 필요없는 조직으로 세분화가 된다던지 하면 차라리 없는 것만 못할 경우도 있습니다.

균형을 맞춰가면서 적절히 회사의 성장과 같이 회사의 내부 모습을 바꿔가는 것이 좋습니다.

모든 것은 때가 있듯이 그 시기를 놓치면 어려워집니다. 항상 준비를 해뒀다가 적절한 시점을 놓치지 않는 것도 매우 중요합니다. 실기는 실패보다 못한 경우가 많습니다.

구체적인 내용들은 계속 포트팅을 해나가도록 하겠습니다.

다 만들었어요. 이제 테스트만 하면 되요.

소프트웨어를 개발하는 회사에서는 자주 듣는 말입니다.

그런데, 이 테스트가 언제 끝날지 모르는 경우가 많습니다.

소프트웨어 개발 컨설팅을 하면서 정말 놀란 것 중의 하나가 대부분의 회사가 릴리즈 시 "알파", "베타", "RC", "GA", "FCS"와 같은 단계를 거치지 않는 다는 것이었습니다. 

대부분이 알파수준의 소프트웨어를 만들어서 만족스러울 때까지 테스트와 수정을 동시에 병행한다는 것이었습니다. 이는 큰 회사나 작은 회사나 별 차이가 없었습니다. 개발을 단계적으로 진행하지 않는 회사는 업무와 일정에 대한 정교한 구분 없이 일을 진행하다가 적당한 시점에서 한번의 테스트를 통해 제품을 완성하려고 합니다.

이를 빅뱅(Big bang) 테스트라 하는데 이 방법이 운 좋게 개발 기간을 단축시켜 줄지도 모른다는 기대감으로 일을 중구난방으로 진행하는 것입니다. 하지만 이는 전혀 근거가 없는 생각이며, 테스트를 한번에 끝낸다고 프로젝트가 더 빨리 끝나지는 않습니다. 이 방법은 테스트 기간 내내 혼란에 휩싸이게 만들고, 테스트가 언제 끝날지 도저히 예측할 수 없으며, 일정 기간 내에 품질이 얼마나 향상될 수 있을지 추측조차 하기 어렵습니다. 심지어 통합조차 잘 되지 않기 때문에 내포되어 있는 버그가 얼마나 되는지도 파악하기 어렵습니다. 결국 프로젝트 일정이 가시권에서 점점 멀어지게 됩니다. 운이 좋으면 밤을 새면서 일정대로 프로젝트를 마칠 것이고, 그렇지 않으면 프로젝트가 실패하게 됩니다. 

소프트웨어 프로젝트는 개발 단계 별로 관리하는 것이 좋습니다. 단계 별로 진행을 하면 각 단계가 명확해지기 때문에 프로젝트 진행 상황이 눈에 들어오고, 혼란으로 인한 재작업이 줄어 들며, 프로젝트 일정을 단축시키고, 비용을 절약해 줍니다.

특히, 높은 품질의 제품을 출시하기 위해서는 제품 및 프로젝트의 성격에 알맞게 단계 별 릴리즈를 하는 것이 좋습니다. 릴리즈는 알파, 베타, RC(Release Candidate)단계로 나뉘고 각각의 릴리즈 일정은 미리 계획하여 정해 둬야 합니다.

각 단계에는 다음과 같은 의미가 있습니다.

• 프리알파(Pre-alpha): 알파 이전에 만들어내는 빌드들입니다. 개발 버전(Engineering version)이라고 하기도 합니다. 일일빌드(Daily Build)의 결과물도 프리알파에 해당합니다. 아직 기능이 모두 다 구현이 되어 있지 않습니다.
• 알파(Alpha): 기능이 모두 구현되었으나, 버그는 꽤 많은 상태, 설치도 안되어서 기능을 확인해 볼 수도 없는 등의 버그는 없어서 모든 기능을 테스트 해 볼 수는 있습니다. 일부 작동이 안 되는 기능이 있습니다. 일반적으로 알파버전부터 테스트팀의 공식적인 테스트가 시작됩니다. 이를 알파테스트라고 부릅니다.
• 베타(Beta): 중요한 버그는 거의 수정이 되어서 작은 버그들만 남아 있습니다. 베타 버전은 종종 사용자 평가(Evaluation) 및 외부 테스트(Field Test)를 위해서 외부에 배포되기도 합니다. 이런 목적으로 배포되는 버전을 베타 릴리즈라고 부르며 베타 버전을 사용해 보는 사용자를 베타 테스터라고 부릅니다. 베타버전 이전에 프리베타(Pre-beta)를 만드는 경우도 있습니다
• RC(Release Candidate): 출시를 위해서 만들어진 버전입니다. FCS(First Customer Shipment), 감마(Gamma) 또는 델타(Delta)라고 부르기도 합니다.
• GA(General availability): RTM(Release to Manufacturing)이라고 부르기도 합니다. RC 중에서 테스트를 통과하여 출시 할 수 있는 버전입니다. 일반적인 경우 마지막 RC와 동일합니다. 

이런 식으로 테스트팀에 전달하는 버전이 어느 수준인지 알려주어야 합니다. 그렇지 않으면 알파수준의 버전을 가지고 곧 고객에게 전달할 수 있을 것 같은 착각에 빠지기도 합니다.

모든 소프트웨어를 개발할 때마다 이 같은 단계를 전부 다 거쳐야 하는 것은 아닙니다. 제품의 규모와 난이도, 성격에 따라서 단계를 서로 다르게 정해야 합니다. 대규모 제품이거나 복잡한 팩키지 제품은 이 단계들을 거치는 것이 일반적입니다. 이런 제품을 한번에 높은 품질로 만들어 내기는 어렵기 때문입니다.

하지만 소규모 제품이거나, 고객의 수가 아주 적거나, 업그레이드 프로젝트라서 복잡도가 낮을 경우라면 처음부터 원하는 품질 수준에 근접하게 제품을 만들어 낼 수 있습니다. 이런 경우라면 테스트 단계를 간략하게 해서 진행할 수 있습니다.

소프트웨어 공학이 왜 필요하지? 복잡하기만 한데...

소프트웨어 공학 블로그를 운영하고 있으면서도 전면에는 소프트웨어 공학이라는 말을 사용하고 있지 않습니다. 그 이유는 소프트웨어 공학은 막연하고 왠지 모르게 문서도 많이 만들어야 할 거 같고, 절차도 엄격히 따라야 할 것 같아서 부담스러운 느낌을 줄 수 있기 때문입니다.

이것이 다 소프트웨어 공학에 대한 오해에서 비롯된 것 같습니다. 이미 유행이 한번 쓸고 지나간 CMMI나 외국의 유명한 방법론들을 도입했다가 실패한 경험과 소문들 때문일 겁니다. 

 

Naver 백과사전에서 소프트웨어 공학을 찾아봤습니다.

다음과 같이 설명되어 있더군요.

요약 컴퓨터 소프트웨어의 계획·개발·검사·보수·관리 등을 위한 기술과 그것을 연구하는 분야이다. 소프트웨어의 규모가 커지고 복잡해짐에 따라 공학적인 접근으로 구조화 프로그래밍을 도입한 것이다 본문컴퓨터 시스템의 가격에서 소프트웨어가 차지하는 비율은, 컴퓨터가 생겨난 직후인 1955년경에는 20% 미만이었지만, 그 후에 급격히 높아져 80년대 후반에는 80~90%에 이르렀다. 이것은 요구되는 소프트웨어의 규모가 커짐에 따라 복잡해진 데 기인한다. 또, 요구되는 소프트웨어가 점차 복잡해진 반면, 그것에 대처할 수 있는 소프트웨어 기술(개발기술 및 관리기술)이 뒤따르지 못하기 때문이다. 그 결과, 소프트웨어는 항상 납기(納期)에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성(透明性)이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 ‘소프트웨어 위기(危機)’라고 불리는 징후가 나타나기 시작했다. 그 원인으로서, 모든 공학 분야에서 공통된 기본적인 설계절차를 밟지 않고 있다는 지적이 일기 시작하고, 소프트웨어의 개발에 스트럭처드 프로그래밍(structured programming:구조화 프로그래밍)과 같은 공학적 어프로치(approach)가 도입되기에 이르렀다. 소프트웨어에 소요되는 비용을, 계획에서 보수에 이르는 각 단계가 차지하는 비율로 보면, 요구하는 정의(定義) 및 방법의 기술(記述) 단계에 약 10%, 설계단계에 약 10%, 프로그래밍단계에 약 10%, 테스트 및 디버그 단계에 약 20%, 그리고 보수에 소요되는 비용이 약 50%를 차지한다. 검출되는 에러로는, 설계단계 및 그 이전의 것이 약 60%나 된다. 종래까지는 프로그래밍 단계가 강조되었으나, 소프트웨어의 ‘라이프사이클’을 인식하고 사태를 개선할 필요가 있다. 그러기 위해서는 과학적인 지식을 축적하고, 이를 실제적으로 응용해야 하는데, 이것들을 다루는 분야가 곧 소프트웨어 공학이다.

상당히 복잡하죠. 매우 잘 쓰여진 글이지만 한번에 딱 뭐다라고 이해하기 어려운 글입니다.

소프트웨어 공학이 무엇인지 한마디로 정의하면 다음과 같습니다.

 

"소프트웨어를 최소 비용으로 최소 시간에 개발하는 방법"

 

소프트웨어 공학의 목적 자체가 이거니까 이를 증명할 필요는 없습니다. 

방법론이나 소프트웨어 공학의 일부를 적용했더니, 시간도 더 많이 걸리고 개발자들이 더 힘들고 효율적이지 못하면 뭔가 잘못된 겁니다. 단순한 Learning curve가 아니라면 다시 생각해봐야 합니다. 어딘가 잘못된 부분이 있을 겁니다. 주변에 전문가가 있으면 의논하는것이 좋습니다.

위 정의에 대해서는 지금으로서는 믿어주기를 바랄 수 밖에 없습니다. 위의 말은 간단해도 소프트웨어 개발현장에서는 수많은 충돌이 일어납니다. 문서를 만드는 것이 더 오래걸린다고 하기도 하고, 프로세스는 거추장스럽다고 하고, 개발자와 직접 얘기를 하는 것이 더 빠르다고 합니다. 이 정도는 간단한 이슈입니다. 훨씬 복잡한 상황이 많기 때문에 일단은 믿고 시작하는 수밖에 없습니다.

위 백과사전의 설명을 보면 80년대 말에 미국에서는 다음과 같은 일들이 일어났다고 합니다.

소프트웨어는 항상 납기(納期)에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성(透明性)이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 ‘소프트웨어 위기(危機)’라고 불리는 징후가 나타나기 시작했다.

 

내 기억으로는 우리나라 80년대 후반은 소프트웨어 태동기였기 때문에 우리와는 거리가 먼 얘기죠.

오히려 위 문장이 지금의 소프트웨어 환경 및 현상과 많이 비슷합니다.

미국 및 소프트웨어 선진국들은 이를 해결하기 위해서 10~20년을 노력했습니다. 그래서 나온 것이 소프트웨어 공학인데, 우리도 똑같이 10~20년을 낭비할 필요는 없다고 봅니다. 모두들 노력만하면 그러한 시행착오 없이 몇 년 안에 우리도 소프트웨어 공학을 개발 현장에 자리잡도록 할 수 있습니다.

 

소프트웨어 엔지니어들… 고집 셉니다.

많은 개발자들이 자신들이 하고 있는 방법이 최선인줄 알고 있습니다. 하지만 이미 전세계의 선배들이 수십년 전부터 이미 고민했던 문제를 또 되풀이하고 있는 경우가 대부분입니다.

특별히 배운 것 없이 선배들에게 좀 배워서 하던 방식대로 개발을 하고 있다면 거의 나름대로의 개발방식으로 개발을 하고 있을 겁니다. (제가 컨설팅을 하면서 실제로 느낀 겁니다.)

"우리는 다르다"라고 하시는 분들도 매우 많습니다. "우리는 다르기 때문에 일반적인 방법을 적용할 수 없다"라고 말씀을 하십니다. 

99%의 경우 다르지 않습니다. 다르지 않으니 다행이지요. 배우고 따라할 것이 있으니까요. 

우리는 세계 소프트웨어 역사에 비해서 1/3밖에 안되는 역사를 가지고 있다는 것을 명심해야 합니다. 한마디로 배울 것이 많다는 거죠. 자신의 방식을 고집하고 있다면 마음을 열고 넓게 봐야 합니다.

소프트웨어 공학은 학교에서 배울 수 없다고 되어 있습니다. 물론 대학에 과목이 있기는 하죠. 하지만 용어들을 익히는 것이지 실제로 그것이 무엇을 뜻하는지는 대부분의 학생들은 이해를 못한다는 겁니다. 즉, 현장에서 배우는 것이 소프트웨어 공학입니다. 대학에서 배운 학생들은 더 빨리 배우기는 하겠죠. 따라서 언제라도 시작해도 늦지는 않습니다. 그동안 쌓은 경험이 도움이 될 수 있습니다. (방해가 되는 경우도 많이 봤습니다.) 그리고 쉽게 배울 수 있는 것도 아니고 그 범위도 매우 큽니다. 시간도 많이 걸리죠. 또, 그 과정에서 별 쓸데 없는 것에 매달리면서 시간 낭비하는 경우도 정말 많습니다.

이럴때 유경험자나 전문가가 주위에 있는 것이 정말 좋습니다. 머리에 지식을 넣어주기는 어려워도 서로 의견을 주고 받고 있다면 쓸모없은 것 공부하느라고 시간을 허비하는 것은 줄일 수 있습니다. 

 

앞으로 계속 연재해 나갈 소프트웨어 공학의 구체적인 내용들이 소프트웨어 공학을 이해하고 실제로 개발에 접목하는데 도움이 되기를 기대합니다. 

 

소프트웨어 개발 시의 애로점, 개발자 진로의 고민, 소프트웨어 공학에서 알고 싶은 내용은 언제든지 메일이나 방명록으로 의견을 주시면 정성껏 답을 드리고 같이 의논할 수 있도록 하겠습니다.

 

 (아래는 소프트웨어 Requirements에 관련된 재미있는 그림입니다. Document 부분의 맨땅이 인상적이네요.)

티스토리 독립도메인으로 이동 전과정 정리

블로그를 시작한지는 얼마 안되었지만, "독립도메인을 사용해야 하는데"라는 생각만 가지고 있다가 오늘 과감하게 이동을 했습니다. 

그러고 나니 할일이 꽤 많더군요. 그래서 독립도메인 설정과정을 한번 주욱 정리를 해봤습니다.

아직 새싹 블로그라서 이동하는데는 큰 문제가 없었지만, 혹시 많은 독자 때문에 이동이 어려운 블로거가 있다면 참조하세요. 

1. 도메인 신청(구매)

도메인은 알아서들 구매하시면 되겠죠. ^^ 

도메인 설정에 대해서는 다 아시겠지만, 일반 독자를 위해서 조금 설명을 해봅니다.

도메인이라는 것은 소유의 개념이 아니고 사용권을 획득하는 것으로써 매년 사용료를 지불해야 합니다.

제가 구매한 도메인은 allofsoftware.net입니다. 16,500원/년(VAT포함)을 주고 KT호스팅에서 구매를 했습니다.

도메인을 등록하면 위와 같이 네임서버를 변경할 수 있도록 되어 있습니다.

네임서버를 직접 운영하고 있지 않은 경우라면 벤더에서 제공하는 네임서버를 그냥 사용하면 되겠습니다.

2. 호스트 등록

도메인을 구매했으면 도메인과 블로그 주소를 연결해줘야 합니다.

위와 같이 nslookup 명령을 이용해서 내 블로그의 IP주소를 찾아야 합니다.

IP주소가 211.234.119.250이라는 것을 알 수 있습니다.

IP주소를 알아냈으면 해당 IP주소를 이용해서 네임 서버에 Host를 등록해야 합니다.

allofsoftware.net과 www.allofsoftware.net 모두를 211.234.119.250으로 등록해 달라고 네임서버 관리자에게 요청을 하면 됩니다. 등록하는 타입은 A레코드인데, 그냥 웹사이트라고 하면 알아서 등록해줍니다.

보통 네임서버들은 도메인정보를 싱크하는데 안전하게 하루 정도는 생각해야 한다고 하는데, 도메인을 새로 추가한 경우에는 기존 IP주소의 변경이 아니기 때문에 상당히 빨리 사용이 가능하기는 합니다.

하지만 저는 안전하게 하루를 기다렸습니다.

3. 티스로리 설정 변경

하루가 지났습니다.

도메인을 변경하려고 나름대로 전략을 세웠습니다.

도메인을 변경하고 나면 가장 걱정이 되는 것이 기존에 주소를 알고 찾아오는 독자일겁니다. 

 

이 블로그는 위와 같이 직접 입력을 해서 들어오는 독자가 23%이므로 블로그 도메인을 당분간 병행하기로 했습니다. 그 기간은 통계를 봐가면서 softwaredev.tistory.com으로 들어오는 독자가 거의 없어질 때까지 하기로 했습니다.

softwaredev.tistory.com -> softwaredev.tistory.com, allofsoftware.net 병행 -> allofsoftware.net 단독 운영  

 

위와 같이 설정을 하면 티스토리의 모든 메커니즘이 2차주소인 독립도메인으로 동작하면서도 1차 주소인 옛날 주소로도 접근이 되더군요.  나중에 1차 주소를 폐쇄할 때는 softwaredev라고 입력한 1차 주소 도메인이름을 지워주면 될 것 같습니다.

블로그 타이틀도 바꿨습니다. 기존의 독자들에게 도메인이 바뀌었음을 어필하기 위해서 새로운 블로그주소도 추가했습니다.

4. RSS Feed 변경

기존에 Feedburner를 이용하고 있었기 때문에 블로그 도메인이 바뀜으로써 RSS Feed 주소가 바뀌는 일은 없었습니다. 하지만 블로그 타이틀 자체가 바뀌었기 때문에 Feedburner의 주소도 바뀌게 되었습니다.

그래서 도메인과 마찬가지로 당분간 두 Feed주소를 같이 운영하다가 서서히 새 Feed주소로 넘어가는 방식을 택했습니다. 

 

Feed Count는 일단 두개를 다 달아 놨고, 어떻게 옮겨가는지 안가는지 확인을 해볼 생각입니다. 그리고 나서 나중에 결정을 하면 될 것 같습니다.

블로그를 시작한지 얼마 안되어서 몇 안되는 구독자지만 소중한 구독자이기에 Old Feed가 0이 될 때까지는 계속 열어 놀 생각입니다.

5. 다음블로그 뉴스

다음블로그 뉴스는 아무리 찾아봐도 블로그 주소와 RSS주소를 바꾸는 기능이 안보이더군요.

그래서 기존 것은 놔두고 새로 등록을 했습니다.

기존 것을 수정하려면 탈퇴하고 다시 가입해야 하는데 그렇게 되면 기존의 정보가 다 사라질 것 같아서, 완전히 새로 가입을 했습니다.

Daum ID 추가부터 새로 했습니다.

그리고 블로뉴스에 가입을 하고 테스트 삼아서 글을 하나 올려 봤더니, 새로운 블로그 뉴스에 등록이 되더군요.

이렇게 해서 다음블로그 뉴스 설정도 완료.

문제가 있을 경우, 티스토리 플러그인 관리에서 다음블로그뉴스 플러그인을 설정해제를 한번하고 다시 설정하면 됩니다.

6. Meta블로그 수정

티스토리 자체적으로 수많은 메타 블로그와 연동이 되므로 글을 연동하는데는 별로 문제가 없어 보입니다. 하지만 내가 수동으로 등록한 몇몇 메타블로그에 들어가서 RSS주소를 변경해줬습니다.

대부분 별 문제가 없이 수정이 되더군요.

7. 검색사이트에 등록

그리고 할일이 각종 포탈과 검색사이트에 등록하는 것입니다.

 

블로그를 조사한 결과 구글에서 가장 많이 검색이 되었고, 네이버, 다음, 야후 순이더군요.

다음은 별도로 등록할 필요가 없기 때문에 아래 5군데에 등록을 했습니다.

• Google (Dashboard이용)
• 네이버에 블로그로 등록
• 네이버에 홈페이지로 등록
• 야후에 블로그 등록
• 엠파스에 등록

이렇게 해서 완료를 했습니다. 아직 블로그에 주렁주렁 달린 것들이 없어서 생각보다는 쉽게 독립도메인으로 옮긴 것은 같은데, 문제가 없는지 며칠 지켜봐야 할 것 같습니다.