안녕하세요,

골방에 쳐박혀 개발하길 즐기는 윤진입니다.


전 누군가를 멘토링할 정도로 훌륭한 사람이 아닙니다.

게다가 사색을 즐기는 지극히 내향적인 사람이기 때문에,

결단코 먼저 나서서 멘토링을 하지 않습니다.


하지만 왠일인지 지난 8월부터 SCSA 인력에 대해 멘토링을 하게 되었습니다.

이번이 아마 생애 처음이자 마지막으로 진행하는 SCSA 멘토링이겠지요.

멘토로 추천해주신 분의 언변에 홀라당 넘어간 것이 멘토링의 시작이었는데요,

앞으로는 넘어가지 않습니다! 후훗; :)


8월/9월/10월/11월

매달 초에 멘티들과 만났으니 이번 달이 네번째 만남입니다.

여느때와 마찬가지로 멘티들의 시험이 끝나는 날로 일정을 잡았었는데요,

이번 시험은 어찌된 일인지 다음주로 연기되었다고 하네요.

단기간에 소프트웨어 교육을 진행하다보니 여러가지로 사정이 생기겠지요.


SCSA는 '융합지향'의 소프트웨어 개발자를 양성하고 있으니,

멘티들에게 개발의 다양한 측면을 보여주고 싶었습니다.

그래서 첫번째 만남에서만 '개발'에 대해서 신나게 떠들고,

두번째 달부터는 '개발 외의 영역'을 보여주기 위해 여러 주제를 정해 진행하였습니다.

- SCSA 선배들의 진로

- 플랫폼 / 앱 기획

- UX 디자이너

- 개발 UX의 역할


그리고 마지막으로 이번 달에는 개발행사 총괄/기획/진행에 대해 주제를 잡았습니다.

개발자의 테크트리에 행사영역이 있다는 사실에 멘티들도 굉장히 흥미로워하더군요.


이 영역에 대해서는,

그저 개발자일 뿐인 제가 해줄 수 있는 얘기가 많지ㅎ 않습니다.


그래서 평소 개발자 행사에서 발표를 하며 여러가지로 도움을 받았던 조재민 책임연구원님께 부탁드렸습니다.

조재민 책임연구원님은 타이젠 데브랩 행사를 기획 & 진행을 해주신 분이신데요,

SCSA의 취지를 이해하시고 적극적으로 나서주셨습니다.

이 자리를 빌어 감사하단 말씀을 전하고 싶습니다.


조재민 책임연구원님은 개발자 행사를 기획 & 진행하기 위해,

기술에 대한 리더십 뿐만 아니라 외국어에도 능통해야한다는 조언을 해주셨습니다.

외국어에 대한 부분에서 심히 뜨끔하며 격하게 공감되더군요;


그리고 깜짝 손님으로 오픈소스그룹장 한지연 수석연구원님을 초빙해주셨습니다.

아... 평소에 만나뵙기도 힘든 거물이신데,

마지막 멘토링에 유종의 미를 거둘 수 있게 자리를 빛내주셨습니다.


왼편부터 조재민 책임연구원, SCSA 최수웅, SCSA 조예나, 한지연 수석연구원

SCSA 김기현, SCSA 이우진, SCSA 홍소희 그리고 개발자 한분;


한지연 수석연구원님은 개발영역에서 기반을 다지시고,

수년전 사내에서는 다소 생소했던 오픈소스분야를 개척하셨습니다.

초기에는 오픈소스를 가져다가 이용하는 사용자 입장에서 오픈소스를 다루셨지만,

이제는 오픈소스에 컨트리뷰션하고 나아가 리딩하도록 최전방에서 이끌고 계십니다.

Tizen Developer Conference나 Samsung Developer Conference를 총괄하고 계시고,

("[Tizen] TDC 타이젠 개발자 회의 2015 선전 개최" 포스팅 참고)

얼마 전에 1차 예선이 치뤄진 SCPC도 총괄하고 계십니다.

("[대회] SCPC 삼성 대학생 프로그래밍 경진대회" 포스팅 참고)

흥미로운 이야기거리가 잔뜩 준비되어계신 분이라 그냥 보내드릴 수는 없었습니다.


똘똘한 멘티들과 합세하여 열심히 질문공세를 날렸고,

그 중 뼈에 새길만한 이야기를 여기에 남깁니다.

개발자 모두에게 하는 조언도 있고 SCSA에 타게팅된 대답도 있습니다.

녹음을 하지 않은 것에 한탄하며,

조악한 기억력을 짜내보도록 하겠습니다.


질의응답은 크게 아래 카테고리로 진행되었습니다.

- 개발자로서 어떤 족적을 남기며 살아오셨는지 

- 지금은 어떤 일을 하고 계시는지

- 힘들었던 점은 무엇이 있는지

- 어려움을 극복하는 방법이 무엇이었는지

- 우리가 가는 길이 맞는 길인지


한지연 수석연구원님의 경력은 사무실 안에서 흡연이 허용되던 시대까지 거슬러올라갑니다.

비행기나 버스처럼 밀폐된 공간에서조차 흡연이 가능했던 시대였으니,

금연아파트가 등장하는 요즘 기준으로 봤을때는 꽤나 먼 과거입니다.


전산계열 전공을 하신 후 동양, KT를 거쳐 삼성전자에서 개발자의 길을 걸으셨습니다.

(동양이라고 언뜻 들었는데 요즘 가는귀가 먹어서 잘못 들었을 수도 있습니다;)

Software Engineering 분야에서 개발을 위한 툴을 개발하시며,

프로그래머 더 나아가 아키텍트로의 소양을 쌓으셨습니다.


이 정도까지 경력을 쌓았으면,

자기계발 못지 않게 기술전파에도 무게를 실어주어야겠지요?

SE의 특성상 본사 개발자들을 위해 수많은 기술전파교육을 맡아하셨을겁니다.

거기에 더불어 해외연구소에도 파견을 가셔서 본사의 기술을 이식하셨겠지요.


해외연에도 똘똘한 연구원들이 굉장히 많지만,

본사의 기술전파로 해외 연구원들의 성장판에 탄력을 줄 수가 있습니다.

인도와 중국 등에 위치한 연구소에 아키텍트 과정을 비롯하여 개발 과정 전반을 이식하셨다고 합니다.

그 때 성장한 인도와 중국 연구원들이 이번 TDS와 TDC 행사에서 발표자로 맹활약을 할 수 있었죠.


해외연구소 생활을 마치고 복귀한 후부터 오픈소스를 맡으셨습니다.

그 당시에는 오픈소스에 대한 인식이 지금과 같지 않았기에,

고작 한 줌의 연구원들과 함께 오픈소스 전반을 다루셨겠지요.

사내플랫폼에서 사용하고 있는 오픈소스에 대한 관리가 주업무였을겁니다.

하지만, 이제는 오픈소스에 코드를 직접 컨트리뷰션할 수 있도록 길을 터주시고,

나아가 오픈소스그룹에서 기술을 선도할 수 있도록 발판을 마련해주고 계십니다.


거기에 더불어 현재는 삼성전자에서 하는 대규모 외부개발자 행사를 총괄하고 계시는데요,

개발자 행사기획에 관심있는 SCSA 멘티들에게 의미있는 조언을 해주셨습니다.


개발행사기획은 개발자를 대상으로 하는 행사를 기획하는 일입니다.

그렇기 때문에 개발자와 기술을 철저히 이해해야 합니다.

참여자와 발표내용을 이해하지 못하는데 행사를 제대로 진행할 수 있을리 없습니다.

따라서 개발행사기획은 개발영역에서 탄탄한 기반을 닦고 난 후에 해야 합니다.

최소 3~4년 개발을 하며 개발에 대한 감각과 노하우를 익히세요.

개발에 대한 깊이가 없는 개발기획은 그저 기획과 다를바 없습니다.

기획은 개발자가 아닌 다른 영역에 있는 사람들도 할 수 있습니다.


이왕에 소프트웨어 개발자가 되었으니,

장차 어느 테크트리를 타든 소프트웨어 개발을 최소 3~4년을 해야한다고 멘티들에게 이야기했었는데요,

한지연 수석연구원님께서 정확하게 다시 지적해주셨습니다.

일만시간의 법칙을 거들먹거릴 필요없이 3~4년의 기간을 거쳐야만,

얼추 한 사람의 개발자몫은 능히 해내는 수준이 될겁니다.

형편없는 실력의 개발자도 이 기간을 잘 거치면 훌륭한 개발자로 괄목상대할만큼 성장하게 됩니다.


지금의 길에 다다르기까지 수많은 어려움이 있으셨을텐데요,

여성개발자로서 가사와 병행하기 힘들지 않으셨냐는 질문에는,

"가족들이 많은 부분에서 희생을 해주었습니다."라고 답하셨습니다.


남편보다 늦게 퇴근하는 날이 태반이었습니다.

아이들은 왜 시험기간에만 출장을 가느냐고 하기도 했습니다.

하지만, 벌써 수능을 볼 정도로 잘 자라주었습니다.


이런 질문은 여러 곳에서 많이 들으셨겠지요.

다소 담담하게 대답해주긴 하셨지만 감당하기 힘든 순간도 있으셨겠지요.


어느 사회나 그렇듯,

상대가 여자이기 때문에 무턱대고 들이대는 잘못된 잣대가 있습니다.

개발영역에서도 마찬가지입니다.

여성 개발자라는 이유로 근거없이 무시하는 개발자가 있습니다.

그런 개발자의 선입견은 쉽사리 고쳐지지 않습니다.

그렇기 때문에 여성개발자로 살아가는게 그리 녹록치만은 않습니다.

결국 스스로 이겨내어야 하는 부분이 있겠지요.


어려움을 극복해내는 방법으로 가장 간단하지만 가장 강력한 방법을 추천해주셨습니다.

어려움에 봉착했을때 저 역시도 자주 사용하는 방법입니다.


자신의 고민을 털어놓을 수 있는 동료가 필요합니다.

"임금님 귀는 당나귀 귀" 얘기처럼,

맘 속 깊은 곳에 있는 얘기를 꺼내놓으면 그것만으로도 위안이 됩니다.

몇 년 전만 해도 그런 이야기를 나눌 수 있는 여자 동료들이 많았었는데요,

지금은 많이 줄어들었습니다.


마지막으로 제가 다소 맹랑한 질문을 드렸습니다.

"타이젠에 미래가 있다고 생각하시나요?"

우문에 현답으로,

"제겐 종교와 같습니다."라고 답해주셨습니다.


저 역시 마찬가지입니다.

타이젠에 제 젊음 또한 고스란히 들어있습니다. :)

그럴듯하게 만들어놨으니 많은 개발자들이 맘껏 놀고 가길 희망합니다.


한참을 적어놓고 보니,

실제로 한지연 수석연구원님께서 하신 발언과 다를 수도 있겠다는 생각이 들기도 합니다.

그 부분은 그저 제 허물일 따름입니다.


좋은 말씀해주신 한지연 수석연구원님께 감사드립니다.

그리고 더불어 부족한 멘토링을 장장 4개월 동안 인내심으로 감내해준,

김기현, 이우진, 조예나, 최수웅, 홍소희 멘티들에게 감사의 마음을 전합니다.

우면에서 봅시다.


끝_


늘상 그렇듯,

오늘도 일개 개발자로서 체감하는 개발현실을 얘기해볼까 합니다.

'일개 개발자'로서의 생각이기 때문에 코끼리의 꼬리만 만지고 있다고 생각하셔도 무방합니다.


Man-Month는 한 사람이 한 달간 하는 일의 규모를 토대로,

프로젝트에 투입할 인력과 일정을 계획할 때 사용합니다.


10명이 1년간 프로젝트를 진행해야하면,

10명 x 12개월 = 120 M/M(Man-Month)

120 M/M 규모의 프로젝트라고 말할 수 있습니다.


프로젝트에 투입한 사람을 좀 더 늘려볼까요?

120 M/M 프로젝트에 12명을 투입하면,

120 M/M / 12명 = 10개월

12개월에서 10개월로 2개월이 줄었습니다.


이 수식에는 한가지 전제가 필요합니다.

투입되는 인력의 수준이 동일하다는 전제이지요.


하지만, 소프트웨어 개발에 발담고 있는 동안,

여실히 깨달은 사실은 개발자 간에 수준이 천차만별이라는 것입니다.


초보개발자와 고급개발자 간의 차이가 20배가 넘는다는 글을 읽은 적도 있습니다.

입사 직후에 정말 아무 것도 몰랐던 저와

여전히 아무 것도 모르는 지금의 저만 비교해봐도

20배는 가뿐히 넘는 것처럼 느껴집니다.


소프트웨어 개발은 제조의 영역과 예술의 영역 사이 어디쯤 위치하기 때문에,

초보개발자와 고급개발자 간의 차이가,

제조업계의 비숙련공과 숙련공의 차이보다는 월등하게 크고,

연습생과 천재 아티스트 간의 차이보다는 좀 작을 거라 생각합니다.


게다가 때로는 대체불가능한 사람이 있습니다.

그런 히어로 개발자들은 개발자들 사이에서는 천재 아티스트와 맞먹는 파급력을 지닙니다.

초보개발자와 히어로 개발자의 간극은 거의 무한대에 가까울 거라 생각합니다.


왜냐하면, 히어로 개발자의 기발한 발상은,

히어로 개발자가 아니면 도출해낼 수 없는 직관의 비약에서 나오기 때문입니다.


제가 일하는 곳에서도,

히어로 개발자 다섯 분이 있습니다.

무려 다섯 분이나 있다는 사실 자체에 놀랍기도 하고 행복하기도 합니다.


약간의 사례를 소개해보겠습니다.

외부 개발자가 사용할 수 있게 API를 설계하는 시간이었습니다.

기존 담당자는 견고하게 구축되어있는 아키텍쳐를 언급하며,

현 아키텍쳐를 기준으로 다음 버전을 준비하고자 하였습니다.

지극히 논리적이고 합리적이었습니다.

히어로 개발자가 딴지를 걸기 전까진요.


히어로 개발자는 기존 담당자의 논리를,

실제로 API를 사용하는 개발자가 불편할 수 있다는 논리로 깨버렸습니다.

히어로 개발자가 원하는 '사용하기 편한' API를 준비하기 위해서는,

오랜 전통을 가지고 있는 아키텍쳐를 전부 바꿔야했습니다.

그렇기 때문에 담당자는 굉장히 강하게 거부의견을 펼쳤습니다.

그렇지만, 히어로 개발자는 그 어느때보다 단호한 고집으로 자신의 주장을 관철했습니다.


아키텍쳐보다 사용자 편의가 우선한다는 히어로 개발자의 의견에 전적으로 동의합니다.

아키텍쳐 따위야 언제든지 바꿀 준비가 되어있어야 합니다.

아키텍쳐가 중요하지 않다는 얘기는 아닙니다.

당연히 아키텍쳐는 소프트웨어 개발에 근간이 됩니다.

하지만, 아키텍쳐보다 중요한게 있습니다.

바로 실제로 소프트웨어를 사용할 사람들이지요. :)


물론 사용자 요구사항은 천차만별입니다.

경우에 따라서는 자신이 요구하는게 뭔지 모르는 경우도 있습니다.

따라서, 요구사항을 비판적으로 가려낼 수 있는 합리적인 절차가 필요합니다.

그 부분에 대한 논의는 다음으로 미뤄두겠습니다.


또 다른 예도 있습니다.

라이브러리 A에서 DB가 필요한 경우가 있었습니다.

라이브러리 A에서 DB 파일을 열고 read / write 해야만 할까요?

그렇게 되면 라이브러리를 사용하는 프로세스에서 DB에 직접 read / write 하게 될지도 모릅니다.

자칫하면 DB에 있는 table을 drop할 수도 있겠지요.

그걸 방지하기 위해 서버-클라이언트 구조를 차용하여,

클라이언트에서 서버에 DB 오퍼레이션을 요청하고,

서버에서는 인증된 오퍼레이션에 대한 동작을 처리하도록 구조를 잡지요.


하지만, 히어로 개발자는 라이브러리 A에서 직접 서버-클라이언트 구조를 만드는 것 대신,

컴포넌트 B에서 마침 사용 중인 서버-클라이언트 구조를 절묘하게 이용하는 것을 제안합니다.

컴포넌트 B의 역할상 라이브러리 A가 기생해도 아무 문제없는 구조였습니다.

히어로 개발자의 제안으로 플랫폼은 불필요한 프로세스를 만들지 않았습니다.


히어로 개발자들의 고집과 발상은 대체불가능합니다.

소프트웨어 개발업체에서 하는 가장 큰 착각은,

이런 히어로 개발자를 부속품 갈아끼우듯이 교체할 수 있다는 겁니다.

아직 제 경험이 미천하긴 하지만,

제 경험상 히어로 개발자는 교체할 수 없습니다.

히어로 개발자를 바꾸면 소프트웨어는 다른 모양으로 변하게 됩니다.

소프트웨어가 원래 가고자 했던 방향으로는 더 이상 갈 수 없습니다.


이 글의 시작은 Man-Month였는데요.

결론은 "히어로 개발자는 대체불가능하다" 정도가 되겠네요.

히어로 개발자는 제조영역 종사자라기 보다는 예술영역 종사자라고 보는게 맞습니다.


애초에 피카소나 샤갈을 다른 사람으로 대체할 수 있다는 정신나간 소리를 하는 사람이 있나요?

히어로 개발자들도 마찬가지입니다.


히어로 개발자가 많아져 소프트웨어 업계 전반의 개발자에 대한 인식이 바뀌면 좋겠습니다.

끝_

  1. 코코콩 2015.10.13 14:00 신고

    초보개발자인 저조차도 현재에서 +@를 하려고 생각만했는데요...
    글을 보니 반성하게 됩니다. 언제나 감사합니다,

    • 하지만,
      그럼에도 불구하고,
      왠지 코코콩님은 저보다 나으실거란 생각이 듭니다. :)
      저야말도 언제나 감사드립니다.

  2. amaze_ 2015.10.13 19:25

    왠지 히어로 개발자이실것만 같습니다. 명쾌한 글 잘 보고 있습니다

    • 안녕하세요, amaze_님.
      처음 뵙겠습니다~
      히어로 개발자가 아니라서 안타깝습니다;
      더 재미난 글을 쓰도록 부단히 노력해야겠네요.
      감사합니다!


대규모 소프트웨어를 개발을 위해,

노련한 개발자들이 치밀한 계획을 수립한다고 해도,

계획을 구성하는 각각의 요소들이 조금씩 틀어지기 마련입니다.

스펙, 일정, 역할, 인원, 우선순위, 작업방식, 리더, 구성원...

바뀌지 않는 것은 '계획이 틀림없이 바뀔 것이다'라는 구성원들의 믿음 정도일 겁니다.


계획을 수립하는 순간,

매일매일 계획이 틀어지는 것을 지켜보는 것은 상당한 스트레스입니다.

그래서 아예 계획보다 변화에 대응하라고 조언하는 애자일 선언문이 더욱 그럴듯해 보입니다.


http://agilemanifesto.org/


위의 선언문은 2001년 미국 유타주에서 개발자 몇 명이 만든 애자일 소프트웨어 개발 선언입니다.

미국에서는 14년 전에 나왔고,

한국에서는 2000년대 중반에 소개되었습니다.


http://agilemanifesto.org/iso/ko/


위의 사이트에서 한국어버전도 찾아볼 수 있습니다.

영어, 한국어 말고도 온갖 언어로 번역되어 있습니다.

그만큼 여러 나라에서 인기를 끌고 있다는 것이겠지요.


애자일이 강조하는 요소는,

- 개인과 상호작용

- 소프트웨어 자체

- 고객과 협력

- 변화에 대응

위의 구문들만 보면 문제될 것은 없습니다.


하지만, 위의 요소를 기존에 중요하다고 여긴 가치와 비교하여 좀 더 파괴력을 가졌지요.

- 공정과 도구

- 문서

- 계약협상

- 계획

위의 단어들은 프로젝트를 진행할때 너무나 중요한 단어들입니다.

저 단어들과 상반되는 룰을 프로젝트에 적용하는 것은,

프로젝트를 위험에 빠뜨리는 무모한 요인처럼 느껴질 수도 있습니다.


물론, 고작 열 손가락 안에 드는 인원으로 개발하는 프로젝트에는,

아무 어려움 없이 무모하게 스크럼을 짜서 스프린트할 수 있습니다.

(스크럼이나 스프린트는 http://storycompiler.tistory.com/137 참고)

실제로 스크럼을 짜서 업무성과가 수직상승한 예는 주변에 널려 있습니다.


하지만, 대규모 프로젝트에서도 가능할까요?

막강한 의사결정권자와 촘촘한 중간관리자가 포진해있는 관료조직은,

정형화된 조직구조와 고착화된 시스템운용방식이 있을텐데요,

애자일 개발방법으로 전환하면 여러가지 파격적인 시도들이 이뤄질 겁니다.


우선 거대 프로젝트를 많아야 열명 남짓한 작은 프로젝트 수십개 혹은 수백개로 쪼개는게 좋겠네요.

그리고 각 프로젝트 별로 참여자를 뽑아야겠죠.

(뽑는 방식을 고민하는 것도 즐거운 일이겠네요)

그 중에는 디자이너와 개발자와 평가자가 한팀이 되어 활동하는 프로젝트도 있을테고,

고객이나 경영자가 한 팀으로 참여한 프로젝트도 있겠죠.

이런 방식으로 문제에 기민하게 대응하게 되어,

좀 더 좋은 소프트웨어를 개발할 확률이 높아집니다.

물론, 팀은 해체되고 조직의 구성원이 뒤죽박죽이 되니,

인사권이나 평가권에 큰 변화가 있겠네요.


각각의 프로젝트에는 독립적인 위상이 부여되고,

일방적인 명령하달에 의한 개발우선순위 변경은 없어져야 할 겁니다.

프로젝트의 운명을 결정하는 것은,

프로젝트에 참여하는 사람들에게 주어질 것입니다.

프로젝트에 대해 가장 잘 아는 사람에게 결정권을 주면,

좀 더 좋은 소프트웨어를 개발할 확률이 높아진다고 믿습니다.


연중 계획은 의미가 없어지고, 매달 계획이나 그보다 작은 단위의 계획과 실천이 중요하겠죠.

개략적인 방향으로서 연중 계획은 필요하겠지요.

수많은 프로젝트가 함께 유기적으로 행동해야하는 경우라면,

일정과 내용에 대해서는 모두의 합의가 있어야하니까요.

하지만, 세부적인 계획과 실천은 짧은 사이클을 타며 기민하게 동작하는게 좋겠죠.

그 편이 좀 더 유연한 소프트웨어를 개발할 확률이 높아질테니까요.


중간관리자의 역할은 여러가지 측면에서 바뀔지도 모르겠네요.

프로젝트에 직접 참여하는 중간관리자는,

노련한 개발자로서 활동하게 되겠지요.

아키텍쳐를 그리고 코딩을 하면서 프로젝트에 직접적으로 기여할겁니다.

프로젝트를 관리하는 중간관리자는,

다수의 프로젝트의 애로사항을 체크하여 개발에 장애가 되는 요소를 없애줘야겠지요.

그렇게 해야 소프트웨어 개발에 박차를 가할 수 있겠지요.


평가는 프로젝트에 참여한 사람들이 다면적으로 진행할 수 있겠네요.

프로젝트의 성공을 위해 다음에도 함께하고 싶은 사람이 있을테고,

반대로 함께하면 안되는 사람도 여실히 드러날 수 있습니다.

언제나 평가와 관련된 부분은 조심할 수 밖에 없기 때문에,

여기서 함부로 논의할만한 주제는 아닌 것 같네요.

하지만, 어쨌든 프로젝트가 끝나고 다음 프로젝트가 계속될 때도 함께한다면,

그 구성원은 서로를 신뢰하고 믿는다는 증거이겠죠.


대규모 프로젝트에 언제나 완벽한 판단을 하는 천재가 있다면,

그 사람의 견해를 언제나 따르면 됩니다.

하지만, 그런 사람이 없다면,

수평적인 의견을 종합하여 의사결정을 하는 방법도 고민해봐야합니다.

대규모 프로젝트에 있는 수많은 소규모 프로젝트의 구성원 모두가 의사결정에 보탬이 되면 좋겠죠.

투명한 정보공개에 자유로운 의사표현이 더해져,

좀 더 나온 결과를 선택하여 더 나은 소프트웨어를 개발할 확률이 높아지겠죠.


어쨌든 대규모 프로젝트에 애자일을 적용하는 것은 쉬워보이지 않습니다.

특히 관료화된 집단에는 집단의 이익과 대치되는 변화가 필연적으로 따라오기 때문에,

자기파괴를 통한 재탄생이 쉽지만은 않겠죠.


성공적으로 거대집단에 애자일 프로세스를 적용한 사례를 찾아봐야겠네요.

각각 집단의 관습에 따라 수많은 수정버전이 있겠군요.


이 모든게 더 나은 소프트웨어를 만들기 위한 고민이라고 생각합니다.

고민의 결과를 조금씩 실생활에 적용해보고 시행착오를 겪으면,

경험적으로 더 나은 방법을 찾을 수 있으리라 생각합니다.


끝_

+ Recent posts