@SoftyChoco Blog

개요소프트웨어 개발 생명주기 모델 중 하나로 가장 고전적인 모델.각 단계가 순차적으로 진행되며, 다시 이전단계로 되돌아가기가 어렵기 때문에 "폭포수 모델"이라고 이야기 함.모델 구조가 간단하며 각 단계별로 산출물이 나오기 때문에 요구사항이 명확하고, 변경될 일이 없는 작은 프로젝트에 적합함.구성도타당성 검토 > 계획 > 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수작업 방식타당성 검토기술적, 법적으로 문제가 없는지 검토하는 단계산출물: 타당성 검토 확인서계획프로젝트의 범위, 일정, 자원 등을 수립하는 단계산출물: 프로젝트 계획서요구사항 분석고객 요구사항을 분석하고, 명세하는 단계산출물: 요구사항 명세서설계요구사항 명세서를 기반으로 DB 구조, 시스템 구조 등을 설계를 진행하는 단계산출물: 시스템..

저는 면접관으로서 지원자를 만날 땐, 약점을 물어봅니다.이 질문에 지원자들의 흔한 답은, "생각을 못 해봤네요."나 "제 약점은 이러이러합니다." 라는 대답입니다.그나마 그중의 일부 지원자는, "제 약점은 이러이러 하지만, 이런 부분을 통해 개선하고 있습니다."와 같은 답변을 해서 자기 객관화와 성장 가능성을 어필하지만, 이 또한 반쪽짜리 답변입니다.왜 이런 답변이 '반쪽짜리'일까요?자기 객관화와 개선 의지는 분명 훌륭한 덕목입니다.하지만, 채용이라고 하는 것은 '지원자'만의 이야기가 아니라, '회사와 지원자가 어떻게 어우러지는지'를 알아보는 자리입니다.결국 위 답변들에서는 '우리 회사와의 연결고리'가 빠져있습니다.개인의 노력만으로 성장하겠다는 다짐은 어디에서나 할 수 있는 이야기입니다.그리고 그 답변은..

"AI는 결국 개발자를 대체할까요?"요즘 개발자들끼리 이야기 할 때면 어김없이 나오는 주제입니다.이미 클로드 코드와 커서 등이 만들어내는 코드는 제법 그럴듯하고, 단순한 기능은 몇 분 만에 뚝딱 만들어내기도 합니다.불안감이 드는 건 어쩔 수 없죠.그래서 오늘은 조금 도발적인 질문을 던져보려고 합니다.지금 당신의 이력서를 한 번 열어보세요.빼곡히 적힌 기술 스택들과 .혹시 그 역량들은, 대학생이 AI를 활용했을 때 금방 따라 할 수 있는 것들은 아닌가요?이 불편한 질문에 답하기 위해, 저는 최근 생각했던 흥미로운 비유 하나를 공유하고 싶습니다."AI는 프렌차이즈와 같다."프랜차이즈는 요리 산업에 혁명을 가져왔습니다.본사에서 제공하는 표준화된 레시피와 시스템 덕분에, 최고급 요리사가 아니어도 누구나 일정한 ..

취업/이직 시 처음에는 여러가지 방법으로 이력서를 찾아보고 적게 된다. 그리고 서류, 면접에서 몇 번 떨어지다 보면, 점점 이도저도 아닌 이력서가 되어가는 경우가 있다.왜 이런 경우가 발생하는 걸까?먼저 이력서의 경우, 불합격으로 인해 주변의 피드백을 받는 경우가 많다주변의 피드백이 면접관으로써 실력있는 한 사람이라면 괜찮지만, 주로 비슷한 연차거나, 면접관으로써의 실력이 없는 사람들 여러명에게 받는 경우이다. 이력서는 "채용공고에 맞는 역량"을 "내가 경험해온 것"으로 녹여내야하는데, 사람마다 어필하는 방식이나 표현이 다르고 중요하게 생각하는 부분이 다르다.예를 들어 기술적인 역량이 중요한 회사에 다니는 경우, 자신의 이력서는 기술적인 역량으로 합격했기에 기술적인 역량을 어필하라고 한다. 협업 실패를 ..

"모르는 거 있으면 편하게 물어보세요."팀장님은 편하게 질문하라는 듯이 이야기 해주시지만, 뭘 물어봐야할지, 어디까지 물어봐도 될지를 모르겠는 상황.나는 그저 막막하고, 질문의 수준이 너무 낮은건 아닌지 질문 하나하나가 걱정만 하는 중인데, 옆자리 동기 놈은 벌써 일을 마무리해가는 듯 합니다. 불안감과 조급함으로 인해 자신감도 바닥을 치게 되었구요.이런 경험, 한번 쯤은 있지 않으신가요?마치 안개 속을 걷는 것처럼 막막하고, 나만 뒤처질까 불안하신가요?괜찮습니다. 이건 내가 무능해서가 아닌 팀장의 잘못이고, 이 글을 읽고 난 뒤에는 뭘 물어봐야할지 아시게 될테니까요!당신은 지금 '시야 10%'로 슈퍼 마리오를 플레이하고 있습니다이 막막함은 마치 아래 슈퍼 마리오 게임을 하는데, 마리오 캐릭터 주변 10%..

이런 생각을 해보자. 어제까지는 막노동을 하던 사람이, 오늘 갑자기 기막힌 사업을 구상해서 성공할 가능성은 얼마나 될까? 아마 대부분은 불가능에 가깝다고 여길 것이다.왜 그럴까?단지 그 사람이 막노동을 하는 사람이라서가 아니다. 우리는 생략된 배경까지도 생각하여 판단한다. 막노동을 하는 사람은 먹고살기 힘들 것이고, 하루하루 일하는게 삶일테니까.물론, 100% 모든 사람이 그런 것은 아니다. 그럼 그들간의 차이는 어디에서 발생하는걸까? 우물 안 개구리이러한 상황은 분명 막노동을 하는 사람만의 이야기가 아니다.대부분의 사람들은 자신이 맡은 '역할'의 관점을 잘 벗어나지 못한다. 마치 우물 안 개구리처럼, 자신이 보고있는 하늘이 전부라 믿는 것처럼. 그 역할이 주는 안정감과 익숙함에 안주하면서, 다른 세상이..

개발을 하다 보면 유난히 예상치 못한 오류가 자주 발생하는 사람들이 있다.특히 자신이 알고 있는 것이 항상 맞다고 믿는 사람일수록 그런 경향이 강했다.반대로 나는 내가 확신할 수 없는 부분에 대해서는 쉽게 믿지 않으려고 노력한다.이 글에서는 왜 개발할 때 "아무것도 믿지 않는 태도"가 중요한지에 대해 이야기해 보려고 한다.사람은 망각한다코드를 작성한 후 시간이 지나면 대부분의 개발자는 그 내용을 점점 잊어버린다.물론 기억력이 뛰어난 사람도 있지만, 보통 6개월 정도 지나면 자신의 코드라도 남의 코드처럼 느껴질 수 있다.그럼에도 불구하고 많은 개발자가 예전에 작성했던 코드를 완전히 이해하고 있다고 착각한다.특히 기존 코드와 연관된 기능을 추가할 때 이런 실수가 자주 발생한다.하지만 기억에 의존하면 실수가 ..

특정 분야(프론트엔드, 백엔드 등)에서 일을 하다보면, 뭔가 나랑은 맞지 않아서 반대쪽으로 넘어가는 경우가 종종 있습니다. 그런데 해당 이력을 적다보면 결국 프론트엔드도 백엔드도 아닌 흔히 말하는 "풀스택 개발자"같은 이력서가 만들어지는데요. 인터넷 상에서 여러가지를 배우는 것 보다 하나에 집중하는게 낫다, 풀스택 개발자는 잡부다 이런 류의 악명이 높다보니 이를 기피하는 분들이 꽤나 있습니다. 하지만 정작 회사 입장에서 봤을 때, 프론트엔드와 백엔드를 모두 할 수 있다는건 굉장한 이점일 수도 있습니다. 먼저 각 분야간의 커뮤니케이션이 원활해질 수 있고, 업무 부하에 따라 전략적으로 배치할 수 있는 인원인데다가, 사실 중소기업 입장에서는 업무 자체가 많지 않은 경우 프론트엔드와 백엔드 둘을 고용하는 것보다..