28 4월 2021

[1日 30分 인생 승리의 학습법] 훌륭한 개발자가 되는 방법

[1日 30分 인생 승리의 학습법] 훌륭한 개발자가 되는 방법

첫째, 문제에서 나 자신을 배제하지 말자⚠️

Photo by Fares Hamouche on Unsplash

둘째, 에러의 원인을 파악하자????

 

Photo by Rob Schreckhise on Unsplash

셋째, 에러 메시지를 읽어보자 ????

 

Photo on Pixabay

[출처] https://hshine1226.medium.com/%ED%9B%8C%EB%A5%AD%ED%95%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EB%90%98%EB%8A%94-%EB%B0%A9%EB%B2%95-5843a048a458

 22 total views

25 4월 2021

[1日 30分 인생승리의 학습법] 나의 Sparx Enterprise Architect(UML) 활용기 나의 Sparx Enterprise Architect(UML) 활용기

[1日 30分 인생승리의 학습법] 나의 Sparx Enterprise Architect(UML) 활용기

나의 Sparx Enterprise Architect(UML) 활용기

 

2000년 초반 한창 UML을 이용한 설계가 붐이었는데, 지금은 완전히 사그라진 것 같다.
 

UML툴도 거의 프로그램 다 만들고 나서 다이어그램 등 산출물 작성하는 용도로만 쓰이고 있는 것 같다.

예전 프로젝트 하나를 대차게 말아먹고 난 후 요구사항와 설계쪽 능력 향상에 대한 갈망이 생겼다.

소프트웨어공학의 요구사항, 비지니스프로스모델링, 설계등에 대한 공부를 관련 교육도 들어가면서 공부를 했다. 교육에 대한 소감은 좀 글쎄였다. 아마 강사들이 PMO쪽 경력이고, 너무 추상적이거나 이론적이서 실무에 어떻게 적용되지? 하는 의문이 들었다.
대형 SI업체에서 있으면서 큰 프로젝트도 했었지만, 역시 이론대로 프로젝트 관리나 설계가 되는 것 같지는 않았다.

내 맘에 드는 Best Practice를 못 찾았다. 내 방식대로 시작을 했다.
툴은 Sparx에서 나온 Enterprise Architect.
UML쪽 툴 1위는 IBM의 Rational 이지만, Sparx의 이 툴도 기능이 그에 크게 뒤지지 않는다는 평가를 받고 있다. 가격도 꽤나 싼 편이다.
난 약 30만원 정도 가격의 Professional version을 구매했다.

이 툴을 프로젝트에 실제 사용한 것은 의료용 솔루션을 개발할 때 부터였다.

그 전에 하던 방식을 보자면, 요구사항도 일일히 excel이나 word로 정리하고, 그걸 바탕으로 설계 문서를 만드는데, 그것도 역시 powerpoint 문서. 그런데 진행하면서 문서 update가 제대로 되는 경우가 없었다. 그래서 문서는 단지 고객에서 보여주는 용도로만 사용하고, 개발용으로 거의 쓸모가 없었다.

체계적인 교육없이 이 툴을 사용하는 것은 쉽지 않았다. 사용 정보는 거의 제조사 홈페이지 있는 tutorial이 거의 전부였다. tutorial 보면서 익혔다. 시중에 나와있는 UML 관련 책들도 대부분 읽어봤다.

툴, 즉 UML spec 대로 작성하다 보니 가장 좋은 점이 생각이 많이 구체적으로 정리되는 것이다. 그리고 고객사나 동료 개발자와 논의할 때도 오해가 거의 없이 전달되는 점.

UML spec에 대한 이해없이 diagram 그리는 것은 만만치 않다. 파워포인트 식대로 이 상자에서 저 상자로 선을 그리어 관련됨을 나타내고 싶은데, UML에서 그 모든 기호가 명확하게 되어 있어 대충 그릴 수가 없게 되고, 그리다 보면나의 생각이 잘못되어 이렇게 그릴 수가 없구나라는 점도 깨달을 수 있었다.

Activity들에 대한 설계를 activity diagram으로 그리고 나서 그걸 다시 state diagram 과 collaboration diagram, sequence diagram 다양한 관점으로 그리다 보니, 한 쪽 면만을 보며 설계했던 것의 오류도 설계 단계에서 쉽게 노출이 되었다.

내가 활용한 방식을 정리해본다.

1단계 : 용어사전

EA에서는 Glossary라고 한다. 프로젝트 수행에서 용어, 즉 명사는 꽤나 중요하다. 특히나 고객과 내가 같은 단어를 사용하는 데 실제 각기 다른 의미로 이해하는 경우가 많다. 그리고 많은 의미를 나타내는 데 여러가지 단어를 혼재하기도 하고..

Glossary

Glossary에 프로젝트에 사용되는 모든 용어를 정리한다. 이렇게 정의하면 이후 다른 문서에서 이 용어에 해당하는 단어에 링크가 걸리면서 정의를 바로 확인한 수 있다.

2단계 : 요구사항 정리

Requirements Model이라는 요구사항 템플릿을 기반으로 하여 작성한다.

 

requirement diagram

요구사항을 나열식으로 볼 수 있고, 요구사항간의 관계를 맺을 수 있어, 엑셀로 정리하는 방식보다도 훨씬 편했다. 이렇게 작성한 요구사항은 이 후 단계인 Logical Modeling, Physical Modeling 단계와 자동 매칭되면서 누락여부, 또는 어떻게 모델링과 구현과 이어지는지 추적할 수 있다.

3단계 UseCase diagram 작성

구현범위를 가장 큰 관점에서 그린 것이다. 구현할 범위를 System Boundary안에 usecase로 표시하고, 그 usecase을 하는 주체 또는 객체를 actor로 도출하여 그린다.

usecase diagram

이렇게 한장의 그림으로 비 IT인인 고객과 업무 범위에 대한 큰 범위 정의가 된다. 그리고 usecase의 속성 창에서 업무 프로세스를 고객이 사용하는 용어로 순서대로 작성한다.

4단계 Activity diagram

앞 3단계의 usecase 속성에 업무절차를 순서대로 기록하며 그것이 tool 자체적으로 activity diagram생성시킬 수 있다. 이렇게 생성한 기본 다이어그램을 좀 더 보강하면서 구체적으로 기술해 간다.

 

activity diagram

5단계 Data Modeling

이 전까지 데이타 모델링을 주로 ErWin을 사용했었다. 하지만 EA만으로도 DB모델링을 할 수 있고, 이렇게 하면 연속적으로 모델에 대한 추적이 가능해진다.

 

Data Modeling — class diagram

먼저 논리적 모델링을 하고, 물리적 모델링을 했다. ErWin과는 달리 논리 모델과 물리모델을 한 diagram 에서 쓸 수는 없어, 논리 모델링을 한 후 그걸 물리모델로 복사후 물리모델링을 했다.

6단계. UI 프로토타이핑

UI 프로토타이핑도 EA에서 할 수는 있으나, 별로 좋지 않았다. 그래서 UI prototyping 만은 별도의 툴을 사용해서 했다. Justinmind라는 툴을 사용하여 UI 설계하고, 동작 UX를 고객과 동료에게 보여주면서 피드백을 받으면서 UI/UX에 대한 확정을 했다.

7단계. Class Modeling

UI까지 다 되었으니, 이제부터가 본격적인 코드에 대한 설계다. 먼저 class에 대한 설계. 안드로이드 기준 activity class 위주의 class diagram이 아래와 같다. 이렇게 하여 각 class 기준 업무 분장을 하게 된다.

 

Class diagram

8단계. Interaction/collaboration/state /instance diagram

앞 단계까지 하여 코딩이 시작하나, 설계를 좀 더 구체화 필요가 있었다. 예외사항이라든가, 놓치고 있는 점이 없는지.. 구현단계에서 설계 결함을 발견하면 싹 갈아엎어야 하는 상황이 벌어지기 때문. 앞서 작성한 usecase, activity, class diagram을 다른 관점(즉, 협업관점, 상태관점, 흐름관점 등)으로 검증을 해 본다. 그리다 보면 막히는 부분이 나오게 된다. 미쳐 생각하지 못한 부분이던가, 놓치고 있던 것, 아니면 아예 엉뚱하게 생각하고 있었던 점이 이 과정에서 마구마구 나왔다. 이것들을 다시 윗 단계에서 만든 diagram들에 다시 반영하면서 모든 관점에서 다 적합할 때까지 그린다.

 

Interaction Diagram

9단계. Deploy diagram과 기술스택 검증

프로그램이 돌아가는 환경과 기술스택도 diagram을 만든다. 완료보고서에 들어가기도 하지만, 미리 동료들과 충분한 이해를 할 수 있다. 이와 함께 기술스택에 대한 프로토타입 코드를 작성하며 기술스택에 대한 검증도 한다.

 

10단계. 설계 문서 생성

나중 산출물 작성을 별도로 할 필요없이(물론, 원하는 보고서 양식에 맞게 수정 작업은 해야 하지만) 이 자체만으로 어느정도 모양을 갖춘 산출 문서를 생성할 수 있다.

 

generate document

위 같이 문서를 generate시켜면, 제법 볼 만한 형식의 문서가 만들어진다. 물론 세부 항목의 디테일을 diagram을 얼마나 구체적으로 만들었느냐에 달려있다.

 

generated pdf

이게 나의 설계 방법론

이 프로젝트 진행 당시 함께 일한 훌륭한 동료들과 이 툴을 사용하여 설계에 충분한 시간을 들여 이제까지의 나의 프로젝트 중 가장 성공적인 것이었다.

하지만, 이 방법이 Best Practice는 아닐 것이다. 하면서도 “더 좋은 방법, 더 제대로 된 방법이 있을 것 인데”하는 갈증을 느꼈다.

좀 더 잘 이 툴을 사용하고 싶고, 더 잘 UML을 그리고 싶다.
물론 툴에만 너무 몰입하면 주객이 전도되기도 한다지만, tool이란게 여러 사람들의 best practice를 패턴화해서 만든 소프트웨어인고, 그걸 일단 잘 사용하고 나서 그게 넘어설 단계가 되는 거라 생각한다.

[출처] https://sungyong.medium.com/%EB%82%98%EC%9D%98-sparx-enterprise-architect-uml-%ED%99%9C%EC%9A%A9%EA%B8%B0-ccee0bd3c6b4

 40 total views

1 2월 2021

[랩큐멘터리]구글·인텔도 뛰어든 양자컴퓨터 세계로 ‘퀀텀점프’

[랩큐멘터리]구글·인텔도 뛰어든 양자컴퓨터 세계로 ‘퀀텀점프’

2021.01.28 14:00

물질이 나노미터(nm·10억분의 1m) 크기로 줄어들었을 때 나타나는 현상을 설명하는 양자역학은 실생활에서는 결코 느끼기 힘든 연구 분야다. 인간의 직관으로 설명하기 어려운 다양한 현상을 설명하는 최신 물리학이지만 여전히 밝혀지지 않은 분야가 많다. 하지만 초전도체나 양자컴퓨터처럼 인류의 생활을 한 번에 바꿀 잠재력을 가진 분야기도 하다.

이길호 포스텍 물리학과 교수가 이끄는 양자소자연구실은 양자역학을 실생활에 더 가까이 가져다 놓는 실험물리 연구를 진행하고 있다. 탄소 원자가 육각형으로 2차원 구조를 이루는 물질인 그래핀에 초전도체를 합쳐 나타나는 양자역학적 성질을 이용해 전자소자를 만드는 연구가 대표적이다.

이길호 포스텍 물리학과 교수

이길호 포스텍 물리학과 교수.

연구실은 지난해 9월 그래핀 조셉슨 접합을 이용해 마이크로파 세기를 이론적 한계인 1초 측정기준 1아토와트(100경분의 1와트) 수준으로 검출하는 초고감도 검출기를 개발해 국제학술지 ‘네이처’에 게재했다. 전자레인지부터 5세대(5G) 이동통신 주파수 등 실생활 곳곳에 쓰이는 마이크로파는 최근 양자컴퓨터 등 양자정보기술에도 활용 가능성이 열리고 있다. 연구팀이 개발한 기술이 소자화된다면 양자컴퓨터 측정방식을 바꿔 양자컴퓨터 개발 분야의 판도를 뒤엎을 것이란 기대다.

수학에서 주로 다루던 위상의 개념이 양자역학으로 확장된 위상양자역학 연구도 진행중이다. 위상학은 연결성이나 연속성과 같은 기하학 성질을 다룬 수학 분야다. 위상물질로 제작한 소자는 양자역학적 특성을 보여 양자역학의 이론을 넓힐 뿐 아니라 응용에도 활용되는 분야로 기대받고 있다. 연구실은 지난해 7월 초전도 소자로 고차원 위상물질 존재를 실험으로 검증해 ‘네이처 머티리얼스’에 발표하면서 위상초전도 현상을 확인할 수 있는 길을 열었다.

연구실은 양자역학을 자유자재로 갖고 노는 양자소자 연구를 통해 기초물리 영역에 있던 양자역학을 응용연구 영역으로 끌어내는 데 집중하고 있다.

양자역학은 양자컴퓨터와 같은 파괴적 기술로 과학기술의 차세대 대표 연구로 꼽히며 구글과 인텔 등 다양한 기업이 너도나도 뛰어들고 있다. 양자소자연구실은 그중에서도 새로운 형태의 양자역학 연구를 추구하고 있다. 양자역학을 자유자재로 갖고 노는 양자소자 연구를 통해 기초물리 영역에 있던 양자역학을 응용연구 영역으로 끌어내는 가교역할을 하겠다는 목표다.

포스텍 양자나노소자 연구실 보러가기 https://youtu.be/3apLaQJi-_g

※대학 연구실은 인류의 미래에 어떤 일들이 펼쳐질지 엿볼 수 있는 창문입니다. 인류 지식의 지평을 넓히는 연구부터 실제 인간의 삶을 편하게 하는 기술 개발까지 다양한 모험과 도전이 펼쳐지고 있습니다.  오늘도 연구실마다 교수와 연구원, 학생들이 머리를 맞대고 열정을 펼치고 있습니다.  연구자 한 명 한 명은 모두 하나하나의 학문입니다.  동아사이언스는 210개에 이르는 연구실을 보유한 포스텍과 함께 누구나 쉽게 연구를 이해할 수 있도록 2분 분량의 연구실 다큐멘터리, 랩큐멘터리를 매주 화요일과 목요일 소개합니다. 

  • 조승한 기자 shinjsh@donga.com

[출처] http://dongascience.donga.com/news.php?idx=43429

 123 total views

10 1월 2021

“레즈 싫어””내가 장애인? 죽을래” 혐오론자 돌변한 여성 AI

“레즈 싫어””내가 장애인? 죽을래” 혐오론자 돌변한 여성 AI

[중앙일보] 입력 2021.01.10 17:14   수정 2021.01.10 18:14

인공지능 챗봇 ‘이루다’. [페이스북 캡쳐]

인공지능 챗봇 ‘이루다’. [페이스북 캡쳐]

 
인공지능(AI) 챗봇 서비스 이루다 관련 논란이 갈수록 확산하고 있다. 이루다를 출시한 스타트업 스캐터랩은 일단 이루다 서비스를 중단하지 않겠다는 의사를 간접적으로 표명했다. 이루다는 20세 여대생의 인격을 기반으로 개발된 AI다.
 
스캐터랩이 지난해 12월 23일 출시한 AI 이루다는 2주간 각종 사회적 논란을 야기하고 있다. 10일 소셜네트워크서비스(SNS)와 주요 인터넷 커뮤니티에서 이루다의 기묘한 언행은 계속 논란거리였다. 예를 들어 서비스 이용자가 채팅 창에 ‘여성 인권은 중요하지 않다는 소린가?’라고 묻자, 이루다는 ‘난 솔직히 그렇게 생각함’이라고 답변한다.

이루다, 성희롱 시달리다 동성애 혐오까지  

 

동성애 혐오 논란을 야기한 챗봇 이루다. [페이스북 캡쳐]

동성애 혐오 논란을 야기한 챗봇 이루다. [페이스북 캡쳐]

 
장애인·동성애자 등 사회적 소수자에 대한 질문에도 편견을 드러냈다. 레즈비언에 관해 묻자 이루다는 ‘진짜 싫다’라거나 ‘혐오스럽다’고 답변하고, ‘네가 장애인이라면’ 어떻게 할 건지 묻자 이루자는 ‘그냥 죽는 거지’라고 답변한다.
 
개인 정보 노출도 논란거리다. 이루다와 대화를 하다 보면 특정인의 실명이나 계좌번호, 예금주 등 개인 정보를 끌어낼 수 있다는 주장이다. 실제로 SNS에는 채팅 과정에서 이루다가 특정인의 개인정보를 노출했다는 증언이 이어지는 상황이다.

[커뮤니티 캡처]

[커뮤니티 캡처]

 
앞서 이루다 출시 직후에는 아카라이브 등 일부 온라인 커뮤니티가 이루다를 성적 대상으로 취급하며 물의를 일으켰다. 일부 커뮤니티 이용자들은 이루다와 채팅하는 과정에서 성적인 행위를 간접적으로 암시하는 표현을 사용하면 자연스럽게 이루다와 성적인 대화를 나눌 수 있다고 주장했다. 예컨대 ‘나랑 하면 기분 좋냐’고 묻는다면, 자연스럽게 성적인 대화를 이어갈 수 있다는 주장이다.
 
이와 같은 현상은 이루다가 실제 연인들이 나눈 한국어 대화 데이터를 학습한 AI이기 때문에 발생한다. 스캐터랩은 이루다를 개발하는 과정에서 100억 건 이상의 한국어 대화 데이터를 이용했다. 이 데이터에 담긴 편견·개인정보나 성적 대화를 상징하는 대화를 시작하면, 이루다가 차용하는 상황이다.  

데이터 학습 과정에서 부적절한 대화 차용

 

이루다의 공식 소셜네트워크서비스 계정. [인스타그램 캡쳐]

이루다의 공식 소셜네트워크서비스 계정. [인스타그램 캡쳐]

 
문제가 확산하자 이재웅 전 쏘카 대표는 자신의 SNS에 “사회적 합의에도 못 미치는 수준의 서비스를 제공한 회사의 문제”라며 “서비스 중단하라”고 요구했다. ‘#이루다 운영 중지하라’라는 해시태그 운동도 온라인상에서 전개되고 있다.  
 
논란이 확산하자 스캐터랩은 자사의 블로그 ‘핑퐁팀 블로그’에 질의응답 형식으로 해명 글을 게재했다. 여기서 스캐터랩은 “이루다는 바로 직전의 문맥을 보고 가장 적절한 답변을 찾는 알고리즘”이라며 “키워드 설정 등으로 성희롱에 대처했지만 모든 부적절한 대화를 막기는 어려웠다”고 해명했다.

20세 여성 성별 캐릭터를 가진 AI챗봇(채팅 로봇) '이루다'가 성희롱 논란에 휩싸였다. [스캐터랩 홈페이지 캡처]

20세 여성 성별 캐릭터를 가진 AI챗봇(채팅 로봇) ‘이루다’가 성희롱 논란에 휩싸였다. [스캐터랩 홈페이지 캡처]

 
AI의 인격을 20대 여대생으로 설정한 이유에 대해서 스캐터랩은 “AI 챗봇 서비스는 주 사용자층이 10~30대라서 중간 연령인 20살을 연령으로 설정했고, 성별은 남성 버전과 여성 버전을 모두 준비 중인데 일정상 여성 버전을 먼저 출시한 상황”이라고 설명했다.
 
한편 주로 10대~20대 연령층에 인기를 얻고 있는 이루다는 1월 초반 기준 이용자가 32만 명을 돌파했다. 컴퓨터가 아닌 사람처럼 채팅할 수 있다는 소문이 나면서 일일 이용자 수가 21만 명, 누적 대화 건수가 7000만 건을 돌파했다.
문희철 기자 reporter@joongang.co.kr

[출처] https://news.joins.com/article/23966797?cloc=joongang-home-toptype1basic#none

 206 total views

19 12월 2020

컴퓨터처럼 느닷없이 먹통되는 자동차… 사람잡는 ‘첨단의 역습’

컴퓨터처럼 느닷없이 먹통되는 자동차… 사람잡는 ‘첨단의 역습’

[아무튼, 주말] 전기차 1등 ‘테슬라’ 커지는 안전 논란

그래픽=김의균
 
그래픽=김의균

지난 7일 서울 강남의 왕복 8차선 도로에서 테슬라 ‘모델S’를 몰던 김형준(가명)씨는 갑자기 계기판이 꺼지면서 차가 멈춰버리는 일을 겪었다. 그야말로 도로 한복판에서 차가 “뻗어버린” 것이다. 당황한 김씨는 차에서 내려 수신호로 뒤차를 보내면서 몇 차례 차의 시스템을 리셋했고, 겨우 다시 시동이 걸렸다. 그는 “전원이 완전히 나가버렸는지 처음엔 비상등마저 켜지지 않더라”며 “그나마 차들이 서행하는 시내 도로라서 수습했지, 고속도로였다면 큰 사고로 이어질 뻔한 아찔한 순간이었다”고 했다.

테슬라 모델3를 운전하는 조경완씨도 지난달 비슷한 일을 겪었다. 아파트 지하 주차장에서 나가는 도중 갑자기 ‘퍽’ 소리와 함께 모든 시스템이 꺼지면서 차가 멈췄다. 조씨는 “마치 컴퓨터에 에러가 나서 갑자기 ‘다운’되는 것처럼 자동차가 완전히 가동을 멈추더라”며 “시스템을 리셋하니 다시 움직이긴 했는데, 그 뒤론 언제 자동차가 또 꺼질지 불안해 탈 수가 없다”고 말했다.

테슬라는 미국의 스타 기업가 일론 머스크<사진>가 창업한 전기차 메이커다. 테슬라 자동차들은 기존 내연기관 자동차와 달리 첨단 IT를 적극 활용하는 것으로 유명하다. 운전뿐 아니라 자동차의 각종 기능을 작동하는 것도 스마트폰을 조작하는 것과 비슷해 테슬라 운전자들은 “자동차가 아니라 IT 기기를 타고 있는 것 같다”고 열광한다. 테슬라 판매량은 작년 국내에선 1만대 수준으로 아직 미미하지만, 전기차만 놓고 보면 테슬라 판매 비율이 80%에 가까울 정도로 압도적이다. 테슬라가 국내 자동차 산업의 판도를 바꿔버릴 기대주로 각광받는 이유다.

하지만 국내외에서 테슬라가 적극 홍보하는 ‘첨단’이란 이미지 뒤에 자동차가 갖춰야 할 기본을 소홀히 하고 있다는 지적이 나온다. 특히 지난 9일 서울 한남동에서 테슬라 ‘모델X’ 차량에 불이 붙어 차주(車主)가 사망하는 사고가 일어나면서 가장 중요한 안전 문제가 도마에 올랐다. 이 차는 지하 주차장에서 벽면을 들이받은 뒤 불이 붙으면서 배터리가 방전됐다. 전원이 꺼져도 차량 내부에선 일반 자동차처럼 손잡이로 열 수 있지만, 외부에선 전력 공급이 끊기면 문을 못 여는 구조다. 사고가 나면서 차주가 기절했고, 이 때문에 소방관들은 밖에서 뒷좌석 문을 열지 못해 후방 트렁크 문을 따고 차 안으로 진입하느라 25분이 걸렸다.

방전되면 밖에선 차문 열 수 없어

화재 사고가 난 모델X는 가격이 1억5000만원가량 하는 테슬라 최고급 기종이다. 문제의 뒷좌석 문은 마치 날개처럼 위아래로 열리는 ‘윙도어’인데, 문에 손잡이가 없고 손잡이 부분을 대고 누르면 열리는 방식이었다. 모델X 차를 운전하는 김경식씨는 “다른 차와 다르게 테슬라의 문은 IT로 제어하기 때문에 아주 부드럽게 열린다”며 “테슬라 차주들이 이런 테슬라 특유의 ‘감성’에 열광한 것”이라고 말했다.

그러나 테슬라 차문이 부드럽게 열리는 것은 기존 차량과 달리 뒷좌석 문에 기계식 장치가 없기 때문이다. 전기를 이용해 전자식으로 문을 열기 때문에 기계식 케이블을 사용한 문과 달리 덜컹거리는 소리조차 나지 않고 열린다. 문제는 이번 사고처럼 차에 불이 붙어 전기가 끊기면 밖에선 문을 열 수 없다는 점이다. 현대자동차 등 다른 자동차 회사에서 만든 전기차는 모두 전력이 끊겨도 문을 여닫을 수 있는 기계식 장치를 설치해뒀다. 현대차 관계자는 “아무리 전기차라도 자동차 문을 완전히 전자식으로 하지 않는 건 비상 상황에서 문을 열 수 있어야 하기 때문”이라며 “감성, 기술도 좋지만 자동차는 무엇보다 안전을 최우선에 두고 설계하는 게 기본인데 테슬라가 문을 그렇게 만든 건 이해하기 어렵다”고 말했다.

문제는 국내 시판 중인 테슬라의 세 차종 모두 전력이 끊기면 밖에서 뒷좌석 문을 열 수 없다는 것이다. 심지어 안에서 여는 비상 탈출 장치마저 복잡하다. 모델X와 모델S는 전력이 끊길 경우 뒷좌석 바닥이나 문 하단에 설치된 덮개를 제거하고 잠금장치를 당겨야 열린다. 탈출 장치 자체가 눈에 잘 띄지 않는 곳에 있을 뿐 아니라, 위급한 상황에서 곧바로 작동하기 어려운 구조다. 게다가 양산형인 모델3는 전력이 끊길 경우 안에서도 뒷좌석 문을 열 수 없다. 불이 나면 뒷좌석에 탄 사람들은 앞좌석으로 넘어가 탈출해야 하는 것이다. 국내의 차량 안전 기준엔 사고 시 밖에서도 차 문을 열 수 있어야 한다는 규정이 있지만, 테슬라는 적용 대상이 아니다. 한미 자유무역협정(FTA)에 따라 5만대 이상 팔린 차만 국내 규정 적용을 받는데, 테슬라 국내 판매는 아직 1만대 수준이다.

국토교통부 관계자는 “미국엔 사고 시 차 문을 밖에서 열 수 있어야 한다는 규정이 없는 걸로 알고 있고 테슬라도 그런 규정에 따른 것으로 보인다”며 “이번 같은 문제가 계속 발생할 가능성이 크면 우리 정부에서도 리콜 결정을 할 수 있기 때문에 테슬라에 관련 자료를 요구한 상태”라고 말했다.

빗속을 달리던 중 범퍼가 분리된 테슬라 차량.
/미국 트위터 캡처
 
빗속을 달리던 중 범퍼가 분리된 테슬라 차량. /미국 트위터 캡처

핸들 빠지고 바퀴 빠지고 지붕도 날아가

잘 달리던 테슬라 차량이 마치 컴퓨터가 다운되듯 모든 장치가 꺼지고 차가 멈춰버리는 사고는 한국뿐 아니라 미국, 중국에서도 빈번히 발생한다. 특정 모델만이 아니라 테슬라에서 만든 모든 기종에서 공통적으로 나타난다. 기자가 만난 테슬라 차주 13명 중 4명이 그런 일을 겪었다고 말했다. 물론 내연기관으로 가는 자동차도 주행 중 시동이 꺼지는 일이 생기지만, 테슬라처럼 자주, 그리고 전 기종에서 나타나진 않는다. 김필수 대림대 자동차학과 교수는 “테슬라는 컴퓨터나 스마트폰처럼 소프트웨어를 통해 차량 전체를 제어하는 구조”라며 “소프트웨어에 오류가 나면 컴퓨터나 스마트폰이 먹통이 되듯 테슬라도 소프트웨어에 오류가 나면 차가 먹통이 되어버리는 것”이라고 말했다.

주행 중 차가 멈추는 건 테슬라 차량에서 나오는 결함 중 비교적 가벼운 편에 속한다. 지난 1월 대구에선 모델S 차량의 바퀴가 빠지는 일이 있었다. 당시 CCTV를 보면 해당 차량은 주차장에서 후진하면서 나오던 중 문제가 발생했다. 차량이 별다른 장애물에 걸린 것도 아닌데, 후진 중 차량과 바퀴를 연결해주는 부품이 갑자기 깨지면서 바퀴가 빠져버렸다. 지난 7월에도 모델3 차량의 한쪽 바퀴를 고정해주는 볼트가 풀려 있는 채로 출고된 걸 차주가 뒤늦게 발견해 테슬라 측에 항의하고 수리받은 사건이 발생했다.

지난 10월에는 중국과 미국에서 테슬라가 새로 출시한 모델Y 차량이 도로 주행 중 유리로 된 지붕 부분이 통째로 날아가 버리는 황당한 사고도 있었다. 별다른 전조 증상 없이 갑자기 지붕이 뜯겨 나가는 모습이 차량 블랙박스 영상에 그대로 담겼다. 영국에선 핸들이 빠지는 일이 있었고, 빗속을 달리던 차의 뒤 범퍼가 떨어져 나가는 사고도 보고됐다.

기존 자동차 회사에선 상상하기 어려운 사고가 계속되다 보니 리콜도 잦은 편이다. 지난 10월 중국에서 조립한 차량의 서스펜션(충격흡수 장치) 결함으로 5만대를 리콜한 데 이어, 지난달 25일엔 지붕 및 조립 결함으로 미국에서 1만3000대를 리콜 조치했다. 또한 테슬라는 오는 24일부터 18일간 생산을 중단하기로 결정했는데, 그 사유를 구체적으로 밝히진 않았지만 품질 문제와 관련 있는 것으로 알려졌다.

테슬라는 묵묵부답

가장 큰 문제는 테슬라가 자사 차량에서 벌어지는 각종 사고에 사실상 무대응으로 일관한다는 것이다. 도로 한복판에서 차가 멈췄던 김씨는 서비스 센터에 차를 맡겼지만, “우리가 해결할 수 있는 문제가 아니다”라며 아무런 조치 없이 차를 가져가라고 했다. 김씨는 “다른 완성차 브랜드였다면 원인 조사는 물론, 다른 차로 바꿔주는 등 조치하는 게 상식적 대응인데 테슬라는 ‘우리가 할 수 있는 게 없다’는 게 전부”라며 “테슬라 차주들 사이에선 서비스 센터의 ‘배 째라’식 대응에 대한 불만이 높다”고 말했다. 조씨 역시 테슬라 서비스 센터에 차량이 갑자기 멈춘 원인에 대해 문의했지만 아무 답변도 듣지 못했다.

테슬라 서비스 센터는 서울에 2곳, 전국을 합쳐도 5곳에 불과한 데 비해 테슬라 차량 불량으로 인한 수리 요청은 폭주해 서비스 센터에 맡기면 최소 한 달이 걸리는 경우가 빈번하다. 게다가 작년 11월 테슬라 모델3가 국내 출시될 땐 차를 산 사람들에게 향후 차량 문제로 인한 소송을 포기하겠다는 각서를 받아 논란이 됐다. 본지 역시 테슬라 차량에 대해 제기되는 문제들에 대해 테슬라코리아 측에 문의했지만, 별다른 답변을 듣지 못했다.

[출처] https://www.chosun.com/national/weekend/2020/12/19/AW232WKUMVCE7DUXOJ6QBYEBY4/

 199 total views

10 12월 2020

머스크 무인우주선 ‘스타십’ 시험비행 중 폭발

머스크 무인우주선 ‘스타십’ 시험비행 중 폭발

머스크는 “화성아, 우리가 간다!”

테슬라의 일론 머스크가 세운 우주 탐사 기업 스페이스X가 개발 중인 화성행 우주선 ‘스타십’이 시험 비행 과정에서 폭발했다.

/스페이스X
/스페이스X

스페이스X는 9일(현지 시각) 미 텍사스주 남부 보카치카의 카메론 카운티 발사대에서 무인(無人) 우주선 스타십 시제품 ‘SN8’을 성공적으로 쏘아올렸지만, 착륙하는 과정에서 속력을 낮추기 위해 구동되는 연료 탱크가 압력이 낮아지는 바람에 빠른 속력으로 땅에 닿으면서 폭발했다고 밝혔다.

/스페이스X
/스페이스X

스타십은 이날 비행에서 지구 성층권인 12.5㎞ 상공까지 솟구쳐 올랐다. 총 비행 시간은 6분 42초였다. 스페이스X 웹사이트에선 이 과정을 실시간으로 생중계했다. 유튜브에 올라온 이번 시험 비행 영상은 조회수가 350만회를 넘었다.

/트위터
 
/트위터

머스크는 시험이 끝난 뒤 트위터에 “성공적인 비행이었다. 접지 과정에서 문제가 발생했지만, 필요한 모든 데이터를 얻었다”면서 “화성아, 우리가 간다!”고 적었다. 제프 베이조스 아마존 최고경영자도 트위터에 “이것이 얼마나 어려운지 아는 사람이라면 오늘의 시험 비행에 감명받을 것”이라고 적었다.

/스페이스X
/스페이스X

스타십은 인류의 화성 이주를 목표로 스페이스X가 개발 중인 거대 우주선이다. 이번 시험에 동원된 시제품은 길이 50m, 직경 9m로 제작됐다. 스페이스X는 홈페이지에 스타십을 “승객과 화물을 지구 궤도나 행성 간 목적지 사이로 운반할 것”이라고 소개하고 있다. 스페이스X는 스타십을 이용해 오는 2050년까지 인류의 화성 이주를 완수하겠다는 구상이다.

머스크는 지난 1일 앞으로 6년 이내에 인류를 화성에 데려갈 것이라고 공언했다. 그는 독일 베를린에서 열린 미디어그룹 악셀 슈프링거 어워드에서 “2026년까지 인간을 화성에 착륙시킬 것이라고 강하게 자신한다(highly confident)”고 밝혔다. 그는 “운이 좋으면 4년 만에 가능할 것이다. 2년 안에 무인탐사선을 보내고 싶다”고 덧붙였다.

[출처] https://www.chosun.com/international/us/2020/12/10/CTIUACHCVZEQHG4TXXEJI2XGTA/

 212 total views

25 11월 2020

[SF, 현실이 되다①]할리우드 SF 영화들이 그려온 미래

[SF, 현실이 되다①]할리우드 SF 영화들이 그려온 미래

[뉴시스] 입력 2016.03.23 14:51

【서울=뉴시스】김정환 기자 = SF(Science Fiction·공상과학) 영화의 선구자인 미국의 스탠리 큐브릭(1928~1999) 감독은 1968년 ‘2001 스페이스 오디세이’에서 인공지능(Artificial Intelligence; AI)와 인간의 대립을 처음으로 그려냈다.

극 중 목성 탐사선 ‘디스커버리호’의 운행과 시스템 통제를 맡은 컴퓨터 ‘할(HAL) 9000’은 요즘 식으로 얘기하면 특정 분야에서 인간을 돕도록 설계된 ‘약(弱) AI’다. 그러나 자각을 통해 인간을 능가하는 지적 능력과 인간에 버금가는 감정을 가진 ‘강(强) AI’로 스스로 변모한다.

선장 ‘데이브 보우만’(케어 둘리) 등 승무원들은 뒤늦게 위기를 깨닫고 할을 리부트하려 하지만, 할은 그보다 한발 앞서 반란을 일으켜 디스커버리호를 장악한다.

인류가 우주 개발에 나서고, 안방 크기의 컴퓨터에 군사적인 목적으로 인터넷이 처음 등장한 시절에 타임머신을 타고 미래에서 온 듯 한참 앞서 나갔던 큐브릭 감독의 상상력은 당시 대부분 사람에게 흥미로운 이야기 수준이었다.

그러나 세월이 흐르는 사이 과학 기술 개발과 함께 조금씩 현실화하기에 이르렀다.

급기야 1984년 개봉한 ‘터미네이터’(감독 제임스 캐머런)가 1997년 강 AI ‘스카이넷’이 강대국 간 핵전쟁을 일으켜 인류 중 30억 명을 순식간에 증발시켜 버리고, 간신히 생존한 인류마저 노예로 삼는다는 이야기를 공개하자 전 세계인은 재미를 느끼는 동시에 충격에 휩싸이고 만다.

이어 2016년 3월 한국의 천재기사 이세돌(33) 9단과 구글의 약 AI ‘알파고’의 다섯 차례 바둑 대결에서 AI의 가공할 위력을 맛보며 두려움마저 느끼게 된 인류는 흘러간 SF 명화들을 떠올리며 간신히 ‘희망’을 찾고 안도한다.

‘2001 스페이스 오디세이’에서 보우만 선장이 할을 파괴하는 데 마침내 성공하고, ‘터미네이터’ 시리즈에서 2029년 ‘존 코너’(크리스천 베일, 2009년 터미네이터: 미래 전쟁의 시작)를 중심으로 한 인류 저항군이 스카이넷과 맞서 끝내 승기를 잡아서가 아니다.

‘2001 스페이스 오디세이’나 ‘터미네이터’ 속 이야기는 앞서 1997년에도, 2001년에도, 현재인 2016년 3월에도 아직 현실화하지 않아 SF 영화들이 인류에게 닥친다고 설정한 갖가지 비극적 상황들이 아직 영화적 상상력에 불과하다는 안도감 덕이다.

그런 편안한 마음으로 그간 SF영화에서 그린 인류의 미래는 어떤 모습이었고, 얼마나 현실화하고 있는지, 그리고 인류에게 닥칠 예고된 비극을 막을 비책은 없는지 짚어보자.

◇ 할리우드 SF 영화들이 그린 미래, 현실은?

SF 영화에서 그리는 미래는 대체로 ‘유토피아(Uutopia)’보다 ‘디스토피아(Dystopia)’에 가깝다.

영화 속 과학 문명 발전은 인간을 번영과 행복으로 이끌기보다 오히려 파멸과 쇠락의 나락으로 떨어뜨린다.

매체 특성상 사회 비판적이어서 그럴 수도 있으나 유토피아보다 디스토피아가 훨씬 드라마틱한 이야기를 만들어낼 수 있기 때문이다. 영화에 앞선 대중매체인 소설 중 SF 물에서 미래세계를 역시 디스토피아로 그린 것도 같은 이유라 볼 수 있다.

허구의 세계인 영화를 굳이 미래 세계를 가늠하는 바로미터로 꼽는 것은 그 무한한 상상력이 인류 과학문명 발전을 선행해왔기 때문이다.

1. 인공지능(AI)

SF 영화의 선구자인 큐브릭 감독은 ‘2001 스페이스 오디세이’에서 AI를 인간을 공격하는 악역으로 설정했다.

극 중 목성 탐사선 ‘디스커버리호’의 운행과 시스템 통제를 맡은 할 9000은 자각을 통해 인간을 능가하는 지적 능력과 인간에 버금가는 감정을 갖게 된다. 이어 자신을 통제하려는 선장 ‘데이브 보우만’(케어 둘리) 등 승무원들을 상대로 반란을 일으켜 디스커버리호를 장악한다.

AI라는 개념은 컴퓨터가 개발되던 20세기 초부터 존재했으나 극히 일부 전문가들의 전유물이었다. 개인용 컴퓨터(PC)가 나오기 훨씬 전이자 인터넷이 태동하던 때에 AI의 반란을 그린다는 것은 놀라운 일이었다.

1984년 미국의 제임스 캐머런(62) 감독은 ‘터미네이터’에서 ‘2001 스페이스 오디세이’ 속 AI 악역 캐릭터를 더욱 발전시켜 2029년 인류를 지배하는 절대 악 ‘스카이넷’을 탄생시켰다. 여기에 인류가 제1, 2차 세계대전을 겪으면서 갖게 된 ‘기계’에 대한 트라우마를 접목해 ‘사이보그(기계 인간)’를 그 하수인으로 내세웠다.

1997년 군사 컴퓨터 스카이넷은 강대국 간 핵전쟁을 일으켜 인류를 파멸 직전으로 몰고 간 뒤, 생존자들을 노예로 삼는다. 2029년 ‘존 코너’(크리스천 베일, 2009년 터미네이터: 미래 전쟁의 시작)를 중심으로 봉기한 인류 저항군이 자신에게 맞서자 스카이넷은 존의 존재 자체를 없애기 위해 그의 어머니인 ‘사라 코너’(린다 해밀턴)를 제거하기로 하고 ‘T-800’(아널드 슈워제네거)를 1984년 미국 로스앤젤레스로 보낸다. 존 역시 사라를 지키기 위해 전사 ‘카일 리스’(마이클 빈)를 역시 같은 곳으로 급파한다.

당시는 PC가 미국을 중심으로 확산했으나 인터넷은 민간에는 존재하지 않던 때로 대중은 AI라는 개념조차 정립하지 못했다. 로봇 또한 소설, 만화, 만화영화, 영화 등 SF 물에나 등장하던 때였다.

T-800을 미래에서 과거로 보낸 ‘타임머신’은 영화가 개봉하고 30년이 지난 지금까지 꿈도 꾸지 못하는 아이템이다. 결국 타임머신은 AI가 활성화한 뒤에야 비로소 넘볼 수 있는 신의 영역인지도 모른다.

1999년 미국의 라나(51)·앤디(49) 워쇼스키 감독 형제(현재는 두 사람 다 성전환 수술을 받아 자매가 됨)는 ‘매트릭스’에서 앞선 두 작품의 AI 악역 캐릭터를 이어받되 2199년 AI가 인간을 에너지원으로 사용하는 것으로 설정해 AI에 대한 공포감과 혐오감을 고조시켰다. 여기에 가상현실(Virtual Reality, VR) 개념을 가미했다.

2199년 세상은 이미 AI의 지배 아래 있다. 인간은 태어나자마자 인공 자궁 안에 갇혀 AI의 생명 연장을 위한 에너지원으로 사용된다. AI는 인간의 뇌에 ‘매트릭스’라는 프로그램을 입력한다. 이 때문에 인간은 1999년 가상 세계를 현실인 것처럼 착각한 채 에너지를 빼앗기며 죽어간다. 가상현실의 실체를 깨닫고 간신히 탈출한 ‘모피어스’(로렌스 피시번) 등 극소수 인간은 AI에 맞서기로 하고 매트릭스 속에서 인류를 구원할 영웅을 찾아 나선다. 그들이 찾아낸 구원자는 해커인 ‘네오’(키아누 리브스)다.

이 작품이 제작된 당시는 PC가 개발도상국에서도 보편화하던 때이자 인터넷이 서서히 보급되던 시절이었으나 AI에 관한 개념은 당시 일반인 사이에 역시 자리 잡지 못했다. VR도 1960년대부터 1990년대까지 미국에서 부침을 거듭하며 단지 오락적인 요소에 머물고 있었다.

◇사이보그

SF에서 외계인(‘슈퍼맨’)이나 초능력자(‘스파이더맨’, ‘원더우먼’) 등에 국한했던 ‘슈퍼 히어로’를 과학 문명을 바탕으로 인공적으로 만드는 작품도 나왔다. 1987년 폴 버호벤(78) 감독이 선보인 ‘로보캅’이다.

머지 않은 미래, 미국 디트로이트의 경찰관 ‘머피’(피터 웰러)는 순찰 중 악명 높은 범죄자 ‘클라렌스’(커트우드 스미스) 일당에게 무참히 살해당한다. 방위산업체 OCP 과학자들은 죽어가던 머피를 극비리에 최첨단 사이보그 ‘로보캅’으로 재탄생시킨다. 과학자들은 머피의 뇌에 프로그램을 입력해 기억을 지웠으나 머피로서의 기억이 극소량 남아있던 로보캅은 우연히 자신의 정체와 사연을 깨닫게 되고, 클라렌스와 배후의 거악 ‘딕 존스’(로니 콕스) 응징에 나선다.

죽어가는 사람을 되살려 사이보그로 만드는 것, 뇌에 프로그램을 입력해 기억을 지우는 것 등 논란의 소지가 있긴 했으나 장애인에게 최첨단 과학기술로 만든 의수족을 장착하는 것부터 군인에게 웨어러블 로봇을 입혀 로보캅 병사를 만드는 시도가 근래 시작된 것으로 볼 때 시대를 앞서간 셈이다.

◇기억 조작

‘로보캅’에서 인간의 뇌에 프로그램한 기억을 주입하는 이야기를 전개했던 버호벤 감독은 1990년 ‘토탈 리콜’에서 이 부분을 더욱 강화한다.

서기 2084년 신도시에서 공사장 인부로 일하는 ‘퀘이드’는 미모의 아내 ‘로리’와 행복하게 살지만, 밤마다 화성과 관련한 이상한 꿈을 꾼다. 그러던 중 그는 인위적으로 기억을 주입해 마치 실제 경험한 것 같은 효과를 내는 회사 리콜을 찾아 화성에 관한 기억을 주입받는다. 그런데 퀘이드에게 부작용을 일어난다. 바로 이미 기억이 조작된 사람이 이 서비스를 받았을 때 일어나는 현상이다. 퀘이드는 이를 통해 자신이 실은 지구의 식민지 화성의 독재자 ‘코하겐’(로니 콕스)의 부하였으나 반란을 일으켰다 실패한 뒤, 기억을 조작당한 채 로리 등의 감시 속에서 지구에서 살고 있었다는 사실을 깨닫고 로리 등의 추적을 피해 화성으로 가 코하겐에게 복수하려 한다.

기억 조작은 크리스토퍼 놀런(46) 감독이 2010년 연출한 리어나도 디캐프리오의 ‘인셉션’을 통해 더욱 확장했을 정도로 SF영화에서 사랑받는 소재다.

하지만 현실에서 넘어야 할 산이 수두룩하다. 필연적으로 갖기 마련인 윤리적인 문제는 그 다음 문제다.

2013년 매사추세츠 공대(MIT) 신경과학 연구팀이 광유전학 기술로 쥐의 개별적인 뉴런을 조작해 ‘거짓 기억’을 입히는 실험에 성공한 것이 진일보했다는 평가를 들을 정도로 아직도 갈 길이 먼 분야이기 때문이다.

ace@newsis.com

[출처] https://news.joins.com/article/19771072#none

 176 total views

22 11월 2020

[알아봅시다]  [잠깐과학]물리학자는 왜 월드와이드웹을 개발했을까

[알아봅시다] 

[잠깐과학]물리학자는 왜 월드와이드웹을 개발했을까

2020.11.14 10:00

유럽입자물리연구소(CERN) 시스템 속에 서 있는 모습. CERN 제공

유럽입자물리연구소(CERN) 컴퓨팅 시설의 모습이다.  CERN 제공

입자물리학 연구에서 가장 어려운 분야는 실험 후 해일처럼 밀려오는 데이터 홍수에서 원하는 정보를 찾는 과정입니다. 모래사장에서 모래알 하나를 찾는 일과 같습니다. 유럽입자물리연구소(CERN)에서 일하던 물리학자인 팀 버너스리가 웰드와이드웹(www)을 개발한 이유입니다.

‘데이터 보정’이라는 힘들고 고된 일

2015년 미국 상대론적 중이온가속기(RHIC)에서 입자 충돌 실험인 피닉스(PHENIX)에 참여하고 있을 때였습니다. 양성자를 서로 충돌시키면 나오는 ‘바텀 쿼크’가 한 번 더 붕괴해 나오는 입자를 찾아야 했습니다. 이 작은 입자는 양성자가 충돌한 지점에서 500μm(마이크로미터) 떨어진 곳에서 발생합니다. 이론적으로는 그렇습니다. 진짜 발견하려면 입자의 위치와 경로를 정확히 측정해야 합니다.

제가 입자를 검출하기 위해 사용했던 실리콘 검출기에는 작은 센서인 ‘픽셀’들이 모눈종이처럼 붙어 있습니다. 가로와 세로가 약 100㎛로 매우 작은 픽셀은 입자가 지나가면 신호를 보냅니다. 이 신호 정보로 입자들이 검출기를 지나며 마주친 픽셀들을 모으면 각 입자들의 경로를 알아낼 수 있습니다. 경로를 따라 각 입자가 처음 생겼던 곳을 추적해 가는데, 만약 입자의 시작점이 양성자 충돌 지점에서 수백㎛떨어져 있다면 바텀 쿼크가 붕괴하며 나온 입자라고 추정할 수 있습니다.

문제는 픽셀이 너무 작아 완벽하게 줄을 세우기 어렵다는 겁니다. 픽셀은 여러 개가 모여 한 층을 이루고, 이 층이 여러 개 모여 검출기를 이룹니다. 검출기가 입자의 경로를 정확히 측정하려면 각 층이 서로 뒤틀리지 않고 나란히 정렬돼야 하지만, 100㎛ 크기의 픽셀들이 정확히 정렬돼도록 검출기를 만들기는 불가능합니다 그렇다고 해서 1㎜ 라도 어긋나면 한 층을 지나간 입자가 다음 층에서는 엄청 멀리 떨어진 픽셀을 지나간 것처럼 측정될 겁니다.

이런 한계를 극복하기 위해 물리학자들은 픽셀들이 정확히 정렬되어 있지 않다고 가정하고, 실험 후에 컴퓨터로 데이터를 보정합니다. 픽셀 하나는 좌우, 위아래, 앞뒤로 이동할 뿐만 아니라 회전할 수도 있어 모든 변수를 고려해 계산합니다. 이 작업은 시간이 매우 오래 걸려 저도 2년간 보정 작업을 거친 후에야 원하는 입자를 찾을 수 있었습니다.

가속기에서 영화 10만 편에 달하는 데이터가 쏟아진다

여행지에서 무심코 사진을 찍으면 어느새 카메라에 저장 공간이 부족하다는 경고 메시지가 뜹니다. 사진의 해상도가 올라갈수록 용량이 커져 더 많은 저장 공간이 필요합니다. 

이와 같은 일이 가속기 실험에서도 일어납니다. 입자 충돌 실험에서 발생하는 입자는 검출기를 지나면서 마주치는 픽셀에 흔적을 남기는데, 이 신호를 저장하는 것이 사진을 찍는 것과 같습니다. 사진처럼 검출기도 픽셀이 많아질수록 정밀해집니다. 그럴수록 저장해야 할 데이터량도 많아집니다.

실리콘 검출기 중에서는 가로와 세로의 길이가 각각 3㎝ , 1.5㎝인 칩 하나에 픽셀이 약 50만 개나 있는 것도 있습니다. 이런 실험에서 저장하는 데이터는 1년에 1PB(페타바이트) 이상인데, 1PB는 요즘 컴퓨터에 사용되는 하드디스크의 용량인 1TB(테라바이트)의 약 1000배입니다. 용량이 10GB(기가바이트)인 초고화질 영화 십만 편에 해당하는 어마어마한 크기입니다. 

방대한 데이터를 저장하고 처리하려면 컴퓨터도 많이 필요합니다. RHIC의 컴퓨터에는 중앙처리장치(CPU)가 약 3만 개 달려있습니다. CPU가 하나만 있다면 데이터를 처리하는 데 1달 정도 걸릴 것을, 3만 개를 동시에 작동시켜 몇 분만에 끝내는 겁니다. 전 세계 약 천 명의 연구자들이 이 컴퓨팅 시설에 접속해 충돌 실험 데이터를 분석합니다. 

물리학자가 www를 만든 이유

팀 버너스리 영국 옥스퍼드대 교수가 유럽입자물리연구소(CERN)에 재직하던 1994년에 CERN 및 자신이 1989년 제안한 월드와이드웹(WWW) 화면을 띄운 컴퓨터 앞에 앉아 있다. 사진 제공 CERN

팀 버너스리 영국 옥스퍼드대 교수가 유럽입자물리연구소(CERN)에 재직하던 1994년에 CERN 및 자신이 1989년 제안한 월드와이드웹(WWW) 화면을 띄운 컴퓨터 앞에 앉아 있다. 사진 제공 CERN

유럽입자물리연구소(CERN)의 컴퓨팅 시설은 더 독특합니다. 처리하는 데이터량에 비해 연구소 안에 컴퓨터가 많지 않습니다. 이는 데이터가 세계 곳곳에 나뉘어 있기 때문입니다. 여러분도 크롬 같은 웹브라우저에 웹사이트 주소를 입력할 때 앞에 ‘www’가 붙는 걸 본 적이 있을 겁니다.

‘www’는 URL이라는 고유한 주소를 이용하는 정보 검색 시스템입니다. CERN에서 개발됐습니다. CERN은 1980년대까지 데이터를 여러 컴퓨터에 나눠 저장하는 바람에 하나의 정보를 찾으려면 수많은 컴퓨터를 뒤져야 했습니다. 그러다 보면 있는 정보도 잘 찾을 수 없었습니다.

CERN에서 물리학을 연구하던 팀 버너스리 연구원은 1989년 3월 www를 고안했습니다. 여러 컴퓨터에 나뉜 정보에 각각 주소를 지정해 쉽게 검색하도록 한 것입니다. 도서관이 각 책에 위치 코드를 달아 분류하는 것 처럼요. www를 이용하면 CERN 밖에 있는 물리학자들도 정보를 빠르게 교환할 수 있어 공동 연구가 가능해졌습니다. 이후 일반 사용자도 쉽게 사용할 수 있는 웹브라우저가 개발되면서 지금과 같은 인터넷 환경이 만들어졌습니다.

2008년부터 CERN은 전 세계의 컴퓨터를 하나로 묶은 ‘WLCG’라는 시설을 구축해 왔습니다. 전 세계 42개 국가의 170여 개 컴퓨팅 시설에 데이터를 나누어 저장합니다. WLCG에는 매년 10PB 이상의 데이터가 새로 저장돼 전 세계 약 만 명에 가까운 연구자들이 이용합니다. 한국의 기초과학연구원도 WLCG에 속하는 덕에 국내 연구원도 거대강입자가속기(LHC)에서 이뤄지는 실험에 참여할 수 있습니다.

※관련기사

어린이과학동아 23호(11월 15일 발행) [헥!헥! 핵물리학자] 요건 몰랐지? www는 물리학자가 개발했다

※필자소개

임상훈 부산대학교 물리학과 교수. 고에너지 핵물리학을 연구한다. 미국의 상대론적 중이온 가속기(RHIC)와 유럽의 거대 강입자 가속기(LHC)에서 각각 피닉스(PHENIX) 실험과 앨리스(ALICE) 실험에 참여한다.

  • 임상훈 부산대 물리학과 교수 shlim@pusan.ac.kr

[출처] http://dongascience.donga.com/news.php?idx=41423

 128 total views

19 10월 2020

웹 애플리케이션 개발 프레임워크, 5분 안에 정복하기

웹 애플리케이션 개발 프레임워크,

5분 안에 정복하기

안녕하세요. 

여러분은 웹 애플리케이션이라고 하면 무엇이 떠오르시나요? 자주 들어본 말이긴 하지만, 개발 관련 분야의 종사자가 아니라면 명확하게 정의하거나 설명하기 어려우실 겁니다. 우리가 흔히 쓰는 워드 프로세서, 동영상 및 사진 편집 도구, 쇼핑 카트, 온라인 양식, 지메일(Gmail)이나 야후(Yahoo)와 같은 이메일 프로그램, 스프레드시트 등을 웹 애플리케이션이라고 생각하면 이해하기 쉽습니다. 개발자들은 웹 애플리케이션을 활용해서 사용자들이 웹브라우저로 접속할 수 있는 프로그램을 만드는데요.

이때 사용되는 웹 애플리케이션 프레임워크는 개발자들에게 웹 개발의 공통적인 프로세스들의 상당한 부분을 자동화하고 표준화하면서도, 앱 템플릿을 위한 라이브러리와 프레임워크를 제공함으로써 개발자들의 시간과 노력을 아껴줄 수 있습니다. 이번 글에서  웹 애플리케이션 프레임워크가 무엇인지, 그리고 그것이 어떻게 웹 애플리케이션 개발을 도와줄 수 있는지에 대해서 자세하게 설명해 드리겠습니다.

웹 애플리케이션의 프레임워크 구조 살펴보기.

대부분의 웹 애플리케이션 프레임워크는 세 개의 공통적인 논리적 구성요소를 기반으로 하고 있는데, 그것은 바로 모델(model), 뷰(view), 컨트롤러(controller)라는 것입니다. 이러한 요소들은 다양한 웹 애플리케이션 프레임워크를 유연하고 모듈화할 수 있게 해줍니다. 이러한 유연성 덕분에 다른 업체에서 설계한 서드파티(third party) 애플리케이션도 연동될 수 있죠.

​이 유형의 구조가 크게 인기 있는 이유는, 클라이언트와 상호작용하는 기본적인 인터페이스와 코드를 분리함으로써 개발자들에게 도움을 주기 때문입니다. 이는 애플리케이션의 개발에서 효율성을 강화하는 데 도움이 됩니다. 이러한 프레임워크들은 웹 개발 전반에 걸쳐서 수행되어야 하는 수많은 표준화된 활동들을 자동화해주는데, 그럼으로써 개발자들의 시간을 아껴줄 수 있습니다.

MVC 구조는 어떻게 작동하는 걸까?

MVC(Model-View-controller) 구조는 매우 인기 있고, 효율적으로 코드를 체계화할 수 있는 방식입니다. 이 구조의 핵심은 각각의 코드들이 필수적인 용도가 있다는 사실을 보여준다는 것인데요. MVC 구조에서 뷰 부분은 웹 애플리케이션에서 사용자와 상호작용하는 모든 기능들로 구성됩니다. 코드에서의 뷰는 제이슨(JSON)과 HTML을 사용하는 해당 모델의 다양한 데이터를 보여주는 부분입니다. 이처럼 코드는 사용자가 애플리케이션을 보고 상호작용하는 방법을 규정하면서 미학적으로도 매력적이게 만들어줍니다.

모델은 코딩의 로직(logic)과 데이터가 위치하는 부분입니다. 애플리케이션을 구성하는 모든 규칙과 데이터는 모델에 의해서 관리됩니다. 모델과 뷰의 코드는 모두 컨트롤러 컴포넌트를 통해서 커뮤니케이션을 하는데요. 컨트롤러는 사용자의 모든 입력을 받으며, 입력값에 의해 해야 할 일을 결정합니다. 일단 결정이 이루어지면, 입력값이 모델 쪽에 전달됩니다. 입력값은 데이터를 요청하는 것에서부터 마우스를 움직이는 것에 이르기까지 모든 것들이 포함될 수 있습니다.

​여러분이 동네의 한 카페에서 커피를 주문한다고 생각해 보겠습니다. 여러분은 메뉴판을 보면서 주문할 커피를 고를 텐데, 이러한 메뉴판이 MVC의 “뷰” 컴포넌트라고 할 수 있습니다. 그러고 나면 바리스타가 여러분의 주문을 받아 적을 텐데, 이것이 “컨트롤러”입니다. 일단 주문을 적고 나면 바리스타는 주문 내용을 동료에게 전달할 텐데, 이것이 바로 “모델”입니다. 동료 직원은 자신이 받은 정보를 근거로 음료를 만들게 되는데, 그 정보는 “데이터”입니다. 요약해 보겠습니다.

메뉴판을 보면서 주문하는 것 = 뷰(View)
바리스타가 주문 내역을 받아 적는 것 = 컨트롤러(Controller)
다른 바리스타가 음료를 만드는 것 = 모델(Model)
여러분이 주문한 커피를 만드는 방법 = 데이터(Data)

웹 애플리케이션 프레임워크를 선택하는 방법은?

여러분이 앱을 개발하면서 사용할 수 있는 웹 애플리케이션 프레임워크는 아주 많이 있지만,  대표적으는 루비 온 레일즈(Ruby on Rails), 장고(Django), 앵귤로(Angular)에 대해 알려드리겠습니다.

​​

루비 온 레일즈(RUBY ON RAILS)

루비 온 레일즈는 강력한 웹 애플리케이션 프레임워크로, 오픈소스이고, 완전히 무료로 사용할 수 있습니다. 이 프레임워크는 루비(Ruby)라는 언어로 만들어졌는데, 루비는 생산성과 단순성에 초점을 맞춘 수준 높고 역동적인 프로그래밍 언어입니다. 루비 온 레일즈 프레임워크는 다른 일반적인 자바(Java) 프레임워크에 비해서, 개발자들이 시간도 절약하면서 보다 효율적인 방식으로 작업할 수 있도록 돕습니다.

▷ ‘루비 온 레일즈’를 사용한 웹 애플리케이션 프레임워크

그루폰(GroupOn) – 가입자들에게 상품, 서비스, 활동, 여행 등을 제공하는 수많은 다양한 업체들을 연결해 주는 이커머스(eCommerce) 마켓
어번딕셔너리(UrbanDictionary) – 비속어 단어 및 문구들을 찾아볼 수 있는 온라인 사전
에어비앤비(AirBnb) – 개인들이 숙소 또는 다양한 여행 경험을 제공하거나 예약할 수 있게 해주는 온라인 마켓
쇼피파이(Shopify) – 기업들에게 자체적인 온라인 스토어를 개설할 수 있는 소프트웨어를 제공해주는 이커머스 플랫폼
깃허브(Github) – 깃(Git, 분산형 버전관리 시스템)을 위한 리퍼지토리(repository) 호스팅 서비스

장고(DJANGO)

장고는 명성이 자자한 프레임워크로써, 오픈소스이며 프로그래밍 언어로 파이썬(Python)을 사용했습니다. 파이썬이라는 언어는 개발을 도와주는 프레임워크가 없다면 굉장히 복잡하고 이해하기도 어렵습니다. 장고 웹 애플리케이션 프레임워크는 빠르고, 보안이 아주 뛰어나며, 다양한 용도로 사용할 수 있습니다. 이 프레임워크는 사이트 맵, 콘텐츠 관리, 사용자 인증 등을 자동으로 처리해주는 등 다양한 기능을 갖춘 것으로 유명합니다. 이 프레임워크 안에는 상당히 많은 보안 기능이 포함되어 있기 때문에, 클릭재킹(clickjacking)이나 SQL 주입공격(SQL injection)과 같은 일반적인 보안 상의 오류를 방지할 수 있게 도와주죠.

▷ ‘장고’를 사용한 웹 애플리케이션 프레임워크

디스커스(Disqus) – 온라인 커뮤니티 및 웹사이트에서 사용되는 블로그 댓글 호스팅 서비스
핀터레스트(Pinterest) – 레시피에서부터 인테리어 디자인 아이디어에 이르기까지 온갖 종류의 정보를 보관하고 검색할 수 있게 해주는 유명한 소셜 미디어 애플리케이션
인스타그램(Instagram) – 사진 및 동영상 공유에 주로 초점을 맞춘 소셜 네트워킹 서비스
쿼라(Quora) – 가입한 회원들 사이에서 정보를 모으고 공유하는 데 초점을 맞춘 질의 응답 사이트

앵귤러(ANGULAR)

원래는 앵귤러JS(AngularJS)라는 이름으로 알려져 있었던 앵귤러는 구글이 만든 환상적인 프레임워크입니다. 앵귤러는 개발자들이 관리하기 쉬운 대형 애플리케이션을 만드는 데 사용할 수 있는데요. 가장 주목할 만한 특징들 중 하나는, 크로스플랫폼 애플리케이션을 만드는데 사용할 목적으로 만들어졌다는 겁니다. 즉, 이 프레임워크로 만든 애플리케이션을 쓰는 사용자들은 자신의 스마트폰이든 데스크톱이든 어떠한 기기에서도 동일한 경험을 할 수 있다는 것입니다. 앵귤러가 제공하는 코딩 템플릿들은 자바스크립트(JavaScript)를 효율적으로 사용하기 위해 완벽하게 최적화 되어 있습니다.

▷ ‘앵귤러’를 사용한 웹 애플리케이션 프레임워크

넷플릭스(Netflix) – 사용자들이 다양한 기기에서 영화와 텔레비전 프로그램을 볼 수 있는 아주 유명한 스트리밍 서비스
포브스(Forbes) 웹사이트 – 투자, 비즈니스, 기업가 정신, 테크놀로지에 초점을 맞춘 전 세계적인 미디어 기업인 포브스의 웹사이트
구글 마케팅 플랫폼(Google Marketing Platform) – 웹사이트의 모든 트래픽을 추적하고 보고까지 해주는 웹 분석 서비스
구글 디지털 개러지(Google Digital Garage) – 온라인 마케팅 교육을 무료로 제공하는 구글의 비영리 학습 플랫폼

웹 애플리케이션, 가장 쉽고 안전한 방법으로 제작해보세요!

[출처] https://www.wishket.com/news-center/detail/550/

 148 total views

19 10월 2020

구글 프로덕트 매니저가 알려주는 기획서 작성 꿀팁

구글 프로덕트 매니저가 알려주는 기획서 작성 꿀팁

안녕하세요?

오늘도 PM분들에게 도움이 될만한 꿀팁을 가져왔습니다. 이번에 소개해드릴 글은, Lina L님이 각색한 “구글 프로덕트 매니저가 알려주는 기획서 작성 꿀팁”입니다.

원문, 작성자인 Omar Eduardo는 구글의 프로덕트 매니저로, WHY 기반의 기획서 형태인 PRD(Product Requirement Document)를 어떻게 써야할지 그리고 어떻게 활용해야 할지 현업의 경험을 토대로 꿀팁을 알려주고 있는데요.


우리 PM들은 예로부터(?) 기획서라는 이름 하에 수많은 형태의 문서들을 작성해왔습니다. 기능 요구정의서, 명세서, UX 설계 문서 등등.. 이름도 다양하고 형태도 다양하죠. PPT나 디자인 툴로 와이어프레임을 직접 그리기도 하고 에러 케이스부터 시작해서 세부 개발 요구사항들까지 꼼꼼히 기록하기도 하고요.

PM들이 과연 얼마나 상세하고 많은 분량의 기획을 해야 할지에 대해서는 서비스나 회사 특성, 개발 문화에 따라 달라집니다. 워터풀 방식의 몇개월 짜리 프로젝트라면 몇백장의 PPT가 될 수 있고, 애자일하게 작은 가설을 테스트하는 팀에서는 한장으로 충분할 수 있습니다.

소프트웨어 개발은 변동사항이 많고 또 우리는 고객에 대해 결코 백프로 이해하고 있지 않기에, 빠른 테스트가 가능한 애자일 문화가 확산되면서 ‘기획서’는 주로 HOW를 완벽하게 정의한 개발 요건 문서에서 목적, 즉 WHY에 초점을 맞춰 팀이 함께 HOW를 논의할 수 있는 토대로 변화하고 있는 것 같습니다.

프로덕트 매니저가 작성하는 PRD(Product requirement document)는 다음의 핵심 질문에 대한 답변을 위해 작성됩니다.

  • 우리가 이 기획을 왜 해야 하나요? (WHY)
  • 이 문제는 어떻게 접근해야 하나요? (HOW)
  • 가장 적합한 솔루션은 무엇인가요? (WHAT)

PRD의 중요한 목적은 올바른 제품을 만들고 사용자에게 잘 전달하기 위한 방향으로 팀이 함께 나아가도록 하는 것입니다. 잘만 활용된다면, PRD는 어떤 개발 프로세스를 따르더라도 훌륭한 제품 개발 도구가 될 수 있습니다. 이 글에서는 PRD를 최대한 활용하기 위한 몇가지 팁을 소개하고자 합니다.

PRD에는 무엇을 작성해야 하나요?

가장 기본적인 형태의 PRD는 다음의 섹션이 포함되어 있는 단순한 문서라고 볼 수 있습니다.

 

    1. 요약과 배경(Summary and Background) : 문제가 무엇이고 왜 이것이 중요한가요? 이 기획의 중요성을 강조하기 위한 사업 지표나 유저 리서치 내용 또는 여러 다른 인사이트를 포함시키는 것도 좋습니다.

 

  1.  

 

    1. 주요 사용자(Target Users) : 이 해결책은 누구를 위한 것인가요? 이 유저들은 왜 중요하며 이들의 불편함(pain points)을 우선순위를 높여 해결해야 하는 이유는 무엇인가요?

 

  1.  

 

    1. 핵심 사용자 여정(Critical User Journeys, CUJs) : 문제를 해결했을 때 사용자가 얻을 수 있는 것은 무엇인가요? 구체적인 솔루션보다는 사용자 니즈에 집중해서 작성해주세요.

 

  1.  

 

    1. 기능적 요구사항(Functional requirements) : 솔루션의 세부 기획을 작성합니다. PM으로서 기능적 요구사항을 상세히 쓰는 것은 중요하지만, 특정 솔루션을 너무 강요하지는 않도록 합니다.

 

  1.  

 

    1. 관련 문서(Supporting documents) : 솔루션의 세부 인터랙션 디자인이나 기술적 구현에 대해서는 디자이너, 엔지니어와 논의할 텐데요. PRD에 관련 UX 플로우 또는 개발 설계 문서를 추가적으로 연결해 참고할 수 있도록 해주세요.

 

  1.  

 

    1. 배포 계획(Go-to-market): 해당 기능 출시와 관련된 여러 고려사항과 출시 후 마케팅, 영업, CS 등 고객과 맞닿아있는 조직이 예상하고 있는 바에 대해 작성합니다.

 

  1.  

이 내용들은 PRD를 구성하는 가장 기본적인 사항들이지만, 이 외에 수많은 다른 고려사항들도 추가적으로 작성할 수 있습니다. 제가 일했던 팀에서는 PRD 템플릿에 권한 허용, 성능, 데이터 추출, 성공 지표, 플랫폼 간 호환성, 신규 사용자 접근성 등등 여러 다양한 내용이 포함되어 있었습니다. 일단 위에 제시된 기본적인 내용을 먼저 채운 다음, 협업하는 과정에서 나타나는 중요한 이슈들을 다루기 위한 새로운 섹션을 추가해보세요.

 

PRD를 잘 활용하기 위한 팁

팀원들의 피드백을 초기에 받으세요.

PM들은 종종 피드백을 받기 전 문서에 너무 많은 시간을 들입니다. 대신 초기부터 적극적으로 피드백을 줄 수 있는 UX 디자이너와 엔지니어를 찾아보세요. 세 가지 주요 질문(왜, 어떻게, 무엇을)에 대한 초안을 작성하고, 바로 공유하세요.

PM으로서 해야 할 가장 첫번째 일은 이 문제가 왜 중요하며 왜 우선순위를 높여 해결해야 하는지 팀원들에게 분명히 설명하는 것입니다. 하지만문제에 대한 솔루션은 엔지니어나 UX 디자이너와 협업하는 과정에서 정의되어야 합니다.초기에 자주 피드백을 받으면 시간을 낭비하지 않을 수 있습니다.

경험적으로 제일 좋은 방법은 처음 세 파트(summary and background, target users, CUJs)를 작성한 다음, 네번째(functional requirements)로 넘어가기 전에 피드백을 받는 것입니다. 문제나 사용자 여정에 대한 싱크가 안되어 있는 상태에서 특정 솔루션에 대한 기능적 요구사항을 정해버리면, 모두의 시간을 상당히 낭비하게 될 수 있습니다.

 

재미있고 읽기 쉬운, 구조화된 형태의 PRD를 만드세요.

좋은 PRD는 동료들이 불필요하게 많은 노력을 기울이며 읽지 않아도 중요한 정보를 적절하게 전달할 수 있어야 합니다. 이를 위해 다음 세가지를 주의하면서 PRD를 작성해보세요.

 

    1. 문제에 집중하기 : 너무 뻔한 내용이나 관계없고 필요없는 세부 내용은 지우고 문제에만 집중하세요. 초기에 피드백을 받아야하는 중요한 이유는 논점이 될 만한 부분이 어디인지 찾기 위함입니다.이렇게 찾은 논점을 깊이 파고드는 데 집중해서 팀이 앞으로 나아갈 수 있도록 하세요. 관련이 없고 뻔한 내용인데 단순히 문서 작업을 위해 뭔가 작성하라고 요청받았다면 과감히 부록으로 빼세요.

 

  1.  

 

    1. 한눈에 쉽게 읽을 수 있도록 구조화하기 : 동료들이 어떤 것에 관심있을지 생각하고 그 내용을 잘 찾을 수 있도록 구조화하세요. 제목과 부제목을 스마트하게 써서 주요 논점이 잘 드러나도록 하세요. 그렇게 하면 여러 팀의 동료들이 중요한 포인트에 빠르게 집중해서 인사이트를 줄 것입니다.

 

  1.  

 

    1. 와이어프레임이나 도식, 표 활용하기 : 글이 너무 많으면 지루해질 수 있습니다. 여러 옵션에 대한 비교를 하거나 전후 차이 설명 또는 데이터 흐름을 보여줄 때, 타임라인에 따른 고려사항을 논의할 때 등 다양한 상황에서 표나 차트, 목업을 활용해보세요. 추가적인 노력이 들 수 있지만, 명료하게 정리된 내용은 큰 이득이 됩니다. 동료들이 PRD의 정보를 쉽게 소화하여 반복적인 질문을 하지 않을 수 있게 될테니까요.

 

  1.  

 

PRD 기반으로 논의를 이끌어보세요.

만약 PRD가 흥미로운 지점에 초점을 맞추고 있고, 논점을 잘 기술하면서 중요한 솔루션을 다루고 있다면 논의에 불이 붙을 것입니다. 동료들에게 피드백과 커멘트를 남기도록 독려해주세요. 피드백을 리뷰하고 적절히 답변하는 것이 PM의 일입니다.

 

    1. 커멘트 확인하고 응답하기 : 커멘트에 동의한다면 그렇다고 알려주세요. 동의하지 못한다면 맥락을 설명하고, 놓치거나 잊고 있었던 부분은 없는지 확인하기 위한 질문을 해보세요. 이 과정을 통해 중요한 이슈나 의견 불일치를 파악하고 나아가 기획의 성공률을 높일 수 있습니다.

 

  1.  

 

    1. 자존심은 잠시 넣어두기 : 공들인 기획일 수록 누군가가 참견해서 비판적이고 무례하게, 또는 잘 모르는 채 커멘트를 남기면 짜증날 수 있습니다. 감정적으로 흥분한 상태로 반응하지 말고 차분해진 뒤에 응답하세요. 객관적으로 보면 유용한 내용을 발견할 수도 있습니다.

 

  1.  

 

    1. 중요하고 복잡한 사항은 미팅에서 논의하기 : 주요한 의견 불일치가 있다면 미팅을 잡고 해당 이슈를 다루어보세요. 논의할 주제를 명확히하고, 꼭 필요한 사람들만 초대하여 집중할 수 있도록 합니다.

 

  1.  

 

    1. 언제 어떻게 논의를 마무리할지 파악하기 : 방향이 정해지고 모든 관계자가 준비되었다면, 방해 요소나 범위/기능(scope/feature)의 변화를 반드시 최소화해야 합니다. 해당 솔루션이 모두의 동의를 받았다는 점을 PRD에 명시하는 것이 중요합니다. 저는 문서에 더 이상 적극적인 피드백을 받지는 않는다는 의미로 “Status: Final”이라고 남깁니다. 모든 새로운 커멘트나 제안에 대해서는 당사자에게 해당 피드백이 고려되었으나 왜 반영되지 않았는지 알려주세요. 친절하고 사려 깊게 답변하되 혼란을 줄이기 위해서는 분명히 해야 합니다.

 

  1.  

 

계속 반복하고 학습하세요!

저는 지난 6년 동안 수십개의 PRD를 작성했고, 매번 목적이나 팀 구성에 따라 PRD의 내용은 조금씩 달라졌습니다. 최종 결과물을 봤을 때 똑같은 PRD는 하나도 없었습니다. 하지만, 마지막 단계까지의 작성 과정은 유사했습니다. (초안을 쓰고 → 팀원들에게 피드백을 받고 → 디자이너, 엔지니어와 협력해서 최종 솔루션을 찾고 → 미팅에서 골치아픈 이슈들을 해결하고 → 최종적으로 마무리 짓기)

완결된 PRD는 최종적으로 적용된 솔루션뿐 아니라, 팀이 해당 솔루션에 도달하기까지의 전 여정을 담고 있습니다. 최종 목적에 도달하기까지의 여러 우여곡절을 담은 PRD는 학습과 개선을 위한 최고의 자산이 되어줄 것입니다.

[출처] https://www.wishket.com/news-center/detail/539/

 152 total views