LINQ(.NET Language Integrated Query) 프로젝트는 데이터 소스 뿐만 아니라 개발을 위한 데이터 접근을 표준화하려는 MS의 이니셔티브이다. LINQ를 검토한 일부 개발자들은 데이터베이스 애플리케이션 개발이 혁신적으로 변화할 것이라고 주장했다.

내 생각에는 LINQ를 진지하게 수용하려면 몇 가지 장벽이 해결돼야 한다고 본다. 그러나 LINQ는 흥미로운 장점이 몇 가지 있으며, SQL 개발자들과 DBA에게 있어서 이 새로운 기술과 이 기술이 약속하는 미래에 대해 알아볼 필요성이 있다.

LINQ의 장점으로는 우선 관계형 데이터베이스 테이블 뿐만 아니라 텍스트 파일, XML 파일, 그리고 동일한 구문을 사용하는 데이터 소스에 질의를 할 수 있다는 점을 들 수 있다. 두 번째 장점으로는 C#, VB.NET 등 임의의 .NET 호환 언어로 이 표준화된 방식을 사용할 수 있다는 점이다.

LINQ의 작동원리
다음의 코드는 C#로 작성된 간단한 LINQ 코드 블록으로 노스윈드 데이터베이스를 타겟으로 한다. LINQ의 작동을 보기 위해 표준 질의 연산자를 사용해 배열로 된 콘텐츠를 처리하는 간단한 C# 3.0 프로그램을 살펴보자.

using System;
using System.Query;
using System.Collections.Generic;

class app {
static void Main() {
string[] names = { "Alpha", "Brian", "Connie", "David",
"Frank", "George",
"Harry", "Inigo" };

IEnumerable expr = from s in names
where s.Length == 5
orderby s
select s.ToUpper();

foreach (string item in expr)
Console.WriteLine(item);
}
}

This program delivers this output:

이 프로그램은 다음과 같은 출력을 낸다:

ALPHA
BRIAN
DAVID
FRANK
HARRY
INIGO

위 예제는 LINQ의 코딩 스타일을 보여주며 프론트 엔드로 코드가 이동하는 것을 보여준다. 내 생각에는 코드가 백 엔드로 가는 것이 맞다. 그러나 코드가 깨끗하고 비교적 투명하다는 사실은 인정한다.

프론트 엔드와 백 엔드의 의미
전통적인 클라이언트-서버 구성에서 프론트 엔드와 백 엔드에 대해 간단히 논하겠다. 백 엔드는 데이터베이스 자체로 서버에 상주한다. 프론트 엔드는 일련의 클라이언트 애플리케이션으로 원하는 데이터베이스와 통신한다.

여기에는 비주얼 베이직, C++, PHP 와 같이 선택된 프로그래밍 언어로 작성된 애플리케이션이 포함된다. 프론트 엔드에는 또한 MS 액세스, 엑셀, 워드와 같은 애플리케이션도 포함시켜야 된다.

100명 이하의 직원을 둔 소규모 기업에서 이러한 구분은 학문적으로 들릴 수 있지만 나의 주장은 "성공을 위해 설계하라. 그렇지 못하다면 이미 실패를 포함하고 있는 것"이다.

따라서 나는 가능한 많은 부분을 프론트 엔드가 아닌 백 엔드에 넣고 싶어한다. 레코드 집합을 만들고 하나 혹은 두개의 매개변수로 선택을 하며 하나 혹은 두개의 열에 의해 정렬을 하는 프로시저나 함수를 내가 작성한다고 가정하자.

만약 이런 로직을 프론트 엔드에 넣는다면 다음 주나 다음 달에 도입되는 새로운 프론트 엔드에 이를 새로이 포함시켜야 할 것이다. 우리는 로직이 언어에 독립적이라 생각하고 싶지만 실제로는 그렇지 않다.

개발은 전통적인 클라이언트-서버에서 다양한 3단계 아키텍처(DLL __hell, SOAP 등)로 발전됐다. 이런 아키텍처에서 프론트 엔드는 상당한 로직을 포함하고 있는 가운데 티어와 통신하며 관심있는 모든 프론트 엔드에 의해 접근될 수 있다.

가운데 티어는 이제 원하는 데이터베이스와 통신한다. 이런 통신을 성취하는 방식은 프론트 엔드 언어와 가운데 티어의 구현에 의존적이지만 가운데 티어가 데이터베이스 서버와 통신하며 프론트 엔드는 가운데 티어와 통신할 때 자기 자신만 신경쓰면 된다. 따라서 백 엔드라는 용어는 이런 아키텍처도 포함하도록 내가 확장시켰다.

내가 말하려는 바는 프론트 엔드는 최소화되어야 한다는 점이다. 가운데 티어를 사용한다면 가능한 많은 로직을 이리로 옮기고 디자인을 재고한 다음 가능한 모든 로직을 백 엔드로 옮긴다.

나의 주관이 나의 낙관론에 어두움을 드리우는 것 같다

나는 다음의 주장이 성스러운 원칙이었으면 좋겠다: 백 엔드의 기능에 관계없이 백 엔드는 동작해야 한다. 이런 주관을 가진 나는 왜 데이터베이스 로직이 프론트 엔드로 가서는 안된다고 보는지 이제 이해할 수 있을 것이다.

왜 이 원칙에 대해 완고하냐고? 내 경험에 의하면 다양한 프론트 엔드 애플리케이션 (웹 사이트, 비쥬얼 스튜디오 애플리케이션, 델파이 애플리케이션))이 하나의 데이타베이스로 향할 수 있기 때문이다. 코드를 백 엔드에서 프론트 엔드로 옮길 수 있다면 프론트 엔드 사이에서도 이동이 가능하다. 만약 비주얼 스튜디오 닷넷을 계속 사용하기로 했다면 이것도 괜찮지만 당신 혹은 직원이 다른 생각을 가지고 있다면 어떻게 할 것인가? 아니면 이런 로직을 다른 데이터베이스에 포팅하고자 한다면?

내 관점이 모두의 지지를 받는 것은 아니다. 나는 어떤 경우 임의의 동적으로 구축된 질의를 필요로 하는 애플리케이션과 상황이 있다고 주장하는 개발자들을 알고 있다. 나는 이러한 상황이 충분히 분석되지 않았다고 주장하지만 내가 틀려도 좋다. 따라서 다른 관점을 검토하고 이것이 옳다고 가정하자. N개의 상황하에서 올바른 단 한 가지 길은 프론트 엔드가 유효한 SQL 명령문을 만들고, 코드를 SQL 인젝션에서 보호하며, 명령어를 데이터베이스 엔진으로 넘긴다.

또한 어떤 입장이 진실이냐를 떠나서 SQL 명령을 백 엔드가 아닌 프론트 엔드에서 개발하기를 원하는 수 많은 개발자들이 있다고 가정하자. 이러한 사람들에게 LINQ 가 가장 인기가 있을 것이다. 나의 성스러운 원칙에 여러분이 동의하는 것만큼 여러분은 이런 프론트 엔드로의 전환이 마땅치 않을 것이다.

판단은 유보적
이 신기술이 데이터베이스 기술에 있어서 다음 번 대박이 될 지 판단하기엔 너무 이르다. 우선 다양한 데이터베이스와 애플리케이션 개발 상황에서 평가돼야 한다. 내 생각에 LINQ 의 멀티-데이터 소스 추상화는 매우 멋지지만 내가 말한 것처럼 코드를 백 엔드에서 프론트 엔드로 옮기는 것은 본질적으로 실수라고 본다.

시간만이 답을 알 것이다.

그러나 LINQ의 장점이 증명될 그 시점이 될 때까지(백 엔드에 로직을 포함하고 프론트 엔드는 프로시저 저장과 원하는 매개변수 공급을 위한 쉬운 호출을 작성하는 것과 비교할 때) 나는 "전통적인" 방식을 고수할 것이다. 백 엔드의 기능에 상관없이 백 엔드는 동작해야 한다.@