레이블이 기반시스템/소스코드관리인 게시물을 표시합니다. 모든 게시물 표시
레이블이 기반시스템/소스코드관리인 게시물을 표시합니다. 모든 게시물 표시

2015년 4월 13일 월요일

빈 줄도 지워서는 안된다.

SVN 쓸까? Git 쓸까주제로 얘기를 하면 논쟁이 심하다하지만 이보다  중요한 것은 SVN이나Git 상관없이 어떻게 하면 여러 개발자들과 협업이  되도록 코딩을 하느냐다.

많은 개발자들은 혼자서 또는 소수의 인원과 개발을 한다또는 여러 명이 개발을 하더라도 자신의 소스코드가  정해져 있어서 혼자 개발하는 경우가 많다이러다 보니 협업을 위한 개발에는 별로 관심이 없다하지만 협업은 혼자서  때도 필요한 것이고 여러 명이 개발할 때는 더욱더 필요하다방법을 모르거나 문제를 피해 다니면 개발 효율이 떨어지고 한계를 넘지 못한다.

혼자서 개발을 하더라도 수많은 브랜치가 발생할  있고 한두 명끼리는 그럭저럭 개발을 하더라도개발팀이 조금만 커져서 뒤죽박죽이 되곤 한다.

그럼 어떻게 코딩을 하는 것이 좋을까?

첫째 줄도 고쳐서는  된다.

내가 고치고 있는 모든 소스코드는 다른 개발자들도 지금 고치고 있다고 생각해야 한다설사 혼자서고치는 소스코드라고 하더라도 습관이 된다협업을 하고 있다는 마인드는 꾸준히 유지를 해야 한다. 

  뿐만 아니다. Indentation 맞지 않는다고 고치는 것도 좋지 않다괜히 연산자 사이에 보기 좋으라고 빈칸을 추가하는 것도 나쁘다무조건 처음에 잘해야 하고 나중에는 그냥 놔두는 것이 낫다.

둘째파일 이름을 바꾸지 말아야 한다.

처음에 대충 파일을 만들다 보면 파일이름이 마음에  드는 경우가 있다그렇다고 파일을 이름 바꾸면 수많은 사람들에게 영향을 준다. Git에서는 파일을 이름 변경을 추적해주는 기능이 있지만 혼란을피할 길을 없다처음에  정해야 한다. 

셋째함수 이름과 정의를 바꾸지 않아야 한다.

대충 만들어 놓고 자꾸 바꾸는 것은 협업 습관이 없기 때문이다그리고 대충 만들고 나중에 수정하는것은 비용이  많이 든다아주 작은 시스템만 경험해  개발자는 이런 방법이  빠르다고 주장할지몰라도  시스템에 개발자가 수십 명이라면 얘기가 달라진다대충하고 바꾸는 습관이 들어서는 안된다.

넷째소스코드를 재배치하지 말아야 한다.

파일의 아래쪽에 있는 함수를 위로 올리고 정리를 하면 소스코드 Merge 어려워진다처음에  생각해서 정하고 나중에는 고치지 말아야 한다여러 사람이 동시 소스코드를 정리하면 소스트리는 완전히 뒤죽박죽이 된다.

이미 문제가 발생한 경우 리팩토링이 필요하게 되고 계획을 잘 세워서 시행해야 하고 상당한 비용을 치뤄야 하는 경우도 있다. 이런 경우는 최소화하고 처음부터 제대로 하는 것이 훨씬 낫다.

 외에도 변수를 어떻게 선언하느냐는  협업을 위한 수많은 코딩 노하우들이 있다항상 개발은혼자 하는 것이 아니다라는 것을 염두해 두고 개발하는 자세가 필요하다.
물론 위 내용들은 개발자 본인이 처한 환경에 따라서 천차만별로 생각할 수 있다. 혼자 개발하는 사람도 있고 수백명이 개발을 해도 혼자 일하는 것처럼 개발하는 경우도 많다. 수천명이 동시에 개발하는 환경에 있는 개발자도 있다. 
필자는 원칙과 원리에 대해서 얘기를 하는 것이니 원리에 대해서 이해를 해보는 노력을 해보자. 일하는 환경은 언제든지 바뀔 수 있지만 습관은 쉽게 바뀌지 않는다. 좋은 습관을 만들어가는 것은 본인의 몫이다.

2013년 9월 4일 수요일

소스코드가 없어졌다.

필자는 소스코드가 없어진 Software 회사를 여러번 보았다. 물론 회사의 전체 소스코드가 없어진 것은 아니다. 일부 소스코드가 없어져서 낭패를 보는 경우는 매우 흔하다. 소스코드는 어떻게 없어지게 될까? 물론 아래 모든 경우는 전사적인 소스코드 관리 및 백업을 받지 않은 경우에서 발생한다.

1. 하드디스크가 망가졌다.

하드디스크는 그렇게 믿을 만한 미디어가 아니다. 어느날 갑자기 망가져 버릴 수도 있고 복구가 안되는 경우도 종종 있다. 10년간 잘 돌던 하드디스크가 PC를 옮겼더니 갑자기 먹통이 되는 경우도 있다. 이런 경우 백업이 없다면 소스코드를 잃어버리는 것이다. 각 개발자의 PC에 사본이라도 있다면 History는 없어져도 최신 소스코드는 건질 수 있지만 그렇지 않아서 소스코드르 잃어버리는 경우를 종종 보았다.

2. 외주를 주고 소스코드를 받지 않은 경우

이 경우도 의외로 많다. 개념이 없이 소스코드를 받지 않은 경우도 있고, 계약상 소스코드는 제공하지 않는 경우도 있다. 두경우 문제가 되기는 마찬가지다. 개발툴을 업그레이드하려면 소스코드가 필요한데 그럴때 외주사가 망해 버리면 영영 발목이 잡혀버린다. 이럴 때는 소프트웨어진흥원에 소스코드 에스크로를 하면 회사가 망했을 때 소스코드를 가져올 수 있다. 외주사가 망해서 소스코드가 없어지는 경우은 의외로 흔하다.

3. 개발자가 소스코드를 관리하다가 퇴사를 한 경우

회사의 중요 제품이라면 소스코드를 잃어버리는 일이 흔하지 않지만 오래된 제품이나 툴등의 소스코드라면 개발자가 대충 소스코드를 보관하고 있다가 퇴사를 해버려서 언제 어떻게 잃어버렸는지도 모르게 소스코드가 없어지는 일이 발생한다. 수년 후 나중에 소스코드가 필요할 때 없어졌다는 사실을 알게 된다.

4. 회사의 소스코드관리시스템(SCM)을 백업받지 않은 경우

소스코드관리시스템을 도입하고 백업을 받지 않는 회사는 엄청나게 많다. 놀랄 일이다. Git등의 분산SCM을 쓴다면 어딘가에 백업이 있지만 SVN을 쓰다가 서버가 날아가면 간신히 부분적인 최신 소스코드만 건지게 된다. History가 사라진 최신소스코드는 그 가치가 몇분의 일로 줄어든다. 물론 많은 회사가 소스코드관리를 제대로 하지 않아서 History가 거의 가치없는 경우가 많다. 하지만 소스코드관리를 제대로 한 경우라면 History는 꼭 필요하다. SCM의 백업은 선택이 아닌 필수다.

이를 방지하는 방법은 전사적으로 소스코드관리를 철저히 하는 것이다. 하나의 통일된 소스코드관리시스템을 사용해야 한다. 회사 몰래 개발자가 숨겨 놓은 소스코드가 존재하면 안된다. 아무리 그렇게 관리를 해도 개발자들이 개인적으로 가지고 있는 소스코드가 존재할 수 있다. 스크립트라고 등록하지 않고, Install shield 프로젝트는 등록하지 않기도 한다. 이런 문제가 발생하는 또다른 이유는 개발자가 개발자PC에서 빌드를 하기 때문이다. 빌드를 빌드 전용서버에서 빌드 담당자가 하게 될 경우 숨어 있는 소스코드를 모두 끄집어 낼 수 있다. 빌드 전용서버는 오로진 SCM에서 소스코드를 가져다가 빌드를 하기 때문에 개발자PC에 숨겨진 소스코드가 있다면 빌드가 되지 않게 된다. 개발자를 못 믿어서가 아니고 빌드는 개발자PC에서 하면 안되는 것이다.

그리고 백업을 제대로 받아야 한다. 백업은 제3의 장소에 보관해서 회사가 완전히 불타 없어져도 소스코드를 바로 복구할 수 있어야 한다는 생각으로 백업을 해야 한다.

이런 환경을 구축하는 것은 비용이 더 많이 드는 일이 아니다. 제대로 관리를 하지 않고 소스코드를 엉망으로 관리하면서 오는 비효율과 비용 및 손실과 비교하면 훨씬 이익이다.

2011년 10월 25일 화요일

SVN보다 Git가 더 좋을까?

요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.

  1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
  2. Github를 써야 한다면 Git를 써라.
  3. 그외에는 모두 SVN을 써라.
기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 
CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 
일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.
  • Folder공유 타입 - RCS, SCCS
  • Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
  • 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs
폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.
또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.
  • Offline에서 자주 개발을 해야 할 때
  • Git 기반의 Open source를 이용한 개발을 해야 할 때
  • Git 기반의 Open source 프로젝트에 참여할 때
  • Github을 써야 할 때
이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.
SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다. 

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.
SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

2020년 7월에 추가한 내용


이 글을 작성한지 9년이 지났다. 그래서 주변 환경이 많이 바뀐만큼 결정의 기준도 바뀌었다. 9년 전인 2011년에는 git를 쉽게 지원하는 client도 시원치 않았다. 하지만 지금까지 많은 기술의 변화가 있었다. 그래서 SVN을 쓸지 Git을 쓸지 결론을 말하지만 다음과 같다.

  • 회사에서 이미 SVN을 쓰고 있어서 Git으로 마이그레이션이 어렵다면 SVN을 써라.
  • 발주사에서 SVN을 써야 한다고 하면 SVN을 써라.
  • 그외에는 모두 Git을 써라.
    • 회사를 새로 시작한다면 Git을 써라.
    • SVN을 쓰고 있어도 Git으로 마이그레이션을 하고 싶으면 해라.
    • SVN에서 Git으로 바뀐다면 Repository 전략을 바꾸어야 한다.

추가 의견으로 Git을 쓴다면 Cloud 서비스를 이용하는 것을 권장한다. 서버를 직접 관리하는 것보다 시간, 비용면에서 효율적이다. Github, GitLab, Bitbucket, Azure Repos 등이 있다.

같은 조건이라면 Git을 사용하기를 권장하지만, SVN을 사용한다고 큰 문제가 있는 것이 아니다. SVN을 잘 쓰고 있다면 계속 사용해도 문제가 없고, 시간과 비용을 들여서 Git으로 옮겨가고 싶다면, 시도해볼만 하다.



    2011년 10월 9일 일요일

    이 소스는 건들지마

    소프트웨어를 개발하는 회사에서는 소스코드 관련해서 가끔 벌어지는 일들이다.
    혹시 해당하는 것들이 있나 확인해보면 소스코드관리시스템을 제대로 쓰고 있나 가늠해 볼 수 있다.
    • 이 소스코드는 건들지만 이번주 금요일에 릴리즈할 건데 지금 테스트 중이라서 건들면 헷갈리니까 잠시 건들지 말아줘
    • 소스코드를 수정해서 등록하는데 Conflict가 났다. 원래 수정자를 찾아 같이 모여서 소스코드를 머지했다.
    • 같은 소스코드를 서로 같이 동시에 수정하면 문제가 많으니 각 모듈마다 담당자를 따로 정해서 소스코드가 충돌하는 경우를 원천 봉쇄했다. 그래서 서로 다른 사람들의 소스코드를 잘 모른다.
    • 하나의 소스코드를 가지고 오늘은 내가 내일은 다른 사람이 수정할 수 있도록 서로 일정을 조정했다.
    • v1.0 출시 후 v1.0 유지보수와 v1.5로 업그레이드 하는 프로젝트가 동시에 진행하는데 서로 소스코드가 섞여서 소스코드 관리를 잘해야 한다.
    • 위 경우 소스코드 충돌 때문에 소스코드 브랜치를 만들어서 따로 6개월간 개발을 했는데 나중에 v1.0의 수정본을 v1.5에 합치는데 워낙 많이 바뀌어서 거의 한달이나 걸렸다. 그 한달동안에 v1.0 소스코드는 또 많이 바뀌어서 Merge하고 테스트하는데 시간이 또 많이 걸렸다. 

    위 경우에서 하나라도 해당하는 것이 있으면 문제가 있는 경우다.

    기본적으로 거의 모든 소스코드 관리시스템은 위 같은 경우들에서 아주 효과적으로 관리를 할 수 있는 모든 기능이 제공되고 있다. 하지만 또 거의 모든 소프트웨어 회사에서 활용을 못하고 있거나 흉내만 내고 있다. 

    그것은 바로 "Baseline"과 "3-way merge"이다.
    이 개념을 정확하게 알고 이와 관련하여 제공하는 소스코드관리시스템의 기능을 정확하게 알고 있다면 다음과 같은 일들이 일어난다.

    • 언제 릴리즈하는지는 상관없이 언제든지 소스코드를 수정할 수 있다. 
    • 소스코드 Conflict가 일어나도 원래 수정자가 없이도 쉽게 Merge할 수 있다.
    • 소스코드에서 여러 컴포넌트를 개발했던 원래 개발자는 있지만 서로 상대방의 컴포넌트를 수정할 수 있고 동시에 수정을 해서 충돌이 가끔 일어나지만 문제 없이 Merge가 된다.
    • 소스코드를 누가 언제 수정하는지 전혀 신경 쓰지 않고 서로 동시에 수정을 할 수 있다.
    • 유지보수 프로젝트와 업그레이드 프로젝트가 동시에 진행을 해도 Merge는 불과 몇시간이 걸리지 않고 대부분 자동으로 해결된다.

    Subversion을 포함한 대부분의 소스코드관리시스템은 흔히 알고 있고 사용하는 기능보다 훨씬 막강한 기능을 가지고 있다. 수천명이 동시에 수십만개의 소스코드를 동시에 마구 고치고 여러 프로젝트가 동시에 진행되도 Merge에 따르는 고통없이 효율적으로 소스코드를 관리할 수 있다.

    아직 그 기능을 충분히 활용하고 있지 않다면 좀더 소스코드관리시스템에 대해서 공부를 해 볼 필요가 있다. 물론 내가 쓴 "소프트웨어개발의 모든 것"이라는 책에는 그 원리와 방법이 꽤 자세히 나와 있으니 참고가 될 수 있을 것이다.

    2011년 2월 18일 금요일

    소스코드 Conflict

    소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

    소스코드관리시스템에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge를 해준다.
    하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 사용자가 직접 Merge를 해야 하고 이때 이용하는 것이 Merge Tool이다.

    많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코드관리시스템를 잘못 사용하고 있는 예가 되겠다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

    Merge Tool은 크게 2-way와 3-way방식으로 구분이 되며 3-way Merge는 블로그에 많은 글들이 있으니 참조할 수 있다.

    3-way Merge 툴을 이용하면 쉽게 Merge를 할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 더 좋다.

    같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게 또는 일어나지 않게 소스코드를 작성할 수 있다.

    근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

    변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

    소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

    그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

    현재 혼자서 개발하고 있는 것이 아닌데 Conflict에 대해서 전혀 걱정을 하고 있지 않다면 오히려 문제가 될 수 있는 상황이다. (사실은 혼자 개발을 해서 Conflict가 일어나고 여러명이 동시에 병행 개발할 때와 똑같다. 왜 그런지 이해하시는 분은 댓글을 달아주면 어떨까요? ^^ )

    Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.

    2010년 12월 3일 금요일

    소스코드관리시스템 사용도 2차 조사 결과

    2009년 2월에 이와 동일한 조사를 한 적이 있었습니다.
    2009/02/22 - [기반시스템/소스코드관리] - 소스코드 관리 방법 조사 결과
    그때도 약 20일간 조사를 했었고, 이번에도 마찬가지로 20일간 조사를 했습니다. 
    2009년에는 109명이 참여를 했는데 이번에는 370명이 넘는 인원이 참여를 해서 더 정확한 결과가 나왔을 것으로 기대합니다.


    이번 설문의 핵심은 소스코드관리시스템을 사용하는지? 사용하지 않는지? 또, 사용한다면 어떤 시스템을 사용하고 있는지를 알아내는 것이었습니다.

    2009년초와 비교를 해보면 꽤 많은 변화가 있었음을 알 수 있습니다.
    가장 큰 변화를 요약하면 다음과 같습니다.
    • 소스코드관리시스템 사용률의 향상
    • CVS, VSS의 몰락
    • Git의 약진
    • Subversion(SVN)의 꾸준한 증가
    그럼 조사 결과를 살펴 보도록 하겠습니다.

    소스코드관리시스템을 사용하고 있는 그룹에서만 통계를 내보면 여전히 Subversion이 압도적인 1위를 차지하고 있고, CVS와 VSS의 사용률이 많이 떨어지면서 Git가 크게 치고 나온 것을 알 수 있습니다. Mercurial의 가세까지 보면 분산소스코드관리시스템에 대한 관심이 많이 높아졌음을 알 수 있습니다.
    또한 더 다양한 소스코드관리시스템의 사용을 시도해보고 있는 것이 눈에 띕니다.



    소스코드관리시스템을 사용하는 비율도 많이 높아졌습니다. 그동안 책이나 블로그를 통해서 소스코드관리시스템을 사용하지 않고 소프트웨어를 개발하는 것은 기적에 가깝다고 하였는데, 이는 긍정적인 신호로 생각됩니다.
    물론 소스코드관리시스템을 사용하고 있는 83%에서도 제대로 사용하고 있는 비율은 극히 낮습니다. 그래도 사용하기 시작한 것만 해도 큰 의미라고 생각됩니다.



    많은 발전이 있었음에도 여전히 소스코드관리시스템을 사용하지 않는 개발자나 회사가 많이 있고 그 속에서의 비율은 큰 차이가 없어 보입니다.
    소스코드관리시스템을 100%의 개발자들이 사용하고, 또한 제대로 사용할 수 있는 날까지 계속 노력을 합시다. 



    저는 수많은 회사에서 소프트웨어 공학/경영 컨설팅을 진행하면서 소스코드관리시스템이 개발 문화를 긍정적으로 상당히 많이 바꾸는 것을 보아 왔습니다. 소스코드관리시스템 없이 소프트웨어를 개발한다는 것은 남들은 총들고 전쟁할 때 돌멩이 들고 싸우겠다는 것과 같습니다. 일단 무기가 있어야 싸움을 시작할 수 있을 것 아닙니까?
    그리고 나서야 기술이나 전략이 의미가 있어집니다. 돌멩이 들고 싸우면서 전략을 논할 수는 없습니다.
    물론 이와 같이 꼭 필요한 무기들은 몇가지 있습니다. 이런한 것들이 기본은 되어야 글로벌 소프트웨어 회사들과 경쟁이란 것을 생각해 볼 수 있습니다. 그렇다고 물론 경쟁이 된다는 것이 아닙니다. 이제 시작할 수 있다는 것 뿐입니다. 

    그리고 나면 진짜 개발 실력, 전략, 마케팅이 필요한 때입니다. 하지만 국내 대부분의 소프트웨어 회사들은 아직 글로벌 경쟁은 생각하지도 못할 수준인데 단순히 요소기술만 가지고 경쟁을 할 수 있다고 착각하는 경우가 많습니다.

    이번 조사 결과를 보면서 점점 긍정적인 신호들을 느낍니다. 앞으로 좀 더 깊은 내용들도 풀어 나가도 될 것 같습니다.

    조사에 협조해주신 모든 분들께 감사드립니다.