본 연구는 디자인산업과 국가경쟁력 강화를 위해 기술개발 투자가 필요한 주요 디자인 기술을 도출하는 것을 주목적으로 함.
디자인기술의 중요성에도 불구하고, 디자인기술 관점에서의 체계적 연구개발 투자가 미흡한 한계를 극복하기 위한 토대를 확보
- 제품 및 서비스 개발 관점이 아닌, 디자인기술 관점에서의 연구개발 방향 및 과제를 도출하고, 연구개발 추진 전략을 수립
디자인 수요 등의 변화 전망을 토대로, 기업의 디자인기술 및 역량수준 제고를 위하여 필요한 핵심 디자인기술을 제시
- 기업의 단계별 디자인역량 강화 방향의 전략적 근거가 될 디자인로드맵 수립
- 시장 및 수요산업, 미래 소비자 트렌드의 변화 동향 및 전망을 토대로 정부와 기업에게 전략적 기술개발 및 투자방향을 제시
- 다양한 산업에서 디자인혁신을 이루기 위한 전략을 도출하는데 지속 활용할 수 있는 체계 마련
디자인기술로드맵은 다음과 같은 핵심 내용을 중심으로 수립
- 디자인 특성을 고려한 기술로드맵 수립 프레임워크의 수립
- 디자인기술 수요 및 요구조건 등에 대한 검토를 토대로, 주요 개발 대상 디자인기술을 제시하는 디자인기술로드맵 수립
- 디자인기술로드맵을 토대로 한 디자인기술개발 추진전략의 제시
연구진
김윤집 한국디자인진흥원 경영기획실 실장
조두현 한국디자인진흥원 정보지원실 실장
송효식 한국디자인진흥원 전략연구팀 팀장
조진희 한국디자인진흥원 정책개발팀 과장
윤성원 한국디자인진흥원 전략연구팀 과장
이석로 한국디자인진흥원 전략연구팀 대리
김진우 한국디자인진흥원 사업지원팀 과장
김지혜 한국디자인진흥원 성과관리팀 대리
허민구 크리액티브컨설팅 대표이사
김선하 크리액티브컨설팅 책임컨설턴트
강민수 크리액티브컨설팅 선임컨설턴트
이진주 크리액티브컨설팅 컨설턴트
첫 인쇄 2012.09.30
발행처 한국디자인진흥원 전략연구실
발행인 이 태 용
주소 경기도 성남시 분당구 양현로 322
코리아디자인센터 한국디자인진흥원 031) 780-2067
웹사이트
한국디자인진흥원 http://www.kidp.or.kr
디자인DB http://www.designdb.com
편집 및 디자인 스테레오타입 02) 512-6538
“이제는 제품이나 서비스의 시대가 아니라 브랜드의 시대이다”
브랜드의 시대라는 것은 과연 어떤 시대를 말하는 것일까요?
‘무엇’을 만드느냐 보다 ‘누가’ 만드느냐가 더 중요해진 시대를 의미합니다.
고객이 무언가를 선택할 때 얼마나 좋은 제품이고 서비스인지를 물론 보지만 그보다 더 중요한 것은 누가 만든 제품인지를 본다는 것이다. 누가 만들었는지를 보면 후회하지 않을 믿을 만한 결정을 할 수 있기 때문입니다. ‘누가’를 비즈니스적으로 잘 표현해 주는 것이 바로 ‘브랜드’입니다.
개인이나 기업이 브랜드로 불린다면 그것은 후회하지 않고 믿을 수 있는 대상이 되었다는 의미입니다. 믿음과 신뢰는 그냥 생기지 않습니다. 업의 본질에 대한 확고한 철학과 진정성의 바탕 하에 어떤 가치를 제공할 것인지에 대해 고객에게 약속하고 지속적으로 지켜나가면서 고객이 실제로 경험해가는 과정을 통해 만들어집니다. 궁극적으로는 고객이 애착을 갖고 사랑하는 수준이 되어 특별한 관계가 맺어지게 되는 것입니다. 이런 관점으로 비즈니스를 해 나가는 것이 브랜드 관점으로 비즈니스를 해 나가는 것입니다
boost라이브러리 중에서 가장 많이 사용하는 기능인 BOOST_FOREACH()와 shared_ptr의 내부 구조를 분석합니다. 그리고 boost의 내부 구현에 사용된 이 기능을 프로그래밍에 응용하는 방법을 제시합니다.
* BOOST_FOREACH 구조 분석 및 응용
* shared_ptr 구조 분석 및 응용
[TechDays Korea 2015] 녹슨 C++ 코드에 모던 C++로 기름칠하기Chris Ohk
기존에 작성해 놓은 C++ 코드에 모던 C++를 적용하기는 쉽지 않습니다. 막상 개선하려고 마음먹었다고 해도, 어디서부터 바꿔야 할 지 막막하기만 합니다. 이 세션에서는 기존 C++ 코드에서 모던 C++를 적용해 프로그램의 구조와 성능을 개선하는 방법에 대해서 설명합니다. 그리고 기존 C++ 코드에 모던 C++를 적용할 때 주의해야 될 점에 대해서도 살펴봅니다.
왜 프로그래머가 가독성을 향상시키는 수련을 평생 해야 하는지를 알려준다. 단지 상투적인 이유만 들먹이는 게 아니다. 좋은 가독성은 프로그래머를 프로로 만들어주고, 큰 기쁨을 주며, 성장할 기회를 준다고 역설한다. 가독성을 향상시키려면 눈에 보이는 것들부터 신경을 써야 하며, 코드 자체가 프로그램을 설명해야 하며, 흐름을 단순화하고 주석을 잘 쓰고 퇴고해야 한다는 간단한 원칙부터 지켜나가야 한다.
"메카 액션 게임 『DAEMON X MACHINA』 신념과 피와 강철의 개발사례" 강연 슬라이드의 한글 번역입니다.
원문:
https://www.slideshare.net/EpicGamesJapan/ue4-festeast2019-dxm
영상:
https://www.youtube.com/watch?v=jykrWtBQEz0
2. 하드코딩
• 데미지 계산의 예
• 데미지 = 공격력 – 방어력 * 0.5
• 위 0.5는 기획자가 임의로 정한 방어력 보정치
• 이상적인 경우
• 게임 설정 데이터에서 값을 읽어오게 하여 기획자가 바꿔가며 테스트
할 수 있도록 함
3. 하드코딩
• 0.5의 성질을 다시 생각해보자.
• 기획자가 자주 바꿀 값인가?
• 자주 사용되는 값인가?
• 데이터 관리자로부터 값을 가져오게 될텐데, 부하 문제는 없는가?
• 저 숫자 하나를 가져오기 위해 전용 데이터 관리자를 만들어야 하나?
4. 하드코딩
• 함수에 0.5를 박아넣자!
• 대대적인 개편이 아니면 데미지 공식은 자주 안바뀜
• 자주 사용되는 기능임
• 당장 빨리 개발해야함 <- 제일 중요!!
func CaluclateDamage(attack, defense)
{
return attack – defense * 0.5;
}
5. 하드코딩을 하는 건 좋은데…
• 한달 후 다른 개발자가 데미지 계산 함수를 보았을 때
• 0.5의 의미가 뭘까? 절반으로 만들기 위한 건가?
• 그래서 기획자에게 물어보고 아래와 같이 주석을 추가했다.
• 데미지 공식이 개편되면 저 주석도 바꿔줘야 함
func CaluclateDamage(attack, defense)
{
// 0.5는 방어력 보정치
return attack – defense * 0.5;
}
6. 하드코딩을 하는 건 좋은데…
• 하드코딩하려 했던 대상을 다시 생각해보자.
• 데미지 = 공격력 – 방어력 * 0.5
• 데미지 = 공격력 – 방어력 * 방어력 보정치
• 0.5를 하드코딩하는게 아니라 “방어력 보정치” 를 하드코딩 해
야 한다.
• 매우 중요!!
7. 상수
• 프로그램 자체에 박힌 값으로 실행 중에 바뀌지 않는다.
func CaluclateDamage(attack, defense)
{
// 0.5는 방어력 보정치
return attack – defense * 0.5;
}
const var defenseAdjust = 0.5;
func CaluclateDamage(attack, defense)
{
return attack – defense * defenseAdjust;
}
8. 네이밍
• 코드에서 표현하고자 하는 대상에 이름을 붙여주는 것
• 앞의 예에서 적절한 네이밍을 통해 얻을 수 있는 장점은 어떤
것이 있었을까?
9. 네이밍
• 주석 없이 코드 자체만으로 내용을 이해할 수 있다.
• “공격력 – 방어력 * 방어력 보정치” 라는 자연어에 가까운 코드가 됨
• 다른 코드에서도 같은 값을 사용하고 있을 때 한꺼번에 수정하
기 쉬움
• 이건 위 장점을 달성하면서 부차적으로 얻을 수 있는 효과라고 생각함
func CaluclateDamage(attack, defense)
{
// 0.5는 방어력 보정치
return attack – defense * 0.5;
}
const var defenseAdjust = 0.5;
func CaluclateDamage(attack, defense)
{
return attack – defense * defenseAdjust;
}
10. 잘못된 네이밍의 예
• 1001 버프가 걸리면 1002, 1003 버
프가 함께 걸리는 하드코딩
• 코드만 봐서는 어떤 동작이 일어나
는지는 알 수 있지만 왜 이런 코드
가 들어갔는지는 알 수 없다.
var sniperBuff1ID = 1001;
var sniperBuff2ID = 1002;
var sniperBuff3ID = 1003;
func OnBuffApplied(buff)
{
if (buff.ID == sniperBuff1ID)
{
ApplyBuff(sniperBuff2ID);
ApplyBuff(sniperBuff3ID);
}
}
11. 잘못된 네이밍의 예
• 스나이퍼 모드가 되면 공격
력은 높아지지만 속도는 느
려지는 기획이었음
• 네이밍 수정만으로 주석이
필요없는 코드가 됨
• 거듭 강조!
• 하드코딩하려 했던 것은 1001
이라는 숫자가 아니라 “스나이
핑 모드 버프”
var sniperModeBuffID = 1001;
var sniperAttackBuffID = 1002;
var sniperSlowBuffID = 1003;
func OnBuffApplied(buff)
{
if (buff.ID == sniperModeBuffID)
{
ApplyBuff(sniperAttackBuffID);
ApplyBuff(sniperSlowBuffID);
}
}
12. 매우 긴 함수
• 플레이어가 맵에 입장했을 때
현재 맵 상태를 인코딩하는
함수
• 맵의 구성요소가 많을수록 함
수가 길어진다.
func EncodeMap()
{
// 맵 기본정보 인코딩
기상정보 인코딩
재생중인 배경음악 인코딩
// 모든 플레이어 인코딩
for (i = 0; i <= players.count; ++i)
{
i번째 플레이어 인코딩
}
// 드랍되어있는 아이템 인코딩
…
}
13. 매우 긴 함수 – 코드 블록에 네이밍
• 주석을 기준으로 코드
블록을 함수로 묶어냄
• 함수의 전체 흐름을 알
아보기 쉬워짐
• 자연어 문단 읽듯이 읽
을 수 있음
func EncodeMap()
{
EncodeMapInfo();
EncodePlayers();
EncodeDroppedItems();
} func EncodePlayers()
{
for (i = 0; i <= players.count; ++i)
{
i번째 플레이어 인코딩
}
}
func EncodeMapInfo()
{
기상정보 인코딩
재생중인 배경음악 인코딩
}
func EncodeDroppedItems()
{
…
}
14. 매우 긴 라인
func UpdateChargeStack()
{
if ((현재카운트 < 최대카운트) and (현재 시간 >= 마지막 충전 시간 + 충전 주기))
{
카운트++;
마지막 충전 시간 = 현재 시간;
}
}
15. 매우 긴 라인 – 논리 단위에 네이밍
• 거듭 강조하듯, 자연어 읽듯이 코드를 읽을 수 있음
• 논리 단위로 테스트하기 용이함
func UpdateChargeStack()
{
if ((not IsMaxStacked()) and IsChargeInvervalOvered())
{
카운트++;
마지막 충전 시간 = 현재 시간;
}
}
16. 요약
• 대상을 정확히 표현할 수 있는 네이밍 사용
• 주석은 네이밍의 기준이 될 수 있다.
• 주석을 줄이려고 노력하면 명확한 코드 짜기에 도움이 된다.
• 주석에 너무 의존하면 함정 주석에 발목 잡힐 수 있음
• 논리 단위로 뽑아낼 수 있는 코드는 네이밍을 붙여 분리