프로그래머의 세계 이해하기

타키탸키·2020년 12월 30일
4

컴퓨터 개론

목록 보기
5/9

프로그래머는 어떤 일을 할까요? 그들 앞에 놓인 복잡한 코드가 나열된 컴퓨터 화면을 보면 프로그래밍을 모르는 사람들 입장에서는 범접할 수 없는 영역처럼 보이기도 합니다.

개발자가 되기 위해서는 프로그래머의 세계에 대해 잘 알아야겠죠? 현직에서는 어떤 프로그램과 기술이 사용되고 있는지 이번 시간에 알아보도록 합시다.

🧙‍♂️ 프로그래밍의 기본기

프로그래밍의 세계는 서로 밀접한 연관을 맺고 있습니다. 비슷한 접근 방식과 문제 해결 방식을 공유하고 있기 때문에 하나를 잘 하면 다른 하나도 잘하게 되는 것이죠. 예를 들어볼까요?

앱 개발자에게 서버 개발을 맡기더라도 조금만 배우면 금방 일에 적응합니다. C++을 배운 사람이 Java를 빨리 배우는 것도 흔히 있는 일이죠. 이처럼 프로그래밍의 기본기가 튼튼하면 새로운 기술, 언어, 환경에도 빠르게 적응할 수 있습니다.

컴퓨터 사이언스의 기본에는 객체 지향 프로그래밍, 알고리즘, 자료구조가 있습니다. 이 세 분야는 어떤 분야의 프로그래밍을 하더라도 꼭 알아야 하는 중요한 개념들입니다.

그 외에도 컴퓨터 구조, 운영체제, 컴파일러, 웹 개발, 데이터베이스, 네트워크 같은 과목들이 있습니다. 이러한 과목들은 기본기를 익혀 두시되, 필요에 따라 더 깊게 학습하면 됩니다.

🧙‍♂️ 소프트웨어 공학

프로그래머는 프로그램만 만드는 사람들일까요? 사실 프로그래머도 하는 일이 참 많습니다.

프로그램을 제작하기 전에 프로그래머는 어떤 기능을 만들어야 하는지, 언제 일을 마쳐야 하는지, 어떤 사람과 협업해야 하는지, 어떤 방식으로 코드를 짤지 등 여러 고민을 합니다.

동료 개발자 외에도 기획팀, 마케팅팀, 영업팀 등 회사의 다른 부서 사람들과 협업을 해야 하는 경우가 많기 때문에 이들과 회의 시간을 가지기도 하죠.

프로그래머들이 하는 일은 소프트웨어 공학에 속합니다. 소프트웨어 공학은 소프트웨어로 제품과 서비스를 만드는 방법에 대한 학문인데요. 소프트웨어 공학의 과정에는 기획, 제작, 테스트, 출시, 사후관리가 있습니다.

기획은 어떤 것을 만들지 정하는 단계입니다. 이 단계에서는 개발자에게 기획 방향에 맞는 업무를 어떻게 제시할 지 고민을 합니다.

개발은 기획한 것을 만드는 단계입니다. 이 단계에서는 어떻게 하면 기획 방향에 맞게 코딩을 구현할 수 있을까 혹은 어떤 동료들과 함께 협업해야 할까 등을 고민합니다.

테스트는 개발이 기획대로 잘 되었는지 확인하는 단계입니다. 이 단계에서는 어떻게 하면 출시 전 발생할 수 있는 모든 문제를 발견하고 효율적으로 해결할 수 있을지를 고민합니다.

배포 혹은 출시는 개발된 제품과 서비스를 사용자가 사용하는 단계입니다. 이 단계에서는 어떻게 하면 각 사용자의 환경에 맞는 소프트웨어를 잘 배포할 수 있을지를 고민합니다.

유지/보수는 출시된 서비스를 변화시키는 단계입니다. 이 단계에서는 어떻게 하면 이미 만들어진 소프트웨어를 쉽게 변경할 수 있을지를 고민합니다.

이 모든 과정을 거치면 다음에는 어떻게 하면 더 매끄럽게 진행할 수 있을까 혹은 어떻게 하면 제한된 자원으로 정해진 일정 안에 좋은 소프트웨어를 완성할 수 있을까를 고민합니다.

🧙‍♂️ 프로세스 관리

하나의 소프트웨어를 출시하기 위해 다양한 사람들이 협업을 진행합니다. 개발자, 기획자, 디자이너, 테스터, 관리자 등이 함께 일하는 것이죠. 여러 사람이 함께 일하다보니 의사소통에 문제가 생기는 경우도 많습니다. 이러한 문제를 해결하기 위해 효율적인 협업 방식을 고민해왔습니다.

가장 대표적인 협업 방식에는 폭포수(Waterfall)애자일(Agile)이 있습니다.

각 단계를 완료하고 다음 단계로 넘어가는 폭포수는 고전적인 협업 방식으로 이해와 관리가 쉽다는 장점이 있습니다.

기획자가 필요한 것을 문서로 완성하면 개발자가 문서를 받아 프로그램을 제작합니다. 프로그램이 완성되면 잘 작동되는지 테스터가 확인하고 문제가 없으면 프로그램을 사용자가 사용할 수 있도록 공개합니다. 마지막으로 오류 개선과 추가적인 기능을 개발합니다.

이렇게 단순하고 직관적인 폭포수 방식에도 문제점이 있습니다. 각 단계를 한 번에 완벽하게 끝내기 어렵다는 것인데요. 이는 기능을 기준으로 전체를 부분으로 나누어 개발을 진행했던 Top-Down 방식과 유사한 문제를 보입니다.

기획자가 개발자에게 세부 사항을 자세히 전달하더라도 개발자의 결과물은 처음 의도와 다르게 나올 수 있습니다. 문제는 이러한 오류가 발생하더라도 완성이 되어 다음 단계로 넘어 갈 때까지 발견할 수 없다는 점입니다.

프로그래밍은 견고한 뼈대를 바탕으로 코딩을 하기 때문에 완성본에 수정 사항이 생기면 고치기가 매우 까다롭습니다. 자칫 잘못하면 처음부터 다시 만드는게 더 좋을 정도니까요.

따라서, 이를 보완하기 위해 나온 새로운 방식이 애자일입니다. 애자일의 사전적 정의는 '재빠른, 민접한'입니다. 결과물을 만들어 미리 확인하고 수정하며 진행하는 방식이기 때문에 이러한 이름이 붙여진 것이죠.

전체 프로그램을 한 번에 만드는 것이 아니라 적당한 크기의 기능으로 나누고 각 기능에 대해 문서로 전달하는 것이 아니라 실행 가능한 소프트웨어로 전달함으로써 완성하기 전 미리 동작을 확인할 수 있습니다.

이러한 방식을 활용하면 완성되기 전 기획자의 의도에 맞게 일이 진행되고 있는지 확인할 수 있고 직접 사용해 보며 의견을 수정할 수도 있습니다.

복잡해지는 소프트웨어와 변화의 주기가 짧아지고 있는 요즘 산업의 트렌드에는 변화에 유연한 대처가 가능한 애자일 방식이 선호되고 있습니다. 최근에는 조직 내에서 애자일 방식이 잘 실현될 수 있도록 Scrum과 Kanban 같은 시스템이 적극 활용되고 있습니다.

애자일이 많은 장점을 지니고 있긴 하지만 그렇다고 해서 폭포수 방식이 무조건 나쁘다고는 할 수 없습니다. 팀 구성원이나 만들고자 하는 제품의 성격, 팀 문화에 따라 폭포수 방식이 필요한 조직도 분명히 있기 때문이죠.

단계별로 데드라인을 정해놓고 진행되기 때문에 각 단계가 복잡하지 않을 때에는 폭포수 방식이 더 효율적일 수 있습니다. 애자일은 단계를 여러 개로 나누고 반복적으로 진행하기 때문에 일이 복잡해진다는 단점을 가지고 있기도 하구요.

상황에 맞게 둘을 섞어 쓰거나 변형해서 쓰기도 합니다. 중요한 것은 조직 내에서 이러한 업무의 흐름을 파악해야 일을 잘하는 프로그래머로 인정 받을 수 있다는 점입니다.

🧙‍♂️ 테스트 프로세스

여러분은 버그(Bug)라는 말을 많이 들어보셨나요? 프로그램에서 의도하지 않은 동작, 유도하지 않은 에러를 버그라고 하는데요. 버그라는 단어는 유명한 개발자 중 한 명인 그레이스 하퍼의 일화에서 나왔다고 합니다.

하퍼는 고장난 컴퓨터의 회로에서 나방 한 마리를 발견했는데요. 이 이후, 컴퓨터에 문제가 발생하면 버그라고 칭하게 되었다는 설이 있습니다. 버그라 불렸던 이 나방은 현재 스미스 소미언 박물관에 보관 중이라고 하네요. 😂😂😂

버그를 방지하려면 미리 소프트웨어를 테스트해봐야 하는데요. 주로 개발자가 개발 단계에서 미리 테스트를 진행해보기도 합니다. 테스트가 반복 작업을 요하는 만큼 최근에는 자동화 테스트 도구테스트 코드가 개발되고 있습니다.

개발 단계에서 발견하지 못한 버그나 특정 상황에서만 발생하는 버그를 잡아내기 위해 테스트 부서를 따로 마련해 둔 기업도 있습니다. 때로는 신뢰도를 중요시하는 테스트 부서와 정해진 시간 안에 개발을 완료하고자 하는 개발 부서 사이의 신경전이 벌어지기도 합니다. 둘 사이의 조율이 가장 중요하겠죠.

소프트웨어에는 많은 버그가 발생하곤 합니다. 하지만 넘쳐나는 버그를 일일히 처리하기에는 시간이 부족한데요. 따라서 테스트에도 프로세스 관리가 필요합니다.

버그를 효과적으로 관리하기 위해 Jira, asana, Trello와 같은 버그 관리 툴이 존재합니다. 버그 관리 툴을 자세히 살펴보면 누구나 기록이 가능한 버그 관리 페이지가 있는데요. 어떤 상황에서 버그가 나타났는지, 누가 그 문제를 해결할 수 있는지, 얼마나 시급한 버그인지를 기입할 수 있는 항목이 있습니다. 이를 이슈(Issue)라고 하고 이슈를 관리하는 프로그램을 이슈 트레킹 툴이라고 합니다.

이슈 트레킹 툴을 활용하면 테스트 관리자는 원하는 시간에 버그를 확인할 수 있고 정해진 일정에 방해받지 않으면서 문제를 해결할 수도 있습니다. 잊어버릴 일도 없구요.

이슈의 상태는 크게 다섯 가지로 나뉩니다. 이슈가 생기면 Open 혹은 TO-DO, 개발자가 개선 작업을 진행 중이면 In-Progress, 문제가 해결되었거나 개발자가 작업을 완료하면 Resolved, 테스트 결과 버그가 잘 해결되면 Closed, 마지막으로 추가적인 문제 발생시 다시 Open 상태로 되돌아가는 Reopen이 있습니다. 각 단계에서 담당자를 정해주는 것은 Assign이라고 합니다. 이렇게 상태를 표시하면 관리자 입장에서는 버그의 관리를 더 효율적으로 할 수 있게 됩니다.

테스트 단계에서 주의해야 할 것은 이슈를 해결할 담당자가 제대로 정해져 있지 않거나 너무 많은 이슈를 한 사람이 해결해야 하거나 이슈의 우선순위가 정해지지 않아 시급한 문제를 처리하지 않거나 하는 문제가 발생할 수 있다는 점입니다. 따라서, 기업은 Project Manager를 두고 전체적인 테스트 과정을 지휘할 수 있도록 하고 있습니다.

🧙‍♂️ 버젼 관리

학창시절, 과제를 제출하기 전 여러 번 수정을 거쳐 파일을 새로 만든 적이 있나요? 새로 파일을 만들 때마다 '최종', '최종2', '최종최종최종' 등 이름을 정하는 경우도 많았습니다. 문제는 이렇게 파일을 많이 만들어 놓으면 어떤 것이 진짜 최종 자료인지 확인할 수 없게 되는 상황이 생긴다는 것입니다.

프로그램을 개발할 때도 마찬가지입니다. 여러 사람이 함께 만들기 때문에 누가 이 코드를 만들었는지, 어떤 의도로 만들었는지, 어떤 코드가 수정되었는지 알지 못해 수정과 삭제에 대한 판단을 제대로 할 수 없어 여러 개의 복사본을 만들게 됩니다.

시간이 지나 프로그램에 에러가 발생하면 코드에 언제, 어떤 변화가 생겼는지 파악이 불가능합니다. 이렇게 되면 처음부터 모든 코드를 다 살펴봐야 하는 불상사가 나기도 하죠.

이런 문제를 해결하기 위해 개발자들은 버젼 관리를 합니다. Git이나 Github라는 말을 들어보셨나요? Git은 버젼 관리를 하는 소프트웨어이고 Github는 git을 이용해 코드를 저장하는 온라인 저장 공간입니다.

프로그램은 발표 자료나 과제처럼 여러 수정본을 가지고 있지 않습니다. 코드의 수정 내용과 순서를 확인하기 어렵고 똑같은 부분으로 용량 부족이 생기는 것을 방지하기 위해서죠.

Git에서는 수정사항이 생기면 전체 복사본을 만드는 것이 아니라 수정 사항 정보만 추가적인 페이지에 기록이 됩니다. 이때 수정의 의도도 함께 기록해둡니다. 특정 수정 버젼을 클릭하면 처음부터 그곳까지의 수정사항만 확인할 수 있습니다. 용량도 줄일 수 있고 수정사항에 대한 코멘트도 확인할 수 있어 수정 이력을 파악하기가 매우 쉽습니다.

Git의 또 다른 장점은 조금씩 변형이 필요한 여러 버젼의 프로그램을 만들 때 효과적이라는 것입니다. 넷플릭스를 결제해 본 경험이 있나요? 넷플릭스는 사용할 수 있는 서비스 범위에 따라 사용자를 라이트, 스탠다드, 프리미엄으로 나누는데요. Git을 활용하면 공통 코드에서 파생되는 라이트 유저만의 서비스, 스탠다드 유저만의 서비스, 프리미엄 유저만의 서비스를 각각 만들 수 있습니다. 수정사항이 생기면 필요한 부분만 추가하면 되는 것이죠.

이러한 과정을 하나의 뿌리에서 뻗어나가는 브랜치(Branch)라고 부르기도 합니다. 이를 응용하면 실행 기기별 프로그램을 따로 제작할 수도 있겠죠?

현직자에게 동료 개발자가 이것만큼은 꼭 알았으면 좋겠다라는 설문을 진행했을 때 가장 많이 나온 답변이 Git을 다룰 수 있었으면 좋겠다라는 것이었습니다. 버전 관리는 팀 단위 개발에서 빛을 발하기 때문에 개발을 시작하기 전 Git을 충분히 익히고 시작하는 것이 좋을 것 같습니다.

🧙‍♂️ 통합 개발 환경 IDE

개발자의 컴퓨터에는 항상 IDE라는 프로그램이 켜져있습니다. IDE란, Itegrated Development Environment의 약자로 통합 개발 환경을 말합니다. IDE는 개발자들이 코딩할 때 도움이 되는 기능을 모아둔 프로그램입니다. 대표적인 IDE에는 비쥬얼 스튜디오, 이클립스, 인텔리제이가 있습니다.

코딩은 텍스트로 작성되기 때문에 메모장에서 실행이 가능합니다. 하지만 실행 속도를 생각하면 IDE를 활용할 때보다 꽤 많이 느립니다.

IDE의 필요성을 예시와 함께 살펴 보겠습니다. 비쥬얼 스튜디오에서는 줄이 바뀜에 따라 들여쓰기를 자동으로 제공합니다. 이는 Python의 아주 기본적인 스타일 가이드 중 하나인데요. 의식하지 않아도 저절로 들여쓰기를 해주니 아주 편하겠죠?

코드를 적을 때, 완전히 다 적지 않아도 미리 여러 예시들을 제시해주는 자동 완성 기능도 제공합니다. 예컨대, if의 i만 적어도 i로 시작되는 코드들을 같이 제시해주는 것이죠. 심지어 명령어의 옆에는 구문과 사용법을 함께 띄워주고 해당 코드를 선택했을 때, 구문의 템플릿이 자동으로 편집기에 입력됩니다.

변수명을 변경할 때도 유용한 기능을 제공합니다. 한글에서 ctrl+f로 단어를 찾아 한 번에 바꾸는 기능을 사용해본 적이 있나요? IDE를 활용하면 최초 선언문의 변수명만 바꾸면 나머지 변수명이 함께 바뀝니다. 정말 편리하죠? 이때, 같은 용도와 쓰임이 있는 단어만을 변경해주는데 자세한 내용은 이후에 더 알려드리도록 하겠습니다.

이처럼 IDE는 코드를 효율적으로 작성할 수 있는 많은 기능들을 제공합니다. IDE의 종류가 다양한만큼 자신에게 맞는 IDE를 골라 익숙해질 때까지 사용하다보면 좀 더 빠르게 코딩을 작성할 수 있습니다.

🧙‍♂️ 유용한 프로그램들

IDE외에도 개발자들이 유용하게 사용하는 프로그램들이 있는데요.

프로젝트를 관리해주는 도구 Jira, Trello, Asana, Confluence와 메신저 Slack, Skype, Jandi, 그리고 디자인 협업 툴인 Sketch 등 정말 다양한 프로그램들을 개발자들이 활용하고 있습니다.

이밖에 더 많은 프로그램을 알고 싶다면 StackShare라는 홈페이지를 참고해보시길 바랍니다.

* 이 자료는 CODEIT의 컴퓨터 개론 강의를 기반으로 작성되었습니다.
profile
There's Only One Thing To Do: Learn All We Can

0개의 댓글