이건 뭐 꼭 이래된다는 얘기는 아니야...
처음에 그렇지 않아도 찬찬히 생각하면서 설계하는 사람도 있으니깐...



근데 있잖아.. 나나... 내 주변에 어떤 사람들을 보면....
요구사항 회의를 하잖아...
그럼 예를 들어 어떤 요구사항에 대해서 막 얘기를 하고 있다보면

개발자는 머리속으로 아 저걸 구현하려면 디비 스키마는 요로코롬 만들어야겠고. 그걸 이런식으로 가져다가 이렇게 뿌려주면 될것 같고..
아니면 외부의 어떤 것을 끌어다가 이렇게 가공한다음 집어넣고 그걸 저거랑 합쳐서 짠~ 하고 뿌려주면 될것 같구만!!!

이라고 머리속으로 생각하면서 얘기하지 않음?

그래서 요구사항 회의를 할때 아 이건 할만하고 이런식으로 구현함 되겠구나 하는건 수용하는거고...
그런 그림이 금방 안떠오르거나 전혀 될것 같지 않으면 힘들겠다고 말하거나 구현이 안된다고 얘기하고...


그런거 아님?


이건 자질이 있고 없고의 문제를 말하는 중요한 사항이긴 한데 \'스킬\'이 딸리거나 \'프로그래밍\'능력이 미천하다해도
개념적으로 머리속으로는 자기가 알고 있는 한도내에서 요구사항을 들음과 동시에 가진 기술과 능력으로 어떻게 해봐야겠다는 방향성을 떠올리지
못하는 사람은 \'개발\'과는 잘 맞지 않는다고 생각해...
비유를 들어 설명하자면 레고 블럭모양을 2종류만 가지고 있는 사람과 10종류를 가지고 있는 차이는 어떻게 할수 없지만
레고 블럭으로 \'집을 만드시오\' 라는 문제에 대해
어떻게 하면 블럭을 조합해서 집을 만들수 있을까? 를 빨리 생각하는 능력은 블럭을 몇종류를 가지고 있는지와는 상관 없다는 말이지

물론 글 첫머리에도 썼지만 우선 요구사항을 가져와서 천천히 생각해보면서 음.. 이건 어떻게 풀어나갈까.. 저건 어떻게 구현하면 될까.. 생각해서 해결하는것도 어떻게 보면 더 신중하고 양질의 결과를 낼수는 있지만...

문제를 인지함과 동시에 해결방안에 대한 대략적 레이아웃을 떠올릴수 있는 사람과 그렇지 못한 사람의 차이는 매우 크다고 생각해...


내가 생각하는 프로그래밍의 적성은 저런 능력이 크게 좌우하는것 같다는 얘기야...


그럼 이제 너님들의 팅커바웃을 한번 얼큰하게 풀어봐바바바바바바밥ㅂ바밥 먹고 싶다...