스크럼

스크럼(scrum)은 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 뜻하는 럭비 용어에서 유래된 것으로, 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중 하나이다. 소프트웨어 개발 프로젝트를 위해 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트나 프로그램 관리에서도 적용될 수 있다.

개요

특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크다. 스크럼은 30일을 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 일반적인 권장 기간은 30일이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주 정도의 유연성을 가진다. 주기가 너무 짧으면 개발 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로, 적용해보면서 조율이 필요한 경우 조율하는 것이 좋다. 스크럼 과정을 통해 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해나가게 된다. 보통, 각 작업은 4시간에서 16시간 정도를 소요하도록 정한다. 물론, 작업을 정하고 할당하는 것은 팀 내에서 자율적으로 진행된다. 애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여긴다. 다만 다른 프로세스들에 비해 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 있다. 비즈니스 요구를 충족시키는 데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크 기법이다. 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게 하여, 복잡하고 정교한 제품을 생산하도록 한다.

특징

특정 언어나 방법론에 의존적이지 않고, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용범위의 개발 기법이다. 스크럼은 다음과 같은 특성을 가진다. 솔루션에 포함할 기능이나 개선점에 대한 우선순위를 부여한다. 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과와 적용할 기능이나 개선에 대한 목록을 제공해야 한다. 날마다 15분 정도 회의를 가지고, 항상 팀 단위라 생각해야 한다. 이때 주의할 것은 보고하는 자리가 아니라 공유하는 자리라는 것이다. 이 프로젝트와 관련되어 한 일, 또는 이슈들을 공유해야 한다. 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지해야 한다.

역사

스크럼 방법론을 창조한 것은 제프 서덜랜드와 켄 슈와버이지만, 스크럼이랑 용어가 처음 등장한 것은 노나카 이쿠지로와 타케우치 히로타카가 하버드 비즈니스 리뷰에 발표된 ‘새로운 신제품 개발 방식’이었다. 이 글에 큰 영감을 받은 서덜랜드와 슈와버가 스크럼의 개념을 실천 기법으로 개발, 발전시키게 된다. 노나카와 타케우치가 왜 럭비 용어인 스크럼을 사용했는지에 대한 언급은 없지만, 스크럼의 핵심인 주도적인 팀 수행을 묘사하기 위해 사용한 것으로 추측된다. 생산성과 혁신을 나타내는 제조업체의 특성을 바탕으로 기업이 팀 안에서 서로 공을 주고받으며 하나가 되어 필드를 나아가는 럭비팀처럼 일체적 방법론을 사용한다고 비유하였다.

장점

스프린트마다 생산되는 실행 가능한 제품들을 통해 사용자와 충분히 의견을 나눌 수 있고, 일일 회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능하다. 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성된다. 다른 개발 방법론들에 비해 단순하고 실천 지향적이다. 스크럼마스터는 개발 팀원들이 목표달성에 집중할 수 있도록 팀의 문제를 해결한다. 프로젝트 진행 현황을 볼 수 있어, 신속하게 목표와 결과를 추정할 수 있고, 목표에 맞게 변화를 시도할 수 있다.

단점

스프린트가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 한다. 그런데 이 작업이 많아지면 그만큼 작업 시간이 더 필요하다. 일일 스크럼 회의를 15분 정도로 제한해 두었는데, 15분 안에 회의를 끝내기는 어렵다. 회의가 길어지게 될 경우 작업 시간이 늦어지고 이로 인해 작업하는데 상당히 방해를 받을 수도 있다. 또한 매일매일 회의를 해야 한다는 부담이 있을 수 있다. 투입 인원수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지는 알기 어렵다. 또한 스크럼은 프로젝트의 관리를 중점으로 하기 때문에 스프린트 수행 후 검토 희의를 하지만 프로세스 품질을 평가하지 않아 품질 관련 활동이 미약하고, 따라서 품질의 정도를 알 수 없다. 검사를 있다 하더라도 부실한 품질평가가 이루어진다.

진행순서

제품 백로그 작성

제품 책임자가 사용자 스토리를 기반으로 제품 백로그(product backlog)를 작성한다. 이때 사용자 스토리는 사용자의 관점에서 작성이 되어야 한다. 제품 백로그는 이해 관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말한다. 우선순위를 가지며, 위에 있을수록 우선순위가 높고 상세화되어 있다. 사용자 스토리란 고객이나 개발자 모두 이해할 수 있도록 고객이 작성하는 것이다. 카드(card), 대화(communication), 테스트(test) 세 가지를 이용하여 작성한다.

• 카드: 고객의 요구 사항을 문서화하기보다는 표현하기 위한 것으로 대화의 매개체 역할을 한다. 누가, 왜, 무엇을에 대한 정보가 다 포함되어 있어야 한다.
• 대화: 카드 내용의 세부사항을 구체화시킴으로서 인수 기준이 정해지고, 이해의 공유를 촉진시킨다.
• 테스트(Confirmation): 대화에서 논의한 인수 기준을 통해 스토리의 완료 여부를 판단한다. 인수 기준이 만족되었는지 여부를 확인하기 위해 긍정적인 테스트와 부정적인 테스트를 모두 사용해야 한다.

스프린트 계획 회의

제품 책임자, 스크럼 마스터, 개발팀이 참여하며 제품 백로그를 기반으로 스프린트 목표와 스프린트 백로그를 계획하는 회의이다. 스프린트 계획 파트 1과 스프린트 계획 파트 2로 나뉘는데, 2주 단위의 스프린트를 기준으로 총회의 시간은 4시간을 넘지 않도록 해야 한다. 스프린트 계획파트 1에서는 스프린트 동안 무엇을 할지 우선순위가 높은 아이템들을 검토하고 스프린트 목표를 정한다. 대체로 이 아이템들은 지난 스프린트에서 제품 백로그 개선을 하는 동안 잘 분석되었기 때문에 이 회의에서는 간단한 질문에 대해서 다시 한번 명확히 하는 작업만 진행된다. 제품 책임자와 팀은 제품 백로그의 우선순위가 높은 아이템들의 목표와 내용에 대해서 정의하며, 이런 우선순위를 통해 팀원들은 제품 책임자의 생각을 알게 된다. 스프린트 계획 파트 2에서는 스프린트 계획 파트 1에서 결정한 무엇을 어떻게 실행할지에 대해 정한다. 스프린트 계획 파트 2를 정확히 어떻게 해야 하는지에 대해서는 정의하지 않는다. 어떤 팀은 새로운 스프린트를 계획하는 데 이전 스프린트의 속도를 사용하기도 하고, 그들의 수용 능력을 계산하기 위해 더 세분화된 방법을 쓰기도 한다. 스프린트 계획 회의가 끝날 때쯤, 개발팀은 각 스프린트가 끝날 때마다 어떤 결과물을 내놓을 것인지 대한 현실적인 목표를 정하는데 이것을 스프린트 약속이라고 한다. 전에 수행했던 스프린트의 경험을 바탕으로 학습한 내용이 반영되어야 한다는 것이 핵심이다.

스프린트 백로그 작성

제품 백로그에서 결정된 우선순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다. 스프린트 목표를 구현 가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행한다. 많은 팀들이 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이것을 스크럼 보드(scrum board)라고 한다.

일일 스크럼 미팅

일일 스크럼 미팅은 개발원들이 늘어지는 것을 막기 방지하기 위해 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행된다. 제품 책임자의 참석은 옵션이고, 매일 정해진 시간에 정해진 장소에 모여서 15분~20분 동안 간단하고 빠르게 진행한다. 어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애 요인 등을 공유하며, 문제가 있을 경우 미팅 후 바로 해결한다. 일일 스크럼 미팅을 지속적으로 할 경우 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방할 수 있다. 개발 팀원들은 매일 스프린트 백로그에 있는 현재 작업을 완료하기 위해 작업이 얼마나 남았는지 번 다운 차트를 통해 진척도를 추적한다.

실행 가능한 제품 개발

각 스프린트마다 목표는 실행 가능한 제품을 만들어서 배포하는 것이다. 매 스프린트의 결과로써 나오는 산출물을 잠재적으로 출시 가능한 제품 증분이라고 부른다.

스프린트 리뷰

스프린트가 종료되었을 때 개발팀이 스프린트 동안 개발한 증분의 기능을 고객을 포함한 이해 관리자들에게 보여주고 피드백을 받는 과정을 말한다. 고객은 자신이 요청한 요구사항이 해당 스프린트 동안 제품이 잘 반영되었는지 평가한 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다. 스프린트의 한주당 스프린트 리뷰 시간은 한 시간으로 제약되어 있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야 한다.

스프린트 회고

스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을 도출함으로써 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말한다. 스프린트 회고 과정에서 스크럼 마스터는 중재 및 조정 역할을 하는 퍼실리테이터(facilitator) 역할을 할 수 있다. 스프린트 회고 과정을 통해 이미 정해진 프로세스로만 프로젝트를 수행하는 것이 아니라 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 한다.

다음 스프린트 시작

스프린트는 제품 책임자가 제품을 출시할 준비가 되었다고 판단할 때까지 계속된다. 스프린트가 회고가 끝나면 휴식 기간 없이 바로 다음 스프린트를 진행한다.

역할

제품 책임자

약자로 PO(Product Owner)라고도 하며, 제품 백로그를 관리, 작성하고 이해 관리자로부터 요구사항을 추출하여 제품 백로그에 반영하는 일을 한다. 고객 밑 조직 가치에 기반하여 제품 백로그 항목들의 우선순위를 매기고 각 스프린트마다 결과를 검토하여 우선순위를 관리, 조정한다. 단 한 명이어야 한다. 팀에 소속되어 있지만, 팀 밖에 있는 고객, 사용자 등 여러 이해관계 당사자들과 대화를 하는 유일한 사람이어야 하고, 팀에 들어오는 압력을 컨트롤할 수 있는 유일한 사람이어야 한다. 소프트웨어 개발 역량이 꼭 필요한 것이 아니기 때문에 개발 영역에 있는 사람이 아닌, 제품을 사용할 고객 또는 비즈니스 요구사항을 정의할 수 있는 사람에게 맡기는 경우도 있다. 투자 수익률을 최대화해야 할 책임이 있기 때문에 상업적인 제품의 경우, 손익에 대한 책임이 있다.

스크럼 마스터

일반적인 프로젝트 관리자들과는 다르게 업무 지시, 통제를 하는 것이 아니라, 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행 중 문제가 생겼을 때 잘 해결할 수 있도록 도와주는 역할을 한다. 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야 한다. 일일 스크럼 회의를 주관하여 팀의 진척도를 모니터링하고, 팀의 생산성에 악영향을 미치는 정책, 절차, 구조를 공론화하는 역할을 한다. 스크럼 마스터와 제품 책임자는 초점이 매우 다르고, 병행할 경우 혼란이나 충돌이 생길 수 있기 때문에 동일한 사람이 맡을 수 없다.

개발팀

스크럼 팀(scrum team) 또는 DT(Development Team)이라고도 부르며 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는, 앞의 2 역할을 제외한 모든 팀원을 뜻하며 주로 5~7명 정도로 이루어진다. 프로젝트 수행에 필요한 모든 역량을 갖춘 팀으로 이를 위해 관련된 모든 부서로부터 팀원이 구성되며, 팀원은 자신의 전문 영역에 고정되지 않고 다 같이 팀 과제를 수행한다. 자율 관리 조직으로 따로 리더가 정해져 있지 않으며, 팀 스스로가 외부의 명령 없이 스프린트 목표를 달성하기 위해 업무 분량, 목표, 달성 방안을 결정하고, 최상의 방법을 결정한다. 주의가 분산되거나 흐름이 바뀌면서 낭비되는 것을 막기 위해, 동시에 여러 프로젝트나 작업을 진행하는 것을 피해야한다. 팀이 안정적일수록 팀의 생산성이 높아지기 때문에 팀원이 중간에 바뀌는 것은 피해야 한다.

추구 가치

• 용기: 팀원 간 갈등과 도전을 위한 용기를 가져야 한다. 해당 기능이 이해가 안 되거나 문제가 있는 경우 일을 더 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득시킬 용기가 있어야 한다.
• 집중(전념): 한 번에 하나씩 일을 마무리하고, 업무에 집중할 수 있도록 불필요한 회의 참석은 지양해야 하며, 주기적인 반복 작업은 제거하거나 자동화해야 한다.
• 헌신/책임: 팀의 목표 달성을 위해 개개인이 공약한 목표를 달성하도록 팀에 헌신하고, 필요한 모든 권한을 부여해야 한다. 개인보다 팀과 공동 목표 달성이 우선이고, 가치 있는 소프트웨어를 개발할 수 있도록 최대한의 지원과 권한이 필요하다.
• 존중: 개개인별로 장단점이 있을 것이고, 그 사람이 그렇게 할 수밖에 없는 이유가 있을 것이다. 팀원 서로를 존중할 필요가 있다.
• 투명성/개방성(정직): 프로젝트에 대한 모든 내용을 투명하게 공개해야 한다. 제품백로그, 스크럼회의, 스프린트 리뷰 등을 통해 공유되어야 하며, 자신에게 불리해도 숨기지 않고 도움을 청해야 한다.

주요 용어

제품 백로그

제품 완성에 필요한 특성, 기능, 개선점 등 제품의 모든 요구사항(사용자 스토리)을 우선순위에 따라 나열한 목록이다. 사업 환경이나 변화에 따라 지속적으로 업데이트되며 좋은 제품 백로그는 DEEP로 표현할 수 있다.

• detailed appropriately: 최우선 순위의 아이템은 낮은 우선순위의 아이템보다 먼저 진행되기 때문에 더 상세하고 세밀하게 기술되어있어야 한다.
• Estimated: 현재 릴리즈의 각 아이템들은 추정이 필요하며 매 스프린트마다 팀원들이 무언가를 배우고 새로운 정보가 생기므로 다시 추정되어야 한다. 팀은 제품 책임자에게 제품 백로그의 각 아이템에 해당하는 일의 양과 기술적인 위험성에 대한 추정치를 제공해야 한다. 제품의 책임자와 다른 사업적인 이해 관계자들은 들은 제품 요구사항의 가치에 대한 정보를 다양한 이해관계자들에게 전달해야한다. 이 정보에는 수익이나 비용 절감, 사업적인 리스크, 중요성이 포함될 수 있다.
• Emergent: 학습한 내용이나 변동되는 것들에 맞추어 제품 백로그는 자주 개선된다. 매 스프린트마다 우선순위에 따라 아이템들이 추가되고 제거되고 수정되며 쪼개지고 변경된다. 그러므로 고객의 니즈 변화, 새로운 아이디어, 경쟁사의 움직임, 기술적인 걸림돌 등을 반영하기 위해서 제품 책임자는 계속해서 제품을 업데이트해야 한다.
• Prioritized: 제품 백로그의 최우선 순위 아이템부터 1에서 N까지의 순서로 우선순위가 매겨져야 한다. 최우선 순위의 아이템들은 적은 비용으로 큰 가치를 내는 것이나, 큰 위험을 포함하고 있는 아이템이다. 전통적인 개발 방식에서는 높은 효과 순으로 결과를 내는 것이 강조되지는 않지만, 스크럼에서는 중요하다. 아이템 위주의 추정 방법을 적용하기에 불명확할 경우, 전반적인 경영 성과를 바탕으로 접근할 수 있다. 이런 경우 성과에 관련된 여러 개의 아이템들이 한 번에 전달되어야 가치를 만드는 경우에 해당되며, 제품 책임자는 최소 기능 제품에 대해서 다음번에 만들 증분을 정의한다. 이러한 방법들은 제안일 뿐, 스크럼에서는 제품 백로그의 아이템들을 표현하거나 우선순위를 매기는 방법에 대해서 정의하지 않고, 추정기술이나 추정 단위에 대해서도 고려하지 않는다.

백로그에는 무엇이 중요한지를 최소한으로 명시해야 한다. 모든 세부사항을 기록하는 것보다는 해당 아이템을 이해하는 데 필수적으로 필요한 것인지 무엇인지 명확히 기록하고, 제품 책임자, 이해 관계자들과의 대화를 통해 이를 늘려나가야 한다. 우선순위가 낮은 제품은 우선순위가 높은 제품에 비해 상세화가 덜 되어 있고, 크기가 크다.

이슈

• 스토리: 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것으로 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성하는 것이 좋다.
• 에픽(Epic): 많은 사용자 스토리, 많은 작은 단위 업무로 나눌 수 있는 업무의 큰 틀이다. 하나의 스프린트에 걸쳐서 끝나는 것이 아닌, 여러 스프린트에 걸쳐 종료되는 것으로 주요 기능들을 중심으로 정의된 여러 스토리들의 집합이다.
• 태스크(task): 에픽이나 스토리의 하위 작업으로, 에픽이나 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업이다. 유사 기능 조사, 테스트 시나리오 작성 등이 해당된다.
• 서브태스크: 스토리의 하위작업으로 에픽이나 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업이다.

완료 기준

완료기준(Definition of Done)은 인수 기준(Acceptance Criteria)이라고도 하며, 사용자 스토리를 완료시키기 위한 조건 명세다. 매 스프린트의 산출물은 잠재적으로 출시 가능한 제품 증분이라고 부른다. 첫 번째 스프린트를 시작하기 전에 제품 책임자, 팀, 스크럼 마스터는 제품 백로그의 아이템이 잠재적으로 출시 가능하기 위해서 필요한 모든 것에 대해 검토해야 한다. 제품을 출시하기 위해 필요한 모든 활동은 ‘잠재적으로 출시 가능’이라는 말의 정의에 포함되어야 하며 그렇기 때문에 스프린트 기간 동안 끝나야 한다. 팀이 각 스프린트마다 잠재적으로 출시 가능한 제품을 전달하고자 하는 목표를 이루지 못하는 경우가 있는데, 이는 팀의 자동화가 덜 되었거나 충분하게 다기능 적이지 않기 때문이다. 시간이 지날수록 더 나아져, 이 문제가 해결되겠지만 시작을 위해서는 현재의 역량에 대한 기능을 만들 필요가 있다. 좋은 제품 책임자는 항상 완료 기준이 가능하면 잠재적으로 출시할 수 있을 수준에 가깝게 잡혀서 개발이 투명해지고 지연되는 경우가 줄어들며 리스크가 감소하기를 원한다. 만약 완료 기준이 잠재적으로 출시 가능한 정도가 아니라면 리스크와 지연이 발생하게 될 릴리즈를 하게 될 때까지 계속 작업이 지연될 것이다. 스크림팀은 앞에서 나온 개선 사항들을 끊임없이 개선하여 완료 기준을 늘리는 데 반영해야 한다.

소멸 차트

번 다운 차트(Burn down chart)라고도 하며, 시간 대비 남아 있는 일의 양을 표현한 차트다. 작업물이나 백로그를 수직축에 표현하고 수평축에는 시간을 표현하여 모든 작업들이 완료되는 시점을 예측하는데 사용한다.

스크럼 보드

벽 크기의 업무 보드 형식으로 만든 스프린트 백로그다. 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판이다. 포스트잇에 적힌 작업들은 “할 일”, “작업 중”, “완료” 등이 있다.

참고자료

• Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde, 〈스크럼의 이론과 실천에 대한 가벼운 안내서Version 2.0〉, 《THE SCRUM PRIMER》
• 〈스크럼(애자일 개발 프로세스)〉, 《위키피디아》
• ZeddiOS, 〈thvmxmdnpdj 개발 방법론(애자일/스크럼〉, 《티스토리》, 2017-02-13
• 양민경, 〈애자일 방법론⓵: 스크럼(scrum)〉, 《뉴스레터》, 2018-06-19
• 민현기, 〈애자일 Scrum(스크럼) 이해하기〉, 《미디엄》, 2019-01-26
• 황선영, 〈스크럼의 진행 과정〉, 《미디엄》, 2019-07-17
• 행복한 앵그리비버, 〈[https://hanminwoo.com/33 애자일(Agile)과 스크럼(Scrum)과 지라(JIRA) 이야기〉, 《티스토리》, 2019-12-01
• 도전적인 HarimKang, 〈스크럼(Scrum) 이란?〉, 《티스토리》, 2020-02-04

같이 보기

• 애자일
• 스프린트
• 프레임워크
• 방법론

이 스크럼 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍 □■⊕, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 프로그래밍 언어 ASP • C 언어 • C++ • C# • CSS • D 언어 • HTML • HTML5 • JSP • PHP • R • XHTML • XML • XSLT • 고(Go) • 고급언어 • 기계어 • 델파이 • 러스트 • 루비 • 루아 • 리액트 • 리퀴디티 • 무브 • 미켈슨 • 베이직 • 브이비스크립트 • 비주얼 C++ • 비주얼베이직(VB) • 비주얼베이직닷넷(VB.NET) • 솔리디티 • 스몰토크 • 스위프트 언어 • 스칼라 • 스크립트 언어 • 알골 • 어셈블리 • 언리얼스크립트 • 얼랭 • 에이잭스(Ajax) • 엠에프씨(MFC) • 오브젝티브-C • 오브젝트 파스칼 • 오카멜 • 웹어셈블리(WASM) • 이와즘(eWASM) • 자바 • 자바스크립트 • 저급언어 • 제이슨(JSON) • 제이쿼리(jQuery) • 카멜 • 코볼 • 코틀린 • 콜드퓨전 • 타입스크립트 • 파스칼 • 파워스크립트 • 파이썬 • 펄(Perl) • 포트란 • 프로씨(Pro-C) • 피엘에스큐엘(PL/SQL) • 피엘원(PL/I) • 하스켈 개발방법론 CBD 개발방법론 • EA • 구조적 개발방법론 • 객체지향 개발방법론 • 라이브러리 • 람다 아키텍처 • 모듈 • 모듈화 • 벤치마킹 • 소프트웨어 개발방법론 • 스크럼 • 스프린트 • 아키텍처 • 아키텍트 • 애자일 • 웹개발방법론 • 정보공학 개발방법론 • 컴포넌트 • 테일러링 • 템플릿 • 폭포수 모델 • 프로젝트 • 프로토타입 • 피드백 코딩 EUC-KR • UTF-8 • 값 • 글루웨어 • 디버깅 • 디코딩 • 마크업 • 버그 • 부트스트랩 • 세이브포인트 • 소스코드 • 시큐어코딩 • 아스키 • 액티브엑스 • 오픈소스 • 유니코드 • 인코딩 • 재컴파일 • 주석 • 컴파일 • 컴퓨터 프로그램 • 코드 • 코딩 • 태그 • 테스트 • 테이블 • 텍스트 • 파싱 • 퍼블리싱 • 퓨니코드 • 하드코딩 • 하이퍼링크 • 하이퍼텍스트 프로그래밍 C 명령어 • 객체 • 객체지향 • 객체지향 프로그래밍 • 거짓 • 관계연산자 • 기본형 변수 • 널 • 논리 • 논리연산 • 논리연산자 • 다중상속 • 다형성 • 대입 • 대입문 • 대입연산자 • 더블 • 도스 명령어 • 디폴트 • 레지스터변수 • 루프 • 리눅스 명령어 • 리턴 • 메모리 주소 • 메소드 • 멤버 • 명령문 • 명령어 • 무한루프 • 문자 • 문자열 • 바이트 • 반복문 • 배열 • 변수 • 분기 • 분기문 • 불린 • 브레이크 • 비교연산자 • 비트연산자 • 산술연산자 • 상속 • 상수 • 생성자 • 선언 • 선언문 • 설정자 • 속성 • 스위치 • 스태틱 • 시프트연산자 • 실행 • 실행문 • 어노테이션 • 에코 • 역참조 • 연산 • 연산문 • 연산자 • 오버로딩 • 오버라이딩 • 외부변수 • 윈도우 명령어 • 유닉스 명령어 • 인스턴스 • 인스트럭션 • 인클루드 • 인터페이스 • 임포트 • 입력 • 입력문 • 입출력 • 입출력문 • 자료형(데이터 타입) • 자바 명령어 • 자바 예약어 • 자바 컬렉션 • 전역변수 • 접근자 • 접근제어자 • 정보은닉 • 정수형 • 정적변수 • 제어 • 제어문 • 제어자 • 조건 • 조건문 • 조건연산자 • 주소 • 증감연산자 • 지역변수 • 참 • 참조 • 참조변수 • 초기화 • 추상메소드 • 추상클래스 • 추상화 • 출력 • 출력문 • 캡슐화 • 케이스 • 클래스 • 파라미터(매개변수) • 파이널 • 패키지 • 퍼블릭 • 포인터 • 프라이빗 • 프로텍티드 • 필드(멤버변수) • 함수 • 환경변수 명령어 abstract • array • boolean • break • byte • case • char • continue • default • double • do while • echo • elif • else • else if • false • final • float • for • gosub • goto • if • if else • import • include • int • join • long • long long • null • print • printf • println • private • protected • public • return • scanf • short • stdio.h • static • string • switch • temp • then • true • unsigned • void • while 디자인패턴 구조패턴 • 동시성패턴 • 동시실행패턴 • 모델-뷰-컨트롤러 패턴 • 상태패턴 • 생성패턴 • 싱글톤패턴 • 아키텍처패턴 • 전략패턴 • 커맨드패턴 • 행동패턴 프로그래밍 인물 귀도 반 로썸 • 그레이스 머레이 호퍼 • 니클라우스 비르트 • 댄 브릭클린 • 더그 커팅 • 데니스 리치 • 리누스 토르발스 • 리처드 그린블라트 • 마거릿 해밀턴 • 마크 앤드리슨 • 빈트 서프 • 빌 게이츠 • 빌 조이 • 스티브 잡스 • 에이다 러브레이스 • 제임스 고슬링 • 척 벤턴 • 켄 톰슨 • 팀 패터슨 위키 : 자동차, 교통, 지역, 산업, 기업, 단체, 업무, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반