Spring Boot 프로젝트에서 초간단 docker compose 사용하기

animato댓글 남기기

Spring Boot를 사용해서 서비스를 만들 때 데이터베이스 같은 외부 서비스 들을 보통 한 개 이상 사용하게 되는데요, 이 때 docker compose를 사용하면 개발 과정에서 외부 서비스 들을 쉽게 관리할 수 있습니다.

docker-compose.yml 파일에 사용할 외부 서비스들을 정의하고 프로젝트 시작 전에 “docker-compose up” 프로젝트 종료 후 “docker-compose down” 명령어를 실행하는 방식이었죠.

Spring Boot 3.1 버전 부터는 docker compose 지원이 강화되어 프로젝트의 docker compose 파일을 감지하고 프로젝트가 기동 될 때 up, 중지 될 때 down 명령을 자동으로 실행해 줍니다.

바로 살펴봅시다!

필요 사항

  • Spring Boot 3.1 이상
  • docker-compose 2.2.0 이상

사용 방법

services:
database:
image: 'postgres'
ports:
– '5432'
environment:
– 'POSTGRES_USER=admin'
– 'POSTGRES_DB=mydatabase'
– 'POSTGRES_PASSWORD=password'
view raw docker-compose-example.yml hosted with ❤ by GitHub

위와 같은 docker-compose.yml 이 프로젝트에 있다고 가정합니다.

developmentOnly 'org.springframework.boot:spring-boot-docker-compose'
view raw build-example.gradle hosted with ❤ by GitHub

build.gradle 파일에 spring-boot-docker-compose 라이브러리를 추가합니다. 개발환경에만 활성화되도록 developmentOnly 를 적용시킵니다.

끝!

직접 실행해서 결과를 확인해보겠습니다.

실행 결과

Spring Boot 실행 로그 중 3번째 라인에서 “Using Docker Compose file …” 을 확인 할 수 있습니다. 이후 Container 를 띄우고 Healthy 상태까지 기다린 이후에 프로젝트가 시작 되는 것을 확인 할 수 있네요!

정말 간단하죠? 심지어 데이터베이스 연결 정보를 애플리케이션 프로퍼티에 지정할 필요도 없습니다. spring-boot-docker-compose 에서 docker-compose.yml 을 읽어서 연결 정보가 필요하다면 ConnectionDetails 을 자동으로 만들어 주기 때문입니다. (자동으로 연결해주는 서비스 목록)

추가 설정

만약 커넥션 주소에 옵션 값을 추가하려고 한다면 docker compose yml 파일에 다음과 같이 추가 할 수 있습니다.

services:
postgres:
image: 'postgres:15.3'
environment:
– 'POSTGRES_USER=myuser'
– 'POSTGRES_PASSWORD=secret'
– 'POSTGRES_DB=mydb'
ports:
– '5432:5432'
labels:
org.springframework.boot.jdbc.parameters: 'ssl=true&sslmode=require'
view raw docker-compose-example2.yml hosted with ❤ by GitHub

마치며

Spring Boot 3.1 부터 강화된 docker compose 지원은 로컬 개발 시 정말 손쉽게 docker compose 를 다룰 수 있도록 도와줍니다. 그동안 외부 서비스들을 별도로 띄워서 사용했다면 docker compose 를 한번 사용해 보시는 것도 좋을 것 같고 이미 docker compose를 사용하고 있었다면 Spring Boot 버전을 3.1 이상으로 올리는 것도 고려해 볼 만 할 것 같습니다. 이미 boot 버전이 3.1 이상이라면 이 기능은 안 쓸 이유가 없습니다!

참고

처음 배우는 엘릭서 프로그래밍 5장 연습문제 풀이

animato댓글 남기기

처음 배우는 엘릭서 프로그래밍 책에 포함된 연습문제에 대한 풀이를 공유합니다.

문제 5-2, 5-3 이고 조건문을 사용하지 않고 FizzBuzz를 구현하는 방법입니다.

# 5-2 인자 세 개를 받는 함수
fizz_buzz = fn
0, 0, _ -> "FizzBuzz"
0, _, _ -> "Fizz"
_, 0, _ -> "Buzz"
_, _, a -> a
end
# 5-3 FizzBuzz 함수
fizzbuzz = fn
n -> fizz_buzz.(rem(n, 3), rem(n, 5), n)
end
IO.puts fizzbuzz.(10)
IO.puts fizzbuzz.(11)
IO.puts fizzbuzz.(12)
IO.puts fizzbuzz.(13)
IO.puts fizzbuzz.(14)
IO.puts fizzbuzz.(15)
IO.puts fizzbuzz.(16)
view raw 5-FizzBuzz.exs hosted with ❤ by GitHub

처음 배우는 엘릭서 프로그래밍 2장 연습문제 풀이

animato댓글 남기기

처음 배우는 엘릭서 프로그래밍 책에 포함된 연습문제에 대한 풀이를 공유합니다.

# 처음 배우는 엘릭서 프로그래밍 연습문제
# 2-1 다음 중 매칭에 성공하는 식은 무엇일까?
a = [1, 2, 3] # 성공
a = 4 # 성공
4 = a # 성공. 단, a 가 4로 할당되어 있다면
[a, b] = [1, 2, 3] # 실패
a = [[1, 2, 3]] # 성공
[a] = [[1, 2, 3]] # 성공
[[a]] = [[1, 2, 3]] # 실패
# 2-2 다음 중 매칭에 성공하는 식은 무엇인가?
[a, b, a] = [1, 2, 3] # 실패
[a, b, a] = [1, 1, 2] # 실패
[a, b, a] = [1, 2, 1] # 성공. a = 1, b = 2
# 2-3 변수 a에 값 2가 바인딩 되어 있다면 다음 중 매칭에 성공하는 식은 무엇인가?
[a, b, a] = [1, 2, 3] # 실패
[a, b, a] = [1, 1, 2] # 실패
a = 1 # 1로 새로 바인딩 됨
^a = 2 # 성공
^a = 1 # 실패
^a = 2 - a # 실패
view raw 2.exs hosted with ❤ by GitHub

Phoenix Up and Running

animato댓글 남기기

Phoenix 는 Elixir 를 위한 웹 개발 프레임워크이다. 피닉스 가이드 문서를 따라서 간단하게 피닉스 웹 서버를 띄운다.

설치

Elixir 설치
brew install elixir

다른 플랫폼의 경우 https://elixir-lang.org/install.html 참조

Hex 설치

Elixir 설치가 처음이면 Hex 설치가 필요하다. Hex 는 Erlang 에코시스템의 패키지 매니저이다.

mix local.hex

mix 는 Elixir 의 빌드 도구이다.

Mix is a build tool that ships with Elixir that provides tasks for creating, compiling, testing your application, managing its dependencies and much more

Phoenix 생성기 설치

Phoenix 프로젝트를 생성하기 위해 다음의 명령 실행. Phoenix 생성기를 설치한다.

mix archive.install hex phx_new

프로젝트 생성

hello 라는 이름의 Phoenix 프로젝트를 만든다.

mix phx.new hello

데이터베이스를 사용하지 않을 것이라면 –no-ecto 옵션을 추가한다. Ecto 는 Elixir 를 위한 데이터베이스 래퍼와 쿼리 생성기이다.

Fetch and instll dependencies? 를 Y 로 넘어가면 다음과 같은 결과를 얻을 수 있다.

Fetch and install dependencies? [Yn] Y

* running mix deps.get
* running mix deps.compile

We are almost there! The following steps are missing:

    $ cd hello

Then configure your database in config/dev.exs and run:

    $ mix ecto.create

Start your Phoenix app with:

    $ mix phx.server

You can also run your app inside IEx (Interactive Elixir) as:

    $ iex -S mix phx.server

프로젝트 폴더로 이동 한 다음 ecto 설정을 실행한다.

cd hello
mix ecto.create

ecto 명령어 실행 중 에러가 발생하면 다음 문서를 참고한다.

postgresql 을 처음 설치했다면 role 이 없어서 오류가 발생한다. psql 에서 다음 명령어를 실행한다.

=# CREATE ROLE postgres LOGIN CREATEDB;

실행

모두 완료가 되었다면 Phoenix 서버를 실행한다.

mix phx.server

[info] Running HelloWeb.Endpoint with cowboy 2.9.0 at 127.0.0.1:4000 (http)
[info] Access HelloWeb.Endpoint at http://localhost:4000

위와 같은 로그를 확인했다면 127.0.0.1:4000 에서 첫 화면을 확인.

완료!

소프트웨어 아키텍처 101 자율 평가 문제 – 6장 아키텍처 특성의 측정 및 거버넌스

animato댓글 남기기
이 이미지는 대체 속성이 비어있습니다. 그 파일 이름은 image.png입니다
소프트웨어 아키텍처 101, 한빛미디어

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

1 아키텍처를 분석할 때 순환 복잡도가 중요한 메트릭인 이유는 무엇인가요?

순환 복잡도가 증가하면 코드의 모듈성, 시험성, 배포성 등 거의 모든 바람직한 코드베이스 특성을 저해하게 된다.

2 아키텍처 피트니스 함수는 무엇인가요? 아키텍처를 분석하는 데 이 함수를 어떻게 사용하나요?

어떤 아키텍처 특성의 객관적인 무결성을 평가하는 모든 메커니즘

아키텍처 피트니스 함수는 아키텍처가 아키텍처 목표를 달성하는데 얼마나 근접해 있는지를 나타낸다. 테스트 주도 개발에서 각각의 기능들이 얼마나 비즈니스 결과에 부합하는지 확인하기 위해 테스트 코드를 작성해서 확인하는 것 처럼 아키텍처 피트니스 함수를 통해 시스템이 아키텍처 목표에 얼마나 부합하는지 테스트 할 수 있다.

3 아키텍처 피트니스 함수를 이용해서 아키텍처 확장성을 측정하는 예를 들어보세요.

https://youtu.be/ipJtGdmyT-Y

책의 저자 중 한명인 마크 리처즈는 이 영상에서 아키텍처 확장성을 측정하는 방법을 설명하고 있다.

또한 이 글 에서는 다음과 같은 아키텍처 피트니스 함수를 통해 아키텍처 확장성을 측정할 수 있다고 한다.

describe "Performance" do
    it "completes a transaction under 10 seconds" do
        expect(transaction.check_transaction_round_trip_time()).to < 10
    end
    it "has less than 10% error rate for 10000 transactions" do
        expect(transaction.check_error_rate_for_transactions(10000)).to < .1
    end
end

4 아키텍트, 개발자가 피트니스 함수를 생성할 수 있게 하는, 아키텍처 특성의 가장 중요한 기준은 무엇인가요?

아키텍처 특성은 운영적, 구조적, 프로세스 측정 등의 기준으로 측정 할 수 있다.

참고자료

소프트웨어 아키텍처 101 자율 평가 문제 – 5장 아키텍처 특성 식별

animato댓글 남기기
이 이미지는 대체 속성이 비어있습니다. 그 파일 이름은 image.png입니다
소프트웨어 아키텍처 101, 한빛미디어

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

1 아키텍처가 지원해야 할 아키텍처 특성의 가짓수를 제한하는 것이 왜 중요한가요?

아키텍처 특성 하나하나는 전체 시스템 설계를 복잡하게 만드는 요인이기 때문에 너무 많은 아키텍처 특성을 수용하면 아키텍트, 개발자가 당초 의도했던 문제 영역의 해결을 시도하기도 전에 아키텍처가 너무 복잡해져버리게 된다.

2 대부분의 아키텍처 특성은 비즈니스 요구사항과 유저 스토리에서 비롯됩니다. 맞는 말인가요, 틀린 말인가요?

많은 아키텍처 특성이 비즈니스 요구사항과 유저 스토리에서 비롯되지만 아키텍트가 알고 있는 도메인 지식에서 도출되는 특성들도 있다. 예를 들어 대학교 학사 관리 시스템의 수강 등록을 처리하는 애플리케이션을 설계한다고 했을 때 학생들의 성향과 습관 상 수강 신청 과정에서 많은 학생들이 마감 직전에 수강 시스템에 몰린다는 것을 알고 있는 아키텍트라면 요구사항 정의서에 탄력성이 적혀 있지 않더라도 탄력성을 도출해 낼 수 있다.

3 비즈니스 이해관계자는 시장 출시 시기(즉, 새로운 기능과 버그 조치 등의 서비스를 가능한 한 신속하게 고객에게 제공하는 것)를 가장 중요한 비즈니스 관심사라고 말합니다. 이런 상황이라면 어떤 아키텍처 특성이 가장 시급하게 지원되어야 하나요?

시장 출시 시기가 중요한 비즈니스 관심사라면 이 시스템은 민첩성, 시험성, 배포성이 시급하게 지원되어야 한다.

비즈니스 요구사항을 시스템에 신속히 적용하는 민첩성이 우선적으로 고려되겠지만 단순히 민첩성만 고려할 것이 아니라 제품 출시와 연관된 여러 특성이 같이 지원되어야 한다. 예를들어 시험성이 떨어지는 아키텍처라면 버그를 조기에 발견하기 어렵고 버그를 발견한다 하더라도 해결 이후에 적절히 해결되었는지 제대로 시험하기가 어렵다. 그러면 버그 조치등의 활동이 전체적으로 느려지게 되고 이는 시장 출시 시기에 부정적인 영향을 주게 된다. 또한 배포성을 제대로 지원하지 않는 아키텍처라면 새로운 기능이 추가 될 때마다 배포 하는 과정에서 많은 시간을 들여야 할 것이기 때문에 시장 출시 시기에 좋지 않은 영향을 줄 수 있다. 따라서 시장 출시 시기가 중요한 비즈니스 관심사라면 민첩성을 비롯하여 시험성, 배포성 등 제품 출시와 연관된 여러 특성을 종합적으로 고려해야 한다.

4 확장성과 탄력성의 차이점은 무엇인가요?

확장성은 유의미한 성능 저하 없이 다수의 동시 유저를 처리하는 능력을 말한다. 확장성이 있는 시스템은 이용자가 꾸준히 늘더라도 추가 이용자를 처리하기 위해 시스템을 변경하거나 추가 리소스를 할당하기 용이한 시스템이다.

반면 탄력성은 트래픽의 폭주하는 정도를 나타낸다. 탄력성의 목적은 할당된 리소스를 지정된 시점에 필요한 실제 리소스 양과 일치 시키는 것이다. 탄력성이 있는 시스템은 갑자기 사용자가 폭증하더라도 사용자 요청을 처리하기 위한 리소스 추가 할당이 적절한 시점에 이루어져 성능 저하 혹은 시스템 다운이 일어나지 않는 시스템이다.

5 고객사가 고객층을 크게 넓히고자 몇 가지 중요한 기업 인수를 추진할 계획이라고 합니다. 여러분은 어떤 아키텍처 특성을 가장 신경 써야 하나요?

기업 인수가 성사된다면 서로 다른 환경에서 만들어진 시스템이 통합 되어야 하는 상황이 일어날 수 있다. 따라서 이와 관련되는 시스템에서는 상호운용성, 확장성, 적응성, 신장성 등의 아키텍처 특성을 고려해야 한다.

참조

소프트웨어 아키텍처 101 자율 평가 문제 – 4장 아키텍처 특성 정의

animato댓글 남기기
이 이미지는 대체 속성이 비어있습니다. 그 파일 이름은 image.png입니다
소프트웨어 아키텍처 101, 한빛미디어

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

1 어떤 속성이 아키텍처 특성이 되려면 충족해야 할 세 기준은 무엇인가요?

  • 비도메인 설계 고려 사항을 명시한다.
  • 설계의 구조적 측면에 영향을 미친다.
  • 애플리케이션 성공에 (절대적으로) 중요하다.

2 암묵적 특성과 명시적 특성의 차이점은 무엇인가요? 각각의 예를 들어보세요.

암묵적 아키텍처 특성은 요구사항 정의서에는 거의 안 나오지만 프로젝트 성공을 위해 꼭 필요한 특성들이다.
예를들어, 가용성, 신뢰성, 보안은 거의 모든 애플리케이션에 필요한 특성이지만 설계 문서에는 잘 등장하지 않는다.

명시적 아키텍처 특성은 요구사항 정의서나 다른 지침서에 기재된다.

3 운영 특성(operational characteristic)의 예를 들어보세요.

특성설명
가용성시스템이 얼마나 오랫동안 사용 가능해야 하나?
연속성재해 복구 능력
성능스트레스 테스트, 피크 분석, 기능의 사용 빈도 분석, 필요 용량, 응답 시간 등
복구성장애 발생 시 얼마나 신속하게 시스템을 재가동 시켜야 하나?
신뢰성/안전시스템에 fail-safe 가 필요한가?
견고성프로그램 실행 중 인터넷 접속 끊김, 정전, 하드웨어 실패 등 에러 및 경계 조건을 감당하는 능력
확장성유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력

4 구조 특성(structural characteristic)의 예를 들어보세요.

특성설명
설정성최종 유저가 소프트웨어 설정을 쉽게 바꿀 수 있는가?
신장성새로운 기능을 삽입하는 일의 중요성
설치성필요한 모든 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있나?
활용성/재사용공통 컴포넌트를 여러 제품에서 활용할 수 있나?
지역성데이터를 입력/조회하는 화면에서 다국어가 지원되는가?
유지보수성시스템을 얼마나 쉽게 변경/개선할 수 있나?
이식성하나 이상의 플랫폼에서 시스템을 실행할 수 있나?
지원성애플리케이션은 어느 정도의 기술 지원을 필요로 하나?
업그레이드성이 애플리케이션/솔루션의 구 버전을 새 버전으로 쉽고 빠르게 업그레이드 할 수 있는가?

5 공통 특성(cross-cutting characteristic)의 예를 들어보세요.

특성설명
접근성색맹, 청각 장애인 등 모든 유저가 접근하는 데 불편함이 없나?
보관성데이터를 따로 아카이빙 해야하나, 아니면 일정 시간 경과 후 삭제해야 하나?
인증유저가 본인이 맞다는 것을 증명하기 위해 필요한 보안 요구사항
인가유저가 애플리케이션에서 정해진 기능만 사용할 수 있도록 강제하는 보안 요구사항
합법성시스템 운영상 법적 제약조건이 있는가?
프라이버시회사 내부 임직원의 트랜잭션을 외부에 드러내지 않는 기능
보안데이터를 암호화 한 후 데이터베이스에 보관해야하나?
사용성/성취성유저가 애플리케이션/솔루션을 이용하여 원하는 목적을 달성하기 위해 필요한 교육/훈련 수준

참고

소프트웨어 아키텍처 101 자율 평가 문제 – 3장 모듈성

animato댓글 남기기
이 이미지는 대체 속성이 비어있습니다. 그 파일 이름은 image.png입니다
소프트웨어 아키텍처 101, 한빛미디어

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

1. 커네이선스라는 용어는 무엇을 의미하나요?

두 컴포넌트 중 한쪽이 변경될 경우 다른 쪽도 변경해야 전체 시스템의 정합성이 맞는다면 이들은 커네이선스를 갖고 있다고 말할 수 있다.

2. 정적 커네이선스와 동적 커네이선스의 차이점은 무엇인가요?

정적 커네이선스: 소스 코드 레벨의 커플링
동적 커네이선스: 런타임 상황에서 확인할 수 있는 커네이선스

3. 타입 커네이선스는 무엇인가요? 이것은 정적 커네이선스인가요, 아니면 동적 커네이선스인가요?

타입 커네이선스는 정적 커네이선스 중 하나로 여러 컴포넌트의 엔티티 타입이 일치해야 하는것을 뜻한다.

4. 가장 강력한 형태의 커네이선스는 무엇인가요?

동적 커네이선스 중 식별 커네이선스
여러 컴포넌트가 동일한 엔티티를 참조하는 경우에 발생

5. 가장 약한 형태의 커네이선스는 무엇인가요?

정적 커네이선스 중 명칭 커네이선스
여러 컴포넌트의 엔티티명이 일치해야 하는 경우에 발생

6. 정적 커네이선스, 동적 커네이선스 중 코드베이스에서는 어느 쪽이 더 바람직한가요?

정적 커네이선스는 동적 커네이선스에 비해 쉽게 개선할 수 있고 동적 커네이선스는 효과적인 분석 도구가 많지 않아 파악하기 어려우므로 정적 커네이선스가 코드베이스에 더 바람직하다. 그리고 동일한 커네이선스가 널리 흩어져 있는 것 보다는 가까이 붙어 있는것이 더 바람직하다(커네이선스의 지역성). 또한 커네이선스가 미치는 영향의 규모 값(degree)이 작을수록 코드베이스에 바람직하다.

참고

소프트웨어 아키텍처 101 자율 평가 문제 – 2장 아키텍처 사고

animato댓글 남기기
소프트웨어 아키텍처 101, 한빛미디어

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

아키텍처 대 개발의 기존 접근 방식을 설명하고, 이제는 더 이상 기존 접근 방식이 통하지 않는 이유를 설명하세요.

전통적인 아키텍트의 책임과 개발자의 책임은 다음과 같다. 아키텍트는 비즈니스 요구사항을 분석해서 아키텍처 특성을 도출/정의하고 각종 컴포넌트를 포함한 아티팩트를 만들어 개발팀에 전달 -> 개발팀은 각 컴포넌트의 설계를 하고 코드를 개발/테스트

전통적인 아키텍처 대 개발의 접근 방식은 아키텍트가 내린 결정이 개발팀에서 전혀 쓸모가 없는 경우가 있음에도 불구하고, 개발팀이 아키텍처를 변경하기로 결정한 내용이 다시 아키텍트에게 전달되는 일이 거의 없다.

변화에 둔감하고 융통성 없는 구식 폭포수 모델과 달리, 요즘 시스템 아키텍처는 매 프로젝트 단계마다, 또는 매 이터레이션마다 끊임없이 변화하고 발전하기 때문에 프로젝트를 성공으로 이끌려면 아키텍트와 개발팀이 모두 활발히 소통하고 프로젝트 생명 주기의 일부로서 항상 서로 동기화 되어야 한다.

지식 피라미드의 세 레벨의 지식을 열거하고 각각의 예를 들어보세요.

지식 피라미드의 세 레벨 (나의 예)

  1. 내가 알고 있는 것 (스프링 웹 백엔드 개발, 클라우드 서비스 활용 웹 개발 등)
  2. 내가 모른다는 사실을 아는 것 (NoSQL, 최신 프론트 웹 개발 등)
  3. 내가 모른다는 사실조차 모르는 것 (열거할 수 없음)

아키텍트에게는 왜 기술의 깊이보다 폭에 집중하는 것이 더 중요한가요?

아키텍트는 기술적인 제약 하에 어떤 기능이 가장 알맞는지 결정해야 하므로 아주 폭넓은 솔루션을 두루 꿰고 있어야 한다.

아키텍트로서 기술 깊이를 유지하고 실무 능력을 잃지 않으려면 어떻게 해야 하나요?

  1. 개념 증명(Proof of Concept)을 자주 해본다.
  2. 중요한 유저 스토리 작업은 개발팀에 맡기고 기술 부채 스토리나 아키텍처 스토리에 전념한다.
  3. 이터레이션 동안 버그를 잡는다.
  4. 간단한 커맨드라인 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화, 자동화 한다.
  5. 아키텍처의 컴플라이언스 보장을 자동화하기 위한 피트니스 함수를 만든다.
  6. 자주 코드리뷰를 한다.

참고

소프트웨어 아키텍처 101 자율 평가 문제 – 1 서론

animato댓글 남기기
소프트웨어 아키텍처 101, 한빛미디어

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

소프트웨어 아키텍처를 정의하는 네 차원은 무엇인가요?

  1. 아키텍처 특성(architecture characteristic)
    시스템의 기능과 직교하는 시스템의 성공 기준
    시스템이 지원해야 하는 ‘~성’ 들 (ex: 가용성, 신뢰성, 시험성, 확장성, 보안, 민첩성 등)
  2. 아키텍처 결정(architecture decision)
    시스템 구축에 필요한 규칙들
    시스템의 제약조건을 형성, 개발자가 해도 되는 것과 하지 말아야 할 것을 알려줌
  3. 설계 원칙(design principle)
    소프트웨어의 조건과 구현 방안에 대한 가이드라인
    (ex: 마이크로서비스 아키텍처의 성능 향상을 위한 서비스 간 통신은 비동기 메시징을 활용해야함)
  4. 구조(structure)
    시스템이 구현된 아키텍처 스타일(들)의 종류
    (ex: 마이크로서비스, 레이어드, 마이크로커널 등)

아키텍처 결정과 설계 원칙은 어떤 차이점이 있나요?

아키텍처 결정이 반드시 지켜야 할 규칙이라면 설계 원칙은 가이드라인
소프트웨어의 모든 조건과 구현 방안을 아키텍처 결정(규칙)으로 다룰 수는 없기에 권장하는 방법에 관한 가이드를 설계 원칙으로 제공

소프트웨어 아키텍트의 8대 핵심 기대치를 나열하세요

  1. 아키텍처 결정을 내린다.
    아키텍트는 기술 선택을 가이드 하는 사람이지 정해주는 사람이 아니다.
  2. 아키텍처를 지속적으로 분석한다.
    ex: 3년 이전에 정의한 아키텍처가 지금도 얼마나 현실성 있는지 평가
  3. 최신 트렌드를 계속 유지한다.
    항상 최신 기술과 업계 트렌드를 따라가야 함
  4. 아키텍처 결정의 컴플라이언스를 보장한다.
    아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙들을 개발팀이 제대로 준수하고 있는지 지속적으로 확인
  5. 다양한 기술과 경험에 노출된다.
    유능한 아키텍트는 여러가지 언어, 플랫폼, 기술을 경험할 기회를 적극적으로 모색하면서 기술의 깊이보다는 폭에 초점을 둔다.
  6. 비즈니스 도메인 지식을 보유한다.
    비즈니스 도메인 지식이 없으면 비즈니스의 문제점, 목표, 요구사항을 이해하기 어렵고, 따라서 비즈니스 요구사항을 수용할 만한 효율적인 아키텍처를 설계하기도 어려움.
  7. 대인 관계 기술이 뛰어나다.
    아키텍트는 개발팀을 기술적으로 이끌기만 하는 사람이 아니라, 개발팀을 리드해서 아키텍처를 구현하는 사람이므로 직책 또는 역할과 상관 없이, 리더십 스킬은 아키텍트로서 성공하기 위해 필수 요구사항의 절반 이상은 차지함.
  8. 정치를 이해하고 처세를 잘한다.
    아키텍트가 내린 거의 모든 결정은 사람들의 반발에 부딪히게 마련이다. 따라서 대부분의 결정을 사람들이 수용하도록 기본적인 협상 기술을 발휘해야 함.

소프트웨어 아키텍처 제1법칙은 무엇인가요?

소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.

참고

소프트웨어 아키텍처 101