최근 며칠간 회사일로 약간의 혼란상황이 있었습니다.
많은 부분 정리가 되긴 했지만, 아직 조금 더 시간이 걸리듯 하네요.
최근 블로그를 쓰지 않고 있었던 것은 다른 일로 좀 바빴기 때문인데, 역시 이것도 시간이 많이 필요해 보입니다. 오늘은 잠시 추석을 앞두고 휴식도 가질 겸 기술이 아니라 기술에 대한 생각들을 한번 이야기해볼까 합니다. 추석에는 다른 작업을 또 열심히 해야 하기에...
그동안도 몇 번 블로그에 정리하고 싶었습니다만, 저 자신도 부족한 것이 많은데 괜한 잘난 척이 되지 않을까, 몇 번이나 쓰기를 망설였던 내용입니다.
그 내용은 개발자들이 흔히 범하는 기술에 대한 오해에서 오는 오만에 대한 것입니다.
최근 면접을 위해 이력서를 보거나 다른 회사의 제안서를 검토하다 보면 애자일 방법론이라던가 도메인 주도개발이라던가 테스트 주도개발을 강점으로 내세우는 경우를 많이 보게 됩니다. 또한 머신 투 머신(이런 용어가 어디에서 나온 것인지 좀 궁금합니다만...)의 인터페이스를 이용한 개발방법론이라는 것도 보게 되더군요. 아마도 EIP(기업 통합 패턴, Enterprise Integration Pattern)을 말하는 것이거나, 마이크로서비스 아키텍트의 사촌쯤 되는 게 아닐까 생각해 봅니다. 심지어 위 기술들에 대한 전문가라고 칭하는 사람들도 보이더군요.
너무나도 당연히 해야만 하는 테스트주도 개발(제 주관적인 생각입니다)을 제외하고 다른 부분에 대해서는 좀 생각을 해봐야 하는 것이 아닌가 합니다.
위에 기술한 것들이 참 좋은 것들이고 올바른 트랜드라고 생각을 합니다만...
좀 더 깊게 한번 생각해 보겠습니다.
애자일 방법론의 핵심이 무엇일까요?
애자일 매니페스토의 한글 번역본은 이렇게 시작합니다.
몇 개월이 지나도록 고객이 UI/UX 스토리보드 이외에 실제로 동작하는 어떠한 프로토타입도 받지 못했다면 제가 생각하기에 애자일 방법론이 아닙니다. 물론, 큰 엔터프라이즈 시스템의 경우 백앤드 작업에 시간이 걸리기 때문에 그럴 수도 있다고 생각하시는 분들도 있을지 모르겠지만, 제 생각에는 아닙니다. 백앤드 시스템 개발 중에도 최소한 엉터리 디자인이 적용된 Mockup이라도 그리고 Mock 데이터를 이용하더라도 프런트앤드의 프로토타이핑이 병행되어져야 한다고 생각합니다. 이것도 최소한일 뿐이지요. 일정 기능이라도 완전한 형태로 고객에게 전달되지 않으면 안 됩니다. 그렇지 않다면 고객이 본인의 요구사항을 개발자들이 정확히 개발하고 있다는 것을 어떻게 알 수 있을까요? 이런 애자일 방법론은 폭포수 모델에 비해서 나은 부분이 무엇일까요?
단순히 백로그를 관리하고 스프린트가 돌고 스탠드업 미팅을 진행한다고 애자일을 하고 있다고 말할 수 있는 것인지 한 번 생각해 봤으면 합니다.
폭포수 모델도 백로그 관리하고 이슈트래킹하고 스프린트 돌리고 스탠드업 미팅을 진행할 수 있습니다. 엉클 밥의 경우는 페어프로그래밍을 하지 않는다면 애자일이 아니라고 이야기하시기도 하더군요. 뭐 그렇게까지 엄격한 잣대를 들이밀고 싶지는 않습니다.
애자일은 고객에게 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키기 위해서 나온 개발 방법론이라는 것을 한번 이야기해보고 싶었습니다.
다음으로는 도메인 주도 설계입니다.
데이터 주도 설계냐 도메인 주도 설계냐를 놓고 어느 것이 우위에 있다고 싸우는 경우를 보곤 합니다. 꼭 싸우지는 않더라도 데이터 주도 설계를 하면 도메인 주도 설계보다 확장성이나 유연성이 떨어진다고 말씀하시는 분들도 있더군요.
그런데 이런 논쟁을 하시는 분들의 경우 일반적으로 마이바티스를 사용하고 있으니 데이터주도 설계에 의한 개발이고 JPA를 사용하고 있으니 도메인 주도 설계에 의한 개발이라고 말씀하시는 분들이 꽤 보입니다. (오늘도 한 분 뵈었죠) 과연 마이바티스를 사용하니 데이터주도 개발이고 JPA 를 사용하니까 도메인 주도 개발일까요? 과연 도메인 주도 개발이 데이터 주도 개발보다 유연성과 확장성이 뛰어날까요?
제가 알기로는 Data Driven Design과 Domain Driven Design의 차이는 관점의 차이로 알고 있습니다. 어떤 프로세스가 진행되는 과정에서 데이터의 생성/변형, 데이터의 그룹화 등에 초점을 맞추고 진행하는 디자인 방식이 Data Driven Design이고, 업무를 중심으로 설계를 진행하는 것이 Domain Driven Design입니다.
실제 현실에서는 어떨까요? Data Driven Design의 경우는 일반적으로 테이블을 기준으로 해서 설계를 진행하게 되는 경우가 많습니다. 업무에 따라서 어떤 테이블을 참조할지를 결정하고 해당 테이블에 대한 데이터 객체를 이용하게 되는 방식이지요. 반면에 Domain Driven Design은 실제 객체에 집중해서 진행하게 됩니다. 업무 또는 업무의 속성을 표현한 객체를 설계하고 해당 관점에서 전체적인 설계를 진행하게 됩니다. 뭔가 말이 딱 와 닿게 만들어지지를 않네요. 어쨌건 이러다 보니 마이바티스는 Data Driven Design에 가깝고 JPA는 Domain Driven Design에 가깝다는 논리가 만들어지는 건지도 모르겠습니다. Domain Driven Design의 관점에서는 실제로 데이터베이스의 테이블과 1:1로 맵핑이 되지 않는 경우도 발생하기 때문에 DDD 진형에서는 이 차이점을 극복하기 위한 다양한 시도나 노하우가 만들어지고 있기도 한 것으로 압니다.
DDD는 업무를 표현하면서 실제 사용 고객의 언어와 개발자의 언어가 같아야 한다고 이야기합니다. 즉, DDD의 핵심은 고객이 사용하는 언어로 만들어낸 요구사항을 어떻게 모델링 해낼 것인가에 있다는 말이지요. 고객과 고객의 업무에 그 초점이 맞추어진다는 점에서 DDD는 일반적으로 애자일 방법론과 궁합이 좋다고 이야기합니다. 즉, DDD는 고객의 업무에 대한 분석이 충분히 이루어져야 하고 고객의 관점에서 고객의 언어로 요구사항을 받아 설계를 진행해야 합니다. 그런데, 고객의 업무와 고객의 요구사항이 정확히 파악되고 분석되지 않은 상태에서 만들어진 도메인이라는 것이 과연 효용이 있는 것인지 한 번 생각해 보았으면 합니다.
마지막으로 EIP 또는 마이크로서비스 아키텍트(이하 MSA, Micro Service Architect)에 관한 이야기를 해 볼까 합니다.
MSA에 대해서는 저도 매우 큰 관심이 있는 상태이고, 최근 열심히 공부하면서 그 활용성을 고민해 보고 있는 분야지만 아직 실전 경험이 없습니다. EIP의 경우도 저에겐 실전경험 없이 수박 겉핥기 수준의 분석을 진행한 경험이 전부인 분야지요. 따라서, 제가 할 말은 거의 없습니다. 하지만, 한 가지만 이야기해볼까 합니다. 과연 EIP 나 MSA가 일반적인 다른 프로그램 패턴보다 성능이 많이 뛰어난 것일까요? 확장하는데 비용이 획기적으로 절약이 될까요? 잘 모르는 제가 볼 때는 많은 고민을 하고 적용 여부를 판단한 후에 설계가 이루어졌을 때만 그 효용가치가 올라갈 수 있다고 생각합니다(뭐는 그렇지 않겠습니까?). 생각 없이 메시지 큐와 파이프 등을 이용해서 개발이 이루어진다면 기술의 배신을 맛볼 수 있지 않을까 생각합니다. 대부분의 신기술이 나올 때 별다른 분석없이 그리고 고민 없이 사용했다가 여러번 배신당한 경험이 있으므로 이 역시 마찬가지가 아닐까 생각하는 것이지요. 주변에 EIP를 사용하고 있는 업체에 계신 분들 이야기를 들어보면 제 생각이 크게 틀리지는 않은 것 같습니다. 처음에는 효용가치가 매우 높아 보이는 설계로 진행되기 시작한 EIP가 점점 뭔가 고가의 솔루션을 요구하기에 이르고 설계 자체도 처음과 다르게 이리저리 어지러운 설계로 변화해가고 결국 감당하기에 벅찬 설계로까지 변질 되어버려서 새로운 시스템에 대해 고민을 하는 경우도 있더군요.
정리해 볼까 합니다.
어떤 영역에나 적용이 되는 최고의 기술 또는 개발방법론 즉 Silver Bullet은 세상에 없다는 것이 제 생각입니다. 기술이나 개발방법론은 트랜드를 가지고 변화하는 특성이 있습니다. 새로운 언어가 나왔다거나 새로운 개념이 출현하면서 다양한 트랜드로 변화를 하게 되지요. 요즘은 MSA라던가 Reactive라던가 Functional Programming이라던가 하는 것들이 트랜드로 떠오르고 있습니다. 하지만, 이 역시 몇 년이 지나고 새로운 언어나 개념들이 등장한다면 다시 구시대의 유물이 되겠지요. 구시대의 유물인 기술과 개발방법론도 반드시 나쁜 것만은 아니라고 생각합니다. 그 역시 원래의 의도대로 고민하고 잘 다듬는다면 더 나은 방법론과 기술로 탈바꿈할 수 있는 여지가 있는 것들이 많이 있을꺼예요.
위에 말씀드렸던 개발방법론이라던가 기술이라던가 하는 것들이 나쁘다는 것이 아닙니다. 이 부분은 오해가 없으셨으면 좋겠네요.
제가 그리 길지 않은 기간 개발자로 살아오면서 느낀 개발에 있어서 가장 중요한 것은 고객의 소리를 얼마나 잘 들어서 그들의 의도를 얼마나 잘 표현해 내줄 수 있는 것인가라고 생각합니다. 고객의 만족도를 얼마나 끌어올릴 수 있는가지요. 그것을 위해서 개발방법론이라던가 아키텍트라던가 기술들이 필요한 것이 아닐까요? 새로운 것이 기존 것보다 얼마만큼 나아질 것인가를 이야기하고 싶다면 데이터를 가지고 이야기해야 한다고 생각합니다. 새로운 고객에게 이야기하는 것이기에 내세울 데이터가 없다면 기존에 작업했을 때의 통계 데이터라도 제시를 하면서 이야기해야만 하는 것이 아닐까요? 통계 데이터도 일반화의 오류를 범할 가능성이 매우 높습니다만, "단순히 두 배 빨라집니다", "개발 시간이 많이 단축돼요", "확장성이 놀랄 만큼 향상됩니다" 보다는 낫지 않을까요? "제 경험으로 봤을 때는 정말 획기적으로 변화될 것입니다" 라는 말도 마찬가지로 문제가 있지 않을까요? 개발자는 약장사가 아니잖아요? 그보다는 최소한 "10번의 프로젝트에서 8번은 30% 정도의 향상을 보였고 2번은 20% 정도 향상을 보였습니다. 고객님의 요구사항을 좀 더 자세히 분석해봐야 하겠지만, 위의 통계는 고객님께도 충분히 적용될 것으로 보입니다. 위의 통계보다 더 나은 결과를 내기 위해서 고객님과 함께 일했으면 좋겠습니다." 정도의 이야기는 해 줘야 하는 것이 아닐까 싶습니다.
개발자가 거짓말을 하지 않는 세상이었으면 좋겠습니다. 개발자가 특정 기술에 대한 신념으로 인해서 오만해지지 않았으면 좋겠습니다. 그건 신념이 아니라 오해일 뿐이니까요.
별로 가진 것도 없고 내세울 것도 없는 생계형 개발자가 잠시 오만하게 굴어봤습니다.
이 글을 읽으시는 분이 있으시다면 부디 너그러이 봐주시기를...
많은 부분 정리가 되긴 했지만, 아직 조금 더 시간이 걸리듯 하네요.
최근 블로그를 쓰지 않고 있었던 것은 다른 일로 좀 바빴기 때문인데, 역시 이것도 시간이 많이 필요해 보입니다. 오늘은 잠시 추석을 앞두고 휴식도 가질 겸 기술이 아니라 기술에 대한 생각들을 한번 이야기해볼까 합니다. 추석에는 다른 작업을 또 열심히 해야 하기에...
그동안도 몇 번 블로그에 정리하고 싶었습니다만, 저 자신도 부족한 것이 많은데 괜한 잘난 척이 되지 않을까, 몇 번이나 쓰기를 망설였던 내용입니다.
그 내용은 개발자들이 흔히 범하는 기술에 대한 오해에서 오는 오만에 대한 것입니다.
최근 면접을 위해 이력서를 보거나 다른 회사의 제안서를 검토하다 보면 애자일 방법론이라던가 도메인 주도개발이라던가 테스트 주도개발을 강점으로 내세우는 경우를 많이 보게 됩니다. 또한 머신 투 머신(이런 용어가 어디에서 나온 것인지 좀 궁금합니다만...)의 인터페이스를 이용한 개발방법론이라는 것도 보게 되더군요. 아마도 EIP(기업 통합 패턴, Enterprise Integration Pattern)을 말하는 것이거나, 마이크로서비스 아키텍트의 사촌쯤 되는 게 아닐까 생각해 봅니다. 심지어 위 기술들에 대한 전문가라고 칭하는 사람들도 보이더군요.
너무나도 당연히 해야만 하는 테스트주도 개발(제 주관적인 생각입니다)을 제외하고 다른 부분에 대해서는 좀 생각을 해봐야 하는 것이 아닌가 합니다.
위에 기술한 것들이 참 좋은 것들이고 올바른 트랜드라고 생각을 합니다만...
좀 더 깊게 한번 생각해 보겠습니다.
애자일 방법론의 핵심이 무엇일까요?
애자일 매니페스토의 한글 번역본은 이렇게 시작합니다.
이 뒤로도 주옥같은 많은 원칙이 나옵니다만, 저에게 애자일의 가장 핵심은 위의 내용입니다.우리의 최우선 순위는, 가치 있는 소프트웨어를일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
몇 개월이 지나도록 고객이 UI/UX 스토리보드 이외에 실제로 동작하는 어떠한 프로토타입도 받지 못했다면 제가 생각하기에 애자일 방법론이 아닙니다. 물론, 큰 엔터프라이즈 시스템의 경우 백앤드 작업에 시간이 걸리기 때문에 그럴 수도 있다고 생각하시는 분들도 있을지 모르겠지만, 제 생각에는 아닙니다. 백앤드 시스템 개발 중에도 최소한 엉터리 디자인이 적용된 Mockup이라도 그리고 Mock 데이터를 이용하더라도 프런트앤드의 프로토타이핑이 병행되어져야 한다고 생각합니다. 이것도 최소한일 뿐이지요. 일정 기능이라도 완전한 형태로 고객에게 전달되지 않으면 안 됩니다. 그렇지 않다면 고객이 본인의 요구사항을 개발자들이 정확히 개발하고 있다는 것을 어떻게 알 수 있을까요? 이런 애자일 방법론은 폭포수 모델에 비해서 나은 부분이 무엇일까요?
단순히 백로그를 관리하고 스프린트가 돌고 스탠드업 미팅을 진행한다고 애자일을 하고 있다고 말할 수 있는 것인지 한 번 생각해 봤으면 합니다.
폭포수 모델도 백로그 관리하고 이슈트래킹하고 스프린트 돌리고 스탠드업 미팅을 진행할 수 있습니다. 엉클 밥의 경우는 페어프로그래밍을 하지 않는다면 애자일이 아니라고 이야기하시기도 하더군요. 뭐 그렇게까지 엄격한 잣대를 들이밀고 싶지는 않습니다.
애자일은 고객에게 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키기 위해서 나온 개발 방법론이라는 것을 한번 이야기해보고 싶었습니다.
다음으로는 도메인 주도 설계입니다.
데이터 주도 설계냐 도메인 주도 설계냐를 놓고 어느 것이 우위에 있다고 싸우는 경우를 보곤 합니다. 꼭 싸우지는 않더라도 데이터 주도 설계를 하면 도메인 주도 설계보다 확장성이나 유연성이 떨어진다고 말씀하시는 분들도 있더군요.
그런데 이런 논쟁을 하시는 분들의 경우 일반적으로 마이바티스를 사용하고 있으니 데이터주도 설계에 의한 개발이고 JPA를 사용하고 있으니 도메인 주도 설계에 의한 개발이라고 말씀하시는 분들이 꽤 보입니다. (오늘도 한 분 뵈었죠) 과연 마이바티스를 사용하니 데이터주도 개발이고 JPA 를 사용하니까 도메인 주도 개발일까요? 과연 도메인 주도 개발이 데이터 주도 개발보다 유연성과 확장성이 뛰어날까요?
제가 알기로는 Data Driven Design과 Domain Driven Design의 차이는 관점의 차이로 알고 있습니다. 어떤 프로세스가 진행되는 과정에서 데이터의 생성/변형, 데이터의 그룹화 등에 초점을 맞추고 진행하는 디자인 방식이 Data Driven Design이고, 업무를 중심으로 설계를 진행하는 것이 Domain Driven Design입니다.
실제 현실에서는 어떨까요? Data Driven Design의 경우는 일반적으로 테이블을 기준으로 해서 설계를 진행하게 되는 경우가 많습니다. 업무에 따라서 어떤 테이블을 참조할지를 결정하고 해당 테이블에 대한 데이터 객체를 이용하게 되는 방식이지요. 반면에 Domain Driven Design은 실제 객체에 집중해서 진행하게 됩니다. 업무 또는 업무의 속성을 표현한 객체를 설계하고 해당 관점에서 전체적인 설계를 진행하게 됩니다. 뭔가 말이 딱 와 닿게 만들어지지를 않네요. 어쨌건 이러다 보니 마이바티스는 Data Driven Design에 가깝고 JPA는 Domain Driven Design에 가깝다는 논리가 만들어지는 건지도 모르겠습니다. Domain Driven Design의 관점에서는 실제로 데이터베이스의 테이블과 1:1로 맵핑이 되지 않는 경우도 발생하기 때문에 DDD 진형에서는 이 차이점을 극복하기 위한 다양한 시도나 노하우가 만들어지고 있기도 한 것으로 압니다.
DDD는 업무를 표현하면서 실제 사용 고객의 언어와 개발자의 언어가 같아야 한다고 이야기합니다. 즉, DDD의 핵심은 고객이 사용하는 언어로 만들어낸 요구사항을 어떻게 모델링 해낼 것인가에 있다는 말이지요. 고객과 고객의 업무에 그 초점이 맞추어진다는 점에서 DDD는 일반적으로 애자일 방법론과 궁합이 좋다고 이야기합니다. 즉, DDD는 고객의 업무에 대한 분석이 충분히 이루어져야 하고 고객의 관점에서 고객의 언어로 요구사항을 받아 설계를 진행해야 합니다. 그런데, 고객의 업무와 고객의 요구사항이 정확히 파악되고 분석되지 않은 상태에서 만들어진 도메인이라는 것이 과연 효용이 있는 것인지 한 번 생각해 보았으면 합니다.
마지막으로 EIP 또는 마이크로서비스 아키텍트(이하 MSA, Micro Service Architect)에 관한 이야기를 해 볼까 합니다.
MSA에 대해서는 저도 매우 큰 관심이 있는 상태이고, 최근 열심히 공부하면서 그 활용성을 고민해 보고 있는 분야지만 아직 실전 경험이 없습니다. EIP의 경우도 저에겐 실전경험 없이 수박 겉핥기 수준의 분석을 진행한 경험이 전부인 분야지요. 따라서, 제가 할 말은 거의 없습니다. 하지만, 한 가지만 이야기해볼까 합니다. 과연 EIP 나 MSA가 일반적인 다른 프로그램 패턴보다 성능이 많이 뛰어난 것일까요? 확장하는데 비용이 획기적으로 절약이 될까요? 잘 모르는 제가 볼 때는 많은 고민을 하고 적용 여부를 판단한 후에 설계가 이루어졌을 때만 그 효용가치가 올라갈 수 있다고 생각합니다(뭐는 그렇지 않겠습니까?). 생각 없이 메시지 큐와 파이프 등을 이용해서 개발이 이루어진다면 기술의 배신을 맛볼 수 있지 않을까 생각합니다. 대부분의 신기술이 나올 때 별다른 분석없이 그리고 고민 없이 사용했다가 여러번 배신당한 경험이 있으므로 이 역시 마찬가지가 아닐까 생각하는 것이지요. 주변에 EIP를 사용하고 있는 업체에 계신 분들 이야기를 들어보면 제 생각이 크게 틀리지는 않은 것 같습니다. 처음에는 효용가치가 매우 높아 보이는 설계로 진행되기 시작한 EIP가 점점 뭔가 고가의 솔루션을 요구하기에 이르고 설계 자체도 처음과 다르게 이리저리 어지러운 설계로 변화해가고 결국 감당하기에 벅찬 설계로까지 변질 되어버려서 새로운 시스템에 대해 고민을 하는 경우도 있더군요.
정리해 볼까 합니다.
어떤 영역에나 적용이 되는 최고의 기술 또는 개발방법론 즉 Silver Bullet은 세상에 없다는 것이 제 생각입니다. 기술이나 개발방법론은 트랜드를 가지고 변화하는 특성이 있습니다. 새로운 언어가 나왔다거나 새로운 개념이 출현하면서 다양한 트랜드로 변화를 하게 되지요. 요즘은 MSA라던가 Reactive라던가 Functional Programming이라던가 하는 것들이 트랜드로 떠오르고 있습니다. 하지만, 이 역시 몇 년이 지나고 새로운 언어나 개념들이 등장한다면 다시 구시대의 유물이 되겠지요. 구시대의 유물인 기술과 개발방법론도 반드시 나쁜 것만은 아니라고 생각합니다. 그 역시 원래의 의도대로 고민하고 잘 다듬는다면 더 나은 방법론과 기술로 탈바꿈할 수 있는 여지가 있는 것들이 많이 있을꺼예요.
위에 말씀드렸던 개발방법론이라던가 기술이라던가 하는 것들이 나쁘다는 것이 아닙니다. 이 부분은 오해가 없으셨으면 좋겠네요.
제가 그리 길지 않은 기간 개발자로 살아오면서 느낀 개발에 있어서 가장 중요한 것은 고객의 소리를 얼마나 잘 들어서 그들의 의도를 얼마나 잘 표현해 내줄 수 있는 것인가라고 생각합니다. 고객의 만족도를 얼마나 끌어올릴 수 있는가지요. 그것을 위해서 개발방법론이라던가 아키텍트라던가 기술들이 필요한 것이 아닐까요? 새로운 것이 기존 것보다 얼마만큼 나아질 것인가를 이야기하고 싶다면 데이터를 가지고 이야기해야 한다고 생각합니다. 새로운 고객에게 이야기하는 것이기에 내세울 데이터가 없다면 기존에 작업했을 때의 통계 데이터라도 제시를 하면서 이야기해야만 하는 것이 아닐까요? 통계 데이터도 일반화의 오류를 범할 가능성이 매우 높습니다만, "단순히 두 배 빨라집니다", "개발 시간이 많이 단축돼요", "확장성이 놀랄 만큼 향상됩니다" 보다는 낫지 않을까요? "제 경험으로 봤을 때는 정말 획기적으로 변화될 것입니다" 라는 말도 마찬가지로 문제가 있지 않을까요? 개발자는 약장사가 아니잖아요? 그보다는 최소한 "10번의 프로젝트에서 8번은 30% 정도의 향상을 보였고 2번은 20% 정도 향상을 보였습니다. 고객님의 요구사항을 좀 더 자세히 분석해봐야 하겠지만, 위의 통계는 고객님께도 충분히 적용될 것으로 보입니다. 위의 통계보다 더 나은 결과를 내기 위해서 고객님과 함께 일했으면 좋겠습니다." 정도의 이야기는 해 줘야 하는 것이 아닐까 싶습니다.
개발자가 거짓말을 하지 않는 세상이었으면 좋겠습니다. 개발자가 특정 기술에 대한 신념으로 인해서 오만해지지 않았으면 좋겠습니다. 그건 신념이 아니라 오해일 뿐이니까요.
별로 가진 것도 없고 내세울 것도 없는 생계형 개발자가 잠시 오만하게 굴어봤습니다.
이 글을 읽으시는 분이 있으시다면 부디 너그러이 봐주시기를...
좋은글 잘 읽고갑니당
답글삭제글에 쓴 것처럼 많이 부끄럽습니다.. 댓글 감사드려요.
삭제