활동내역.zip/개인

같은 개발자에게서 클린코드 컨퍼런스를 두 번 듣고온 프론트엔드 엔지니어 꿈나무가 생각하는 클린코드란?

728x90

'클린 코드'가 코드에 대한 책이 아닌 사실에 대하여

책이 아니라고요? 그렇다네요.

왜 두번이나 다녀왔어요?

오늘은 학교에서의 회의를 마치고 클린코드에 대한 2번째 컨퍼런스에 다녀왔습니다.
첫 번째는 11월 22일에 다녀왔던 GOORM COMMIT에서, 그리고 두 번째는 오늘 다녀온 튜링의 사과에서 진행된 강연이었습니다.
첫 번째 클린 코드 관련 강연에 갔을 때에는 클린코드가 무언인지 궁금해서 갔고, 그리고 두 번째는 그래서 코드를 어떻게 대해야 하는 지 궁금했기에 다녀왔습니다.
물론 두 곳 모두 왕복 약 80정거장이라는 정말 긴 거리를 다녀오긴 했지만, 그래도 처음과 두 번째가 모두 얻어가는 것이 있었습니다.

결론부터 말씀드리자면 클린코드에 대한 생각 뿐만 아니라 코딩을 대하는 근본적인 생각까지도 변화했다고 볼 수 있습니다.
이 글은 과연 클린코드가 무엇인지, 그리고 이걸 어떻게 대해야 하는지에 대해 2번의 같은 주제의 컨퍼런스를 듣고 작성한 글임을 알립니다.

그리고 판교는 예뻤습니다

이것이.. 판교? 너무 도시가 예뻤어요. 확실한건 여기 살면 매일 자전거 타러 나올 수 있습니다.
물론 날씨이슈가 있다면 조금 힘들겠지만요

튜링의 사과(in 뚝섬)도 예뻤습니다

강연을 진행하신 박성철 개발자님과 함께 찍은 사진입니다! 두 번 뵙고 찍어서 그런지 기분도 두 배로 좋네요

튜링의 사과는 서점 + 작업공간이 공존하는 그런 느낌이었는데 분위기가 너무 좋았습니다.
보증금 환급 혹은 작업공간 종일 이용권을 선택할 수 있었는데, 2시간정도 걸리는 거리로 인해 환급을 받아 조금 아쉬웠네요

환급금으로는 맛있는 붕어빵을 사먹어야겠어요.

요즘 클린코드 핫합니다. 그렇지 않나요?

요즘 클린코드는 굉장히 많이 퍼져있는 개념입니다. 개발을 시작한지 1년도 되지 않은 저에게도 친숙한 것을 보면 정말 그렇죠.
클린코드가 어떻게 해서 유명해졌을까 궁금했었는데, 아래와 같은 과정을 통해서 유명해지지 않았을까 싶네요.

코딩의 미래: AI가 발전하면서 코딩은 필요없어지지 않을까?

코딩은 "요구조건을 상세히 표현하는 것"이다. 그리고 코드는 "그 조건을 표현하는 수단이다."

이 말은 무슨 소리일까요? 코딩은 요구조건을 상세히 표현하는 수단입니다. 그렇기에 아무리 AI가 발전한다고 해도 사라지지는 않을 겁니다.
이전까지만 해도 저는 GPT와 같은 AI가 계속해서 발전하다보면 어느 순간 코딩이 필요가 없는 세상이 오지 않을까 싶었습니다.
하지만 컨퍼런스 이후로는 이 생각이 변화하였는데, 이는 다음과 같았습니다.

코드는 결국 받아온 요구조건을 상세하게 표현하기 위한 수단으로 요구조건을 아무리 AI라 하더라도 도움은 될 뿐 결국 이를 다루는 사람이 반드시 필요하기 마련입니다. 그래서 개발자는 사라지지 않을 것이며, 이러한 요구조건을 상세하게 구현해내며 일어나는 모든 문제를 해결하는 "해결사"의 역할로 남아있지 않을까 싶습니다.

그래서 "코더"는 예전과는 다른 의미를 띄게 됩니다.

우리가 생각하는 코더, 그저 코드만 입력하는 사람이었죠.

기존에 깔려있는 인식을 살펴봅시다. 코더란 무엇일까요? 아마 많은 분들이 생각하시기에 "부여된 요구조건을 그대로 코드로 옮기는 사람"이라는 그저 주는 대로만 구현해내는 쉬운 일만을 하는 사람이라고 보실 수도 있습니다.
하지만 여기서 말하는 코더는 설계하는 사람으로서의 코더입니다. 우리가 흔히 생각하는 개발자인것이죠.

이미 생성형 AI들이 등장함에 따라 단순히 주어진 태스크들을 수행만 하는 역할들 대부분이 대체되었습니다. 그러면 다른 역할이기도 했던 기존에 프로그램에 대한 설계를 하고 실제로 코드로 옮겨내는 작업들이 개발자들의 주 업무로 변화하기 시작했습니다.

개발자는 예전과 다르게 어떻게 바뀌었을까요?

간단합니다. 개발자는 이제 설계하는 것에 더 많은 시간을 쏟게 되었습니다!

간단하고 반복적인 코드작업들을 더 이상 하지 않아도 되면서 개발자들을 더욱 좋은 설계, 그리고 더욱 좋은 코드를 위한 방법에 집중하기 시작했습니다. 이전까지는 어떻게든 코드를 옮기기만 했던 시간들이 대부분이었다면, 이제는 코드를 어떻게 더 효과적이고, 성능 좋고, 확장성이 좋도록 작성할 수 있을까에 대한 고민을 하기 시작했습니다.

그렇게 설계에 대한 중요성, 좋은 코드에 대한 중요성이 드러나기 시작하면서 "클린 코드"에 대한 관심이 증가해 왔습니다.

그런데, 클린코드는 결국 리팩터링이 아닌가요?

우리는 르블랑의 법칙과 보이스카우트의 법칙을 알고 있다.

클린 코드를 알고 있다면 유명한 두 가지 법칙을 떠올리실 수 있습니다. 한 가지는 르블랑의 법칙이고, 다른 하나의 법칙은 보이스카우트의 법칙입니다.

르블랑의 법칙: 나중은 결코 오지 않는다. 지금 좋은 것을 사용하라
보이스카우트 규칙: 언제나 처음 왔을 때보다 깨끗하게 해놓고 캠프장을 떠날 것

이런 법칙들을 통해 보았을 때 아얘 처음부터 코드 작성 시작 단계에서부터 완전히 깨끗하게 하는 것이 가장 이상적인 프로그램이다? 라는 생각으로 인해 "아, 일단 정말 신중하게 엄청 잘 설계해두고 코드를 만들어야겠다"라고 생각할 수도 있을 것입니다. 그리고 그것이 바로 클린코드가 아닐까 하는 생각도 들고요.
하지만 어떤 방법이 좋은 설계일 지 잘 모를 뿐더러 현실 세계에 퍼져있는 수많은 유동성 가득한 문제상황들은 이런 완벽한 설계를 한순간에 완벽하지 않은 설계로 만들어버리기도 합니다.

이렇게 생각해보면 어떨까요? "왜 '일단 돌아가는 쓰레기부터 만들어라'라는 말이 등장했을까?"

일단 돌아가는 쓰레기부터 만들어라

일단 돌아가는 쓰레기부터 만들어라. 이 말은 결국 일단 현 상태에서 문제를 이해한 수준으로 먼저 만들라는 말과 같다.

어떤 문제던 사람이 한번에 이해할 수 있는 일정 수준은 정해져있다고 생각합니다. 특히 지금의 저와 같은 개발을 배워나가는 학생의 경우는 더더욱 그러하죠. 그렇기에 처음부터 뭘 따로 설계하고 잘 짜려고 하는 것보다는 그저 코드를 만들어서 잘 돌아가는 것을 확인하고, 그 후 이해되는만큼만 나눠서 더 좋게 만들고, 그것을 반복하는 것이 더 좋은 방법이지 않을까 하죠.

요즘 말하는 개발자, 프로그래머의 역할이 설계자쪽에 점점 가까워지면서 처음부터 좋은 설계를 해서 잘 만들어야 할 것만 같은 그런 추세를 보이고 있습니다. 거기에는 요즘 많이 팔리고 있는 클린 코드와 관련된 책들도 들어가있죠. 예를 들어서 클린 코드가 아니라면 개발을 하지 않으려는 사람도 있을 것이고, 처음부터 코드를 잘 짜면 리팩터링을 안해도 되는 것 아니냐는 것이죠.

어느정도 맞는 말입니다. 레거시 코드에 상당히 많은 사람들이 고통을 받고 있기도 하고, 처음부터 완벽한 코드를 작성하면 리팩터링을 할 필요도 없으니까요.

하지만 이 말이 정말일까요? 저희는 정말 간단한 요구조건이 아닌 이상 현실과 연관되어있는 그 어떤 문제에 대한 요구조건을 명확하게 이해하는 것을 어려워합니다. 현실은 수많은 변수들로 구성되어있고, 변화하는 변수들을 모두 예상하고 코드를 짜는 것이란 불가능에 가까우니까요.

그리고 리팩터링 하라

돌고돌아 나온 다음 방법은 이겁니다. 그리고 리팩터링을 하는 겁니다!

그렇게 다시 돌고 돌아서 리팩터링을 하는 것이 방법이라는 방향으로 나아가고 있습니다. 코드라는 것은 처음부터 만들어지는 "공산품"이 아닌 계속해서 자신을 포식하고 성장하는 "생물"과 같으니까요. 많은 분들이 헷갈리시는 것들 중 하나가 바로 이 "리팩터링(refactoring)"이라는 것의 어원입니다.

그렇다면 이 리팩터링은 무엇이길래 어디서부터 그 개념이 의도와는 다르게 전파된 것일까요?

리팩터링, Factory가 아닌 Factoring!

리팩터링에서의 Factoring은 우리가 알고있는 Factory와는 그 의미가 다릅니다.

우리가 알고있는 그 리팩터링을 생각해볼까요? 가장 친숙한 단어인 Factory가 떠오르실 겁니다. 그래서 "아, 그래서 Factory니깐 잘 만드는, 공장에서 만들어내는 그런 느낌으로 새로운 코드를 짜는거구나!" 라고 인식하고 있으실 텐데요, 단어부터 다시 살펴보고 가볼까요?

먼저 Factory는 공장, 그리고 같은 어원이긴 하지만 Factoring은 인수분해를 의미합니다. 엄연히 다른 뜻이 되었죠.

정말 그렇습니다. 인수분해를 의미하기에 이를 코드에 적용해본다면 문제를 분해하고, 다시 결합하는 과정을 나타냅니다.
그말인 즉슨, 같은 의미를 뜻하는 단어인 decomposition이라는 말로도 나타낼 수 있으며 "재설계"라고 번역할 수 있습니다.
처음에 이렇게 번역되어 들어왔다면 덜 헷갈리지 않았을까 싶기도 하네요.

리팩터링을 하기 위해서는 무언가 만들어진 코드베이스가 필요하다는 것이고 그걸 이해하는 순간 적용하면 된다는 겁니다!
그런데 한가지 의문점이 있습니다. 코드 짜기에도 바쁜데, 리팩터링은 언제 하는 것이 좋을까요?

코딩비둘기로 살펴보는 "언제 리팩터링을 해야하는가?"

리팩터링은 눈에 보였을 떄 하는게 가장 좋습니다. 날 잡고 하기보다는 코드 보다가 조금씩 수정해나가는 것이지요.

사실 새로운 기능을 작성하다가도 눈에 보이면 코드를 살짝 수정해두는 것이 리팩터링이고, 코드를 작성하다가 반복적으로 고통을 받으면 그때 리팩터링을 하기도 하고, 정말 다양합니다. 저도 겪어본 일이지만 날 잡고 리팩터링한다고 그러고 있다가 결국 제대로 무언가를 하지도 못하고 끝난 적도 많았기에 정말 추가적으로 코딩을 하다가 발견한 문제가 있으면 그때그떄 수정해두는 것이 좋은 방법이 아닐까 싶습니다.

그 비둘기 짤이 있죠. 이걸로 비유를 해볼게요.

저희는 비둘기를 개발하는 개발자로서 "비둘기를 날도록 만들어라"라는 요구조건을 받아 개발하기 시작했습니다. 나머지 요구조건은 따로 없기에 저희의 일은 "날도록 만들어라"라는 문제를 어떻게든 해결하는 것이죠.

어떻게든 비둘기를 "날도록" 만들었습니다. 요구조건대로 날아가긴 합니다. 다만, 머리가 돌아가면서 헬리콥터처럼 날아가죠. 이럴꺼면 대나무 헬리콥터를 달아줄껄 싶기도 합니다.
뭔가 예상대로 날아가지는 않지만 원하는 요구조건을 먼저 만족시킨 것은 맞으므로 이 코드를 바탕으로 게속 무언가를 계속해서 만들어나갑니다.
그러다가 어느 날, "날개를 보강하여 비행 성능을 높여라" 라는 요구조건을 받았습니다.
1. 이런! 저희는 날개를 보강해도 머리를 돌려서 날고있는데, 의미가 없는 작업일까요? 성능에는 변화가 없어지거든요!
2. 이 때, 결국 성능을 위해서 머리를 돌리는 것 대신에 날개를 사용하도록 코드를 수정하기로 했습니다.
  1. <리팩터링을 이럴 때 일어나는 것이 아닐까 싶어요.>

일단 작성된 코드로 잘 돌아간다면 두고 있다가, 추가적인 요구조건에 의해 수정하는 것이 현실세계에서 일을 가장 효율적으로 처리하는 방법이 아닐까 싶습니다.
물론 처음부터 이런 것들을 고려해서 비둘기가 날개를 써서 날도록 만들었다면 더 좋았겠지만, 만약 제가 "비둘기"라는 것을 모르고 "헬리콥터"만 알고 있었다면 저도 위와 같은 흐름으로 구현을 했을 것 같습니다.

그렇게 계속 만들어나가면서 "아, 비둘기는 머리를 돌려서 날아가는 것이 아니라 날개를 위아래로 움직이면서 날아가는 것이구나!" 라고 문제를 더 상세하게 이해하고 다음과 같은 사고흐름을 가질 수 있습니다.

아, 비둘기의 머리는 생각을 하면서 비행 방향을 결정하고 날개를 움직여서 날아가는 것이겠구나?

이런 예시와 같이 시스템이 발전해나가는 것이 아닐까요?
현실 세계에서는 여기서 예시를 들은 비둘기 대신 해결하려는 문제상황을 대입해보면 비슷한 상황들이 많이 펼쳐진다는 것을 알 수 있었습니다.

이 파트는 조금 길어서 정리한 한 문장을 적어보자면 아래와 같습니다.

"우선 내가 이해한 대로 문제를 해결하고 점점 문제에 대한 이해도가 높아지면서 문제 해결 방법을 변경해도 늦지 않다. 어떻게 사람이 한번에 모든 것에 대한 본질을 꿰뚫고 파악할 수 있겠는가?"

그래도 리팩터링 하다가 코드가 망가질까봐 무서워요

그래서 테스트코드라는 것이 있죠! 코드가 늘어나서 생산성이 떨어진다고요? 그렇지 않습니다!

이런 고민을 하시는 분들 대부분은 테스트코드의 중요성을 인지하지 않고 그저 기능만을 구현하신 분들이 대부분일 것이라 생각합니다.
실제로 테스트 코드를 작성하지 않고 리팩터링을 한다면 어떤 문제가 발생할 지, 겉보기에는 잘 된 것 같아보여도 실제로는 어떤 문제가 발생할 지 알 수 없습니다.

물론 테스트코드를 처음 작성해야 할 때는 해야할 일이 두 배가 된 것처럼 보이기도 합니다. 하지만 처음에는 그렇게 보여도 나중에 요구조건을 변경하거나 리팩터링을 해야할 때에는 오히려 생산성이 높아지는 결과를 낼 수 있다는 사실을 알고 계셨나요? 어떤 틀을 갖추고 있는 지 테스트코드를 통해 미리 지정하다보니, 많은 양의 변경사항이 있어야 함에도 불구하고 다소 빠르고 정확하게 코드를 바꿔나갈 수 있다는 점이 특징입니다.

예를들어 요즘같은 추운 날 국민간식이라고 불리는 붕어빵에 비유를 해볼까요?

붕어빵으로 알아본 테스트코드의 중요성

붕어빵은 역시 팥붕이죠. 반박시 슈붕

우리가 붕어빵을 만들기 위해 붕어빵 반죽과 단팥, 슈크림 등을 틀을 잘 만들어 두었습니다. 그리고 항상 일관된 모양이 나오기 위해 미리 확인하려고 일관된 모양의 붕어빵 틀을 만들어두었죠.

약간 다를 수도 있겠지만 붕어빵 틀을 테스트코드에 비유해보면 이해하기 쉽습니다.
테스트코드를 작성한다면 어떤 모양으로 나올 지를 미리 확인해볼 수 있기에 붕어빵 모양이 올바른지, 팥붕이면 팥이 제대로 들어가있는지, 슈붕이면 슈크림이 제대로 들어가있는 지 확인할 수 있죠.

만약 요구조건이 바뀐다면??(음, 네모난 붕어빵으로 제품을 수정해야겠는데?)

간단합니다. 테스트코드를 변경하고 이에 맞게 코드를 수정하면 됩니다!

네모난 붕어빵이 요즘 인기가 많죠. 그래서 이런 인기에 편승해 이익을 내기 위해 우리의 개발자에게 "기존의 붕어빵 대신에 네모난 붕어빵을 만들어주세요!" 라고 요청을 했어요.

그러면 개발자는 간단하게 붕어빵틀을 위 모양에 맞게 변경(테스트코드 변경)하고 이 모양대로 나오도록 제조 방법(코드)를 작성하면 되는 것이죠!

어때요 정말 간단하지 않나요? 만약 테스트코드(붕어빵틀)이 없었다면 이게 만들어지긴 했는데 네모가 아니라 세모, 원, 육각형 등 어떤 모양이 나올 지 알 수 없는 상태로 만들어졌을지도 모르죠. 중앙이 비어있는 붕어빵이 될 지도 몰라요.

이렇게 테스트코드가 중요합니다. 여차하면 TDD라는 개념이 나왔을까요?

결국 테스트코드는 리팩터링을 위한 하나의 장치가 아닐까요?

테스트코드는 결국 고층 건물 작업을 하는 데 필요한 안전장치와 같이 하나의 수단일 뿐이다.

강연에서 사용했던 이 이미지처럼 테스트코드가 없었을 때에는 이런 느낌으로 코드작업을 하지 않았을까요?

Q. 방금전까지는 붕어빵으로 잘 비유를 하다가 갑자기 웬 고층 건물인가요?

A. 물론 방금 전의 비유도 그런 느낌이 맞긴 했지만. 실제로 코드 작업을 하는 것이 생각보다 고층 건물에서 안전장치 없이 작업하는 것처럼 위험하다는 것을 알리기 위해 그렇게 적었습니다.

많은 개발자분들이 느끼기에도 코드 작업하다가 실수 하나 내면 갑자기 그 정교한 프로그램이 비행기 엔진에 나사 하나가 들어간것마냥 뭐가 문제인지는 모르겠는데 갑자기 안돌아가는 그런 일을 겪으신 분들이 많을 것입니다.

테스트코드 없이 코드를 작성하고 적용한다는 것을 고층 건물에서 어떠한 안전장치도 없이 계속해서 작업해나간다는 소리와 같습니다. 코드를 다 작성했고, 테스트코드가 없이도 잘 돌아가길래 배포까지 마쳤는데 갑자기 예상치 못했던 문제로 인해 서버가 다운된다면? 생각만해도 끔찍하죠..!

그래서! 테스트코드는 꼭 필요합니다. 개발자의 안전을 위해서요!

어쩌다보니 클린코드에서 테스트코드까지 흘러왔군요. 이 이야기의 결론은 무엇이죠?

결론은 클린코드는 단지 코드에 대한 것만을 의미하는 것이 아니라는 점을 주목해야 합니다. 방법론적인 하나의 방법일 뿐 반드시 적용해야하는 좋은 코드는 아닐수도 있다는 것이죠.

이런 말이 있습니다. "단순히 개발자가 편하기 위해서 우리는 하드웨어의 성능을 포기하는 것은 정말 좋지 않은 태도입니다."
말 그대로 클린코드 기법을 사용해 코드를 리팩터링 한다고 했을 때 성능이 유지되거나 더 좋아지면 좋겠지만, 그렇지 않은 경우도 존재합니다.
그렇다면 과연 개발자의 편의를 위해 그동안의 하드웨어의 발전을 부정하는 코드를 사용하는 것은 올바르다고 볼 수 있을까요?

개발자의 편의, 기업이 바라보는 제품(비용 등), 사용자의 만족 이 모두를 만족시킨만한 그 교집합에 있는 이상적인 제품을 위해 약간은 양보를 하고 가야 하는것이 아닐까 싶습니다.

많은 개발자들이 "클린(clean)" 그리고 "코드(code)"에 집중을 하고 있습니다. 하지만 막상 이에 대해 깊게 들어가보면 우리가 아는 클린코드는 코드에 대한 것이 아닐수도 있습니다.
어쩌면 클린코드는 붙여져있는 그 이름과는 다르게 "클린", 그리고 "코드" 양쪽 다 상관없는 개념일지도 모릅니다.

따로 정답도 없고 완벽한 결론도 없는 이러한 주제이지만, 그래도 이 글에 대한 결론은 필요하겠죠?

앞으로의 개발시장에서 우리는 많은 시행착오를 거쳐야 합니다. 아직도 컴퓨터에 대한 많은 부분을 정복하지 못하고 사용하고 있죠.
이러한 세상에서 우리는 그때그때 가장 정답에 근접한 코드들을 통해 정답이 없음에도 그렇게 보이도록 만드는 역할을 하는 "문제 해결사 및 정복자"를 담당하고 있습니다.

그렇게 주어진 문제들에 대한 이해도를 높여가며 점진적으로 코드를 키워나가는 것이 개발자들의 목표이며 이상이라고 생각합니다. 그러기 위해서는 문제를 이해하는 능력이 필요하고, 이해가 된 순간 이를 분해하여 다시 이해하고 결합하고 이러한 능력이 추가적으로 필요하겠죠.

개발을 배워나가는 저와 같은 학생들에게 클린코드는 어떤 의미인가요? 지금 배우고 써보는 것도 괜찮을까요?

저는 아직 개발을 배워가는 한 명의 학생입니다. 이렇게 강연들을 듣고나니 질문을 드리고 싶은 것이 하나 있습니다. 저와 같은 개발자를 향해가는 학생들 중에서도 클린코드에 푹 빠져있고, 좋은 설계에 대해 관심있게 보고 있는 경우가 많습니다.
하지만 지금까지의 내용을 클린코드를 지금 시점에 배우는 것보다는 사고의 확장을 먼저 일으키는 것이 중요한 것 같아 보입니다.
개발자님께서는 조언을 주신다면 어떤 말씀을 해주시겠습니까?

실제로 위와 같은 질문을 드렸고, 다음과 같은 답변을 받았습니다.

우선, 지금 클린코드에 대한 것을 적용시키기 전에 내가 코드를 잘 만들 수 있는 사람인지부터 확인을 해보시는 것이 좋습니다. 만약 클린코드 방법론, 여러 정형화된 규격에 맞지 않은 코드를 작성할까 두려워하며 시작조차 하지 못한다면 어느 의미가 있겠나요?
우선 어떻게든 많은 코드들을 작성해보면서 코드를 찍어내기 쉬운 상태로 먼저 올라가야 합니다. 그러면서 계속해서 코드들을 키워내다보면 그 과정에서 원칙을 익히고, 방법들을 습득하는 것입니다.
만약 이런 상태에서 클린코드와 같은 방법론을 배우고 적용해보고 싶다는 생각을 하고 있다면 얼른 그만두세요.
클린코드? 객체지향? 좋은설계? 일단은 지금은 때가 아닙니다.
물론 하지 않는다면 취직이 되지 않으니 취업 전에 잠깐 공부하는 것으로도 충분합니다.

이런 답변과 함께 하나의 방법론을 제시해주시기도 하였습니다.

마무리: 고통 주도 개발자를 해 보아라

일단 돌아가게 만들어라. 그리고 어떤 것이 내게 고통이 된다면 그 떄 해결해도 늦지 않다.

고통 주도 개발자?

일단 돌아가게 코딩해봅시다
어떤 것이 나에게 고통이 된다면 그 떄 해결합시다. 미리 깨끗하게 만들 필요는 없어요.

많은 프로그래머들이 이미 원칙 주도 개발을 하고 있습니다. 그 소리는 원칙을 지키지 않는 코드는 작성하지 않으려 한다는 소리이고, 그러한 원칙을 지키려다보니 원칙에서 벗어난 코드를 작성하는 것을 극도로 기피한다는 의미이기도 합니다.
가장 중요한 것은 일단 코드를 찍어낼 수 있어야 합니다. 무엇이든 만들 수 있어야 개발을 할 수 있거든요.
그리고 그런 원칙을 지키도록 만드는 것은 그 이후에 해도 충분합니다. 특히 우리와 같은 개발자 꿈나무들은 말이죠.

자, 그럼 고민하지 말고 일단 만들러 가봅시다!

End