[C#] 명쾌한 abstract 메소드와 virtual 메소드 차이점

왠지 모르게 다들 어렵게 설명한다.
데브피아만 가도 “abstract는 없으면 인스턴스 생성 안되고 virtual 은 없어도 인스턴스 생성된다…”
한국 종특인 돌려말하기인지 모르겠지만, 초보들에게는 더럽게 이해 안되는 답변이다.
심지어 그런거 모르냐, 책을 읽어라, 알게된다. 이지랄까지 하고 있으니…
선배 개발자들 맞는지 의문 투성이다 정말. 먹고살기 빠듯한 건 아는데 그렇게 가르쳐주기 귀찮았냐 하는 생각이 든다.
내가 후배 개발자를 위해 간단명료하게 설명한다.

자. 네가 얻은 새로운 집에 시멘트만 있는 방 내부를 꾸미게 됐어.
이게 abstract class 다.

벽지는 붙여야지? 안그럼 방이냐? 폐가지.
그리고 장판 깔아야지 안그럼 맨발로 방 못들어가잖아.
그래서 벽지와 장판 붙이는 기능을 가진 메소드를 abstract로 선언한다.

좋아. 벽지는 일단 붙였어. 그럼 벽지에 데코를 붙이는 생각도 했을거야.
예를 들면, 벽에 뭐 매달거나, 야광 스티커를 붙이거나 할거야.
근데 이건 안해도 지장 없잖아.
그래서 벽지 데코를 붙이는 메소드를 virtual로 선언한다.

이해했지?

public abstract class 추상인테리어{
    public abstract 벽지 벽지칠하기();
    public abstract 장판 장판붙이기();
    public virtual 데코레이션 데코붙이기(){
        return null; // 기본 데코 안붙일거다.
    }
}

public sealed class 철수인테리어 : 추상인테리어{
    public override 벽지 벽지칠하기(){
        var 벽지칠 = new 벽지();
        var 벽지색 = 벽지색깔.파란색;
        //벽지 칠하는 프로세스 구현
        return 벽지칠;
    }
    public override 장판 장판붙이기(){
        var 장판깔기 = new 장판(장판.흔한거);
        //장판 까는 프로세스 구현
        return 장판깔기;
    }
}

public class 영희인테리어 : 추상인테리어{
    public override 벽지 벽지칠하기(){
        var 벽지칠 = new 벽지();
        var 벽지색 = 벽지색깔.분홍색;
        벽지칠.패턴 = 벽지패턴.꽃무늬;
        //벽지 칠하는 프로세스 구현
        return 벽지칠;
    }
    public override 장판 장판붙이기(){
        var 장판깔기 = new 장판(장판.예쁜거);
        //장판 까는 프로세스 구현
        return 장판깔기;
    }
    public override 데코레이션 데코붙이기(){
        var 데코 = new 데코레이션();
        데코.종류 = 스티커.야광(색깔.초록색);
        //데코 붙이는 프로세스 구현
        return 데코.다붙였다();
    }
}

존나 흔한 이름으로 클래스 붙였다.
끗.

composite / 2015년 8월 21일 / Piss Development / 3 Comments

XP_CMDSHELL 및 sp_OACreate 프로시저 좀 쓰지 마.

MS SQL Server는 Oracle에 비해 정말 편리한 기능을 가지고 있다.
그것도 SQL 상에서 콘솔 명령어 날릴 수 있고 심지어 OLE 라이브러리를 불러다 쓸 수 있다.

는 개뿔 보안에 최악 프로시저 형제 되시겠다.
일단, 왜 쓰지 말아야 하는지 나열하겠다.

1. 이 프로시저가 털리면 DB 서버 자체가 털리는 거나 마찬가지

말 그대로다. SQL Server는 보통 가장 높은 권한(SYSTEM 및 Administrator 등)으로 돌아가며,
기재했던 프로시저는 이 권한 그대로의 명령어와 루틴을 실행한다.
심지어는 자기 편리하려고 프로시저의 권한을 public으로 물리는 미친 새끼들도 있다.
절대 그러지 마라. DB 시스템 다 털린다. 데이터 다 빼가거나 변조, 심지어 삭제나 다운은 시간 문제다.
그리고 일 발생하면 엉뚱한 곳에서부터 분석하게 된다.

참고로 필자 경험인데, 연습삼아 구축한 MSSQL에 이 프로시저 public 열리고 며칠 만에 짱깨한테 어드민 계정 털려 들어가지도 못했다.
다행히도 XenServer로 구축한 가상 OS였고, 연습서버라 다행이지 만약 실서버였으면 사상 최악의 공황이 아닐 수 없을 거다.

2. 이 프로시저에 딸려온 프로세스 망가지면 SQL Server 자체가 다운되버리는 불상사 발생

XP_CMDSHELL 의 경우 딱히 말할 것도 없다. 예외 처리에서 파일명 올바르던 어쩌던 다음 SQL 구문 실행에 큰 영향을 주지는 않는다.
문제는 바로 sp_OACreate 프로시저다. 이 프로시저는 OLE 라이브러리를 SQL Server 엔진에서 직접 구동하고 예외 처리가 안된 상태에서 실행하기 때문에,
만약 예외 처리를 재대로 하지 않거나 예상치 못하게 프로세스 다운이 발생하면 이게 바로 SQL Server 서비스 다운으로 직결이다.

예기치 않게 DB가 다운되면 그다음 시나리오는 더이상 얘기 안해도 알지?

DB는 DB답게 쓰자. 부족하다고 헛짓거리 하다가 털리지 말고.
정 부족함을 채우고 싶다면 CLR을 써라. SQL Server 2005부터 각 버전에 맞게 CLR 인터페이스를 지원한다.
오라클 또한 Java 를 지원하여 SQL의 부족함을 채울 수 있다.

composite / 2015년 7월 27일 / Piss Development / 0 Comments

프록시 자동설정 원리

Weblock 이라는 아이폰 앱이 있다.
이 앱은 광고 사이트나 패턴을 정리해서 프록시 자동설정 파일 (Proxy Auto-config, PAC)을
만들어 적용하여 사파리 등의 웹 브라우저에서 짜증나는 광고를 안띄워주는
고마운 프로그램이다.

필자의 경우 이 Weblock 을 무료일 때 다운받았는데, 이 앱 덕분에 쾌적한 브라우징을 할 수 있었다.
그렇다면 이 원리는 무엇인가?

해답은 바로 Weblock 을 사용하면서 URL을 보면 js URL을 복사하는 부분에서 찾을 수 있다.
이 url 복사 후 붙여넣으면 js 소스가 뜨는데 이게 바로 PAC에서 사용하는 JS다.

운이 좋게도 이 PAC 스크립트를 작성하는 가이드를 한글로 제공한 고마운 분이 있으니,
미꾸라지 PAC (Proxy auto-config) 문법 링크를 참조하라.
이 글에서는 간단한 작성법만 나열하므로 PAC에 대한 전체적인 레퍼런스를 보고 싶으면 위 링크로 가도록.

먼저, 이 스크립트를 처음 작성한다면 먼저 JS에 대한 기초 지식이 요구되며, 단 3가지 문법만 기억하면 된다.

//1. 첫번째 프록시 접속 후 실패 시 두번째 프록시 접속. 세미콜론(;)으로 구분하여 작성하면 된다.
var PROXY_URL = "PROXY proxy1.example.com:8080; PROXY proxy2.example.com:8080";
//2. 프록시를 사용하지 않고 직접 접속하는 키워드이다. 
var DIRECT = "DIRECT";
//3. 이제 적용하기 위해 함수를 작성하는데, 함수명은 FindProxyForURL 이 되시겠다.
//   콘솔 프로그램의 main 함수와 같은 역할을 하는 프록시의 주 실행 함수이다.
function FindProxyForURL(url, host){
    // example.com 및 그 하위 도메인은 직접 접속하도록 한다.
    if (shExpMatch(host, "*.example.com"))
    {
        return "DIRECT";
    }

    // 임의 도메인을 접속 시 아래 지정된 IP와 마스크로 접속했을 경우
    // fastproxy.example.com 포트 8080 이라는 프록시로 접속하도록 한다.
    if (isInNet(host, "10.0.0.0", "255.255.248.0"))
    {
        return "PROXY fastproxy.example.com:8080";
    }

    // 그리고 마지막으로 모든 접속을 proxy.example.com 포트 8080 으로 접속한다.
    // 만약 프록시 응답이 없을 경우 할 수 없이 다이렉트로 접속한다.
    return "PROXY proxy.example.com:8080; DIRECT";
}

끝이다. 어때요. 쉽죠?
위 파일을 js로 저장 후, 각 브라우저에서 프록시 설정에서 자동 프록시 설정할 때 저 스크립트를 작성한 URL을 지정하면 된다.
아이폰이나 안드로이드 같은 모바일 환경에서는 Wi-Fi 연결 시 프록시에서 자동 선택 후, URL을 입력하면 된다.

자. 이제 이 PAC을 응용하여 간단한 Ad-block 스크립트를 작성하도록 하겠다.


//직접 접속 키워드 var PROXY_DIRECT = "DIRECT"; //차단 키워드 //Dummy Proxy로 차단한다. 해당 IP는 구글 DNS IP이다. //즉, 실제 프록시도 아니고 어자피 응답 실패하는 거 알지만 //이걸 이용해서 광고 사이트를 무조건 실패하는 프록시로 강제 접속하는 //마법의 키워드이다. var BLACK = "PROXY 8.8.8.8:53"; function FindProxyForURL(url, host) { var u = url.toLowerCase(); var h = host.toLowerCase(); //광고 호스트 중 하나인 onclickads.net 호스트이거나, 페북에서 사용하는 광고 이미지를 더미 프록시로 차단한다. if (dnsDomainIs(h, "onclickads.net") || shExpMatch(u, "*/fb*akamaihd.net/*image.php*facebook.com*ads*image*")) { return BLACK; } //나머지는 직접 접속으로 정상 접속하도록. return PROXY_DIRECT; }

그리고 이걸 당신의 웹호스팅이다 Github Page에 넣고 자동 프록시 설정 주소에 넣으면 광고차단 효과가 있을 것이다.
이게 끝인가? 맞다. 끝이다.

마지막으로 PAC 스크립트 작성시 주의점을 알려주겠다.

  • 몇몇 브라우저는 PAC 스크립트 파일의 인코딩을 시스템 인코딩에 따른다. 예를 들면 IE는 UTF-8을 인식할 수 없다. 특히 한글 입력은 왠만하면 하지 말자.
  • 크로스 플랫폼 PAC 스크립트를 작성 시 가능하면 옛날식 JScript 시절 표준을 따르는 것이 좋다. 각 브라우저나 OS 자바스크립트 엔진을 따르기 때문이다.

참고자료

composite / 2015년 7월 15일 / Piss Development / 0 Comments

2015년 6월 29일자 NoSQL 오픈소스 임베디드 DB 리스트

이번엔 약속대로 자바 기반의 임베디드 NoSQL DB를 소개한다.
Java 1.6에 내장된 Apache Derby DB(Java DB)는 소개에서 제외한다. SI/SM 개발자들 이거 자바 내장인거 알기나 하는지 내 알바 아니지만.
사족으로 역시 자바가 정말 다양한 방식의 NoSQL DB가 있다. 닷넷에서 아쉬우면 IKVM 써서 쓰는 방법이 있긴 하지만…

1. MapDB

MapDB is embedded database engine. It provides java collections backed by disk or memory database store. MapDB has excellent performance comparable to java.util.HashMap and other collections, but is not limited by GC. It is also very flexible engine with many storage backend, cache algorithms, and so on. And finally MapDB is pure-java single 400K JAR and only depends on JRE 6+ or Android 2.1+.

순수 자바로 만들어진 컬렉션 기반의 키값 DB. 메모리 및 파일 가능.
400kb의 가벼움과 안드로이드 지원으로 특히 안드로이드 개발자에게 사랑받고 있는 DB인 데다가
Apache License 2.0 이라 기업에서도 부담없이 사용 가능.

2. OrientDB

OrientDB is a 2nd Generation Distributed Graph Database with the flexibility of Documents in one product with an Open Source commercial friendly license (Apache 2 license). First generation Graph Databases lack the features that Big Data demands: multi-master replication, sharding and more flexibility for modern complex use cases.

순수 자바로 만들어진 Graph/Document DB. 서버/임베디드 모두 가능. NoSQL 계의 MySQL 같은 존재임.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
리플리케이션 및 셰딩이 지원되기 때문에 스케일링이 가능하면서도 Apache License 2.0으로 기업에서도 무료로 사용 가능.
자바를 사용하는 유명 기업에서 채용되기도 하였으며, 유료인 Enterprise Edition은 엔터프라이즈에 필요한 기능을 사용 가능. (개발/테스트 목적으로 무료로 사용가능)

3. Neo4j

Neo4j is used by thousands of organizations, including 50+ of the Global 2000, in mission-critical production applications. Developed by the inventors of the modern graph database, Neo4j is the only graph database on…

순수 자바로 만들어진 Graph DB로 OrientDB와 쌍벽을 이루고 있으나 우세. eBay나 National Geographic 등 세계 유명 기업에서 사랑받는 DB.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
리플리케이션 및 셰딩이 지원되기 때문에 스케일링이 가능한데 라이선스가 GPLv3 라 기업의 경우 내부시스템은 무료로 쓸 수 있으나 재배포 판매 시 소스 공개하던가 사던가 해야 함.
유료인 Enterprise Edition은 엔터프라이즈에 필요한 기능을 사용 가능. (30일 체험 사용 가능)

4. Titan

Titan is a scalable graph database optimized for storing and querying graphs containing hundreds of billions of vertices and edges distributed across a multi-machine cluster. Titan is a transactional database that can support thousands of concurrent users executing complex graph traversals in real time.

빅데이터를 위해 태어난 자바 기반의 Graph DB. 다른 NoSQL DB와 연동하는 기능이 특징.
Graph DB는 NoSQL 중에 Relational Schema를 지원하기 때문에 기존 SQL DB와 유사하게 사용 가능한 장점이 있다.
빅데이터 위주의 스케일링에서 강점이 있으며, Apache License 2.0이기 때문에 기업에서도 부담없이 사용 가능.

5. iBoxDB

iBoxDB is a fast transactional table style document NoSQL Application Database, easily store, process objects and documents, traditional table with unstructured data, zero configuration, pure JAVA and .NET engines, no dependencies.

iBoxDB has a well designed interface with great performance and capability for agile development, you can focus on the applications. It can embed into an application and deploy on mobiles, desktops, servers, then help designers to persist objects and documents thread-safely with transaction support.

.NET 과 Java 둘 다 품은 (그것도 IKVM도 아니고 독립적으로 각각 엔진 개발) 특이한 키값 기반 NoSQL DB.
.NET은 2 이상, Java는 6 이상이면 가능. 라이선스는 걍 무료. 오픈소스는 아님 (자바는 오픈되었으나 닷넷만 클로즈드)

6. JasDB

JasDB was designed with easy of use and minimal configuration in mind. JasDB can be installed and configured in almost no time at all. Use JasDB as an embedded DB inside your JVM or you can use it to store your unstructured data in JSON format. If you want to scale JasDB, simply run and use it through the REST webservice.

순수 자바로 만들어진 Document DB. REST 내장으로 서버로도 사용 가능. JSON 형식으로 저장하는 것이 특징.
안드로이드도 지원하며, MIT X11 License로 기업에서도 부담없이 사용 가능

… 자바로 만든 NoSQL DB 드럽게 많아서 더이상 나열 못하겠다.
NoSQL DB를 전문적으로 모은 사이트가 있으니 어느 언어 개발하던 상관없이 부족함을 채우고 싶다면 여기로 가서
http://nosql-database.org/
Key-Value, Document, Graph, Column 등 다양한 DB 종류 구분이 가능하다. 하지만 지원되는 언어는 나도 모르니 해당 공식 사이트 가서 확인하라.

composite / 2015년 6월 29일 / Piss Development / 0 Comments

composite / 2015년 6월 25일 / Piss Development / 0 Comments

Visual Studio 를 Sublime Text 처럼 쓰고 싶다면? MixEdit.

Eclipse 나 IntelliJ 등의 IDE는 정말 나름대로 강력한 편집 기능을 적용하였으나…
Visual Studio 는 정말 강력하고 나태하게 만들면서도 사용자를 아쉽게 하는 재주가 있다.
Sublime Text 의 멀티 커서 혁명이라고는 하나 UltraEdit 에서 시작됐는데,
UltraEdit 는 무겁고 확장성도 부족하고 가격도 상당히 비쌌기 때문에 Sublime Text를 구매하기에 충분한 매력이 되었다.
하지만 Github 이 이 아성(?)을 무너뜨리기 위해 Atom 에디터를 내놓고, 이 에디터 기반을 MS가 받아들여 Visual Studio Code를 출시했다.

이제 Visual Studio 의 편집에 아쉬워 할 필요가 없게 되었다.
Sublime Text를 통한 부족함을 해소시켜주는 Visual Studio 확장이 생겼으니까.

바로 MixEdit 되시겠다.

1
2

기본적인 ctrl+D 로 멀티 캐럿으로 단어 선택하고,
alt+click 으로 블록 캐럿을 활성화시켜 깔끔한 코딩 배열을 완성시킬 수 있다.
Sublime Text를 완벽히 흉내내진 않았지만, Code Alignment 의 부족함을 채워주기엔 충분한 기능이다.

안타깝게도 무료 확장은 아니다. $9.99 로 구매해야 한다.
하지만 기능이나 기간 제한은 다행히도 없다. 단지 처음 기능을 실행할때나 가끔 뜨는 구입 요구 대화 상자가 뜰 뿐.

composite / 2015년 6월 23일 / Piss Development / 0 Comments

ASP.NET WebForm 에서 대용량 다운로드 시 주의할 점

먼저 만악의 근원 ViewState를 해제해야 한다.

<%@ Page Language="C#" AutoEventWireup="true" EnableViewState="false" %>

EnableViewState 속성을 false 로 설정하면 된다.
그럼 끝.

그리고 WebForm은 대용량 다운로드 시 잼병이므로 Response.OutputBuffer = false 주는 것이 좋다.
그럼 Transfer-Encoding: chunked 헤더가 발생하여 용량은 알 수 없지만 버퍼를 재때(또는 Flush 써서) 클라이언트에 쏴버리므로 메모리를 아낄 수 있다.
아니면 이보다 더 가벼운 REST Server를 구성하는 것이 좋다. 설령 ASP.NET MVC던 Nancy 던… 그들이 더 가벼우니까.

파일 용량 보여주면서 대용량 다운받는 방법? 메모리 아끼는 효율적인 방법은 Websocket 이다. HTTP는 답 없다.
다운로더 앱이 있는 이유이기도 하다.

근데 aspx로 백날 지랄해봐야 진리는 IHttpHandler 다. 다 필요없고 HTTP 처리가 매핑해라. 존나 빠르고 편하다.

composite / 2015년 6월 9일 / Piss Development / 0 Comments

Visual Studio 2013 에서 닷넷 구버전 디버깅 팁

Visual Studio 2013 에서는 디버깅하는데 편집하며 계속하기 하고 싶지만 v4.5.1 64비트만 된다는 오류가 나온다.
먼저 64비트 디버깅은 닷넷 4.5.1 부터만 되기 때문에 만약 IIS Express 를 64비트로 사용한다면 옵션 -> 환경 -> 웹 -> 64비트 IIS 사용 체크 해제해야 한다.

디버깅할 때 구버전에서도 편집하며 계속하기를 활성화 하려면 당연히 프로젝트 속성에 편집하며 계속하기 체크 해야 하고,
도구 -> 옵션 -> 디버깅 에서 “관리되는 호환성 모드 사용” 에 체크하면 된다.
이런데도 안된다면 프로젝트를 수동으로 편집해야 하는데, 디버깅할 프로젝트를 “프로젝트 언로드” 하고,
프로젝트명을 오른쪽 마우스에 편집한다. 그리고 맨 위에 있는 <PropertyGroup> 요소 안에 아무데나 아래 문구를 삽입한다.

<_ResolveReferenceDependencies>true</_ResolveReferenceDependencies>

그리고 프로젝트 다시 로드한다.
그러면 디버깅하면서 편집도 되고 편리할 것이다.

composite / 2015년 5월 14일 / Piss Development / 0 Comments

[.NET vs JAVA] 쓰레드 동기화

고급 언어의 가장 알다가도 모를 이슈가 바로 쓰레드 동기화이다.
둘 다 Thread unsafe 의 경우는 반드시 발생을 하며, 특히 대량 처리로 인해 꼬이는 경우에 대해서는 유용하게 사용한다.
그럼 이 둘이 사용하는 동기화의 차이는 무엇일까?

결론부터 말하자면 차이점 없다. 기능 똑같다. 단지 구문만 틀릴 뿐.
자바의 경우 메소드에 synchronized 키워드를 붙일 수 있다.

public synchronized void doSomething(){
    //...
}

하지만 그래봤자 메소드 내용을 아래와 같이 처리하는 꼴이 된다.

public void doSomething(){
    synchronized(this){
        //...
    }
}

닷넷은 메소드에 동기화 키워드를 제공하지 않으며 구문으로만 제공한다.

public void DoSomething()
{
    lock(this)
    {
        //...
    }
}

그리고 임의의 private 객체 하나 지정해서 이를 사용해서 부분적인 동기화 작업을 수행하는 케이스가 대부분이다.
문제는 자바의 경우 메소드 동기화는 클래스 동기화나 다름없는데도 이를 이용하는 경우가 많다는 것이다.
물론 클래스 모두 동기화를 걸어서 일관적으로 수행하는 작업이라면 오히려 편리하지만,
그런 경우가 흔치 않기 때문에 오히려 동기화 방식은 구문 방법을 추천하고 싶다.
그 이유는 간단하다. 유연하고, 명확하며, 동기화가 필요한 부분에만 적용되어 더 빠른 처리를 제공할 수 있다.
특히 닷넷과 자바를 오가는 등의 폴리글랏 개발자라면 메소드 동기화보다 동기화 구문을 사용하자.
마이그레이션하기 존나 편할 것이다.

composite / 2015년 5월 7일 / Piss Development / 0 Comments

Microsoft Edge? 한국에게는 ‘H'(엣찌)

H를 한국에서 보통 ‘에이치’라 읽지만 일본에서는 ‘엣찌’ 라고 읽는다.
그리고 이 엣찌의 또다른 뜻이 있는데, 사실 인터넷 신조어인 셈이지만
일본어 변태적을 뜻하는 ‘헨타이’ 의 로마자 Hentai에서 H의 일본어 발음의 로마자 Ecchi 이기도 하다.
주로 매체에서… 음… 음흠 흠흠. 일단 이정도 정보 가르쳐준 거라고 고마워 하라. 모르는 사람이었다면.

어쨌든, 한국에서는 아직도 크로스 플랫폼을 자위행위로 까내리는 새끼들이 있고, 기관, 기업들이 존재한다.
마침 이 기사가 있다. MS 새 브라우저가 웹 생태계에 던진 메시지
시리즈물 기사인데, 엄청나게 영양가 없는 기사다. 개인적으로. 특히 한국이 MS 엣지를 특히 주목해야 할 이유.

나도 HTML5 개발자고, CSS에 ECMA6 등 최신 표준을 추구하는 개발자인데도 불구하고 이 기사가 영양가 없는 기사라고 할 수밖에 없는 이유가…
대한민국의 IT 산업구조와 현실에 안맞는 법, 그리고 관피아… 설명하자니 그냥 내가 성경 쓰는게 더 나을 지도 모르겠다. 그정도로 길다.
그 중에 한국이 크로스 플랫폼을 거부하는 이유 중 몇가지가 있다면…

1. 배로 불어나는 구축비용

그렇다. 기관 소개 사이트를 구축할 때 IE만 생각하면 800만원이지만 크로스 플랫폼은 1500으로 불어난다.
그래서 크로스 플랫폼은 돈아까운 기관이나 기업들에겐 참 좆같지 아니할 수 없다.
근데 요즘도 그런 자세가 보인다면 노답. 옛날 향수에 젖어 10년전 가격으로 웹사이트 구축해달라는 거나 마찬가지다.
근데 크로스 플랫폼 할 거면서 IE 구축비용을 바란다면 그냥 나가 뒤지라고 말하고 싶다.
요즘도 100만원도 안되는 가격으로 네이버처럼 만들어 달라고 하는 무식쟁이들이 판을 치는데.
참 요즘 한국에서 무식한 새끼들도 사업할 수 있다는 게 노답이긴 하다.

2. 고도화 비용을 낭비

한국은 정말 멍청하지 아니할 수 없다. 말놀리기다 시발.
어쨌든, 한국은 사이트 재구축시 아예 갈아엎고 처음부터 구축한다.
근데 웃긴게 뭐냐면 개발환경은 이전 환경 그대로 쓴다는 거다.
예를 들어, 자바 1.4 쓴 웹 사이트를 재구축하는데 이전 환경에 맞추기 위해 1.4 그대로 쓴다는 거다.
그리고 디자인만 바뀐 결과물이 완성된다.
신규 구축 비용을 들이면서 서버 업글할 돈이 없는건지 그저 현업이 귀찮은건지 참 알다가도 모르겠다.
이게 진정한 비용 낭비다… 이럴거면 뭐하러 고도화를 하냐. 시발 그냥 리뉴얼 하지. 리뉴얼이 싸게 먹히는데.

3. 쥐어짜는 개발일정

아직도 10년전 웹 기술을 답습하는 불쌍한 개발자도 많고, 웹보다 엑스플랫폼 같은 응용 솔루션이 편하다고 우기는 개발자도 있다.
그들에게 단가는 여전히 올라가지 않고, 경력이 늘어나는대도 정체된 개발과 단가에 익숙해져 무신경해진 개발자들이 있다.
그들에겐 그런 빡빡한 개발일정에 익숙하다 보니 개발일정이 넉넉해지거나, 애자일이거나 하면 오히려 무능력해지는 개발자를 발견하게 된다.
어쨌든 간에 쥐어짜는 개발일정은 잠재적 오류를 볼 시간이 부족해지며, 구축 후에 조용하던 사이트가 갑자기 무너질 때 개발자 탓을 한다.
놀고 있다.

이 외에도 많은데, 지금도 이런 개발패턴에서 변하지도 않았는데 마소 엣지 브라우저가 나온 들 달라질 거? 없다.
굳이 있다면? 이런 시나리오가 나올 가능성 100%다. 이건 윈도우 8 때도 발생했던 일이다.

“저희 서비스는 마이크로소프트 엣지를 지원하지 않습니다. 반드시 인터넷 익스프로러에서만 이용할 수 있습니다.”

그리고 이런 공문 떨어지고 땜빵하면서 뻐길 것이다. 물론 결국은 무너지게 되어 있지만.
대한민국 정부부터 기업들은 그렇게 뻐겨 왔다.

그래도 한국의 선진 개발자들은 답을 찾을 것이다. 늘 그랬듯이.

composite / 2015년 5월 6일 / Piss Development / 0 Comments